«Almost free» — Some experiences with the Raspberry Pi, CI20, BananaPi, CuBox-i... And whatever will follow
I know very little about hardware.
I think I have a good understanding on many aspects of what happens inside a computer, but my knowledge is clearly firmer on what happens once an operating system is already running. And even then, my understanding of the lower parts of reality is shaky at most — At least according to my self-evaluation, of course, comparing to people I’m honored to call “my peers”.
During the last ~18 months, my knowledge of this part of reality, while still far from complete, has increased quite a bit — Maybe mostly showing that I’m basically very cheap: As I have come across very cheap (or even free for me!) hardware, I have tried to understand and shape what happens in levels below those where I dwell.
I have been meaning to do a writeup on the MIPS Creator CI20, which was shipped to me for free (thanks++!) by Imagination Technologies; I still want to get more familiar with the board and have better knowledge before reporting on it. Just as a small advance, as this has been keeping me somewhat busy: I got this board after their offer to Debian Developers, and prompted because I’ll be teaching some modules on the Embedded Linux diploma course dictated by Facultad de Ingeniería, UNAM — Again, I’ll blog about that later.
My post today follows Riku’s, titled Dystopia of things, where he very clearly finds holes in the Internet of Things offering of one specific product and one specific company, but allows for generalizations on what we will surely see as the model. Riku says:
Today, the GPL sources for hub are available - at least the kernel and a patch for busybox. The proper GPL release is still only through written offer. The sources appeared online April this year while Hub has been sold for two years already. Even if I ordered the GPL CD, it's unlikely I could build a modified system with it - too many proprietary bits. The whole GPL was invented by someone who couldn't make a printer do what he wanted. The dystopian today where I have to rewrite the whole stack running on a Linux-based system if I'm not happy what's running there as provided by OEM.
This is not exactly the situation on the boards/products (it’s a disservice to call the cute CuBox-i just a board!) I mention I’m using, but it’s neither too far. Being used to the easy x86 world, I am used to bitching on specific hardware that does not get promptly recognized by the Linux kernel — But even with the extra work UEFI+SecureBoot introduces, getting the kernel to boot is something we just take for granted. In the MIPS and ARM worlds, this is not so much of a given; I’m still treating the whole SPL and DeviceTree world as a black box, but that’s where a lot of the work happens.
The boards I am working on try to make a point they are Open Hardware. The CI20 is quite impressive in this regard, as not only it has a much more complete set of on-board peripherials than any other, but a wealth of schematics, datasheets and specifications for the different parts of its components. And, of course, the mere availability of the MIPSfpga program to universities worldwide is noteworthy — Completely outside of my skillset, but looks most interesting.
However… Despite being so much almost-Free-with-a-capital-F, all those boards fail our definitions of freedom in several ways. And yes, they lead us to a situation similar to what Riku describes, to what Stallman feared… To a situation not really better to where we stand on openly closed-source, commodity x86 hardware: Relying on binary blobs and on non-free portions of code to just use our hardware, or at least to use many of the features that would be available to us otherwise.
As an example, both the CI20 and the CuBox-i vendors provide system images able to boot what they describe as a Debian 7 system, based on a 3.0 Linux kernel (which Debian never used; IIRC the CuBox-i site said it was derived from a known-good Android kernel)… Only that it’s an image resulting of somebody else installing and configuring it. Why should we trust their image to be sane? Yes, the resulting installation is quite impressive (i.e. the CI20’s 3D demos are quite impressive for a system that feels otherwise sluggish, and out of my ARM experience, I’d wager it feels sluggish mostly because of a slow SSD)…
I have managed to do clean Debian installs on most of my ARM machines (the CuBox-i as described in my previous blog post; this post from Elena ``of Valhalla’’ prompted me into trying the already well documented way of running the official Debian Installer, which worked like a charm and gave me a very nice and responsive Debian 8 install — Modulo yes, the Banana’s non-free video interface, which AFAICT uses the non-free Mail binary driver… And which I haven’t had the time to play with yet. Of course, my CuBox is in a similar situation, where it works like a charm as a personal server, but is completely worthless as a set-top box.
So, with those beautiful, small, cheap SoC systems, we are close to where we stood twenty years ago with x86 Linux: Good support for a small set of peripherials, but a far cry from having a functional system with exclusively free software. <a href=”https://linux-sunxi.org/LeMaker_Banana_Pi”As the (great!) Linux-sunxi Wiki says</a>,
Despite claims of being open source, this is not open source hardware. If you are thinking of getting this device, you should also try looking into the hardware from our Community instead.
Still… Playing with these boards has taught me a lot, and has clearly taught me I’m still standing on the first steps of the n00b level. I have a lot to learn to be able to responsibly teach my part of the diploma course, and I’m very thankful for the differences in hardware (and, of course, for the hardware manufacturers, specially for the MIPS Creator CI20 and the Lemaker Banana Pi for giving me boards to work on!)
I shall keep posting on this topic.
Comments
gwolf 2015-06-25 21:28:00
Para el diplomado
Hola Miguel,
Pues… Bueno, no consideraba que usáramos los monitores ;-) Sabes, se trata de usarlos como equipos embebidos, a pesar de que sean tan grandes que tal etiqueta ya no les queda ;-) Prefiero usarlos ya sea por el puerto serial o por red.
Pero sí, si quieres conectarlos a un monitor VGA, hace falta comprar el adaptador. Supongo que los monitores del laboratorio se conectan por DVI (cable de conector típicamente blanco, un poco más ancho que el VGA). DVI es un puerto nativamente digital, por lo que el convertidor a HDMI es más sencillo y barato. Pero… bueno, no pienso que lo utilicemos.
Saludos,
Miguel JT 2015-06-23 21:02:17
Hola intercambio de info para el Diplomado de Linux embebido
Hola próximo profesor del Diplomado Linux Embebido, después de leer su artículo que habla sobre algunas tarjetas con tecnología SoC, usted le pidió a nuestro maestro en turno del DLE nos menciono que vamos a utilizar la tarjeta Raspberry, yo ya tengo una con un adaptador que convierte de HDMI macho a VGA hembra, para poder conectar mi Raspberry a un monitor VGA, el laboratorio donde tomamos el DLE los monitores ni son HDMI ni VGA, nos podría decir si necesitamos comprar un adaptador diferente para conectar a los monitores del laboratorio a las Raspberry he ir los comprando y lleguen en el mismo envío de las Raspberry.