[U-Boot] Load Debian/Fedora via EFI
Hi,
I tried to boot latest debian and fedora rootfs via distro boot and getting errors. I have tried to run just one command and it is failing.
ZynqMP> bootefi bootmgr ${fdtcontroladdr} BootOrder not defined EFI boot manager: Cannot load any image
How to define BootOrder?
Thanks, Michal
On 11/29/19 11:16 AM, Michal Simek wrote:
Hi,
I tried to boot latest debian and fedora rootfs via distro boot and getting errors. I have tried to run just one command and it is failing.
ZynqMP> bootefi bootmgr ${fdtcontroladdr} BootOrder not defined EFI boot manager: Cannot load any image
How to define BootOrder?
Thanks, Michal
# Booting via boot manager
U-Boot currently has no runtime support for variables. But Linaro is working on it. So update-grub cannot set the variables for you.
You can use the efidebug command to prepare for booting via the boot manager:
=> efidebug boot add 0001 Debian mmc 0:1 \ efi/debian/grubarm.efi console=${console}
There seems to be a bug with communication lines in U-Boot. So you actually have to put this into a single line.
=> efidebug boot order 0001
Use saveenv if you want to save the settings.
If you do not want to use the internal device tree load the proper device tree, e.g.
=> load mmc 0:2 $fdt_addr_r dtb
Now you are ready to boot via the boot manager:
=> bootefi bootmgr $fdt_addr_r
# Booting via distro defaults
DISTRO_DEFAULTS tries to load the devicetree from ${fdtfile} and the UEFI binary from efi/boot/bootaa64.efi on ARM64. See ./include/config_distro_bootcmd.h.
OpenBSD and FreeBSD follow the distro boot convention, Debian GRUB does not.
# Booting via boot script.
On Debian I use package flash-kernel to keep /boot/dtb in sync with the kernel and have a u-boot.scr.uimg script with something like the following lines:
setenv bootargs console=${console} load mmc 2:1 ${kernel_addr_r} EFI/debian/grubarm.efi load mmc 2:2 ${fdt_addr_r} dtb bootefi ${kernel_addr_r} ${fdt_addr_r}
Alternatively you could use package flash-kernel and implement the /etc/flash-kernel/preboot.d/ hook to start GRUB, cf. /etc/flash-kernel/bootscript/bootscr.uboot-generic
I currently have no Fedora system in use.
Best regards
Heinrich
On 29. 11. 19 19:23, Heinrich Schuchardt wrote:
On 11/29/19 11:16 AM, Michal Simek wrote:
Hi,
I tried to boot latest debian and fedora rootfs via distro boot and getting errors. I have tried to run just one command and it is failing.
ZynqMP> bootefi bootmgr ${fdtcontroladdr} BootOrder not defined EFI boot manager: Cannot load any image
How to define BootOrder?
Thanks, Michal
# Booting via boot manager
U-Boot currently has no runtime support for variables. But Linaro is working on it. So update-grub cannot set the variables for you.
Who from Linaro is working on it? Akashi?
You can use the efidebug command to prepare for booting via the boot manager:
=> efidebug boot add 0001 Debian mmc 0:1 \ efi/debian/grubarm.efi console=${console}
There seems to be a bug with communication lines in U-Boot. So you actually have to put this into a single line.
=> efidebug boot order 0001
Use saveenv if you want to save the settings.
If you do not want to use the internal device tree load the proper device tree, e.g.
=> load mmc 0:2 $fdt_addr_r dtb
Now you are ready to boot via the boot manager:
=> bootefi bootmgr $fdt_addr_r
# Booting via distro defaults
DISTRO_DEFAULTS tries to load the devicetree from ${fdtfile} and the UEFI binary from efi/boot/bootaa64.efi on ARM64. See ./include/config_distro_bootcmd.h.
OpenBSD and FreeBSD follow the distro boot convention, Debian GRUB does not.
Fedora is the same case. I got it working based on your guidance but would be IMHO better to extend distroboot to cover one of the major distribution even through workaround till variable support is done.
# Booting via boot script.
On Debian I use package flash-kernel to keep /boot/dtb in sync with the kernel and have a u-boot.scr.uimg script with something like the following lines:
setenv bootargs console=${console} load mmc 2:1 ${kernel_addr_r} EFI/debian/grubarm.efi load mmc 2:2 ${fdt_addr_r} dtb bootefi ${kernel_addr_r} ${fdt_addr_r}
flash-kernel is interesting. It generates u-boot script but if extX partition has no bootable flag u-boot distroboot ignores it completely. What's your default partition setup?
Alternatively you could use package flash-kernel and implement the /etc/flash-kernel/preboot.d/ hook to start GRUB, cf. /etc/flash-kernel/bootscript/bootscr.uboot-generic
I currently have no Fedora system in use.
you can take a look. https://alt.fedoraproject.org/alt/
Thanks, Michal
On 12/2/19 3:21 PM, Michal Simek wrote:
On 29. 11. 19 19:23, Heinrich Schuchardt wrote:
On 11/29/19 11:16 AM, Michal Simek wrote:
Hi,
I tried to boot latest debian and fedora rootfs via distro boot and getting errors. I have tried to run just one command and it is failing.
ZynqMP> bootefi bootmgr ${fdtcontroladdr} BootOrder not defined EFI boot manager: Cannot load any image
How to define BootOrder?
Thanks, Michal
# Booting via boot manager
U-Boot currently has no runtime support for variables. But Linaro is working on it. So update-grub cannot set the variables for you.
Who from Linaro is working on it? Akashi?
I was in contact with Ilias Apalodimas but do not know who is doing the actual work.
See https://youtu.be/SEMJGOzjrHY @ 14:00
You can use the efidebug command to prepare for booting via the boot manager:
=> efidebug boot add 0001 Debian mmc 0:1 \ efi/debian/grubarm.efi console=${console}
There seems to be a bug with communication lines in U-Boot. So you actually have to put this into a single line.
=> efidebug boot order 0001
Use saveenv if you want to save the settings.
If you do not want to use the internal device tree load the proper device tree, e.g.
=> load mmc 0:2 $fdt_addr_r dtb
Now you are ready to boot via the boot manager:
=> bootefi bootmgr $fdt_addr_r
# Booting via distro defaults
DISTRO_DEFAULTS tries to load the devicetree from ${fdtfile} and the UEFI binary from efi/boot/bootaa64.efi on ARM64. See ./include/config_distro_bootcmd.h.
OpenBSD and FreeBSD follow the distro boot convention, Debian GRUB does not.
Fedora is the same case. I got it working based on your guidance but would be IMHO better to extend distroboot to cover one of the major distribution even through workaround till variable support is done.
I don't like the idea of distribution specific stuff getting into U-Boot.
We would end up with a plethora of possible UEFI binaries to search for: shim, GRUB, iPXE, any Linux kernel. All of these are binaries could be used for booting Fedora, Debian, or any other Linux distribution via bootefi. And which one should we take if there is more than one of these?
I especially dislike any claim that one distribution is "major" and another is not. Should we kick out CentOS and Fedora because they are less popular than Ubuntu and Android?
So let's leave it to the distribution to create boot.scr or provide a binary following the naming convention given in the UEFI specification (chapter 3.5.1.1 Removable Media Boot Behavior).
# Booting via boot script.
On Debian I use package flash-kernel to keep /boot/dtb in sync with the kernel and have a u-boot.scr.uimg script with something like the following lines:
setenv bootargs console=${console} load mmc 2:1 ${kernel_addr_r} EFI/debian/grubarm.efi load mmc 2:2 ${fdt_addr_r} dtb bootefi ${kernel_addr_r} ${fdt_addr_r}
flash-kernel is interesting. It generates u-boot script but if extX partition has no bootable flag u-boot distroboot ignores it completely. What's your default partition setup?
I have separate partitions:
/boot of type 83 (Linux, ext2) and marked as bootable and with boot.scr on it. /boot/efi of type ef (EFI, vfat) and not marked as bootable
The sequence on the block device does not matter.
When booting via iSCSI with iPXE I put boot.scr and snp.efi on an EFI partition marked as bootable.
Best regards
Heinrich
Alternatively you could use package flash-kernel and implement the /etc/flash-kernel/preboot.d/ hook to start GRUB, cf. /etc/flash-kernel/bootscript/bootscr.uboot-generic
I currently have no Fedora system in use.
you can take a look. https://alt.fedoraproject.org/alt/
Thanks, Michal
On Tue, Dec 03, 2019 at 08:51:09PM +0100, Heinrich Schuchardt wrote:
On 12/2/19 3:21 PM, Michal Simek wrote:
On 29. 11. 19 19:23, Heinrich Schuchardt wrote:
On 11/29/19 11:16 AM, Michal Simek wrote:
Hi,
I tried to boot latest debian and fedora rootfs via distro boot and getting errors. I have tried to run just one command and it is failing.
ZynqMP> bootefi bootmgr ${fdtcontroladdr} BootOrder not defined EFI boot manager: Cannot load any image
How to define BootOrder?
Thanks, Michal
# Booting via boot manager
U-Boot currently has no runtime support for variables. But Linaro is working on it. So update-grub cannot set the variables for you.
Who from Linaro is working on it? Akashi?
I was in contact with Ilias Apalodimas but do not know who is doing the actual work.
See https://youtu.be/SEMJGOzjrHY @ 14:00
This is still under discussion for us. We'll either support runtime variables as defined in the UEFI spec or present a cached copy on Linux. You can then build a capsule and update the variables on next boot. In any case capsule updates are not supported yet, so any path we choose requires some development. I'll try to keep both of you updated on the development process.
Cheers /Ilias
út 3. 12. 2019 v 20:56 odesílatel Heinrich Schuchardt xypron.glpk@gmx.de napsal:
On 12/2/19 3:21 PM, Michal Simek wrote:
On 29. 11. 19 19:23, Heinrich Schuchardt wrote:
On 11/29/19 11:16 AM, Michal Simek wrote:
Hi,
I tried to boot latest debian and fedora rootfs via distro boot and getting errors. I have tried to run just one command and it is failing.
ZynqMP> bootefi bootmgr ${fdtcontroladdr} BootOrder not defined EFI boot manager: Cannot load any image
How to define BootOrder?
Thanks, Michal
# Booting via boot manager
U-Boot currently has no runtime support for variables. But Linaro is working on it. So update-grub cannot set the variables for you.
Who from Linaro is working on it? Akashi?
I was in contact with Ilias Apalodimas but do not know who is doing the actual work.
See https://youtu.be/SEMJGOzjrHY @ 14:00
You can use the efidebug command to prepare for booting via the boot manager:
=> efidebug boot add 0001 Debian mmc 0:1 \ efi/debian/grubarm.efi console=${console}
There seems to be a bug with communication lines in U-Boot. So you actually have to put this into a single line.
=> efidebug boot order 0001
Use saveenv if you want to save the settings.
If you do not want to use the internal device tree load the proper device tree, e.g.
=> load mmc 0:2 $fdt_addr_r dtb
Now you are ready to boot via the boot manager:
=> bootefi bootmgr $fdt_addr_r
# Booting via distro defaults
DISTRO_DEFAULTS tries to load the devicetree from ${fdtfile} and the UEFI binary from efi/boot/bootaa64.efi on ARM64. See ./include/config_distro_bootcmd.h.
OpenBSD and FreeBSD follow the distro boot convention, Debian GRUB does not.
Fedora is the same case. I got it working based on your guidance but would be IMHO better to extend distroboot to cover one of the major distribution even through workaround till variable support is done.
I don't like the idea of distribution specific stuff getting into U-Boot.
We would end up with a plethora of possible UEFI binaries to search for: shim, GRUB, iPXE, any Linux kernel. All of these are binaries could be used for booting Fedora, Debian, or any other Linux distribution via bootefi. And which one should we take if there is more than one of these?
I especially dislike any claim that one distribution is "major" and another is not. Should we kick out CentOS and Fedora because they are less popular than Ubuntu and Android?
So let's leave it to the distribution to create boot.scr or provide a binary following the naming convention given in the UEFI specification (chapter 3.5.1.1 Removable Media Boot Behavior).
ok understand.
# Booting via boot script.
On Debian I use package flash-kernel to keep /boot/dtb in sync with the kernel and have a u-boot.scr.uimg script with something like the following lines:
setenv bootargs console=${console} load mmc 2:1 ${kernel_addr_r} EFI/debian/grubarm.efi load mmc 2:2 ${fdt_addr_r} dtb bootefi ${kernel_addr_r} ${fdt_addr_r}
flash-kernel is interesting. It generates u-boot script but if extX partition has no bootable flag u-boot distroboot ignores it completely. What's your default partition setup?
I have separate partitions:
/boot of type 83 (Linux, ext2) and marked as bootable and with boot.scr on it. /boot/efi of type ef (EFI, vfat) and not marked as bootable
The sequence on the block device does not matter.
When booting via iSCSI with iPXE I put boot.scr and snp.efi on an EFI partition marked as bootable.
That means that you had done that changes by hand.
Thanks, Michal
On 12/5/19 11:21 AM, Michal Simek wrote:
I have separate partitions:
/boot of type 83 (Linux, ext2) and marked as bootable and with boot.scr on it. /boot/efi of type ef (EFI, vfat) and not marked as bootable
The sequence on the block device does not matter.
When booting via iSCSI with iPXE I put boot.scr and snp.efi on an EFI partition marked as bootable.
That means that you had done that changes by hand.
Thanks, Michal
If you boot the kernel of the Debian installer via UEFI, it installs GRUB EFI but you may have to install flash-kernel manually.
If you you want to use iPXE on ARM, you are on your own. There isn't even a package with snp.efi provided by Debian. But at least the installer allows you to set up your partitions and do the installation on an iSCSI drive.
Best regards
Heinrich
On Tue, Dec 03, 2019 at 08:51:09PM +0100, Heinrich Schuchardt wrote:
On 12/2/19 3:21 PM, Michal Simek wrote:
On 29. 11. 19 19:23, Heinrich Schuchardt wrote:
On 11/29/19 11:16 AM, Michal Simek wrote:
Hi,
I tried to boot latest debian and fedora rootfs via distro boot and getting errors. I have tried to run just one command and it is failing.
ZynqMP> bootefi bootmgr ${fdtcontroladdr} BootOrder not defined EFI boot manager: Cannot load any image
How to define BootOrder?
Thanks, Michal
# Booting via boot manager
U-Boot currently has no runtime support for variables. But Linaro is working on it. So update-grub cannot set the variables for you.
Who from Linaro is working on it? Akashi?
I was in contact with Ilias Apalodimas but do not know who is doing the actual work.
See https://youtu.be/SEMJGOzjrHY @ 14:00
You can use the efidebug command to prepare for booting via the boot manager:
=> efidebug boot add 0001 Debian mmc 0:1 \ efi/debian/grubarm.efi console=${console}
There seems to be a bug with communication lines in U-Boot. So you actually have to put this into a single line.
=> efidebug boot order 0001
Use saveenv if you want to save the settings.
If you do not want to use the internal device tree load the proper device tree, e.g.
=> load mmc 0:2 $fdt_addr_r dtb
Now you are ready to boot via the boot manager:
=> bootefi bootmgr $fdt_addr_r
# Booting via distro defaults
DISTRO_DEFAULTS tries to load the devicetree from ${fdtfile} and the UEFI binary from efi/boot/bootaa64.efi on ARM64. See ./include/config_distro_bootcmd.h.
OpenBSD and FreeBSD follow the distro boot convention, Debian GRUB does not.
Fedora is the same case. I got it working based on your guidance but would be IMHO better to extend distroboot to cover one of the major distribution even through workaround till variable support is done.
I don't like the idea of distribution specific stuff getting into U-Boot.
We would end up with a plethora of possible UEFI binaries to search for: shim, GRUB, iPXE, any Linux kernel. All of these are binaries could be used for booting Fedora, Debian, or any other Linux distribution via bootefi. And which one should we take if there is more than one of these?
I especially dislike any claim that one distribution is "major" and another is not. Should we kick out CentOS and Fedora because they are less popular than Ubuntu and Android?
So let's leave it to the distribution to create boot.scr or provide a binary following the naming convention given in the UEFI specification (chapter 3.5.1.1 Removable Media Boot Behavior).
# Booting via boot script.
On Debian I use package flash-kernel to keep /boot/dtb in sync with the kernel and have a u-boot.scr.uimg script with something like the following lines:
setenv bootargs console=${console} load mmc 2:1 ${kernel_addr_r} EFI/debian/grubarm.efi load mmc 2:2 ${fdt_addr_r} dtb bootefi ${kernel_addr_r} ${fdt_addr_r}
flash-kernel is interesting. It generates u-boot script but if extX partition has no bootable flag u-boot distroboot ignores it completely. What's your default partition setup?
I have separate partitions:
/boot of type 83 (Linux, ext2) and marked as bootable and with boot.scr on it. /boot/efi of type ef (EFI, vfat) and not marked as bootable
The sequence on the block device does not matter.
When booting via iSCSI with iPXE I put boot.scr and snp.efi on an EFI partition marked as bootable.
I'm concerned that we're talking about what Linux distros should / shouldn't be doing right now, but haven't been CC'ing a lot of the folks involved on that side of things. Adding some folks.
participants (4)
-
Heinrich Schuchardt -
Ilias Apalodimas -
Michal Simek -
Tom Rini