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 · 9 comments

Comments

Projects
None yet
6 participants
@zeekoe
Copy link

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

This comment has been minimized.

Copy link
Collaborator

julialongtin commented Apr 25, 2018

@zeekoe

This comment has been minimized.

Copy link
Author

zeekoe commented Apr 27, 2018

Thanks! Good to know.

@christinaa

This comment has been minimized.

Copy link
Owner

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Owner

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

This comment has been minimized.

Copy link

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

RPi3: implement power-off
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

This comment has been minimized.

Copy link
Owner

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

This comment has been minimized.

Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment