BOOTVAR0 support for RPi4

[andr2000]

Describe the bug

Hello,
it becomes crucial for at least secure boot use-cases to be able to have a single signed image for different HW configurations. It is now possible to handle that with bootvar0 + config.txt for RPi5, but it seems RPi4 has similar capabilities, but lacks bootvar0 support
It would be extremely helpful to have bootvar0 implemented.
Thank you in advance

Steps to reproduce the behaviour

Try to use bootvar0 on RPi4/CM4

Device (s)

Raspberry Pi CM4

Bootloader configuration.

[all]
BOOT_UART=1
WAKE_ON_GPIO=0
POWER_OFF_ON_HALT=1
HDMI_DELAY=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=0xf25641

# Disable self-update mode
ENABLE_SELF_UPDATE=0

# Setting SIGNED_BOOT=1 causes the bootloader to required signed boot.img files
# which can be used to test that boot.img files are signed correctly.
#
# This setting does NOT enable secure-boot and can be switched off.
#
# If secure-boot is enabled via program_pubkey=1 then SIGNED_BOOT=1 is implicitly set
# and cannot be unset.
SIGNED_BOOT=1

DISABLE_HDMI=1

BOOTVAR0=0x10

[bootvar0&0x10]
dtoverlay=uart2

[bootvar0&0x8]
dtoverlay=uart4

[all]

System

No response

Bootloader logs

No response

USB boot

No response

NVMe boot

No response

Network (TFTP boot)

No response

[berkutta]

Also requested here https://forums.raspberrypi.com/viewtopic.php?p=2338591

[andr2000]

I grepped for BOOTVAR0 in usbboot and there are traces of it in 2711 bootloader binaries. My guess is those are not implemented though, just placeholders maybe... It's a pity we cannot send patches for the bootloader itself...
Still, documentation mentions its support

[popcornmix]

BOOTVAR0 for pi4 is planned, but it wasn't clear how many were using this on Pi5, and whether there was demand for it on Pi4, so it has been low priority. I'll bump it up the priority list.

[andr2000]

It is really needed for production where you want a single run-time configurable build. In case of secure boot it is even more complicated w/o this feature.
Having it for Pi5 only doesn't solve the problem if you need to support both Pi5 and older Pi4 devices.
You can somewhat work this around with some scripting, say in initramfs, which may use dtoverlay conditionally to customize the device tree and some other parameters, but this doesn't work for platform devices at least (UARTs for example)...