Hi,

I have an ODROID XU4 (a SBC based on Exynos5422). Since I'm one of those
PC people that would like everything to work like my PC does, I use GRUB
on it (plus, it gives me a nice boot menu when I can choose older kernels
or rescue mode, which is great when you're trying new and different things).

However, there's one thing GRUB doesn't know how to, and that is how to
find the right device tree file and put it in /boot. flash-kernel knows
(by virtue of having its database), but if I install flash-kernel, the first
thing it does is to make a boot.scr, which has higher priority than my GRUB
install (which is in /boot/EFI, lowest in the list of places U-Boot is looking
during boot), essentially overwriting it.

It would be really nice with some way of integrating this. As some sort
of minimal interaction, having some way of installing flash-kernel without
actually flashing (just having the kernel hooks copy the DTB into /boot)
would probably be the easiest; perhaps split into a separate package?

The more advanced integration would probably be if flash-kernel somehow
could flash GRUB (ie., running grub-install and then having its own
boot.scr boot GRUB instead of the kernels), but this sounds like it would
involve policy issues.

Control: tags 873390 pending

Applied to git:

https://anonscm.debian.org/git/d-i/flash-kernel.git/commit/?id=6db017ad4dbbc35e7eb30f48ae053c8cee0a4011

Should be in the next upload.

This might also be used to resolve at least part of the issue with
loading GRUB mentioned in #824954.


live well,
  vagrant

Let's assume U-Boot uses distroboot as described in doc/README.distro.

Environment variable boot_scripts decides which boot scripts are loaded.

The default value is

boot_scripts=boot.scr.uimg boot.scr

So if you create a boot script named boot.scr.uimg, it will override the
boot.scr created by flash-kernel.

flash-kernel creates a link /boot/dtb to the actual dtb.

So we do not need any variable part for calling grub.

Create a text file boot.txt like

# Booting Odroid C2 with grub
load mmc 0:2 0x1000000 dtb
load mmc 0:1 0x13000000 efi/debian/grubaa64.efi
bootefi 0x13000000 0x1000000

or

# Booting Odroid XU3/4 with grub
load mmc 0:2 0x43000000 dtb
load mmc 0:1 0x42000000 efi/debian/grubarm.efi
bootefi 0x42000000 0x43000000

Here I assumed that /boot/efi is partition 1 and /boot is partition 2.

Please, carefully verify the script for XU3/4. I have only tested on
Odroid C2.

Execute
mkimage -T script -d boot.txt uboot.scr.uimg

Copy file uboot.scr.uimg to the boot partition.

Now U-Boot will boot using uboot.scr.uimg and ignore the boot.scr that
flash-kernel keeps updating.

Best regards

Heinrich Schuchardt

-------- Forwarded Message --------
URL:
  <http://savannah.gnu.org/bugs/?52939>

                 Summary: [PATCH] 10_linux: support loading device trees
                 Project: GNU GRUB
            Submitted by: xypron
            Submitted on: Sat 20 Jan 2018 11:58:56 AM CET
                Category: Booting
                Severity: Major
                Priority: 5 - Normal
              Item Group: Feature Request
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Heinrich Schuchardt
        Originator Email: xypron.glpk@gmx.de
             Open/Closed: Open
         Discussion Lock: Any
                 Release:                  Release: Git master
         Reproducibility: Every Time
         Planned Release: None


<http://savannah.gnu.org/bugs/download.php?file_id=42983>

Since a while we have exit /etc/flash-kernel/ubootenv.d for
flash-kernel. A script can be added here to launch GRUB.

Another possibility is to create /boot/boot.scr.uimg using mkimage from
a text file with a content like the following lines:

load mmc 0:2 $fdt_addr_r dtb
load mmc 0:1 $kernel_addr_r efi/debian/grubaa64.efi
bootefi $kernel_addr_r $fdt_addr_r

So I suggest to close this issue.

Best regards

Heinrich Schuchardt

Hello,

For FreedomBox, I experimented with building a single UEFI image for
multiple arm64 boards as described for SUSE[1]. I tested a single UEFI
arm64 image for Rock64, RockPro64 and Raspberry Pi 3B+.

As part this, u-boot will reside on an SPI flash with OS on an eMMC, an
SD card, a USB disk or an NVMe drive. Alternatively, u-boot will reside
on an SD card with OS on a different drive. We can build these tiny
u-boot based firmware images separately or in cases like Raspberry Pi,
provide a build script or provide external references on how to get the
images.

The main OS image will have grub-efi with EFI partition and will not
contain u-boot or u-boot boot script. When u-boot starts from SPI flash
(or SD card), due to distroboot, it will load the DTB file from /dtb of
EFI partition and execute Grub EFI. Grub is responsible for loading the
kernel and initrd while DTB is loaded and passed on to the kernel via
Grub by u-boot. I had to do two hacks to make this happen:

1) Copy /boot/efi/EFI/debian/grubaa64.efi to
/boot/efi/EFI/boot/bootaa64.efi.

2) Copy /usr/lib/linux-image-$(latest)/ to /boot/efi/dtb/. For this I
wrote a small kernel hook script.

flash-kernel could introduce a new 'mode' of operation, say 'efi-dtb',
to help with hack number two. It will have to copy the latest kernel
dtbs recursively to /boot/efi/dtb.

FreedomBox is currently building an image for each of the boards it
supports. Being able to build a single image for all boards of an
architecture is a great simplification. Further more, image will contain
completely free software even for boards like Raspberry Pi (because
non-free firmware need not be shipped by the project).

Links:

1) https://www.suse.com/media/article/UEFI%20on%20Top%20of%20U-Boot.pdf

Thanks,

There may be several distinct bugs involved with #824954.  For one, I
suspect `grub-install`'s behavior needs to change if EFI variables aren't
supported.  I use this as a flag which could distinguish installation on
top of a full EFI implementation (perhaps Tianocore-derived), versus
U-Boot's rather primative EFI implementation.

Notably right now `grub-install` tries to install to
/boot/efi/EFI/debian by default.  This is appropriate for a full EFI
implementation where boot entries can be added by adding variables.  Yet
with U-Boot's limited implementation, the files must go in EFI/BOOT
(--bootloader-id=BOOT).

Right now I'm simply trying to figure out what others have done to reuse
it for my own purposes.

For a Raspberry PI, I've got the initial workings of a script to
accomplish this goal.

First, install u-boot-rpi, raspi-firmware, and grub-efi-arm64.

Next, create a filesystem on a device the Raspberry PI will boot from.
For anything pre-RP4, this will have to VFAT and show up in a MBR.  A
system I've done has a GPT with entry #3, which matches with entry #1 in
MBR.  The Raspberry PI will find this and boot from it, Linux will see it
as /dev/sda3.  Mount this filesystem on /boot/efi.


Do the following:

cp /usr/lib/raspi-firmware/* /boot/efi
# cp /usr/share/doc/raspi-firmware/copyright /boot/efi/LICENSE.broadcom

cp /usr/lib/u-boot/rpi_arm64/u-boot.bin /boot/efi/u-boot64.bin

cp /usr/lib/u-boot/rpi_3/u-boot.bin /boot/efi/u-boot3.bin
cp /usr/lib/u-boot/rpi_4/u-boot.bin /boot/efi/u-boot4.bin

cp /boot/dtbs/`uname -r`/broadcom/bcm2*-rpi*.dtb /boot/efi

grub-install --bootloader-id=BOOT
cp /boot/efi/EFI/BOOT/grubaa64.efi /boot/efi/EFI/BOOT/bootaa64.efi

echo bootaa64 > /boot/efi/startup.nsh


Now, I'm using SuSE as a starting point.  They copy a series of
device-tree overlays into /boot/efi/overlays.  These may come from the
Raspberry PI Foundation for optional hardware/configuration the RPF
provides.

Next would be to to create /boot/efi/config.txt.  I'm unsure of which
directives would be appropriate for Debian.  Debian would certainly need
to configure distinct "kernel=" lines depending upon which variant was
being booted.

This is rather badly damaged by bug #939633.  Until the device-trees are
fixed, this is completely broken.

Not ready for most people, but almost there...

The patch to have GRUB load a device-tree is interesting.  This is
certainly worthy of discussion.

Three issues come up when looking though:

First, your patch modifies /etc/grub.d/10_linux, but misses
/etc/grub.d/10_linux_xen.  /etc/grub.d/10_linux_xen needs a fairly
similar treatment.

Second, rather than having this get buried inside Debian bug #824954, you
should instead file a new bug against grub-common.

Third, there may be a need for extra guarding to ensure these sections
*only* get invoked on ARM devices (I'm fairly sure the *exact* *same*
file is shipped for all architectures).

Am 27. November 2020 04:18:06 MEZ schrieb Elliott Mitchell <ehem+debian@m5p.com>:

RISC-V uses device-trees too.
Some ARM devices use ACPI instead of device-trees.

The main issue is that fix-ups are not applied by U-Boot when GRUB loads the device-tree. A UEFI protocol for device tree fix ups would be needed. This issue has been discussed in this years Device Tree Evolution project (https://www.linaro.org/engineering/core/devicetree-evolution/).

Best regards

Heinrich