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
signature.asc
Description: PGP signature
