Unable to boot Aplais iMX8

Technical Support
,
1

I was trying to enable secondary boot on our Apalis iMX8 board. I used the u-boot partconf command to modify the partion configuration.

/ # mmc extcsd read /dev/mmcblk0boot0 | grep PARTITION
Partition switching timing [PARTITION_SWITCH_TIME: 0xff]
Boot configuration bytes [PARTITION_CONFIG: 0x49]
Partitioning Support [PARTITIONING_SUPPORT]: 0x07
Partitions attribute [PARTITIONS_ATTRIBUTE]: 0x00
Partitioning Setting [PARTITION_SETTING_COMPLETED]: 0x00
Extended Partitions Attribute [EXT_PARTITIONS_ATTRIBUTE]: 0x0000
/ # mmc extcsd read /dev/mmcblk0boot1 | grep PARTITION
Partition switching timing [PARTITION_SWITCH_TIME: 0xff]
Boot configuration bytes [PARTITION_CONFIG: 0x4a] <<<--------
Partitioning Support [PARTITIONING_SUPPORT]: 0x07
Partitions attribute [PARTITIONS_ATTRIBUTE]: 0x00
Partitioning Setting [PARTITION_SETTING_COMPLETED]: 0x00
Extended Partitions Attribute [EXT_PARTITIONS_ATTRIBUTE]: 0x0000

Ever since I changed the partition config on the second partition I have been unable to boot the board. A Tezi install after forcing recovery appears to complete but the board still wont boot (no activity at the terminal).

I would like to reverse the changes to partition 2 but don’t have access to “mmc partconf” (uboot) via Tezi. The mmc commands available in Tezi don’t allow me to clear those boot partition access bits [0-2].

Questions:

  1. Can I tweak Tezi to stop at a u-boot prompt (thereby giving me access to “mmc partconf”)? I tried putting a blank boot.scr script in the SD card with Tezi (used for recovery) but still end up at a Tezi prompt.

  2. Any other way to get a u-boot prompt?

  3. A way to change the 0-2 bits via Tezi?

Thanks for your help.

3

Yes, simply hold down the ‘space’ key in the debug UART terminal while loading TEZI via USB OTG. Then you need to restore original eMMC partition configuration
mmc partconf 0 1 1 0

4

I was able to get it booting again but what appeared to make the difference was clearing the BOOT_ACK bit on boot partition 0 which has always been set.

I don’t understand yet why there appears to be 3 different partition config settings on one device. mmcblk0boot0, mmcblk0boot1 and mmclblk0 can all be read and changed independently.

For secondary boot to work does the SCU actually reconfigure the partition config to activate boot1? The partitioning of the eMMC with boot0 at 0x0 and boot1 at 4MB matches the default 0x0 fuse settings. I assumed boot0 and boot1 both needed to be enabled for secondary boot to work but that experiment got me here. Any guidance would be great.

5
6

oof, that was dense but got it working. Or at least it boots with 1MB of boot0 erased and set as primary boot.

Is there a way to detect, post-boot, that there was indeed a boot failure on the primary boot partition?

Thanks for your help Alex.

7

Could you please provide more detailed information about what you plan to achieve and how you intend to do so?

8

For redundancy we want a backup (secondary) boot image. If the primary image is programmed and something is wrong with the image after programming, how would we know we didn’t just boot the secondary image? In other systems with redundancy like this, Zynq Ultrascale+ for example, we can read the “multiboot” register to know which partition number that was booted.

Right now I’m pretty sure the secondary boot works because I wrote 1MB of zeros to mmcblk0boot0 and it still boots but it won’t be that obvious in the real world.

9

Okay, but I’m still unclear about which component is responsible for selecting the image to boot and on what criteria it makes this selection. Have you made any modifications to U-Boot?

10

The SCU is in control of what gets booted. Assuming we are using boot0 as the primary partition it will attempt to boot from boot1 if the image is corrupted or has a read issue. In the case where this occurs, we want to know it and fix the primary image. Maybe I misunderstand your question. I’m guessing you know all of this.

11

Unfortunately, I’m not aware of such SCU functionality. To my knowledge, the SCU is responsible for managing power, clocks, resets, and security for the i.MX 8 SoC, as well as providing communication interfaces to other subsystems. If it involves the SCU, you would need to request the SCU to report which partition was selected for booting.

12

Yeah, something along those lines.

From the QM RM:

5.8.2.2.1 High Level eMMC Boot Flow
The SCU ROM supports 4 eMMC boot scenarios:

  1. In this scenario, the “eMMC fast boot” fuse is blown. The primary and secondary
    image container set are both in the boot partitions, and
    BOOT_PARTITION_ENABLE = 1 or 2.
  2. In this scenario, the “eMMC fast boot” fuse is blown. The primary and secondary
    image container set are both in the User Area, and BOOT_PARTITION_ENABLE = 7.
  3. In this scenario, the “eMMC fast boot” fuse is not blown. The boot mode is Normal
    Boot, and the primary and secondary image container set are both in the User Area.
  4. In this scenario, the “eMMC fast boot” fuse is not blown. The boot mode is Normal
    Boot, and the primary and secondary image container set are both in the boot
    partitions, and BOOT_PARTITION_ENABLE = 1 or 2.

For the eMMC boot scenario #1 and #2, the SCU ROM performs an eMMC fast boot.
The SCU ROM reads 8KB into the TCM free space and checks if the container is valid.
If the container is valid, the image is loaded according to the information in the container
header. If the container header is not found, the SCU ROM continues to read 24KB, and
then reads 8KB (from 0x8000) to check whether a valid container exists or not.
In the case of failure, the following is performed:
• The SCU ROM sends a MU message to the SECO to indicate that a secondary boot
is needed and then triggers a reset.
• The SCU ROM reads the ECSD register to check the
BOOT_PARTITION_ENABLE value.
• If BOOT_PARTITION_ENABLE = 1 or 2, the value 1 or 2 is written to ESCD
PARTITION_ACCESS, and then an attempt is made to read the image from offset 0.
• If BOOT_PARTITION_ENABLE = 7, the SCU ROM performs a normal eMMC
boot. The image container set address is specified by the fuse “Secondary Image
Container Set offset selection”.
For the eMMC boot scenario #3, the image is read normally from 0x8000. If this fails,
the SCU ROM sends a message to the SECO to indicate that a secondary boot is needed,
and issues a WDOG reset. Then the SCU ROM boots the secondary image container set
from the address specified by the fuse “Secondary Image Container Set offset selection”.
For eMMC boot scenario #4, ROM updates BOOT_PARTITION_ACCESS per the value
of ECSD BOOT_PARTITION_ENABLE, and then reads the image from offset 0x0. If
the boot fails, the SCU ROM sends a message to the SECO to indicate that a secondary
boot is needed, and issues a

13

If it involves the SCU, you can send a request to the SCU to report which partition was selected for booting. Information on the SCFW source code location and compilation instructions is available here. You can modify it to meet your specific requirements.