
Minimal Raspberry Pi VPU firmware - swiley
https://github.com/christinaa/rpi-open-firmware/blob/master/README.md
======
mrlambchop
I wrote the BootROM and 2nd stage loader used in VC3 and VC4 - way back in
~2005. And the interrupt controller, VPU sync block and various other things
used in this open FW.

This is pretty awesome to see how much context the community has reverse
engineered from the design - I remember making the first BCM2835 based project
(the Roku 2) and spending _A LOT_ of time getting the ARM to startup reliably
and boot into Linux as fast as possible. I've spotted 2 concepts in the open
FW so far that misunderstood the implementation of the HW but are still
working which is fun!

One advantage of the having the GPU start first (maybe the only advantage :)
is that it can play a video for a splash screen instead of a static image. If
you've ever used a Roku 2/3 or newer, this is a feature I hacked together for
a demo to hide boot-up latency - now its a standard part of RokuOS (and is
quite hard to replicate on traditional ARM/MIPS SoC's).

~~~
gh02t
I'm guessing you had privileged access to the datasheets for those chips and
you're not legally allowed to tell them what they misunderstood? I imagine I
would feel super weird seeing something being done wrong but not being allowed
to tell someone. I mean I understand why, but it'd be frustrating.

~~~
mrlambchop
Well, I wrote the RTL as well as implemented the SW so I guess I do have
propriety information on the topic...

In theory, all the code and sequences for the BootROM, 2nd stage, ARM loader
and peripheral control functions is available by disassembling the binaries
(and extracting some code from the ROM with a mempcy) - it just requires
reverse engineering / re-implementing inside and this is part of the fun / why
this project is so great.

I might suggest they poke at the linux port and u-boot of the BCM2835 from
Roku however :)

------
loonattic
If this matured, maybe there would be some interest in porting OpenBSD to RPi
with this? Theo didn't like the firmware blob, right?..

~~~
justin66
An openbsd port is already underway.

------
erikb
What can one do with it? Is it like a bootloader? Sorry really not enough
know-how.

~~~
david-given
The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the
side. At power on, a boot ROM loads an embedded OS image into the VC4
processor. That then sets up the hardware, powers up the ARM, and loads the OS
image into _that_. The VC4 then continues running in the background servicing
RPCs from the ARM.

What this is is a replacement VC4 operating system image which just fires up
the ARM with an embedded image, sets it running, and then halts (assuming I'm
understanding the docs correctly); so it can't (yet) actually load an OS into
the ARM from disk or respond to RPCs etc.

In practical terms, this is the biggest, most difficult step forward towards
running an almost completely open system on the RPi. (It could also be used as
the core of a proper operating system running on the VC4 itself, which could
be rather interesting.)

~~~
wyldfire
> The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on
> the side.

I knew that the bootloader worked that way but didn't think of it being that
way until reading your comment. Interesting to think of the hierarchy that
way.

Naively this makes me think that the ARM ISA could use something like UEFI (or
BIOS) to unify the devices' bootstrapping logic around some common metaphor.

~~~
david-given
Well, the ARM is _literally_ powered down until the VC4 turns it on.

(I've heard that the only reason the ARM is there at all is that Broadcom had
a royalty-free license and there was some spare silicon, so they thought, hey,
why not, it might be useful...)

Traditionally ARMs have never used any kind of common boot process because
they come out of the embedded world where every system is bespoke --- the
focus is always on individual products, rather than building a platform.

There have been various efforts to fix this but AFAIAA they've never come to
much. I think the current one is DeviceTree, but I don't believe there's much
vendor support.

~~~
yalogin
> Traditionally ARMs have never used any kind of common boot process because
> they come out of the embedded world where every system is bespoke --- the
> focus is always on individual products, rather than building a platform.

This is something I did not know. In the mobile world the boot happens in the
UEFI mould right? So when someone licenses from ARM they get to design their
own boot sequence?

~~~
nanolith
Well, it's two different use cases. PCs are platforms, and they have common
components and optional peripherals. Embedded systems are completely custom
designs that rarely have common components. Everything is driven by BOM cost,
and if you don't need something, you don't add it.

Booting such a system is highly dependent upon the board configuration and the
peripherals that are needed. Furthermore, vendors have different boot-up
requirements. Some boot loaders perform proprietary system checks before
loading the RTOS. Some boot loaders need to be able to upgrade firmware from
an image on-chip, in flash, or fed into it over SPI or a UART. Some boot
loaders are little more than a jump table decoder that just jumps to the
currently active firmware image on the chip. Creating a universal boot loader
with enough flexibility for each of these situations is harder than just
implementing a boot loader for a particular electronics product or product
family.

~~~
david-given
There's a bit of a trend to embed a tiny ROM in the processor itself that's
got just enough intelligence to bootstrap an image off various peripherals.

The Broadcom parts work like this for the VC4; the boot ROM can talk to an SD
card, parse a FAT filesystem, and load and run the second-stage loader
(bootcode.bin). But Allwinner chips do this too, and they're even smart enough
to try several different media types (including SATA, IIRC!). Ditto Tegra
parts.

I imagine that if you're a major customer you get to choose the contents of
the boot ROM.

From a hacker perspective, it's brilliant, because the devices are completely
unbrickable. It doesn't matter how broken they get, you can't change the ROM,
which means that you always have ability to get something working. But, of
course, they all have entirely different APIs. The VC4 just dumps an image
into memory, sets a couple of registers, and jumps to it, and I imagine the
others all do the same thing.

~~~
koytch
The only upside of this is unbrickability. Having the boot ROM inside the CPU
means you are stuck forever with whatever bugs there are in it. Been there.

------
RossBencina
I have a vague hope that one day the dual-core VPU on the Pi will be usable
for time-critical real-time i/o in much the same way as the PRUs on the BBB
are used.

------
rcarmo
Nice. There's an Inferno port to the Raspberry Pi that could be made even
smaller by using this (I suppose): [http://lynxline.com/projects/labs-
portintg-inferno-os-to-ras...](http://lynxline.com/projects/labs-portintg-
inferno-os-to-raspberry-pi/)

------
2bluesc
NuttX would be interesting on a raspberry pi. Much lighter weight then Linux
but still implements POSIX like interfaces. The POSIX stuff always felt to
clunky for a microcontroller, but rPi might be just right.

While a port has been discussed, I don't think a port has been completed.

~~~
zokier
I wonder what sort of practical benefit there is for the "lighter weight" of
NuttX? I imagine the main attraction is realtimedness, but I think that is
sort of orthogonal to light-weightness. And even then it has rtlinux to
compete with.

