AnsweredAssumed Answered

Trouble booting from eMMC while updating i.mx6ul board from 2015 uboot.imx to 2017 SPL+uboot.img

Question asked by Robert Cagle on Apr 22, 2019
Latest reply on Apr 23, 2019 by igorpadykov

I am trying to update a custom imx6ul board from the NXP bsp u-boot
to the Community bsp u-boot.  The custom board boots from emmc okay using a 2015
NXP u-boot.imx image, but fails to boot from emmc with a 2017.11 or 2019.4 fslc
spl image. However, I am able to run the spl image if I manually load
it using usb-sdp or jtag.


I've tried:


a) checking imx_usb_loader scripts to make sure installation was done correctly.
    dd if=/dev/zero of=/dev/mmcblk1 bs=1k seek=512 conv=fsync count=8
    echo 0 > /sys/block/mmcblk1boot0/force_ro
    dd if=SPL of=/dev/mmcblk1boot0 bs=512 seek=2
    dd if=u-boot.img of=/dev/mmcblk1boot0 bs=512 seek=138
    echo 1 > /sys/block/mmcblk1boot0/force_ro
    mmc bootpart enable 1 1 /dev/mmcblk1

    # My emmc has an 8g user area and two 16MiB boot partitions.
    # I've tried zeroing them all out and applying SPL to one
    # at a time to verify I am programming/using the correct area
    # of flash. Everything appears ok, and I am able to boot my
    # 2015 version of u-boot from emmc using the same steps.


b) checking the extcsd info on the emmc to make sure boot
   partition is enabled. Also played around with Boot bus conditions
   but wound up leaving them at 0x0.
    Boot configuration bytes [PARTITION_CONFIG: 0x48]
     Boot Partition 1 enabled                                             
     No access to boot partition             


    Boot bus Conditions [BOOT_BUS_CONDITIONS: 0x00]         


    # I've tried all combinations I could find, none worked better,
    # many worked worse.


c) after POR, checking smbr1/sbmr2 (they look mostly ok)

            [cfg4: 10 - ECSPIx_SS1 - pulled high by mistake,
                             shouldn't hurt?]
            [cfg3: 00 - reserved]
            [cfg2: 48 - 8-bit, eSDHC2, 0-500/400mhz, 3.3v]
            [cfg1: 60 - emmc, regular-boot, high-speed,
                    no-sd-power-cyc, thru-sd]


    sbmr2=02000041    [bmod=internal, 4=??, sec_config=open]


d) after POR, checking whether ivt got loaded in ocram (it did).
        J-Link>mem32 907400,c
        00907400 = 402000D1 00908000 00000000 00000000
        00907410 = 00907420 00907400 00000000 00000000
        00907420 = 00907000 0000D000 00000000 400400D2


e) checked SPL ivt header for correctness
   (script from


    $ python3 SPL
    =================IVT data===================
    =================DCD data===================
    No DCD data in table


f) after POR, checking whether code got loaded into ocram (usually not!)
    Why is ivt okay but this never loaded or overwritten?
    J-Link>mem32 908000,8
    00908000 = 5880BCE7 9EB3322F E4B82B75 BCA61DFB
    00908010 = D81D695D 59B3F13D 483D24F5 21F92F47


    when loading from usb-sdp this contains correct spl code, and it
    stays there all the way thru the main u-boot prompt. why different?
    J-Link>mem32 908000,8
    00908000 = EA00000F E59FF014 E59FF014 E59FF014
    00908010 = E59FF014 E59FF014 E59FF014 E59FF014


Any other ideas on how to debug this? It seems like (f) is a big clue, but
I don't know where to go with it. Hopefully something simple!