GNU bug report logs - #45519
MLO failed to load u-boot.img on beaglebone black(AM335x)

Previous Next

To reply to this bug, email your comments to 45519 AT debbugs.gnu.org.

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: MLO failed to load u-boot.img  on beaglebone black(AM335x)
Date: Tue, 29 Dec 2020 04:47:25 +0100

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

Hi,

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

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

And at boot, it seems that MLO can't load u-boot.img:
> U-Boot SPL 2020.10 (Jan 01 1970 - 00:00:01 +0000)
> Trying to boot from MMC1
>
> U-Boot SPL 2020.10 (Jan 01 1970 - 00:00:01 +0000)
> Trying to boot from MMC1
> 
> U-Boot SPL 2020.10 (Jan 01 1970 - 00:00:01 +0000)
> Trying to boot from MMC1
I don't know why there is a loop here. I didn't check if the watchdog
was disabled in MLO or not.

In gnu/bootloader/u-boot.scm in guix source code, we have:
> (define install-beaglebone-black-u-boot
>   ;; http://wiki.beyondlogic.org/index.php?title=BeagleBoneBlack_Upgrading_uBoot
>   ;; This first stage bootloader called MLO (U-Boot SPL) is expected at
>   ;; 0x20000 by BBB ROM code. The second stage bootloader will be loaded by
>   ;; the MLO and is expected at 0x60000.  Write both first stage ("MLO") and
>   ;; second stage ("u-boot.img") images, read in BOOTLOADER directory, to the
>   ;; specified DEVICE.
>   #~(lambda (bootloader root-index image)
>       (let ((mlo (string-append bootloader "/libexec/MLO"))
>             (u-boot (string-append bootloader "/libexec/u-boot.img")))
>         (write-file-on-device mlo (* 256 512)
>                               image (* 256 512))
>         (write-file-on-device u-boot (* 1024 512)
>                               image (* 768 512)))))

0x60000 is at 384k. It's defined by
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR which defaults to 0x300.

Here u-boot.img[1] is 600K, so if we add 600k and 384k we're still
within the 1M alignment space before the first partition:
> Device     Boot Start     End Sectors  Size Id Type
> guix.img1        2048   83967   81920   40M ef EFI (FAT-12/16/32)
> guix.img2       83968 3287855 3203888  1.5G 83 Linux

So we can rule out space issues.

Another possibility is that it tries to boot on the filesystem instead
of block offset. I've already tried to upstream a patch for that in
u-boot (that I attached here) but it was refused because it had some
side effects:

On Mon, 20 Jan 2020 13:17:01 +0530
Lokesh Vutla wrote:
> > With this change, and CONFIG_SPL_RAW_IMAGE_SUPPORT disabled,
> > raw MMC boot will be tried first, and if it fails, it FS will
> > be tried.  
> This means that if FS boot is required then SPL_RAW_IMAGE_SUPPORT
> should be disabled. So with this patch applied, the default
> omap3_defconfig will fail to boot with FS mode. It is difficult to
> support this unless ROM passes some information on the bootmode.

We are using this patch in Parabola. I'll try to test it too in Guix
though I can often take quite some time to manage to test things with
Guix when patching Guix itself.

References:
-----------
[1]/gnu/store/83rpk8q9bww0phl6z6zgpf06qhqs8cw6-u-boot-am335x-boneblack-2020.10/libexec/u-boot.img

Denis.

[0001-omap34xx-SPL-enable-MMC-raw-boot-with-u-boot.img.patch (text/x-patch, attachment)]

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

Message #8 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: Re: MLO failed to load u-boot.img  on beaglebone black(AM335x)
Date: Tue, 29 Dec 2020 05:33:55 +0100

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

On Tue, 29 Dec 2020 04:47:25 +0100
Denis 'GNUtoo' Carikli <GNUtoo <at> cyberdimension.org> wrote:
> > "/libexec/MLO")) (u-boot (string-append bootloader
> > "/libexec/u-boot.img"))) (write-file-on-device mlo (* 256 512)
> >                               image (* 256 512))
> >         (write-file-on-device u-boot (* 1024 512)
> >                               image (* 768 512)))))
Ah my bad, theses are in bytes (write-file-on-device uses seek which
looks like lseek). 

So if u-boot.img is 600k, that's over the 512k.

MLO[1] is about 108k (108740 bytes), so that's under 128KiB.

So we could move u-boot.img at 256KiB instead of 384KiB.

This way we'll still have some margin for MLO but and increase the
space for u-boot.img to 768k.

References:
-----------
[1]/gnu/store/83rpk8q9bww0phl6z6zgpf06qhqs8cw6-u-boot-am335x-boneblack-2020.10/libexec/MLO

Denis.

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

Message #11 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: Re: MLO failed to load u-boot.img  on beaglebone black(AM335x)
Date: Tue, 29 Dec 2020 06:05:34 +0100

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

On Tue, 29 Dec 2020 05:33:55 +0100
Denis 'GNUtoo' Carikli <GNUtoo <at> cyberdimension.org> wrote:

In addition I forgot that the patch I talked about was for omap3 and
not for AM335x.

Denis.

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