I am creating a process to load some Colibri iMX6S 256MB IT V1.1A during production assembly.
The module is installed into a custom carrier board which has an SMSC (Microchip) USB2514B USB hub and four USB type A jacks.
I have compiled a custom U-Boot with some changes to the PIN MUX for a 24-bit parallel RGB display and some additional GPIOs. The default environment CONFIG_ENV_SIZE was also changed from 8192 to 16,384. I also compiled a custom Linux Kernel to support the 24-bit RGB display and some other devices on the carrier board.
The goal is to take a new board delivered from Toradex with the Toradex Easy Installer and install these customer images.
The process is:
Insert USB drive with a tezi_config.json file with a image_list to a HTTP server image_list.json.
The HTTP server image_list.json only has one entry to a subdirectory with the image.json file.
The image.json file defines the mmcblk0 paritions for the BOOT, two rootfs (ROOTFS0, ROOTFS1) and a fourth partition for DATA. The image.json has autoinstall=true.
The image.json section for mmcblk0boot0 defines the U-Boot images.
SPL with dd_options “seek=2”
u-boot.img with dd_options “seek=138”
env_uboot_16K.img with dd_options “seek=4063”
The env_uboot_16K.img has some custom environment variables such as removing the vidargs and setting panel equal to the name of the display I added to the displays in the colibri_imx6.c.
My initial testing to create this process was with a Colibri iMX6S 256MB V1.0A (not IT). When I insert the USB drive and power on the device the Toradex Easy Installer successfully installs the images and when it completes I power off the device and remove the USB drive. When I power it back on U-Boot has the custom environment I created and boots the Linux Kernel.
When I switched to the next device I have a Colibri iMX6S 256MB IT V1.1A installed, we want the IT version in the production product. I perform the same steps with the same USB drive and HTTP server and the Easy Installer does complete successfully. When power down the device and remove the USB drive and power the device back on U-Boot shows the Warning - bad CRC, using default environment.
I have read that there are some things done in the SPL to adjust the DRAM timings for the IT version. Is there something that would cause the CRC check on the environment to fail on the industrial temperature version and not the commercial temperature? Or is this a difference between the V1.0A and the V1.1A? I was thinking that there might be some difference in the config block that I don’t see.
I did discover that using either fw_printenv or fw_setenv during the wrapup.sh would cause a bad CRC. This is cause by the fact that the Easy Installer has a /etc/fw_env.config set to the 8K size and offset.