OSDev.org

bzt wrote:

By 2020, Intel will be only supporting UEFI Class 3, which means no legacy support of CSM compatibility.

(Some manufacturers still might ship UEFI with CSM option, but that's not mainstream any more as of 2021)

Cheers,
bzt

Have mixed feelings on this, I see the perspective that Intel needs to conserve resources (money) as it isn't doing too fantastic as a business these days.

But self-crippling your platform while everyone is more or less looking forward to embrace the all-mighty new king named aarch64? Sounds like the a surefire way to perish as a viable business a few years or decades earlier.

But I'm sure of one thing, I won't be buying more products from someone who "purposefully" make the life of writing a hobby OS harder than it already is.

xeyes wrote:But I'm sure of one thing, I won't be buying more products from someone who "purposefully" make the life of writing a hobby OS harder than it already is.

Using UEFI to boot your OS is no more difficult than using the BIOS. It is different, but the amount of work and complexity is similar.

kzinti wrote:

xeyes wrote:But I'm sure of one thing, I won't be buying more products from someone who "purposefully" make the life of writing a hobby OS harder than it already is.

Using UEFI to boot your OS is no more difficult than using the BIOS. It is different, but the amount of work and complexity is similar.

It's not about boot, but about text mode

On the other hand, I heard that ARM also uses UEFI, one less incentive to use x86.

Let me put this a bit more blatantly, by dropping CSM, Intel is more or less turning x86 platform from

"a platform that has its quirks but also comes with over four decades of history and fond memories as well as easily obtainable/widely published know-hows"

into

"a platform that is less powerful in absolute terms, less efficient in relative terms, being ditched by leading system vendors, and also has the exact same limitations"

About two decades ago AMD saved x86 from a similar move by Intel.

Remember the "let's emulate 32bit and move to the awesome 64bit Itanium (under the table: let's then drop the emulation to force a pure 64bit world)" days?

Would history repeat itself?

I think you are conflating many unrelated things together here.

I personally couldn't care less about that text mode going away. It is obsolete and not that useful. But I can see how it can help beginners get started...

kzinti wrote:

xeyes wrote:But I'm sure of one thing, I won't be buying more products from someone who "purposefully" make the life of writing a hobby OS harder than it already is.

Using UEFI to boot your OS is no more difficult than using the BIOS. It is different, but the amount of work and complexity is similar.

Not really. With BIOS you could boot something using hand-coded assembly without any tools at all. With UEFI, you need a C compiler that can produce the PE executable that UEFI needs. Which essentially means you need a Linux box or an Unix-like environment under Windows, like cygwin. Forget about hand-coding assembler code to get something to boot.

Additionally, all modern UEFIs boot you up into long mode with paging enabled. BIOS will boot you up in real mode without any paging. If you are not writing a long mode OS, you need to provide a long mode stub that turns-off long mode and goes back to protected mode.

Another issue is that some OSes can turn-off the posibility to boot anything except the preloaded OS with UEFI using the "secuity features" which are better described as "lock-down features".

kzinti wrote:I think you are conflating many unrelated things together here.

I personally couldn't care less about that text mode going away. It is obsolete and not that useful. But I can see how it can help beginners get started...

I personally care and don't support decisions that make the entry point too high and turn potential beginners away

But I can see how someone couldn't care less as long as it doesn't break his/her stuff (yet).

xeyes wrote:

kzinti wrote:I think you are conflating many unrelated things together here.

I personally couldn't care less about that text mode going away. It is obsolete and not that useful. But I can see how it can help beginners get started...

I personally care and don't support decisions that make the entry point too high and turn potential beginners away

But I can see how someone couldn't care less as long as it doesn't break his/her stuff (yet).

Right. Text mode is much easier to use than a linear frame buffer, and so will turn away beginners. It's not trivial to create characters with a linear frame buffer. Also, there is a large amount of different configurations and UEFI is not required to support any particular organization. Text mode is well defined, the buffer is always at B8000 and it always has 25x80 characters.

rdos wrote:

xeyes wrote:

kzinti wrote:I think you are conflating many unrelated things together here.

I personally couldn't care less about that text mode going away. It is obsolete and not that useful. But I can see how it can help beginners get started...

I personally care and don't support decisions that make the entry point too high and turn potential beginners away

But I can see how someone couldn't care less as long as it doesn't break his/her stuff (yet).

Right. Text mode is much easier to use than a linear frame buffer, and so will turn away beginners. It's not trivial to create characters with a linear frame buffer. Also, there is a large amount of different configurations and UEFI is not required to support any particular organization. Text mode is well defined, the buffer is always at B8000 and it always has 25x80 characters.

Exactly, this might escape the memory of highly experienced folks who has a stable hobby OS for a decade or more.

But the possibility of direct visual feedback (characters, even short strings) via a few store (mov) instructions is very valuable during the early stages where the OS can hang or crash at any moment. It works with or without paging, works with or without protected or long mode, works with or without compiling or linking against complex C functions/libraries.

It just works, and works reliably, when one need it the most

rdos wrote:Text mode is well defined, the buffer is always at B8000 and it always has 25x80 characters.

Maybe I did understand you wrong, but I think there is 80x50, too.

Greetings
Peter

xeyes wrote:What does "don't use the BIOS on screen" mean though?

If you use INT 0x10 to output text, you have to tell the BIOS when you've set up an unusual video mode so it knows how to put text on the screen correctly. (Although it depends on the INT 0x10 handler being fully IBM-compatible, which is asking a lot from modern PCs...)

rdos wrote:Text mode is well defined, the buffer is always at B8000 and it always has 25x80 characters.

Not always! Those are just the default settings that the BIOS will usually set for you. You can always ask the BIOS to set up a different text mode, or poke the VGA registers to do it yourself, or go digging through a junk pile for one of the museum pieces that boots with a different text mode by default.

Octocontrabass wrote:

xeyes wrote:What does "don't use the BIOS on screen" mean though?

If you use INT 0x10 to output text, you have to tell the BIOS when you've set up an unusual video mode so it knows how to put text on the screen correctly. (Although it depends on the INT 0x10 handler being fully IBM-compatible, which is asking a lot from modern PCs...)

Using BIOS int 10 is not as simple as just writing the characters into the buffer, and also doesn't work once you have left real mode or have done other stuff that makes it non-functional.

Octocontrabass wrote:

rdos wrote:Text mode is well defined, the buffer is always at B8000 and it always has 25x80 characters.

Not always! Those are just the default settings that the BIOS will usually set for you. You can always ask the BIOS to set up a different text mode, or poke the VGA registers to do it yourself, or go digging through a junk pile for one of the museum pieces that boots with a different text mode by default.

I've been into this since the late 80s, and I've not yet seen a PC that boots with BIOS and doesn't have the 25x80 mode as default. The only exception is that a momochrome adapter will be at B0000 instead, which once was useful for debugging with two monitor solutions. So, to be really sure something is displayed, write it to both B0000 and B8000.

Besides, even if the resolution isn't 25x80 you can still show a short message by writing to the beginning of the buffer.

kzinti wrote:Using UEFI to boot your OS is no more difficult than using the BIOS. It is different, but the amount of work and complexity is similar.

I would strongly disagree and so would many other programmers, like Linus for one

Some facts to back up:
You can write an ELF loader for BIOS in less than 512 bytes, knowing that everything above 1M is free, and loading is as simple as calling an interrupt where paramter 0x80 is the disk. Installing requires writing one sector to the disk.
You simply cannot do that with UEFI: requires locating f*d up interfaces, handling god-knows what protocols (ImageHandle -> LIP -> SFS -> IOVolume ->DeviceHandle) just to get how your disk can be referred to, memory above 1M is not guaranteed to be free, so you must figure out if UEFI haven't allocated the ELF's memory already, exiting Boot Services etc. etc. etc. The result is a LOT bigger than 512 bytes and installing it is a lot more problematic than just updating a sector, and it can blow up 100x times more ways.

Another simple test: compare a BIOS E820 memory map with an UEFI memory map, and see how much more fragmented it is and how much more memory wasted!

xeyes wrote:What does "don't use the BIOS on screen" mean though?

Don't use BIOS interrupts to print to screen. @Octocontrabass summed up the issues with that pretty nicely.

rdos wrote:Text mode is well defined, the buffer is always at B8000 and it always has 25x80 characters.

Put aside that you can use more coloumns and rows, the address isn't always B8000 either. It is typically B0000 for monochrome modes, but you can also configure it yourself with the VGA registers. It was a quite common practice to change the address when the CRT beam reached a certain scanline, that's why most DOS games have a vertical status bar at the bottom of the screen.

Cheers,
bzt

rdos wrote:I've been into this since the late 80s, and I've not yet seen a PC that boots with BIOS and doesn't have the 25x80 mode as default.

I did say "museum pieces"! Most folks wouldn't want to configure their EGA to boot in 40x25 text mode, although that was supposedly possible. (One of these days I'll find the right hardware and see for myself.)

rdos wrote:The only exception is that a momochrome adapter will be at B0000 instead, which once was useful for debugging with two monitor solutions.

If you installed a CGA and a VGA in the same PC, the VGA would be the monochrome adapter. This even works with some PCI SVGA cards!

bzt wrote:memory above 1M is not guaranteed to be free, so you must figure out if UEFI haven't allocated the ELF's memory already,

Or set up the page tables to put the kernel directly into its desired higher-half virtual address.

bzt wrote:You can write an ELF loader for BIOS in less than 512 bytes, knowing that everything above 1M is free, and loading is as simple as calling an interrupt where paramter 0x80 is the disk. Installing requires writing one sector to the disk.
You simply cannot do that with UEFI: requires locating f*d up interfaces, handling god-knows what protocols (ImageHandle -> LIP -> SFS -> IOVolume ->DeviceHandle)

Imagine that... using a different firmware requires you to use a different APi. Who would have thought?

bzt wrote:memory above 1M is not guaranteed to be free, so you must figure out if UEFI haven't allocated the ELF's memory already, exiting Boot Services etc.

How is that relevant to anything? Who cares where you bootloader is loaded in memory? It doesn't matter.

bzt wrote:The result is a LOT bigger than 512 bytes and installing it is a lot more problematic than just updating a sector, and it can blow up 100x times more ways.

I am not sure what you are doing (or trying to do) here. But when I want to update my bootloader I just copy the file where i want it on the partition and it works just fine. I assure you files bigger than 512 bytes are no problems. There is nothing "problematic" here about anything.

bzt wrote:Another simple test: compare a BIOS E820 memory map with an UEFI memory map, and see how much more fragmented it is and how much more memory wasted!

That is not my experience. The UEFI memory map looks very much like the BIOS one. That is until you start doing dynamic allocations: it will create entries in the memory map to remember the memory you allocated. This is useful: you get dynamic memory allocations for your bootloader, something that doesn't even exist with the BIOS.

Sounds like all your complaints are about UEFI not being BIOS or POSIX. Well guess what... it's neither and it's not trying to pretend to be. Just use UEFI the way it was meant to be used and a lot of your difficulties will go away.

xeyes wrote:But I'm sure of one thing, I won't be buying more products from someone who "purposefully" make the life of writing a hobby OS harder than it already is.

I don't think you understand something: none of the chip manufacturers want to support hobby OS devs, period. Not even the SOC producers for single-board maker equipment - hell, especially them, given how reticent many of them are in giving out documentation (I'm looking at you Broadcom, though they aren't the only ones). If Intel, AMD, and the various ARM manufacturers could lock everyone out and only have to deal with Microsoft or Apple for system software (preferably only one of them, it doesn't matter which), they would have done so by now, and a shift away from x86 for the (already flagging even given the recent boom in home use) desktop market could be just the opportunity for them to try doing that.

So why haven't they done so? Basically, they haven't seen a reason to do so. They tolerate Linux (and to a lesser extent, FreeBSD and the various RTOS products such as QNX or eCOS) as a fait accompli, and even then only because of its position in the server and embedded markets - and because it costs them nothing to do so.

Hobby OS devs don't even show up on their radar. At all. To the extent they are aware of us, they see us as nuisances to be quashed.