Musings from kb8ojh.net

Wed, 23 Apr 2014

My parallella is here!

by on :

I was a backer of the AdaptevaParallella Kickstarter campaign way back in 2012. Parallella is a development board for Adapteva's Epiphany processor line, which is a massively parallel (though initial silicon is limited to 16 or 64 cores, the design is intended to scale to 4096 cores) coprocessor with an impressive FLOPS/IOPS-to-the-watt figure. The 16-core board I signed up for is 32 GFLOPS at 2 W maximum power consumption.

Despite a number of (long) delays in finalizing the board and then again in production, my board arrived early last week. I haven't had a lot of time to look at it yet (and I don't know when I will), but I'm including here a bit of a first impression and some hints on how to get it rolling.

Setup

The first thing I did when I received the board and started looking into getting it running was cringe at the number of plug-ins and peripherals and cables that I was going to have to round up to get it booted. Fortunately, what the (obvious) documentation wasn't telling me was that I didn't need any of that stuff — which included things like micro-HDMI and USB OTG cables. What I did have to find was a wall wart capable of 2 A at 5 V, which I was fortunately able to buy off the junk shelf at a local computer store, and a micro&nbps;SD card. The card I got is a 16 GB Class 10, but it seems to be pretty pokey. It was also cheap, so OK. The power connector, by the way, is a type “M” at Radio Shack (2.1 mm ID, 5.5 mm OD).

Ultimately I booted the device with only the aforementioned SD card and a 3.3 V serial breakout. I realize that for some people the serial breakout might be a bigger stopper than a micro-HDMI cable, but I happened to have one of these serial cables on hand (don't let the description fool you, it has nothing in particular to do with the Pi!). If you do have a Pi, you could cable the two boards' serial ports together directly, as well. The correct wiring for that adapter onto the Parallella serial header (which is beside the Ethernet jack) is with the black wire at the board edge, green wire on the center pin, and white wire nearest the Ethernet. Do not connect the red 5 V wire anywhere!

With the serial cable installed, you should be able to see U-boot messages by running screen /dev/ttyUSB0 115200 (substituting whatever serial port device your dongle shows up as) and booting the Parallella with no SD card installed. Assuming that works, it's time to install Linux on the thing!

I opted to install the default Linaro image with the “headless” boot image. I followed more or less the “Method #2” instructions on the Parallella card creation page, with the exception that I fetched the headless boot image from the Parallella github page (rel.14.03.06-headless.tgz as of the time of this writing) instead of the boot image linked from the instructions. I then prepped the card and booted it normally, which (surprisingly and disappointingly) dropped me directly to a root prompt on the serial port!

The Linaro boot image has a number of unwanted (to me) “features” with respect to configuration and account management, as it comes out of the proverbial but non-existent box. Account management is tricky for installer-less images, since you have to let your user log in somehow; however, the Linaro image goes a bit too far in that it provides you with two methods — a predefined user with a known username and password (linaro/linaro) and a root prompt on both the serial console and tty1! So, the first thing you're going to want to do is give yourself a way to log in, a way to achieve root access, and then disable these things.

I simply used adduser to add a user account for myself, then vigr to add myself to the sudo group and a variety of console groups while removing the linaro user from the same. After verifying that that login worked (via ssh), I then used vipw -s to disable the linaro login by changing its password to *. Removing the root logins took just a little bit more digging, but it turned out to be as easy as editing /etc/default/autogetty and removing the contents of the AUTOGETTY_ARGS environment variable. This reverted both the serial console and tty1 to regular getty login prompts.

Impressions

This board is pretty neat, there's no doubt about it. It is almost exactly (possibly exactly) the same form factor as the Raspberry Pi, and in fact clips very nicely into a half-shell for the Pi that I had laying around. Getting it to the point where I could log in and poke at it was simple, and running a sample program on the Epiphany processor was similarly trivial. There are some neat projects underway to use the Epiphany for cool things (I am in particular interested to see where the SDR efforts go), and while there were some growing pains with the tools early on it looks like OpenCL is basically Just Working these days.

As Adapteva notes, this thing runs hot. Like, burn your finger hot. They ship it with a tiny heat sink for the Zynq processor/FPGA chip, but my Epiphany also runs extremely hot; I haven't heat sinked it yet, but the local computer store has some RAM sinks that I believe will install without touching any other components, and I plan to put one on it. Adapteva also recommends some forced air flow, and I would, too. Without a fan, the copper pours on the board itself even get warmer than I would prefer.

There are some unfortunate physical aspects to the board. For example, while I haven't done any heat load calculations or anything, I would be quite surprised if the Epiphany and Zynq chips aren't too close together for their combined dissipation. If I were going to run the board hard, I would worry about that. This is exacerbated by the fact that there are some physically large 0.1 μF capacitors immediately adjacent to these chips on the top side of the board, making a large, flat-bottomed heat sink problematic. I understand that a second board revision taking these concerns into account is on the way (and in fact the problematic capacitors are specifically called out in a post on the Adapteva forums describing the next-gen layout), and I would be happy to see that. In the meantime, I'll sink my Epiphany and set a fan where it can blow across the board.

tags: embedded, floss, parallella
path: / | permalink | Comments

Sun, 16 Mar 2014

A new PGP key and a public identity tool

by on :

I've been generally refreshing my crypto keys and practices lately (new, stronger disk encryption configurations, new SSH keys, etc.), and I've finally worked my way around to PGP keys. I've had a number of PGP keys over the years (four that I still have tabs on, and three that remain relevant), and generally, I feel, managed them well. However, I've never had a coherent, published key management policy; with this new key, I have produced one.

The new key ID is A1A8 ED0E, and it is available here as well as on the common key servers. The related policy is here, signed by the key. It applies from here forward to my previous key, 771F C72B, but obviously cannot be applied retroactively. My older but still relevant key, 883C 1C14, has been revoked and should not be used for any purpose other than verifying preexisting signatures (for which it is valuable, as it is moderately well-connected).

Both of my active keys (771F C72B and A1A8 AD0E) as well as my key management policy are now linked from my home page.

In other news...

Geoff Lane introduced me to Keybase, a social media-inspired public key crypto identity and management interface. It consists of a web service with both a web site and CLI frontend that ties together social media accounts (right now, just Twitter and Github) with PGP keys. Users can be looked up by their Keybase username, their identity verified either via PGP key or Keybase ID, and their associated social media accounts thereby verified. The command line client offers a simpler interface to PGP encryption and authentication, assuming you plan to communicate with other Keybase users.

I'm not sure what I think of the system, yet. It's not exactly a key verification system; it appears that verification and signatures are based not on the other user's crypto keys, but on their Keybase ID, which includes their key ID among other fields. This means that it doesn't directly extend the web of trust. On the other hand, it's probably good that it doesn't directly extend the web of trust, because key verification is rather abstracted and the interface almost encourages verifying users by their social media identity rather than their key identity. It also appears to be able to track only one key per user.

That said, Geoff and I had a conversation recently about how difficult and opaque key verification and building crypto relationships are, and this platform shares some features with the ideas we discussed. It will be interesting to see what kind of adoption it sees and, critically, what kind of email/etc. integration appears. For now, they're in alpha stages and it's too early to tell. I can say that the web interface is slick and the social media account verification tools are interesting. (Basically you post a proof-of-identity JSON object signed by your PGP key (or digest thereof, in the case of Twitter) to a public place on the social media network, and then Keybase verifies it.)

In the meantime, my Keybase ID is https://keybase.io/elb. If you receive an alpha account (or the service goes public), please verify me and connect.

tags: encryption, keybase
path: / | permalink | Comments

Fri, 07 Mar 2014

et 0.2.0 is out

by on :

I have just released version 0.2.0 of my time tracking tool, et. This release adds a bit of polish (and some bug fixes) to 0.1.0, the initial release, which was just finished enough to use for time tracking.

The et home page has download information, and the ChangeLog is here.

tags: et, floss, software
path: / | permalink | Comments

Wed, 05 Mar 2014

Words of Radiance: A story of fan-friendly publishing

by on :

just released the second book in his series The Stormlight Archive, Words of Radiance. Mr. Sanderson is an author who seems to Get It regarding the modern age of content. I don't know how it's working out for him financially, but I certainly hope well. He's done it again, though — Words of Radiance is available, simultaneously, in hardback, e-book, and audiobook, including e-book sales on multiple providers (e.g., Kindle, Nook, Kobo, and third-party shops) and without DRM, and audiobook sales of a similar state.

This is refreshing to see for many reasons, but let me enumerate a few. First, the e-book and the hardback book are both treated as first-class citizens; neither class of purchaser need wait for no reason. Second, the availability of e-books from multiple distributors in multiple formats is fantastic, as it avoids vendor lockdown. Third, DRM-free ensures that fans can read the book for as long as they have possession of the bits — without being tied to a provider that may disappear, change technologies, or otherwise become unreliable.

Point one is just a nice thing to do. Points two and three are much bigger. I am personally very glad to see third-party e-book vendors providing the book, because I have a healthy distrust of some first-party vendors. (*Ahem* Amazon, how about that 1984? I won't be buying e-books from them any time soon...) DRM-free is a similar story — although, fortunately, it looks like DRM-free content is slowly “winning” on a lot of fronts. When Apple chose to make the iTunes store DRM-free and forced the music distribution model, that put a lot of power into the hands of consumers.

I for one already have my DRM-free e-book ready to go (purchased from Dragonmount, and I look forward to enjoying it.

tags: books, drm, freedom, trust
path: / | permalink | Comments

Sat, 01 Mar 2014

The Raspberry Pi graphics chipset is (partially?) open now

by on :

The Raspberry Pi Foundation just announced that after two years of production, the VideoCore IV 3D graphics engine on the Pi has an open specification. This is pretty huge news — the Pi has required a binary blob graphics driver that runs on the multimedia coprocessor with a thin “open” shim over it on the main CPU since its inception, which means that its graphics stack was, for all reasonable intents and purposes, entirely closed.

The shim between the primary kernel and coprocessor drivers was open-sourced in late 2012, which was also a huge step forward; it allowed non-Linux operating systems to be ported to the Pi with some hope of usable performance. Since then, ports of numerous systems such as Plan 9 and the BSDs have appeared on the Pi. It's not yet clear (to me, at least) what direct effects opening the GPU-level graphics drivers will have, but certainly the philosophical value is enormous.

Here's to the Pi, a happy second birthday, and the next two years of openness and improvements!

tags: embedded, floss, pi
path: /links | permalink | Comments

<<  Page 5 of 7  >>
[ | | ]