guix-devel
[Top][All Lists]
Advanced

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

Re: Guix on the ASUS C201PA


From: Timothy Sample
Subject: Re: Guix on the ASUS C201PA
Date: Wed, 06 Mar 2019 09:33:20 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hi Vagrant,

Vagrant Cascadian <address@hidden> writes:

> On 2019-03-06, Timothy Sample wrote:
>> I was able to get Guix to boot on an ASUS Chromebook C201PA.  This model
>> of computer is pretty neat.  It’s an ARMv7 (32-bit) machine that can be
>> run with entirely free software.  There is even a free graphics driver
>> in the works [1].
>
> Very excited to try this!
>
> I've been working on getting Debian to work on it for years, and had it
> working with linux 4.8.x... and then haven't gotten it working with any
> kernel version since. I've very recently been trying to get Archlinux
> and Parabola working on it, but haven't gotten very far yet...

Arch Linux ARM worked well enough for me.  It even boots from stock
Google firmware.  It was the system I used to build Guix.  I assume that
Parabola would be similar.

>> For the bootloader, these machines use Depthcharge.  Depthcharge boots a
>> specially packaged and signed kernel image from a specially marked
>> partition.  This kernel image is written to the partition directly
>> without a file system.
>
> I have two big technical frustrations with Depthcharge:
>
> It's really hard to debug or select alternate kernels when boot is
> failing.
>
> The kernel+initrd is limited to ~16MB. linux-libre on armhf is about
> 5MB, and the initrd around 11MB... so it's running pretty close to that
> limit (Debian initrd's are even larger these days). I even increased the
> size of the partition to 32MB to see if it would work, but it refused to
> boot from anything larger than 16MB.

I didn’t know about the image size limit.  Guix (with the very spartan
PrawnOS kernel build) is only 14M, so I guess I was just lucky here.

It might be worth trying to better mimic what Google does with
ChromeOS.  That is, you could lay out the disk as follows.

    p1. kernel-a
    p2. initrd-a
    p3. kernel-b
    p4. initrd-b
    p5. root

If you could get initrd to run correctly from a separate partition, then
you could both make use of Depthcharge’s fall-back feature and avoid the
size limitation.  In Guix, we could toggle which kernel and initrd
partition we write to and set the boot priorities appropriately.  This
would allow one to fearlessly run “guix system reconfigure”.

> [...]
>
> Thanks for working on it, and I'll try it out and report back.

Good luck!


-- Tim



reply via email to

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