SFO17 Cross-Distro meeting notes

[Enrico Weigelt, metux IT consult]

On 29.09.2017 01:06, Riku Voipio wrote:

> One day, booting on arm will be so boring, that nobody will bring it
> up on our cross-distribution BoF. That day was not today.

Depending on the board's boot devices, it already may be pretty boring.
At least non-embedded boards should just boot from an internal micro-sd.
Easy to maintain / replace by operators.

> RHEL only supports ACPI on arm64. Even if you are not RHEL, you should
> prefer ACPI over device tree, if the former is available.

Actually, I'd always prefer DT over ACPI. And I never ever wanna depend
on any crappy BIOS/EFI firmware. It's whole purpose is just obsolete
(technically, already was obsolete when ACPI was invented)

> U-boot can now start EFI binaries, making u-boot an excellent platform
> to implement an UEFI bios. 

Why should anyone introduce such obsolete things like EFI/BIOS on arm ?
For what purpose ?

One of the major benefits of ARM world is that we don't have to care
about those crappy proprietary relics. We have full control over our
machines, and we won't let that be taken away again.

> This allows single-path installers for
> distributions, where install of distribution starts always by loading
> grub from EFI.

This is completely obsolete, if you just have a barebox on the primary
boot medium (where the ROM loader starts from), which - of course -
passes the right DT etc to the kernel. We don't even need any special
MBR setup anymore - the bootloader just reads some plain text files
from some filesystem (eg. first hdd, network, whatever you like).
We don't need grub on arm - barebox is far superior. u-boot might be
interesting for *very small* devices (where every byte counts), but for
most machines it's just obsolete.

> On arm64, Kernel doesn't self-decompress. The bootloaders are stringly
> recommended to support decompressing kernel images. It's optional in
> grub, make sure your grub does. At least iPXE and u-boot don't support
> booting Image.gz on arm64, and should be fixed.

barebox supports lots of different image types, compressed as well as
uncompressed. even if - for whatever reason - whe might need to invent
yet another one, it's pretty simple to add.


--mtx