Bug#824954: flash-kernel: please provide a way to integrate with GRUB

[Steinar H. Gunderson]

Package: flash-kernel
Version: 3.66
Severity: wishlist

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.

-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 4.6.0 (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

[Heinrich Schuchardt]

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

[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: xypro...@gmx.de
Open/Closed: Open
Discussion Lock: Any
Release: Release: Git master
Reproducibility: Every Time
Planned Release: None

_______________________________________________________

Details:

Currently grub only loads the Linux kernel and the initial file system
before booting.

On the arm and arm64 architectures the device tree is also needed for
booting. The device tree is Linux kernel version dependent. So we can
not rely on the initial bootloader to provide the correct device tree
when calling grub.

For example I am using U-Boot to load iPXE. In iPXE I choose an iSCSI
target. iPXE connects to the target and starts grubaa64.efi. The device
tree that has to be used depends on the Linux kernel installed on the
chosen iSCSI target.

Luckily the device tree to be loaded can be specified in grub with the
devicetree command.

The patch changes the 10_linux script to look in sequence for files
* ${dirname}/dtb-${version} and * ${dirname}/dtb.

If one of the files is present an entry

devicetreee ${rel_dirname}/${dtb}

is added to the Linux boot entry.

== Distro suppport ==

Debian maintains a symbolic link /boot/dtb to the most current device
tree and another symbolic link /boot/dtb-${version} for the version
specific devicetree if package flash-kernel is installed.

On Suse a symbolic link /boot/dtb points to the current
/boot/dtb-${version}.

== Caveats ==

The EFI bootloader will still have to supply a dummy device tree which
will be replaced by the devicetree command.

As of U-Boot version v2018.01 U-Boot this dummy device tree has to be
passed explicitely to the bootefi command.



_______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Sat 20 Jan 2018 11:58:56 AM CET Name:
0001-10_linux-support-loading-device-trees.patch Size: 3KiB By: xypron

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

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?52939>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Heinrich Schuchardt]

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

[Elliott Mitchell]

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.


--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | ehem+...@m5p.com PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

[Elliott Mitchell]

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

[Elliott Mitchell]

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

[Heinrich Schuchardt]

Am 27. November 2020 04:18:06 MEZ schrieb Elliott Mitchell <ehem+...@m5p.com>:
>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).

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