x64 UEFI to x86

[kerravon]

I have PDOS-generic in various forms (see pdos.org) and it operates under various pseudobioses.

A "pseudobios" is my term for my own wrapper on top of UEFI/BIOS or anything else to give a C90 API to the OS, so that you can read a disk as a file - it's all hidden - or it is a real file - PDOS-generic has no idea.

So now I would like to run an 80386 version of PDOS-generic but on a modern x64 computer.

It is only things like fread, not fprintf, that the pseudobios is required to provide, so there are never any variable arguments to contend with. I will have all memory allocated below 2 or 4 GiB, and normally I just allocate a fixed 70 MiB or whatever for PDOS to manipulate anyway - enough to run gccwin and get it to recompile itself.

So my plan is for the x64 UEFI pseudobios (it appears as a normal UEFI app, but optionally bootable), to switch to PM32 and execute PDOS-generic, which in turn does callbacks to the x64 pseudobios. There will need to be some (mostly?) assembler glue to convert the different register usages for each function (not a lot of them - fopen etc).

Also I assume that I need to disable interrupts while in PM32 - which is fine by me.

I'm not familiar whether UEFI contains calls to switch from/to long mode and PM32, and also to disable interrupts.

I'll also be ensuring the stack is 16-byte aligned on return to x64 mode.

Any advice/info on the mechanics of this?

Thanks. Paul.

[kerravon]

Oh - correction - it is CM32 I believe I need.

PDOS-generic doesn't do any privileged instructions at all. It goes back to the pseudobios (perhaps HAL - hardware abstraction layer) for all such needs.

It doesn't need access to any particular area of memory either - it will use whatever the pseudobios tells it to use.

[feryno]

Some UEFI firmware still have built-in CSM (compatibility support module, do not mistake with corporate stable model). I was able to install MS DOS 6.22 into machines with these motherboards: ASUS Prime B650M-K (required installing PCIe graphics card with VGA BIOS to enable CSM), Supermicro M11SDV-8C-LN4F (CSM was enabled by default). I used 2 TB spinning plates SATA HDDs (MBR type partitioning, first partition 2047 MB FAT16 + they won't suffer as they do not require TRIM commands unlike SSD disks). When you write 1.44 MB FAT12 floppy image into USB stick they take it as an emulated floppy so you can boot from it and install OS into HDD.
Do you want to run PDOS in newest UEFI x64 systems without CSM?

[kerravon]

Some UEFI firmware still have built-in CSM (compatibility support module, do not mistake with corporate stable model). I was able to install MS DOS 6.22 into machines with these motherboards: ASUS Prime B650M-K (required installing PCIe graphics card with VGA BIOS to enable CSM), Supermicro M11SDV-8C-LN4F (CSM was enabled by default). I used 2 TB spinning plates SATA HDDs (MBR type partitioning, first partition 2047 MB FAT16 + they won't suffer as they do not require TRIM commands unlike SSD disks). When you write 1.44 MB FAT12 floppy image into USB stick they take it as an emulated floppy so you can boot from it and install OS into HDD.
Do you want to run PDOS in newest UEFI x64 systems without CSM?

Yes - correct. The nature of PDOS has changed with PDOS-generic (a totally portable OS unless you really want to quibble). Instead of me insisting on buying hardware that will run PDOS/386, I am instead providing a variety of ways to manipulate existing hardware to suit the PDOS-generic model (which uses no privileged instructions).

The person from Slovakia I work with has told me (just now) that I don't even need to disable interrupts, and has provided the attached example code.

[rdos]

I see no reason why you would want to switch back to x64 if your kernel is 32-bit. I do this by loading a long mode binary that disables long mode and enters protected mode. This binary needs to be loaded at a fixed physical address below 4G. I pass a pointer to ACPI, the video buffer, and a pointer to where the kernel image itself is. You cannot rely on the EFI loader to handle relocations in your 32-bit kernel; instead, you must do this yourself. I don't keep the x64 environment, as it is pretty obsolete. You cannot rely on BIOS, so your kernel must have its own native protected mode drivers.

I think a 32-bit kernel must support PAE if it is loaded by a 64-bit EFI implementation since these might pass physical memory pointers that are above 4G. It is often video memory that is above 4G, but it could also be various PCI devices and even the ACPI table.

[kerravon]

You cannot rely on the EFI loader to handle relocations in your 32-bit kernel; instead, you must do this yourself.

Yes - I will do that.

I don't keep the x64 environment, as it is pretty obsolete.

What's obsolete about it?

You cannot rely on BIOS, so your kernel must have its own native protected mode drivers.

I rely on UEFI. That's the design. I don't exit boot services.

I think a 32-bit kernel must support PAE if it is loaded by a 64-bit EFI implementation since these might pass physical memory pointers that are above 4G. It is often video memory that is above 4G, but it could also be various PCI devices and even the ACPI table.

The pseudobios will handle anything provided by UEFI. The 32-bit kernel only needs to do callbacks into the pseudobios. That's the design.

[zaval]

I'm not familiar whether UEFI contains calls to switch from/to long mode and PM32, and also to disable interrupts.

It doesn't contain calls to from/to long mode and PM32. 64 bit UEFI is always running in a 64 bit long mode with enabled paging, of course. 32 bit UEFI is always running in protected mode with paging disabled. Interrupts are not disabled, but only the timer interrupts are being served. There are no UEFI calls to enable or disable interrupts.

If you want to run your 32 bit protected mode OS* on modern x64 UEFI only machines, I think it's better to write a 64 bit UEFI loader for your OS, that will use UEFI boot services for loading your OS files, and for showing your boot screen and configuration/option screen if you have any and that will prepare and switch to the required CPU execution mode/state in the final, trampoline loading phase. The only thing, that you can't use after that is UEFI runtime services, in your OS, but it's not that bad and even then, if you still would want to use them, you could, just preserve their code and data and switch back to 64 bit long mode before calling them.

* correction. After reading yet once, I realized, that what you want would be a bit harder to achieve, since if you want to preserve the whole UEFI environment with boot services includingly, then you should do what's needed for that. Your wrapper should restore CPU execution state/mode on every call to UEFI. in addition to preserving all the code and data for both boot and runtime services. It's hard to say how usable this baroque structure will be though, because if you don't exit boot services, you can't serve any peripherals, everything only via the wrapper and calls to UEFI. How possible then it would be to use protected mode? On every timer interrupt UEFI must take control and be in a 64 bit long mode, how could you achieve that if you switched to pm? If you want to keep using boot services, you cannot switch to pm, because you have no control on the timer. It's under UEFI boot services until you exit them, so no, better to add to pdos to become a 64 bit one or not rely on UEFI during pdos runtime.

[kerravon]

I'm not familiar whether UEFI contains calls to switch from/to long mode and PM32, and also to disable interrupts.

It doesn't contain calls to from/to long mode and PM32. 64 bit UEFI is always running in a 64 bit long mode with enabled paging, of course. 32 bit UEFI is always running in protected mode with paging disabled. Interrupts are not disabled, but only the timer interrupts are being served. There are no UEFI calls to enable or disable interrupts.

If you want to run your 32 bit protected mode OS* on modern x64 UEFI only machines, I think it's better to write a 64 bit UEFI loader for your OS, that will use UEFI boot services for loading your OS files, and for showing your boot screen and configuration/option screen if you have any and that will prepare and switch to the required CPU execution mode/state in the final, trampoline loading phase. The only thing, that you can't use after that is UEFI runtime services, in your OS, but it's not that bad and even then, if you still would want to use them, you could, just preserve their code and data and switch back to 64 bit long mode before calling them.

* correction. After reading yet once, I realized, that what you want would be a bit harder to achieve, since if you want to preserve the whole UEFI environment with boot services includingly, then you should do what's needed for that. Your wrapper should restore CPU execution state/mode on every call to UEFI. in addition to preserving all the code and data for both boot and runtime services. It's hard to say how usable this baroque structure will be though, because if you don't exit boot services, you can't serve any peripherals, everything only via the wrapper and calls to UEFI. How possible then it would be to use protected mode? On every timer interrupt UEFI must take control and be in a 64 bit long mode, how could you achieve that if you switched to pm? If you want to keep using boot services, you cannot switch to pm, because you have no control on the timer. It's under UEFI boot services until you exit them, so no, better to add to pdos to become a 64 bit one or not rely on UEFI during pdos runtime.

I added something additional to say CM32 rather than PM32. Does your comment still apply?

Even if it does apply - you mention I have no control over the timer. Surely I just need to disable interrupts while in PM32 or CM32?

And regardless of any of that - what peripheral would need to be served? PDOS is single-tasking. It will wait for any read or write to complete before resuming execution.

I did some timings recently on a long-running CPU-intensive (ie in reality memory-access intensive) task that interests me (mfemul) and Windows with disk caching was about 18% faster than PDOS with no disk caching and just relying on SSD to be fast itself.

[rdos]

I think this design should use compatibility mode within long mode. This way you should not need to disable interrupts or switch to protected mode. Still, this will be a pretty lame design.

[kerravon]

I think this design should use compatibility mode within long mode. This way you should not need to disable interrupts or switch to protected mode. Still, this will be a pretty lame design.

Yes, it can be considered lame. But so long as it works, people will have a fully working starter system with which to develop a non-lame os.

Which is my goal. I'm not trying to create the world's best os at this point in time.

Nor do I have time to do so with my limited resources.

It has taken me over 30 years to get this far.