TS-4900 Production: Difference between revisions

From embeddedTS Manuals
m (Links auto-updated for 2022 re-branding ( https://files.embeddedarm.com/ts-socket-macrocontrollers/ts-4900-linux/usb-blaster/old/ts-imx6-usbprod.tar.bz2 →‎ https://files.embeddedTS.com/ts-socket-macrocontrollers/ts-4900-linux/usb-blaster/old/ts-imx6-usbprod.tar.bz2 https://support.embeddedarm.com/support/tickets/new?type=support-request&product=menu →‎ https://support.embeddedTS.com/support/tickets/new?type=support-request&product=menu))
m (Non-link text auto-updated for 2022 re-branding ( http://ftp.embeddedarm.com/ftp/ts-socket-macrocontrollers/ts-4900-linux/distributions/debian/debian-armhf-jessie-20150526.tar.bz2 →‎ http://ftp.embeddedTS.com/ftp/ts-socket-macrocontrollers/ts-4900-linux/distributions/debian/debian-armhf-jessie-20150526.tar.bz2))
 
Line 13: Line 13:
# Now you would create your images on the /mnt/sd/, but for
# Now you would create your images on the /mnt/sd/, but for
# an example these steps would write our latest debian image:
# an example these steps would write our latest debian image:
sudo wget -O /mnt/sd/emmcimage.tar.bz2 http://ftp.embeddedarm.com/ftp/ts-socket-macrocontrollers/ts-4900-linux/distributions/debian/debian-armhf-jessie-20150526.tar.bz2
sudo wget -O /mnt/sd/emmcimage.tar.bz2 http://ftp.embeddedTS.com/ftp/ts-socket-macrocontrollers/ts-4900-linux/distributions/debian/debian-armhf-jessie-20150526.tar.bz2
# You can use a symlink to write the same image to sd
# You can use a symlink to write the same image to sd
sudo ln -s /mnt/sd/emmcimage.tar.bz2 /mnt/sd/sdimage.tar.bz2
sudo ln -s /mnt/sd/emmcimage.tar.bz2 /mnt/sd/sdimage.tar.bz2

Latest revision as of 14:23, 18 January 2022

Our i.MX6 based products include a hook in U-Boot to look for a USB mass storage device and execute a U-Boot script file, "/tsinit.ub", if it exists on the first partition of the drive. This can be used to program microSD, eMMC, SATA, and customized U-Boot environments for your final production process. This process would involve simply plugging in a thumbdrive, powering on the unit, waiting 10-15 minutes, and looking for the blinking green LED for a pass, or blinking red for failure.

The USB blasting image can be downloaded here. This includes a basic Linux kernel, and a small initramfs that will mount the USB drive at /mnt/usb/, and execute /mnt/usb/blast.sh.

The blast image/scripts requires 10 MB, so the drive must be a size that will fit this and any other supporting files that your process requires. The partition can be formatted at FAT32, vfat, or ext2/3/4. To create this on a Linux workstation:

# This assumes the drive is /dev/sdc, and already has a single partition:
sudo mkfs.ext3 /dev/sdc1
sudo mkdir /mnt/sd/
sudo mount /dev/sdc1 /mnt/sd/
sudo tar xf /path/to/ts-imx6-usbprod.tar.bz2 -C /mnt/sd/

# Now you would create your images on the /mnt/sd/, but for
# an example these steps would write our latest debian image:
sudo wget -O /mnt/sd/emmcimage.tar.bz2 http://ftp.embeddedTS.com/ftp/ts-socket-macrocontrollers/ts-4900-linux/distributions/debian/debian-armhf-jessie-20150526.tar.bz2
# You can use a symlink to write the same image to sd
sudo ln -s /mnt/sd/emmcimage.tar.bz2 /mnt/sd/sdimage.tar.bz2
sudo umount /mnt/sd
sync
Note: The ext4 filesystem can be used instead of ext3, but it may require additional options. U-Boot does not support the 64bit addressing added as the default behavior in recent revisions of mkfs.ext4. If using e2fsprogs 1.43 or newer, the options "-O ^64bit,^metadata_csum" must be used with ext4 for proper compatibility. Older versions of e2fsprogs do not need these options passed nor are they needed for ext3.

Our default blast.sh will look for these files:

  • sdimage.tar.bz2
  • emmcimage.tar.bz2
  • sataimage.tar.bz2 (dual/quad only)
  • sdimage.dd.bz2
  • emmcimage.dd.bz2
  • sataimage.dd.bz2 (dual/quad only)
  • u-boot.imx
  • env.txt
Note: These can be symlinks, however the file they point to must be the specified format, disk image or tarball.
Note: It is not possible to use both a disk image and a tarball together on a single storage device. However, when writing to multiple devices they do not need to all be the same format. For example, it's possible to write to eMMC with a disk image, but provide a tarball for the microSD and have them both written successfully.

Using a tarball for microSD, eMMC, or SATA will result in the process creating a single partition on the specific flash device, format it as ext4, and extract the contents of the tarball to the root directory of the new partition. Note that no matter what the existing partition scheme was, it will be wiped and a single partition will be created in its place. If there is an "md5sums.txt" file in the root of the filesystem, the process will verify the newly unpacked file structure using the MD5 signatures in this file. Details about this file and a script to create it can be found at the end of this section.

Full disk images ending with ".dd.bz2" will write the image directly to the media byte for byte. If a ".dd.md5" file exists which contains the md5sum of the image, the disk will be read back and verified against this MD5 hash. A compatible file for the microSD for example, can be created with the command 'md5sum sdimage.dd > sdimage.dd.md5'. The md5 file must not be created from the image file after it is compressed.

The "u-boot.imx" file will be written to the SPI flash. Ensure that the file version matches the specific processor on the device being processed! If you are uncertain, please contact support. The process will verify the U-Boot binary after it is written if there is a "u-boot.imx.md5" file. This can be created with the command 'md5sum u-boot.imx > u-boot.imx.md5'.

The env.txt file will be written to the U-Boot environment. If this file is present, then the existing contents of the U-Boot environment in the SPI flash will be erased, followed by the new environment variables written to SPI. This file expects the format to be:

<variable 1> <value 1>
<variable 2> <value 2>

For example, to change "bootcmd" to always boot to eMMC, first create a "env.txt" file with these contents:

bootcmd run emmcboot;

USB production in the manner described above is provided by the 'usbprod' command run as a part of "bootcmd". In order to speed up boot times, the call to 'usbprod' can be removed as done above. However, removing it will not allow future updates via USB to occur in the same manner. It is possible to modify the above to boot straight to eMMC, but still retain USB update functionality:

bootcmd run usbprod; run emmcboot;

When the script begins the red LED will blink. When it is finished, red will turn off and green will blink. The blast.sh script includes all of this logic, and can be customized for the users application to pull the image instead from http/nfs on the local network.

(Optional) Add md5sum verification to your image


If your image includes a "md5sums.txt" in the rootfs, that image will be verified after writing. This script can be used to add an md5sums.txt into your image.

#!/bin/bash
for img in *.tar.bz2; 
	do mkdir tmp >/dev/null 2>&1
	tar --numeric-owner -xf $img -C tmp/
	cd tmp/
	rm md5sums.txt > /dev/null 2>&1
	rm ../md5sums.txt > /dev/null 2>&1
	find . -type f -print0 | xargs -0 md5sum >> ../md5sums.txt
	mv ../md5sums.txt .
	mkdir ../out/ >/dev/null 2>&1
	tar --numeric-owner -cjf ../out/"$img" *
	cd ../
	rm -rf tmp/
done

Save this script into a "addmd5sums.sh", put it and your image(s) (tar.bz2) in a directory. These should be the only files in the directory.

sudo ./addmd5sums
ls out/

The images in out will include the md5sums.txt.