Running LEAP: Portable 64-Bit ARM Computing Sat, Sep 19. 2015
I really want a 64-bit ARM laptop, but no one is shipping them yet -- not even Vero Apparatus.
So, I've put together the next-best-thing: a portable, wireless system assembled from off-the-shelf components. The resulting system weights ~1.8 kg (4 lb), has a 5-6 hour battery life, and fits in my laptop bag. It has microSD for storage, an 8-core Cortex-A53 processor, wifi, ethernet, and bluetooth, an external HDMI output for presentations, and 1GB of RAM. The components are held between two sheets of acrylic by 3M Dual Lock fasteners so the configuration can be easily switched up.
This system runs a version of LEAP, our experimental enterprise Linux distribution for AArch64 systems loosely based on the CentOS 7 x86_64 sources, on a 96Boards HiKey. The HiKey isn't officially supported by LEAP (yet), but we expect to support it later this year. I look forward to swapping the HiKey for a 96boards Enterprise Edition board later this year.
If you're at Linaro Connect next week, I'd be glad to give you a peek sometime during the week or on Demo Friday, and I'll blog about how the system was assembled a few weeks down the road.
The OSTEP Applied Research Team Thu, Jul 2. 2015
I haven't introduced my research team for quite a while, and it has changed and grown considerably. Here is the current Open Source Technology for Emerging Platforms team working with me at Seneca's Centre for Development of Open Technology. From left to right:
- Michael (Hong) Huang (front)
- Edwin Lum (rear)
- Glaser Lo
- Artem Luzyanin (front)
- Justin Flowers (rear)
- Reinildo Souza da Silva
- Andrew Oatley-Willis
Edwin and Justin work with me on the DevOps project, which is applying the techniques we've learned and developed to the software development
processes of a local applied research partner.
Michael, Glaser, Artem, Reinildo, and Andrew work with me on the LEAP Project. Recently (since this photo was taken), Reinildo returned to Brazil, and has been replaced by Christopher Markieta (who has previously worked with this project).
I'm dying to tell you the details of the LEAP project, so stay tuned for an announcement in the next week!
Connecting a 96boards HiKey to a Breadboard Sat, Apr 11. 2015
I've wanted to experiment with interfacing the 96boards HiKey (8-core, 64-bit ARM development computer) to some devices, but the 2mm 40-pin header is difficult to bring out to a breadboard (except by individual wires). I designed a simple adapter board and had some produced by the awesome OSH Park prototype PCB fabbing service. The boards are back, and I've been assembling a few of them for testing.
The adapter has a 40-pin 2mm male connector that plugs into the 96boards "low-speed" (LS) female header. It brings those signals to a 40-pin 0.1"/2.54mm header that can be used with an insulation displacement connector (IDC) on a ribbon cable. The other end of the ribbon cable can then be connected to a standard solderless breadboard using an adapter (most of the 40-pin IDC-to-breadboard adapters used with the Raspberry Pi A+/B+/2 should work -- for example, the AdaFruit Pi Cobbler Plus (straight) or T Cobbler Plus (T-shaped), KEYES SMP0047 from dx.com (U-shaped - not checked), or a 40-pin IDC Ribbon Breakout from Creatron in Toronto (straight) -- obviously, the pinouts from the 96boards connector will be different, so ignore or rewrite the pin labels on the adapter board). Update: Watch out for breadboard adapters that connect pins together -- e.g., that are designed for use with a Pi and connect together Ground or Supply pins, which will have different functions on 96boards LS connector. (I found a T-style adapter from DX.com that has this issue).
These first-try "Alpha 1" boards are not ideal -- they're bigger than they need to be, the board occludes one of the 96boards mounting holes, and the routing is wonky (I let the autorouter do its thing, and ended up with a couple of unnecessary vias and some wild traces). Nonetheless, the board seems to do what it was intended to do. I'm going to work on a second-generation design, but it may be a little while before I get around to it.
If you're interested in using this design, it's licensed under CC-BY-SA and can be downloaded or ordered from the OSH Park sharing site.
You can use this with the 2mm (96boards LS) and 2.5mm (IDC) connectors on the same side of the board, or on opposite sides of the board.
If you place them on the same side of the board (see the populated PCB with no cable attached in the photo -- though the IDC socket should be rotated 180 degrees), the pin numbering on the IDC cable will match the 96boards pin numbering. However, the IDC connector will be really tight to the edge of the board -- you may want to slightly angle the IDC header when you solder it on.
If you place them on the opposite sides of the board (the adapter plugged into the HiKey in the photo), the even and odd numbered pins will be swapped (1<->2, 3<->4).
One final note -- these should work fine with other 96boards devices that comply with the Consumer Edition specification -- and hopefully, it won't be long before the DragonBoard 410c is available so we can test this theory!
(The board in the photo is in one of the very basic acrylic cases I built for the HiKeys).
Initial Current and Temperatures on the HiKey from 96Boards Sat, Feb 14. 2015
This board is powered by an 8-core, 64-bit Cortex-A53 ARMv8-A Kirin 620 SOC from HiSilicon with 1GB of LPDDR3 RAM, a Mali 450MP4 GPU, dual USB, eMMC and micro-SD storage, 802.11g/n, and high- and low-speed expansion connectors with I2C, SPI, DSI, GPIO, and USB interfaces.
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.
More notes to follow...
Looking for a Debugging Mentor Wed, Feb 20. 2013
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.
Anyone willing to mentor me through this?
Acessing the armv6hl Koji Buildsystem Mon, Feb 11. 2013
The Seneca CDOT OSTEP project has been operating a Koji buildsystem for the Fedora ARM Secondary Architecture project, for the armv5tel and armv7hl architectures. These architectures are going to shift to the Fedora Phoenix datacentre Real Soon Now(tm) now that true enterprise-grade ARM server hardware is available.The armv5tel architecture has hit EOL with Fedora 18, but will be supported with updates until a month after the release of Fedora 20; we (the Fedora ARM group) is working towards Primary Architecture status for armv7hl by the Fedora 20 release.
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...
1. Set up your Fedora packager environment, if you haven't already done so.
2. Add this text to the end of your ~/.fedora-server-ca.cert file:
3. Place this text in /etc/koji/armv6-config:
;configuration for koji cli tool
;url of XMLRPC server
server = http://japan.proximity.on.ca/kojihub
;url of web interface
weburl = http://japan.proximity.on.ca/koji
;url of package download site
topurl = http://japan.proximity.on.ca/
;configuration for SSL athentication
cert = ~/.fedora.cert
;certificate of the CA that issued the client certificate
ca = ~/.fedora-upload-ca.cert
;certificate of the CA that issued the HTTP server certificate
serverca = ~/.fedora-server-ca.cert</code>
4. Execute this command: sudo ln -s /usr/bin/arm-koji /usr/local/bin/armv6-koji
5. Ping someone on the OSTEP team via irc://irc.freenode.net/seneca to add your FAS2 username to the Koji instance.
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.