Raspberry Pi 4 ROM bootloader

[za3k]

Yup, this was pure curiosity from a hobbyist messing with writing early-stage bootloaders/microkernels, about all the steps that would happen before my stage of bootloading got called.

From the Debian Wiki: "All Raspberry Pi models before the 4 (1A, 1B, 1A+, 1B+, Zero, Zero W, 2, 3) boot from their GPU (not from the CPU!), so they require a non-free binary blob to boot.". And "Announced in 2019, this system adds a second HDMI port, more memory, true Gigabit Ethernet and USB3. There is no support for it in the Debian kernels yet. We understand this computer no longer boots from the GPU, so it is probable it will no longer require a binary blob to boot." This may be accurate in context, I'd have to know more about what Debian is doing, but it mislead me into thinking that BOTH bootloader stages were in ARM on the Pi 4. Thanks dickon+co for the clarification. I may update that wiki if I get around to making an account (unlikely).

Thanks jamesh for the explanation, and you sound like you've been a bit harassed about this in the past, sorry if this was a bit of a sore point. It's certainly more fun for me to learn about how something I own works, but it sounds like I have have to mess around with different hardware.

[dickon]

Ah. Yeah, that's wrong. It still needs a bunch of blobs to get going, which aren't going to be released any time soon. Think of them as the equivalent of the BIOS on a PC.

[hippy]

From the Debian Wiki: "... We understand this computer no longer boots from the GPU, so it is probable it will no longer require a binary blob to boot."

The Pi 4B still boots from the GPU which runs its ROM bootloader code when it boots, what that ROM bootloader does has changed.

Pre-4B the ROM code would load and execute 'bootcode.bin' from SD Card if it didn't choose to do anything else. The 4B does not load 'bootcode.bin' but executes what's in the Boot Eeprom.

Pre-4B the code to perform USB or network booting had to be in the on-chip ROM. That code has migrated into the Boot Eeprom for the 4B.

So it's still closed-source binary blobs, it still boots from GPU, just that the ROM code presumably became less, what is no longer in that ROM code and what was in 'bootcode.bin' has moved to being in Boot Eeprom.

[jamesh]

More information here https://www.raspberrypi.org/documentati ... teeprom.md

[za3k]

> From the Debian Wiki: "... We understand this computer no longer boots from the GPU, so it is probable it will no longer require a binary blob to boot."

To clarify, if you read the rest of the page the intent is really to write "We understand this computer no longer boots from the GPU, so it is probable it will no longer require a binary blob [in our distributed SD card] to boot.". Which, at least the second half is true. Really the fix here is to clarify that there are two bootloader stages, which is consistently skipped on the page.

For context, I believe Debian has a policy around only distributing only open-source code, but as far as I know none against supported closed BIOS eeproms. So presumably the Raspberry Pi 4 is the first hardware where Debian could distribute a version that runs on Raspberry Pi 4, separate from the Raspbian project. (whose distro is identical except the inclusion of a .bin, AFAIK, but I'm no expert).

[trejan]

To clarify, if you read the rest of the page the intent is really to write "We understand this computer no longer boots from the GPU, so it is probable it will no longer require a binary blob [in our distributed SD card] to boot.". Which, at least the second half is true. Really the fix here is to clarify that there are two bootloader stages, which is consistently skipped on the page.

The equivalent of the bootcode.bin 2nd stage bootloader is stored on the onboard EEPROM now on a Pi 4 but you still need the big start4.elf firmware binary that runs on the VPU.

A completely open source binary blob free Pi isn't possible yet and I doubt it will be anytime soon. The open source Pi firmware project is on indefinite hiatus and targeted an old Pi SoC with a lot of hardware support still missing.

[cleverca22]

The Pi4 is OTG able?

Yes

and i can confirm that usbboot does indeed work, but only if the SPI firmware fails its validation check

The equivalent of the bootcode.bin 2nd stage bootloader is stored on the onboard EEPROM now on a Pi 4 but you still need the big start4.elf firmware binary that runs on the VPU.

A completely open source binary blob free Pi isn't possible yet and I doubt it will be anytime soon. The open source Pi firmware project is on indefinite hiatus and targeted an old Pi SoC with a lot of hardware support still missing.

i am able to execute custom code on the rpi4, from both the bootcode.bin stage (recovery/spi/usb-device) and the start4.elf stage, but i have not yet found a way to enable the ARM cores, and DDR4 requires the closed-source bootcode.bin to be present in SPI currently

it is in my plans to have that kind of arduino level control, and i could do that now, if you wanted to entirely ignore the dram and arm core, you would be limited to 128kbyte for both your .text and variables