Replies: 5 comments 7 replies
-
This would take too much time to make, IL2CPU adaptation, cosmos adaptation and so much other stuff, its more like a dream to have it |
Beta Was this translation helpful? Give feedback.
-
I don't think that UEFI support in Cosmos is a "dream" away from reality; the Limine bootloader already abstracts the majority of the communication you do with firmware interfaces - it's just that Cosmos still uses the Multiboot2 protocol. Cosmos isn't "bound" to BIOS, since we don't depend on BIOS once we exit 16-bit real mode. The only issue I can see is porting Cosmos to use bootloader-provided services rather than firmware interface-provided ones. This would mean that the VBE class would be thrown out, and instead the framebuffer provided by the bootloader would be used. Multiboot2 actually provides such a tag - it's the UEFI will not provide 64-bit support; BIOS is not the component that is holding Cosmos back from transitioning into 64-bit long mode. Structures like the GDT would have to be updated (simple), and all pointers would have to be converted to quad-words (not so simple, since Cosmos uses types such as However, for now, focus is more on cleaning and refactoring old code. There are major bugs in the current master branch that still need to be resolved before we start using bootloader-provided abstraction layers. |
Beta Was this translation helpful? Give feedback.
-
Wait, Cosmos uses VBE manually and not Multiboot2's framebuffer tag????!!!! |
Beta Was this translation helpful? Give feedback.
-
one day cosmos will move to UEFI but we have a lack of man power |
Beta Was this translation helpful? Give feedback.
-
Solved by #2828 |
Beta Was this translation helpful? Give feedback.
-
I think if use uefi, no graphic limit, no disk limit. Uefi can skip some part ‘Starting ACPI’, and can support 32, 64!
Beta Was this translation helpful? Give feedback.
All reactions