CM4 bootloader not booting from MSD GPT boot partition when GPIO is active

[knro]

Describe the bug

Cannot boot into alternate boot partition. HDMI does not work when GPIO 6 is pull low on power up to load this boot partition. CM4 is connected to a custom carrier board. It boots normally from MSD first GPT boot partition.

EEPROM boot.conf is configured to boot from Partition 3 (/dev/sda3) if GPIO 6 is activated (button press to trigger recovery on the custom carrier board).

# Boot from partition /dev/sda3 if GPIO 6 is pulled low
[gpio6=0]
PARTITION=3

/dev/sda1 is the regular boot partition and if GPIO 6 is pulled low, we expect it to boot from /dev/sda3. Both are FAT32 GPT partitions

/dev/sda: PTUUID="6f95897a-2b83-4988-9244-7e0e5c42f9b9" PTTYPE="gpt"
/dev/sda1: LABEL_FATBOOT="BOOT" LABEL="BOOT" UUID="E1BD-70BD" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="boot" PARTUUID="654c279d-d347-436b-900c-01e12bce6b06"
/dev/sda2: LABEL="rootfs" UUID="a4b3ef34-532d-430b-a401-589e4a6a5d2c" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="root" PARTUUID="d4c29ff9-782c-4a25-b339-4b4f2d7fe8c1"
/dev/sda3: UUID="884D-24D5" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="rescue_boot" PARTUUID="a7b3b751-c482-4d8a-aec9-a8e7700c41b0"
/dev/sda4: LABEL="rootfs" UUID="d048efb5-3235-4317-9dbc-e514ea7759e9" BLOCK_SIZE="1024" TYPE="ext4" PARTLABEL="rescue_root" PARTUUID="9f23b749-3208-4f1f-a120-fb4132d8416c"
/dev/sda5: LABEL="home" UUID="6c7ccf08-56cd-4904-9e4f-c311a86b8206" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="home" PARTUUID="3e433965-86cc-421c-9dc9-2ff3dbb482b8"

Please note that if we use sudo reboot 3 it does not work either, it always boots from the first MSD boot partition regardless.

Steps to reproduce the behaviour

1. Press button to pull GPIO 6 low
2. CM4 not booting

Device (s)

Raspberry Pi CM4, Other

Bootloader configuration.

[all] BOOT_UART=0 WAKE_ON_GPIO=1 POWER_OFF_ON_HALT=0

Boot Order Codes, from https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#BOOT_ORDER

Try SD first (1), followed by, USB PCIe, NVMe PCIe, USB SoC XHCI then network

BOOT_ORDER=0xf14

Set to 0 to prevent bootloader updates from USB/Network boot

For remote units EEPROM hardware write protection should be used.

ENABLE_SELF_UPDATE=1

USB_MSD_EXCLUDE_VID_PID=174c3074,174c2074

Boot from partition /dev/sda3 if GPIO 6 is pulled low

[gpio6=0] PARTITION=3

System

Raspberry Pi reference 2021-10-30 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, c12b1df4ed6416fb0df33ba1731c5b13c1bdbdf8, stage4

2023/05/11 07:26:03 version 4fd8f1f3f7a05f7756edb1d3f15ffd7e428981f5 (release) timestamp 1683786363 update-time 1692970553 capabilities 0x0000007f

Mar 17 2023 10:51:33 Copyright (c) 2012 Broadcom version 82f3750a65fadae9a38077e3c2e217ad158c8d54 (clean) (release) (start_x)

Linux 6.1.41-v8+ #1 SMP PREEMPT Thu Jul 27 08:29:37 +03 2023 aarch64 GNU/Linux

Bootloader logs

No response

USB boot

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 174c:3074 ASMedia Technology Inc. ASM1074 SuperSpeed hub Bus 002 Device 003: ID 174c:225c ASMedia Technology Inc. AS2235 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth Bus 001 Device 003: ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

NVMe boot

No response

Network (TFTP boot)

No response

[timg236]

There's no official support for GPT partitions, although I think in this case you might want partition 2. i.e. the second 'bootable' partition

[knro]

How come there is no support and it works fine when booting from the first GPT boot partition? It's only when GPIO 6 is triggered high (and tried it with partition 2) it fails to load the correct rescue boot partition.

[timg236]

Different bits of the stack have different ideas of partition numbers. Making GPT work correctly with autoboot / reboot parameters will require changes (possibly non-backwards compatible change) in various places and probably updates to start4.elf as well.

[timg236]

Marked as a future bug/enhancement to see whether GPT can be properly supported and what the impact on start4.elf might be.

btw: Partition zero means the 'default' partition. Typically this will end up as 1 assuming that 1 is the first bootable partition. This is because it corresponds with the partition number derived from the PM_RSTS register which will be zero after chip reset