[rektide]

Sadists.

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.

[christina_b]

>unlocking the unique video core to get anywhere near there

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 ^^

[trome]

You are fighting the good fight, freeing one of the most common single board computers! That being said, besides quantity, why focus on the Raspberry Pi instead of Allwinner H3 based boards or another board where most of the support (including uboot) is already upstreamed & can be run with a fully libre stack?

[christina_b]

If a "development" board does not let me run my own code in EL3 (Secure monitor mode), I'm not buying it, as simple as that. A lot of boards that use Allwinner chips will use a signed bootloader that exits secure mode before passing control to your code.

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.

[makomk]

I didn't even know Allwinner supported secure boot, and it's certainly not widely used as far as I know. Running your own code in EL3 is pretty standard there because it's the mode when the ROM bootloader hands over control to the user-provided bootloader. You sure you haven't confused them with one of the other manufacturers?

[christina_b]

All modern ARM chips support secure mode, it's a set of modes, in AArch64, we colloquially call them EL3 (Exception level 3, highest privilege level above EL2, the hypervisor level).

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)

[makomk]

Well, of course they support secure mode/EL3, it's just not exactly secure on any Allwinner-based system I'm aware of because the ROM bootloader will happily load any chunk of code yo choose to supply into RAM from the boot device and jump to it whilst still in EL3, without any signature checks. Allwinner really don't seem to be keen on locking their chips down.

[trome]

Uhh, the H3 has supports TrustZone and has an efuse that is unset but can be burned with a signature, so its supportable in that regard.

[niftich]

With this bootcode.bin running on the VPU, after the ARM starts up and Linux is loaded, does the VPU halt and remain unreachable, or does the "normal" VC4 RTOS execute such that stuff from the ARM can be mailboxed to it?

[christina_b]

Currently it sleeps and waits for a mailbox interrupt after which it acks it and goes back to sleep. We're planning on using the interface to load a second stage firmware that would emulate the closed source firmware's power/clock management interfaces (but not framebuffer/PV/HVS/HDMI related stuff since there are Linux drivers for that now).

[BuuQu9hu]

Which toolchain are you using? binutils/GCC or LLVM? Is the code for that upstream?

[christina_b]

binutils/GCC, have Julian to thank for his wonderful toolchain: https://github.com/puppeh/vc4-toolchain

[faragon]

The "24 GFLOPS" in RP come from the GPU (Videocore IV, 32-bit precision) [1].

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

[rektide]

Oh my goodness how right you are. I'm very sorry! I should have checked this far better. Again, super sorry.

I believe I was unintentionally citing that a single Cell SPE is 25.6 GFLOPS: https://en.wikipedia.org/wiki/Cell_(microprocessor)#Synergis...

[userbinator]

At first I was optimistic that with all the popularity of the RPi, someone would eventually be a hero, but the fact that apparently not a single leak of the full datasheet has occurred after all these years also tells a lot about how Broadcom operates. Even the usual neighbourly Chinese forums are noticeably devoid of Broadcom information --- not as in "taken down/DMCA'd", but as in "we just don't know anyone who has access and is willing to share".

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.

[BuuQu9hu]

https://www.raspberrypi.org/blog/a-birthday-present-from-bro...

[trome]

Broadcom released a tangentially related driver (Not targeted at the RasPi) and the person who could do the quickest, dirtiest port of that driver to kinda-sorta get Quake 3 running got $10k. I remember when this happened, it was a shitshow then, and looking back it makes the people behind the Raspberry Pi Foundation look incompetent if viewed kindly.

[Itsdijital]

The founder and CEO of RPi was a technical director and ASIC architect at Broadcom.

Looking at it like that, its dead obvious why they went with broadcom.

[vvanders]

Yup and Eben Upton did it to teach basics of computer programming and development since he was so frustrated with the state of things in the UK.

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.

[userbinator]

teach basics of computer programming and development

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.

[GFK_of_xmaspast]

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

[userbinator]

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.

[nickpsecurity]

That means it was a closed, proprietary system that was reverse engineered & emulated. Different from an open system that doesn't require that. Also more efficient in hardware if any clones port original design.

[mongol]

Indeed.

[rtpg]

Are there SoCs at a comparable price/speed that are more open?

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.

[aceperry]

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

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.

[superflyguy]

I doubt the pi foundation are remotely concerned with how open the soc is as it has absolutely no impact on the core uses of the pi. They're smart people and would have made a different choice were it the case.

[tinus_hn]

I've seen statements from them about this. They do care but they also are pragmatic and made the choices they had to make to reach their goal, which was to have a small cheap programmable device with enough power to make cool things easily. Openness came second to that.

[makomk]

The Orange Pi PC is $15, roughly comparable to the Pi 3 performance wise, and doesn't require any of this hilarity to boot with open source code.

[christina_b]

See my other comment about Allwinner, but basically my biggest issue is that they lock down their bootloader with signing and do not allow you to execute code in EL3/Secure mode without exploits.

[squarefoot]

This is very sad because those H3/H2 based boards are SO much more interesting than the RPis. I can't but wonder why Allwinner is so hostile to OSS.

[bostand]

Not sure why this is downvoted.

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.

[justabystander]

> The OPi chip maybe for not cone from a "respected" western company

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.

[bostand]

> This isn't some petty nationalist agenda like you're claiming

That's not what I am saying. I'm saying Broadcom is getting a pass because they are a household name.

[ekianjo]

Is it just me or the downloads on the Orange Pi site have no checksum attached?

http://www.orangepi.org/downloadresources/orangepipc2/2016-1...

[trome]

The OrangePi Zero is $7, same H3 SOC with the same software stack, plus it has ethernet, wifi & POE.

[userbinator]

AllWinner comes to mind; here's one of the more well-known RPi-ish boards using them:

https://www.olimex.com/Products/OLinuXino/open-source-hardwa...

[rincebrain]

Allwinner's been known to play hard and fast with the GPL and LGPL, so I'm not sure I'd cite them for being better about open source.

cf. http://linux-sunxi.org/GPL_Violations

[makomk]

I think they got their act together a while ago. More importantly, part of the reason they got in so much hot water is they didn't use the Pi's GPL compliance technique of moving everything interesting into a blob running on a totally undocumented core. Everything important runs on the ARM core. (I believe some of the newer SoCs have an embedded core for power management, but apparently it's OpenRISC-based.)

[wycx]

Allwinner itself might not be the best example of open source support, but Allwinners products are well supported in the mainline kernel by the outstanding work of the linux sunxi team. See their progress here:

http://linux-sunxi.org/Linux_mainlining_effort

edit: I now see you link to linux-sunxi, so you probably already know about this.

[userbinator]

They release plenty of documentation, which is more than can be said for Broadcom who seem to be doing all they can to both stay proprietary and legal. Broadcom supplies binary blobs, some source code (which is definitely not for those blobs given how anal they are about IP/licensing), and almost no documentation; AllWinner supplies binary blobs (which are based on existing open-source, thus easier to reverse-engineer), some source code, and far more documentation. Regardless of the legal situation, the contrast is clear.

[trome]

Yet they have the best mainline driver support, with a fully open VPU driver. Not saying they did any of that mind you, but they at least put the docs out there and eventually posted their BSP on github under GPLv2, so their changes could be updated & mainlined.

[justabystander]

> Yet they have the best mainline driver support, with a fully open VPU driver.

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.

[trome]

Uhh, if you want a bad experience from a closed source blob, CedarX is your go to. Cedrus is the fully open VPU driver I was referring to, with H265, VP8 and H264 support.

http://linux-sunxi.org/Cedrus

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.

[joezydeco]

Yes. Qualcomm/NXP/Freescale's iMX, for starters. Or TI's Sitara line (BeagleBone).

[agumonkey]

Nowadays possibly; when the rpi project started I don't think so.

[sambe]

Educational and 100% free are not the same. It's not remotely hard to imagine them having other trade-offs to make and being most concerned with getting devices in hands.

"Abomination" is ridiculous.

[Thrillington]

After spending a few days poking around trying to get the I2S block going, abomination is the right word for the processor. If only because of the severe lack of documentation and support.

Your point that the pi board provides educational value despite the frustratingly obtuse abomination at the core is valid though.

[oneplane]

You make it sound like there was an alternative, which at least at design-time, there wasn't.

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.

[waterhouse23]

No, Broadcom is quite unique in requiring blobs to boot. There are plenty of SoCs that are functional without firmware blobs.

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.

[christina_b]

>No, Broadcom is quite unique in requiring blobs to boot.

Yes precisely, so we offer an alternative to those blobs that allows you to boot ARM without needing a closed-source firmware.

[oneplane]

But isn't the blob in the Pi just that, for the GPU? It's the GPU that boots and then the CPU, not the other way around. Or does the blob contain both GPU code and CPU code? And how is this different from UEFI or BIOS, or option ROMs in video cards? AFAIK you have plenty of Broadcom chips that don't need a blob to boot, those in most routers for example. Sure. there are routers with redboot, u-boot, CFE etc. but they are not much different from a BIOS firmware in a PC.

[koz1000]

Spot on. BSP != "blob".

[trome]

Sure, but Allwinner did release their BSP under GPLv2, which the community summarily ported to mainline for the chunks they hadn't rewritten already.

Broadcom has yet to do anything like that.

https://github.com/allwinner-zh/linux-3.4-sunxi

[waterhouse23]

The reason they chose this Broadcom part is because they could get it cheap from Broadcom (founders have an association with Broadcom).

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.

[Nexxxeh]

I think goven the origin story of the Pi, "political" implies something that wasn't there. The Pi was want expected to be the huge success it has been.

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.

[joezydeco]

Broadcom has no interesting in selling parts to anyone unless you're moving millions of handsets a year.

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.

[pero]

As a little cherry on top, the CPU they sourced is also crippled with no onchip crypto. Even the half-price Pine64 has a CPU with crypto instruction sets.

[viraptor]

> Sadists.

You meant masochists?

[rektide]

Uggghhh I meant masochists. That's a... very unfortunate mistake. As I said already in this thread (RE getting the GFLOPS way wrong), sorry!!!

I meant masochists. Thanks for questioning.

[stevekemp]

I think the implication was that the choice made users suffer, and feel pain - so sadism fits.

[viraptor]

Makes sense. I read it as referring to people doing the reverse engineering work initially.

[agumonkey]

What SoC of that class (perf/price) was on shelves when the rpi started ?

[joezydeco]

OMAP3, OMAP4, Sitara, iMX5, iMX6.

The Broadcom part in the RPi was heavily subsidized. Don't be fooled by price here.

[agumonkey]

Yes but still, at that time these SoC alone were above the rpi board price point. If you wanted to sell something aronud 30 you had to do vendor tricks with odd parts.

[joezydeco]

Yes. Embedded engineers do this every day.

BTW the Broadcom part is heavily subsidized.

[nitrogen]

Subsidized by whom? Who is losing money on the RPi?

[ZenoArrow]

>"anti-open source CPU cores"

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.

[pjc50]

> Sadists

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

[joezydeco]

I know this is still heresy even though we're long past the "RPi is an educational tool for kids!" phase...but you have other choices.

[rektide]

I still use a lot of the Marvell Kirkwood units I had from 2009 or so. My first was a OpenRD board which was I think like $160, but there was a ton of low-end NAS & other gear. My favorite unit was the Iomega iConnect, a simple unit having a plush 512MB flash, 256MB ram, 4 USB ports, gbit ethernet, and an Atheros chipset, and could be had on ebay for $65. Havent had any running for a while, but for a good while these were all over the place.

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.

[koz1000]

Sometimes talking to RPi developers is like talking to coffee drinkers that only visit Starbucks.

You can't convince them that there's a bigger world of options out there that can be better for your particular application.