[arm] Remove native u-boot loader

[kallisti5]

Once the arm / arm64 EFI bootloaders can successfully enter the kernel, we should likely drop the native u-boot platform loader.

u-boot offers EFI bios services now, which simplifies everything from a bootloader perspective on pretty much every platform.

The native u-boot platform loader only received an FDT, thus needed a bunch of "mini uart" drivers packaged within it per architecture to support "whatever" debug output.

Leveraging EFI means we can rely on EFI bios services until the kernel drivers can take over.

https://dev.haiku-os.org/ticket/17188 is a sister ticket to this one.

[X512]

It would be better to reorganize boot loader code to reduce code duplication instead of deleting boot loader platforms.

Existing platform code can be reorganized info 4 parts:

1. Generic code (example: region allocator). Move it to common part of boot loader.

2. Architecture-specific code (example: setup MMU page table, jump to kernel). Move it to common "arch" directory and reuse between platforms.

3. Drivers (example: FDT code, VirtIO disk and keyboard drivers, display drivers). Make some new directory for them and share between platforms.

4. Actual platform code (example: serial output while firmware is used, framebuffer setup, disk reading). Keep it as is.

[axeld]

Besides drivers, which are currently not really exposed, the current code should already be divided into the three parts that you mentioned.

I'm not sure if you actually need drivers in the boot loader separately, at least I don't see much value in it, as there is no platform abstraction suitable for drivers.

Why would we need drivers, if EFI (or any other firmware) already takes care of our needs?

Drivers would only really be useful if we want to be able to boot without firmware support. I don't see much reason to provide a complete platform abstraction just for this use case. I wouldn't assume that's how we want to boot on more than very few hardware, if at all.

[X512]

Why would we need drivers, if EFI (or any other firmware) already takes care of our needs?

First I consider FDT handling as drivers because it is used by multiple platforms and architectures. Some hardware may need drivers because firmware don't handle it properly. For example existing Haiku u-boot ARM boot loader have graphics driver: ​https://git.haiku-os.org/haiku/tree/src/system/boot/platform/u-boot/arch/arm.

[X512]

the current code should already be divided into the three parts that you mentioned.

Region allocator is still duplicated on all platforms, but only physical pages allocation is actually platform-dependent. MMU code also can be shared for example for EFI and BIOS boot loader.

[kallisti5]

Drivers would only really be useful if we want to be able to boot without firmware support. I don't see much reason to provide a complete platform abstraction just for this use case. I wouldn't assume that's how we want to boot on more than very few hardware, if at all.

That's kind of what position the native u-boot loader puts us into. For context:

• EFI bootloader
  • Can be started by u-boot on arm,x86,riscv,etc via bootefi command
  • Can be started by tianocore on arm,x86,riscv(wip upstream),etc
  • Provides bios services for printf, serial, framebuffer, network, etc to bootloader.
  • Our bootloader gets a FDT passed in via EFI as well.
• u-boot bootloader
  • Can be started by u-boot with a long history of existance
  • Doesn't provide bios services. We get a dtb and our bootloader needs individual drivers packed into it for various uart / serial / framebuffer / video devices until our kernel loads.

There's a lot of reasons to put focus on the EFI bootloader on non-x86 platforms and to abandon the native u-boot haiku_loader.

Geist brought up that older ARM SoC's may have forked u-boot trees pre-EFI support as a counter point, however i'm not sure we should waste time trying to support arm boards which never bothered to upstream their u-boot support. (Raspberry Pi, Beagle Bone, LibreComputer, Orange Pi, Tinker Board, all have upstream u-boot support for context and can start our EFI bootloader)

With all of this said.. the arm EFI haiku_loader has not yet been successful jumping into our kernel. More work is needed before taking any action on this ticket.

This was opened for some thought and discussion around it :-)

[davidkaroly]

The ARM u-boot loader has been removed as of hrev56225.

In case anyone's interested, I retained an almost-working version in my github branch:

​https://github.com/davidkaroly/haiku/tree/archive/u-boot-arm