ARM: Installation and Booting; was: Re: GuixSD on ARM;

[Danny Milosavljevic]

On Wed, 13 Jul 2016 08:55:23 +0200
Ricardo Wurmus <address@hidden> wrote:

> It would be very nice to be able to use GuixSD on the EOMA68.  Alas, I
> don’t have an overview on what work needs to be done to get there.

First, we'd need to get it to boot.

For example for the Allwinner A20 board:

Allwinner A20 boot process is:

- the boot ROM (which is Free Software - cool!) runs. 
- it checks whether a special "FEL" button is pressed. If so, it uses USB to 
"debug upload boot". Otherwise:
- it checks SD-card and then NAND availability
- it checks whether user wants to abort autoboot via USB keyboard or serial. If 
not:
- On the first available device, it loads (mainline) U-Boot SPL (which is Free 
Software)
- U-Boot sets up the DCDC voltages, RAM (!), display and USB
- U-Boot does what it is told in its config file - which is usually to load the 
Linux kernel and device tree file from somewhere to some fixed memory address 
and then jump to it.

So if we want GuixSD to work on it, we need U-Boot support.

U-Boot has a LOT of special cases for strange embedded hardware and I doubt it 
makes sense to duplicate it in Grub. So I'd just chainload Grub in U-Boot.

Also, one compiles U-Boot for a specific board - it's kinda like the Linux 
kernel config [actually, most of the drivers were copied from Linux and then 
cut down], just without module support. So there would need to be different 
packages maybe - like u-boot-a20-lime2, u-boot-a20-eoma68, u-boot-a20-... . 
Also, not sure whether the installer could in principle detect what it's 
running on - or copy the U-Boot config or entire U-Boot over from the boot 
media you used to run the installer with)

The U-Boot SPL is searched for at a fixed sector on the drive - that can make 
partitioning ... challenging. The first few times I accidentially overwrote 
U-Boot by just having gdisk start the partition at its default suggested sector.

The sectors are just after the master boot record and weird GPT-thingie. I'm 
leaving a gap there now and everything works fine. Maybe would make sense to 
make a dummy partition take up the space - I did not try it, though.

Also, while Allwinner A20 has SATA support, the EOMA board doesn't supply it 
because many other SOCs (which they want to use) don't have it. How is that 
future-proof?

If you do use SATA, you still need to put U-Boot on SD or the Flash. U-Boot has 
SATA support so it can load Grub etc from the hard drive.

In any case, setting this stuff up manually is not for the faint of heart. So 
it would be nice if an eventual GuixSD installer would do that, too - if we 
officially support ARM.

The Allwinner A20 is quite slow by today's standards. Not Raspberry Pi slow - 
but maybe 4 times as fast as it. Compiling useful things take a long time 
(read: Linux kernel takes days to compile). However, I think it's more 
trustworty than the usual x86_64-nobody-knows-what-it's-doing - so I still 
compile things directly on it, if possible.

Other ARM processors, including newer Allwinner ARM processors, are much 
faster. However, most ARM vendors dropped SATA support - which frankly makes me 
wonder how people are using this as a production (as opposed to consumption) 
machine - SD cards *will* break after some writing (mine broke after < 2 
months).

The Flash is connected directly. So if you wrote to it regularily (I don't - I 
have a SATA drive for that), you'd have to make sure there's a wear-levelling 
layer. So either you use a special filesystem (ubifs etc). Or you use a 
wear-levelling driver (ubi) and then on top of that a filesystem with TRIM 
support.

The Allwinner Linux kernel doesn't support any of that (they have their own 
weird-ass NAND driver which exposes a block device which doesn't do any wear 
levelling) - however, the mainline Linux kernel supports everything on the A20 
quite well - except G2D acceleration and video (as in movie) acceleration - 
both of which *have* been reverse engineered; just the mainline support isn't 
there yet.

Also, I disabled disk encryption because it's too slow to be usable.

That said, the board I have runs as a (home) server 24/7 for 1.5 years now 
without issues. In the mean time one x86_64 laptop broke and the second one has 
fan issues. So A20 (1) is slow but (2) is rock solid stable (3) needs no fan. 
Also I have a 2 TB hard drive on it which does 80 MB/s reading and 20 MB/s 
writing on that hardware.

It has Ethernet - but it depends on the board vendor whether you can store the 
MAC address in (custom) hardware or not. LIME2 has an EEPROM accessible via I2C 
for that. However, the default Linux Ethernet driver doesn't use it. Sigh. You 
basically are supposed to use i2c-tools to manually store it there or 
something. At that point I can just store it on the SD card :P

If you don't store the MAC address, it will use a random one every time it 
boots - that's bad for other network devices like switches, routers etc.

Also, many boards don't have an external RTC and don't supply battery power to 
the internal RTC. That means the computer's idea of time will be wrong and so 
SSL won't work. I usually use NTP to fix that (*). Not sure what EOMA68 does.

(*): in order to fix the time you need NTP. But ntpd will not correct times 
that are so far off. So you need to stop ntpd and run ntpdate and start ntpd. 
For that, network has to work. So you need to have read the MAC address 
manually, set up the network, ran ntpdate and then everything else. That means 
the default Debian systemd configuration is right out. I haven't got this to 
work automatically. [I use it as a server so it doesn't matter much to me to do 
that manually once a year or something]