Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Minimal Raspberry Pi VPU firmware

github.com

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Minimal Raspberry Pi VPU firmware

#41

Post by pcwalton »

david-given wrote: post #6
erikb wrote: post #2

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

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 embe…

Everyone says this setup where the VC4 boots the ARM is weird, but isn't that pretty similar to how Intel ME boots the x86, right down to the proprietary firmware and everything?

It doesn't seem like an unusual setup to me at all: the only unusual thing, I guess, is that the VC4 is capable of a lot more than the small ARC/ARM core inside Intel ME.

Re: Minimal Raspberry Pi VPU firmware

#42

Post by yellowapple »

pcwalton wrote: post #41
david-given wrote: post #6

Earlier quoted context omitted.

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 embe…

Everyone says this setup where the VC4 boots the ARM is weird, but isn't that pretty similar to how Intel ME boots the x86, right down to the proprietary firmware and everything? It doesn't seem like an unusual setup to me at all: the only unusual thing, I guess, is that the VC4 is capable of a lot more than the small ARC/ARM core inside Intel ME.

The main weirdness is that the VC4 is more of a GPU than a secondary CPU. It'd be like an Nvidia graphics card bootstrapping the actual CPU in an ordinary desktop.

Re: Minimal Raspberry Pi VPU firmware

#43

Post by pcwalton »

yellowapple wrote: post #42
pcwalton wrote: post #41

Earlier quoted context omitted.

Everyone says this setup where the VC4 boots the ARM is weird, but isn't that pretty similar to how Intel ME boots the x86, right down to the proprietary firmware and everything? It doesn't seem like an unusual setup to me at all: the only unusual thing, I guess, is that the VC4 is capable of a lot more than the small ARC/ARM core inside Intel ME.

The main weirdness is that the VC4 is more of a GPU than a secondary CPU. It'd be like an Nvidia graphics card bootstrapping the actual CPU in an ordinary desktop.

Agreed that this is odd. But that's just a difference in the capabilities of the bootstrap core: Intel uses a less powerful ARC or ARM core, while Broadcom uses a more powerful core that also functions as a GPU. The mechanism is the same.

There isn't a fundamental difference in how Intel CPUs start up and how the Raspberry Pi starts up, as I sometimes see people implying.

Re: Minimal Raspberry Pi VPU firmware

#44

Post by david-given »

makomk wrote: post #35
david-given wrote: post #6

Earlier quoted context omitted.

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 embe…

In practical terms, this seems to be quite a long way from running a completely open system - the VC4 is responsible for initializing a whole bunch of critical and I believe undocumented hardware that's required to enable any of the peripherals, and this doesn't. Basically, a whole bunch of stuff that'd be implemented by drivers on (say) most Allwinner SoCs I've looked at instead relies on the blob. This is probably…

I've written some bare-metal stuff on the Pi (somewhere I've got a 90% finished port of Fuzix for it), and oh god yes, that's so true. Being able to do complex stuff like set up a framebuffer by making a simple RPC call to the VC4, passing in a pointer and a descriptor block saying 'this big, please', is so much better than having to do it yourself.

But this firmware doesn't contain code to initialise the GPU, it does contain initialisation code for one rather important peripheral, which is the DRAM. The VC4 has been pretty well reverse engineered for a while (I did one of the early C compiler ports for it), but the big missing piece was figuring out how to initialise the RAM. Without that, everything had to fit in the 128kB of built-in SRAM.

This firmware's a huge step forward.

Re: Minimal Raspberry Pi VPU firmware

#45

Post by david-given »

yellowapple wrote: post #42
pcwalton wrote: post #41

Earlier quoted context omitted.

Everyone says this setup where the VC4 boots the ARM is weird, but isn't that pretty similar to how Intel ME boots the x86, right down to the proprietary firmware and everything? It doesn't seem like an unusual setup to me at all: the only unusual thing, I guess, is that the VC4 is capable of a lot more than the small ARC/ARM core inside Intel ME.

The main weirdness is that the VC4 is more of a GPU than a secondary CPU. It'd be like an Nvidia graphics card bootstrapping the actual CPU in an ordinary desktop.

That's not quite right. The Pi has a completely separate GPU unit. The VC4 is different, and is a pretty normal processor, although it's got a pile of DSP addons.

The instruction set's here:

https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...

...but to summarise:

- 32 registers which can hold either integers or 32-bit floats;

- ARM-like 32-bit 3op instructions, with a limited set of 16-bit 2op instructions;

- integrated 32-bit floating point instructions, using the same registers as everything else;

- some 48 bit instruction forms (allowing a full 32-bit payload! No ghastly ARM constant pools or PowerPC-style split payloads!);

- two cores, with integrated interrupt handler;

- integrated DSP with 80-bit vector instructions working on a 64x64x8bit vector working area, which TBH looks like it was stolen from another processor completely and which I frankly don't understand;

- ARM-style conditional execution (for some instructions);

- ARM-style multiregister loads and saves (and pushes and pops);

- DSP-style saturated arithmetic and fixed-point support;

- no ALU-setting-condition-flags instructions, or add-with-carry or subtract-with-carry operations, which makes 64-bit arithmetic really painful (if you need cmp to set the condition flags, what's the carry flag even for?)

It's actually a really nice thing to write assembly for. It's orthogonal enough to be understandable, while quirky enough to allow some really satisfying optimisations. e.g. there's the addcmpb instruction, which while add a value to a register, compare with another register, and branch based on a condition code, all in a single 32-bit operation --- it's basically a loop in a box.

It's also the only time I've ever seen 6-bit floating point constants...

Re: Minimal Raspberry Pi VPU firmware

#46

Post by david-given »

nanolith wrote: post #34
yalogin wrote: post #29

Earlier quoted context omitted.

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

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 diffe…

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.

Re: Minimal Raspberry Pi VPU firmware

#47

Post by aleden »

dezgeg wrote: post #40
ansible wrote: post #17

Earlier quoted context omitted.

I actually have one of those, but never investigated the bootloader situation for that platform. And to get good use out of the GPU (one of the main selling points for this platform), you'll want to use the Nvidia proprietary driver.

The K1 chip has a blob-free boot (unlike the newer chips AFAIK) except for the USB-based flash programming / recovery mode, so for the initial installation you'd need to manually flash the eMMC somehow if you don't want to run any proprietary code. And yes, CUDA isn't supported by the open drivers. Other than that, I've heard Nouveau works relatively well. Though I'm not still sure if the open source graphics communi…

NVIDIA has made it possible to run the Jetson TK1 under Nouveau with hardware accelerated graphics (Weston/Wayland or X).

https://github.com/NVIDIA/tegra-nouveau-rootfs

Using a completely open stack on the TK1, from u-boot to kernel (except for the USB firmware), I can run ARM virtual machines with QEMU/KVM.

Re: Minimal Raspberry Pi VPU firmware

#48

Post by TD-Linux »

revelation wrote: post #5
erikb wrote: post #2

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

It replaces the non-free binary blob on the Raspberry Pi that runs right after reset and initializes the processor. Modern complex processors require a specific and carefully orchestrated series of initialization steps to configure system clocks and ensure external RAM and other peripherals work correctly. Of course no one in their right mind would use this reverse-engineered code here for any serious purpose. Instea…

>and use something actually free, like the BeagleBone.

Oh please, while you lose the VC4 firmware, you instead get a proprietary PowerVR GPU with no free drivers. Not to mention that the Beaglebone has a much worse CPU than the "bolted on ARM" of the RPi.

If you're going to dump the rpi for this reason, going to something like the imx6 used in the Cubieboard and Novena would make a lot more sense (edit: Cubox, not Cubieboard).

Re: Minimal Raspberry Pi VPU firmware

#49

Post by peterderivaz »

david-given wrote: post #45
yellowapple wrote: post #42

Earlier quoted context omitted.

The main weirdness is that the VC4 is more of a GPU than a secondary CPU. It'd be like an Nvidia graphics card bootstrapping the actual CPU in an ordinary desktop.

That's not quite right. The Pi has a completely separate GPU unit. The VC4 is different, and is a pretty normal processor, although it's got a pile of DSP addons. The instruction set's here: https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor... ...but to summarise: - 32 registers which can hold either integers or 32-bit floats; - ARM-like 32-bit 3op instructions, with a limited set of 16-bit 2op instruction…

It was my first job out of University to design this instruction set which may explain some of the quirkiness...

Initially the instructions did all set the status flags but it caused a tight feedback loop in the processor. The choice was between a higher clock frequency for all instructions or better 64-bit arithmetic.

None of the initial video applications needed 64-bit support so it lost out, although I did get to put in the divide instruction just so my Doom port could run faster :)

Re: Minimal Raspberry Pi VPU firmware

#50

Post by wolfgke »

TD-Linux wrote: post #48
revelation wrote: post #5

Earlier quoted context omitted.

It replaces the non-free binary blob on the Raspberry Pi that runs right after reset and initializes the processor. Modern complex processors require a specific and carefully orchestrated series of initialization steps to configure system clocks and ensure external RAM and other peripherals work correctly. Of course no one in their right mind would use this reverse-engineered code here for any serious purpose. Instea…

>and use something actually free, like the BeagleBone. Oh please, while you lose the VC4 firmware, you instead get a proprietary PowerVR GPU with no free drivers. Not to mention that the Beaglebone has a much worse CPU than the "bolted on ARM" of the RPi. If you're going to dump the rpi for this reason, going to something like the imx6 used in the Cubieboard and Novena would make a lot more sense (edit: Cubox, not Cu…

> If you're going to dump the rpi for this reason, going to something like the imx6 used in the Cubieboard and Novena would make a lot more sense.

The Cubieboard uses an Allwinner SoC, which has a bad reputation among oppen source people since Allwinner violated the GPL multiple times in the past (though I heard the Linux support is decent; mainly because of the work of the Sunxi community: https://linux-sunxi.org/Main_Page). Novena (and "Sabre Lite - i.MX6 Quad Core"; cf. https://news.ycombinator.com/item?id=12743798) indeed use a Freescale (now bought by NXP) SoC.

Post reply on HN