i.MX 8M Mini eMMC Boot Fusing

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

i.MX 8M Mini eMMC Boot Fusing

6,324 Views
marcelziswiler
Senior Contributor I

Trying to get eMMC booting going on an i.MX 8M Mini based design I stumbled over several shortcomings of the current reference manual (IMX8MMRM Rev. 2, 08/2019) which require clarifying:

Table 6-3. GPIO override contact assignments

=> By contact you probably mean pin, right?

6.1.4.7 Persistent bits

Table 6-8. Persistent bits

=> Table talks about SRC_GPR10 bits 29 and 30 but 6.5.5.26 SRC General Purpose Register 10 (SRC_GPR10) shows everything as reserved.

Table 6-19. USDHC boot eFUSE descriptions

=> That table seems to be rather messed up:

Shipped value of 000 for single bit BOOT_CFG[7].

Missing settings for Bus width BOOT_CFG[6:4].

Rows 7 and 8 are completely messed up:

MMC Speed Mode (CFG[3:2])

USDHC1 IO Voltage Selection (CFG[1])

=> Fuse column talks about BOOT_CFG vs. 0x490 and 0x4A0 but unclear what exact fuses that now is.

=> Order of rows (e.g. starts with bit 7 down to bit 0 and then bit 15 down to 8) is very confusing.

6.1.5.4.2 MMC and eMMC boot

eMMC4.3 or eMMC4.4 device supporting special boot mode

The BOOT ACK is selected by the .

=> I guess there is something crucial missing before that dot.

eMMC4.4 device

This mode can be selected by the BOOT_CFG2[7:5] (bus width) fuse.

=> Can't find any further mentioning of that BOOT_CFG2[7:5] anywhere.

6.1.5.4.4 IOMUX configuration for SD/MMC

Table 6-22. SD/MMC IOMUX pin configuration

=> Is it really true that for USDHC1 and USDHC2 DATA4 to DATA7 are not using their native SD1 resp. SD2 pins but rather some weird ECSPI1 resp. ECSPI2 alt2 ones? Anyway, so far, trying 4-bit only mode also does not seem to work.

6.1.5.4.5 Redundant boot support for expansion device

=> It's not quite clear whether or not this section also applies to eMMC and more specifically its fast boot mode as well. E.g. do the same image offsets apply or are they different when putting stuff into the eMMC hardware boot area partitions?

6.2.1 Boot Fusemap

=> Confusing use of BOOT_CFG vs. 0x470.  I assume they mean the same thing.

Table 6-43. MMC/eMMC Boot Fusemap

=> Doe the "Power Cycle Enable" and/or "SD Loopback Clock Source SEL" settings actually really matter at all if booting from eMMC?

=> Row 0x470[7:0] mentions "Reserved for HS200". Is HS200 actually supported for eMMC booting at all?

6.3.2.2 Fuse Shadow Memory Footprint

=> That graphic show 5 BOOT_CFGs, however, it is not quite clear what exactly is meant by those.

6.3.4 OCOTP Memory Map/Register Definition

OCOTP memory map

=> At least here there is the first concrete mentioning if OTP banks and words but what exactly they map to now is still not quite clear e.g.

Value of OTP Bank1 Word3 (Boot Configuration Info.) (OCOTP_HW_OCOTP_BOOT_CFG0)

Value of OTP Bank2 Word0 (Boot Configuration Info.) (OCOTP_HW_OCOTP_BOOT_CFG1)

Value of OTP Bank2 Word1 (Boot Configuration Info.) (OCOTP_HW_OCOTP_BOOT_CFG2)

Value of OTP Bank2 Word2 (Boot Configuration Info.) (OCOTP_HW_OCOTP_BOOT_CFG3)

Value of OTP Bank2 Word3 (BOOT Configuration Info.) (OCOTP_HW_OCOTP_BOOT_CFG4)

Could you please clarify the above items or at least give us a clear understanding of how exactly e.g. the imx8mm_evk could be fused to boot from its eMMC?

Anyway, our current fusing looks as follows but that does not quite seem to work as of yet:

fuse prog 1 3 0x100020d6 (BT_FUSE_SEL, eMMC boot, SD1, fast boot, 4-bit DDR, high speed, 1.8V)
fuse prog 2 2 0x00000001 (enable boot ack)

And the matching eMMC configuration:

mmc bootbus 0 1 0 2 (4-bit, reset bus width, DDR)
mmc partconf 0 1 1 0 (booting from boot area partition 1, send acknowledge)

BTW: That imx8mm_evk does not seem to connect the eMMC's reset aka RST# signal. Is that really recommended and has no adverse effect even considering eMMC fast boot spec actually requiring it?

Thanks!

Labels (1)
0 Kudos
10 Replies

2,348 Views
frix
Contributor II

Good day,

Have you managed to solve your e-Fuse boot problem?

I'm successfully using the Super Root Key to boot a signed u-boot. I'm trying to lock down the boot sequence to only use the eMMC. There's also a fallback to SD if the DISABLE_SDMMC_MFG bit is left at 0.

Before setting the fuses I've used the development kits external boot select switches to successfully boot from SD and eMMC.

The iMX 8M Mini application processor reference manual was used to look up the
meaning of the register definitions.

OCOTP_HW_OCOTP_BOOT_CFG0 register:
3035_0470 Value of OTP Bank1 Word3

Register fields defined on page 823 & p824
[15: 0] BOOT_CFG
   Page 816: Boot fusemap : eMMC
   [0] - IO voltage selection (Manufacture mode) : 0=3V3
   [1] - IO voltage selection (Normal boot mode) : 0=3V3
   [3:2] - Speed : 00=Normal
   [6:4] - Bus width : 010=8-bit
   [7] - Fast boot: 0=Regular
   [8] - SD loopback : 0=Through SD pad
   [9] - Power cycle : 0=Disable
   [11:10]- Port select : 10=uSDHC3
   [14:12]- Boot device select : 010=eMMC (According to p815, Table 6-41)
   [15] - Reserved
[24:16] Reserverd
[25] SEC_CONFIG[1] : 1x - Closed (HAB Security On)
[27:26] Reserved
[28] BT_FUSE_SEL : 1=Boot config from eFuses
[29] FORCE_COLD_BOOT : 1=Always cold boot. Higher security
[31:30] Reserved

The programmed fuse value:
u-boot=> fuse sense 1 3 1
  Sensing bank 1:
  Word 0x00000003: 0x32002820

When u-boot is programmed into eMMC, it boots it regardless of the external bootpin settings.

If I wipe the u-boot from eMMC, it will load the u-boot on the SD card if the external boot pins are set to Mode0=1, Mode1=0

I expect the boot ROM is falling back to SD due to SDMMC_MFG (manufacture mode) still being active.

Page 824 defines further boot config registers:
3035_0480 Value of OTP Bank2 Word0 (OCOTP_HW_OCOTP_BOOT_CFG1)
3035_0490 Value of OTP Bank2 Word1 (OCOTP_HW_OCOTP_BOOT_CFG2)
3035_04A0 Value of OTP Bank2 Word2 (OCOTP_HW_OCOTP_BOOT_CFG3)
3035_04B0 Value of OTP Bank2 Word3 (OCOTP_HW_OCOTP_BOOT_CFG4)
Page 817 -- 819 covers the register fields. The registers were not altered. The default values are:
u-boot=> fuse sense 2 0 4
                01000010 00000000 00000000 00000000

I didn't use the FastBoot option.

 

So far I'm using u-boot in the user partition of the eMMC. I would like to use boot0 with fallover to boot1 if it becomes corrupt. Do you know if its as simple as programming the same configuration to boot0&boot1 and then the eMMC will automatically perform the switchover if the data in boot0 becomes corrupt?

Regards,
Frikkie

0 Kudos

5,337 Views
igorpadykov
NXP Employee
NXP Employee

Hi Marcel

I escalated questions and update when receive answers.

Best regards
igor

0 Kudos

5,337 Views
igorpadykov
NXP Employee
NXP Employee

Hi Marcel

I got answer below:

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

About eMMC fast boot on iMX8MMini_LPDDR4_EVK, I have a summary as following.

 

1.  Build boot image
Default release flash.bin can NOT support eMMC fast boot. Please rebuilt your flash.bin(boot image) using imx-mkimage tool.
~$ make SOC=iMX8MM flash_evk_emmc_fastboot
  Users can boot from SD fristly, then set eMMC configuration and burning boot image to eMMC correct partition.
2. U-boot command sets eMMC device configuration
eMMC number is 1 on iMX8MM_LPDDR4_EVK. IMX8MM fast configuration need to exactly match eMMC device side.
For example, if eMMC configs is "mmc1,fast_boot_ack_disable,boot0_partition" and  "mmc1,bus width is x04,ddr mode", GPIOs or efuse should be BOOT_CFG[7:0]= 11010111 and BOOT_CFG[15:8]= 00101010.
Users can try config BOOT_CFG under "internal boot" mode through GPIOs before fuse those bits.
All fast boot configuration except "ACK" could be set through BOOT_CFG. Fast boot "ACK" option only could be enabled by fuse, uboot command is "fuse prog 2 2 0x00000001"
To match the eMMC configs above, U-boot command should be
> mmc partconf 1 0 1 1   //mmc1,fast_boot_ack_disable,boot0_partition
> mmc bootbus 1 1 0 2   //mmc1,bus width is x04,ddr mode,high speed
3. Kernel command for copying boot-image to boot partition
~$ echo 0 > /sys/block/mmcblk2boot0/force_ro
~$ sudo dd if=flash.bin of=/dev/mmcblk2boot0 bs=1024 seek=1 && sync
~$ echo 1 > /sys/block/mmcblk2boot0/force_ro
Hardware Reset or CMD0 with Arg = 0xF0F0F0F0 can make eMMC from all status(except inactive) to pre-idle mode. There is no affect on eMMC reset and fast boot, even if the reset pin is unused on iMX8MMini_EVK.

Hope the steps can help customer to understand  the description of iMX8MMini Reference Manual. Thanks.

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

Best regards

igor

0 Kudos

2,876 Views
max_chen
Contributor I

HI @igorpadykov ,

Excuse me, i have question about the  emmc fast boot,  I use ddr3l in our board. 
Does emmc fast boot support DDR3l platfrom?

0 Kudos

5,336 Views
marcelziswiler
Senior Contributor I

Hi Igor

Thanks for this. Meanwhile, we also found some bits and pieces of this puzzle scattered throughout various source files with most of its accompanying documentation completely missing. Due to us using an eMMC connected to the SD1 pins rather than the SD3 ones we faced a further level of issues (e.g. https://source.codeaurora.org/external/imx/uboot-imx/commit/arch/arm/mach-imx/spl.c?h=imx_v2018.03_4... just hard-coding stuff different to any other i.MX 8M based platform). Anyway, we have it now somewhat working on our own hardware as well. However, you do realise that you did not really answer one single of the quite concrete questions I do still have about how this stuff is documented in the reference manual? Gladly accepting any further concrete answers on any of this. Thanks!

Cheers

Marcel

0 Kudos

5,335 Views
igorpadykov
NXP Employee
NXP Employee

Hi Marcel

 

I received answers below:

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

Table 6-3. GPIO override contact assignments

=> By contact you probably mean pin, right?

Yes. GPIO be overrided or not, which depends on boot mode and BT_FUSE_SEL.


6.1.4.7 Persistent bits

Table 6-8. Persistent bits

=> Table talks about SRC_GPR10 bits 29 and 30 but 6.5.5.26 SRC General Purpose Register 10 (SRC_GPR10) shows everything as reserved.

It seems to have a conflict. We are checking with SOC design.


Table 6-19. USDHC boot eFUSE descriptions

=> That table seems to be rather messed up:

Shipped value of 000 for single bit BOOT_CFG[7]. Missing settings for Bus width BOOT_CFG[6:4].

Rows 7 and 8 are completely messed up: MMC Speed Mode (CFG[3:2])

USDHC1 IO Voltage Selection (CFG[1])

=> Fuse column talks about BOOT_CFG vs. 0x490 and 0x4A0 but unclear what exact fuses that now is.

=> Order of rows (e.g. starts with bit 7 down to bit 0 and then bit 15 down to 8) is very confusing.

The information included in Table 6-19. USDHC boot eFUSE descriptions is incomplete.
Please also refer to Table 6-43. MMC/eMMC Boot Fusemap and Table 6-47. Boot Fusemap.

pastedImage_1.jpg

6.1.5.4.2 MMC and eMMC boot

eMMC4.3 or eMMC4.4 device supporting special boot mode

The BOOT ACK is selected by the .

=> I guess there is something crucial missing before that dot.

I noticed your description. Indeed, there be missing information.  I will feedback it to doc team.
The BOOT ACK is selected by the 0x4A0[0]. Please refer to Table 6-47. Boot Fusemap or Table 6-19. USDHC boot eFUSE descriptions.

 

eMMC4.4 device

This mode can be selected by the BOOT_CFG2[7:5] (bus width) fuse.

=> Can't find any further mentioning of that BOOT_CFG2[7:5] anywhere.

Boot mode and device are introducted by some sections. You can refer to it posted by iMX8MMini_EVK schmatic.
It is very helpful for your design.

 

6.1.5.4.4 IOMUX configuration for SD/MMC

Table 6-22. SD/MMC IOMUX pin configuration

=> Is it really true that for USDHC1 and USDHC2 DATA4 to DATA7 are not using their native SD1 resp.
SD2 pins but rather some weird ECSPI1 resp. ECSPI2 alt2 ones?
Anyway, so far, trying 4-bit only mode also does not seem to work.

There are some errors in Table 6-22. ECSPI1 don't have alt2 function as data[4:7] pins of USDHC2.
ECSPI2 don't have alt2 function as data[4:7] pins of USDHC1.

USDHC1 and USDHC3 can support up to an 8-bit interface, USDHC2 can only support up to a 4-bit interface.

SD/eSD can support 1-bit/4-bit bus width boot mode. MMC/eMMC can support 1-bit/4-bit/8-bit bus width boot mode.
Please set BOOT_CFG[0:15] according to your design.
 

6.1.5.4.5 Redundant boot support for expansion device

=> It's not quite clear whether or not this section also applies to eMMC and more specifically its fast boot mode as well.
E.g. do the same image offsets apply or are they different when putting stuff into the eMMC hardware boot area partitions?

Redundant boot can be applied to eMMC, but ROM can NOT support eMMC fast boot for secondary image.

 

6.2.1 Boot Fusemap

=> Confusing use of BOOT_CFG vs. 0x470.  I assume they mean the same thing.

Yes. They will realize the same function.
If BOOT_MODE1 and BOOT_MODE0 be set as 00(BOOT From Fuses), boot config be read from efuse.
If BOOT_MODE1 and BOOT_MODE0 be set as 10(Internal Boot),  boot config be read from BOOT_CFG pins.
 

Table 6-43. MMC/eMMC Boot Fusemap

=> Does the "Power Cycle Enable" and/or "SD Loopback Clock Source SEL" settings actually really matter at all if booting from eMMC?
Both configs have effect on eMMC booting.
BOOT_CFG[9]"Power Cycle Enable" determines SD power cycle enable/eMMC reset enable;
If the SD Loopback Clock is set, the feedback clock comes directly from the loopback SD clock, instead of the card clock(by default).

 

=> Row 0x470[7:0] mentions "Reserved for HS200". Is HS200 actually supported for eMMC booting at all?

"Reserved for HS200" means current boot code can NOT support HS200 mode.


6.3.2.2 Fuse Shadow Memory Footprint

=> That graphic show 5 BOOT_CFGs, however, it is not quite clear what exactly is meant by those.

List all fuse shadow memory, BOOT_CFGs[0:4], Shadowed memory mapped access to OTP Bank x, word x.

 

6.3.4 OCOTP Memory Map/Register Definition

OCOTP memory map

=> At least here there is the first concrete mentioning if OTP banks and words but what exactly they map to now is still not quite clear e.g.

For fuse mapping, please refer to Table 6-43. MMC/eMMC Boot Fusemap and Table 6-47. Boot Fusemap.

Value of OTP Bank1 Word3 (Boot Configuration Info.) (OCOTP_HW_OCOTP_BOOT_CFG0)
Address: 3035_0000h base + 470h offset = 3035_0470h

Value of OTP Bank2 Word0 (Boot Configuration Info.) (OCOTP_HW_OCOTP_BOOT_CFG1)
Address: 3035_0000h base + 480h offset = 3035_0480h

Value of OTP Bank2 Word1 (Boot Configuration Info.) (OCOTP_HW_OCOTP_BOOT_CFG2)
Address: 3035_0000h base + 490h offset = 3035_0490h

Value of OTP Bank2 Word2 (Boot Configuration Info.) (OCOTP_HW_OCOTP_BOOT_CFG3)
Address: 3035_0000h base + 4A0h offset = 3035_04A0h

Value of OTP Bank2 Word3 (BOOT Configuration Info.) (OCOTP_HW_OCOTP_BOOT_CFG4)
Address: 3035_0000h base + 4B0h offset = 3035_04B0h

 

Best regards
igor

5,335 Views
marcelziswiler
Senior Contributor I

Hi Igor

Thanks, that clarified a few things. However, I still have some more questions.

> There are some errors in Table 6-22. ECSPI1 don't have alt2 function as data[4:7] pins of USDHC2.
ECSPI2 don't have alt2 function as data[4:7] pins of USDHC1.
>
> USDHC1 and USDHC3 can support up to an 8-bit interface,

OK, but on what exact data[4:7] pins for USDHC1 is the question.

> USDHC2 can only support up to a 4-bit interface.
>
> SD/eSD can support 1-bit/4-bit bus width boot mode. MMC/eMMC can support 1-bit/4-bit/8-bit bus width boot mode.
> Please set BOOT_CFG[0:15] according to your design.

> Redundant boot can be applied to eMMC, but ROM can NOT support eMMC fast boot for secondary image.

OK, but how exactly does it work? By default we can eMMC fast boot from the primary hardware area boot partition. But if that fails due to e.g. corruption how/where exactly would it attempt to boot the secondary image now? And how exactly does the eMMC know that it should no longer be in fast boot mode?

0 Kudos

5,335 Views
lockit282
Contributor III

Were you able to get redundant boot working?  Were you using an Android based system?  If you were able to get it to work would you mind sharing how you did it?  I am currently trying to get it working on our system -- my issue is figuring out the correct offset for both the table and the secondary image (using u-boot-imx8mm-trusty.imx).  Also wondering if for test you can just leave fastboot in both as long as you do not use it in the secondary image?

0 Kudos

5,335 Views
marcelziswiler
Senior Contributor I

No, unfortunately, we never got any useful answer about this from NXP :-(

0 Kudos

5,337 Views
marcelziswiler
Senior Contributor I

We hooked up an oscilloscope to the eMMC's clock line but absolutely no reaction upon power-cycle so far. Wondering which of them many misleading parts of the reference manual is responsible for this!

0 Kudos