From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: Porting GuixSD to ARM article. Date: Mon, 22 Jan 2018 22:51:27 +0100 Message-ID: <20180122225127.28494aa4@scratchpost.org> References: <87shc2c3fh.fsf@gmail.com> <20180122211500.GA2400@jurong> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51484) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1edk09-0000VT-C6 for guix-devel@gnu.org; Mon, 22 Jan 2018 16:51:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1edk06-0002KK-9f for guix-devel@gnu.org; Mon, 22 Jan 2018 16:51:37 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:43488) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1edk06-0002Id-1L for guix-devel@gnu.org; Mon, 22 Jan 2018 16:51:34 -0500 In-Reply-To: <20180122211500.GA2400@jurong> 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: Andreas Enge Cc: Guix-devel Hi, > - In my case, I own an Olimex Lime 1. I think that this might correspond > to a20-olinuxino-micro-installation-os. Whatever it is, it does not have > integrated memory, but needs to run directly from the micro SD card. I've added a20-olinuxino-lime-installation-os to guix master now. I don't have the Lime1, so please test it. > So how do I install it, since I cannot boot from one medium and install > easily to another one? Should I attach an SD card reader to install onto > a second SD card, then boot from that in a second step? Yes, that's a possibility. You can also transfer over the network etc. What this installation-os disk-image gives you is an image file. You can transport it on non-SD cards. In the end it has to somehow end up on an SD card, of course :) I've also tested our new "--system" facility which allows us to build the ARM image on x86_64 - but I'm sad to say that glibc has a bug which makes the build fail . In short, right now you have to build armhf images on an armhf machine (which takes foreeeever). At least it doesn't have to be exactly the same machine, so I volunteer the guix build farm's Novena :-> It still bothers me that we build these huge images for different ARM systems although only u-boot, MAYBE the kernel and MAYBE the debug tty differ. We should change it not to build common parts again, I think. The easiest way to do that would be to build a generic ARM image with extlinux bootloader (i.e. without u-boot itself), the multi ARM Linux kernel (we do that already) and then have the agetty fish out the console from the kernel command line at runtime (so that the agetty configuration is not different either). We could add a new argument to the kernel command line, or fish the tty out of the existing "console" kernel argument. We can boot the system via the vendor's u-boot (all ARM systems I've used have one) and our Linux kernel & GNU system. In the booted system, one can then reconfigure with u-boot (or not). That way, we'd have only one ARM image for all ARM (v7) systems.