So far, this has been an incredible board to work with, despite some teething pains with the pre-release/early access software and documentation (and a few minor quibbles with the design decisions behind the 96Boards Consumer Edition spec and this first board). It's not in the same performance class as the ARMv8 server systems that we have in the EHL at Seneca, but it's a very impressive board for doing ARMv8 porting and optimization work -- which is its intended purpose, along with providing a great board for hacker and maker communities.

I experimented with the board last week and took some readings at home today, and thought I'd share some of my findings on board current draw and temperatures, because it may be useful to those planning alternate power supplies and considering temperatures and airflows for cases:

Current consumption: The board draws ~120 mA at idle (Linux login prompt) with nothing connected, and about 150-155 mA with a basic USB fast ethernet adapter connected. With ethernet attached and 8 cores doing busy-work (compressing /dev/urandom to /dev/null), current consumption rises to just over 300 mA (297-320). All of these readings are at 12+/-0.25 vdc, so that's under 4W including the USB ethernet. Note that the GPU was basically idle during these tests.

Temperature: In a room with an ambient temperature of ~21C, with all 8 cores doing busy work (8 processes gzipping /dev/urandom to /dev/null, and top reporting 0.0% idle), the temperature on the SOC heatsink rose fairly quickly to ~48C, and eventually reached 52C, measured using an infrared temperature reader (accuracy of +/- <2C).

A couple of other random observations about the board:

The board mounting holes accommodate M2.5 screws. Basic hardware stores, including Home Depot (at least in Canada), do not carry M2.5 screws, so I've been thwarted in my efforts to mount this onto an acrylic plate so far (cases will evetually follow, I'm sure, but I always prefer to have boards on/in something and not sitting directly on my desk). I'm sticking some silicon feet on the bottom as an interim measure.

There is a "USERDATA" partition on the eMMC which is not used by the initial software image. Be sure to format and mount that partition to gain an additional 1.5 GB of space if you're running from eMMC.

I'm looking forward to the release of WiFi drivers and UEFI bootloader support soon, as promised by the 96Boards project.

The Free Software and Open Source Symposium (FSOSS) 2014 is around the corner, and it's shaping up to be the best in years. We have well over 30 talks spread over 2 days, covering just about every corner of open source from new and upcoming technologies through business models. We have a keynote from my colleague David Humphrey examining the implications of Heartbleed, as well as keynotes from Chris Aniszczyk (Twitter) and Bob Young (Lulu/Red Hat/TiCats). There are speakers from Canada, the US, Hungary, the UK, Cuba, and India, representing open source communities, academia, entrepreneurs, startups, and companies such as Mozilla, Cisco, AMD, Red Hat, and Rackspace.

Until October 10, registration for this event is just $40 (or, for students and faculty of any school, $20), which includes access to all of the keynotes, talks, and workshops, two lunches, a wine/beer/soft drink reception, a t-shirt, and swag.

I've packaged the quick2wire python3 library for the Raspberry Pi. This provides easy access to the i2c peripheral bus from Python3; I've packaged this up because I need it, and also to test and demo the package review process for Pidora.

Here's a little demo of the quick2wire library in action which I wrote some time back and have been using as a test for the package -- this reads a TCN75A (data sheet) thermal sensor chip:

# The first byte contains the temperature in degrees # Celsius (actually, this is a signed number, so # values over 127 are negative, but I'm ignoring # that here). The second byte contains 256ths of a # degress, but the default resolution of the sensor # is 0.5 degrees, so it will always be 0 (.0) or 128 (0.5) # unless the resolution is changed. # # This line converts the two bytes into a single # temperature and prints it. print("Temperature: %3.3f°C" % (read_temp[0][0]+read_temp[0][1]/256) )

# Delay half a second before getting next reading time.sleep(0.5)

The package is up for review in Pidora (not Fedora, but only because it's not useful on other platforms -- at least at this time). The package review, including links to the specfile and SRPM, is ticket #495.

I'd love to figure out why my Toshiba Z830's screen-brightness controls work fine after suspend but don't work after hibernate with Fedora 17 (I have two-phase suspend/hibernate set up). I'm comfortable doing debugging but don't even know where to start on this one -- I don't know which subsystems to poke at.

We (Seneca OSTEP) are now also operating a second Koji buildsystem, for the armv6hl architecture. This architecture is really of interest only for the Pidora project for the Raspberry Pi at this point in time. This buildsystem is accessible on the web at http://koji.pidora.ca

However, to access the armv6hl buildsystem using the Koji command-line tools, using a Fedora client certificate, a bit of a dance is required. This post outlines the steps...

6. Profit! -- You should now be able to issue commands to the armv6hl koji system by typing: armv6-koji command

In due course, we'll get this configured as a standard secondary-arch Koji instance, and you can skip the steps above -- but in the meantime, if you want to help with the armv6hl effort, those are the steps required.

These are my first two books: X Power Tools, a thorough guide to the X Window System (O'Reilly, ISBN 9780596101954) and Fedora Linux: A Complete Guide to Red Hat's Community Distro, a practical hands-on book on Fedora (O'Reilly, ISBN 9780596526825).

Amazon.ca (Canada):

Amazon.com (USA):

Fedora Linux is also available for online reading through Safari and in downloadable PDF format from oreilly.com