Jump to content

Cheap, low power Linux fileserver


Recommended Posts

I've described my current fileserver here before.
In short, I went from an absolute electricity guzzler to something that takes a sip every so often.

As time progressed, I started to once again get disappointed with my current setup, specifically once again the power requirements. I used to have 2 'always on' computers where 1 would act as a gateway to the internet and the other would be a fileserver. Since they're always on, I wanted to get the power draw of these devices to an absolute minimum. The current specs are:

Gateway box
Via Epia-SP with a Via Eden CPU @ 800MHz
100W PicoPSU + 150W power brick

When Via originally came with these fanless Eden boards, I bought 4 of which 3 have succumb to the capacitor plague but this one is still going strong. The PicoPSU is rather more powerful than need be but I already had one so... Total power draw of this set is about 20W idle. It's only got 100MBit networking, but since it's my way out to the internet and I've only got 25MBit it's sufficient. When I download something using it and want to transfer it to the fileserver, it's a bit slowish, but managable.

AMD A50-based MoBo with onboard AMD E-350 CPU.
2x2TB Samsung SpinPoint + 1x3TB Western Digital + 1x16 GB Kingston SSD (slow but cheap)
550W PSU

I'm too lazy to open up the box to verify the board, but it's got a fan on it which is starting to get a bit noisy. Scratchy sounds. Yes, I'm certain it's that 40mm fan on the heatsink of the CPU and not the harddisks making that noise. Mainly due to the harddisks and the rather excessive PSU this thing draws about 40W idle.

So this setup eats almost 1500 Watt per day doing absolutely nothing. When I made this setup, that was actually pretty damn decent. Since then though, affordable low-power ARM boards that still provide very decent performance have become widely available and have by now reached the point where they can better the above setup in interesting ways.
Now then, please let me introduce you to the PcDuino3 Nano. This gorgeous little board has an AllWinner A20 CPU, 1GB RAM, 3 USB 2.0 ports (1 OTG), Gigabit ethernet and a SATA port. I've just ordered 2 for $90 including shipping - my own little christmas present to me.

For the gateway box, things are fairly straightforward: I have a USB ethernet adapter for 100MBit which will go to my router. Since it's 100MBit USB 2.0 will suffice and given the fact that I only get 25 MBit off the internet it'll suffice in that regard aswell. The GBit goes to my LAN and should speed things up nicely. I'll use one of the 16GB Class 10 MicroSD cards I used for performance testing as local storage and network-mount the fileserver for the larger stuff (torrents and the like) now that the network performance should suffice.
Which brings us to the fileserver which, to be honest, is going to be infinitely more interesting because the problem here is that I still want to attach multiple harddisks even though the PcDuino only has 1 SATA port. Luckily, SATA has a solution for that: Port Multiplication. Using a board such as this you can connect up to 5 harddisks to a single port. The only downside here is that the board does Command Based Switching (CBS) which basically means only 1 drive can be accessed at any given time whereas the rather more expensive FIS-based port multipliers allow you to access all devices simultaneously and you're only limited to the speed of the SATA port. However there's another problem: Port multiplier support isn't part of the standard SATA spec and many SATA controllers don't yet support it. It took some digging but today I discovered this forum post describing how a small kernel patch would enable port multiplier support on the BananaPi, another, somewhat more expensive A20-based board. That was the clincher for me: Gigabit and multiple harddisks on an ARM-based platform. Nice!

Now you might ask "Where, exactly, does the 'hack' come in?" and you'd be right to ask. The point is that these ARM boards run off of 5V as does the port multiplier board. You can find solutions for cheap NAS devices based on, for instance, the Raspberry Pi but they work by using 2.5" mobile harddisks that operate on 5V and thus can be powered over USB with a little fiddling. I'll be using full 3.5" Desktop harddisks that take the vast majority of their power in using the 12V line of the SATA power plug. The solution I've come up with is to take a standard 12V power supply I already have (the one currently in the gateway box to power the PicuPSU could even be used, but it's WAY too powerful for what I need here) and the 12v to 5v buck converter I bought for my Odroid cluster project. That thing is rated for 6A. So, 12v comes in from the power brick which will be split. 12V continues to the appropriate line on a Molex connector (I have leftover Molex splitters and Molex to SATA cables) and the other end goes to the buck converter. From there, 5v goes to the appropriate line on that same Molex connector as well as to the 2 PcDuino's and the port multiplier board. The PcDuinos are each rated at 2A which might be cutting it a bit close, but if my Odroid is anything to go by, at least half of that is for when you kick the graphics on the ARM board into high gear, which I won't be doing anytime soon.

My hope is that with this setup I'll have equal or, in the case of the gateway device, better performance at about 30 Watt of power draw. Given my current usage pattern for my fileserver (the girlie didn't like me removing files from there unless the movie really sucked hard - now I only keep stuff I expect to go and watch sometime soon) I expect to be able to take out the 3TB harddisk probably reducing the power draw to about 25W.
Going this route will cost me about 110 dollars which at todays rates is about 90 euros. The rule of thumb here in .nl is that 1 watt of non-stop power draw for a full year will cost you 2 euro meaning that if I do manage to go from the current 80W to 30W I'll be saving 100 euro per year in electricity costs. In other words, this little project will start paying for itself in just one year. :smile:

Edited by Cooper
Link to comment
Share on other sites

  • 2 weeks later...
  • Replies 87
  • Created
  • Last Reply

Top Posters In This Topic

Did some measurements. If I put things together like in this image, routing the power cables under the various boards (it helps that the micro-usb ports are on the bottom of the Nanos) I stay within the limits of the ITX form factor, which is the size of the case I want to put everything in. The harddisks are used to demarcate the space.


Link to comment
Share on other sites

  • 2 weeks later...

With all the bits in, I tried to get one of the Nanos to start up. First I needed an HDMI to DVI plug which I lacked but a coworker could lend me the one he used for his Pi (music server at work, so it had to be back the next day). I tried it by naively plugging the USB thing for power into my PC which, to my delight, got it going but, to my despair, abruptly ended mid-boot. Clearly, it wasn't getting the power it needed from the USB port. I tried a few more things, but it soon became clear that this wasn't going to work with anything I had ready to go.

So today I took apart an old Mini-ITX case and took its power input cable and plug, screwed that directly onto the buck converter and started checking voltages. I was getting 12.2V in which resulted in 5.5V out. Not bad, but 10% over seemed a bit too much, so using that single copper screw on the solid blue block I turned it down to about 5.2V. Moved on to the USB cable. Carefully stripped the outer cable, found the inside cables to be color-coded, did a quick continuity check to verify they were what they were supposed to be (can never be too sure with these cheap ones) and hooked that up to the other end of the buck converter. Plug in network and a wireless keyboard and you get this:


Which worked :)


I didn't measure the current yet, but the buck converter remains cold to the touch even after prolonged service (well, idling, really... but still).

I'm now going to see if I can get this puppy going with Gentoo booting off an SD card because this internal memory is SLOOOOOW. Once booted I logged in via SSH and did a quick 'ls /' as a first step. I thought the board locked up, it wouldn't do anything anymore. After at least 5 seconds, maybe as much as 10, the prompt came back and things were sorta back to normal, but if this clearly isn't going to cut it for me in the long run. First runs of anything tend to stall very long too. Once it's either in memory or otherwise buffered, the board flies so the potential's there.

Moving on, I had some issues with the harddisk of a regular PC this week. The UEFI BIOS wouldn't load because, as it turned out, the harddisk I tried to use used to be part of my 10-disk RAID5 array. Nothing a format wouldn't fix, but as I was formatting it I noticed that on top of that harddisk a sticker said the device took so-and-so much current from 12VDC and 5VDC. The numbers felt a bit high so I began to worry if this 6A buck converter would suffice since the harddisks took quite a bit more power off of the 5V rail than I honestly expected.

So I took out the harddisks from my current JBOD array and sure enough, similar sticker. I've got 2 Samsungs that are rated "+12V/+5V 0.5A, 0.85A" and the WD says "12V 0.45A" "5V 0.6A". So the 3 harddisks combined swallow 1.3A. The Nanos themselves can take up to 4A total, but that's everything maxed out and with power hungry USB devices attached. That leaves about 0.7A for the SATA port multiplication board. I think that should remain within bounds, and doubly so when the boards aren't doing much of anything which should be most of the time...

Link to comment
Share on other sites

Those Nanos is are a great find. I couldn't resist and ordered one. I'm developing a robotics thing and I'm trying, so far, a Netduino, a Beaglebone Black, and now a PcDuino3 Nano.

The Netduino has been a disappointment because of the C# overhead. Just too slow for things like following a gyro and accelerometer.

Link to comment
Share on other sites

If CPU horsepower is a big focus, I'd take a good look at the Odroid-C1 over at HardKernel. It's a nifty 4-core machine with Pi-like headers for a Pi-like price though, since that board is so new, more local distributors don't have them yet.

My reason for picking the Nanos here is gigabit ethernet and, most importantly, a SATA plug that I can coerce into port multiplicating.

Link to comment
Share on other sites

Not sure the Odroid-C1 is Arduino compatible. The Nano is, or they say it is. Not certain I like their video response to some customer problems on Arduino compatibility.

Language barrier aside, the dude says customers have been complaining about getting the Arduino stuff to work, then runs the simplest Arduino script (blink) and is like, see? It works! Stupid customers!

Obviously he doesn't address using Arduino shields and other aspects of compatibility.

I'm not complaining. At that price, I'll find a use for it regardless.

Link to comment
Share on other sites

Yeah, C1 is aiming for mostly-Pi-compatibility. There's, like, 3 pins that don't match.

Sounds like really unprofessional response on the PcDuino front. My biggest gripe is with their forum software, which requires you to fill in, for each post, a captcha and no less than 3 anti-spambot verification questions.

But their hardware seems to work so far for the things I want to do with it so it's not all bad. :smile:

My christmas holiday starts this friday, so things will speed up around then...

Oh, lest I forget, I ordered some small heatsinks and thermal tape for them. I noticed the chip gets a bit warm to the touch and since the box it'll be in isn't very open, nor will there be any fans spinning, I thought it'd be prudent to include this. And since you can only get these things for a sensible price when you buy them in bulk, I ordered 20 on the assumption that I can affix them to the Odroid-C1's I'm going to put in my cluster aswell.

Edited by Cooper
Link to comment
Share on other sites

I ended up going with this layout:
The reason for that is the screw holes for the backing board. It's just a chunk of 17x17(ish) plexi intended to take the place of an ITX board in an enclosure, but I want to screw it down so the holes need to be where they are on an ITX and I have to be able to screw this board in place when all the other stuff is already on there. I have room next to the boards on all sides except the what is the bottom in this image which is where the cables will exit the enclosure. By setting things up like this I can still connect the USB power cable to the left PcDuino without having to struggle with the SATA board.

The SATA board and the buck converter are screwed in place whereas the PcDuinos are held in position by 4 nails each, which I've cut to I'd say just over a centimeter in height. The nails have their heads glued to the bottom of the underside of the plexi and the PcDuinos simply slide over them. Gravity is going to have to keep them in place since I couldn't find any screws with a 2mm diameter which is what the size of the holes in the boards is.

I had my first attempt at compiling my own kernel on one of them and failed sort of miserably. Everything got built but it wouldn't boot. I'm taking a long, hard look at how the Arch Linux people have done it as well as the Linux-sunxi website (which I should've done in the first place) as doing so in the first place would've saved me time and disappointment. Advice like "don't bother with mainline just yet as a lot of stuff doesn't work there yet, use our modified 3.4 kernel instead" is best read before you let the board compile everything in the hope you've configured it properly...

More in the days to come...

Link to comment
Share on other sites

The nails came loose from the board, so I decided to glue some tape over it. Problem was, the head of the nails stuck out sufficiently to prevent the tape from sticking.
So I took a drill and a bit slightly wider than the width of a nail head and took away some plexi from the top of the first hole allowing the head to sink in and be flush with the rest of the board.

I repeated the procedure for a second hole. Feeling confident I went to the third....


As in shit...

It did however turn out to be a blessing in disguise because while it might not be immediately obvious, I had the board... upside down. That's right: all the parts were attached to what should've been the underside of the board. :huh: Hooray for idiocy.

But knowing now what I didn't know then I set out to try again. I found that my jigsaw had a knob that controlled how fast the saw should move, obviously set to the max. When I turned that down to the lowest setting the saw just glided through the plexi like a hot knife through butter and this time not splintering any plexi along the way. Since I expected some cracks I cut out the chunk for the board with some room to spare. As this went really well I used the jigsaw to trim off the excess aswell which also went suspiciously smoothly. This left me with 4 thin strips of plexi. I divided the strip of plexi into 16 roughly similarly sized bits by slightly cutting into the plexi with a small hacksaw and then drilled 8 of them with a small, 2mm drill and the other 8 with a larger, 5mm drill. I then cut away the bits using a simple cutter so I now had 16 small chunks of plexi, 8 with a hole just big enough to put a nail through and 8 with a hole big enough to fit the head through. I glued a bit with a small hole on top of one with a larger hole and then glued the two, with the nail in it, onto the backing board, using a PcDuino as a guide. The end result looks like this:


By doing it like this the nails themselves are simply held in place but not fixed so there's a bit of wiggle room as you slide a PcDuino over them. Which is perfect for me since I know I wouldn't be able to achieve the precision needed to attach the boards using a fixed nail. Another possible advantage of having mounted the boards like this is that the boards are now some 4 mm elevated from the backing board. This could prevent heat from building up under the board.

The next challenge will be to wire up the electrics and discover just how much power all this, including the harddisks, needs to operate.

Edited by Cooper
Link to comment
Share on other sites

Appreciated. :smile:

Rest assured, I'll be seeing this one through, although my time is pretty much booked up to and including christmas day.

What I did do in the mean time is work on attaching the SATA cable. As you might notice from the last picture in my last post the 1-to-5 sata board's single SATA connection is right in front of the higher parts of the PcDuino. Most of the regular USB cables I have come with a connector that's too large to fit in the space between and the ones I have that operate at a 90 degree angle have the SATA cable moving down. It's possible to use that, but I'd have to cut a hole in the plexi to guide the cable through. Might not be such a bad idea to do so anyways, but in the mean time I'm first having a go at this:



I've found in my spares box a SATA cable with an almost sufficiently short connector. It had a bit of plastic at the end positioned over the red plastic which I carefully cut away allowing a nice and tight bend. It's not even touching the PcDuino now, although when I look at where the connector and the red plastic meet I can see bits of shiny metal coming through. I'm hoping that's just isolation, otherwise I'm quite confident I've destroyed a SATA cable and my only recourse is to cut that hole in the board for the 90 degree cable. I'm also bending the cable fairly sharply where I connect it to the PcDuino. This is because the enclosure it'll go into is a 1U box so there's not that much height and if I let nature run its course the rigidity of the SATA cable is such that it would easily pull the PcDuino up from the board. If I do end up going with the 90 degree angled cables, I'm going to try and find one with angled connectors on both ends.

Edited by Cooper
Link to comment
Share on other sites

Did a bit of work wiring things up a bit.


As you can see, only the harddisks are connected, the buck converter allowing me to provide 5v and the associated ground for the molex connector. Note that those wires are routed underneath the converter to keep the wiring mess to a minimum and relative to the previous image I turned the converter around.

Once I attached the power brick things powered up... and down then up again... and down. Clearly 3 harddisks spinning up at exactly the same time was too much for this 40W power brick. Thankfully I also had a 60W power brick on stand-by and once I swapped those two around things powered up and remained powered up. Out of the 3 harddisks that will be connected in the final setup, the WD drive does staggered start up meaning it won't actually spin up the drive until the OS tries to detect what partitions are on it so in that I might just get away with the 40W brick again, but for the time being I'll just stick with this one. Size-wise it's larger but a lot flatter. The thin-ness and larger surface should allow more heat to escape if that were to become an issue.

Next up: Wiring in the other components.

Link to comment
Share on other sites

For now it remained cold to the touch, but I haven't stressed it by any means - 2A tops and this thing is rated for 6. I need to hook up the boards still but family obligations and the fact that I've currently got a ball of snot where my brain used to be is slowing me down quite a bit. Typical, eh? Getting ill when you've got time off. Happens every time...

Link to comment
Share on other sites

Heatsinks arrived in the mail today.


Perfect fit I'd say. Still waiting on the thermal tape so this image is more for the visual than anything.

I read back over this thread and I noticed this:

I've got 2 Samsungs that are rated "+12V/+5V 0.5A, 0.85A" and the WD says "12V 0.45A" "5V 0.6A". So the 3 harddisks combined swallow 1.3A. The Nanos themselves can take up to 4A total, but that's everything maxed out and with power hungry USB devices attached. That leaves about 0.7A for the SATA port multiplication board. I think that should remain within bounds, and doubly so when the boards aren't doing much of anything which should be most of the time...

Interesting bit of math going on there. 0.85+0.85+0.6 = 1.3 ... I must've used an original Pentium to compute that. So, 2.3 A for the harddisks means the nanos better not be claiming their 2A aswell or that Buck converter is likely to start bucking. I'll need to keep an eye on this...

Link to comment
Share on other sites

Just read through my Cluster topic again and I noticed that this buck converter, which I previously thought to be rated at 6A, is in fact rated at 15A.

I'll get nowhere near that, but it's nice to know that instead of dangling over the edge I've actually got substantial headroom here.

Link to comment
Share on other sites

The thermal tape arrived today. It's like double-sided tape except that it transfers heat way (waaaaay) better.


The tape itself is white, blue is the color of the plastic cover you need to peel back to get to the sticky bit. The heatsinks are now properly attached but it all looks like in the image I posted previously so no point in making a new pic of that.

Link to comment
Share on other sites


Everything wired up for power, with the power on. All that remains is the SATA cables between the 1-to-5 board and the harddisks, verifying that the one SATA cable you see in the image wasn't destroyed as I cut away plastic to allow it to make that first bend and building the kernel such that I can run Gentoo off of this. Might even start with an original kernel that boots into Gentoo. Probably a bit easier.

I will at some point have to redo the cabling a bit where the 5v and ground exit the buck converter. Those cables don't go in there quite right and because of that the screw doesn't seem to 'grab' the wire. As a result of that, when I moved the board away the cables instantly came loose again. Maybe I have to put some solder on it or something, I don't know. One thing's for sure though, the power supply holds up nicely with everything attached so in terms of overall viability of the concept I'm right where I expected to be. :smile:

Link to comment
Share on other sites

Redid the wiring since it was kinda loose to begin with and ended up shorting. It's solid now and for the last hour or so the setup seen in the previous image has been effectively idling on my desk.
Total power draw, idling as I said, with three harddisks attached is just under 30W which is AWESOME. You see, this isn't running with the three harddisks I'll be using when I'm done but three rather older 250gb disks. I said previously

I've got 2 Samsungs that are rated "+12V/+5V 0.5A, 0.85A" and the WD says "12V 0.45A" "5V 0.6A".

The harddisks I've got hooked up right now are 3 Seagates rated 12V 0.52A / 5V 0.72 so the 12v power draw is marginally higher and the 5v power draw somewhat in between. Main difference is that, possibly because they currently aren't being addressed by any sort of logic, the harddisks don't go into power saving mode like the ones in my current fileserver do, shutting off the drive motor. So when this setup really starts idling the power draw should decrease somewhat more. Maximum power draw measured at the wall was 63W so it's getting close to what the power brick can handle. Then again, that WD drive doesn't spin up until you actually address it so chances are even the peak power draw in the eventual setup will be less.

Temperatures, and mind you, all I did was power it up - they really haven't been doing anything so far - are fine. The heatsinks on the Nanos get warmish, the ones on the buck converter even less so. My thermometer says ambient temperature is 19.5 degrees and the heatsink on the Nanos is 32.9 and the heatsink on the buck converter just 26.0 degrees (all Celsius, obviously). The hottest item in the setup are the harddisks themselves at 39.7 so all in all this is looking really good.

Link to comment
Share on other sites

Having detached the harddisks I began anew with installing Gentoo on one of the Nanos. Currently that machine is compiling the git sourcecode and its associated dependencies and the heatsink on the CPU warms up to 38.7 degrees. Maximum power draw during this was 6.4 watts which, due to the absence of the harddisks, was all down to the Nanos and the 1-to-5 SATA board so in total this setup with one board actually doing something significant made it draw about 1.3 amps.

I'm using for my CFLAGS variable (compiler options used when compiling a package):

-O2 -pipe -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -fomit-frame-pointer

The -mfpu switch might need a bit of explaining. On ARM you have the NEON instruction set which is similar to MMX/SSE/3DNow instructions for the x86 platform. These instructions use the registers reserved for the FPU which is why they're mentioned here. The 'vfpv4' bit stands for Vector Floating Point version 4. By comparison, an Odroid's Cortex-A9 has a v3. Main difference between v3 and v4 being that v4 supports additional instructions for fused-multiply-add (C=A+B in 1 instruction rather than the typical C=A C=C+B requiring 2 instructions). The 'float-abi' being 'hard' means that the CPU has a hardware FPU unit which, in the ARM world and in particular the cheaper and even less electricity-guzzling types, this is typically something that gets omitted and worked around by either changing the algorithms to only need integer math or by using a software library that computes a floating point number using integer math (which is invariably slower).

It's worth noting that when I partitioned my SD card, I created 2 partitions: root and boot, where boot is a standard ext2 of 64 megs and the rest of the 16 gig SD card became an ext4 filesystem with 1 inode for every 2 blocks (one for every 8k of diskspace, indicated to mkfs.ext4 via the '-i 8192' parameter - typical being 1 inode for every 4 blocks, or 16k of diskspace) which is needed because of my scheme of unifying the contents of multiple harddisks by creating an exported folder on my main filesystem (the SD card) which only contains links to the actual files on the harddisk. This scheme allows me to quickly list and inspect the server's contents without actually needing to spin up the drives until I actually try to read the actual file. Since links only contain the filename of the real file they reference, they claim next to no storage on the filesystem, but they do require one inode each which is why I need more than the typical amount of inodes for my filesystem.

Link to comment
Share on other sites

Okay, those not particularly interested in setting up Gentoo on your PcDuino Nano 3 can probably skip this post, as I'll be detailing here the various steps I took to get things going on the device. I'll be editing this post as development progresses.

Start the Nano without the MicroSD card inserted and let it boot to desktop. Start a terminal (lxterm) and from there start sshd if needed and note the IP address. I prefer going this route as I only have 1 monitor and I want to watch some video and such on it as this thing compiles everything so at this point I switch back the monitor and ssh into the device. Login with ubuntu/ubuntu.

Insert the SD card. Any partition on there of a recognised type will be automounted (I *HATE* that feature) so make sure to unmount any /dev/mmcblk0* partitions before you continue.
Fdisk the card. Drop everything, then create 2 partitions. The first will become the boot partition and 64M large. The second partition can have the remainder of the SD card (note that you might get away with using an 8 GB card, but I'd recommend a 16 GB one). The boot partition ought to be bootable, but the Nano doesn't care either way. Use mkfs.ext2 to create a filesystem on the boot partition and mkfs.ext4 to create one for the root parititon. Because of my way of unioning the eventual harddisks using symlinks on the root filesystem, I make sure to create a relative abundance of inodes. Feel free to skip that bit.

mkfs.ext2 /dev/mmcblk0p1
mkfs.ext4 -i 8192 /dev/mmcblk0p2

Set the time on the machine since by default it starts with a date in 2010 which can cause all sorts of stupid warnings.

date --set "11 JAN 2015 11:22:33"

Create a /mnt/gentoo (in keeping with the Gentoo handbook) mountpoint and mount the root filesystem there. Then create a boot directory in it and mount the boot filesystem there.

mkdir /mnt/gentoo
mount /dev/mmcblk0p2 /mnt/gentoo
mkdir /mnt/gentoo/boot
mount /dev/mmcblk0p1 /mnt/gentoo/boot

Download the latest Gentoo stage3 tarball for ARMv7a with hard fp and unpack it in /mnt/gentoo

tar xjpf stage3-armv7a_hardfp-*.tar.bz2 -C /mnt/gentoo

Prepare the system for chrooting into this environment. Since on ubuntu /dev/shm is a link to a location that will become inaccessible from the chrooted environment, recreate it properly.

rm /dev/shm && mkdir /dev/shm
mount -t tmpfs -o nosuid,nodev,noexec shm /dev/shm
mount -t proc proc /mnt/gentoo/proc
mount --rbind /sys /mnt/gentoo/sys
mount --make-rslave /mnt/gentoo/sys
mount --rbind /dev /mnt/gentoo/dev
mount --make-rslave /mnt/gentoo/dev

Enter the chrooted environment.

cd /mnt/gentoo
chroot /mnt/gentoo /bin/bash 
source /etc/profile

Welcome to Gentoo. Start by updating the local portage tree and then installing an actual editor.

emerge vim

Edit /etc/portage/make.conf and set your CFLAGS to -O2 -pipe -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -ffast-math -ftree-vectorize -fomit-frame-pointer.

You should NOT add a MAKEOPTS variable to let make use multiple processes during building - it's my personal experience that on this setup it throws the build process off signficantly. Feel free to give it a try, but if your build process gets stalled, know that leaving this out can at the very least reduce its frequency.

Add GENTOO_MIRRORS and SYNC urls as per the handbook and tweak the USE variable to your hearts content. For the latter I highly recommend including -X meaning no X support. This is going to be a little server after all.
Since every so often the ssh link to the device stalls and sometimes doesn't recover, we'll need the 'screen' tool to allow us to reconnect to the shell in which the build process is running, so install that.

emerge app-misc/screen

And once it's done start it.


Next time an ssh session stalls, recover it with this set of commands

sudo su -
cd /mnt/gentoo
chroot /mnt/gentoo /bin/bash 
source /etc/profile
screen -rd

Edit /etc/fstab to point to the appropriate boot and root partitions, remove swap, fd and cdrom and add this tmpfs mountpoint to speed up the compilation of packages during emerging:

none            /var/tmp/portage        tmpfs   noatime      0 0

Some big packages need the RAM for the actual compilation, so create a config file named /etc/portage/env/notmpfs.conf with the following contents:


Create that /var/tmp/notmpfs directory. Then, create the /etc/portage/package.env file and for each large package add a line like this (to recompile the base system, this will suffice. Add more as required):

sys-devel/gcc notmpfs.conf

Also, the sys-libs/db package doesn't compile with that -ffast-math parameter to gcc. Create the file /etc/portage/env/sys-libs/db with the following contents

CFLAGS="-O2 -pipe -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -fomit-frame-pointer"

Note that some packages, such as gcc, are actually so memory-intensive that the 1GB of RAM on the Nano is insufficient. For those situations it's best to temporarily add a swapfile like so:

dd if=/dev/zero of=/swapfile bs=1024 count=1048576
chown root:root /swapfile
chmod 0600 /swapfile
mkswap /swapfile
swapon /swapfile

When compilation completes, simply turn off the swapfile and remove it again.

swapoff /swapfile
rm /swapfile

It's best not to use a permanent swap partition on an SD card as that could seriously reduce the longevity of the card. If a regular harddisk is available for swap, using it instead is highly recommended.

Check the currently set profile. The list produced is rather long (30+ entries) but in my case it was already set to the appropriate value (default/linux/arm/13.0/armv7a).

eselect profile list

Set the appropriate timezone for the system.

echo "Europe/Amsterdam" > /etc/timezone
emerge --config sys-libs/timezone-data

Use the 'date' command to verify things are in order.
Edit the locale such that at least ISO-8859-1 and UTF8 are present. Next, generate them and pick one, preferably the UTF-8 one, which might not have the number 5 on your system. End by reloading the environment so everything is aware of the locale.

vi /etc/locale.gen
eselect locale list
eselect locale set 5
env-update && source /etc/profile

Next we start installing the u-boot bootloader which is a bit involved as you need to grab it from a git tree. So start by emerging git.

emerge dev-vcs/git

Next, enter /usr/src and clone the appropriate u-boot repo here.

cd /usr/src
git clone --depth 1 https://github.com/linux-sunxi/u-boot-sunxi.git

This u-boot repo supports lots of boards based on the AllWinner CPU and many others aswell. There's an overview in the boards.cfg file but to find my board I just did a quick case-insensitive grep for pcduino on that file and got 2 matches:

Active  arm         armv7          sunxi       -               sunxi               Linksprite_pcDuino3                  sun7i:LINKSPRITE_PCDUINO3,SPL,SUNXI_GMAC,FAST_MBUS
Active  arm         armv7          sunxi       -               sunxi               pcDuino                              sun4i:PCDUINO,SPL,SUNXI_EMAC

The main and easily verifiable difference is the GMAC vs EMAC option - EMAC is 100MBit mac whereas GMAC is gigabit mac. Clearly I need to build u-boot for the Linksprite_pcDuino3 target.

cd /usr/src/u-boot-sunxi
make distclean
make Linksprite_pcDuino3_config

This will produce 3 files we need: u-boot.img spl/sunxi-spl.bin and tools/mkimage
The first two files are the bootloader, the third one is a tool used in creating a 'uImage' of the kernel and is used to create a file used by the bootloader aswell further along in the process.
First we install the bootloader. On the SD card, the region with offset 8K and size 32K needs to contain the SPL initial loader. The next 512K should contain u-boot itself and the 128K after that contains its environment which needs to be cleared.

dd if=spl/sunxi-spl.bin of=/dev/mmcblk0 bs=1024 seek=8
dd if=u-boot.img of=/dev/mmcblk0 bs=1024 seek=40
dd if=/dev/zero of=/dev/mmcblk0 bs=1024 seek=552 count=128

To finish up, we copy the mkimage program to /usr/bin

cp tools/mkimage /usr/bin

Next up is creating the kernel. The latest mostly stable one at this point in time is the 3.4.104 kernel, so head back into /usr/src and make a git clone of that (they currently have an experimental 3.14 branch, but leave that for later).

cd /usr/src
git clone --depth 1 git://github.com/linux-sunxi/linux-sunxi.git -b sunxi-3.4

Someone was kind enough to create a default configuration in the Linux kernel for boards like this, so use that as a starting point but some changes are still required. The default configuration supports the emac (which isn't present on the board) and creates only a module for gmac so remove emac support and change gmac support to Y. This is controlled by the "Allwinner Ethernet MAC support" option for emac and "Sunxi platform 10/100/1000Mbps Ethernet driver" for gmac, both of which can be found in Device Drivers/Network device support/Ethernet driver support. There's a *TON* of additional things that will be configured in with the default config. Sifting out which of these are relevant will be a task for some other time and very specific to what you want to do with your system. Know at least that if you do just this you should get a working kernel.

cd /usr/src/linux-sunxi
make sun7i_defconfig
make menuconfig
make uImage modules

And install the kernel and its modules at the appropriate locations.

cp arch/arm/boot/uImage /boot
make modules_install
make firmware

The kernel needs a configuration file provided to it by the bootloader in a specific format. There are git repos for these config files and for tools to convert this config file into something the kernel can work with. Grab them.

cd /usr/src
git clone --depth 1 git://github.com/linux-sunxi/sunxi-tools.git
git clone --depth 1 git://github.com/linux-sunxi/sunxi-boards.git

The tool we need is fex2bin and the board file is linksprite_pcduino3.fex. Compile the tool and then use the tool to convert the board file.

cd /usr/src/sunxi-tools
make fex2bin
./fex2bin /usr/src/sunxi-boards/sys_config/a20/linksprite_pcduino3.fex /boot/script.bin

Create the bootloader's configuration file /boot/boot.cmd with the following contents:

setenv bootargs console=tty0 hdmi.audio=0 disp.screen0_output_mode=1280x720p50 console=ttyS0,115200 root=/dev/mmcblk0p2 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 consoleblank=0 rootwait panic=10
ext2load mmc 0 0x43000000 script.bin
ext2load mmc 0 0x48000000 uImage
bootm 0x48000000

Using a tool from the u-boot tree, create an image of that file.

/usr/src/u-boot-sunxi/tools/mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

Time to finish up, in line with the Gentoo handbook again. Edit /etc/conf.d/hostname and provide a hostname.

The name of your network device will be eth0. Edit /etc/conf.d/net and provide a mac address for it.


Set things up so it starts at boot.

cd /etc/init.d
ln -s net.lo net.eth0
rc-update add net.eth0 default

Set a root password for the system.


Install a system logger, cron daemon, dhcp client and setup sshd to start at boot.

emerge app-admin/syslog-ng sys-process/cronie net-misc/dhcpcd
rc-update add syslog-ng default
rc-update add cronie default
rc-update add sshd default

Due to the problem with the system time not being retained by anything, we need to install an NTP client to do it for us on boot.

emerge net-misc/ntp
rc-update add ntpd default

The kernel used is based on Linux 3.4 but when you upgrade Gentoo it will install, amongst other things, the latest version of the linux-headers package which contains the header files for the latest kernel whose sources are available, which is typically the very latest kernel around. What we need to do is install the linux-headers package for Linux 3.4 and then prevent updates to that package in the future.

emerge =sys-kernel/linux-headers-3.4-r2
mkdir -p /etc/portage/profile
echo "sys-kernel/linux-headers-3.4-r2" >> /etc/portage/profile/package.provided

Note that after updating the linux-headers package it's recommended you update glibc. This will take a while...

emerge sys-libs/glibc

Unmount all previously mounted filesystems and restart the board, otherwise just reset using the power plug. This time leave the sd card in the device as it starts up. Check the screen to make sure everything's on the up-and-up. One thing I noticed is that on reboot /dev/fd was missing. It's used extensively by emerge, so make sure it exists and if it doesn't, create it with this command:

ln -s /proc/self/fd /dev/fd

Since it's a Gentoo machine, I recommend you now rebuild the complete system. It will take a while, but it will be a good stability test and you'll end up with the perfect system for this board.

emerge -e world
Edited by Cooper
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.

  • Create New...