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.
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
