* Load Debian/Fedora via EFI
2019-12-03 19:51 ` Heinrich Schuchardt
@ 2019-12-04 3:07 ` Ilias Apalodimas
2019-12-05 10:21 ` Michal Simek
2019-12-05 14:37 ` Tom Rini
2 siblings, 0 replies; 8+ messages in thread
From: Ilias Apalodimas @ 2019-12-04 3:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Load Debian/Fedora via EFI
2019-12-03 19:51 ` Heinrich Schuchardt
2019-12-04 3:07 ` Ilias Apalodimas
@ 2019-12-05 10:21 ` Michal Simek
2019-12-05 11:52 ` Heinrich Schuchardt
2019-12-05 14:37 ` Tom Rini
2 siblings, 1 reply; 8+ messages in thread
From: Michal Simek @ 2019-12-05 10:21 UTC (permalink / raw)
To: u-boot
ú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
^ permalink raw reply [flat|nested] 8+ messages in thread* Load Debian/Fedora via EFI
2019-12-05 10:21 ` Michal Simek
@ 2019-12-05 11:52 ` Heinrich Schuchardt
0 siblings, 0 replies; 8+ messages in thread
From: Heinrich Schuchardt @ 2019-12-05 11:52 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Load Debian/Fedora via EFI
2019-12-03 19:51 ` Heinrich Schuchardt
2019-12-04 3:07 ` Ilias Apalodimas
2019-12-05 10:21 ` Michal Simek
@ 2019-12-05 14:37 ` Tom Rini
2 siblings, 0 replies; 8+ messages in thread
From: Tom Rini @ 2019-12-05 14:37 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 8+ messages in thread