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
>