MLO failed to load u-boot.img on beaglebone black(AM335x)

  • Open
  • quality assurance status badge
Details
One participant
  • Denis 'GNUtoo' Carikli
Owner
unassigned
Submitted by
Denis 'GNUtoo' Carikli
Severity
normal
D
D
Denis 'GNUtoo' Carikli wrote on 29 Dec 2020 04:47
(address . bug-guix@gnu.org)
20201229044725.3856df42@primarylaptop.localdomain
Hi,

I've generated an image for the beaglebone black with this
(beaglebone-black.scm) file:
Toggle quote (31 lines)
> ;; 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:
Toggle quote (3 lines)
> 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:
Toggle quote (8 lines)
> 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:
Toggle quote (15 lines)
> (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:
Toggle quote (4 lines)
> 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:
Toggle quote (8 lines)
> > 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.
From a49275a3cc03970939585610ebcf3b3d7e547037 Mon Sep 17 00:00:00 2001
From: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Date: Sat, 9 Nov 2019 18:53:40 +0100
Subject: [PATCH] omap34xx: SPL: enable MMC raw boot with u-boot.img

The following commit enabled raw SPL booting:
22d90d560a omap3: Use raw SPL by default for mmc1
but it was reverted by the following commit:
821c89d38c Revert "omap3: Use raw SPL by default for mmc1"
because SPL is unable to distinguish between RAW images and
garbage.

However if CONFIG_SPL_RAW_IMAGE_SUPPORT is disabled, SPL does
identify if there is a valid image with spl_parse_image_header.

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.

The two scenarios have been tested on a BeagleBoard XM Revision C1.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
---
arch/arm/mach-omap2/boot-common.c | 2 ++
1 file changed, 2 insertions(+)

Toggle diff (17 lines)
diff --git a/arch/arm/mach-omap2/boot-common.c b/arch/arm/mach-omap2/boot-common.c
index 734fa9d9e6..a48244e1c5 100644
--- a/arch/arm/mach-omap2/boot-common.c
+++ b/arch/arm/mach-omap2/boot-common.c
@@ -132,8 +132,10 @@ void save_omap_boot_params(void)
(boot_device <= MMC_BOOT_DEVICES_END)) {
switch (boot_device) {
case BOOT_DEVICE_MMC1:
+#ifdef CONFIG_SPL_RAW_IMAGE_SUPPORT
boot_mode = MMCSD_MODE_FS;
break;
+#endif
case BOOT_DEVICE_MMC2:
boot_mode = MMCSD_MODE_RAW;
break;
--
2.24.0
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAl/qps4ACgkQX138wUF3
4mMamQ/+NTnRZeCR2Rb7Ja1pYcLoBHEZ9KEEEFKw79lgscJSdHO7A36+e4b/QJCK
j6ftQRrWdKX0CdNUzlZYQsrCh3lW20JtOnP76Kvz247ok3fHEQuRTpVbmIuzh9Sv
3ogAXD2Id6LVvIozZJdZ759X+4UTIDNF5fyZmwYt5jtoprAw6Tu9oVjVWNYRCPhs
qWoq4D/N1Sj8sCqxkeHYG2RLa9aaY67IXeHBUwj45lJLjRcxpWBZZodRk9a9TIJn
cAdxyT52JuNEpeupWVlT8kZ4/2OMq8fZ/BQk5WcSkDjxLW569FOlkfkXBS5nzdKp
w1YTiu3vPHHfFm5GOvEIU1UXcsFbmeRCpJSiiN2V5aVl8ZoShIyk1fzTbC/91n0R
HOra2QKQoSqwnJK4o32N0udRPDhjdI1xcl98cmuSbgqY+83wJu4hzgQxD5r8eQJB
lt7SHGIqHi5/8l6bhTD6JKvGlxXbCyEXl920oERvth/E3J0N/RrBOxbT/Ao/aqGJ
dFQ6t4P3tlFWxiHPecFvTyepOyY6Mu0cR7btaWBx2mocFun2VfdAMn5/HTTjzo4i
hciynh13MzI5rFJ9wEgnA2lm9JvBNmVthhQTjDBz8QovlPlzotUgShPbvXWVl1Ef
UXJUt/rleOCCXvoOlyET3aMrrVM74dwcTKAxVfH/TE/mCB0JPfw=
=ZGXI
-----END PGP SIGNATURE-----


D
D
Denis 'GNUtoo' Carikli wrote on 29 Dec 2020 05:33
(address . bug-guix@gnu.org)
20201229053355.30ce920b@primarylaptop.localdomain
On Tue, 29 Dec 2020 04:47:25 +0100
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:
Toggle quote (5 lines)
> > "/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.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAl/qsbMACgkQX138wUF3
4mN9rw/+LfXb/idYeqHkKAN0ntPUmJhtAkwHD6GkM9+iTkUguDr5RWDxeLcdmZpW
6rLrIVO52Tgd883ZzCjeN39WIkmglsKT+KKWfBGdrAeKCUTI/7KwJ//Op8KOXp/8
pCyCzUNq2kA4kpti+qi9C+3LVp6OeLb5DI0ZOgx5MIP5V88/0tk34S/Tkt2Nstz7
Qt4eACqpjUUoqFj+jQ+cqKKwL5hKDcE/BRkxrCNF6J6CzZraxNMuf49cANKdipJx
kOmqj0rvFeYRNDLJTE4cb/TzFTt5M4eaU9Oss14xg/yXDxSbDgNrW7ZENT6cIa3+
2iAAWZVEDsHx2pcC33z72sGyTXQEOfJb4PHoqLeG9NdhzieqXDVkEI+GGQG6v4vA
MY+r44tGeXkcDh7LKk472PIwEfuuuIvEuSwYs4lR7b6flfnTGIIu7wHeyB1iBFfS
oUQEKSOf1gkHu9QacnD/16HBUJH0O+CFlvGBTPizMhrhVIKO+6pFIWJhoVbfkA5l
QxGQsmBRcvQWn2DN6rEtVjGfbd4xpBm/UgXy6vtBu25VUXwHcID6xbk7ehseDKWG
LfaYk1wmpEG9s/RZDq5vnWtCpX6aR42vD1hi7zhdtapgNSyzmcQRY2q4ZtI3rJ3O
ZcrRkrKBjhNt583TkRKLMUav7hN+yDz5nd+j7jlZVmx0zOY7fRs=
=73IM
-----END PGP SIGNATURE-----


D
D
Denis 'GNUtoo' Carikli wrote on 29 Dec 2020 06:05
(address . bug-guix@gnu.org)
20201229060534.33826161@primarylaptop.localdomain
On Tue, 29 Dec 2020 05:33:55 +0100
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:

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

Denis.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAl/quR4ACgkQX138wUF3
4mN3IQ/8DVcZnMoImQ5vZfkOGOLbmq+hXMV2BEav91IoNX38ZnDWpHAikzsF6Da3
oCmxZfChf8sHBfgltXfWq98VP0Vl6V7lV9+fz/lo/FC1aQHPUT4QYUL4UycZFmEG
P0JM1gMSOTIRyRGFpujr363b0+ZT86iZDVgSTgkph7SrYaO8jf3/A1CbhilLUuIP
02S6HvqlH12BB4Sqy2JPbdKo0rbkzWp2Xba61CPSZLOTuwpwBPV/m3ER65BRt+1d
KhT8BkRj+An+RYHO86YDAvpPv9ZOABM6FWWjtiFOTTKijfcXbyuGP0Vgd8LQ1Vz/
UnR9WGBveSRXTxvj2AUXXHPekLfsBQe4nAEixKWMR/9CN9T++/nwGvbEPYdcCq/O
otHEBAhcJNEvsq4lAKUJAHX5m0woD7aHq97752zXchJA1GeYp6eCTyTxf8WVz4cz
Va/KYADFgnifoX6o/xtp5SRJm7dWC7rhutsF6QR/kU/N5IVcfvCr8UnO+CS7dTg+
HCpcMnp0igtaLSjMR2Bw54PjIMRDUDwL7axWYTBO1UnryG2Fp7KWpdWIbzOQXdGc
s40l2w7HAdoBPYYSFwaAllC9tRyAvbIAbdsMY+gCLg7Zm2VZLRaAd5w0hADiEsSC
ZgEpU1osghGauglu8FhaQxXdYqtqvKlOrjZ8snJNvtuQMabqXvw=
=sU4j
-----END PGP SIGNATURE-----


?