We actually have documented most vector instructions of VC4 and Julian's toolchain supports pretty much all documented ones, so the toolchain we have is pretty close to what Broadcom would have with their MetaWare compiler for VC4.
>The RPI3 is rated for 24GFLOPS
You mean the VPU, we also have QPU and ARM on the side.
>so many really weird abnormal subsystems
True that, lack of TZPCs, ARM AxPROT[1] being forced to high causing all ARM accesses to be insecure on AXI even in secure monitor mode (sadness), lack of a GIC. I could go on and on about what's wrong with BCM283x family but hey at least it's interesting.
>But I am sincerely impressed and it has been amazing work slowly wrangling this abomination into order.
Thank you ^^
My favourite is probably NVIDIA Jetson TX1 where development boards do not have a key fused in them and have documented TrustZone peripherals, so you're free to run your own secure monitor.
Sadly while ARM on rPi does start in secure mode, it lacks any secure peripherals (AxPROT[1] is forced to high so even if ARM is in secure mode, it cannot make secure bus transactions) but it's mostly a matter of principle of being able to have ARM code run in EL3 for me.
The entire point of a development board is to be able to mess around with it, I'm not wasting my time on boards with locked down features.
Most ARM cores start in secure supervisor mode, which can transition to secure monitor mode at will (secure monitor being a special version of secure supervisor). Most bootloaders including Allwinner's will exit secure mode by setting the NS bit in SCR and therefore enter user provided code in non-secure supervisor (or hypervisor mode) which would be called EL1 (or EL2 for hypervisor) on AArch64.
EL3 has nothing to do with ROM or Allwinner or anything else, it's an execution mode defined by ARM themselves, the core is reset in that mode.
(Secure mode is also known as TrustZone, if that term seems more familiar though TrustZone is usually "the whole package" including support from the CPU and the corresponding peripherals)
1). The first stage bootloader doesn't require signing.
2). The first stage bootloader starts in EL3 mode (ie. BootROM doesn't exit it like it did on some OMAP dev boards)
The PS3 does more than 230 GFLOPS, just with the Cell processor (1 dual threaded CPU and 7 vector units -CPUs with wide SIMD, working in 256KB local scratchpad RAM-) [2]. In addition to that, the PS3 GPU does 400 GFLOPS [3]. So the PS3 is "600 GFLOPS" (32-bit precision).
[1] https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...
[2] https://en.wikipedia.org/wiki/PlayStation_3_technical_specif...
[3] https://en.wikipedia.org/wiki/RSX_'Reality_Synthesizer'#cite...
I believe I was unintentionally citing that a single Cell SPE is 25.6 GFLOPS: https://en.wikipedia.org/wiki/Cell_(microprocessor)#Synergis...
Then again, forgive me for generalising, but the RPi community has always appeared to me to be comprised of mostly "new school" "hackers and makers", with very few from the "old school" "hack-and-free" culture. They haven't had to deal with the anti-open-source attitude of Broadcom and the unavailability of drivers. They aren't the type who think things like electrical specifications for GPIOs are important (the last time I checked, they were officially unavailable... and anyone asking on the forums was responded to condescendingly or misleadingly by the officials.) They just don't know any better. It's not surprising then, that a large part of the community is actually praising BRCM for making the RPi possible.
Looking at it like that, its dead obvious why they went with broadcom.
I really hate the attitude of the root post that holds open hardware above everything else. RPi has done a ton to help education getting a new generation excited about computers.
There are already Arduinos and regular PCs (of which you will find far more documentation on... especially the latter) for that. Why make another closed proprietary system just for teaching? All it will do is make those educated (indoctrinated?) by it think this type of environment should be the norm and encouraged, when there are in fact plenty of better ones.
Even a C64 or a ZX Spectrum would be a better choice than an RPi for teaching.
This is the strangest opinion I've seen all day. My teen programming years were on a c64 in the late 80s, and in retrospect that was a really tough learning experience (and when I got to college and had access to 'anything else' I never looked back).
Also how was the c64 not a 'closed proprietary system'?
It's been completely reverse-engineered, emulated, and documented, a lot more than can be said of the SoC in the RPi. Maybe in 30 years the same will happen to the latter, but I'm not too optimistic about that.
C64: http://www.classiccmp.org/cini/pdf/Commodore/C64%20Programme...
C128: http://www.pagetable.com/docs/Commodore%20128%20Programmer's...
Because that's still not equal to an open-source design where the licensing eliminates such risks.
I can understand being disappointed at this choice, but if no other options exist, then either you're sacrificing price or performance to get more open-ness. My impression has been that this has mostly been about giving a cheap, easy to use software platform, and they've succeeded at that because of the price/performance balance.
That was then, though. Now that this platform is more established, I imagine they can apply some pressure to get things like the video core to be more open.
It was chosen mainly for the low price. The performance was a little subpar but it had the advantage of a decent video graphics block.
"Now that this platform is more established, I imagine they can apply some pressure to get things like the video core to be more open"
Broadcom was one of the worst companies to get documentation from, even for their own customers. Unless you were a big customer, you're lucky to get the time of day from them. Hopefully, their new owners Avago will have a different attitude towards the open source community.
The OPi chip maybe for not cone from a "respected" western company but it is in all regards a more open chip.
While the datasheet is almost as thin as that of Broadcom it is mostly because they use standard components where the full datasheet is available from arm.
There are also far less magic blobs and crazy boot gymnastics in there.
This isn't some petty nationalist agenda like you're claiming. AllWinner's lack of respect stems from their pathological refusal to cooperate with the Linux kernel and their many GPL license violations. They throw out new hardware cores very frequently, but the hardware is impossible to keep updated (and is thus insecure and hard to use) because AllWinner won't release hardware documentation or source code. I've got a few AllWinner devices, and they're poorly suited as general-purpose computing devices if you need both graphics and a recent kernel. They collect dust with my other nigh-unusable hardware.
Most of the AllWinner support in the kernel has been added despite the company's deplorable position, and the major community repository of information is highly critical of them (http://linux-sunxi.org/Allwinner). It's sad for a company when your major users and developers think so poorly of you.
Broadcom also acted like this for many years, and was similarly hated. The Raspberry Pi has been a bit of a paradigm shift in corporate policy which has earned them a lot more respect. And it's still been a rather slow journey.
If AllWinner wants respect, they can earn it by making their hardware easy to use for the hobbyist and non-commercial developers they're courting with all the cheap knockoffs they're releasing (e.g. Orange Pi, Banana Pi, etc which try and profit off brand name similarity). Blaming it on Western propaganda is just pitiful self-deception.
That's not what I am saying. I'm saying Broadcom is getting a pass because they are a household name.
http://www.orangepi.org/downloadresources/orangepipc2/2016-1...
https://www.olimex.com/Products/OLinuXino/open-source-hardwa...
http://linux-sunxi.org/Linux_mainlining_effort
edit: I now see you link to linux-sunxi, so you probably already know about this.
It is not fully open. (http://linux-sunxi.org/CedarX). Partial code was published a year and a half ago, but the video engine still isn't supported. Their GPUs are Mali, as well, which is still a large obstacle in running a modern kernel.
Not to mention that all the code they published was as code dumps, some was under unclear licensing, and it's never on a remotely modern kernel, so it requires heavy porting. But yeah, they did release the code after years of complaints about GPL violations.
Giving a company credit for community efforts is kind of misleading.
Mali is still closed source, but GPUs in general are in a poor state for open driver support. Luckily you don't need GPU drivers to bring up Xorg on HDMI on Allwinner chips, so unless your playing video games, it is a non-issue.
Their code dumps they have cleared up the licensing on as of late, Tyle from Allwinner did make clear that everything that isn't explicitly licensed in the file itself is under GPLv2, and that that was Allwinner's original intention. The fact that they are ancient BSP kernels is sucky, but the community is making these sub-$1 SOCs run circles around the other SBCs.
"Abomination" is ridiculous.
Your point that the pi board provides educational value despite the frustratingly obtuse abomination at the core is valid though.
On top of that, other vendors have pretty much the same problems. Take Intel's stuff for example. It doesn't work without a BSP and you can't even boot a system and have it on for over 30 minutes without a running Management Engine.
Qualcomm, AllWinner, Marvell, Ti, they all make ARM SoC's and they all need their own BSP's to work. Broadcom is not unique in this.
Generally there are issues getting the GPU working well without firmware blobs but other aspects work fine.
Check out the Freescale part used in Bunnie's Novena laptop for example.
This is also the case for TI parts and the other manufacturers you list. Broadcom is somewhat unique in requiring a blob to even boot the system.
Yes precisely, so we offer an alternative to those blobs that allows you to boot ARM without needing a closed-source firmware.
Broadcom has yet to do anything like that.
So, basically it was a political choice to use this part. I think it also helped Broadcom sell a part which wasn't hugely popular.
They weren't sure they'd sell 1000 initially, and 10,000 was crazy dream. It wasn't conceived as the next wave of hacker and maker computers. Its goal was to be a cheap and accessible way to teach kids programming.
Eben Upton was an SoC architect at Broadcom and was working there full time, and when the Pi was designed they thought they'd shift 1000 units of the end product. Why on Earth would they use anything other than the Broadcom?
It was a practical and logistical choice.
Other manufacturers use cheap dev boards as a way to seed sales with manufacturers (e.g. Pandaboard or Beaglebone), but RPi was not one of them.
You meant masochists?
I meant masochists. Thanks for questioning.
The Broadcom part in the RPi was heavily subsidized. Don't be fooled by price here.
BTW the Broadcom part is heavily subsidized.
I take it you're talking about the SoC rather than the CPU. In this case, open-source drivers for ARM SoC weren't exactly common when the RPi was launched. For example, I can't think of a single open-source GPU driver (used with ARM SoCs) that was available at the time.
> abomination
You know, this kind of language doesn't make people want to spend money and effort on open sourcing things. Where's your cheap open hardware, then?
iomega iconnect: https://wiki.openwrt.org/toh/iomega/iconnect
The Kirkwood was fair. 1.6GHz ARMv5TE-ish cores, custom architecture, but sipping data through a 16 bit DDR2 channel. I had hope that Marvell would progress and keep it up, but they seemed to get harder to find and harder to use and less supported and only show up in some random Android STB as the years went on.
But this is the basis I had during RPi's 2012 arrival. Still flush with hope, of decent upstreamed cores, & it seemed rather like an unfortunate step back. That said, I was buying for twice the price of RPi while only paying rather discounted ebay prices, albeit for consumer goods with wifi, flash, cases, & warranties.
I'm still not sure what I'd point people to today if I wanted to suggest an alternative. The good work done in making blobless rpi happen, in building good upstream drivers has been incredibly impressive. I do wish Freescale had better recognized the need for low cost boards. Now a days, Atmel's SAMA5D3-Xplorer board has really good upstream, great peripherals, Arduino headers, and has fantastic power consumption, but it's three times the RPi price.
You can't convince them that there's a bigger world of options out there that can be better for your particular application.
The Pi's choice of picking one of the most egregiously unsupported and anti-open source CPU cores was absurd. The people doing the absurdly hard work of taking up the slack that the Raspberry Pi Foundation created from this pick AND the RPI Foundations complete unconcern about the situation and open source at large is to me beyond belief. For a thing that purported to be an educational platform, this situation ought never have happened. At the time at least the low price of the decrepit old core was a good useful competitive advantage, I can acknowledge that, but it remains revolting to me that the #1 cheap Linux system is the spawn of some ancient horror Broadcom dropped with ghastly documentation and unsupportable drivers.
But congratulations. For some reason people have kept the march of progress going on this beast. The RPI3 is rated for 24GFLOPS which is 1 more than a PS3 cell processor. It's been an unbelievable amount of work to get anywhere near unlocking the unique video core to get anywhere near there, but people keep pushing, so good on them. I still think it's a mistake for volunteers to work so ridiculously hard to build drivers for a core whose maker has contributed so little, spent so long releasing even basic docs, and who implemented so many really weird abnormal subsystems, especially when it was originally atop such an ancient core.
But I am sincerely impressed and it has been amazing work slowly wrangling this abomination into order.