rpi-open-firmware VS sbts-aru

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

Unfortunately a Raspberry Pi is a bit ill suited for production environments. Id recommend an RTC module. Otherwise this might be helpful: https://github.com/hcfman/sbts-aru

If you install my sbts-aru project

https://github.com/hcfman/sbts-aru

It will shrink your partitions, add news and install one of these and set up a sub micro second system clock and an audio recorder suitable for sound localization with a single install command.

I recommend primo EM272 microphone capsules for use with https://github.com/hcfman/sbts-aru. They are high quality, very sensitive with high signal to noise ratio, lauded for nature recording use cases. They can be bought assembled for around 65 euros in the Netherlands. However these capsules are often found in much more expensive equipment.

My sound localizing Raspberry Pi installs a resilient base system as part of its install.

https://github.com/hcfman/sbts-aru

https://hackaday.com/2023/12/30/localizing-fireworks-launche...

With one command it for all Pi’s for both Raspbian and bookworm it:

* Shrinks the file system (Gee, how does it do that with just one disk ? ;-) )

I have a sound localization project that can help with that

https://github.com/hcfman/sbts-aru

You need to be able to hear the sound from three or more recorders. And normally localization is better within the polygon of microphones but there’s an area of better localizability extending outside of a vertex.

Interesting history!

And while we are in the subject of sound localizing may I take the liberty of introducing my new raspberry pi sound localizing audio recorder.

https://github.com/hcfman/sbts-aru

It installs with one command on all Raspberry Pi versions and synchronizes the system time to less than 1 microsecond of error with a cheap GPS.

With three of these I’ve been able to sound localize the explosions from illegal fireworks to a specific car park from more than 3km away with lots of houses in between.

When I got to the car park I could smell the sulphur from the fireworks.

This will even run on a Raspberry Pi zero running of a battery with a 6 euro neo 7m gps and a 6 euro usb mic.

Very nice tool!

So grab a spare Raspberry Pi, a GPS, a cheap USB sound card and a mic and get recording with this Pi based Acoustic Recording Unit

https://github.com/hcfman/sbts-aru

And while you are at it, install 3x or more and localize where the birds are.

Sound localizing. I was intensely passionate about it when I saw the possibility to do it well on a Raspberry Pi. There were quite a few more problems than so expected which is why it took five months (of weekends) to complete it well.

But I’m super happy with the result and have a bunch of geeks with recording nodes setup a long distance apart. Localizing large explosions show that it’s possible to localize to a carpets even when some of the nodes are almost 5 away.

For those interested, here is the project:

https://github.com/hcfman/sbts-aru