From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: ARM: Installation and Booting; was: Re: GuixSD on ARM; Date: Wed, 13 Jul 2016 11:11:36 +0200 Message-ID: <20160713111136.645c3248@scratchpost.org> References: <5f0fbebb97ed071ef040f4bb0e3f046c@d4n1.org> <87vb0a10ys.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNGCw-0002ce-LX for guix-devel@gnu.org; Wed, 13 Jul 2016 05:11:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNGCq-00040V-EG for guix-devel@gnu.org; Wed, 13 Jul 2016 05:11:53 -0400 Received: from dd1012.kasserver.com ([85.13.128.8]:38512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNGCq-00040N-3y for guix-devel@gnu.org; Wed, 13 Jul 2016 05:11:48 -0400 In-Reply-To: <87vb0a10ys.fsf@elephly.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus , Daniel Pimentel , guix-devel@gnu.org On Wed, 13 Jul 2016 08:55:23 +0200 Ricardo Wurmus wrote: > It would be very nice to be able to use GuixSD on the EOMA68. Alas, I > don=E2=80=99t 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.=20 - it checks whether a special "FEL" button is pressed. If so, it uses USB t= o "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 F= ree 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-Bo= ot. 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 the= n cut down], just without module support. So there would need to be differe= nt 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 boo= t media you used to run the installer with) The U-Boot SPL is searched for at a fixed sector on the drive - that can ma= ke partitioning ... challenging. The first few times I accidentially overwr= ote U-Boot by just having gdisk start the partition at its default suggeste= d 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 i= t because many other SOCs (which they want to use) don't have it. How is th= at 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 tim= e (read: Linux kernel takes days to compile). However, I think it's more tr= ustworty than the usual x86_64-nobody-knows-what-it's-doing - so I still co= mpile things directly on it, if possible. Other ARM processors, including newer Allwinner ARM processors, are much fa= ster. However, most ARM vendors dropped SATA support - which frankly makes = me wonder how people are using this as a production (as opposed to consumpt= ion) 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-lev= elling layer. So either you use a special filesystem (ubifs etc). Or you us= e a wear-levelling driver (ubi) and then on top of that a filesystem with T= RIM 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 we= ar levelling) - however, the mainline Linux kernel supports everything on t= he A20 quite well - except G2D acceleration and video (as in movie) acceler= ation - both of which *have* been reverse engineered; just the mainline sup= port 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 i= t. Sigh. You basically are supposed to use i2c-tools to manually store it t= here 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 EOM= A68 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 nt= pd. 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 m= eans the default Debian systemd configuration is right out. I haven't got t= his 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]