rpi-open-firmware
rpi-open-firmware copied to clipboard
christinaa
Is this project dead? [KB - No not dead but on hold, see my response]
Or is it still alive? It looks almost usable (except for USB), but since last commit is about a year ago I was wondering if 'almost' would mean 'never'.
I think it's waiting for someone to pick up the torch... i'm buried in nvidia land...
On Wed, Apr 25, 2018 at 8:33 AM, zeekoe [email protected] wrote:
Or is it still alive? It looks almost usable (except for USB), but since last commit is about a year ago I was wondering if 'almost' would mean 'never'.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/christinaa/rpi-open-firmware/issues/37, or mute the thread https://github.com/notifications/unsubscribe-auth/AQDAArfK_O3OMgMEJVgSS938NQ0-OYk_ks5tsG0mgaJpZM4TjVmE .
It's not being developed but it's not dead. Please read this fully as to why this project isn't dead.
I don't like Broadcom's approach to this, where in my personal opinion, 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, and if Broadcom does release a new SoC with all that addressed (Maybe they already have, I haven't really kept track?) I'll likely work on it again.
ARM isn't a second class citizen on this platform, it's a third class citizen since BCM2709 (again this is an opinion). This project was fun and goal was achieved. I'm not really the project lead or contributor anymore, if someone knowledgeable wants to see it through, I'd be more than happy to pass the leader role and help them get started. It's possible that their new (?) SoC has that all fixed, in which case, if someone can validate that at least GIC is working correctly as intended on ARMv8 platforms, I'll also gladly continue working on this.
Until then, I really don't see the point, 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. I've updated the README to make it more obvious with reference to this issue for details, hopefully this will prevent more confusion.
I do apologize, I know many have been interested in this, please realize that this takes a tremendous amount of effort and stress which I can't conjure up for a hobby project without being interested in it myself.
Thanks for the explanation. I'm very well aware of this being a huge effort project. It's just that I didn't read anywhere an official "closing" message for this project. I'm looking for the most open, not too expensive, SBC. Since for Raspberry Pi there's lots of community support, that would be the best bet. However, I had some troubles with the blobs in the past and I don't like them being closed away. Guess I'll surely have to look further reading your in-depth info on the chip. ;)
Just out of curiosity, @christinaa, now that you mention that the Rapsberry Pi doesn't really have the features you need, have you found a board that does? I, like @zeekoe, have looked for a decent and completely open SBC, with no luck. The closest to a completely open ARMv8 board seems to be the Raspberry Pi 3, despite it not being 100% open, and it's only because of the community (see: this repository :D). The worst offender is usually the GPU.
Virtually any AArch64 SoC that's not made by Broadcom with a GPU and doesn't lock down TrustZone and leaves OTP unprogrammed for most part. Look into sunxi.
@christinaa what about Marvell's Armada 37xx and 7/8k? They are not friendly about releasing doc, but they are releasing full ARM trust-zone and u-boot sources so you can rebuild everything from scratch and I guess also flash to devices (boards like EspressoBin and MachiatoBin). Not sure if this is what you call "no lock down TrustZone and OTP unprogrammed". Thanks!
If you start in AArch64 mode you should be in secure mode at the highest privilege level (EL3 Monitor) or in AArch32 the Secure Monitor Mode (Providing the platform allows you to switch to AArch64 somehow, which is tricky since you need to have started in AArch64 state, though some vendors have bypasses by soft resetting the ARM core for example, really depends on the SoC).
Anything other than either that or starting in secure supervisor mode or there being no OTP key flashed and you being free to just fakesign your bootloader, assuming the ROM allows that, is not something I would consider getting but that is my personal opinion as I have an interest in the technology (keep in mind that half of TZ features have to be implemented by the SoC vendor including secure interrupts and TZPCs). That is the case for NVIDIA Tegra devkits which are quite pricey and lots of sunxi chips where you usually don't get devkits that are preprogrammed to run securely at all (you start in secure mode but it doesn't work correctly until you blow a certain eFuse).
If you start in hypervisor or supervisor mode then the ROM code or the (likely signed) SPL have locked down that mode at which point your only hope is a software/hardware bug to glitch the ROM/SPL into executing code in secure context via a malformed SMC for example.
Not sure if it's still actual, but I've been using Poplar from 96boards based on HiSilicon Hi3798C V200 SoC and I think this is what you might be interested.
Schematics and decent SoC datasheet are publicly available (https://github.com/96boards/documentation/tree/master/enterprise/poplar/hardware-docs). It also has excellent upstream bootloader support (TF-A with OP-TEE payload as BL32, U-boot (unfortunately network driver isn't up-streamed yet)) and basic mainline Linux kernel support. The bootrom jumps to l-loader (the first bootloader, which is stored on eMMC and which you can modify) and continue booting in EL3, so you can write to VBAR_EL3 the base address of your own custom vector table.
I respect your decision and thank you very much for your elaborate answer. Does the release of the new Raspberry Pi 4 change anything for you?
@igoropaniuk have you figured our what these bootrom binary blobs for(the ones preceding TF-A)? and can you live without them?
The bootrom jumps to l-loader i meant bootrom - binary blobs that precedes l-loader
"TZPCs" working, security working as intended, instead of NS forced to high on bridge
@christinaa, I'd say it's pretty strange that you find interesting to work on such things in a project like this. If you're interested to work on such things, you should be able to easily get a paid job in that area and help companies build locked-down ~~spying and privacy violating, beyond any user control~~ beautiful unicorn software.
Otherwise, if RaspberryPi's and their CPUs have stuff like TrustZone permanently disabled, that's absolutely great news, meaning that you can take any RaspberryPi-based product, throw out its vendor crapware, and replace with open software. I thought that would be a motivation to work on a project like this.
@IdeaHunter
I'm not sure I understood you correctly, but BootROM by definition is something that is flashed to OTP memory during the factory provisioning, so obviously you can't avoid it.
For example, for AArch32 mode boot, the OTP memory, where the BootROM is flashed, should be mapped to 0x00000000 or 0xFFFF0000 (depends on SCTLR.V value, which sets the location of the reset vector). In general, it does primary initialization of vector tables (Secure VBAR, VBAR, HVBAR and MVBAR), enables async exceptions, inits registers, configures MMU and clears/invalidates caches.
Also sometimes it has some basic FAT support (where it pull the TF-A binary from) and minimal RSA crypto stuff for verifying signatures(if your SoC is Secure-boot-enabled).
I hope this is what you were asking about :)
@igoropaniuk oh, whow, thanks, you have a big insight in bootrom - no question here. In my case i seems like can avoid bootrom altogether because somehow my bootrom goes on the flash same way as it goes for l-loader and TF-A(i can be mistaken but this is only plausible explanation i can get about 2 mysterious binary file that got flashed on my board before loading) https://www.96boards.org/documentation/consumer/hikey/hikey970/installation/board-recovery.md.html#run-the-script-to-initially-prepare-fastboot https://github.com/96boards-hikey/tools-images-hikey970
Also string literals in blob fit one to one with your description of what bootrom is supposed to do. If it not a secret then where did you get all this info arm bootrom? or at least info about what you should have initialized via bootrom to make sure cpu doesn't go bananas?
Ah, ok, you're talking about Hikey970. AFAIK, there is no any sec_usb_xloader.img binary on Poplar.
@vchong any ideas regarding the binary and what it is supposed to do?
If it not a secret then where did you get all this info arm bootrom? or at least info about what you should have initialized via bootrom to make sure cpu doesn't go bananas?
It's publicly available here http://infocenter.arm.com/help/topic/com.arm.doc.dai0527a/DAI0527A_baremetal_boot_code_for_ARMv8_A_processors.pdf
@igoropaniuk @IdeaHunter The bootrom is still there. These images are for the lack of a better term helper or extension images for the bootrom, but the sources are not available. For more possibly related info see https://discuss.96boards.org/t/what-is-hikey960-mechanism-of-booting/2516. Please note that the previous comments actually apply to the hikey960, NOT hikey970, but I ASSUME they work on similar premises.
with pre- bootcode.bin now in eprom, and an "updater" or reflasher image being available for the eeprom, does this enable things to be setup anyway thats required could the cpu be brought up in aarch64 mode and be less of a third class citizen ?
if this repo is ported to the rpi4 (at a minimum, i think the dram controller code would have to be overhauled), you could put the entire bootcode.bin this project generates into the SPI chip
then it will always do whatever is under arm_chainloader/ on bootup, without needing any blobs on the SD card
(ive not yet investigated what arm_chainloader/ does exactly, but the readme implies it can boot linux
so you could get custom firmware, in the SPI chip, that just boots a linux kernel from the SD card)
edit:
upon reading the source, it looks like it loads cmdline.txt, rpi.dtb and zImage from the SD card, and then executes the kernel
so, with proper porting to the rpi4, you could have a modified rpi, that just reads those 3 files from the SD card, and boots, and every piece of software you can change is open
only blob that remains, is the mask rom
Why is there problem with wrong startup mode of the ARM cores? Doesn't the maskrom code run on the VPU?
@christinaa, I realize you're in a bit of a holding pattern with this project but I stumbled across a Raspberry Pi Videocore IV Vulkan driver work in progress. This appears to be in active development. Would this help your project at all?
That project is distinct from efforts to create a fully open source Vulkan driver for the Videocore VI (BCM2711) found on the Raspberry Pi 4, which you also may have heard about.
Just thought i'd mention; cleverca22 has continued this work with a gusto. You can catch him in #raspberrypi-internals on freenode irc.
On Wed, Feb 12, 2020, 12:21 AM gitjeff2 [email protected] wrote:
@christinaa https://github.com/christinaa, I realize you're in a bit of a holding pattern with this project but I stumbled across a Raspberry Pi Videocore IV Vulkan driver https://github.com/Yours3lf/rpi-vk-driver work in progress. This appears to be in active development. Would this help your project at all?
That project is distinct from efforts to create a fully open source Vulkan driver for the Videocore VI https://www.zdnet.com/article/raspberry-pi-4-graphics-win-open-source-vulkan-driver-support-is-coming/ (BCM2711) found on the Raspberry Pi 4, which you also may have heard about.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/christinaa/rpi-open-firmware/issues/37?email_source=notifications&email_token=AEAMAAXAKRLXJ2T32LGKPHDRCMXILA5CNFSM4E4NLGCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELOQDGQ#issuecomment-584909210, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEAMAAXRLKUUDZEWKS6YGUTRCMXILANCNFSM4E4NLGCA .
Just thought i'd mention; cleverca22 has continued this work with a gusto. You can catch him in #raspberrypi-internals on freenode irc.
@julialongtin That's on https://github.com/librerpi/rpi-open-firmware right?
It's not being developed but it's not dead. Please read this fully as to why this project isn't dead.
I don't like Broadcom's approach to this, where in my personal opinion, 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, and if Broadcom does release a new SoC with all that addressed (Maybe they already have, I haven't really kept track?) I'll likely work on it again.
ARM isn't a second class citizen on this platform, it's a third class citizen since BCM2709 (again this is an opinion). This project was fun and goal was achieved. I'm not really the project lead or contributor anymore, if someone knowledgeable wants to see it through, I'd be more than happy to pass the leader role and help them get started. It's possible that their new (?) SoC has that all fixed, in which case, if someone can validate that at least GIC is working correctly as intended on ARMv8 platforms, I'll also gladly continue working on this.
Until then, I really don't see the point, 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. I've updated the README to make it more obvious with reference to this issue for details, hopefully this will prevent more confusion.
I do apologize, I know many have been interested in this, please realize that this takes a tremendous amount of effort and stress which I can't conjure up for a hobby project without being interested in it myself.
I don't like Broadcom because one thing "not open to open source" but they give us source code to useless stuf- ... i don't think they have gave us any open source code that they made.
It's not being developed but it's not dead. Please read this fully as to why this project isn't dead. I don't like Broadcom's approach to this, where in my personal opinion, 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, and if Broadcom does release a new SoC with all that addressed (Maybe they already have, I haven't really kept track?) I'll likely work on it again. ARM isn't a second class citizen on this platform, it's a third class citizen since BCM2709 (again this is an opinion). This project was fun and goal was achieved. I'm not really the project lead or contributor anymore, if someone knowledgeable wants to see it through, I'd be more than happy to pass the leader role and help them get started. It's possible that their new (?) SoC has that all fixed, in which case, if someone can validate that at least GIC is working correctly as intended on ARMv8 platforms, I'll also gladly continue working on this. Until then, I really don't see the point, 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. I've updated the README to make it more obvious with reference to this issue for details, hopefully this will prevent more confusion. I do apologize, I know many have been interested in this, please realize that this takes a tremendous amount of effort and stress which I can't conjure up for a hobby project without being interested in it myself.
I don't like Broadcom because one thing "not open to open source" but they give us source code to useless stuf- ... i don't think they have gave us any open source code that they made.
Don't misunderstand me, I put the rocket emoji, not because I celebrate such insanity, but because you gave an answer that is completely on target...
Side note btw, I would really love it, if people could liberate some newer processors, based on newer ARM cortex cores...
Such as A75 for example?
Sounds like a dream right?
Probably is for the time being...
Better to have something while we wait for an extremely useful and non crappy risc-v or an extremely useful non crappy ultra lightweight OpenPOWER processor to appear, btw such an idea... IS happening, or I should say, it is being WORKED on...
https://github.com/antonblanchard/microwatt
;)
https://archive.fosdem.org/2021/schedule/event/switchtoopenpowerhardware/attachments/slides/4607/export/events/attachments/switchtoopenpowerhardware/slides/4607/Fosdem_2021_Switch_OH_PowerArchitecture.pdf
https://www.phoronix.com/scan.php?page=news_item&px=OpenPOWER-Microwatt-Fab
https://www.powerpc-notebook.org/
Risc-V is also a given though...
Btw, I will end this comment by saying:
Proprietary is no different then all of the things simunateously at once:
Bloatware + Malware + DRM + Insecurity + Other Bad Stuff
Thus, broadcom as well as other heavily proprietary companies who make open source, let alone libre software, nearly impossible,
They should treated with the respect they deserve:
That respect?
Out of 100,
-100
If you want newer processors powerpc-notebook is not where to look. Raptor Computing makes some workstations and servers based on current day PowerPC chips.
Asahi Linux project aims to run Linux on Apple M1 which is a modern ARM implementation. Just like Broadcom Apple does not give useful source code, though.
If you want newer processors powerpc-notebook is not where to look. Raptor Computing makes some workstations and servers based on current day PowerPC chips.
Asahi Linux project aims to run Linux on Apple M1 which is a modern ARM implementation. Just like Broadcom Apple does not give useful source code, though.
Actually, it is in development, that Google, is funding the idea of ultra lightweight processors based on powerpc and supposedly, they want them completely open source.
As for Apple, agree with you there, they are untrustworthy, when I said newer in the case of ARM, I meant based on A75 or A76, anything newer, is unlikely to be broken into, for an extremely long time.
;)
That being said, lightweight powerpc chips are a LONG way off, for now, as far as I know,
Unless, https://libre-soc.org gets a speed boost and doesn't fail like the last project they did...
I dunno if I completely trust them, but I am watching every so often, out of curiosity...