Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is this project dead? [KB - No not dead but on hold, see my response] #37

Open
zeekoe opened this issue Apr 25, 2018 · 25 comments
Open

Is this project dead? [KB - No not dead but on hold, see my response] #37

zeekoe opened this issue Apr 25, 2018 · 25 comments

Comments

@zeekoe
Copy link

@zeekoe zeekoe commented Apr 25, 2018

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'.

@julialongtin
Copy link
Collaborator

@julialongtin julialongtin commented Apr 25, 2018

@zeekoe
Copy link
Author

@zeekoe zeekoe commented Apr 27, 2018

Thanks! Good to know.

@christinaa
Copy link
Owner

@christinaa christinaa commented May 12, 2018

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.

@christinaa christinaa changed the title Is this project dead? Is this project dead? [KB - No not dead but on hold, see my response] May 12, 2018
@zeekoe
Copy link
Author

@zeekoe zeekoe commented May 12, 2018

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. ;)

@AntonioND
Copy link

@AntonioND AntonioND commented May 13, 2018

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.

@christinaa
Copy link
Owner

@christinaa christinaa commented May 14, 2018

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.

@kgardas
Copy link

@kgardas kgardas commented May 31, 2018

@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!

satmandu referenced this issue in andreiw/raspberry-pi3-atf Jul 9, 2018
This implements "power off" (low power mode, really)
as per raspberrypi/firmware#1016 (comment)

GPIO3 low to turn it back on.

Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
@christinaa
Copy link
Owner

@christinaa christinaa commented Jul 25, 2018

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.

@igoropaniuk
Copy link

@igoropaniuk igoropaniuk commented Jan 24, 2019

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.

@Huii
Copy link

@Huii Huii commented Jun 25, 2019

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?

@IdeaHunter
Copy link

@IdeaHunter IdeaHunter commented Jun 25, 2019

@igoropaniuk have you figured our what these bootrom binary blobs for(the ones preceding TF-A)? and can you live without them?

@IdeaHunter
Copy link

@IdeaHunter IdeaHunter commented Jun 26, 2019

The bootrom jumps to l-loader
i meant bootrom - binary blobs that precedes l-loader

@pfalcon
Copy link

@pfalcon pfalcon commented Jun 30, 2019

"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.

@igoropaniuk
Copy link

@igoropaniuk igoropaniuk commented Jul 1, 2019

@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 :)

@IdeaHunter
Copy link

@IdeaHunter IdeaHunter commented Jul 1, 2019

@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?

@igoropaniuk
Copy link

@igoropaniuk igoropaniuk commented Jul 1, 2019

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

@vchong
Copy link

@vchong vchong commented Jul 1, 2019

@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.

@chriscamacho
Copy link

@chriscamacho chriscamacho commented Jul 26, 2019

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 ?

@cleverca22
Copy link

@cleverca22 cleverca22 commented Nov 30, 2019

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

@hramrach
Copy link

@hramrach hramrach commented Dec 12, 2019

Why is there problem with wrong startup mode of the ARM cores?
Doesn't the maskrom code run on the VPU?

@gitjeff2
Copy link

@gitjeff2 gitjeff2 commented Feb 11, 2020

@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.

@julialongtin
Copy link
Collaborator

@julialongtin julialongtin commented Feb 12, 2020

@mkesper
Copy link

@mkesper mkesper commented Sep 7, 2020

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?

@Dell-Glitch
Copy link

@Dell-Glitch Dell-Glitch commented Mar 15, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet