IMX6 eMMC boot

[andrewparlane]

Hi all,

So I'm trying to get our custom board with an IMX6 to boot u-boot from eMMC.

Here's what I've done:

1) use boundary devices imx_usb to load u-boot in using the serial downloader mode.

2) boot linux from sdcard on sd3

3) cd cd /sys/bus/mmc/devices/mmc1\:0001/     (sd4, emmc)

4) cat boot_info

1) desired SD clock: 52000000, actual: 49500000

1) desired SD clock: 52000000, actual: 49500000

mmc1: BKOPS_EN bit is not set

boot_info:0x07;

  ALT_BOOT_MODE:1 - Supports alternate boot method

  DDR_BOOT_MODE:1 - Supports alternate dual data rate during boot

  HS_BOOTMODE:1 - Supports high speed timing during boot

boot_size:4096KB

boot_partition:0x49;

  BOOT_ACK:1 - Boot acknowledge sent during boot operation

  BOOT_PARTITION-ENABLE: 1 - Boot partition 1 enabled

boot_bus:0x00

  BOOT_MODE:0 - Use single data rate + backward compatible timings in boot operation

  RESET_BOOT_BUS_WIDTH:0 - Reset bus width to x1, single data rate and backwardcompatible timings after boot operation

  BOOT_BUS_WIDTH:0 - x1 (sdr) or x4 (ddr) bus width in boot operation mode

5) write u-boot.imx (same one serial downloader used) to emmc using:

dd if=/sdcard/u-boot.imx bs=1k seek=1 conv=fsync of=/dev/mmcblk1

I have 4 mmcblk1 devices:

   mmcblk1

   mmcblk1boot0

   mmcblk1boot1

   mmcblk1rpmb

I assume writting to the mmcblk1 entry is correct?

6) reboot and verify image:

dd if=/dev/mmcblk1 bs=1k skip=1 count=211 of=/tmp/uboot.tmp

diff -s /sdcard/u-boot.imx /tmp/uboot.tmp

7) reboot and set fuses in u-boot:

fuse prog 0 5 00005862

fuse prog 0 6 00000010

That sets: BOOT_CFG1 to 0x62

BOOT_CFG2 to 0x58

and BT_FUSE_SEL to 1

8) set dipswitches so boot_mode gpios = 00

9) power on, nothing happens. try using imx_usb serial downloader app thingy, and it works. So something is failing.

We scoped the clk pin on the eMMC and it appeared to wiggle.

Some final points.

We are using a 16GB eMMC v4.41 chip, with an 8 bit bus. No vselect. On the default pins for SD4. We have a reset pin, on NANDF_ALE.

I have the line: "BOOT_FROM sd" in my u-boot board.cfg file, which I think sets the offset to 0x400.

Have I missed anything?

Thanks,

Andy

[leoschwab]

We also have a custom board that is successfully booting from eMMC.

First, ensure your boot switches are correctly set to boot from eMMC.  How this is done is specific to your board and how you've wired up the BOOT_CFG pins.

Next, you said your kernel was reporting the eMMC being setup as follows:

Andrew Parlane wrote:

boot_partition:0x49;

  BOOT_ACK:1 - Boot acknowledge sent during boot operation

  BOOT_PARTITION-ENABLE: 1 - Boot partition 1 enabled

This means the eMMC will be exposing the "boot" regions (which are distinct from the main "user area"), and the boot ROM will load U-Boot from there.  So that's where you need to copy U-Boot:

# Enable writes to /dev/mmcblk1boot0

echo 0 > /sys/block/mmcblk1boot0/force_ro

# Precaution: Erase entire eMMC boot region.

dd if=/dev/zero of=/dev/mmcblk1boot0

# Copy U-Boot to eMMC boot region.

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

Then power-cycle the board.  U-Boot should load immediately.  The U-Boot binary image you successfully loaded and ran via the USB serial downloader should work for this purpose.

Once you have U-Boot successfully loading and running, check that U-Boot can see and read from the eMMC using U-Boot's 'mmc' and 'fatls' or 'ext2ls' commands.  If not, you have more work to do :-).

[andrewparlane]

OK, so I noticed last night my board had stopped working with the serial downloader when my boot_mode gpio lines were set to fuse boot.

Erasing /dev/mmcblk0boot1 and /dev/mmcblk0 (blk0 because my sdcard isn't in ATM). Still causes the same behavior, but erasing /dev/mmcblk0boot0 makes it work again with boot_mode = fuse boot.

So this tells me that I had firmware in the right place, and it validated, but the image refused to run correctly and crashes before any output comes out.

Erasing mmcblk0boot0 and putting my latest u-boot fw in there (exactly the same file I pass to imx_usb for the serial downloader). With the commands (i erased it earlier).

echo 0 > /sys/block/mmcblk0boot0/force_ro

dd if=/usr/local/fw/u-boot.imx of=/dev/mmcblk0boot0 bs=512 seek=2

sync

Then I power cycle, and it fails to boot, and the serial downloader still works :\

I dump mmcblk0boot0 using dd if=/dev/mmcblk0boot0 of=/tmp/u-boot.tmp and diff with the original binary. Other than  0x400 bytes of 00s at the beginning and a tonne of 00s at the end, the dump is as expected. With the IVT located at 0x400 (same as described in one of my other comments).

So not sure what's going on now, I thought I was making progress when the serial downloader stopped working.

[Ahmet_Cihan_AKINCA]

Hi. I have the same problem with imx7d. did you solve this problem?

I'm running on SD Card without any problem but can not run with eMMC. u-boot.imx or u-boot.bin give same result. boot_cfg pins seem correct. I tried mmcblkX or mmcblkXboot0. Why is eMMC boot not working?

[igorpadykov]

Hi Andrew

you can just reproduce boot settings for SPF-27392 (also pins on SD4)

MCIMX6DL-SDP p.5 for eMMC i.MX6_SABRE_SDP_DESIGNFILES

Programming is performed with MFG Tool IMX_6DL_6S_MFG_TOOL

steps are described in i.MX_6Solo6DualLite_SABRE-SDP_Linux_User's_Guide.pdf

L3.0.35_4.1.0_LINUX_DOCS

attached ucl2.xml profile "SabreSD-eMMC-uboot-kernel" shows commands

which uses MFG Tool for eMMC programming.

Best regards

igor

[andrewparlane]

Hi Igor,

Thanks for your reply.

I looked through that docs and the schematic. It states required dipswitches, which maps to gpio pull ups, which maps to setting bits in the BOOT_CFG 1 and 2 regs. They agree with what I'm setting.

Looking at the ucl2.xml you attached (thanks), how do I tell which <LIST> section I want to look at. The "Choose eMMC android as media" looks promising.

This runs the following commands:

dd if=/dev/zero of=/dev/mmcblk0 bs=512 seek=1536 count=16

echo 0 > /sys/block/mmcblk0boot0/force_ro

dd if=$FILE of=/dev/mmcblk0boot0 bs=512 seek=2 skip=2

echo 1 > /sys/block/mmcblk0boot0/force_ro

echo 8 > /sys/devices/platform/sdhci-esdhc-imx.3/mmc_host/mmc0/mmc0:0001/boot_config

This looks promissing.

I haven't run the first line. The actual writing the image writes to boot0 which is good to know, and it also skip=2 which I wasn't doing. This skips the first 1K of input data. Which if I'm correct is meant to contain the IVT?

The rest I think I've got done.

I've tried these new commands and still nothing. Unfortunately it could be anything from my image is in the wrong place, to I need to add a config option to u-boot to my fuses are wrong. It makes it quite hard to figure out where it's going wrong.

[igorpadykov]

Hi Andrew

seems for yocto correct

sudo dd if=u-boot.imx of=/dev/sbX bs=512 seek=2; sync

as suggested in

How to burn Uboot Linux on SD Card?

[andrewparlane]

Hi Igor,

I tried that command using mmcblk0, mmcblk0boot0 and mmcblk0boot1 with both the .imx and .bin files and it still doesn't work. I'm going to try and validate my IVT and see if I can spot the problem that way.

[MT]

Hi Andy

You need to use u-boot.bin, not u-boot.imx in the

dd if=/sdcard/u-boot.imx bs=1k seek=1 conv=fsync of=/dev/mmcblk1

You are missing the IVT table in your MMC image, see this post for the differences between .bin and .imx

u-boot.bin and u-boot.imx

BR

Mark

[andrewparlane]

I've been looking through my .imx and .bin files and found that the IVT is actually in the .imx and not in the .bin.

Here is the first 48 bytes of .imx file:

d1 00 20 40 00 00 80 17 00 00 00 00 30 fc 7f 17

24 fc 7f 17 04 fc 7f 17 00 00 00 00 00 00 00 00

f5 fb 7f 17 00 60 03 00 00 00 00 00 d2 03 18 40 

So first 4 bytes are header and version:

d1 - tag (correct)

00 20 - length in big endian = 32 bytes as required

40 - version (supported = 40 or 41)

Next 4 bytes are entry address

00 00 80 17 - 0x17800000 as set in u-boot using CONFIG_SYS_TEXT_BASE. Copied from the nitrogen6lite config

Next we have 4 bytes reserved set to 0s

Next DCD address

30 fc 7f 17 - 0x177ffc30

Then bood data address

24 fc 7f 17 - 0x177ffc24

Then self, address of IVT

04 fc 7f 17 - 0x177ffc04

csf addrss

00 00 00 00 - not secure boot

reseverd

0s as required

So since the IVT is at 177ffc04 and is 32 bytes long. The boot data is right after at address ...177ffc24.

This consists of 12 bytes

f5 fb 7f 17 - 177ffbf5 - absolute address of image. Where does this come from?

00 60 03 00 - size of image = 0x36000 ~= 213KB which matches the size of my .imx

00 00 00 00 - plugin, 0 as expected

Then there is the device config data, the header is

d2 - tag as required

03 18 - size

40 - version, the TRM says: "Version: A single byte field set to 0x41" does this mean my DCD is not supported? Or is it just a typo in the TRM.

So my questions are:

1) I assume I need to use the .imx then since this contains the IVT

2) What does the "absolute address of image" in the boot data section refer to?

3) Does the version being 0x40 in the DCD cause a problem?

4) Is 0x1780_0000 a reasonable value for CONFIG_SYS_TEXT_BASE?

5) Which eMMC partition does it try and read the image from? boot0 boot1 or the start of the main eMMC (mmcblk0). I've seen various answers to this.

Thanks,

Andy

[andrewparlane]

Hi Mark,

Unfortunately that didn't help.

I wrote my u-boot.bin to /dev/mmcblk1, /dev/mmcblk1boot0 and /dev/mmcblk1boot1

Can you confirm which it should be?

For reference I'm using Boundary Devices uboot, from commit: 4dfca8881f318f0d346b575ffbe93aa12755c4e9, working on trying to figure out which branch.

Kernel is also from Boundary Devices linux-imx6, 3.10.17-ga branch.

[igorpadykov]

Hi Andrew

Boundary Devices use different methods for eMMC programming, so

I would suggest to join the mailing list below so more people can help you

and post on Boundary Devices forum.

https://lists.yoctoproject.org/listinfo/meta-freescale

http://boundarydevices.com/community/

Best regards

igor

[andrewparlane]

Thanks, I'll get in touch with them.

[igorpadykov]

Hi Andrew

yes, skipping the first 1K is for providing correct IVT offset (1K for SD boot).

Actually you can check image with hex editor : if it already has this offset or not.

Also after boot failure, one can connect the OTG on the board to the PC, if a new HID

device can be found,  the ROM code entered serial download mode which mean

some error occurred in the booting process. One can also check with MFG Tool,

if it sees i.MX6 device.

Then attach the board with any JTAG debugger, such as RV-ICE or

Lauterbach and dump 0x907400 (ROM uses 0x907000 as starting address),

you should see your IVT header here if the SD access is ok.

Best regards

igor

[andrewparlane]

Hi Igor,

Let me see if I understand this correctly:

building u-boot causes the IVT to be generated it is pre-pended to the .imx file and the result is the .bin? My .imx file is 213KB and my .bin is 209KB. This suggests that either Boundary's u-boot is not doing the same thing, or the .imx -> .bin is stripping stuff out.

Then we write the resulting image to eMMC, containing the IVT and the binary. The IVT goes at address 0x400, the u-boot binary at 0x800.

After a boot failure, the  serial downloader is active, and I can use the boundary imx_usb tool to load in u-boot. So it has reverted to serial downloader mode, showing there is an error.

Andy