
Open source VPU side bootloader for Raspberry Pi - hermanhermitage
https://github.com/christinaa/rpi-open-firmware
======
userbinator
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/...](https://github.com/christinaa/rpi-open-
firmware/tree/master/bcm2708_chip) 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.

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

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

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

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

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

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

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

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

------
aargh_aargh
Link to the author's blog: [http://crna.cc/](http://crna.cc/)

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

------
bitwize
Holy smokes, the thing everybody said would never exist!

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

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

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

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

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

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

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

~~~
pfalcon
Come on, it's a middle of 2016, everyone gotta know about projects like
[http://icoboard.org/](http://icoboard.org/) ,
[https://olimex.wordpress.com/2016/05/06/ice40hx1k-evb-
open-s...](https://olimex.wordpress.com/2016/05/06/ice40hx1k-evb-open-source-
hardware-fpga-board-designed-with-kicad-and-working-with-icestorm-foss-
toolchain-first-prototypes-are-ready-and-run/) , 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.

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

~~~
pfalcon
> 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](https://github.com/cliffordwolf/picorv32)

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

~~~
david-given
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.

