Building Super Small Linux Computers From Scratch

Conventional wisdom says small, powerful embedded Linux like the Raspberry Pi, Beaglebone, or the Intel Edison are inherently manufactured devices, and certainly not something the homebrew tinkerer can produce at home. [hak8or] is doing just that, producing not one, but two completely different tiny Linux computers at home.

The first is based on Atmel’s AT91SAM9N12 ARM processor, but the entire board is just about two inches square. On board is 64 MB of DDR2 DRAM, a USB host and OTG port, and not much else. Still, this chip runs a stripped down Linux off of a USB drive.

The second board is based on the Freescale i.MX233. This board is similar in size and capabilities, but it’s not exactly working right now. There’s an issue with the DRAM timings and a capacitor underneath the SD card is a bit too tall.

The real value of [hak8or]’s project is the incredible amount of resources he’s put into his readme.mds for these repos. If you’ve ever wanted to build an embedded Linux device, here’s your one-stop shop for information on booting Linux on these chips.

50 thoughts on “Building Super Small Linux Computers From Scratch

  1. At 100 MHz SDRAM speed, do you really need the serpentine traces ? Delay is only 150 ps per inch, so even if there’s half an inch difference between two traces, that’s just 0.75% of a cycle.

    1. You are totally right, but I added them in as a “just to be sure”. I am still a noob at all this so I wanted to remove as many possible gotcha’s as possible. For my next design I will probably dabble and get a much better understanding of length matching.

  2. It is hard to beat the Atheros AR9331 or Ralink RT5350/MT7620 when you want really tiny Linux systems. You can achieve the same size as this project with the addition of wifi/Ethernet.

  3. too bad number 2 does not work, put on a wifi module and maybe some fancy micro usb and you have an awesome board that would replace my raspberry in no time, almost a post stamp computer that can serve as a mini fileshare or code base server would be awesome. with the powerbanks of these days that could run for a long while too !

    1. Hey, just use an OpenWrt system for that, that’s what they are – small computers that run Linux =) The simplest would be MR3020 or WR703N – stock routers that can be re-flashed to OpenWRT, though ROM-limited (can be easily solved with a flash drive). Then, there are System-on-Module solutions that are specifically for theDIY community, such as Carambola, VoCore, BlackSwift… I personally recommend BlackSwift, ordered 3 of them, will be making an ultra-small portable router with that. The most important advantage of it is having DDR2 memory – every other OpenWRT SoM (except Carambola 2) has DDR. That, and it’s the size of SD card… But not available right now – their Kickstarter just ended, will have to wait till they take orders and till they have devices they can sell =)

    2. Number two probably just requires modifying the memory timings which shouldn’t be an issue to fix. I just hadn’t got the chance to work on it yet because I have exams coming up and I landed myself a kick ass internship just recently (because of this board actually!).

      Though, keep in mind that the processor I used is *sllooowwwwww*. I am talking compiling a C++ hello world using GCC taking over 10 seconds slow. It was done pretty much solely to learn and understand how how to make these pieces of magic. and serves no practical purpose.

      Though I am hoping to make another system where the SoC can use PCI-E so I can connect that to my desktop. Then throw in an FPGA board also capable of using PCI-E that outputs video and audio over HDMI, write a very simple GPU for the FPGA in system verilog, and use it it as a very simple game console thingamabob.

  4. Some time ago, I planned to build a small Linux sbc using iMX233,too. The iMX233-OLinuXino-MICRO just uses a two-layer PCB and all components, including the iMX233 are solderable by hand. In fact I would have just modified the plans from olimex. The atmel build on the other hand looks more complicated, at least from soldering side.

    1. Regarding a two layer board, I highly advise against that. My first MX.233 board was just two layer, which meant a non continuous ground plane, poor power distribution, and a total pain to route.

      OSH can do 4 layer for double the price which still isn’t much considering this is a tiny board. The time you save from doing routing and power distribution would be worth far more than the measly ~$10 bump a 4 layer needs.

  5. It’s too bad it’s near impossible for mere mortals to order SoCs with PoP memory attached. Many cellphones and the original RasPi use PoP parts to eliminate DRAM routing and reduce board area. In fact, the original RasPi would have been a much more complex board if it weren’t for the PoP memory.

    The major memory vendors offer PoP multifunction memories with DRAM and eMMC in one package. Even though these are usually fine pitch BGAs, they integrate everything necessary for an embedded system into one package but the power supply and minor interface (Ethernet PHY, USB (ULPI) PHY, 3.3V SD buffering) in package. And some PMIC power supply chips include a ULPI-to-OTG bridge on-chip lessening the component count.

    The bottom line is that it would be possible to make a ridiculously small embedded Linux board with decent horsepower and relatively inexpensive PCB with a part like this.

    1. Actually, I tried contacting various companies like Qualcom, Authorized distributes of Samsung, etc. I was hoping they would let me purchase more advanced chips which are Package On Package and whatnot. None of them replied sadly since I am a mere mortal who isn’t interested in buying as many chips as my house is worth.

      Had they replied and I could have bought such chips in single unit volume, I would have definitely tried this as a third embedded system. Like you said, it would probably make routing a godsend compared to what I am doing now, especially considering I have no software to simulate the design. Hell, I can’t even simulate crosstalk and whatnot, I need to do estimates by hand, so I have no idea if I could cope with the 400 Mhz+ speeds involved in much more capable embedded systems.

  6. That’s pretty awesome! I hope some day I reach the level where I am doing this. The pre-manufactured devices never seem to have exactly the set of features or ports that I need. It’s great that we now have SBCs available that are so tiny but when you have to chain a hub plus half a dozen adapters to them… they are big again plus an awkward mess! Building ones own could mean avoiding all of that.

    Along that train of thought… why the micro usb connector? If you are going to use a USB stick for your permanent storage then do you have a USB stick with a micro-connector? I’ve never seen that before! I know that a full-size USB-A connector would mean a slightly larger PCB but if you are stuck ALWAYS using a micro to full-size adapter… you might as well consider that as part of your board size since it’s for all intents and purposes a permanent fixture. That means the board is bigger yet when you use the Micro connector! Also, with the adapter in that host connector can you even access the other connector which is right next to it?

    1. There are two USB connections that the SAM9N12 offers, one is a USB device/slave which you connect to a host such as your computer. This connection is used by SAM-BA for initial programming/debugging the system. For example, you can use Atmel’s SAM-BA client to write U-Boot to the onboard data flash.

      The other board is USB OTG (can act as a USB host just like your desktop/laptop), which lets you connect a flash drive, keyboard, wireless dongle, whatever you want, to the board. I added it on since I figured it would be cool to be able and connect a flash drive to this later on. Luckily, that saved my ass since I couldn’t get NAND flash to work by my already late project deadline my professor gave me.

      Henrik later on my reddit discussion ( pointed out that getting NAND flash should be pretty easy based on his fix, which would let this operate without the dataflash board and a USB flash drive, making the design really tiny.

      1. Ok, interesting. I am curious why the memory must be external. If the CPU/MCU has an MMU and enough internal ram, would that change things? Not that I can think of such a CPU/MCU, haha

          1. You actually don’t need more than maybe 4 megabytes to have a linux system with a shell. But I haven’t had a chance yet to see just how little RAM is needed to have an actually usable linux system yet.

  7. Seeing something like that posted almost gives me enough motivation to finally opensource my vybrid designs. Although bigger one is oshpark manufacturable and can easily be implemented into other projects.
    I really like the idea to have more people using boards like that to minimize the effort to fix all Software stuff.

    1. As phreaknik, I totally recommend you open source it. Sure, it may be messy (I didn’t expect this to blow up as much as it did and haven’t had the chance to clean it up yet), but it’s better than nothing.

      I am sure if you put a mention somewhere that it is still very much a WiP people won’t complain much.

  8. Somewhat off-topic: the proportional font on the silk screen immediately caught my eye. Does anyone know how to make Gerbers in Eagle like that? Or is he (as I suspect) not using Eagle for CAD?

    1. I grimaced when that video went from dumb-to-worse as it said “Co-founder, and ninja” under that guy’s name. Really? The board might be awesome but the video just made me cringe.

      At least it had a ton of buzzwords and SillyCon valley newspeak.

  9. Great job! I wish i could be able to have 1% of you skills!

    This makes me wonder how do you configure/compile/install a linux kernel and OS on a “unknown” device?

    I have for example unused embedded devices (autonomous MPEG video encoder) running VX Works, and i would like to repurpose them by replacing the original OS by my own mine. I can have a look on the mainboard to know which chips are used (CPU, I/O chips, Ethernet controller…) so i believe i can then find which drivers to activate into linux kernel, but what about memory space adresses, how to flash a working bootloader…

    Does anybody know some good tutorial for that?


    1. Do you know what the CPU core is? For example, is it a known architecture that GCC already supports like an Arm A5, or is it some unkown customized architecture? If it’s an unkown arch, then you would have to write your own backend to gcc or clang, which is by no means easy. If it’s known, then finding out the address space might be just a trial and error process, assuming you don’t overwrite U-Boot and whatnot accidentally.

      If you also need to handle the bootloader then, well, it would be potentially very difficult if the components which require drivers are closed down.

      There tends to be two bootloaders, or three if you count the one integrated into the SoC’s ROM. The ROM one is non modified and sets up the serial port for debugging and searches for a secondary boot loader on NAND flash, a SD card, etc, in an order as per the datasheet. The secondary one sets up DRAM and is used to either call a third bootloader or just setup the kernel. The third boot loader, if used, tends to allow more customization than the second bootloader and is also loaded into external memory instead of the internal SoC’s SRAM. The second bootloader tends to be very tightly integrated with the SoC, with the company providing it. Writing your own would likely be a pain because you need to manually set up a ton of peripherals. The secondary bootloader will likely be what will block you.

      U-Boot is luckily rather flexible and doesn’t require too much customization for various architectures/boards other than memory size, what devices are where, etc.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.