topic Re: imx93 eMMC boot container set selection in i.MX Processors

imx93 eMMC boot container set selection

electro1 — Mon, 20 Jan 2025 10:18:22 GMT

Hi,

I'm trying to get redundant bootloader in eMMC working, were I want to have a version of the bootloader in both eMMC bootarea 1 and 2. As I understand it, the iMX93 ROM should select the container set with the highest SWVersion as primary image set.

I created two versions of the bootloader by doing a dummy change in u-boot to get different git hashes and version strings so I can differentiate between them. Then I built imx-boot boot containers and manually modified the SWVersion field for the OEM container by changing the header at offset 1K. Lets call them V1 and V2 where V2 has higher SWVersion field.

I then flashed these versions to the eMMC bootareas.

This is the behavior I see for different scenarios:

Bootarea1: V1, Bootarea2: V2. V1 boots, even though V2 has higher SWVersion
Bootarea1: V2, Bootarea2: V1. V2 boots as expected
Bootarea1: none, Bootarea2: V2. V2 boots as expected

It seems bootarea1 is always used as long as it is valid. I would expect V2 to boot in scenario 1 above.

As far as I understand, eMMC fast boot is not enabled. All the boot fuses are 0 and unmodified. Secondary boot offset as well, I think it is not used when eMMC bootareas are used?

The eMMC is has the following boot configuration:

=> mmc partconf 0
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x0
BOOT_PARTITION_ENABLE: 0x1
PARTITION_ACCESS: 0x0

I tried both with and without boot acknowledgment enabled, with no difference in behavior.

Re: imx93 eMMC boot container set selection

AldoG — Thu, 23 Jan 2025 19:53:22 GMT

Hello,

It does behave as it is said even you may refer to the Figure 18. Boot Image Container Sets Selection in reference manual.

Could you help me sharing the boot logs when running your test?

Best regards/Saludos,
Aldo.

Re: imx93 eMMC boot container set selection

electro1 — Fri, 24 Jan 2025 10:18:16 GMT

Here is information and logs about the three cases.

Headers from imx-boot containers

output using od --width=4 -A x -t x1

NXP header is same for both containers.

v1 header:
...
000400 00 a0 00 87 OEM header
000404 10 00 00 00
000408 01 00 00 01 SW Version: 1, Fuse version 0
00040c 90 00 00 00
...

v1 u-boot git hash:

e65c48e

v2 header:
...
000400 00 a0 00 87 OEM header
000404 10 00 00 00
000408 02 00 00 01 SW Version: 2, Fuse version: 0
00040c 90 00 00 00
...

v2 u-boot git hash:

669f2a5

Logs

flash_bootloader.sh below is a simple script which flashes a given boot area (0 or 1).

Scenario 1: Bootarea1 v1, Bootarea 2 v2

v1 boots, see git hash in version string. Expecting v2 to boot.

Setup:

# ./flash_bootloader.sh 0 imx-boot-v1
3960+1 records in
3960+1 records out
# ./flash_bootloader.sh 1 imx-boot-v2

Boot log:

U-Boot SPL 2024.04+ge65c48e26ef+p0 (Jan 17 2025 - 08:03:10 +0000)
SOC: 0xa1009300
LC: 0x2040010
PMIC: Over Drive Voltage Mode
EA: Using gzipped ddr data from eeprom
M33 prepare ok
Normal Boot
Trying to boot from BOOTROM
Boot Stage: Primary boot
image offset 0x0, pagesize 0x200, ivt offset 0x0
Load image from 0x54800 by ROM_API
NOTICE: TRDC init done
NOTICE: BL31: v2.10.0 (release):android-14.0.0_2.2.0-rc2-0-g7c64d4e86
NOTICE: BL31: Built : 10:35:32, Aug 29 2024

U-Boot 2024.04+ge65c48e26ef+p0 (Jan 17 2025 - 08:03:10 +0000)

Reset Status: POR

CPU: NXP i.MX93(52) Rev1.1 A55 at 1700 MHz
CPU: Extended Industrial temperature grade (-40C to 125C) at 51C

Scenario 2: Bootarea1 v2, Bootarea2 v1

v2 boots, see git hash in version string

Setup:

# ./flash_bootloader.sh 0 imx-boot-v2
3960+1 records in
3960+1 records out
# ./flash_bootloader.sh 1 imx-boot-v1
3960+1 records in
3960+1 records out

Boot log:

U-Boot SPL 2024.04+g669f2a5bf5d+p0 (Jan 17 2025 - 14:34:22 +0000)
SOC: 0xa1009300
LC: 0x2040010
PMIC: Over Drive Voltage Mode
EA: Using gzipped ddr data from eeprom
M33 prepare ok
Normal Boot
Trying to boot from BOOTROM
Boot Stage: Primary boot
image offset 0x0, pagesize 0x200, ivt offset 0x0
Load image from 0x54800 by ROM_API
NOTICE: TRDC init done
NOTICE: BL31: v2.10.0 (release):android-14.0.0_2.2.0-rc2-0-g7c64d4e86
NOTICE: BL31: Built : 10:35:32, Aug 29 2024

U-Boot 2024.04+g669f2a5bf5d+p0 (Jan 17 2025 - 14:34:22 +0000)

Reset Status: POR

CPU: NXP i.MX93(52) Rev1.1 A55 at 1700 MHz
CPU: Extended Industrial temperature grade (-40C to 125C) at 50C

Scenario 3: Bootarea1 empty, Bootarea2 v2

v2 boots, see git hash in version string

Setup:

# ./flash_bootloader.sh 0 /dev/zero
dd: error writing '/dev/mmcblk0boot0': No space left on device
8193+0 records in
8192+0 records out
# ./flash_bootloader.sh 1 imx-boot-v2
3960+1 records in
3960+1 records out

Boot log:

U-Boot SPL 2024.04+g669f2a5bf5d+p0 (Jan 17 2025 - 14:34:22 +0000)
SOC: 0xa1009300
LC: 0x2040010
PMIC: Over Drive Voltage Mode
EA: Using gzipped ddr data from eeprom
M33 prepare ok
Normal Boot
Trying to boot from BOOTROM
Boot Stage: Secondary boot
image offset 0x0, pagesize 0x200, ivt offset 0x0
Load image from 0x54800 by ROM_API
NOTICE: TRDC init done
NOTICE: BL31: v2.10.0 (release):android-14.0.0_2.2.0-rc2-0-g7c64d4e86
NOTICE: BL31: Built : 10:35:32, Aug 29 2024

U-Boot 2024.04+g669f2a5bf5d+p0 (Jan 17 2025 - 14:34:22 +0000)

Reset Status: WDOG3

CPU: NXP i.MX93(52) Rev1.1 A55 at 1700 MHz
CPU: Extended Industrial temperature grade (-40C to 125C) at 51C

Re: imx93 eMMC boot container set selection

AldoG — Fri, 24 Jan 2025 20:54:53 GMT

Hello,

It seems that the Secondary_boot_offset you have is not correct this is why is not taking into account the second container unless the first one is absent, please refer to the figure 18

Scenario 1 & 2

Scenario 3

Best regards/Saludos,
Aldo.

Re: imx93 eMMC boot container set selection

electro1 — Mon, 27 Jan 2025 07:58:23 GMT

I believe Scenario 3 should result in "No valid Image Set, no image set is picked up for boot" according to the diagram if the offset is invalid.

But I can try setting the secondary boot offset. What should it be set to when using eMMC boot areas? I think it should be zero, but that is not possible to set?

Re: imx93 eMMC boot container set selection

AldoG — Thu, 30 Jan 2025 22:54:03 GMT

Hello,.

Note that the offset of the 1st boot image container set is fixed on the primary boot device and hard code in ROM code. The offset of the 2nd boot image container set on the primary boot device is specified by the fuses “Secondary_boot_offset”:

As stated in Reference Manual table 24:
Secondary_boot_offset Offset = 1 MB*(2^n). n = 2 if fuse is 0. n = 0 if fuse is 2. Secondary boot flow is disabled if fuse value is bigger than 10

If Secondary_boot_offset = 0 → n = 2;
If Secondary_boot_offset = 2 → n = 0;

Best regards/Saludos,
Aldo.

Re: imx93 eMMC boot container set selection

electro1 — Fri, 31 Jan 2025 12:29:00 GMT

Secondary_boot_offset will be 1 MB if fuse is 2. This is not what we want, it should be 0 MB since the bootloader is stored at the beginning of the boot areas. Is this possible to configure?

From table 24:

Secondary_boot_offset Offset = 1 MB*(2^n). n = 2 if fuse is 0. n = 0 if fuse is 2. Secondary boot flow is disabled if fuse value is bigger than 10.

0000 - 4 MB
0001 - 2 MB
0010 - 1 MB
0011 - 8 MB
0100 - 8MB
0101 - 32MB
…
1001 - 512 MB
EMMC :
254 - last 128 M
255 - last 24K

In general this documentation is very confusing with binary and decimal values mixed. I guess secondary boot flow disabled if fuse is bigger than 10 decimal? At the same time the values 254 and 255 are specified for eMMC?

Re: imx93 eMMC boot container set selection

AldoG — Tue, 04 Feb 2025 19:56:27 GMT

Hello,

I have investigated further on this issue, and checked internally.

On i.MX93, for boot partitions on eMMC, primary image is in boot1 and secondary image is in boot2. Moreover, the SW_Version won't be checked here.

So to say the version it is skipped but in case of failure it does jump to the secondary image, in case of using user partition then offset needs to be set as we have discussed before.

Please do accept my apologize for the confusion.

Best regards/Saludos,
Aldo.

Re: imx93 eMMC boot container set selection

electro1 — Wed, 05 Feb 2025 08:27:17 GMT

Thank you for clarifying how it works. I hope the documentation can be updated to reflect this.