Running `rpiboot` reports `Cannot open file fixup4.dat`
adelton opened this issue · 4 comments
Describe the bug
I've built rpiboot on my Fedora and was able to use it to boot and enable my Compute Module 4 as USB mass storage (/dev/sda). However, during the execution, the rpiboot reported
Cannot open file fixup4.dat
This file is nowhere to be found in this repository and is it concerning that the tool looks for some "random" file which could possibly change its behaviour.
Steps to reproduce the behaviour
- Run
rpiboot. - Connect CM4 (in PiTray mini) to the USB of the machine.
Device(s)
Raspberry Pi CM4
Compute Module IO board.
PiTray mini 200904857.
RPIBOOT logs
# rpiboot
RPIBOOT: build-date Jan 4 2024 version 20221215~105525
Waiting for BCM2835/6/7/2711...
Loading embedded: bootcode4.bin
Sending bootcode.bin
Successful read 4 bytes
Waiting for BCM2835/6/7/2711...
Loading embedded: bootcode4.bin
Second stage boot server
Cannot open file config.txt
Cannot open file pieeprom.sig
Loading embedded: start4.elf
File read: start4.elf
Cannot open file fixup4.dat
Second stage boot server done
Kernel logs
[215970.038751] usb 3-1: new high-speed USB device number 37 using xhci_hcd
[215970.165231] usb 3-1: config index 0 descriptor too short (expected 55, got 32)
[215970.165697] usb 3-1: New USB device found, idVendor=0a5c, idProduct=2711, bcdDevice= 0.00
[215970.165701] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[215970.165703] usb 3-1: Product: BCM2711 Boot
[215970.165705] usb 3-1: Manufacturer: Broadcom
[215970.165707] usb 3-1: SerialNumber: b96b0915
[215972.246426] usb 3-1: USB disconnect, device number 37
[215974.847761] usb 3-1: new high-speed USB device number 38 using xhci_hcd
[215974.975545] usb 3-1: New USB device found, idVendor=0a5c, idProduct=2711, bcdDevice= 0.00
[215974.975551] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4
[215974.975554] usb 3-1: Product: BCM2711 Boot
[215974.975556] usb 3-1: Manufacturer: Broadcom
[215974.975558] usb 3-1: SerialNumber: b96b0915
[215976.225753] usb 3-1: USB disconnect, device number 38
[215977.815749] usb 3-1: new high-speed USB device number 39 using xhci_hcd
[215977.942972] usb 3-1: New USB device found, idVendor=0a5c, idProduct=0001, bcdDevice= 0.01
[215977.942983] usb 3-1: New USB device strings: Mfr=2, Product=1, SerialNumber=3
[215977.942986] usb 3-1: Product: Compute Module
[215977.942989] usb 3-1: Manufacturer: Raspberry Pi
[215977.942991] usb 3-1: SerialNumber: b96b0915
[215977.944711] usb-storage 3-1:1.0: USB Mass Storage device detected
[215977.945181] scsi host0: usb-storage 3-1:1.0
Device UART logs
No response
It also report:s
Cannot open file config.txt
Cannot open file pieeprom.sig
That's the way the tool works, allowing custom firmware images to be used - see https://github.com/raspberrypi/usbboot/tree/master/msd for a firmware binary with MSD support. It could have included a fixup4.dat file, which would allow the image to adjust for devices with more RAM, but in practice it's not necessary.
I wonder if these should be read when a specific command line parameter is used, not when the files happen to be in the current (?) directory?
We'll consider any submitted PRs, but otherwise this is unlikely to change.
I briefly considered masking "file not found" or moving to a higher verbosity debug level but it's actually quite useful be because it indicates progress from the bootloader so I think NGTF.