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

31–40 of 62 posts

Re: Minimal Raspberry Pi VPU firmware

#31

Post by pjc50 »

yalogin wrote: post #25
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…

I read through the wiki page for videocore but still did not get a complete picture of what this is. Is it a GPU? If its a GPU or something that specializes in processing video/audio why is it in charge of the boot process? Doesn't it usually happen the other way around, the boot ROM loads the host OS which in turn initializes the other firmware?

Better documentation: https://github.com/hermanhermitage/videocoreiv

It's a vector processor and a GPU. The vector processor is intended for video decoding and therefore has a very big SIMD capability. It has some nice gimmicks like the 'square' register file: you can access rows or columns for SIMD operations. The VPU is I believe what boots first and normally runs an RTOS called "ThreadX".

The GPU is OpenGL-capable.

Re: Minimal Raspberry Pi VPU firmware

#32

Post by pjc50 »

yalogin wrote: post #29
david-given wrote: post #14

Earlier quoted context omitted.

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…

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

Mobile doesn't have UEFI either. Usually what happens is the processor has some minimal boot ROM that can initialise the Flash (and enforce signed boot!), and then it just loads a chunk of Flash into RAM and jumps to it.

Re: Minimal Raspberry Pi VPU firmware

#33

Post by pjc50 »

c3833174 wrote: post #22
jdub wrote: post #15

Earlier quoted context omitted.

The ARM world is rapidly moving towards UEFI, partly thanks to Microsoft insisting there be something like it for them to build on. Even better, u-boot implements enough of it to boot a UEFI operating system. So on some new devices you'll get UEFI firmware, on everything else you can flash u-boot with UEFI support... and it's now part of their default configs. Pretty cool. :-)

>The ARM world is rapidly moving towards UEFI, partly thanks to Microsoft insisting there be something like it for them to build on. Hope it isn't another quirky "just enough to boot windows, with other OSs having to clone windows behaviour to work" thing. Can secure boot be disabled on ARM?

See your mobile phone: it depends whether the manufacturer makes that an option. In a processor I'm familiar with (imx53), once it's turned on by a processor fuse it stays on - it's then up to the second stage boot loader (provided by the device OEM) to decide whether to load untrusted images.

Re: Minimal Raspberry Pi VPU firmware

#34

Post by nanolith »

yalogin wrote: post #29
david-given wrote: post #14

Earlier quoted context omitted.

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…

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

Re: Minimal Raspberry Pi VPU firmware

#35

Post by makomk »

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…

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 part of the reason the Raspberry Pi has relatively good mainline kernel support - they don't have to deal with months of LKML hell to get basic things like clocking and power management working every time they release a new chip because that's all handled in the blob.

Re: Minimal Raspberry Pi VPU firmware

#36

Post by Narishma »

RossBencina wrote: post #27
yalogin wrote: post #25

Earlier quoted context omitted.

I read through the wiki page for videocore but still did not get a complete picture of what this is. Is it a GPU? If its a GPU or something that specializes in processing video/audio why is it in charge of the boot process? Doesn't it usually happen the other way around, the boot ROM loads the host OS which in turn initializes the other firmware?

There is some information here: https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor... In particular we are talking about "Scalar/Vector (VPU)" "Dual Core VideoCore IV® Multimedia Co-Processor" (Figure 3B). As far as I understand, that's the thing that boots the device and usually runs ThreadX OS in the closed-source bootloader. The VPU is a dual core processor with scalar and integer vector instructions. Th…

I believe the VPU runs the OpenGL ES stack when using the closed source drivers.

Re: Minimal Raspberry Pi VPU firmware

#37

Post by zokier »

2bluesc wrote: post #21

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.

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.

Re: Minimal Raspberry Pi VPU firmware

#38

Post by 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).

Re: Minimal Raspberry Pi VPU firmware

#39

Post by bronson »

geon wrote: post #18
david-given wrote: post #14

Earlier quoted context omitted.

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…

> there was some spare silicon I don't think such a thing exists. Aren't dies made as small as possible to increase yield? I know the Cell processor in the ps3 had a spare spe core to significantly increase yield.

Chip layout/floorplan isn't like laying tiles. Not everything is gridded and fits together perfectly.

Re: Minimal Raspberry Pi VPU firmware

#40

Post by dezgeg »

ansible wrote: post #17
abrodersen wrote: post #10

Earlier quoted context omitted.

I think the Jetson TK1 from NVIDIA can run mainline Linux with most of the devices working.

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 community has figured out a way to get stacks like Xorg or Wayland/Weston running without hacking the source on architectures where rendering and scanout are done by different DRM devices.

Post reply on HN