On Wed, 13 Jul 2016 08:55:23 +0200 Ricardo Wurmus <rek...@elephly.net> 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]
