Skip to content
bifferos edited this page Aug 30, 2021 · 3 revisions

Introduction

A long, long time ago (around 2008), sometime before cheap Linux SBCs like the Pi came along people where hacking routers to run an operating system called OpenWrt. OpenWrt was based on Busybox and people were able to cram a lot into just a few MB of flash with configuration systems written in Lua. OpenWrt primarily supported Linksys routers, but inevitably other architectures arose, some were MIPS-based. Some others were based on x86 cores, notably - but not limited to - RDC in Taiwan. These latter devices were of particular interest to me, because although x86 can be considered a 'dead' architecture it's also rather familiar. It's a bit of a nuisance when writing a bootloader because you have to work your way around the entire history of the PC computer in bringing the system up, starting at the instruction 0xffff0 at the top of the original 1MB memory in real mode and taking it from there.

Around this time a company called MRT Communications decided to release a little device called the WANSER-R (AKA Addonics NAS).

It wasn't a router, it was an independent device that was designed to sit on a network and perform tasks while your main PC was switched off, such as long file downloads. It could also behave as a printer server back in the days when many USB printers didn't have a wifi/rj45 option (almost all of them do nowadays). The devices were cheap (about £30) so I wondered if they ran Linux, and took a chance and purchased one.

First look

Well it turned out the device didn't run Linux. However it had some interesting possibilities. For starters, it had a bootloader that wasn't locked down and allowed one to TFTP alternative firmware onto the device. There was also a program called RDC Loader that promised to update the bootloader via JTAG (Windows only unfortunately), and at the time OpenWrt supported other RDC CPUs such as the RDC3210 (a larger version of the S3282 BGA device found in the WANSER-R) which was functionally very similar, with a data sheet available.

I was able to get Linux running on the device and decided it would be nice to sell these as to hobbyists. There was a problem however, the 1MB of flash that comes with the devices severely limited their use. It required a USB-root filesystem to support OpenWrt and this isn't really a standard config for OpenWrt either, with it generally being run from JFFS.

MRT Communications

But unlike other manufacturers, MRT Communications were prepared to answer emails from people like me. If you've dealt with far-Eastern electronics companies you'll understand what I mean. It turned out that minimum order value for these boards was 500 units. There seemed little hope of selling this many units unless I was offering something that other people wouldn't be, when basically anyone can order the same units from MRT and under-cut my prices and point to my website for the 'community' support. So I took the decision to create a custom bootloader. The bootloader would be compact, have some extra features, make it easy to work with the boards, and I'd offer my support only to people who were clearly running it.

After starting to sell these boards as a sideline to my main job, some things became apparent: Individual unit sales didn't really make any money. Unless you're Amazon with a highly organised distribution setup that walk/drive to the post-office to post a couple of boards barely gets reimbursed in terms of the money coming in. Forget about any community support, you are basically doing this as a charity. There's a reason why distributors expect mark-up of about 2/3 the sale price, and I was buying the units for $12 each in these quantities and totally failing to sell them for the $36 I should have. I didn't realise I was breaking a cardinal rule of distribution.

However, the bulk orders were different. Once people started using these as part of other projects where they added their own value and the quantities on each order increased into the dozens of boards, it started to return some money. Don't get me wrong, when including the community support effort I once worked out I was getting about $2/hour overall. I was never going to be rich, but there could be some prospect of living off such an income if things progressed.

It was only after my first order that I realised there was the possibility of adding 8MB (instead of 1MB) of flash to the boards. This was really unfortunate. I simply hadn't asked if there was an option and on reflection this was one of the stupidest mistakes I made. This increased the cost by only about $0.5 overall and then OpenWrt JFFS became possible. I also got MRT to add some headers to the boards for connecting a serial adapter (which was no extra), and gave them a special firmware consisting of a modified bootloader and Linux kernel. This firmware got burnt into the flash chips before they were placed on the boards. The bootloader couldn't be used by end-users because it didn't allowed flashing, but instead took you through the process of setting the MAC address, booting the kernel and testing a bunch of things. This significantly reduced the number of faulty boards they were sending me because they had to go through a full test of Ethernet and USB, whilst not actually supplying them with my Bootloader. I was paranoid at the time of them doing a production run with my bootloader for a different customer.

The End

Things were going OK for a while, but ultimately the Pi project came along and that was pretty much the death of the Bifferboard as a commercial concern. There were some things I preferred about the Bifferboard, and still do. I didn't personally have any need for video in any of my embedded projects, and wanted something a step-up from an Arduino as opposed to a step-down from a PC. Using a serial console was no big deal. I didn't like the fact that the Pi had cases full of openings. I hated that it had no on-board flash, and I hated that I couldn't compile up statically-linked applications on my desktop computer without any kind of toolchain and just execute them on the target. I loved the fact that super-fast access to IO was just an assembler instruction away (after an ioperm()) because the IO concept was built into the x86 processor, and dislike having to make kernel-level changes to support things like custom i2c and SPIO communication. So there are things the x86 architecture has going for it for the hobbyist user, even if they're a little hackish in nature.

I saw that someone was hacking Coreboot to work on the Bifferboard, which was also another reason to abandon selling Bifferboards. Although done with the best intentions, such a move could mean the end of any bulk orders, and therefore any funding for community work as I mentioned above. I decided this was just not the place to be if I had hopes of giving up the day-job and working on this stuff full-time (which was my ultimate aim).

What next?

I still have an interest in this area. I think there is a place for low powered x86 in the embedded world, and RDC make other chips which are faster, and still x86, some with industrial temperature ranges, if the cost can be made low enough. However it's done it needs to be done in such a way that the people supporting the project get some cash for the community work. As I came to realise, either OpenWrt or kernel work is very time-consuming due to the complexity of the code bases (the OpenWrt make system alone is very hard to come to terms with) so to keep up with the latest versions of either requires massive effort injection and this is not particularly interesting work once you've done it the first time and you're simply watching how kernel structures and interfaces are changing and trying to keep up with them. To get your (new) architecture accepted into OpenWrt kernel patch sets is hard but to get the mainline kernel devs interested you're going to have to have a very popular device, on a par with the Pi itself.

Clone this wiki locally