A few months ago, I wrote a blog post about a little two watt x86 SoC/SBC board I had in my possession, and that I intended to use with batteries for ultra-low power off-the-grid applications. The board is the Vortex-dx x86 board. There are newer SoC/SBC boards, but they’re usually using more like eight or ten watts of power consumption, and therefore not in the “ultra” low power camp (for x86 genre boards).
The link of the previous post was at:
Boards like the Vortex work well with a uSD – IDE adapter, and it’s not so difficult to install an OS directly to the uSD or SD card. Recently, I decided to install an OS that didn’t have very good USB/uSD device access capabilities onto the Vortex. The SD – IDE converter could allow the OS to run from the uSD (through the converter’s abstraction), but it could not install it. This was because the OS couldn’t boot from a USB based CD drive or thumbdrive. So, I used QEMU to build the “hard disk” – or “raw disk” image, and then the “dd” utility to copy it to the uSD, where it could be utilized through the IDE converter. It worked pretty well, so I thought I’d describe the process on the blog here.
For my description, I’ll use FreeBSD (even though it does have USB capabilities). Most people use QEMU with a “disk in a file” abstraction. A little known feature of QEMU is to use a second host drive directly, like with this syntax:
- qemu-system-i386 -hda /dev/sdb -cdrom xyz-os.iso -boot d -serial stdio
This is relatively dangerous, as one could easily clobber a drive that wasn’t intended to be clobbered (raise hand here). So, a better way to do it is to use the “disk in a file” abstraction, but build it as a raw hard drive image. This image can be subsequently copied over to another hard disk or to a uSD disk using the dd command. With such a hard drive image tucked away someplace, I can easily create a new installation, or overwrite an existing one if I wish.
When making a hard drive image, using the “disk in a file” technique – one must tell QEMU explicitly that this is what is wanted. Otherwise, QEMU will protect the user, and refuse to write to sector zero, which precludes installing a new MBR and partition table on the drive. As I said, I intended to build the image in a file, but the exclusion of sector zero still applied. So, the new syntax for the safer way (the image file) – is shown here with the explicit “raw” format declared such that “sector zero” can be written to the file:
- qemu-system-i386 -drive file=./fbsd11.img,format=raw -cdrom ./fbsd11.iso -boot d -serial stdio
This of course assumes that a zero-file fbsd11.img of appropriate size had been created via the dd utility:
dd if=/dev/zero of=./fbsd11.img bs=1M count=<desired block count for size>
There is a shortcut to create the zero-file, but it doesn’t fill it with zeroes. If the file is “zeroed” – then it will often compress to a much smaller archive.
The -serial stdio syntax allows QEMU to print the serial debug output of the OS to stdio (i.e., you can see it in the launch window under the OS window). AFAIK, the image created with this syntax is exactly what would be created on the hard drive with a conventional installation. I’ve found it convenient to use the Haiku OS to lay down the MBR and to create paritions on it, so that my easy-copy HD image can have as many as four different operating systems on it. While I’m not advertising/vouching/promoting Haiku (especially since it is alpha stage software) – it seems to work so far, and has its own nifty little bootloader. This bootloader seems tons easier to use and set up than grub or the BSD loader.
FreeBSD running X windows was just too slow on the Vortex. IMO. So – I have mostly a text based system on the Vortex, but with a graphical web browser. I did this by compiling Netsurf to use a framebuffer and SDL. There may be security caveats associated with running Netsurf after it’s been compiled for use with a framebuffer (and no X windows) – but I don’t use this setup on the public internet (only a private intranet). The overall performance and the netsurf-fb performance is adequate for my requirements on the intranet. In terms of the SoC, I have used this little 2 watter with the Haiku OS, and its performance there was (barely) acceptable for a patient person. IMO. I still haven’t tried Windows with it.
While the image creation procedure and the framebuffer browser build worked for me, I cannot claim that they’re foolproof ideas or that they won’t under certain conditions produce unexpected results. Also, I am not vouching for the accuracy of the information. So, this is not advice to do as I do. If it goes wrong somewhere, don’t blame me. Caveat Emptor.
QEMU is a trademark of Fabrice Bellard, and the product is at http://www.qemu.org. This author and site has no affiliation with QEMU or its author.
The Vortex86dx is a product of DMP at dmp.com.tw, and is not affiliated with this site in any way.
Haiku OS is trademarked by Haiku, Inc. The website for them is at www.haiku-os.org. This author and site have no affiliation with them. I like it tho!