IMX6U7 not booting after flashing rootfs.sdcard.gz and u-boot.imx images

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IMX6U7 not booting after flashing rootfs.sdcard.gz and u-boot.imx images

1,347 Views
AnkitVaghasiya
Contributor I

Hello,

We are having MCIMX6U7CVM08AD in our custom board and we are using yocto for creating u-boot.imx and dual-rootfs.sdcard.gz file to prepare the builds. After changing the flashing approach our boards are not booting at all and imx_usb is not helping us to boot atleast u-boot prompt. Below are the 2 approaches:

until now we were using the below method to flash/reflash the board and there were no issues:
1. Change the jumper to put i.MX into recovery mode
2. Use ./imx_usb to load the u-boot image into the RAM
3. run ums server in u-boot console by 'ums 0 mmc 0' to export block device to host system (here, mmc 0 is sandisk eMMC SDINBDG4-8G-XI1)
4. run command 'zcat core-image-base-mainboard-sbs-20200716174512-dual.rootfs.sdcard.gz | sudo dd of=/dev/sdx bs=1M conv=fsync' from host system to flash Linux Kernel with boot,2 rootfs and userdata partition in the eMMC
5. finally run command 'dd if=u-boot.imx of=/dev/sdx bs=512 seek=2 conv=fsync' from host system to flash u-boot image the eMMC

Since the above method was taking 45 min to flash ~7.1GB of extracted sdcard image, we have changed the flashing approach as below:
1. Prepare SDcard with ext4 filesystem partition and copy dual.rootfs.sdcard.gz and u-boot.imx in to the SDCard (not making it bootable but just copying required files) and insert in SDcard slot
2. Change the jumper to put i.MX into recovery mode
3. Use ./imx_usb from host system to load the u-boot image in to the RAM
4. By now, we have 2 eMMC device detected in u-boot
     => mmc list
     FSL_SDHC: 0 (eMMC)
     FSL_SDHC: 1 (SD)
5. copy the sdcard.gz in to the RAM by 'mmc dev 1; load mmc 1:1 10008000 core-image-base-mainboard-sbs-20200716174512-dual.rootfs.sdcard.gz'
     => 492423925 bytes read in 23581 ms (19.9 MiB/s)
6. Write sdcard.gz from RAM to eMMC by 'mmc dev 0; gzwrite mmc 0 10008000 0x1D59CAF5 100000 0'
     => 7602176000/3307208704
     uncompressed 7602176000 of 3307208704
     crcs == 0x7e092288/0x7e092288
7. copy the u-boot.imx in to the RAM by 'mmc dev 1; load mmc 1:1 30008000 u-boot.imx'
     => 429056 bytes read in 46 ms (8.9 MiB/s)
8. Write u-boot.imx from RAM to eMMC by 'mmc dev 0; mmc write 30008000 2 346' (i.e. 429056 size of u-boot.imx / 512 = 1506 = 0x346)
     => MMC write: dev # 0, block # 2, count 838 ... 838 blocks written: OK
9. Run 'ums 0 mmc 0' to validate all newly create partitions are exported with data
10. Run 'hexdump -C /dev/sdx' to validate the u-boot.imx image starting from 0x400 address.
11. Power reset the board and change the jump back to the initial position.
12. Board is not booting and getting below prints on console:
     U-Boot 2016.03 (Jul 16 2020 - 23:00:31 +0530)

     CPU: Freescale i.MX6DL rev1.3 at 792 MHz
     Reset cause: POR
     Board: SBS
     I2C: ready
     DRAM: 1 GiB
     MMC: FSL_SDHC: 0
     timeout irqstat=10000
     timeout irqstat=10000
������������������������������������������������

since its not booting we have tried puting it to the recovery mode and boot using imx_usb but that is not helping us to recover the state of board.

we need your help to identify and resolve the above issue. we have corrupted such 2 boards with same steps.

0 Kudos
2 Replies

1,302 Views
igorpadykov
NXP Employee
NXP Employee

Hi Ankit

 

had board passed ddr test and uboot dcd header was updated with new ddr calibration

coefficients found from ddr test:

https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-6-7-DDR-Stress-Test-Tool/ta-p/11082...

https://source.codeaurora.org/external/imx/uboot-imx/tree/board/freescale/mx6sabresd/mx6dlsabresd.cf...

 

Best regards
igor

0 Kudos

1,293 Views
Ankit_Vaghasiya
Contributor I

Hello,

We haven't doubted the ddr since the issue happened on 2 board by just following the same steps.

Inverting the order for USDHC4 (eMMC) and USDHC2 (SD) in board_mmc_init() of u-boot resolved our issue. Actually fsl_esdhc_initialize() was getting stuck somewhere with the earlier sequence.

Thanks,

0 Kudos