[U-Boot] Load Debian/Fedora via EFI

[U-Boot] Load Debian/Fedora via EFI

[Michal Simek]

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


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

[U-Boot] Load Debian/Fedora via EFI

[Heinrich Schuchardt]

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

[U-Boot] Load Debian/Fedora via EFI

[Michal Simek]

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

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Load Debian/Fedora via EFI

[Heinrich Schuchardt]

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
>

Load Debian/Fedora via EFI

[Ilias Apalodimas]

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

Load Debian/Fedora via EFI

[Michal Simek]

ú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

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Load Debian/Fedora via EFI

[Heinrich Schuchardt]

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

Load Debian/Fedora via EFI

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191205/7f0b5f5f/attachment.sig>