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

[zeekoe]

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]

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 ***@***.***> 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 <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQDAArfK_O3OMgMEJVgSS938NQ0-OYk_ks5tsG0mgaJpZM4TjVmE> .

[zeekoe]

Thanks! Good to know.

[christinaa]

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.

[zeekoe]

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]

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]

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]

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

[christinaa]

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]

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]

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]

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

[igoropaniuk]

@IdeaHunter you mean https://github.com/96boards/l-loader ?

[IdeaHunter]

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