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.
>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.
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?
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.
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?
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)
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.
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?
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).
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).
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.
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.
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.
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.
> 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'?
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.
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.
Did they give you copyright and patent licenses allowing you to do whatever you wanted with their tech? Or did a cloner have to hope the company would take no legal action?
Because that's still not equal to an open-source design where the licensing eliminates such risks.
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.
"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.
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.
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.
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.
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.
> 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.
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.)
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:
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
I confess. I'm completely ignorant about the Raspberry Pi even though I have a 3rd generation I bought recently. So I don't really understand what the significance of "Blobless Linux" is.
Is the Raspberry Pi an open-source software and hardware platform? If not, what is? What should I have bought if not the Pi3?
> Is the Raspberry Pi an open-source software and hardware platform?
No, the hardware isn't open, and not all of the software is, either. It requires a closed-source blob of code to boot the system. There's "real" firmware in the VC4 chip, which is the first part of the Pi to come up, some binary blob bootloader files, and drivers handling graphics and hardware decoding that are still closed. There is an open-source 3D driver, but it's missing some capabilities from the closed one (hardware accelerated video decoding), but includes some extras (some degree of support for non-mobile OpenGL).
The chips from most other vendors are at least bootable without blobs, even if video output won't be properly accelerated.
There is no sane reason which would explain why you should not have bought a Pi. Open or not it would not make any difference to more than a small room full of people. A bunch of people spent years designing hardware and negotiating with people to get the Pi built at a low cost and it's become the best selling UK computer ever with over 10,000,000 sales. It's succeeded at what it was supposed to do; provide an educational platform for kids.
Counterpoint: The pi runs Linux inefficiently, draws too much power and gets too hot. All of these could probably have been fixed with minimal support from broadcom (and a bit more open thinking from them during the design).
Open source is not a crazy idea by a bunch of fanatics, it had real world implications.
>All of these could probably have been fixed with minimal support from broadcom (and a bit more open thinking from them during the design).
Support from Broadcom is unlikely to fix it, the BCM283x family of SoCs are just a huge mess and in my opinion are either suited for really specific applications (TV boxes) or as "toys".
The ARM core itself is integrated very poorly almost as an afterthought, since it wasn't in the original design, the BCM283x family is just BCM27xx family VideoCore4 VPU+QPU combinations with an ARM core hacked (and I really do mean hacked) on top.
Yes, 2837 is a 1995 soc design with a 64-bit quadcore forced into it. Their multicore support was probably thrown together in an afternoon by a junior asic designer on a hangover.
But some of the issues could have been worked around with better documentation.
It's really doubtful that more than a tiny fraction of RPi sales have gone to kids. Be honest here, whatever the RPi Foundation's marketing, the overwhelming majority have gone to hobbyists.
The RPi is uniquely unsuited to an educational environment anyway. The SD cards are unreliable, especially in combination with the RPi's poor power filtering and the cheapo phone adapters it's usually paired with. Anyone who has used a RPi has had to deal with filesystem corruption and SD card failures, intermittent USB bus brownouts, etc, and I can only imagine the nightmare of having to maintain a lab with 50 of the things. You can't PXE boot them (let alone remote-manage them) because they have no BIOS, just a blob on a physical card that needs to be swapped out.
The Pi should have had eMMC day one, and shipped with a proper power adapter and better power filtering. But much like their choice of Broadcom SoCs - they made a political decision that they were going to market primarily around the $35 price point, and so they cheaped out on $5-10 worth of hardware and ended up with a device that was entirely unsuitable for their stated purpose.
And the terrible thing is - the PC is not the sole component in the system anyway. The Pi still needs a case, a a monitor, keyboard, switches, etc, and if you are trying to stand up a lab for the first time it's not like you have 50 monitors or keyboards laying around for free, you need to buy those. So you are looking at more like $150 per system anyway, and the $10 you save on cheaping out on the hardware becomes a meaningless fraction of the total cost. Just buy the right hardware the first time. An ECS Liva is only like $75 anyway, it comes with a case, onboard eMMC, AC adapter, and wifi, you've made up the difference in cost in accessories included in the box.
There were many other terrible design decisions as well - such as the choice of USB as a system bus, which is again entirely unsuitable, especially when you are running on a low-power processor where running the USB bus full-tilt eats a significant fraction of your CPU cycles. It's like that shitty Mac Performa x200 road-apple design with the split half-width left-hand/right-hand busses which couldn't talk to each other, it eats up all your cycles by just using your disk or network. Even if the processor on other boards is no faster in synthetic benchmarks - they have a proper system architecture with SATA and often USB 3.0 and gigabit ethernet that makes an enormous difference in real-world performance.
Furthermore - the Pi was plagued by driver problems with its USB stack for years. It would randomly drop USB frames when operated at USB 2.0 speeds, and it took upwards of 2 years after launch for the Pi foundation to get around to pushing a fix (again, because they chose a processor for which they could not release documentation, and they did not employ enough staff to actually fix their issues). How on earth are you supposed to do education on it when they can't even get their system bus to be stable?
You know what I would do if I was running an actual lab? ECS Liva Xs, or other cheapo x86 PCs running a standard stack. Or go down to your university surplus store and pick up as many generic Dell boxes as you need for $50 apiece, out the door, ready to work. The Pi is good for embedded hobbyist work (the i2c interface is very powerful), but it totally fails as a machine for teaching programming compared to Ye Olde White Box.
I tried to run a pair of RPis as my fileservers for about a year and a half, and I finally just gave up and sold them. They aren't good for the "mini Linux PC" application at all, compared to properly-designed hardware that you can buy for only a little bit more money (or sometimes even less money, especially when you work out the total system cost).
(note: Pi3s can finally PXE boot without a SD card, which is like the bare minimum requirement for running an educational PC lab without going insane)
I'd love someone knowledgeable to explain why this happens. According to general opinion on the RPi forums, it's because SD card manufacturers cheap out all the time.
I'd have something like a dozen SD cards running things like cameras over the years, and probably a hundred booting ESXi servers. And I've never seen a failure.
Across three RPis, I've bought about seven SD cards, and from everything RPi users tell me, that's a totally normal failure rate.
Edit: In regards to cheap whiteboxes, no such options allow access to GPIO ports. I've learn plenty of interesting things about soldering circuits by having these, without considering the Pi a PC learning tool.
In regards to cheap whiteboxes, no such options allow access to GPIO ports.
The parallel port on older PCs works reasonably well as GPIO; you can get expansion cards for those which don't have one (they seem to have gone up in price now but they used to be extremely cheap.) Since this is an actual external interface it will be more robust than the GPIOs directly connected to the SoC of the RPi, and if you use expansion cards you can just swap them out if they do get damaged.
> Across three RPis, I've bought about seven SD cards, and from everything RPi users tell me, that's a totally normal failure rate.
Sounds about right. I went through maybe 4-6 cards on 2 Raspberry Pis in a year and a half.
> I'd love someone knowledgeable to explain why this happens. According to general opinion on the RPi forums, it's because SD card manufacturers cheap out all the time
SD cards are basically uniquely ill-suited to be used in a Raspberry Pi.
First off, cheap SD cards have no wear levelling. The flash controllers are super primitive. They are designed to be written sequentially until full, and erased, like you would use a camera. A regular Linux operating system is not designed to moderate its writes, it will happily do all kinds of work and logging on /var and other places, doing tons of heavy random writes that put tons of wear on the card (write amplification/etc), and there is no levelling taking place. The flash cells just burn out.
Real mobile OSs are much smarter about what they write to flash, and they have eMMC that usually has at least a slightly smarter controller optimized for more random-ish loads, and/or is totally under the CPU's control with a filesystem designed to work with flash.
Next, flash doesn't like to be powered off during erases or writes. In some cases it can actually corrupt operations that were successfully completed. The flash cells do not get as much charge as they should and can decay prematurely.
Nor does flash like operating under questionable power conditions either. The flash can think it's successfully completed the operation, the processor will keep on trucking, but if the voltage drooped too much, the write doesn't persist. In some cases, this can cause the flash to get trapped in a "bricked" state that needs a hard reset to clear properly (which can't be done with a SD card).
The Pi also has no/very little power filtering. Your phone doesn't ever run off the charger. It uses the adapter to charge the battery and/or feed the regulator circuit, the key being there is a regulator circuit here. The Pi does not have one.
In short - the Pi is an absolute worst case in terms of power. Your average camera or phone has a battery, so the power is clean, full-on power faults are quite uncommon, and the device can monitor voltage and stop doing writes before things get critical. Not only is it really, really easy to accidentally or purposefully unplug the Pi, or flip the power strip off, but the shit-tier phone chargers that get used with it have terrible power filtering and tend to have wildly insufficient power delivery capacity. Under load, the voltage droops and the noise on the power line gets pretty intense.
With the first-gen Pis, there was an additional physical issue with the SD cards. The cards are just made of plastic, they are meant to go into a slot in a camera or phone that physically supports them, they are not intended to just hang off into space. The Pi does actually get fairly warm, especially if you have it in a case, and hot plastic warps. The card loses contact half-way through a write and there goes your file system.
Adding a "UPS" board that can command a soft-poweroff, a decent microSD card (Samsung EVO are reputedly the most reliable on a Pi), and a "low-profile" microSD adapter that doesn't hang off into space quite as much reportedly make a pretty big difference in reliability, as does using a purpose-built adapter from a reputable vendor like Adafruit or something. Not running it in a case probably helps too.
Again though, once you spend the money to fix the flaws, you could just buy something that just includes what you need to boot up right in the box.
I really can't emphasize enough how much all of this is actually the result of poor design. If the Pi Foundation would have chucked a 2 GB eMMC chip on there and added a barrel connector and a decent power supply, these issues would be essentially eliminated. And IMO the issues are pretty much show-stoppers for any chance of reliable operation.
> In regards to cheap whiteboxes, no such options allow access to GPIO ports. I've learn plenty of interesting things about soldering circuits by having these, without considering the Pi a PC learning tool.
That's definitely true, but you can also buy a Bus Pirate that will be capable of adapting most simple embedded units to any PC.
You really only need the Pi's GPIOs when you are doing something that involves really high throughput or really low latency. The examples I've heard are video streams and using a GPS board as a reference for an NTP server - they exist, but for your every day "talk SPI/I2C to a sensor" or "count freqency counts from a sensor" the Bus Pirate does very well.
>it uses the adapter to charge the battery and/or feed the regulator circuit, the key being there is a regulator circuit here. The Pi does not have one.
Wait, what? Of course the RPi has voltage regulators. Do you think the Broadcom chip runs at 5V? There's a LP2980-N and NCP1117 shown in the schematic.
Yeah, and microSD cards run at 3V3. The problem is that a phone usually has better filtering capacitors, which the Pi lacks and thus any noise from the power line directly goes from 5V down to 3V3. Oh, and people usually buy the 2-5$ range of power adaptors from Amazon, I'm amazed that no one has managed to burn down their house with this stuff.
>The problem is that a phone usually has better filtering capacitors, which the Pi lacks and thus any noise from the power line directly goes from 5V down to 3V3.
The RPi has filtering capacitors. In general filtering capacitors are regular cheap X5R or X7R caps. They don't need to be anything special. Look at any LDO regulator datasheet.
> Oh, and people usually buy the 2-5$ range of power adaptors from Amazon
What does that have to do with the designers of the RPi? They don't have any control over which power supplies people buy.
It's hard to specifically assign blame to noise since it's such a personal and transient problem, but as a general statement power quality is one of the biggest problems with the Raspberry Pi and I strongly suspect that the Pi is not really equipped to tolerate 270mv swings as are seen on cheap USB adapters. Phones deal with this quite fine, but the Pi has less filtering and if anything is doing things that are much more sensitive to noise due to its OS.
> What does that have to do with the designers of the RPi? They don't have any control over which power supplies people buy.
You shouldn't have to buy a power supply at all. The norm is that when you buy a piece of hardware it comes with an appropriate power supply. When I buy a $15 gigabit-ethernet switch from D-Link, it comes with a power adapter.
Again, the Pi Foundation wanted to hit their price target so they could put "A computer for $35!!!" in their advertising, so they cheaped out on something that probably costs $2 when you are buying a million of them. At quantity 500, you are already down to $4 when sourcing them from Mouser.
They also pretty much openly encouraged you to use whatever crappy USB charger you had lying around. The reality is most knockoff chargers are total crap, their current ratings are dramatically overinflated, and they certainly won't be delivering clean power anywhere near their current ratings, which again amplifies the problems with the Pi's lack of filtering.
All of this has been well-known for ages. Check out Ken Shirriff's excellent series of teardowns on cheapo USB chargers and his comparison to a genuine Apple charger. This was not news even at the time.
>but as a general statement power quality is one of the biggest problems with the Raspberry Pi and I strongly suspect that the Pi is not really equipped to tolerate 270mv swings as are seen on cheap USB adapters. Phones deal with this quite fine, but the Pi has less filtering
What is your source for all these statements? How do the voltage regulation circuits in phones differ? If anything the phones ought to have more noise, since they're using switching regulators rather than linear regulators.
>Again, the Pi Foundation wanted to hit their price target
Yes, you got it. There's 1001 improvements that could be made to the RPi. If you made all of those improvements, it would not be affordable.
>They also pretty much openly encouraged you to use whatever crappy USB charger you had lying around.
They say to use a charger that's rated for at least 2.5A. That does not include most crappy phone chargers. They also sell an official RPi power supply which anyone is free to buy if they're concerned about this issue.
> What is your source for all these statements? How do the voltage regulation circuits in phones differ? If anything the phones ought to have more noise, since they're using switching regulators rather than linear regulators.
It's pretty self-evident that the circuits are different. The phone normally operates from its battery, the amount of ripple present from a battery is zero. I'm not sure what source exactly you want me to provide to cite the fact that a phone has a battery, anyone knows that.
Also, typically a phone will use a buck converter (or perhaps buck-boost) to drop its voltage, rather than a switching regulator.
Some phones do have problems operating while plugged into crappy adapters (the power does pass through), the most common being that the touchscreens stop working.
> Yes, you got it. There's 1001 improvements that could be made to the RPi. If you made all of those improvements, it would not be affordable.
And yet any network switch you buy off the shelf for $15 comes with a workable power supply.
But yes, that is my point, the parent was asking for reasons why you wouldn't buy a Raspberry Pi, and the fact that it's got a shitty power system that tends to result in SD card corrupt is a major reason you should not purchase a Pi and prefer a properly engineered product. I think we're in agreement.
The Pi Foundation themselves cite the cost of the switching-mode power supplies on their alpha boards as adding $2 to the bill-of-materials cost, leading to their decision to remove them from production boards. Terrible anti-consumer move, how much have you spent on burned-out SD cards so that they could hit their $35 price point?
Anyway, any random piece of electronics comes with a power supply. A $15 network switch comes with a power supply, or a drive enclosure (those are even quite beefy ones!). Competing products like the ECS Liva come with their own power supplies too, and the total cost of the system is the same as the Pi.
> They say to use a charger that's rated for at least 2.5A. That does not include most crappy phone chargers.
They've backpedaled on this since the launch after problems started appearing. The official spec at launch was that the Pi pulled 700ma for Model B and 300ma for Model A, and pretty much any random charger meets that spec. Anyway, most chargers are significantly overstating the amount of clean power they can provide, because they expect the phone to be using them for charging, not for operating.
> I'll be testing PSUs soon as well, although maybe not as thoroughly. It certainly seems that the Foundation may have been wrong in assuming that USB chargers produce the current they say they do and that all USB cables are reasonably constructed.
The fact that $1.99 adapters you get off eBay were built like shit wasn't a shocker to anyone, even at the time. That's a hilariously naieve assumption for them to make.
> They also sell an official RPi power supply which anyone is free to buy if they're concerned about this issue.
This only launched within the last year. Good on them for finally doing it, but it should be included with the device, and should have been included from day 1.
> The phone normally operates from its battery, the amount of ripple present from a battery is zero. I'm not sure what source exactly you want me to provide to cite the fact that a phone has a battery, anyone knows that.
I was asking for a cite on the claim that the phone has a better voltage regulation circuit. AFAIK both the RPi and phones are using jellybean switching regulator ICs to convert and regulate the voltage. Even an expensive switching regulator is going to have a hard time competing with the PI's linear regulators in terms of output noise. (The Pi, of course, can afford to waste a bit of power, whereas the phone needs to juice all of the battery capacity.)
>Also, typically a phone will use a buck converter (or perhaps buck-boost) to drop its voltage, rather than a switching regulator.
Erm, a buck converter is a kind of switching regulator (one that drops rather than increases the voltage). See for example the buck/boost/etc. options under 'Topology' in Mouser's switching regulator category, or the Wikipedia definition:
>Some phones do have problems operating while plugged into crappy adapters (the power does pass through), the most common being that the touchscreens stop working.
This undermines your point that phones somehow have better voltage regulation circuitry than the RPi. Many that will run directly off USB power have exactly the same issues.
>Good on them for finally doing it, but it should be included with the device, and should have been included from day 1.
But why are you still advising people not to buy the Pi because of power supply issues? I bought my first Pi a few months ago and made sure to get an adequate power supply (not difficult). I haven't had any problems.
>and so they cheaped out on $5-10 worth of hardware
The problem is that if you keep not cheaping out on $50-10 worth of hardware, you end up with something that costs $200. Everyone has their own pet peeve with the RPi which could be fixed for an extra $5.
> It's really doubtful that more than a tiny fraction of RPi sales have gone to kids. Be honest here, whatever the RPi Foundation's marketing, the overwhelming majority have gone to hobbyists.
That's great, the hard work put in by hobbyists has made the Pi an even better platform to teach the kids. And their purchases have helped financially support the educational mission. I say this as a hobbyist who started out picking up a Pi and has now directly taught kids.
> The RPi is uniquely unsuited to an educational environment anyway.
A traditional educational environment, maybe, but it's exactly those environments that have made computing such a dry and uninteresting pursuit in the first place. The computer lab at my school and college was tragic. I can only imagine how much I'd have loved to hack on a Pi, and I'm glad to be a small part of the effort to make that opportunity available to present and future generations.
> The SD cards are unreliable
I've used Pi's non-stop since day 1, and it's been a large part of my career for over 3 years. I can count the number of SD card failures I've had on one hand. I've never been particularly careful about shutting them down. I have two running on my desk 24/7 for development/testing. We've have two running in our post room, hard powered on/off every single day for 2 years. I think reports of unreliability are greatly exaggerated.
> the cheapo phone adapters
There's an official Pi power-supply for that. I certainly wont argue that terrible phone adapters are a problem though. It was the answer to every problem report on IRC for years :D
> You can't PXE boot them
The Pi 3 can PXE boot and boot without SD cards from, albeit not all, hard disks and other USB-attached storage.
> The Pi should have had eMMC day one
I think the cost of this wouldn't have helped with traction.
> shipped with a proper power adapter
Yup! Albeit, cost again. And, arguably, there are pretty good reasons not to ship a microUSB power adaptor, since most of us already have a tangled mess of them anyway from a dozen past phones. It's just unfortunate the phone ones were/are awful.
> The Pi still needs a case
It doesn't need one, but they look pretty :D Incidentally it's because someone recognised the demand for a case that I have a job that I love. Oh and people love to accessorize, so the ability for a customer to choose one to their liking is often a positive part of the experience.
> a monitor
Most people had an HDMI TV, but in retrospect the inclusion of HDMI/RCA led to a whole aftermarket of HDMI->VGA adaptors since schools are stuck in 1998. I think it's important to reinforce that learning doesn't, and absolutely shouldn't, only happen in schools.
> a proper system architecture with SATA and often USB 3.0 and gigabit ethernet
To hobbyists, maybe, but then they'd have cost $100 and been another unsung bit-player like the BeagleBone Black (Disclaimer: I loved the BBB). The Pi's biggest success was shaking up market, perhaps even creating one, and gravitating a whole bunch of people to a common cause. They also proved there was a market, so now if you want those things, there are plenty of alternative choices! And then they did it again with the Pi Zero- blatantly giving the market an "we're not going to watch you hit $9, $8, $7, $6 price points just for headlines. Get to the point" shakeup. You don't have to buy a Zero, but you'd be on rocky ground if you tried to argue that your options aren't better because of it.
> Furthermore - the Pi was plagued by driver problems with its USB stack for years
Ugh. shudder memories! But largely irrelevant these days.
> it totally fails as a machine for teaching programming compared to Ye Olde White Box.
Having run several workshops using the Pi, and contributed to more, I disagree. If for nothing else other than it's different enough to not simply put people off from the get-go. "Learn programming on these boring old white boxes" is not nearly as exciting as "learn to interface the real world with minecraft on credit-card sized computer." The low cost and educational push has also enticed a wave of enthusiastic geeks out of the woodwork, eager to teach anyone who'll listen. I know and deeply respect many of them, and I've had tremendous opportunity to make a positive impact on people's lives that perhaps I wouldn't have ever realised without the Pi.
> I tried to run a pair of RPis as my fileservers for about a year and a half
Yup. They are totally awful for this purpose, or at least just barely adequate, but that doesn't reinforce that they're awful at everything else.
> running an educational PC lab
I think you perhaps have too narrow a definition of education. I think the Pi excels because it fascinates people outside of a sterile classroom environment. Nobody is going to build and battle a robot, or create a 20 square foot version of whack-a-mole, or make a power-glove controlled robot arm, or a "disco" button that explodes their living room into song and light... out of a bunch of computers PXE-booting and tethered to ethernet.
The effort put into Blobless linux is itself a fantastic example of people using the Pi to push their own boundaries and learn things. And you say it's failed at being educational? Nonsense.
If your use case is for a low power server, something that many people seem to do, then a Raspberry Pi is suboptimal.
Something based on the Allwinner A20 makes a good choice as the SoC has an integrated ethernet (10/100) and SATA controllers, which means no USB-to-ethernet or USB-to-SATA half-arsery.
I am running an old A10-based Mele A2000 with wired ethernet and a 1 TB SATA HDD as a home server. Stock Debian with a mainline kernel and mainline u-boot 'just works' if you want to run a headless server.
If you want some GPIOs and other pins broken out, look at boards from Olimex [1] or Itead [2] or Cubie [3].
Stupid question: does this now mean that you can boot a RPi to Linux with zero blobs involved?
Additional question: does anyone have a list of devices that you can boot without any blobs involved? E.x. if someone wants to go "full Stallman" what are the options to do that?
We have considered it, however, because there's still a need for a firmware, the first stage bootloader and the firmware itself are using a common driver framework, it just makes things easier. Besides, the firmware will later run an RTOS (for example LittleKernel) and Uboot doesn't provide RTOS-like services.
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.