OSDev.org

Ethin wrote:This in no way invalidates my point.

Ethin wrote:How is it a personal insult if its true? You have aptly demonstrated on this topic alone that you are unable or unwilling to acknowledge that you are wrong.

bzt wrote:It's not allocated because there's absolutely no guarantee that UEFI allocation would return the address where the executable is linked at (should I say yet another design failure...? Why AllocPool not reading the pointer passed to it?) And I didn't wanted to overcomplicate this simple tutorial by mapping the load address to the link address, so it was easier to use an address that's surely above the wasted UEFI memory.

rdos wrote:I agree that this is really a poor design decision. Some things (like switching to real mode or protected mode from long mode) requires fixed physical addresses to work, but there is no guarantee that you can get a physical address below 1M (or below 4G either), and so you need to guess which physical address might be non-used & present in most UEFI implementations. It wouldn't have been a problem to reserve some range for boot/OS loaders.

physaddr_t AllocatePages(int pageCount, physaddr_t maxAddress)
{
    EFI_PHYSICAL_ADDRESS memory = maxAddress;
    EFI_STATUS status = g_efiBootServices->AllocatePages(AllocateMaxAddress, EfiLoaderData, pageCount, &memory);
    if (EFI_ERROR(status))
    {
        Fatal("Out of memory");
    }

    return memory;
}

...

// Allocate 10 page of memory below 1MB
auto memory = AllocatePages(10, 0x100000);

kzinti wrote:UEFI uses identity mapping. You don't have to guess what the physical memory address is: it's the same as its virtual address. Using AllocatePages() with AllocateMaxAddress, you can allocate memory below any address you want. This is in the design of the UEFI API, it wasn't missed.

kzinti wrote:In that case you would have to either design your trampoline to work from any address and/or change your design. I agree this is extra work that you didn't need to do with the BIOS, but that's doesn't make UEFI a broken system.

Different software will have different constraints. UEFI provides memory management, the BIOS doesn't. Expecting UEFI to be compatible with every quirks of the BIOS is unreasonable.

Although this is not guaranteed by the spec, my experience shows that in practice UEFI firmwares will not allocate memory below 1MB on PCs unless you ask for it. That memory is obviously precious. What you can do is ExitBootServices() and then install the trampoline where you want it. But really, make it position-independant to be extra safe (yes, some work required).

kzinti wrote:Here is an example of a SMP AP startup trampoline (real mode) that can run at any address below 1MB:
https://github.com/kiznit/rainbow-os/bl ... ia32/smp.S

rdos wrote:The problem is with switching from protected mode to long mode. I've not been able to figure out a way to do that without a trampoline at a fixed physical address. The main problem is that the code segment always atarts at 0 in long mode and that my assembler (JWasm) has some limitations when it comes to mixing 32-bit and 64-bit code. It might be possible to solve this though.

rdos wrote:The trampoline must be at a fixed physical address since it's called from the BIOS / UEFI after it's internal initialization (mine is at 100:0). You might call this another problem with UEFI. There should have been an API for setting up the AP entry-points, and they should have run in the same mode as UEFI itself. That would have required this to have been part of the run-time services.

rdos wrote:Actually, my OS also requires that a few pages at the bottom of physical memory are free for compatibility reasons with older BIOS loaders. I cannot change this since the loaders are written to disc on some older systems that still run.

kzinti wrote:

rdos wrote:The problem is with switching from protected mode to long mode. I've not been able to figure out a way to do that without a trampoline at a fixed physical address. The main problem is that the code segment always atarts at 0 in long mode and that my assembler (JWasm) has some limitations when it comes to mixing 32-bit and 64-bit code. It might be possible to solve this though.

Here is another SMP trampoline to go from real mode -> protected mode -> long mode. It also works from any address below 1MB:
https://github.com/kiznit/rainbow-os/bl ... 6_64/smp.S

Hopefully you can adapt the technic to work with your assembler.

kzinti wrote: I must say that you are losing me here. In my mind the firmware has nothing to do with trampolines. What do you mean by the BIOS or UEFI calling your trampolines?

kzinti wrote: Neither firmware has support to help your kernel start APs... Why is it a flaw that UEFI doesn't provide such runtime services? The BIOS doesn't either... isn't that also a flaw? Why not start the APs from your kernel (or after exiting boot services) instead of starting them earlier?

rdos wrote:No difference. You still need to locate the code where UEFI jumps to after the initial code is done. When you reset an AP it will start executing in real mode in the UEFI/BIOS area, and you cannot place any code there. So, the way it is solved is that you write a value to the CMOS where you want it to start, but this cannot be anywhere below 1MB. A convenient place is at 0x100:0.

rdos wrote:That the CPU reset-code is located in the UEFI/BIOS, and so it is always UEFI code that is executed first. When it has finished its own initialization of the core, it will jump to an address that is indicated in the CMOS, and then your code must be here.

rdos wrote:The logic is identical between BIOS and UEFI. The AP core will start executing at the RESET vector in BIOS address space, and then your code will be called based on CMOS settings.

rdos wrote:I think this is a flaw in UEFI. First, because this makes it impossible for Intel and AMD to remove real mode

rdos wrote:and second because you still need to have code to switch to protected mode or long mode, which UEFI does for you for the BSP.

kzinti wrote:

rdos wrote:and second because you still need to have code to switch to protected mode or long mode, which UEFI does for you for the BSP.

That means UEFI does more for you than the BIOS does. UEFI switches the BSP to protected or long mode for you where the BIOS doesn't. So UEFI being helpful here is a design flaw?

kzinti wrote:That means UEFI does more for you than the BIOS does. UEFI switches the BSP to protected or long mode for you where the BIOS doesn't. So UEFI being helpful here is a design flaw?

bzt wrote:And can you prove that UEFI will allocate the memory area where the ELF is linked at? Nope, of course you can't. UEFI or not, you must use that address because that's where the segment is linked at.

rdos wrote:I've not been able to figure out a way to do that without a trampoline at a fixed physical address.

rdos wrote:The hand-off between UEFI/BIOS through loader to the OS kernel is already complex enough and shouldn't need to cope with this kind of strangeness from UEFI.

quirck wrote:I wish UEFI was more clear about details of paging mode it sets up.

UEFI Spec 2.3.4 wrote: Paging mode is enabled and any memory space defined by the UEFI memory map is identity
mapped (virtual address equals physical address), although the attributes of certain regions
may not have all read, write, and execute attributes or be unmarked for purposes of platform
protection. The mappings to other regions are undefined and may vary from implementation
to implementation.

quirck wrote:Will it use 5-level paging if available? Will CR4.PCIDE be set?

quirck wrote:If an OS loader isn't prepared for all that, it's probably going to crash. Who knows what future control bits will be added that need to be accounted for.

bzt wrote:I've implemented SMP for RPi, coreboot, BIOS, UEFI etc. And yes, UEFI was the most problematic of all because you must comply with an unknown environment (like GDT and paging), plus jump to a relocated address after set up you don't know at compilation time

kzinti wrote:

UEFI Spec 2.3.4 wrote: Paging mode is enabled and any memory space defined by the UEFI memory map is identity
mapped (virtual address equals physical address), although the attributes of certain regions
may not have all read, write, and execute attributes or be unmarked for purposes of platform
protection. The mappings to other regions are undefined and may vary from implementation
to implementation.

<...>

You seem to imply that if an UEFI implementation used 5-level paging it would crash existing bootloader. I don't see why that would be the case. Can you elaborate what your thinking is here?