Produces a router-focused Alpine build for AARC64 systems.
Most of the work involved in adding a new system is just tuning the kernel configuration for that system.
Currently, we can produce images for:
Note that for the RockPro64, the kernel is tuned specifically for my needs, and it may not work for you.
bash build-image.sh -t <platform>
(When upgrading, you want to wipe everything from the partition and explode into an empty filesystem.)
You should now be able to put this MicroSD card into your system, power it on, and 30-45 seconds later, you'll have an Alpine prompt! For the RockPro64, there will be a console on both HDMI and the serial console. For the Macchiatobin, this will only be on serial.
From here on, you can follow the usual Alpine installation instructions.
This is very much a self-serving project, so there's a very good chance you'll be surprised by some things in here. Specifically:
iptablessupport is in the kernel.
All the things I'd like to change but haven't gotten around to yet:
nftablesfor firewall management,
ethtoolto troubleshoot network issues, and ... I forget the rest, but I have them noted down ... somewhere.
mmcdevice automatically (to be used for LBU)
vlanpackage conflicts with
ifupdown-ng, and including it in the base package set results in a broken world. This should be reported/fixed, as
vlanis important to us, but not
Well, yeah. This is more of a "Fun and Anticipated Questions" than a "Frequently Asked Questions".
Depends on your perspective -- but I find asking people about their grandmothers to be fun.
Yeah, that just seems to be broken right now. Which kinda breaks the whole point of the board, but right now, the PHY isn't attaching properly. I'm not entirely certain why, but at least the copper NIC is working. (The 2.5GbE interface is theoretically working, but that's not tested.)
WARNING: THIS WILL REMOVE ALL YOUR DATA
If you think you might possibly have something stored on that MicroSD card that maybe you, or your grandmother, will want to access at some point in the future, please back it up now. You will lose that data during this process.
diskpart(followed by the enter button, of course) to launch the disk partition manager
list diskto show the available disks, and figure out which one is your MicroSD card (hint: it will not be Disk 0)
select disk <n>, where
nis the number of the disk assigned to your MicroSD card
clean(this is the step that removes all your data)
convert mbrto create a new MSDOS partition table
create partition primaryto create a new partition (
diskpartwill also magically select this partition for us, which is one less thing for us to type out!)
format quick fs=fat32 label="ALPINE"to format this new partition
J-- and assign it:
Voila! You now have a blank, MSDOS-compatible, FAT32-formatted MicroSD card at your chosen drive letter (
J:, if you followed everything verbatim).
Yeah, okay, this is less than helpful. But it's late, I'm tired, and I don't want to admit to the world that I still use
fdisk and don't know how to use any of the newer partition managers.
The boards are pretty forgiving, thankfully. If you trash u-boot in the SPI, you can flash it to an MMC card directly (instructions can be found in the
Update the U-Boot link above), and re-flash to SPI from there. This is a bit too complicate for me to toss as an answer in a light-hearted FAQ, so feel free to hit me up if you need help (open an issue, @-me on Twitter, whatever).
If you think it's just the u-boot environment that needs cleaning, that's an easy fix! Get on your console, power up the board, interrupt the boot process, and then just type
env default -a followed by
env save. That's it! Your U-Boot configuration is reset to defaults. At this point, I would recommend removing power from the board -- a simple
reset doesn't always work as expected here.
Yeah. Well, as I noted above, SD cards are slow. Almost the entirety of the boot time is spent reading the
initramfs from the SD card, so I'm trying to cut out as many kernel modules as I possible can. The first successful boot I had took almost a full minute, and I managed to cut that down to about 30 seconds just by stripping unnecessary cruft from the kernel (do you really need Android driver support on this thing?).
I still have a fair bit of work to do here: some more modules to cut out, some others to add back in, then finally actually going over the configuration and making sure it actually makes sense. I'm targeting usage as a wired router: no wireless cards, no GPU support, just passin' packets.
So would I, probably. Thankfully it's pretty easy to add a package to your system once it's up and running, so modifying the base system is a lower priority right now.
Because all my cross-compiling efforts were failing, and using a pre-existing Debian install on an AARCH64 platform was the easiest way to get a stable build system up and running, with a reasonably current version of
gcc available. This configuration is also most likely to be supported in various cloud-provider CI systems, making it a reasonable target.
This will probably work on any Debian derivative (i.e. Ubuntu) with no modifications, but I haven't tested it. Using this script with any other distribution will require some slight modifications -- probably just to the package installation stuff, and the build flags we use when building the kernel. It will not work on anything that is not a Debian-derivative, mostly because it is flat-out expecting
apt to be the package manager.
Alpine's preferred boot manager (syslinux) doesn't support AARCH64, and the U-Boot support is perfectly functional. I'll admit to actually liking UEFI, but in the spirit of keeping things simple, there's no particularly compelling reason to move away from U-Boot at this time.
Yes, I certainly am! I have a list of things to look at, but if there's anything in particular you'd like to see, please let me know!