rpi-open-firmware VS ArduinoCore-mbed

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

UPDATE: I have been able to correct this problem by using a different boards core: the Arduino MBED RP2040 and now I can run multiple strips using FastLED and the Adafruit RP2040 Scorpio.

It is 100% real. He linked to the library on GitHub. https://github.com/arduino/ArduinoCore-mbed/tree/29d629061f840133e7a19e723fd0747dfce6fea4/libraries/doom

The Max Carrier "Getting Started" page says it allows interfacing with the M4 core. On the AruinoCore-mbed GitHub, it says that the code is ran by the M4 core on the STM chip. So not the M7 core on the same chip?

Yes, I was able to compile the blink example. I checked on the GitHub and it seems that the core does have Ble.h here but I don't know whether it exists in my local system.

Does anyone know how to get this to work? The only resource I have found is this thread on github, but the information there doesnt really help me at all... Minimal example of SPI for Portenta H7 · Issue #131 · arduino/ArduinoCore-mbed · GitHub

I stand corrected on the USB bit, actually -- it looks like you're using an alternate USB library which might avoid the licensing issue -- but some components of OpenAMP are provided under this license. Search for "SLA0044" to find the rest.

https://github.com/arduino/ArduinoCore-mbed/blob/e50ec8aa1b1...

Arduino has official boards running on STM32. Unfortunately for a lot of people "Arduino" means "Arduino UNO" which is an 8bit product while most of the products are now based on ARM Cortex M processors. Having said that, using the Arduino framework has a lot of benefits in terms of simplicity,code re-use and availability of libraries. There is a not so well know trick which allows you to run an official port of Arduino on any stm32 board which supports mbedOS : in this repo https://github.com/arduino/ArduinoCore-mbed you'll find a script called mbed-os-to-arduino that creates the Arduino port for the processor you're using. enjoy :)