Discussion:
Porting GuixSD to ARM article.
(too old to reply)
Mathieu Othacehe
2017-12-22 13:12:02 UTC
Permalink
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
Vincent Legoll
2017-12-22 15:38:44 UTC
Permalink
Hello,
Post by Mathieu Othacehe
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
Mathieu Othacehe
2017-12-22 22:43:51 UTC
Permalink
Hi Vicent,
Post by Vincent Legoll
The definition on an installation image for the BeagleBone Black.
s/on an/of an/
Thanks for pointing it out.
Post by Vincent Legoll
In "Preparing a dedicated system configuration", I'm not sure,
(tty "ttyO0")
Isn't that a typo also ?
Nope it is not. It's the name of serial port on some Omap targets.

Mathieu
Pjotr Prins
2017-12-22 15:58:16 UTC
Permalink
Post by 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,
Very cool!

--
Mathieu Othacehe
2017-12-22 22:44:14 UTC
Permalink
Post by Pjotr Prins
Very cool!
Thanks Pjotr!

Mathieu
Andreas Enge
2018-01-22 21:15:00 UTC
Permalink
Hello Mathieu,
Post by Mathieu Othacehe
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
Danny Milosavljevic
2018-01-22 21:51:27 UTC
Permalink
Hi,
Post by Andreas Enge
- 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.
Post by Andreas Enge
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.
Mathieu Othacehe
2018-01-23 09:29:52 UTC
Permalink
Hi Danny,
Post by Danny Milosavljevic
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 :(
Post by Danny Milosavljevic
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
Danny Milosavljevic
2018-01-23 10:04:10 UTC
Permalink
Hi Mathieu,

On Tue, 23 Jan 2018 10:29:52 +0100
Post by Mathieu Othacehe
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.
Post by Mathieu Othacehe
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?
Mathieu Othacehe
2018-01-23 10:42:55 UTC
Permalink
Post by Danny Milosavljevic
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 ?
Post by Danny Milosavljevic
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
Ricardo Wurmus
2018-01-23 11:51:28 UTC
Permalink
Post by Mathieu Othacehe
Post by Danny Milosavljevic
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
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
Danny Milosavljevic
2018-01-23 18:35:25 UTC
Permalink
Hi Ricardo,

On Tue, 23 Jan 2018 12:51:28 +0100
Post by Ricardo Wurmus
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?
Mathieu Othacehe
2018-01-23 09:23:50 UTC
Permalink
Hi Andreas,
Post by Andreas Enge
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 :)
Post by Andreas Enge
- 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!
Post by Andreas Enge
- 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.
Post by Andreas Enge
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.
Post by Andreas Enge
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.
Post by Andreas Enge
- 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.
Post by Andreas Enge
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
Andreas Enge
2018-01-23 20:46:46 UTC
Permalink
Hello,
Post by Mathieu Othacehe
Post by Andreas Enge
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?
Post by Mathieu Othacehe
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
Mathieu Othacehe
2018-01-24 08:17:48 UTC
Permalink
Hello,
Post by Andreas Enge
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
Andreas Enge
2018-01-24 10:12:23 UTC
Permalink
Post by Mathieu Othacehe
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

Loading...