hardware: https://www.96boards.org/
boot: https://github.com/ARM-software/arm-trusted-firmware
toolchain: http://releases.linaro.org/14.11/components/toolchain/binaries/
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.
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.
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.
Microsoft have some kind of UEFI bootloader for the Pi2 for Windows 10 IOT.
I looked a little more in detail, and this might make it easy to enable/unlock the hardware codecs that were initially locked-down.
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.
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.
Who says this is a contradiction?
The rest is a matter of looking at register traces and lot's of hard work on Kristina's part.
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.
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.
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).
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 :)
(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.