iMX.6: u-boot has a misconfigured mmc order in v2023pre

Affected images versions

• not relevant (explain why)
• see the table below (list the build id and the apt or ostree deployment of the tested images in the appropriate cells)

Type	Arch	v2021	v2022	v2023pre
minimal/fixedfunction	amd64
minimal/fixedfunction	armhf			apt
minimal/fixedfunction	arm64
target/hmi	amd64
target/hmi	armhf			apt
target/hmi	arm64
basesdk	amd64
sdk	amd64
nfs	amd64
nfs	armhf
nfs	arm64
lxc	amd64
lxc	armhf
lxc	arm64
image-builder
package-source-builder

Tested with apertis_v2023pre-fixedfunction-armhf-uboot_20221012.0019.img, the issue doesn't appear in v2022, v2023dev3 has not been tested.

Unaffected images versions

• v2021
• v2022

Steps to reproduce

Follow the steps at https://www.apertis.org/reference_hardware/imx6q_sabrelite_setup/ to install u-boot: Use the latest uboot-v2023pre-installer-mx6qsabrelite.img.

When rebooting with an apertis image on the SD card, the console will show:

U-Boot 2022.10+dfsg-1+apertis3bv2023preb1 (Apr 18 2022 - 16:34:49 +0000)

CPU:   Freescale i.MX6Q rev1.0 at 792 MHz
Reset cause: WDOG
Model: Freescale i.MX6 Quad SABRE Lite Board
Board: SABRE Lite
I2C:   ready
DRAM:  1 GiB
MMC:   FSL_SDHC: 2, FSL_SDHC: 3
[...]
MMC: no card present
Couldn't find partition mmc 0:1
Error selecting device
MMC: no card present
Couldn't find partition mmc 0:1
Error selecting device
MMC: no card present
Couldn't find partition mmc 0:1
Error selecting device
Hit any key to stop autoboot:  0 
MMC: no card present
MMC: no card present

Expected result

The MMC line should show:

MMC:   FSL_SDHC: 0, FSL_SDHC: 1

and boot from mmc0

Actual result

The MMC line shows:

MMC:   FSL_SDHC: 2, FSL_SDHC: 3

but the boot commands only try to boot on mmc0 then mmc1 before trying other methods.

Reproducibility

How often the issue is hit when repeating the test and changing nothing (same device, same image, etc.)?

Put the ✅ in the most appropriate entry:

1. ✅ always
2. often, but not always
3. rarely

Impact of bug

How severe is the bug? Does it render an image unbootable? Is it a security issue? Does it prevent specific applications from working? What is the impact? Does this bug affect a critical component? Does it cause something else to not work? How often is the bug likely to be found by a user? For example, every boot or once per year?

The board cannot boot anymore and needs manual commands to be entered in u-boot. This will especially happen when setting up a new board. For reference, the booting commands, that are also needed to install a new version of u-boot are:

=> setenv devnum 2
=> run mmc_boot

Attachments

None

Root cause

The root cause has not been determined yet. The aliases on the device tree seem correct (they did not change since v2022)

Outcomes

Fix aliases: pkg/u-boot!81 (merged)

Management data

This section is for management only, it should be the last one in the description.

/cc @andrunko @em @sagar @sudarshan @wlozano

Phabricator link: https://phabricator.apertis.org/T9333