Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Understanding EFI

On Tue, Mar 27, 2018 at 04:29:06AM +0500, Saad Mahmood Mughal wrote:
> Port-arm folks this is the relevant part I wanted to ask to you guys:
> I also had some questions regarding U-boot. (*2) looked similar to my
> project but after reading it I am a bit confused. The problem is that is
> Wikipedia says that U-boot is a bootloader but the milestones in my project
> say that we need to use U-boot's EFI services to run NetBSD's bootloader. I
> am assuming that the U-boot bootloader will be the first to boot and then
> it will boot our EFI bootloader as an EFI application.

Think of it as several stages of a bootloader.

Typical old i386 example: the BIOS reads sector 0 of the hard disk (the
Primary Boot Record) and executes code in there, the PBR identifies the
NetBSD partition and executes code in the first sector of that (the Master
Boot Record), that code in turn loads the secondary boot loader /boot
and executes it.

That "final" bootloader now interacts with the user in a pretty common
way for most NetBSD architectures, it offers a command prompt and optional
menu, defined in /boot.cfg.

For ARM, depending on the exact cpu and machine, the way may be even
more complicated (including various security levels and signed
binaries), but in the end we would like to end in a similar "final boot
loader" as described above.

One nice way to get there is to use a u-boot variant that offers 
"UEFI services", which abstract all device IO aways - so this final boot
loader would not really care about FDT or any information in there (but
it would later pass a device tree loaded from a DTB file or the original
one used by u-boot on to the kernel).

We have such an (U)EFI boot loader for some architectures already: ia64 (but
that one is not a good start to look at), i386/amd63, and also arm64 (not
yet in-tree, but publically available).

Instead of having multiple different versions, we should just have one,
and it should work for all our architectures that have (U)EFI services


Home | Main Index | Thread Index | Old Index