OSDev.org

I wrote:BIOS must use unreal mode. My desktop with BIOS has ACPI reclaim memory above 0xC0000000. So, BIOS had to put it there. So it went into unreal mode.

Still waiting for a response to this

nexos wrote:Still waiting for a response to this

Unfortunately it doesn't fit Bzt's idea of what the world should be.

bzt wrote:They are pretty clear that BIOS must use real mode, and in addition BBS allows 16-bit protected mode for Option ROMs, but that's it. No 32 bit protected mode, therefore no addressing above 1M in BIOS. (Of course a ROM code can switch to protected mode and access memory above 1M, but then you can't call that standard IBM PC BIOS)

BIOSes aren't the best at holding standards. I am sure BIOSes break these specs. Also, from Wikipedia:

The size of the BIOS, and the capacity of the ROM, EEPROM, or other media it may be stored on, has increased over time as new features have been added to the code; BIOS versions now exist with sizes up to 16 megabytes. For contrast, the original IBM PC BIOS was contained in an 8 KiB mask ROM.

BIOS exceeds the 1M mark .

bzt wrote:Now you're just trolling.

Tell me how Octocontrabass was trolling. He was just telling the truth.

bzt wrote:Look, if you are fool enough to think that UEFI is not overcomplicated and it's simpler and slimmer than BIOS, so be it! It's on you.

BIOS is an un-standardized mess. It makes bootloader development complicated. It can also be just as bloated as UEFI.

nexos wrote:

I wrote:BIOS must use unreal mode. My desktop with BIOS has ACPI reclaim memory above 0xC0000000. So, BIOS had to put it there. So it went into unreal mode.

Still waiting for a response to this

As I have said, not everything that's in ROM is part of the BIOS. Neither is ACPI. ACPI is independent to BIOS and UEFI, accessible under both. (If you don't believe me, just check if you can use ACPI without legacy CSM under UEFI. Hint: you can.)

nexos wrote:It makes bootloader development complicated.

How? All you need is an Assembler (actually any Assembler will do: nasm, fasm, masm, tasm, gas, you name it). UEFI EDK is a bit more complex, you can't use just any C compiler, and UEFI ABI compatibility isn't trivial either.

Under UEFI there are at least 3 different and incompatible protocols (!) to load something from disks. On the other hand, you can put all your money on that BIOS interrupts used by Microsoft boot sectors and OS loaders are available and 100% compatible on every single BIOS machines!

nexos wrote:For contrast, the original IBM PC BIOS was contained in an 8 KiB mask ROM.

No comment. That's what I was saying all along. Show me any UEFI implementation that slim!

nexos wrote:Tell me how Octocontrabass was trolling.

He was complaining about a service that's accessible from real mode only.


Just for the records, I'm talking from experience, and you don't have to convince me to write an UEFI loader. I've already did that. BTW once the kernel gets control, nobody cares about the boot environment any more, it's totally irrelevant (you can't use UEFI and you won't use BIOS services).

For me this conversation is over. If you can't see the truth after all of this, then believe what you want to believe; not everybody is ready to be awaken from the Matrix

Have a nice day,
bzt

I would never predict that a simple factual correction would escalate into further pointless arguments! Anyway, even though bzt has said that the conversation is over, I'll try to clear some things up and provide a little more context, given that I have experimented a little bit with BIOS development (didn't get very far though).

bzt wrote:And that's true. Look it's plain simple: BIOS uses real mode. You simply cannot address more than 1M memory in real mode. 0 to 10FFF0 (1M+64k-16) to be exact. In that address space, there's only that much ROM, no more.

Normally, you indeed can access slightly more than 1M in Real Mode, that is 0x00000000-0x0010FFF0 (which is correct if the A20 is enabled, which it should be anyway). Except that, as nullplan said, the reset CS.Base is 0xFFFF0000, so by using the CS segment you can access from 0xFFFF0000 to 0xFFFFFFFF and the reset address is 0xFFFFFFF0. I know this is somewhat confusing given that CS.Base can not be set without loading another GDT, which is not the normal way of setting segments in Real Mode. However, this is done automatically on reset by the processor circuitry, just like setting IP=0xFFF0, and no instruction is needed for either. If you reload the CS segment without loading another GDT first, it will be switched to regular Real Mode operation, else it will be switched to the regular or irregular operation that you specified in the GDT. This is also the reason Unreal Mode works.

Depending on the chipset, there are several megabytes at the end of the 32-bit address space reserved for the ROM. For example, in the Intel 945 Mobile family of chipsets (which the aforementioned ThinkPad T60 uses), there are 2M reserved for the ROM, that is 0xFFE00000-0xFFFFFFFF. See also the datasheet, section 9.3, figure 13, page 327. Interestingly, the same range is reserved for the ROM in the Intel 440FX chipset, which was released in 1995, and I imagine that BIOSes were much smaller in 1995 than in 2006. But apart from the "real" ROM mapping at the end of the address space ("real" is not to be confused with Real Mode), old chipsets can also map the respective regions of the BIOS to 0x000C0000-0x000FFFFF. However, in newer chipsets that indeed are designed for UEFI, there might not be any ROM mapped to any subregion of 0x000C0000-0x000FFFFF and BIOS "shadowing" is necessary in order to maintain compatibility with legacy requirements.

At the reset vector, the BIOS usually invalidates the caches through the WBINVD instruction, then it jumps to a predetermined at build time address inside the last 64k of the address space. Typically, after the jump, there is some basic processor initialization stuff done, and then a 32-bit GDT is loaded, again from some address inside the upper 64k. All such accesses and references in the upper 64k are done using the CS segment with a regular 16-bit offset. There is however an interesting quirk when loading the GDT. Since the 16-bit LGDT instruction only understands 24-bit addresses (by setting the higher 8 bits to zeroes), a 0x66 operand prefix is required so the GDT base address actually is 0xFFFFxxxx and not 0x00FFxxxx.

Now with the GDT loaded, a switch to protected mode is done in the same way as we do in our bootloaders. The segments are subsequently initialized, and the BIOS goes on to initialize some more things before starting the chipset initialization. Note that there is no main memory accessible before the chipset has been properly initialized, so there isn't much that can be done at this point (though it's standard practice to temporarily use the CPU caches as memory).

During chipset initialization, which is done by tweaking the PCI registers of chipset, the DRAM is initialized. After that, it's typical to "shadow" the BIOS to 0x000C0000-0x000FFFFF, with the reasons being that DRAM access is a lot faster than flash access and that some chipsets don't even support mapping the legacy BIOS range to the actual ROM. For chipsets that support this mapping, the "shadowing" is achieved through using the "Programmable Attribute Map" PCI registers, 13 of them in total, each controlling a different subrange of 0x000C0000-0x000FFFFF. For example, the 0x000F0000-0x000FFFFF address range is controlled through PAM0. The Intel 440FX datasheet also has an example how to "shadow" the BIOS to main memory with the PAMs. However, irrespectively from whether the BIOS is or isn't shadowed, these PAMs still need to be assigned at this point, unless there is evidence that both RE and WE have a defined default state, which I'm not aware of, and that this default state is indeed what we want.

After this point, the BIOS can happily use the main memory and initialize the system further. Finally, when it needs to interact with the bootloader, it switches to Real Mode as this is the mode that the bootloader expects. After such interactions, it returns to Protected Mode so it can execute other parts of itself, presumably implemented with 32-bit code.

Note that I have mostly looked at 32-bit Intel chipsets. Unfortunately, the introduction of 64-bit Intel chipsets (specifically the Intel 965 series) "coincided" with the introduction of the Intel Management Engine (then called the Manageability Engine if you want to search for it in the Intel 965 datasheet). The Intel Management Engine makes it practically impossible to write a custom (non-approved) BIOS without any proprietary blobs and, even then, it might not always work (Coreboot does, in fact, include proprietary blobs and still doesn't work everywhere). Thus, my interest in Intel 965 and later is very minimal.

Irrespectively from all of this, a BIOS can in fact be smaller than UEFI and it usually is. But I still wouldn't say that the BIOS is necessarily better. In my opinion, both are awful, but that's what we have/had on most personal computers, servers, etc. Thus, unless we are going to design a BIOS/UEFI/Coreboot replacement and successfully install it on at least 5% of all existing x86 computers as well as make it one of the de-facto standards, I too think that further discussion in this topic is pointless, unless it consists of actually informative posts (like this one, I hope) and not flaming (like most other posts in this topic).

testjz wrote:Depending on the chipset, there are several megabytes at the end of the 32-bit address space reserved for the ROM. For example, in the Intel 945 Mobile family of chipsets (which the aforementioned ThinkPad T60 uses), there are 2M reserved for the ROM, that is 0xFFE00000-0xFFFFFFFF.

And? Why is it so difficult to understand that ROM is not the same as BIOS? There are many other things stored in the ROM which aren't BIOS. For one, there are sound cards which store wave samples in ROM (or at least I know for a fact that some old GUS cards did that).

The ThinkPad T60 series that you have mentioned has a built-in support software in ROM, which has nothing to do with the BIOS, yet it resides in the ROM.

You also can use the ThinkVantage button to interrupt the startup sequence of the computer and start the Rescue and Recovery workspace, which runs independently of the Windows operating system and is hidden from the operating system

Once after a short blackout I had the chance to see an ATM booting OS/2 where the entire OS image was located in ROM (I saw on the BIOS screen that there were no HDDs at all, and I haven't seen a PXE booting screen either, and the whole OS booted up amazingly fast, lot faster than what BNC network cards were capable of at that time).

I've also heard rumours that a special version of Windows was capable of booting from ROM, used by the military on machines controlling radar stations. I haven't seen that with my own eyes, but I trust the source and I believe that's true.

Finally, UEFI also stored in ROM, which isn't BIOS either (there's lot more to UEFI than legacy CSM).

Cheers,
bzt

Indeed the ROM contains more stuff apart from the BIOS. Are we really just arguing about this?

That said, given there are more standards to be supported now that in the 1980s or the early 1990s, standards for both devices and interfaces, I'd still question whether the BIOS can today fit in just 128k. If I had a working computer with an actual BIOS that is not UEFI CSM, I'd maybe try to inspect its ROM. Or maybe a fellow member would do it, I don't know. But it really doesn't matter at this point.

I tried to be informative in the last post, but it turned out to further the fight. So, I'm dropping it too.

testjz wrote:I'd still question whether the BIOS can today fit in just 128k.

Exactly. The original IBM PC had no PCI bus, no AHCI controller, no ACPI, no complex chipset with I/O APIC and PCI IRQ routing. The BIOS sets all that up. I would assume BIOS would have maybe the initial portion in low memory, and then have an expanded portion in memory above 0xC0000000. This discussion is getting nowhere, however.

I made a sort of resolution to this issue, by creating this page:

https://wiki.osdev.org/Porting_to_UEFI

which directly mentions the legacy Bare Bones, and informs on how to port to UEFI.

nexos wrote:I renamed UEFI Bare bones to UEFI App bare bones just now, and started a UEFI bare bones with BOOTBOOT and GRUB. It can be found at https://wiki.osdev.org/User:Nexos/UEFI_Bare_Bones

I don't understand. If you're using an external bootloader, what about this is UEFI-related? I mean, won't GRUB or BOOTBOOT prepare the system to much the same state as they would from a BIOS boot?

eekee wrote:I don't understand. If you're using an external bootloader, what about this is UEFI-related? I mean, won't GRUB or BOOTBOOT prepare the system to much the same state as they would from a BIOS boot?

Quote from the new wiki page: Porting to UEFI

Changes

Most UEFI implementations do implement compatibility with legacy BIOS in the form of CSM (compatibility support module), so you may not need to make your OS UEFI compatible. Just note that not all machines may support CSM and therefore it may be worth it to make your OS UEFI capable.

However, one breaking change that will definitely affect your OS is that UEFI does not support traditional CGA text mode. You are required to use graphics mode, and there is no text mode emulation in place.

Here are a few mandatory changes for legacy-BIOS OSes:

- You will need to write your own (new) terminal driver that uses bitmap fonts to draw text onto the screen.
- You will need to request a graphical framebuffer from your bootloader.

foliagecanine wrote:

eekee wrote:I don't understand. If you're using an external bootloader, what about this is UEFI-related? I mean, won't GRUB or BOOTBOOT prepare the system to much the same state as they would from a BIOS boot?

Quote from the new wiki page: Porting to UEFI

I think there's a little misunderstanding here. What you quoted, refers to the steps needed when you write your own loader from scratch. On the other hand @eekee was talking about using an existing bootloader, like GRUB or BOOTBOOT (which have already implemented the things listed in the quote).

The point of using an existing solution is that you don't have to care about firmware-specific stuff, but you can rely on a specific state regardless to the firmware. The BOOTBOOT protocol was designed to be that way in the first place, and there's a subset of Multiboot configurations that can be loaded with GRUB on both legacy BIOS and UEFI machines.

Cheers,
bzt

In either case, the main difference is you won't have access to text-mode, so you'll have to get a graphical framebuffer from (in this case) the bootloader.
If you are already independent from the text-mode and don't drop into real mode to do any BIOS stuff, there's not much else needed to change.