rpi-open-firmware VS rpi-open-firmware

Comment by the developer who attempted to create open firmware, https://github.com/christinaa/rpi-open-firmware/issues/37

> a lot of corners were cut to save time leading to what I believe is poor ARMv7+ Cortex IP integration (GIC, TrustZone, etc). So I stopped working on it. If those things were not the case (GIC working, "TZPCs" working, security working as intended, instead of NS forced to high on bridge, at least in my understanding) I would still work on it ...

ARM isn't a second class citizen on this platform, it's a third class citizen since BCM2709 (again this is an opinion) ... the features I wanted to tinker with the most are absent by design (cutting corners) and I'm not willing to resort to SW emulation of them through clever uses of the VPU.

Sure, and it's been done: https://github.com/christinaa/rpi-open-firmware - but that doesn't involve ThreadX source, just some standard reverse engineering work. ThreadX is really the least interesting part of this whole operation in terms of the Raspberry Pi.

It's very cool that ThreadX has been open sourced as it offers an additional battle tested and mature alternative to FreeRTOS for new projects, but in terms of reverse engineering or open sourcing the Raspberry Pi VideoCore blob, it's pretty much a non-event IMO.

I guess you are thinking of this issue:

https://github.com/christinaa/rpi-open-firmware/issues/37

Since then the project moved to a new maintainer (not me), who worked on it slowly but surely. They need new contributors though.

They have (https://github.com/christinaa/rpi-open-firmware). The problem is that almost nothing works (no video or even USB). The sequel to "f you, NVIDIA": f you, Broadcom.

> no clue if there's a project to reimplement that

There was! And it even booted Linux in some capacity: https://github.com/christinaa/rpi-open-firmware

> every chip is very different from one another

Eh, the usual embedded SoCs are not that different from each other — ARM GIC, ARM timer, lots of Synopsys Designware crap for SDMMC/XHCI/PCIe/etc.

For many SoCs it's totally feasible to make standards-compliant firmware, e.g. for the Rockchip RK3566 there is https://github.com/jaredmcneill/quartz64_uefi

And SoCs from the networking world (Marvell, NXP) are typically supported by upstream EDK2.

from 2018: Is this project dead? KB - No not dead but on hold, see my response · Issue #37

https://github.com/christinaa/rpi-open-firmware/issues/37

> Please correct me if I'm wrong.

My memory told me it was the GPU that needed the blobs. So I asked at DDG

https://duckduckgo.com/?t=ftsa&q=binary+blobs+and+the+Raspbe...

Turned up this: https://wiki.debian.org/RaspberryPi and it says...

> All Raspberry Pi models before the 4 (1A, 1B, 1A+, 1B+, Zero, Zero W, 2, 3, Zero 2 W) boot from their GPU (not from the CPU!), so they require a non-free binary blob to boot

So the 4 (and I suppose the 5, if it ever actually comes...)

Goes on to say:

> Since then, Broadcom publicly released some code, licensed as 3-Clause BSD, to aid the making of an open source GPU driver. The "rpi-open-firmware" effort to replace the VPU firmware blob started in 2016. See more at https://news.ycombinator.com/item?id=11703842 . Unfortunately development of rpi-open-firmware is currently (2021-06) stalled.

So there you are. Not wrong, are you, but not strictly correct, depending on "...to run properly" definition

https://github.com/librerpi/rpi-open-firmware has updates 3-months ago

many of those demos work on the the entire pi model range

pi3 support is only broken due to arm side problems, which could be fixed by just using a different bootloader

and the https://github.com/librerpi/rpi-open-firmware codebase can already boot linux headlessly on both pi2 and pi3, it uses a different arm bootloader

Yes, and some folks are reverse engineering their stuff:

https://github.com/librerpi/rpi-open-firmware/

rpi-open-firmware: open-source VPU side bootloader for Raspberry Pi\ (35 comments)

There is work being done on the RPi4, for example the SHA1 HMAC protecting the boot on the RPi4 had to be cracked (and was easily), I hear future versions have RSA signing support, so the proprietary firmware might become mandatory at some point.

https://github.com/librerpi/rpi-open-firmware/blob/master/do...

There is a project to create an open source version of the proprietary GPU firmware that boots into the ARM processor:

https://github.com/librerpi/rpi-open-firmware

I note that even the Raspberry Pi is moving towards locked down devices, the RPi4 has an (easily cracked) HMAC blocking booting into the open source firmware and I hear more recent hardware editions have RSA signing support in the bootrom code.

https://github.com/librerpi/rpi-open-firmware/blob/master/do...