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.
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.
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 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.
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?
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.
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!
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.
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.
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).
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.
I looked a little more in detail, and this might make it easy to enable/unlock the hardware codecs that were initially locked-down.