FDT or ACPI

[n0p0n3]

I am having trouble finding a hard answer on the topic of hardware detection. My current project is refactoring parts of xv6 into a software based antikernel/exokernel design as practice before attempting similar with netbsd, but I am finding it difficult to understand parts of the boot process. I aim for x86_64 and arm (specifically the pinephone) support and have chosen uboot as the firmware to provide uefi (bare mode for x86_64). I have read that uboot provides acpi tables on x86, but can't seem to find if it does on arm. I have seen that EBBR requires either fdt or acpi tables for hardware enumeration, but cannot find how to determine which is provided, or where fdt are stored. In older docs, fdt was passed to kernel directly, but it seems now it can be passed through EfiACPIReclaimMemory? Is there a standard way, or do I just need to check each case? Is there a better way I have not found? I've been a lurker here for a long time, love that this place provides so much information that seems can only be found in undergrad level computer science courses (of which I have taken a few through places like edx and mit opencourseware), but sometimes there's answers that require coming out of the woodwork for.

[Octocontrabass]

Follow the pointer in the EFI system table to the EFI configuration table and search the EFI configuration table for an ACPI or Devicetree entry. Chapter 4 of the UEFI specification has more details.

I'm not sure if there are any restrictions on which type of memory Devicetree tables may be located in.

[zaval]

keep in mind, that what EBBR specifies or any other BBR from ARM and what uboot on pinephone (or uboot in general) does - are very different things. in short, there is no ACPI for any Allwinner/Amlogic/Rockchip SoCs yet. so, despite ACPI is waay better, than FDT, you can't have it for your target. Or, you can create it on your own. I wanted to consider such a possibiilty, but, admittedly, I haven't reached yet to that point, that I can boast both deep ACPI knowledge and having Allwinner's SoCs full documentation, full enough for creating ACPI tables for Allwinner - I just can't say yet if it's possible to create your own set of ACPI tables for their chips yet. If it is, I'd go with this approach, because, frankly, FDT is a very linuxism contaminated clusterf&ck.

and yeah, FDT is passed through the system table, as Octocontrabass said. it's when you use uboot's UEFI. you tell uboot - here is my .dtb (via script or manually in its CLI) and it passes it to your loader. so, you need to write a script for uboot, that will load a .dtb file, preprocess it via uboot's specific commands, then load your UEFI OSL and then finally use bootefi command for taking control over. FDT will be specified in the system table and you can ensure it is really FDT by looking at the appropriate GUID set by UEFI, it's all specified in the UEFI spec.
the script would be something like this:

Code: Select all

fdt_addr_r 0x43000000
kernel_addr_r 0x42000000

load mmc 0:1 0x43000000 /boot/dtb/sun8i-r40-bananapi-m2-ultra.dtb
fdt addr 0x43000000
fdt resize
fdt set /chosen bootargs "your kernel flags, if any. would be stuffed into this special DT node"

fatload mmc 1:1 0x42000000 <path/to/your/osl.efi>
bootefi 0x42000000 - 0x43000000

it's an example, but be sure to check "bootefi" command parameters, I forgot the whole set, because I only pass the loaded .efi, no FDT yet.

passing a .dtb through the specified register is a linux specific behavior, as described in the linux documentation (implemented via uboot's "booti" command), it's not relevant to UEFI.

[n0p0n3]

That's alot to unpack all at once, I'll have to refer back to it as I work. Thanks alot for the info. Right now I'm following poncho's uefi os tutorials to get a basic kernel working up to getting the memory map (most of what I want to play with is moving the kernel upper half into the libc in an antikernel design, but without the specialized hardware, thus an exokernel). I decided on using uefi to not have to deal with switching to long mode myself and other benifits, but I needed to know about this mainly for hardware detection, not trying to use acpi's device drivers myself (yet, I've seen its needed for system shutdown at least? that or triple faulting, but I'm not that far yet). So, If I understand correctly, uboot presents the info the same as acpi? I just need to have a branch to handle whichever is passed? It was just confusing because SBBR requires uefi, EBBR requires one or the other, but not both, and I couldn't find a definite answer on how it was to be handled, just a discussion thread that moved somewhere else without deciding which standard needed to handle it.

[zaval]

uboot passes to your UEFI OS Loader FDT. you find it in the configuration table, which you find through the system table, the pointer to which you get as a parameter of your loader entry. that this configuration table is FDT, you know, looking at its GUID - there is GUID, defined for FDT. from there, you try your best to get HW info from FDT. good luck with that.

[n0p0n3]

Ok, Thats what I thought. Thanks for the info, been a big help. Is there any consensus on 2nd stage bootloader + kernel vs uefi direct loading the kernel? Like uefi->grub->linux vs uefi->linux w/ efistub?

[Octocontrabass]

I don't know if there's any consensus, but I prefer to have a separate loader. It makes linking the kernel at a higher-half address easier, since the code to set up the higher-half paging is part of the loader.

It also gives you flexibility in your binary format. Your loader has to be relocatable PE, but your kernel can be whatever you want.

[zaval]

Ok, Thats what I thought. Thanks for the info, been a big help. Is there any consensus on 2nd stage bootloader + kernel vs uefi direct loading the kernel? Like uefi->grub->linux vs uefi->linux w/ efistub?

UEFI implies, you would have your OS Loader, as a UEFI application and it will do its job, using services, provided by the firmware. Seconding Octacontrabass, I go with this approach and imo, it's the only normal way in case of UEFI.

What linux does, is another story. and it's rather a matter of if you want to follow that design choices. it's your project after all, why should you align with what someone else is doing? (esp. if that choice looks awkward ). as I know, most linux distributions for pinephone or, more generally, - for these enthusiastic SBCs, don't use UEFI at all. uboot has linux specific things, so they use that (booti command for example, as said above, it plainly follows linux "format"). but there are distributions, that can be booted using UEFI and do use grub or maybe that UEFI stub stuffed into the linux kernel directly. OpenBSD uses UEFI capabilities of uboot, a normal way, IIUC. that is, comes with its own standalone loader, at least for the preinstallation phase. But again, I'd consult with the specification of the interface, you are going to use. not with how others do. The UEFI spec's "Introduction" and "Overview" sections give a pretty clear understanding of how UEFI sees things should be arranged.

[n0p0n3]

I was just wondering if there was any hidden pitfalls associated with doing it the efistub way, my kernel is pretty much just going to be a second stage bootloader anyway, just enough to setup free memory lists, parse hardware and setup vfs, other than that, the system is going to be somewhat like a multitasking bare metal machine with synchronization and access controls done through the vfs. It just seemed overcomplicated having a separate bootloader when my kernel is just going to be load and forget. I've spent along time designing, and learning theory, but I'm just now getting to implementation. I decided on using uboot because it has the uefi capabilities, mostly to have a single stable(ish) boot system across my supported archs. Anyway, thanks alot for all the help!

[Octocontrabass]

I was just wondering if there was any hidden pitfalls associated with doing it the efistub way,

It makes your kernel depend on UEFI, and it's more difficult to link.

The only non-obvious pitfall you might run into are relocations. UEFI requires a relocatable PE binary, which means your stub either needs completely position-independent code or a relocation table. If you write the stub entirely in assembly, it's not too difficult to ensure the code is completely position-independent, but it's not so easy if you're planning to write the stub in another language.

Some UEFI implementations (e.g. OVMF) may load your PE binary even if it's not relocatable.