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

51–60 of 62 posts

Re: Minimal Raspberry Pi VPU firmware

#51

Post by gh02t »

mrlambchop wrote: post #38

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

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.

Re: Minimal Raspberry Pi VPU firmware

#52

Post by TD-Linux »

wolfgke wrote: post #50
TD-Linux wrote: post #48

Earlier quoted context omitted.

>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/Ma…

Oops, I confused Cubieboard and Cubox, which does have an i.MX6.

Re: Minimal Raspberry Pi VPU firmware

#53

Post by tmzt »

gh02t wrote: post #51
mrlambchop wrote: post #38

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

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.

Been on the other side of that working on the HTC Linux project and chatting with Android developers at Google. I knew they were laughing to themselves as we tried to figure out what were modem differences and what were SoC differences between MSM7x00A and non-A.

Re: Minimal Raspberry Pi VPU firmware

#54

Post by monocasa »

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…

Unfortunately NXP is nuking most of the iMX6 support from orbit after they bought Freescale. Even things like most of the SD card images for their SABRE boards were deleted of their site. It's only due to the large open ecosystem around the iMX6 that we were able to debug some issues while bringing up a board recently.

Re: Minimal Raspberry Pi VPU firmware

#55

Post by mrlambchop »

gh02t wrote: post #51
mrlambchop wrote: post #38

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

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.

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 :)

Re: Minimal Raspberry Pi VPU firmware

#56

Post by koytch »

david-given wrote: post #46
nanolith wrote: post #34

Earlier quoted context omitted.

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 (in…

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.

Re: Minimal Raspberry Pi VPU firmware

#57

Post by david-given »

peterderivaz wrote: post #49
david-given wrote: post #45

Earlier quoted context omitted.

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…

That's awesome! Also, Doom uses divisions?

Are you allowed to tell us what the C compiler used internally was based on? I know there are some very easy to port proprietary compilers which commonly don't see the outside world, and I'm wondering whether it was one of those, or whether some poor sucker had to port gcc.

Re: Minimal Raspberry Pi VPU firmware

#58

Post by webscaleizfun »

monocasa wrote: post #54
TD-Linux wrote: post #48

Earlier quoted context omitted.

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

Unfortunately NXP is nuking most of the iMX6 support from orbit after they bought Freescale. Even things like most of the SD card images for their SABRE boards were deleted of their site. It's only due to the large open ecosystem around the iMX6 that we were able to debug some issues while bringing up a board recently.

Same thing happened with Allwinner's SOCs, when the one point of contact that was providing the source of their modified kernel left, Allwinner chipsets stopped getting rapid mainline kernel support.

The silver lining though is that the sunxi community has been working to mainline newer chips like the Allwinner H3 & has been doing a bang up job with minimal info, newer kernels can boot up & get most hardware onboard configured & ready to use.

Re: Minimal Raspberry Pi VPU firmware

#59

Post by pcwalton »

david-given wrote: post #57
peterderivaz wrote: post #49

Earlier quoted context omitted.

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…

That's awesome! Also, Doom uses divisions ? Are you allowed to tell us what the C compiler used internally was based on? I know there are some very easy to port proprietary compilers which commonly don't see the outside world, and I'm wondering whether it was one of those, or whether some poor sucker had to port gcc.

> Also, Doom uses divisions?

Well, it's 3D, so you pretty much need perspective divide at the very least…

Re: Minimal Raspberry Pi VPU firmware

#60

Post by hermanhermitage »

peterderivaz wrote: post #49
david-given wrote: post #45

Earlier quoted context omitted.

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…

Love the design of the instruction set. It was a lot of fun reverse engineering it and mulling over the design space. Thanks.
Post reply on HN