[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ARM: Installation and Booting; was: Re: GuixSD on ARM;
From: |
Danny Milosavljevic |
Subject: |
ARM: Installation and Booting; was: Re: GuixSD on ARM; |
Date: |
Wed, 13 Jul 2016 11:11:36 +0200 |
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]
Re: GuixSD on ARM, Ludovic Courtès, 2016/07/13