Feature request: Verbose output from `start*.elf`

srcshelton commented 1 month ago

Describe the ~~bug~~ Feature Request Even with uart_2ndstage=1, the serial output I'm getting is as follows:

RPi: BOOTLOADER release VERSION:4fd8f1f3 DATE: 2023/05/11 TIME: 07:26:03
BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=683786363 serial xxxxxxxx boardrev d03140 stc xxxxxx
PM_RSTS: 0x00001000
part 00000000 reset_info 00000000
uSD voltage 3.3V
Initialising SDRAM 'Micron' 32Gb x2 total-size: 64 Gbit 3200
DDR 3200 1 0 64 152

Boot mode: SD (01) order f2564
SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1ff0000 delay: 276
SD HOST: 200000000 CTL0: 0x00800f00 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: EMMC
SD retry 1 oc 0
SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
OCR c0ff8080 [0]
CID: 00150100414a544434520600f4c05238
SD HOST: 200000000 CTL0: 0x00800f04 BUS: 25000000 Hz actual: 25000000 HZ div: 8 (4) status: 0x1fff0000 delay: 4
SD HOST: 20000000 CTL0: 0x00800f04 BUS: 50000000 Hz actual: 50000000 HZ div: 4 (2) status: 0x1fff0000 delay: 2
MBR: 0x00000001, 2103295 type: 0xee
MBR: 0x00201800,  131072 type: 0xef
MBR: 0x00000000,       0 type: 0x00
MBR: 0x00221800,28301312 type: 0xee
Trying partiion: 0
GPT xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 000000001 001d1efff num-partitions 128 entry-size 128
GPT partition: 0 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 000000800..0000017ff
GPT partition: 10 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 000001800..0002017ff
GPT partition: 11 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 000201800..0002217ff
Matched GUID bootable-part-idx 0 want partition 0
type:32 lba: 2103296 oem: 'BSD  4.4' volume: ' BOOT_0     '
rsc 32 fat-sectors 1008 c-count 129024 c-size 1
root dir cluster 2 sectrs 0 entries 0
FAT32 clusters 129024
Trying partition: 0
GPT xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 000000001 001d1efff num-partitions 128 entry-size 128
GPT partition: 0 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 000000800..0000017ff
GPT partition: 10 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 000001800..0002017ff
GPT partition: 11 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 000201800..0002217ff
Matched GUID bootable-part-idx 0 want parition 0
type: 32 lba: 2103296 oem: 'BSD  4.4' volume: ' BOOT_0     '
rsc 32 fat-sectors 1008 c-count 129024 c-size 1
root dircluster 2 sectors 0 entries 0
FAT32 clusters 129024
Read config.txt bytes     7371 hnd 0x10b8
Read start4cd.elf bytes   808892 hnd 0x37
Read fixup4cd.dat bytes     3204 hnd 0x1d101
0x00d03140 0x00000000 0x00001fff
MEM GPU: 16 ARM: 998 TOTAL: 1014
Firmware: f4e2138c2adc8f3a92a3a65939e458f11d7298ba Feb 29 2024 12:25:16
Starting start4cd.elf @ 0xff000200 partition 0
+

(…delay…)

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]

This is all good up to Starting start4cd.elf - but to add clarity when trying to further debug early boot failures, please consider adding more helpful (optional?) debug output such as:

Verbose warnings if any expected file is missing (I recently moved boot-files to subdirectories to be identified by os_prefix= and forgot to move the kernel - start4cd.elf simply hung rather than alerting me of any issue);
Some character (.?) printed for every unit-amount (1kb?) of kernel image/DTB/initramfs data transferred into RAM from the boot media (perhaps different characters for each type of data?);
Notification when data transfer is complete (useful then boot-delay or boot_delay_ms is set to know when the timer has started);
Verbose notification of any other issue or error - or simply insight into the steps which VideoCore is performing as start*.elf executes.

To reproduce With uart_2ndstage=1, a whole host of edge-cases can leave the system hung with no insight into what might have occurred.

Expected behaviour It would be incredibly helpful if start*.elf could be as verbose as possible (with UART enabled?) to give technical users insight into what is (or isn't) happening at this stage of the boot-process.

System

Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW: CM4
Which firmware version (vcgencmd version)? f4e2138c2adc8f3a92a3a65939e458f11d7298ba Feb 29 2024 12:25:16

srcshelton commented 1 month ago

Update:

I've just seen https://github.com/raspberrypi/documentation/pull/3550 - I don't suppose there's any chance that debug-logging could be restored to start4cd.elf (… or added as a new start4cdd.elf?), for users who only require a minimal set of GPU features, but do wish to be able to debug what's happening?

pelwell commented 1 month ago

The cd in start4cd stands for cut-down. In order to reduce the firmware to fit in 16MB, one of the things that is omitted is the logging output. Debug your system with the regular firmware, then switch.

srcshelton commented 1 month ago

I still feel that there would be a benefit to start*.elf producing more verbose general output as outlined above rather than the detailed debug output which the non-cd binaries output (since start4cd.elf appears to hang for several seconds even when everything is working correctly!) - but I can close this issue if this isn't going to be possible.

pelwell commented 1 month ago

The start firmware is not used on Pi 5, and people have managed for 10 years with it as is, so possible or not it is unlikely to be changed now.

raspberrypi / firmware

Feature request: Verbose output from `start*.elf` #1886