[christina_b]

>unlocking the unique video core to get anywhere near there

We actually have documented most vector instructions of VC4 and Julian's toolchain supports pretty much all documented ones, so the toolchain we have is pretty close to what Broadcom would have with their MetaWare compiler for VC4.

>The RPI3 is rated for 24GFLOPS

You mean the VPU, we also have QPU and ARM on the side.

>so many really weird abnormal subsystems

True that, lack of TZPCs, ARM AxPROT[1] being forced to high causing all ARM accesses to be insecure on AXI even in secure monitor mode (sadness), lack of a GIC. I could go on and on about what's wrong with BCM283x family but hey at least it's interesting.

>But I am sincerely impressed and it has been amazing work slowly wrangling this abomination into order.

Thank you ^^

[trome]

You are fighting the good fight, freeing one of the most common single board computers! That being said, besides quantity, why focus on the Raspberry Pi instead of Allwinner H3 based boards or another board where most of the support (including uboot) is already upstreamed & can be run with a fully libre stack?

[christina_b]

If a "development" board does not let me run my own code in EL3 (Secure monitor mode), I'm not buying it, as simple as that. A lot of boards that use Allwinner chips will use a signed bootloader that exits secure mode before passing control to your code.

My favourite is probably NVIDIA Jetson TX1 where development boards do not have a key fused in them and have documented TrustZone peripherals, so you're free to run your own secure monitor.

Sadly while ARM on rPi does start in secure mode, it lacks any secure peripherals (AxPROT[1] is forced to high so even if ARM is in secure mode, it cannot make secure bus transactions) but it's mostly a matter of principle of being able to have ARM code run in EL3 for me.

The entire point of a development board is to be able to mess around with it, I'm not wasting my time on boards with locked down features.

[makomk]

I didn't even know Allwinner supported secure boot, and it's certainly not widely used as far as I know. Running your own code in EL3 is pretty standard there because it's the mode when the ROM bootloader hands over control to the user-provided bootloader. You sure you haven't confused them with one of the other manufacturers?

[christina_b]

All modern ARM chips support secure mode, it's a set of modes, in AArch64, we colloquially call them EL3 (Exception level 3, highest privilege level above EL2, the hypervisor level).

Most ARM cores start in secure supervisor mode, which can transition to secure monitor mode at will (secure monitor being a special version of secure supervisor). Most bootloaders including Allwinner's will exit secure mode by setting the NS bit in SCR and therefore enter user provided code in non-secure supervisor (or hypervisor mode) which would be called EL1 (or EL2 for hypervisor) on AArch64.

EL3 has nothing to do with ROM or Allwinner or anything else, it's an execution mode defined by ARM themselves, the core is reset in that mode.

(Secure mode is also known as TrustZone, if that term seems more familiar though TrustZone is usually "the whole package" including support from the CPU and the corresponding peripherals)

[makomk]

Well, of course they support secure mode/EL3, it's just not exactly secure on any Allwinner-based system I'm aware of because the ROM bootloader will happily load any chunk of code yo choose to supply into RAM from the boot device and jump to it whilst still in EL3, without any signature checks. Allwinner really don't seem to be keen on locking their chips down.

[christina_b]

Hm, I may have been wrong, would be nice to have someone who owns one of these boards to verify that:

1). The first stage bootloader doesn't require signing.

2). The first stage bootloader starts in EL3 mode (ie. BootROM doesn't exit it like it did on some OMAP dev boards)

[trome]

Uhh, the H3 has supports TrustZone and has an efuse that is unset but can be burned with a signature, so its supportable in that regard.

[niftich]

With this bootcode.bin running on the VPU, after the ARM starts up and Linux is loaded, does the VPU halt and remain unreachable, or does the "normal" VC4 RTOS execute such that stuff from the ARM can be mailboxed to it?

[christina_b]

Currently it sleeps and waits for a mailbox interrupt after which it acks it and goes back to sleep. We're planning on using the interface to load a second stage firmware that would emulate the closed source firmware's power/clock management interfaces (but not framebuffer/PV/HVS/HDMI related stuff since there are Linux drivers for that now).

[BuuQu9hu]

Which toolchain are you using? binutils/GCC or LLVM? Is the code for that upstream?

[christina_b]

binutils/GCC, have Julian to thank for his wonderful toolchain: https://github.com/puppeh/vc4-toolchain