i.MX6Q Failure To Boot From eMMC on Custom Board

[cbrust]

We have a custom board based largely upon the i.MX6Q SabreAI reference design with the addition of eMMC (like SabreSD).  We've configured and built a custom U-Boot and Linux using the Yocto FSL Community BSP v3.14.28 release.  During our development, u-boot has been successfully loaded and executed manually with the DTB, Linux kernel and RootFS on a TFTP server.  Everything boots up and runs flawlessly this way so we know that our U-Boot and Linux are good.  The problem is that we cannot get U-Boot to start when it is loaded into the eMMC on our custom board. 

We've verified required settings (provided below) but U-Boot does not start upon power on (or reset) and after about 30 seconds the i.MX6Q reverts to serial download mode as expected upon a boot failure. I've also attempted to use the MFGTool but again without success. Since we have a booting/running Linux via TFTP we have placed U-Boot manually into eMMC. The details of this are below.  We've been successful placing and executing U-Boot/Linux with this same process on the SabreSD eMMC.   To Linux, our eMMC devices appear as /dev/mmcblk2, /dev/mmcblk2boot0, etc. This process has been verified as successful in placing u-boot into the boot 0 partition.

---------------------------------------

Here's our procedure to load U-Boot from Linux.

-- Enable read/write for boot region

     $ echo 0 > /sys/block/mmcblk2boot0/force_ro

-- Zero out the boot region as a precaution

     $ dd if=/dev/zero of=/dev/mmcblk2boot0

     $ sync

-- Copy U-Boot onto the boot partition

     $ dd if=u-boot.imx of=/dev/mmcblk2boot0 bs=512 seek=2

     $ sync

-- Make it "bootable"

     $ echo 8 > /sys/devices/platform/.../mmc2/mmc2:0001/boot_config

--------------------------------------

Here are the details of the custom board registers after U-Boot comes up for reference.

After power on, the SRC_SBMR# registers have the following values shown & I've decoded the most relevant values.

SRC_SBMR1 = 0x0000 D062 (b 00000000 00000000 11010000 01100010)

SRC_SBMR2 = 0x2A00 0001 (b 00101010 00000000 00000000 00000001)

These  registers indicate:

BMOD[1:0] = 10             <- Internal Boot

BT_SEL_FUSE = 0         <- Bits of SBMR are overridden by GPIO pins

DIR_BT_DIS = 0             <- Direct Boot from External Memory is Allowed

SEC_CONFIG[1] = 01     <- Open - allows any code to be flashed/executed

BOOT_CFG1[7:5] = 011 <- Boot from eMMC

BOOT_CFG1[4] = 0        <- Regular Boot (not Fast Boot)

BOOT_CFG1[3] = 0        <- SD/MMC Speed = High (not Normal)

BOOT_CFG1[2:0] = 010 <- These bits are reserved

BOOT_CFG2[7:5] = 110 <- 8-bit DDR (MMC 4.4)

BOOT_CFG2[4:3] = 10   <- uSDHC3 port selected

BOOT_CFG2[2] = 0        <- Boot ROM default (DLL override)

BOOT_CFG2[1] = 0        <- Boot Ack Enabled (Fast Boot Acknowledge Disable)

------------------------------------

At this point we believe have verified all settings as correct and cannot explain why U-Boot will not start from eMMC.  Based upon the above settings, the i.MX6Q is apparently trying to boot from eMMC but failing. We can tell this because serial download mode appears after about 30 seconds have elapsed. Interesting to note is that if U-Boot is loaded and executed via another means, we can actually boot and run Linux out of the custom board eMMC.  Only U-Boot is unable to start.

One, possibly important difference is that our custom board uses a Samsung 64GB eMMC version 5.0 chip (supposed to be backward compatible to v 4.4).  I do not think this is an issue but I add it here in case it is relevant.

Any insight on where to look or what to try would be greatly appreciated as we are at a standstill on this issue.  Maybe there's an alternative to placing U-Boot in the boot0 partition if this cannot be made to work?

Thanks in advance.

Cliff

[cbrust]

Thanks Jimmy,  I was already aware of the reference you posted and our U-Boot has the patch needed as that is a part of v3.14.28 Linux we are using.   As I stated previously, our Samsung eMMC v5.0 works perfect in every respect except one.  That is, U-Boot will not start out of eMMC.  Please look at the other point that I made in my prior post regarding BOOT_CFG1[1] being set to 1.  Could that be an issue?

[cbrust · Accepted solution]

This problem has been resolved.  The final solution was the removal of 2 pull-ups on our board corresponding to BOOT_CFG1 & BOOT_CFG2.

Here are the details of the changes.

----------------------------

1) BOOT_CFG1[2:0] = "010" (was changed to "000"

     ----Changing this BOOTCFG1 by itself did not allow u-boot to start.

2) BOOT_CFG2[7:5] = "110" was changed to "010"

     ----This changed from "8 bit DDR (MMC4.4)" to "8 bit" and then u-boot started upon reset/power on.

--------------------------

Basically, we had to match exactly the settings of the SabreSD board in order to get u-boot to start with eMMC v5.0.  Funny thing about this is that this does not match our default eMMC configuration.....

[cbrust]

Found some additional info on BOOT_CFG1 bits that are marked reserved.  It appears that they do have function for eMMC as detailed under SDHC interface (fuse addresses).  The bit of interest mentioned in the last post is BOOT_CFG1[1] = 1.   On the SabreSD this bit is "0" for both the eMMC and SD Card.  This bit when set to "1" is a "reset enable" and causes a reset of the eMMC to occur with a 5ms delay for the stated purpose of changing voltage (1.8v to 3.3v and vice versa I assume).  Could this reset or the incurred delay be the cause of boot failure?   Like I said, the SabreSD board sets this bit to "0" which means disable the reset.

[jimmychan]

For your reference, i.mx6 with eMMC 5.0 SDR or DDR interface?

[jimmychan]

1. when you using the MFGtool, is there any error occur?

2. when you loading the u-boot to EMMC manually, your steps and the path are little bit different from the mfgtool's script. I place the part of script here for your reference.

    (where %mmc% is equal to 2 for your case)

    <CMD state="Updater" type="push" body="$ dd if=/dev/zero of=/dev/mmcblk%mmc% bs=1k seek=384 conv=fsync count=129">clear u-boot arg</CMD>

    <!-- access boot partition -->

    <CMD state="Updater" type="push" body="$ echo 0 > /sys/block/mmcblk%mmc%boot0/force_ro">access boot partition 1</CMD>

    <CMD state="Updater" type="push" body="send" file="files/u-boot.imx" >Sending u-boot.bin</CMD>

    <CMD state="Updater" type="push" body="$ dd if=$FILE of=/dev/mmcblk%mmc%boot0 bs=512 seek=2">write U-Boot to emmc</CMD>

    <CMD state="Updater" type="push" body="$ echo 1 > /sys/block/mmcblk%mmc%boot0/force_ro"> re-enable read-only access </CMD>

    <CMD state="Updater" type="push" body="$ echo 8 > /sys/block/mmcblk%mmc%/device/boot_config">enable boot partition 1 to boot</CMD>

In the last two commands, please try to re-enable the read-only access and enable the boot partition. "each 8" to /sys/block/mmcblk2/device/boot_config.

[cbrust]

Hello Jimmy,

Thanks for the fast response.  Here's the answer to your question/directions.

1. The last thing the MFGTool shows is "Loading UBoot" on the screen and then hangs forever.  There is no error in the logfile.  This was the primary reason for loading UBoot via JTAG and running from there.  This method has been very successful and allows us to run Linux out of the eMMC.  We just cannot get UBoot to start at Power on or Reset.

2. I retried flashing UBoot with the steps you provided from the MFGTool. (That is also where I got my steps although I altered them from the original in trying to get things working.) The steps you gave me apparently succeed as you can see in the log below, but after completing the steps, UBoot still fails to start from eMMC.  Here are the steps.

---------------------------------------------------------

root@imx6q:~# dd if=/dev/zero of=/dev/mmcblk2 bs=1k seek=384 conv=fsync count=129

129+0 records in

129+0 records out

root@imx6q:~# echo 0 > /sys/block/mmcblk2boot0/force_ro

root@imx6q:~# dd if=u-boot.imx of=/dev/mmcblk2boot0 bs=512 seek=2

998+0 records in

998+0 records out

root@imx6q:~# echo 1 > /sys/block/mmcblk2boot0/force_ro

root@imx6q:~# echo 8 > /sys/block/mmcblk2/device/boot_config

root@imx6q:~#

---------------------------------------------------------

There has to be another issue preventing UBoot from starting. 

Is there anything that could cause an invalid boot mode to occur from eMMC when everything is correctly flashed and configured?  

There are only 2 things that we see that are not "normal" in our design.

1.  We have a hardwired "1" in a reserved bit of BOOT_CFG1[2:0] = "010".  This bit appears to be used by the SD Card boot mode and is set this way intentionally.  Could this interfere with eMMC booting?

2.  Samsung eMMC 5.0 is not fully backward compatible with eMMC 4.4.   Does anyone have experience with eMMC 5.0 compatibility?

Please provide any thoughts/questions/suggestions you may have.

We have to get this going.

Thanks,

Cliff