rpi-open-firmware VS Ansible

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

I use some Pis for various things in my house including Zeroes through CM4s and 4Bs.

The Zeroes run Raspbian configured with the read-only filesystem option. I have found it necessary to uninstall `unattended-upgrades` because the overlayfs employed for read-only root caches disk writes in RAM and the update/upgrade process exhausts RAM. For the same reason I disable swap. It makes no sense to swap to RAM on a 512GB system.

Upgrades are tedious since they require disabling overlayfs, rebooting, upgrading, rebooting, and enabling overlayfs. I wrote Ansible playbooks to perform these tasks. (https://github.com/HankB/Ansible/tree/main/Pi)

I have a Pi 4B performing as a file server and running Debian (not Raspbian) It boots from an SD card so that the entire HDDs can be used for a ZFS pool. To reduce wear and tear on the SD card I have mounted `/var` to a ZFS filesystem. I should probably use `tmpfs` for `/tmp`.

I use a Pi CM4 to run HomeAssistant and that boots and runs from an NVME SSD where durability is less an issue.

Nice. I've written some playbooks for my herd of Pis as well. (https://github.com/HankB/Ansible/tree/main/Pi) I dropped by mainly to say "well done!"

I use Ansible for a lot of repetitive tasks on R-Pi OS - mostly for a bunch of zeroes. https://github.com/HankB/Ansible/tree/main/Pi I haven't bothered automating stuff on Debian but it could be done.

I've been using Ansible to configure Pis instead of the imager just because I've done it manually in the past and just automated that process. https://github.com/HankB/Ansible/blob/main/Pi/provision-local.yml

I've started employing the readonly configuration available in raspi-config for systems that don't require writable storage. I've written some Ansible playbooks to make that a little more convenient. https://github.com/HankB/Ansible/tree/main/Pi On Pi 3/4 I usually use an SSD but I have a few zeroes that are more or less IoT devices and run from SD cards.

Yes, thanks - I meant to. https://github.com/HankB/Ansible/blob/0c4a1bce42f84acc4176624fed671ee460c683a6/Pi/provision-local.yml

At one point (well before I finished the series) I decided to start doing rather than continue learning. My results have been very satisfying. (https://github.com/HankB/Ansible *) When I want to perform some task that I'm not familiar with, I check the online manual and/or search for examples. In that way my learning is more self directed. I do plan to get back to watching the series at some point but in the mean time my learning is more goal/self directed. I'm over the hump and at the point where Ansible is a useful tool. (I did not have any experience with other automation tools such as Chef or Puppet and my prior experience is as a S/W developer and not an administrator.)