dunkaist wrote: ↑Mon Dec 11, 2023 10:07 amIndeed, jumping directly to the 32-bit code was one of reasons to separate BIOS code to bootbios.asm. Another reason was to avoid dead 16-bit code when booting on modern UEFI systems.
Yes, but I think you shouldn't worry about that dead code. It's just a few kilobytes, and it provides backward compatibility out-of-the-box with all the non-UEFI loaders. (Those wouldn't mind this protmode entry pointer either.)
dunkaist wrote: ↑Mon Dec 11, 2023 10:07 amUnfortunately, things have got more complicated since separation of bootbios.asm. If you grep /kernel/trunk, you can see that UEFI macro is used in a number of files
I did. I took the libery to assess the situation before I made this suggestion. I'm fairly certain they won't do anything (about 99.99999% sure).
Code: Select all
$ grep UEFI `find . -name '*.asm'` `find . -name '*.inc'`
./kernel.asm:if ~ defined UEFI
./init.inc:if defined UEFI
./init.inc: ; UEFI loader knows where RSDP is
./video/cursors.inc:if ~defined UEFI
./blkdev/disk.inc:; GUID Partition Table Header, UEFI 2.6, Table 18
./blkdev/disk.inc:; GPT Partition Entry, UEFI 2.6, Table 19
./core/apic.inc:; non-UEFI loaders don't load DEVICES.DAT and don't initialize [acpi_dev_size]
./core/apic.inc:if defined UEFI
./bootloader/uefi4kos/uefi.inc:;; Based on UEFI library for fasm by bzt, Public Domain. ;;
./bootloader/uefi4kos/uefi64.inc:;; Based on UEFI library for fasm by bzt, Public Domain. ;;
./bootloader/uefi4kos/uefi32.inc:;; Based on UEFI library for fasm by bzt, Public Domain. ;;
$
Now one by one:
kernel.asm: this is just the one that prefixes the binary with the biosboot code.
init.inc:
Code: Select all
if defined UEFI
; UEFI loader knows where RSDP is
mov ebx, [BOOT_LO.acpi_rsdp]
test ebx, ebx
jz .done
call .check
else
movzx ebx, word [0x40E]
shl ebx, 4
lea ecx, [ebx+1024]
call .check
...
Considering that like you said, biosboot leaves the BOOT_LO zeroed out, this "if" could be removed. If acpi_rsdp is set, we can use it, if not, then the code could go on as usual. (However if I were you, I would consider moving the word [0x40E] part into bioscode and set BOOT_LO.acpi_rsdp there, so init.inc wouldn't have to care where that pointer come from.)
video/cursors.inc:
Code: Select all
if ~defined UEFI
cmp [SCR_MODE], word 0x12
jne .not_vga
; TODO
Similar, only this time it's the UEFI loader that leaves the mode field zero. (We must check if SCR_MODE is indeed initialized from BOOT_LO.mode, and then this "if" can be removed.)
blkdev/disk.inc: just a comment about GPT
core/apic.inc:
Code: Select all
; non-UEFI loaders don't load DEVICES.DAT and don't initialize [acpi_dev_size]
if defined UEFI
cmp [acpi_dev_size], 0
jz @f
stdcall map_io_mem, [acpi_dev_data], [acpi_dev_size], PG_SWR
mov [acpi_dev_data], eax
jmp .loaded
@@:
end if
This again won't cause trouble, just need to check if acpi_dev_size is indeed initialized from BOOT_LO.devicesdat_size (which biosboot zeroes out), and then it's safe to remove this "if".
dunkaist wrote: ↑Mon Dec 11, 2023 10:07 amWe don't have proper versioning of the boot protocol
No need, there's no difference. It's just a few checks if some fields are filled it or not, neither the workflow, nor the BOOT_LO structure changed in any way.
dunkaist wrote: ↑Mon Dec 11, 2023 10:07 amwe have quite a few of exotic loaderes that e.g. boot KolibriOS from DOS or Windows.
Again, not a problem because these just jump to biosboot code in the kernel, and they never jump to the protmode code.
dunkaist wrote: ↑Mon Dec 11, 2023 10:07 amTo remove these macros and build the universal BIOS/UEFI kernel image we should first go through all the BIOS loaders and make them to initialize the new BOOT_LO fields with some sensible values.
You don't have to do any of this if you keep biosboot in the kernel (for now at least).
I agree that removing biosboot and rewriting all loaders to come to a common ground with BOOT_LO is the way to go on the long term, but that's not what I suggesting here. I'm only suggesting a small step: keep biosboot, just add protmode entry to it at a fixed location. This way no matter what all those loaders do, because it's biosboot that initializes BOOT_LO on BIOS systems.
dunkaist wrote: ↑Mon Dec 11, 2023 10:07 amIn short, let's keep two separate images so far.
That's problematic, because KOLIBRI.KRN (the UEFI variant) has no header, so there's no way of telling that it is actually a KolibriOS kernel.
dunkaist wrote: ↑Mon Dec 11, 2023 10:07 amThere is a technical issue preventing unification that can be resolved in the future. I'm not ready to edit and test all the BIOS loaders at the moment, sorry.
Only if you about to remove biosboot, which I think you shouldn't. Maybe in the future when you're ready, but not now.
I believe having a unified kernel (with well detectable magic bytes) is very very important, and I'm offering my help to achieve that. Anything you need, I can provide you patches and I can test, just let me know what you need! I strongly believe this worth the effort, and I'm ready to sacrifice me spare time for it.
Cheers,
bzt
ps.: I'm glad to see that my uefi.inc was useful to you!