turdus wrote:
I've started the UEFI road, and have got quite far. If I may I'd give some advice.
First, there's no need for 2nd stage on UEFI, one efi boot loader application is more than enough.
The 2nd stage needs to run in 32-bit protected mode, preferentially with a segmented model to get rid of problems of where the code is loaded. The kernel is started in non-paged 32-bit protected mode by creating selector 0x30, mapping it to the kernel code loaded in memory, and doing a call to the entry-point. There is no other way to load RDOS.
turdus wrote:
According to /efi/boot/bootx64.efi: you should write your boot loader application in a way knowing it will be run under different names (shouldn't be a problem), and by default, put it in /rdos/bootx64.efi. If you don't want to use a boot manager, simply copy it in /efi/boot directory, but if you do, you can make that to load your app in /rdos. Either way when your app gains control it can load your OS, and don't care whether a boot manager is installed at all.
Yes, except there seems to be some magic also. It seems like Windows 7 can hijack this process and force UEFI to always run some specific efi-file.
turdus wrote:
But, also consider:
1. there's no guarantee you can get any free memory under 4G (for non-paged protected mode), no trick help with that
There is. You refuse to boot
The memory allocation function can be passed a suggested address, and UEFI should reserve it if possible. It can also be passed an upper limit (for instance 4G). This can be used both for the fixed physical address, and to obtain memory in the correct range.
turdus wrote:
2. all BIOS functions have UEFI equivalents
3. no way to know how long the BIOS legacy code (such as VBE) will work on modern machines
therefore there's no need, and you should never switch CPU mode on UEFI architecture in the first place.
Right, but I need a convenient migration route. It's much easier to debug an UEFI implementation that also doesn't need to assume VBE is not present. It's preferable to be able to first boot with UEFI and VBE, implement the required text-mode functions with LFB, and then boot with UEFI and GOP.
turdus wrote:
As for the OS image: you can load it from any FAT device using UEFI calls (no need to implement fs driver in your loader), and let UEFI allocate the memory for it. Once you turn off identity mapping, and set something more comfortable arrangement for your kernel, you can map it at whatever address you like. Just make sure you call exitbootservices before you do so to stop other UEFI applications. If you plan to use fs other than FAT (like me), use the UEFI allocate and readblocks calls and you're good to go. No need for any non-paged mode code to load your kernel at a fixed address.
There is a need to load it below 4G. Otherwise it will be impossible to start the OS.
turdus wrote:
Think it that way: forget code reuse, you'll need to completely rewrite your booting code in a single UEFI application that provides exactly the same environment as your current BIOS loader. (By using PMBR as stage1 you'll still be able to boot the same USB disk image on BIOS machines as well as on UEFI ones without your kernel even knowing which one was used to boot it).
There is no way I will do a full 64-bit OS at the same time as an UEFI boot. If the UEFI boot code cannot handle the current 32-bit segmented kernel, it's simply useless.