How to generally enter virtual 8086 mode?

[rdos]

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.

Maybe so, but the same binaries can run on anything from ancient 386s to modern threadrippers. Most modern OSes cannot even run on hardware that doesn't support long mode. My OS can boot without BIOS, with legacy BIOS, 32-bit EFI and 64-bit EFI.

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.

For me, UEFI and BIOS is just a way to launch a real OS. Having to learn how to write an EFI bootloader, how to build it with GCC is just distraction from more useful stuff.

And I certainly prefer assembly over C. I primarily work with C++ and assembly, but not C. C is just a lazy language for people that cannot write in assembly directly. It lacks the power of assembly and creates unreadable code when low-level stuff is implemented.

[Gigasoft]

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.

Then you would use allocation type AllocateMaxAddress, doesn't need to be a fixed one.

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.

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]

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.

I don't have a linked OS image. The kernel driver is initialized by finding the driver in the binary loaded by EFI (or BIOS), mapping it to selector 0x30 and calling the entry-point with a far call. For this to work, the GDT must contain entries that relate to the loaded image.

OTOH, I do support loading the OS binary at any point. The primary problem is with switching from long mode to unpaged mode and set up 32-bit paging from a random physical address. I typically won't identify-map all of memory, and require the kernel to reside in "low" memory.

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.

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.

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

After reading this, I'm just as lost as to how Windows manages to lock-down boot and how to fix it.

[Ethin]

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.

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.

Uh... Its not undocumented at all. Have you actually read the UEFI specification? Last time I checked, the UEFI specification not only contained very in-depth discussion of the UEFI variable subsystem, including the ones that were standardized (yes, standardized, what a concept!), as well as functions for not only getting and setting variable values but also querying info about them and authenticating them.

Edit: also, UEFI does not require that the system be in 64-bit mode when UEFI sets up its environment. You should carefully re-read section 2.3 of the UEFI specification.

[Octocontrabass]

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.

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.

Yes, deleting the Windows boot manager also counts as moving it elsewhere.

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

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

[rdos]

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.

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.

[Ethin]

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.

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.

I find it very interesting that your just looking at things like the page count and jumping to conclusions. The UEFI specification does not just specify how to boot an OS; it specifies debugging support, supported file systems... It describes computer firmware.

[Octocontrabass]

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.

[Gigasoft]

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.

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

If the OS is being installed from a separate installation medium, the installer application would be the one setting up the variables. You run the installer by selecting the appropriate boot option (USB, CD, or Network) from the firmware menu. Or are you saying you don't have this menu at all?

An installer that runs inside Windows would call SetFirmwareEnvironmentVariableA. If you are doing it manually then there is probably a tool out there on the internet for editing UEFI variables.

[kzinti]

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

That's just FUD. I am on my 3rd computer where I use UEFI booting. I also use secure booting for my Windows 11 installation. I can still boot Linux and my own OS from UEFI. There is no locking anywhere. I can do whatever I want with my UEFI system.

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

I have used rEFInd in the past, it's a great bootloader for machines with UEFI firmware. I also has command line tools to manipulate variables.
https://www.rodsbooks.com/refind/installing.html

There is also the UEFI shell that allows you to manipulate variables:
https://linuxhint.com/use-uefi-interact ... -commands/

[rdos]

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.

I read chapter 3, and it provides some interesting background to "variables". I suppose I need a "tool" that just wipes out all boot variables so the computer boots using the default efi-file.

[kzinti]

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]

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.

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.

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.

[kzinti]

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.

Both inithd and mkpart are tools...

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.

bootx64.efi is the bootloader... not sure why you need a second stage bootloader (load64.bin) but that's fine, it has nothing to do with UEFI.

I don't know why you have this problem where you need to erase UEFI variables, I have never run into this or heard about it before now. Just erase your CMOS if your firmware is in a bad state. No tools required. Did you set the boot priority to your floppy drive? The fact that you are attempting to boot a floppy drive with UEFI might actually be the problem. It's not exactly a common or expected scenario. Yes there are old systems still using floppy drives, but they also don't have UEFI.

[Ethin]

Pretty sure the only reason your able to boot the floppy drive at all is because your doing it over USB. Get with the times and use this thing called a USB flash drive and you might find your life being a bit easier.