Porting GuixSD to ARM article.

Porting GuixSD to ARM article.

[Mathieu Othacehe]

Hi Guix!

A new article is available on Guix's website. It summarizes recent
progress on ARM porting topic.

https://www.gnu.org/software/guix/blog/2017/porting-guixsd-to-armv7/

Feel free to ask any question or propose follow-up actions here!
Many thanks to Ludo, Danny and Ricardo for the early review :)

Happy reading,

Mathieu

Re: Porting GuixSD to ARM article.

[Vincent Legoll]

Hello,

On Fri, Dec 22, 2017 at 2:12 PM, Mathieu Othacehe <m.othacehe@gmail.com> wrote:
> https://www.gnu.org/software/guix/blog/2017/porting-guixsd-to-armv7/
>
> Feel free to ask any question or propose follow-up actions here!
> Many thanks to Ludo, Danny and Ricardo for the early review :)

I think there are typoes:

The definition on an installation image for the BeagleBone Black.
s/on an/of an/

In "Preparing a dedicated system configuration",  I'm not sure,
but you have a "tty-O-0" in the system configuration:

(tty "ttyO0")

Isn't that a typo also ?

-- 
Vincent Legoll

Re: Porting GuixSD to ARM article.

[Pjotr Prins]

On Fri, Dec 22, 2017 at 02:12:02PM +0100, Mathieu Othacehe wrote:
> 
> Hi Guix!
> 
> A new article is available on Guix's website. It summarizes recent
> progress on ARM porting topic.
> 
> https://www.gnu.org/software/guix/blog/2017/porting-guixsd-to-armv7/
> 
> Feel free to ask any question or propose follow-up actions here!
> Many thanks to Ludo, Danny and Ricardo for the early review :)
> 
> Happy reading,

Very cool!

-- 

Re: Porting GuixSD to ARM article.

[Mathieu Othacehe]

Hi Vicent,

> The definition on an installation image for the BeagleBone Black.
> s/on an/of an/

Thanks for pointing it out.

> In "Preparing a dedicated system configuration",  I'm not sure,
> but you have a "tty-O-0" in the system configuration:
>
> (tty "ttyO0")
>
> Isn't that a typo also ?

Nope it is not. It's the name of serial port on some Omap targets.

Mathieu

Re: Porting GuixSD to ARM article.

[Mathieu Othacehe]

> Very cool!

Thanks Pjotr!

Mathieu

Re: Porting GuixSD to ARM article.

[Andreas Enge]

Hello Mathieu,

On Fri, Dec 22, 2017 at 02:12:02PM +0100, Mathieu Othacehe wrote:
> A new article is available on Guix's website. It summarizes recent
> progress on ARM porting topic.

I am reading it only now (since I wish to install GuixSD on an ARM board
of mine, but better late than never...). Very nice work and write-up!

But I still have a few questions:
- Now that there is a release 0.14, could the images not be made available
  on the website?
- 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.
  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?

  Would it not make sense to provide not installation images, but installed
  images? These could be used to directly boot the machines, and then instead
  of doing "guix system init", one should be able to do a "guix system
  reconfigure". To develop a bit more, the two-step installation (first
  creating a disk image, then installing onto the hard drive) could be seen
  as an artefact of installing on bigger machines with their more complicated
  setting using grub, and where taking out the hard disk and copying an image
  with dd onto it is not so practical... Why should it not be easier to
  directly boot the final GuixSD on an ARM machine?

  Notice that the last section of the blog post does not solve the problem:
  As I realised by trial and error when trying to use a disk-image for a
  virtual machine, it really is only an installation-image, since user data
  is stored in an overlay file system that is lost upon reboot.

- Suggestion in that context: Rename "guix system disk-image" to "guix system
  installation-image".

Thank you again for the post, and I am looking forward to more instructions
for the other boards!

Andreas

Re: Porting GuixSD to ARM article.

[Danny Milosavljevic]

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.

Re: Porting GuixSD to ARM article.

[Mathieu Othacehe]

Hi Andreas,

> I am reading it only now (since I wish to install GuixSD on an ARM board
> of mine, but better late than never...). Very nice work and write-up!

Thank you :)

> But I still have a few questions:
> - Now that there is a release 0.14, could the images not be made available
>   on the website?

I just saw that Danny proposed a patch about it!

> - 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.
>   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?

I guess you can do like I did in "Preparing a dedicated system
configuration" section of the article. That means preparing a config.scm
that suits your needs, run a "guix system disk-image
--system=armhf-linux config.scm" and dd the image obtained on a SD
card. There is no "installation image" per-se, you build the system that
you'll directly use once booted.

>   Would it not make sense to provide not installation images, but installed
>   images? These could be used to directly boot the machines, and then instead
>   of doing "guix system init", one should be able to do a "guix system
>   reconfigure". To develop a bit more, the two-step installation (first
>   creating a disk image, then installing onto the hard drive) could be seen
>   as an artefact of installing on bigger machines with their more complicated
>   setting using grub, and where taking out the hard disk and copying an image
>   with dd onto it is not so practical... Why should it not be easier to
>   directly boot the final GuixSD on an ARM machine?

Unless I don't get you right, it's already working! You don't need to
run "guix system init" like I said before. Once you booted the mpd
server, you can reconfigure it to add a new package, there's no init
involved.

>   Notice that the last section of the blog post does not solve the problem:
>   As I realised by trial and error when trying to use a disk-image for a
>   virtual machine, it really is only an installation-image, since user data
>   is stored in an overlay file system that is lost upon reboot.

It's only true if your image is including "%installation-services" that
provides "cow-store-service". That's why in the mpd.scm from the article
the system is not inherited from beaglebone-black-installation-os. By
starting from mpd.scm you should be able to write a system config that
can boot and be used directly without any further installation step.

> - Suggestion in that context: Rename "guix system disk-image" to "guix system
>   installation-image".

Unless I'm wrong above, "guix system disk-image" is used to provide both
"ready-to-use" images and "installation-images" (and possibly other kind
of images too), so I don't think that would be a good idea.

> Thank you again for the post, and I am looking forward to more instructions
> for the other boards!
>

Thanks, I hope you will be able to produce a working GuixSD image for
your target. Don't hesitate to ask other questions!

Mathieu

Re: Porting GuixSD to ARM article.

[Mathieu Othacehe]

Hi Danny,

> 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>.

Oh too bad :(

> 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.

The problem with the approach of no writing u-boot is when you're
preparing a blank SD card and expect to boot from it.

However, I agree we could try to generalize the agetty configuration
part by fishing the right console to user.

An other problem would be in the initrd were some target specific module
can be required to mount the rootfs ("omap_hsmmc" on BBB for example).

WDYT ?

Thanks,

Mathieu

Re: Porting GuixSD to ARM article.

[Danny Milosavljevic]

Hi Mathieu,

On Tue, 23 Jan 2018 10:29:52 +0100
Mathieu Othacehe <m.othacehe@gmail.com> wrote:

> The problem with the approach of no writing u-boot is when you're
> preparing a blank SD card and expect to boot from it.

Right, that would be a problem sometimes.  Most ARM boards I have
have additional flash or eMMC which would still contain u-boot 
in that case - but there are boards where this isn't the case.  

Also, if the board prefers to boot from the SD card even if
there's no u-boot on it that would be bad, too.

We could ship the generic ARM image, let the user use
qemu-system-arm to boot it and set up the correct u-boot in
there, and only then write it to SD card.

There could even be a small part in the wip-installer-2
that asks you which u-boot you want and set that up.

I'm just trying to prevent Hydra from building ~1000 huge disk images
with minimal differences in the future... :)

Maybe all this stuff is premature optimization and we could just
let Hydra build them after all.

> An other problem would be in the initrd were some target specific module
> can be required to mount the rootfs ("omap_hsmmc" on BBB for example).

Yeah, I saw that now.  I wonder how to generalize that.  Maybe try to
include a union of all possible boot-required modules?

Re: Porting GuixSD to ARM article.

[Mathieu Othacehe]

> We could ship the generic ARM image, let the user use
> qemu-system-arm to boot it and set up the correct u-boot in
> there, and only then write it to SD card.
>
> There could even be a small part in the wip-installer-2
> that asks you which u-boot you want and set that up.
>
> I'm just trying to prevent Hydra from building ~1000 huge disk images
> with minimal differences in the future... :)

I agree a single ARMv7 would be better too :) On that point, NixOS seem
to provide a generic image an gives the instructions to write the
bootloader afterwards for every target:

https://nixos.wiki/wiki/NixOS_on_ARM

and here,

https://nixos.wiki/wiki/NixOS_on_ARM/BeagleBone_Black

I'm not found of this approach as it requires more manual steps but we
could maybe try the same thing.

What do other people think ?

> Yeah, I saw that now.  I wonder how to generalize that.  Maybe try to
> include a union of all possible boot-required modules?

That would be tricky to create and maintain.

Arch Linux does the same thing as NixOS and requires some specific
manipulations for every supported platform:

https://archlinuxarm.org/platforms

Maybe we should look for a distribution that has a generic image with
automatic initrd module list detection ?

Thanks,

Mathieu

Re: Porting GuixSD to ARM article.

[Ricardo Wurmus]

Mathieu Othacehe <m.othacehe@gmail.com> writes:

>> We could ship the generic ARM image, let the user use
>> qemu-system-arm to boot it and set up the correct u-boot in
>> there, and only then write it to SD card.
>>
>> There could even be a small part in the wip-installer-2
>> that asks you which u-boot you want and set that up.
>>
>> I'm just trying to prevent Hydra from building ~1000 huge disk images
>> with minimal differences in the future... :)
>
> I agree a single ARMv7 would be better too :) On that point, NixOS seem
> to provide a generic image an gives the instructions to write the
> bootloader afterwards for every target:
>
> https://nixos.wiki/wiki/NixOS_on_ARM
>
> and here,
>
> https://nixos.wiki/wiki/NixOS_on_ARM/BeagleBone_Black
>
> I'm not found of this approach as it requires more manual steps but we
> could maybe try the same thing.
>
> What do other people think ?

Can we automate these steps so that we have only a single image but
customized loader scripts per target?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Porting GuixSD to ARM article.

[Danny Milosavljevic]

Hi Ricardo,

On Tue, 23 Jan 2018 12:51:28 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:

> Can we automate these steps so that we have only a single image but
> customized loader scripts per target?

Difficult to say.  What would run the loader script?

Re: Porting GuixSD to ARM article.

[Andreas Enge]

Hello,

On Tue, Jan 23, 2018 at 10:23:50AM +0100, Mathieu Othacehe wrote:
> >   Notice that the last section of the blog post does not solve the problem:
> >   As I realised by trial and error when trying to use a disk-image for a
> >   virtual machine, it really is only an installation-image, since user data
> >   is stored in an overlay file system that is lost upon reboot.
> It's only true if your image is including "%installation-services" that
> provides "cow-store-service". That's why in the mpd.scm from the article
> the system is not inherited from beaglebone-black-installation-os. By
> starting from mpd.scm you should be able to write a system config that
> can boot and be used directly without any further installation step.

I see, that is a very interesting observation! Is it documented anywhere?
A further naive question: How does it differ from a vm-image then?

> Thanks, I hope you will be able to produce a working GuixSD image for
> your target. Don't hesitate to ask other questions!

I should give it a try, once I have a bit of time, which probably means
not before the weekend.

Thanks!

Andreas

Re: Porting GuixSD to ARM article.

[Mathieu Othacehe]

Hello,

> I see, that is a very interesting observation! Is it documented anywhere?
> A further naive question: How does it differ from a vm-image then?

Well "vm-image" is pretty close to "disk-image". The difference is that
"vm-image" output is meant to be run with qemu. However, there's no qemu
machine emulating the BBB. So, producing a "vm-image" for BBB is not
viable.

If one day BBB is (unlikely) supported by qemu, then "vm-image" will
allow you to test system configurations in a VM without the need of a
BBB hardware.

Mathieu

Re: Porting GuixSD to ARM article.

[Andreas Enge]

On Wed, Jan 24, 2018 at 09:17:48AM +0100, Mathieu Othacehe wrote:
> Well "vm-image" is pretty close to "disk-image". The difference is that
> "vm-image" output is meant to be run with qemu.

Ah, indeed, the output format is different. The other day I converted
a vm-image to "raw" format, which I suppose is then essentially the same
as a disk-image. I just did not know how to create a disk-image without
the cow-store.

Andreas