[tryboot] in EEPROM config to change BOOT_ORDER does not seem to work

[mvirkkunen]

Describe the bug

The [tryboot] conditional does not seem to work in the EEPROM configuration to change BOOT_ORDER. The documentation suggests that "Conditional filters are also supported except for EDID", but at least in my case this particular one doesn't seem to do anything. Does the EEPROM configuration not count as a "configuration file", or am I doing something wrong?

Steps to reproduce the behaviour

Using the bootloader configuration below, I was hoping to be able to temporarily boot from USB while keeping the SD card as the primary boot device, in order to boot faster. However even though the bootloader reports that it noticed the TRYBOOT flag, the first boot mode tried is SD, and it does not even try to enumerate USB devices before booting from SD.

Device (s)

Raspberry Pi 4 Mod. B

Bootloader configuration.

[all] NET_INSTALL_ENABLED=0 DISABLE_HDMI=1 BOOT_UART=1 BOOT_ORDER=0xf41

[tryboot] BOOT_ORDER=0xf14

System

vcgencmd bootloader_version

2022/11/25 10:54:13 version 850fab5f087c6c1b257d394d12e746503eb7bded (release) timestamp 1669373653 update-time 0 capabilities 0x0000007f

Bootloader logs

[ 23.938204] reboot: Restarting system with command '0 tryboot'

RPi: BOOTLOADER release VERSION:850fab5f DATE: 2022/11/25 TIME: 10:54:13 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1669373653 serial d2c5e564 boardrev b03115 stc 622769 PM_RSTS: 0x00000020 part 00000000 reset_info 00000001 uSD voltage 3.3V Initialising SDRAM 'Samsung' 16Gb x1 total-size: 16 Gbit 3200 DDR 3200 0 0 16 152 TRYBOOT

TRYBOOT Boot mode: SD (01) order f4 SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276 SD HOST: 200000000 CTL0: 0x00800f00 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276 OCR c0ff8000 [316] CID: 009f5449534436344761672006300137 CSD: 400e00325b590001d0ff7f800a400000 SD: bus-width: 4 spec: 2 SCR: 0x02058483 0x01000000 SD HOST: 200000000 CTL0: 0x00800f04 BUS: 50000000 Hz actual: 50000000 HZ div: 4 (2) status: 0x1fff0000 delay: 2 MBR: 0x00000008, 4194304 type: 0x0c MBR: 0x00400008,10485760 type: 0x83 MBR: 0x00000000, 0 type: 0x00 MBR: 0x00000000, 0 type: 0x00 Trying partition: 0 type: 16 lba: 8 oem: 'mkfs.fat' volume: ' V ^ ' rsc 4 fat-sectors 120 c-count 1048507 c-size 4 root dir cluster 1 sectors 32 entries 512 FAT16 clusters 1048507 Trying partition: 0 type: 16 lba: 8 oem: 'mkfs.fat' volume: ' V ^ ' rsc 4 fat-sectors 120 c-count 1048507 c-size 4 root dir cluster 1 sectors 32 entries 512 FAT16 clusters 1048507 Read tryboot.txt bytes 737 hnd 0x6bd8 Read system/start4.elf bytes 2250688 hnd 0x6766 Read system/fixup4.dat bytes 5398 hnd 0x6763 0x00b03115 0x00000000 0x00001fff MEM GPU: 100 ARM: 924 TOTAL: 1024 Firmware: 1a79bba5cc84ea52d15809fff557479fdf084529 Nov 11 2022 11:13:01 Starting system/start4.elf @ 0xfec00200 partition 0 +

MESS:00:00:02.577081:0: arasan: arasan_emmc_open MESS:00:00:02.735908:0: brfs: File read: /mfs/sd/tryboot.txt MESS:00:00:02.739038:0: brfs: File read: 737 bytes

USB boot

No response

NVMe boot

No response

Network (TFTP boot)

No response

[timg236]

It's not supported in the EEPROM config because it's loaded earlier. I'll update the docs.

[mvirkkunen]

Aw, that's too bad. I guess there is no real way to only temporarily change the boot order to boot from USB then?

A hack I came up with was to have "tryboot.txt" only exist on the USB drive and not on SD, so the SD card will be ignored in tryboot mode because the file doesn't exist, but it feels like.. a hack.

[timg236]

It's not trivial to change it, and [tryboot] wasn't intended for this purpose. However, it's use-case seems reasonable so moved this to an 'feature', there might be a more generic boot-flag that we can do if space can be found in the partition number field etc.

[mvirkkunen]

Yes, tryboot definitely wasn't meant for this, but if it had worked it would have been a convenient way to set a temporary boot device. Of course, if there could be an option to set the boot mode (or some other flag) besides tryboot, that would be even better.

The specific usecase I was hoping to use this for is firmware updates on USB drives for offline devices that have an internal SD card. I want the drive to be bootable so that it can install firmware even onto a blank SD card, and I thought it would be simpler to reboot to it in the normal update case as well, in order to not have two different update paths to verify. I'm using the "tryboot.txt only exists on USB" hack for now, and it seems to work.

[lurch]

@mvirkkunen Would you like to test #579 ?