Open source VPU side bootloader for Raspberry Pi | Hacker News Reader

Open source VPU side bootloader for Raspberry Pi

github.com

Was this the result of much reverse-engineering, or was there a recent Broadcom release/leak of the needed information? The files in https://github.com/christinaa/rpi-open-firmware/tree/master/... are interesting... I'd suggest making a copy of them for safekeeping. ;-)

I looked a little more in detail, and this might make it easy to enable/unlock the hardware codecs that were initially locked-down.

It wasn't a leak, Broadcom publicly released all this code a while ago to aid the making of an open source GPU driver. All this has been licensed under 3-Clause BSD license and distributed by Broadcom themselves. There's no point in making a copy since you can just download these files from Broadcom themselves.

This won't help you with codecs, codecs are mostly code in the firmware that uses vector instructions of the VPU to accelerate the video decoding. If you want to use the codecs I would recommend paying for them instead of engaging in piracy.

The "BROADCOM CONFIDENTIAL" header in a few of them certainly made me think otherwise...

codecs are mostly code in the firmware that uses vector instructions of the VPU to accelerate the video decoding

That means it should be possible for open-source firmware to add more, freely usable, codecs than in the proprietary firmware.

Yes if you can implement high performance video codecs using pretty much undocumented vector instructions of the VPU, you are welcome to do so.

Also, there are hardware blocks for JPEG and MPEG for best performance. See vcodec.h etc.

But the VPU 2D SIMD is good for non supported codecs.

> If you want to use the codecs I would recommend paying for them instead of engaging in piracy.

Who says this is a contradiction?

Those headers are as I recall all part of Broadcom's release at https://www.broadcom.com/support/videocore.

The rest is a matter of looking at register traces and lot's of hard work on Kristina's part.

Boy, it would be sweet if ARM or someone would sponsor some kind of common system architecture. Sure, lots of vendors would keep making their own boards like Pi, beagleboard, ODROID, etc. But having an extensible architecture like UEFI or similar to facilitate bootstrapping while still being open would be awesome.

Not ARM, but there is http://www.lowrisc.org/, not sure of its status.

u-boot is pretty good, and the defacto "standard" for these kinds of things.

Microsoft have some kind of UEFI bootloader for the Pi2 for Windows 10 IOT.

The SPARC architecture is open and fully documented, the only licensing encumbrance is a token administration fee of approximately $100 that helps maintain the organisation that is the steward of the SPARC ISA intellectual property and the fee only applies if you intend to implement your own hardware commercially.

I'm constantly amazed at how much work is done to reinvent the wheel as far as ISAs are concerned, SPARC is an excellent platform and has an extremely high level of "shovel ready" hardware designs that you can just ship to a manufacturer and get back hardware. There is even open VHDL to fabricate modern high power CPU designs.

But the problems here are nothing to do with choice of ISA and everything to do with standardisation of the bringup/boot process.

Free/Open Source chips are a lovely idea that doesn't work without a financial sponsor because software can be made and distributed at near-zero marginal cost, including by the end user, but hardware can't.

> you can just ship to a manufacturer and get back hardware

So, why don't you do that? And if you wonder about others, especially big corporate guys, easy thinking would be that $100 isn't all you need to use SPARC, and it's cheaper for them to use something else. However, if you put it like that, you're a computer geek with zero insight into economics and marketing. The real answer is that it's more profitable for them to use something else than SPARC.

They are: http://www.96boards.org/

They already have done all that:

  hardware: https://www.96boards.org/
  boot: https://github.com/ARM-software/arm-trusted-firmware
  toolchain: http://releases.linaro.org/14.11/components/toolchain/binaries/

In particular, the ARM trusted firmware project is what is supposed to save us from todays proprietary boot madness

The word "trusted" with regard to firmware traditionally means "pwned by a hostile adversary"; did ARM just choose a bad name for their project or is this another bit of "you think it's your computer but you're wrong" bullshit?

The code is BSD licensed but TrustZone and probably this reference firmware for it are mostly about DRM.

Ah, ok, so it is all about the traditional, unintentionally ironic definition of "trusted", then.

Context: This is a first step in allowing blob free development on the RaspberryPi.

Link to the author's blog: http://crna.cc/

I think the video capabilities especially in connection with the CSI camera is what sets the Raspberry Pi really apart from Odroid and so on. It's pretty amazing that it can encode 720p video at 48fps - didn't something like encoding a DVD take like 8 hours 10 years ago?

Holy smokes, the thing everybody said would never exist!

I'm not sure everyone said it would never exist--just that it would be hard. There has always been a small but dedicated community around reverse engineering the thing. Though this has come quite a bit sooner than I expected!

Still doesn't exist, though it's a step in the right direction. Before, the most anyone had managed on the Raspberry Pi without the closed-source bootloader was to run small VPU programs that toggled GPIOs and talked serial; now this can run small ARM programs that do the same. It still needs some way to actually read programs from external storage and a whole bunch of (completely undocumented, IIRC) clock and power management hardware initialization.

Don't get me wrong, it's impressive what the Raspberry Pi community have managed given that just how heavily hamstrung they are here, but don't expect to be running Linux without the blob any time soon. I remember people involved in this talking about having reverse-engineered enough information to boot the ARM core in theory over a year ago. It's slow going.

Actually, the bulk SDRAM/ARM work was done by me in the space of around month (though I only ARM to finally work three days ago with Herman's help).

You could run Linux on ARM using this but you would need to write some more drivers, otherwise you'd be limited to pretty much GPIO/serial/SDHOST PIO.

SDHOST is actually a fairly trivial interface to implement, I'm going to use it in my chainloader but I haven't had the time to look at it yet.

> Actually, the bulk SDRAM/ARM work was done by me in the space of around month

Full-time? Rainy weekends? This borders on personal territory of "what do you do for day-job?", so feel free to skip answering.

I wonder, could we see a potential let's say Raspberry Pi 5 use a quad-core RISC-V processor, as well as an open source GPU (and open source everything else)? I think that would align quite well with Raspberry Pi's mission, and it's an an better position to kickstart the adoption of open source CPUs and GPUs than some other noname project.

Don't get me wrong, it's an interesting idea, but in terms of the Foundation's actual goal to "advance the education of adults and children, particularly in the field of computers, computer science and related subjects" I cannot see the huge effort required to move to new hardware being a good use of their limited resources. Focusing on improving software and the actual teaching materials/training available to educators would make more sense for their mission.

Then my guess is the Raspberry Pi will be "disrupted", because the hacker/maker community, which may be an even bigger market currently than the "school market", will adopt the fully open source alternative. Some Arduino boards are already starting to support RISC-V processors, so I think it's only a matter of time.

Got a link to those RISC-V based Arduino boards?

IIRC the RISC-V ISA itself isn't finalised so I would be surprised if people were manufacturing it already.

Come on, it's a middle of 2016, everyone gotta know about projects like http://icoboard.org/ , https://olimex.wordpress.com/2016/05/06/ice40hx1k-evb-open-s... , etc. projects. They allow to have completely open-source process to bring up RISC-V CPUs on a reverse-engineered FPGA. When they collect enough funds (if people of the world will give it to them), they will make ASIC silicon too. The only risk is that big corporations won't give up their prerogative of being the only parties who make the world better, subsume RISC-V and shove out closed-down RISC-V chips like they did before. But how it should work is that there should be competition between classical NDA-ridden and close-down stuff and open RISC-V, to let customers decide what they want in a particular case.

Ah, I thought you were talking about ASICs. Are those FPGAs big enough to support RISC-V?

The closed corporate versions of RISC-V thing is very likely and probably will become the easiest way to get a RISC-V chip.

> Are those FPGAs big enough to support RISC-V

RISC-V is a flexible and configurable architecture, with support ranging from small MCUs to 128-bit ISA which nobody else have yet (for a general-purpose ISA) to tagged memory (which failed to rule the world in 1970ies but now might be just used when gives benefit).

Those FPGAs of course run an MCU variant of RISC-V (as we started with talking about Arduino), e.g. https://github.com/cliffordwolf/picorv32

> align quite well with Raspberry Pi's mission

There're multiple missions, including market and uphold Broadcom Corporation's presence in various niche markets and advertise Broadcom throughout the various industry and market segments (also, for 4+ years, it was "sell old Broadcom stock", but finally they succeeded and RasPi3 has current, not outdated CPU). All big cheeses from RasPi foundation are big cheeses from Broadcom. And they are known to have shutdown third-party vendors who tried to use Broadcom CPUs for RasPi-like designs, nor they fancy using somebody's else chips for their stuff.

Note there's nothing wrong with that - you can sell your chips (or other stuff) and make the world better at the same time (and that's what everyone does on this planet).

Ah, the VC4...I had the impression the toolchain for that will be a nightmare to setup outside of the "close guarded internal tools"( which were "fun" to use).

Besides except the video stuff I do not see a point of running (lets say a Linux) on the VC4.

But still fun moment to see all this being done, congrats :)

The VC4's actually quite a nice processor; it's fun to write code for. 32 registers, massive DSP unit which I haven't looked into, instructions can be 16, 32 or 48 bits long (inline 32-bit constants!), FPU which shares registers with the integer unit, and some really interesting instructions for fast loops...

(My favourite is addcmpb, which will increment a register by a constant or register, compare the result to a constant or register, and do a branch based on the result... all in a single 32-bit instruction. It's a for-next loop in a box.)

...but the downsides are that the FPU is single-precision only, doing 64 bit arithmetic is really hard, and the processor seems not to have any kind of MMU, which means that running real operating systems on it is likely to be very hard.

Reply on news.ycombinator.com