rpi-open-firmware
quartz64_uefi
rpi-open-firmware | quartz64_uefi | |
---|---|---|
6 | 5 | |
1,117 | 141 | |
- | - | |
0.0 | 7.3 | |
about 2 years ago | about 2 months ago | |
C | C | |
GNU General Public License v3.0 or later | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
rpi-open-firmware
-
Considerations for a long-running Raspberry Pi
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.
-
Microsoft opens sources ThreadX RTOS used in Raspberry Pis
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.
-
LibreRPi โ open source replacements for RPi firmware
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.
-
Using my homemade linux laptop my 70's terminals are able to connect to the interwebs!
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.
-
SoftBank's Sale of Arm to Nvidia Collapses, Arm to IPO
> 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.
-
rpi-open-firmware: open-source VPU side bootloader for Raspberry Pi
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
quartz64_uefi
-
NetBSD on Pine64 SOQuartz
I have a follow up on this post... i have tried several different eMMC modules (from Pine64 and Hardkernel), I have tried different carrier boards, and different power supplies. The issue remains - UEFI on the SDcard and an NetBSD-current generic 64bit (from armbsd.org) - the eMMC continues to be write-protected. This might be a huge ask, but is there anyone out there with: * a SOQuartz module * an eMMC module containing the NetBSD-current generic 64-bit image * Jared McNeill's quart64 UEFI on an SDcard * an official raspberry pi compute module carrier board who could try this out?
1) uefi (https://github.com/jaredmcneill/quartz64_uefi) on sd card, NetBSD Generic Arm 64-bit image (https://nycdn.netbsd.org/pub/arm/HEAD/202211221110Z/NetBSD-HEAD-aarch64-202211221110Z-generic.img.gz) on eMMC.
-
NetBSD port-arm Pine64 SOQuartz Module Question
Take one of the images from https://github.com/jaredmcneill/quartz64_uefi/releases and write it to an SD card.
-
SoftBank's Sale of Arm to Nvidia Collapses, Arm to IPO
> 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.
-
Pine64 should re-evaluate their community priorities
>> As one example, we could be installing the Linux distribution of our choice on the Pinebook Pro using a standard aarch64 UEFI ISO installer, just like we do for any other laptop, if someone spent a couple of weeks upstreaming the last 6 patches to mainline Linux and put together a suitable u-Boot payload to flash on the SPI flash chip. But, instead of one working solution for everyone, we have 20+ Linux distros publishing Pine64-specific images to flash to microSD cards.
I think this is a key part of the problem and is not unique to Pine64 devices, but the ARM ecosystem as a whole.
There needs to be more funding and focus drawn towards standards compliant firmware. U-Boot is great, but it tends to lead to lots of unique distribution-specific problems as Drew points out here.
We have the SBBR and UEFI standards for ARM, but it needs to be more widely built out for consumer devices and not just servers.
Here is one key piece of work that NetBSD maintainers are working on: https://github.com/jaredmcneill/quartz64_uefi
What are some alternatives?
tl - The compiler for Teal, a typed dialect of Lua
aws-graviton-getting-started - Helping developers to use AWS Graviton2 and Graviton3 processors which power the 6th and 7th generation of Amazon EC2 instances (C6g[d], M6g[d], R6g[d], T4g, X2gd, C6gn, I4g, Im4gn, Is4gen, G5g, C7g[d][n], M7g[d], R7g[d]).
rpi-open-firmware - Open source VPU side bootloader for Raspberry Pi.
videocoreiv - Tools and information for the Broadcom VideoCore IV (RaspberryPi)
rpi-open-firmware - Open source VPU side bootloader for Raspberry Pi.
serverlessui - A command-line utility for deploying serverless applications to AWS. Complete with custom domains, deploy previews, TypeScript support, and more.
ArduinoCore-mbed
lk-overlay