Someone asked me about 64K pages and the AArch32 ABI again recently. It’s a question that has passed across my desk multiple times and even followed me through multiple companies. Given that long history, and the changes made to the Arm toolchains to ensure freshly built ELF binaries can be loaded, I was interested to see whether Debian 9 (Stretch) armhf userspace would on a machine with 64K pages. I also had access to a Developerbox to help me indulge my curiosity. The short answer is that it is *not* possible to boot Debian Stretch armhf container on a machine with 64k pages because the kernel cannot map the init process… but is only half the story; it really was very close to working!
Scattered across myriad blogs around the internet you will find many different ways to boot GNU/Linux for arm64 (a.k.a. AArch64) using QEMU with or without KVM. However, when I recently wanted to quickly spin up a KVM VM on my Developerbox using the Debian Installer ISO images, I couldn’t find any end-to-end instructions. There is lots of great information out there but I had to assemble the fragments myself. Having done that I thought I would share the results…
I recently bought a (comparatively) cheap K40 laser
engravercutter and am slowly getting to know it, whilst also getting ready to heavily mod it. I have plans to improve (slightly) the cutting area, to add air assist, to replace the controller board and upgrade the bed (pretty much all the usual stuff) and I plan to blog about it as I go.
However here at the very beginning of the journey my machine is freshly calibrated and almost, but not quite stock. The bed was causing a few problems, not least that, when cutting large sheet material, the lip of the clamp brought the material too close to the laser. That was easily remedied by unscrewing the clamp and dropping it into the bottom of the machine (its metal, it will be quite safe down there). However the means the cut pieces drop to the bottom of the machine where they are at risk of damage from the laser working overhead… and small pieces can be hard to find because some idiot left a big metal clamp down there.
The solution turned out be a very cheap anti-splater guard for a frying pan. It cost me £1 (since Brexit that’s dropped to about $1.20) from a local discount store and for now I’ve just gaffer taped it to the underside of the existing bed. Since it’s working so well I’m thinking of driving a couple of self tapping screws into a couple of cable clips to hold the frame in place without any sticky residue.
This is working great for small items, catching any components that are cut from the middle of the bed and with absolutely no signs of backscatter. Amoung other things I’ve used this simple bed to build a case for my Carbon board (a 96Boards IoT edition micro-controller board) and the results are, I think, pretty awesome.
So a very, very simple mod but more than enough to allow the whole family to have a bit of fun with our new toy. Whilst its not quite as much fun just to watch I would still invite you to watch the video below showing the cutter creating the case for the Carbon. I find it oddly hypnotic!
The Dragonboard 410c is a great platform but currently there is a problem with the wireless driver that makes it very hard to run it headless and connect to services running on the board via wifi.
At present the board does not respond correctly to broadcast packets. This results in a number of issues but by far the most significant is that the board cannot reply to ARP requests and this prevents other devices from opening connections to it. From the client machines point of view it knows the board is there, and it can look it up using DNS, but it can’t take the final steps needed to communicate with the board.
In the example below we have a client machine, birch.lan, unable to access dragonboard.lan, because it cannot find the right MAC address.
birch# arp -e Address HWtype HWaddress router.lan ether 40:ba:fa:xx:xx:xx dragonboard.lan (incomplete) wychelm.lan ether fc:aa:14:xx:xx:xx
If only we could get the MAC address into birch’s ARP cache then there would be no problem doing basic network activity like connecting an SSH server. Thankfully there is a fairly easy way to automate this…
Get the Dragonboard to do a nmap ping-sweep of the subnet.
To be clear this is a hack of such huge proportions that it deserves more than just those four letters! It is a bodge, a sticking plaster, a nasty solution stuck together with sticky tape and glue, it does not make me feel warm and snuggly inside… however… it does work.
Not only does it work but it can also be trivially hooked up to systemd so that the device can periodically shout out its presence.
Firstly we need to create a simple service to launch the ping sweep (actually it will be much more like an arping sweep):
# # /etc/systemd/system/share-mac.service # # Running an nmap ARP ping sweep will encourage other # devices to cache this boards MAC address. This # works around a problem where the Dragonboard # 410c does not correctly respond to ARP # requests. # # Note that although nmap's port scanning is # disabled it remains possible that the host # discovery protocol (which is not *actually* # as simple as a ping sweep) may still trigger # an IDS if run on a corporate network. # Take care! # [Unit] Description=Send our MAC address to other devices [Service] Type=simple # Change the IP address range as needed... ExecStart=/usr/bin/nmap -PR -sn -n -e wlan0 192.168.1.1-254
The above service runs just once and it would be enough to get the board noticed after it boots but eventually the other devices would evict the ‘410c from their ARP caches and it would fall off the network again. To solve this we can use a systemd timer to ensure we always keep poking the other devices:
# # /etc/systemd/system/share-mac.timer # [Unit] Description=Repeatedly send out our MAC address [Timer] OnBootSec=30 OnUnitActiveSec=3m Unit=share-mac.service [Install] WantedBy=multi-user.target
Finally we need to run a few commands on the ‘410c to install nmap and ensure systemd runs the above files:
apt-get update apt-get install nmap systemctl enable share-mac.timer systemctl start share-mac.timer
With these changes in place the ‘410c should announce its existence to all hosts on the network shortly (~30 seconds) after booting and it will repeat the sweep every 5 minutes to ensure the ARP caches stay nice and hot going forward.
The results of the above scripts showed up straight away in birch.lan‘s ARP cache:
birch# arp -e Address HWtype HWaddress router.lan ether 40:b0:fa:xx:xx:xx dragonboard.lan ether 02:00:7d:xx:xx:xx wychelm.lan ether fc:aa:14:xx:xx:xx
Share and enjoy!
Update #1 (2016-01-15): Updated the nmap command with -PR (ensure pure ARP ping sweep), -n (no reverse DNS lookup) and -e wlan0 (only deploy workaround on a specific network interface). Reduced the interval between sweeps from 5 mins to 3 mins to better handle congested networks (10 minutes ARP cache timeouts are common). Thanks to snowbird and ldts-jro for their feedback with this.
I have amassed a modest collection of 96Boards. They come as plain circuit boards with nothing to keep them safe from damage during handling. Its not just static discharge we have to worry about! Many of the boards have fairly large components on the underside and these can be knocked off by careless handling (I admit that I’m tempted to say “Hi” to a colleague at this point, but I won’t). Since, I’m at least as careless about handling as the next software engineer so I decided a case was needed.
I’m not aware of anyone selling cases for the 96Boards Consumer Edition so I decided to get my own laser cut. As it happens between ordering the boards and writing this post I have started to come across a couple of other folks at Linaro who are experimenting with cases but nevertheless I think I’m still the first to blog about it!
There is a hackspace in Bristol, UK where I live which could be a great place to get involved in laser cutting but it’s right on the other side of the city and I’ve not really found the time to get very involved there. Instead I decided to try out the Seeed Studio online laser cutting service: 100mm x 100mm, cut to your own design for $6 for five (plus postage).
Having something of a plan the only remaining problem is that I know absolutely nothing about CAD/CAM. The only information on the Seeed Studio website about file formats is that I must send in .zip or .rar files and the only blog posts I could dig up wanted me to use the Google Sketchup which is non-free and partially discontinued.
In the end I just asked myself, “How hard can it be?” and fired up LibreCAD. After working through a couple of tutorials I learned how to round off corners and how to add dimension information. Armed with this, and the 96Boards CE Specification which has very clear diagrams of the physical layout of the board, I draw a basic top/bottom plate. I wasn’t happy with the 35mm of “wasted” material due to the minimum panel size of the manufacturer so I added a half-top component as well. The half-top should work very nicely with the 96Boards UART board.
Influenced by this blog post I decided to export from LibreCAD as an SVG. This turned out not to be such a great idea. The resulting SVG uses curves that are quantized to pixelish boundaries. The friendly folk at Seeed Studio declined to use it and askeld me for DXF files instead. Since DXF is the native file format for LibreCAD this was not much of a hardship.
And that’s it… I got a bunch of cases made in a couple of colours. The glowing neon green in the photo above is sooooo my favourite. I’ve hurled my design files at github and, because I’ve had so much fun with this, I’ve given the project a nice generic name. Maybe there are more cases to come. If that happens, you’ll read about it here first!