hardware

warning: Creating default object from empty value in /home/gwolf/drupal6/modules/taxonomy/taxonomy.pages.inc on line 33.

«Almost free» — Some experiences with the Raspberry Pi, CI20, BananaPi, CuBox-i... And whatever will follow

Submitted by gwolf on Fri, 06/12/2015 - 19:46

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

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.

This side up — Finally

Submitted by gwolf on Sat, 11/20/2010 - 23:38

Can I count myself in a majority of people that feel that, while the USB standard is a great advance regarding the way we used to connect our stuff to the computer some years ago (when we used a different cable for every friggin' device we had, and we had to care about having only one parallel and two seral ports in regular configurations, and don't even get me started on port settings — speed, parity, etc.), every time we hold a USB cable in our hand we feel one of the designer teams decided to play a prank on humanity by making the connector's orientation basically unguessable?

By the frustration this square thingy inflinges on us (being any other decent cable used on a computer either have a visually recognizable shape or just round and thus omnidirectional) I think that the rate by which I get the connector with the correct side up (or front, or right, or whatever) is way lower than 50%.

Anyway, I found that the standard does provide for a (IMO quite dubious but still better than guesswork at the port) way to distinguish which way up - Quoting from Wikipedia's entry on USB connectors:

(…)The side of the connector on a USB cable or other product with the "USB Icon" (trident logo) should be "visible" to the user during the mating process.(…)

Officially, the USB 2.0 specification states that the required USB Icon is to be "embossed" ("engraved" on the accompanying diagram) on the "topside" of the USB plug, which "provides easy user recognition and facilitates alignment during the mating process."

There are several caveats which make this less than ideal, some of which you already thought of, some others are in the referred article and I won't reproduce them. I am just amazed that... USB has been around for almost 15 years (and has been the most popular connection type for ~10 years). And I have never seen anybody apparently knowing this rule.

This was a public service announcement in the hopes you will be happier people armed with its knowledge.

No sense in caring for a hard disk

Submitted by gwolf on Fri, 08/27/2010 - 17:28

  1. Aug 27 06:00:15 lafa kernel: [7218302.960003] sd 1:0:0:0: [sdb]
  2. Add. Sense: No additional sense information
  3. Aug 27 06:00:15 lafa kernel: [7218302.960003] sd 1:0:0:0: [sdb]
  4. Sense Key : No Sense [current]

My hard drive does not currently make any additional sense.

( categories: )
Syndicate content