Hi all,
I am trying to boot u-boot from an SD card on an i.MX6 custom board and am having some difficulties.
I have used a JTAG emulator to load u-boot into DDR manually and run it. So I've ironed out DDR timing issues and basic board operation. I have validated u-boot runs and successfully gets to the command prompt. From there I have validated the MMC device is accessible and I can load the kernel binary into memory from the SD card. So I know the interface is working properly, but I cannot seem to boot from the SD card.
I have also validated with an oscilloscope that, on power up, clocks are going to the SD card.
From my reading I believe that the u-boot.imx image should be placed at offset 1024 on the SD card
Linux on the i.MX6 sabre sd platform in a few commands
u-boot on the i.MX6 sabre sd platform in a few commands)
I have tried various ways to program the binary to the SD card, but have been unsuccessful in booting the board from SD:
$ sudo dd if=u-boot.imx of=/dev/sdb bs=1k seek=1
$ sudo dd if=u-boot.imx of=/dev/sdb bs=512 seek=2
So I have a few questions:
1. What address does the i.MX6 boot ROM read from on power-up when it's looking for the DCD table in the u-boot.imx image?
2. What data is the boot ROM looking for?
3. How do I troubleshoot this further?
In case of relevance, my i.MX6 chip is: MCIMX6Q6AVT10AD SBFV1535 5N55D KOREA D1FVSBF
Thanks.
解決済! 解決策の投稿を見る。
We discovered the issue by comparing the boot configuration from our custom board to the SabreSD board. The problem was a resistor was mistakenly populated on BOOT_CFG1_3 to pull the line high. This put the SD interface in SDR50 mode instead of normal/high speed mode. The resulting behavior was clocks would go to the uSDHC1 interface, but the data would not be copied into OCRAM. Removing the resistor resolved the issue.
We discovered the issue by comparing the boot configuration from our custom board to the SabreSD board. The problem was a resistor was mistakenly populated on BOOT_CFG1_3 to pull the line high. This put the SD interface in SDR50 mode instead of normal/high speed mode. The resulting behavior was clocks would go to the uSDHC1 interface, but the data would not be copied into OCRAM. Removing the resistor resolved the issue.
Hi,
If all other things that you already verified are working properly, it seems that the i.MX is missing the boot configuration (ROM code). Are the boot fuses burned out to boot from the SD? Or if the fuses are not burner, are the boot switches (GPIOs) properly configured to boot from the correct SD module?
Additionally, you could take a look at the following thread (verify that proper u-boot.bin file was used):
Hope this will be useful for you.
Best regards!
/Carlos
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Carlos,
The boot fuses are not burned currently as this is a Rev A development board. The boot configuration is using the eFuse method (GPIOs). Those are properly configured for SD based on Chapter 8.5.3.1 in the i.MX6Q RM to: 0100 (BOOT_CFG1[7:4]).
I read through that thread and there appears to be some confusion between the u-boot.bin and u-boot.imx files. The u-boot.imx file is the u-boot.bin file WITH the IVT prepended. But it also doesn't appear the OPs issue was resolved.
So, yes, the u-boot file I am programming to my SD card is the u-boot.imx file. I have validated that the .imx file contains the IVT header information beginning at 0x0 and stretching to the beginning of u-boot (which starts at 0xC000). I have also copied the data out of this file manually and compared to the board config files (u-boot-2014.07/board/boundary/nitrogen6x/ddr-setup.cfg, 1066mhz_4x256mx16.cfg, clocks.cfg, etc) that the DCD table is based on to make sure that the data in the IVT header is correct. All that looks good.
Hi,
So, if the u-boot is running (loaded from SD) it means that the boot configuration is properly set, and the u-boot was stored on the proper locations of the SD (as you already mentioned with the memory dump). Therefore, other possibilities to fail the boot after this could be:
Hope this will be useful for you.
Best regards!
/Carlos
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
I have validated my boot cfg bits through the schematics are set to 0x0800_E048 which properly selects the uSDHC1 interface for booting. I was attempting to validate this with my emulator, but am unsure of the address the boot cfg bits are stored in on the i.MX6. Where can I find this register?
If I use my JTAG emulator to boot u-boot I can access the SD card and have validated my u-boot.imx image exists in the 2nd block of memory on the card:
U-Boot > mmc read 0x10000000 2 1
MMC read: dev # 0, block # 2, count 1 ... 1 blocks read: OK
U-Boot > md.b 0x10000000
10000000: d1 00 20 40 00 00 80 17 00 00 00 00 2c f4 7f 17 .. @........,...
10000010: 20 f4 7f 17 00 f4 7f 17 00 00 00 00 00 00 00 00 ...............
10000020: 00 f0 7f 17 00 e0 05 00 00 00 00 00 d2 01 90 40 ...............@
10000030: cc 01 8c 04 02 1b 00 18 00 08 17 40 02 1b 00 04 ...........@....
According to fdisk in Linux, the block size for the disk is 512. Which means that my u-boot.imx image is properly located at a 1024 byte offset.
So the SD card is programmed properly (according to documentation), the interface is accessible, the boot configuration bits appear to be correct... What else could be wrong?