We have previously used a Colibri iMX6S 256MB with 4GB eMMC on our custom carrier board. We recently started testing with the Colibri iMX7D 1GB with 4GB eMMC. I modified U-Boot and the Linux Kernel to support the pinmux changes for the custom carrier board and was able to replace the u-boot.imx, zImage and device tree in a Tezi image and copy to a USB drive. I used Tezi to install this image for the USB drive and the Colibri iMX7 did boot these new images and everything seemed to be working fine. At this point the only way to update U-Boot is to put the module in recovery mode by shorting the pins and load Tezi to RAM and install the updated image from USB. With the iMX6 we were able to use the update scripts and run setupdate and we would like to use this for the iMX7 as well. Using the update.sh and flash_eth.scr from the iMX6 as reference I created new scripts for the iMX7. After the first time running “run setupdate” and “run update” the iMX7 module will no longer boot, U-Boot does not start. I am able to put the module into recovery mode and run recovery-linux.sh to load Tezi to RAM and select any of the Toradex images listed and it completes the install successfully but when the board is powered down and back up it still does not boot. I did notice that with the USB_OTG cable plugged in the module will eventually, approximately 10 seconds, enter recovery mode on its own. This seems to indicate that the iMX7 attempted to boot from eMMC but failed and fell back to recovery (serial download) mode. I think that either the BOOT_MODE fuses or the eMMC configuration got changed. There is nothing in the scripts that would have attempted to change the fuses but it would have issued the command “mmc bootbus 0 2 0 1”. I know the update scripts are not supported on the eMMC but I was hoping that I could get some information on how the iMX7 should be configured to boot eMMC. I can load Tezi to RAM and access the /sys/fsl_otp to view the fuse settings. I can also use the mmc bootbus and mmc partconf commands. Could you provide information on how the iMX7 should be configured to boot from the eMMC?
Could you provide the version of the hardware and software of your module? Which carrier Board are you using?
Can you please share the error log when the module is not booting?
The module is a Colibri IMX7D 1GB V1.1A.
The carrier board is a custom design board. I used the Toradex carrier board design guide and schematics of the Toradex carrier boards as reference. This custom board was designed such that it would be compatible with all Colibri modules. I also have a Toradex Iris carrier board V1.1A which I could use if it is necessary to recover the module.
The module originally came with Toradex Easy Installer (Tezi) but I do not remember which version. The software that I am attempting to load is a custom build of U-Boot cloned from the Toradex u-boot-toradex.git branch 2016.11-toradex and a custom Linux Kernel cloned from Toradex linux-toradex.git branch toradex_4.1-2.0.x-imx. The changes to U-Boot and Linux Kernel are mainly to configure the i.MX7 pins for a 24-bit RGB LCD display and a few GPIO. As stated before I used the Toradex images and replaced the u-boot.imx, zImage and device tree and was able to install them using the Toradex Easy Installer. The issue happened when I tried to load the images using the update scripts. Since Toradex does not have update scripts for the i.MX7 with eMMC I modified the scripts for the i.MX6 Colibri module. After attempting to use these new update scripts the first time the i.MX7 will no longer boot. When the board is powered on nothing is printed to the debug console. I can put the module into recovery mode by shorting the pads on the i.MX7 module and load Toradex Easy Installer to RAM using the recovery-linux.sh script. The Toradex Easy Installer shows the images for LXDE (Stable) 2.7, LXDE 2.8b2 and Toradex Easy Installer 1.5. I can select any of these images and it appears to install correctly but they do not boot when the module is power cycled. The module does not seem to be loading U-Boot since nothing is printed to the console port.
To answer your question, since nothing is printed to the debug console I do not have any log information. I did notice that when powered after approximately 10 seconds the USB_OTG port shows device ID 15a2:0076 of the module in recovery (serial download) mode. I believe the internal boot code of the i.MX7 is not loading the u-boot image form eMMC and finally falls back to serial downloader mode.
I believe something has either changed in the i.MX7 boot settings or the eMMC is not configured properly. The update scripts that I used should not have modified the boot settings of the i.MX7 but did run the command “mmc bootbus 0 2 0 1” which would modify the eMMC. Since that command was in the original flash_eth.scr for the i.MX6 it may not be appropriate for the i.MX7. I was wondering if you could provide details on how the eMMC should be configured for the i.MX7. Also when Toradex Easy Installer is running from RAM I have access to the Linux console to view information from /sys/fsl_otp or possibly change settings. Is there any command or steps that I can go to get the i.MX7 module back to the factory settings?
As you suspected, on Colibri iMX7D 1GB we use slightly different settings to boot from eMMC. This probably causes the issue.
First, you can check the SoC fuses, they should be as follows:
Colibri iMX7 # fuse read 1 3
Reading bank 1:
Word 0x00000003: 100028e4
Colibri iMX7 # fuse read 2 2
Reading bank 2:
Word 0x00000002: 00000002
Toradex Easy Installer in recovery mode uses a U-Boot without flash support (so we can use the same U-Boot for Colibri iMX7D with eMMC and with raw NAND). To recover a U-Boot with eMMC support, use the following command:
sudo ./recovery/imx_usb u-boot.imx-emmc
Then press Ctrl+C to get to the U-Boot console.
To configure the eMMC boot configuration use
Colibri iMX7 # mmc bootbus 0 2 0 2
- boot_bus_width: 2 (8-bit)
- reset_boot_bus_width: 0
- boot_mode: 2 (use dual data rate)
You can also reset the partition configuration using
Colibri iMX7 # mmc partconf 0 1 1 0
- boot_ack: 1
- boot_partition: 1 (Boot partition 1), 7 (User area)
- partition_access: No access to boot partition (default)
Thank you very much. The SoC fuses were still correct, it was the bootbus configuration that was causing the problems.