OSDev.org

Ethin wrote: These are obstacles for you in particular. Your OS uses ancient, outdated technologies that no modern OS uses, which is why your running into these problems.

Ethin wrote: UEFI has lots of advantages for me: I get to write less assembly, I can implement nice things like braille display HID support as early as the very point when the USB hardware is initialized by the firmware (try doing that in BIOSes, I guarantee you you won't be able to do it), and a lot is standardized that isn't in a BIOS system. Before UEFI came along any form of accessibility -- even the most primitive stuff -- was a pipe dream and it was just known that such a thing would never happen, but it is no longer a pipe dream and can be done with what UEFI provides. It helps that the vast majority of HW vendors *don't* reimplement UEFI and just use EDK II (although a customized form of it). Sadly, many people don't think of accessibility during development and only as an afterthought, which I hope changes soon because that's something that I shouldn't have to make into a legal requirement to get people to do. Anyway. I find UEFI to be a blessing a lot more than a curse, considering what it allows me to do. Secure boot abuse is a problem, but I appreciate the fact that I can set up my own keys and lock down the boot process to things only I want to boot, and I can then reinforce that with extra restrictions of my own when my kernel is launched. I appreciate that I don't have to care about the video mode; I always will have an LFB and that means I don't have to add extra code for text mode unless I want it, and if I want that I might as well just write a GPU driver. I never have to reconstruct any boot environment because I don't care about segments when paging gives me all the benefits of segments and then some.

rdos wrote:Of course, the primary reason I want to place my OS image at a fixed address is because it must be below 4G. A 64-bit EFI might place it above 4G. I also have reserved a physical address range a bit higher (0x120000) that is aimed to be used to switch between long mode and protected mode. I need this since that process requires turning off paging.

rdos wrote:Actually, the boot process itself requires the loader to be placed at a fixed address too, for exactly the same reason. To get back to protected mode, there is a need to define a new GDT, turn off long mode (which ends up in non-paged mode) and init protected mode. This process is much easier to do when the image is loaded at a fixed address.

rdos wrote:How to change boot variables is undocumented and not supported by the UEFI interactive interface.

Gigasoft wrote:

rdos wrote:Actually, the boot process itself requires the loader to be placed at a fixed address too, for exactly the same reason. To get back to protected mode, there is a need to define a new GDT, turn off long mode (which ends up in non-paged mode) and init protected mode. This process is much easier to do when the image is loaded at a fixed address.

Yes, but you could move this code into the OS image instead, and just have different entry points for BIOS, 32-bit UEFI and 64-bit UEFI.

Gigasoft wrote:

rdos wrote:How to change boot variables is undocumented and not supported by the UEFI interactive interface.

How is it undocumented? Use the EFI Runtime Services SetVariable function. Sounds like a case of not RTFM.

rdos wrote:

Octocontrabass wrote:

rdos wrote:If that wasn't enough, I cannot tell UEFI to place my OS image at a fixed physical address, and so I need to guess were it is safe to place it. With BIOS, I can load it anywhere I want.

Why do you want to place your OS image at a fixed physical address? (Plus, BIOS and UEFI both provide a memory map that tells you exactly where you can place things.)

Because it is convenient. With BIOS, it pretty safe to place an OS image just above the HMA area (0x110000). The BIOS memory map primarily is useful so the OS knows where there is working physical RAM. With older 386 hardware, I don't think you can rely on the BIOS memory map function to even exist.

The UEFI memory map, OTOH, is cluttered with UEFIs own memory usage that is not standardized. It's possible that UEFI could place itself or some data just above HMA (although, I've not yet seen any implementation that does so).

Of course, the primary reason I want to place my OS image at a fixed address is because it must be below 4G. A 64-bit EFI might place it above 4G. I also have reserved a physical address range a bit higher (0x120000) that is aimed to be used to switch between long mode and protected mode. I need this since that process requires turning off paging.

Actually, the boot process itself requires the loader to be placed at a fixed address too, for exactly the same reason. To get back to protected mode, there is a need to define a new GDT, turn off long mode (which ends up in non-paged mode) and init protected mode. This process is much easier to do when the image is loaded at a fixed address.

Octocontrabass wrote:

rdos wrote:often you will find Windows still boots even when you have replaced the proposed 64-bit loader bootx64.efi.

That's because bootx64.efi is the fallback bootloader, used only when there are no other bootloaders installed. You're supposed to install your own bootloader within your own subdirectory and create a boot variable that refers to it.

Unfortunately, some broken UEFI implementations will always launch the Windows boot manager if it's present, ignoring boot variables and the fallback bootloader. In these cases, you'll have to either move it elsewhere (and update the Windows boot variable to point to the new location) or replace it with your own bootloader.

How to change boot variables is undocumented and not supported by the UEFI interactive interface.

Anyway, a safe way to remove Windows appears to be to repartition the disc, as this appears to make UEFI so confused so it uses bootx64.efi to boot regardless of the hidden settings Windows once created.

rdos wrote:With older 386 hardware, I don't think you can rely on the BIOS memory map function to even exist.

rdos wrote:Anyway, a safe way to remove Windows appears to be to repartition the disc, as this appears to make UEFI so confused so it uses bootx64.efi to boot regardless of the hidden settings Windows once created.

rdos wrote:Besides, the documentation of GetVariable and SetVariable says nothing about "boot functions":
https://edk2-docs.gitbook.io/edk-ii-uef ... etvariable

Octocontrabass wrote:

rdos wrote:With older 386 hardware, I don't think you can rely on the BIOS memory map function to even exist.

INT 0x15 EAX=0xE820 doesn't exist on any 386 hardware I've seen, but INT 0x15 AH=0x88 does. There is no situation where you would need to make assumptions about the memory map. And if we're talking about older 386 hardware, you can't assume there's memory at 0x100000 in the first place.

Octocontrabass wrote:That's not the documentation. This is the documentation. Boot variables are explained in chapter 3 of the UEFI specification.

rdos wrote:

Octocontrabass wrote:

rdos wrote:With older 386 hardware, I don't think you can rely on the BIOS memory map function to even exist.

INT 0x15 EAX=0xE820 doesn't exist on any 386 hardware I've seen, but INT 0x15 AH=0x88 does. There is no situation where you would need to make assumptions about the memory map. And if we're talking about older 386 hardware, you can't assume there's memory at 0x100000 in the first place.

I think I can because I require a minimum of 4 MB of RAM, which means there should be RAM at 0x110000 if the computer has 4 MB of RAM.

Octocontrabass wrote:That's not the documentation. This is the documentation. Boot variables are explained in chapter 3 of the UEFI specification.

Over 2,500 pages to explain how to boot an OS? That's insane.

rdos wrote:Over 2,500 pages to explain how to boot an OS? That's insane.

rdos wrote:Which is a bit circular since if I already can boot my EFI image I don't need to change variables. I want to "kick-out" Windows by deleting the variables they setup to lock down the boot process, but naturally I cannot do this if I cannot boot an EFI image. For this to be user friendly, it would be required to be able to view & delete these variables in the setup GUI.

In short, if UEFI really aimed at user friendliness, there would be no variables for how to boot, rather public functions to register new OSes to a boot-manager BUILT-INTO UEFI. And the setup GUI would be REQUIRED to be able to delete unwanted boot entries and run EFI OS installation images. This is not something you should do from inside Windows.

Gigasoft wrote:Don't know what you mean by "lock down the boot process", Windows certainly does no such thing.

Gigasoft wrote:If you are doing it manually then there is probably a tool out there on the internet for editing UEFI variables.

Octocontrabass wrote:

rdos wrote:Over 2,500 pages to explain how to boot an OS? That's insane.

Do you have to read all of Ralf Brown's Interrupt List to boot an OS on BIOS? No, of course not.

It's the same for UEFI.

rdos wrote:I suppose I need a "tool" that just wipes out all boot variables so the computer boots using the default efi-file.

kzinti wrote:

rdos wrote:I suppose I need a "tool" that just wipes out all boot variables so the computer boots using the default efi-file.

Right, it's not like you need any tool to write your BIOS bootloader to the MBR.

rdos wrote: No, I don't. I boot with a USB floppy containing my OS and then on the command line I write "inithd /i / r 0", then I create a partition with mkpart, and copy the boot image to the root. That's pretty simple.

rdos wrote:With UEFI, I boot with a similar USB floppy containing my OS and then on the command line I write "inithd /G 0", then create a system partition and root partition with mkpart, create a few directories there, copy the bootx64.efi (or booti32.efi) to the correct position, copy the boot loader (either load32.bin or load64.bin), and then copy the boot image to the root. That's considerably more complicated, and then I have still not been able to wipe out the EFI boot variables so I'm not guaranteed that my OS rather than
Windows will be booted.