Closed woachk closed 2 years ago
Yes, although it would need to fail reading from the SPI EEPROM to do this! This will be supported later, along with network booting and USB booting
Hi,
So after removing the boot code section from the SPI flash (but not the memsys ones), booting is feasible.
Meanwhile, in that state the BCM2711 boot device can actually be seen when not having the boot code section present as recovery.bin on an microSD card.
Thanks,
Update: successfully booted Pi4 over USB
SPI has no bootable code, but has every other file, so it's not a complete USB boot, just loading the bootable part of the EEPROM image over USB
Now that #46 has been merged, is there something else needed for USB boot? Is there a guide already to get a Raspberry Pi 4 to boot from USB mass storage? I'm happy to test.
Thanks for clarifying.
given that the boot rom is able to fire up usb gadget mode, i assume the rpi4 bootcode.bin
could also in theory load memsys??.bin
over usb as well?
is there any public documentation on what memsys??.bin
does? and why there are 8 copies of it?
I guess this can be closed now? #68 shows rpiboot being used with a rpi4b.
if recovery.bin and the eeprom fail (or are disabled with OTP+gpio), it can boot a recovery.bin over usb-device mode, which can request the pieeprom.bin and flash things if the eeprom has been flashed to include 0x3 (the usb-dev mode) in BOOT_ORDER, it can fetch start4.elf over usb
whats not clearly documented yet, is how to force usb-dev mode without flashing the eeprom
also, i did most of the above testing with https://github.com/librerpi/rpi-tools/tree/master/webusbboot rather then the original usbboot (this repo)
also, if 0x3 (usb-dev) is in the BOOT_ORDER, and pieeprom.{upd,sig} are in the usbboot fileserver, the eeprom can reflash itself, without having to force an eeprom failure exactly the same way it works over network and usb-host boot
usb-dev mode will fail, and try the next one, if the host on the far end responds, and cant find the required boot files but usb-dev mode wont fail, if the host is missing (dumb power brick), and never responds
so putting usb-dev as your # 1 boot priority isnt a valid solution right now, which complicates trying to quickly switch between internal and external booting
but usb-dev mode wont fail, if the host is missing (dumb power brick), and never responds
Perhaps the usb-dev mode is missing a suitable timeout setting? ping @timg236
Usb dev behaves the same as pi3 and does not time out. It’s there to support CM4 MSD and ramdisk so enhancing this to be a general purpose boot mode is a low priority
@cleverca22 As you've clearly investigated this rather thoroughly, perhaps you'd like to add your findings to https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/ ? :slightly_smiling_face:
perhaps adding a timeout to bootconf.txt, that defaults to never might be an option? then you could put usb-dev earlier in the boot priority list, without a power brick making it unbootable
@lurch i did document my initial findings in https://www.raspberrypi.org/forums/viewtopic.php?f=98&t=288900 and i should make a PR to the docs repo later, but id like to get my hands on a CM4 to validate some things, like if the nRPIBOOT jumper also prevents flashing
found a minor bug in the firmware/boot/start4.elf
binary:
[root@amd-nixos:~]# lsusb -d 0a5c:2764
Bus 013 Device 033: ID 0a5c:2764 Broadcom Corp. BCM2711 Boot
if dwc2 isnt enabled in config.txt, and you boot linux, the dwc2 is never reset the host pc still thinks its in gadget mode and fully connected, despite linux now being in control, and linux being un-aware of the dwc2 even existing
edit:
even when dwc is enabled in config.txt
, it still doesnt get reset, until you actually modprobe dwc2
due to a lack of udev, it doesnt auto-load, because the initrd unpacks after DTB parsing, and its expecting udev to probe things again
i did document my initial findings in https://www.raspberrypi.org/forums/viewtopic.php?f=98&t=288900 and i should make a PR to the docs repo later
Nice. You may also be interested in reading some of the notes I pulled together here - although some of it might be out-of-date now, and I make no guarantees as to its accuracy :wink:
i also missed small details like how CM4 skips the recovery.bin from SD step i was worried about that potentially resulting in a bricked CM4, since you cant get into MSD mode if its booting that file
but that was already thought of and disabled, but i dont see how it was disabled yet, would need to see an OTP dump from a CM4
This has worked on Pi4 for a while now it's possible to select a GPIO to be the nRPIBOOT GPIO on a Pi4 See program_rpiboot_gpio https://github.com/raspberrypi/usbboot/blob/master/secure-boot-recovery/config.txt
Hi,
Is RPi4 support for this feasible considering that it has an OTG USB Type-C port?
Thanks,