guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Porting GuixSD to ARM article.


From: Danny Milosavljevic
Subject: Re: Porting GuixSD to ARM article.
Date: Mon, 22 Jan 2018 22:51:27 +0100

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
<https://sourceware.org/bugzilla/show_bug.cgi?id=22273>.

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]