GNU bug report logs - #45517
Failed boot on arm32 with u-boot due to missing requirements with the distro boot protocol

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45517 in the body.
You can then email your comments to 45517 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Denis 'GNUtoo' Carikli <GNUtoo <at> cyberdimension.org>
To: bug-guix <at> gnu.org
Subject: Failed boot on arm32 with u-boot due to missing requirements with
 the distro boot protocol
Date: Tue, 29 Dec 2020 03:34:39 +0100

[Message part 1 (text/plain, inline)]

Hi,

I've generated an image for the Lime2 with this (lime2.scm) file:
> ;; Based on Guix's beaglebone-black.tmpl
> (use-modules (gnu) (gnu bootloader u-boot))
> (use-package-modules bootloaders)
> (operating-system
>   (host-name "lime2")
>   (timezone "Europe/Paris")
>   (locale "en_US.utf8")
>   ;; We use a microSD
>   (bootloader (bootloader-configuration
>                (bootloader u-boot-a20-olinuxino-lime2-bootloader)
>                (target "/dev/mmcblk0")))
>   (kernel-arguments '("console=ttyS0,115200" "ignore_loglevel"))
>   ;; This module is required to mount the SD card.
>   (initrd-modules (cons "sunxi-mmc" %base-initrd-modules))
>   (file-systems (cons (file-system
>                         (device (file-system-label "my-root"))
>                         (mount-point "/")
>                         (needed-for-boot? #t)
>                         (type "ext4"))
>                       %base-file-systems))
>   (packages %base-packages)
>   (services (append (list
>                      (agetty-service
>                       (agetty-configuration
>                        (extra-options '("-L"))
>                        (baud-rate "115200")
>                        (term "xterm-256color")
>                        (tty "ttyS0"))))
>                     %base-services)))

I then built it with:
> cp `guix system disk-image --target=arm-linux-gnueabihf lime2.scm` \
>     guix.img

However when booting the image, u-boot doesn't find
/boot/extlinux/extlinux.conf.

However running the following command in u-boot makes the board boot:
> sysboot mmc 0:2 any $scriptaddr /boot/extlinux/extlinux.conf

When we look at the resulting image with fdisk -l we have:
> Device     Boot Start     End Sectors  Size Id Type
> guix.img1        2048   83967   81920   40M ef EFI (FAT-12/16/32)
> guix.img2       83968 3301783 3217816  1.5G 83 Linux

The second partition (which has /boot/extlinux/extlinux.conf) doesn't
have the boot flag.

Adding the boot flag with the following command results in a booting
image:
> sfdisk guix.img -A 2

This is because the distro boot protocol (documented in
doc/README.distro in u-boot source code[1]) expects the partition that
holds the extlinux.conf config file to be "explicitly marked bootable".
else "U-Boot falls back to searching the first valid partition of a
disk for boot configuration files."

So we either need to remove the first partition or to mark the second
partition as bootable or both.

I've tried looking in the partitioning code to understand how flags are
set but I'm a complete newbie in scheme so I failed. Being able to set
the bootable flag could probably help in some situations where a first
partition has to be used for some reasons.

In addition, the first partition it only contains the
/EFI/BOOT/BOOTIA32.EFI file which is of the following type:
> PE32 executable (EFI application) Intel 80386 (stripped to external
> PDB), for MS Windows
So it could also be removed and/or replaced with ARM code.

References:
-----------
[1]https://gitlab.denx.de/u-boot/u-boot/-/raw/master/doc/README.distro

Denis.

[Message part 2 (application/pgp-signature, inline)]

Message #8 received at 45517 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Denis 'GNUtoo' Carikli <GNUtoo <at> cyberdimension.org>
Cc: 45517 <at> debbugs.gnu.org
Subject: Re: bug#45517: Failed boot on arm32 with u-boot due to missing
 requirements with the distro boot protocol
Date: Wed, 30 Dec 2020 15:35:48 +0100

Hello Denis,

> I then built it with:
>> cp `guix system disk-image --target=arm-linux-gnueabihf lime2.scm` \
>>     guix.img
>
> However when booting the image, u-boot doesn't find
> /boot/extlinux/extlinux.conf.
>
> However running the following command in u-boot makes the board boot:
>> sysboot mmc 0:2 any $scriptaddr /boot/extlinux/extlinux.conf
>
> When we look at the resulting image with fdisk -l we have:
>> Device     Boot Start     End Sectors  Size Id Type
>> guix.img1        2048   83967   81920   40M ef EFI (FAT-12/16/32)
>> guix.img2       83968 3301783 3217816  1.5G 83 Linux

The default image type creates an EFI partition which is not desirable
here. You should try again running this instead:

--8<---------------cut here---------------start------------->8---
guix system disk-image -t arm32-raw lime2.scm
--8<---------------cut here---------------end--------------->8---

Thanks,

Mathieu

Message #11 received at 45517 <at> debbugs.gnu.org (full text, mbox):

From: Denis 'GNUtoo' Carikli <GNUtoo <at> cyberdimension.org>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: 45517 <at> debbugs.gnu.org
Subject: Re: bug#45517: Failed boot on arm32 with u-boot due to missing
 requirements with the distro boot protocol
Date: Sat, 2 Jan 2021 03:54:40 +0100

[Message part 1 (text/plain, inline)]

On Wed, 30 Dec 2020 15:35:48 +0100
Mathieu Othacehe <othacehe <at> gnu.org> wrote:
> The default image type creates an EFI partition which is not desirable
> here. You should try again running this instead:
> 
> --8<---------------cut here---------------start------------->8---
> guix system disk-image -t arm32-raw lime2.scm
> --8<---------------cut here---------------end--------------->8---
Thanks a lot, that works fine.

Sorry for the noise.

Denis.

[Message part 2 (application/pgp-signature, inline)]

Message #16 received at 45517-done <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Denis 'GNUtoo' Carikli <GNUtoo <at> cyberdimension.org>
Cc: 45517-done <at> debbugs.gnu.org
Subject: Re: bug#45517: Failed boot on arm32 with u-boot due to missing
 requirements with the distro boot protocol
Date: Sat, 02 Jan 2021 11:23:24 +0100

Hey Dennis,

> Thanks a lot, that works fine.

Glad it works! Maybe we should consider creating a
gnu/system/images/lime.scm file in the future.

Closing this one.

Thanks,

Mathieu

Message #19 received at 45517-done <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: 45517-done <at> debbugs.gnu.org,
 Denis 'GNUtoo' Carikli <GNUtoo <at> cyberdimension.org>
Subject: Re: bug#45517: Failed boot on arm32 with u-boot due to missing
 requirements with the distro boot protocol
Date: Sun, 3 Jan 2021 23:15:01 +0100

[Message part 1 (text/plain, inline)]

Hi Mathieu,

On Sat, 02 Jan 2021 11:23:24 +0100
Mathieu Othacehe <othacehe <at> gnu.org> wrote:

> > Thanks a lot, that works fine.  
> 
> Glad it works! Maybe we should consider creating a
> gnu/system/images/lime.scm file in the future.

Sure.

I think that Allwinner boards are all similar enough in booting that we could
just have a gnu/system/images/allwinner.scm to support them all--except for
the u-boot package reference they are all the same.

Later Allwinner boards added a reference to an alternative boot sector[1]
for the first part of u-boot into boot ROM *in addition* to the old one--so
even those would still work!

Long story short, all of the Allwinner boards can inherit from the same
allwinner image type--with only the u-boot package (not even the
bootloader-installer) swapped out.

We could have a gnu/system/images/olinuxino-lime2.scm which would inherit
from that common thing somehow (and which would thus have about two lines
of source code total).

But there's a reason I added OS-WITH-U-BOOT and that's because of things
like this.  It can adapt any existing operating-system image, swapping out
the bootloader by an u-boot with a random u-boot board config name and
compile it for a given architecture.

It would be nice to have it integrated into the Guix image generation
process somehow, if possible.  

By automatically calling OS-WITH-U-BOOT (as a fallback), we could avoid ending
up with 1273 similar files in gnu/system/images.  Guix would just call
os-with-u-boot dynamically to generate those image types at runtime
that don't have a special one in that directory.

WDYT?

[1] https://linux-sunxi.org/Bootable_SD_card#SD_Card_Layout

[Message part 2 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.