Protected Mode BIOS

[Tyler]

Would it be possibly to access the BIOS at location 0xF0000 once in protected mode using the original vector table locations and translating them into my protected mdoe address space?

Also does anyone know anything about the BIOS32 and if it is relocated at memory 0xF0000000 or was the information i read bad?

I already know how to use Video BIOS in protected mode as it proves code to move it and do so using VBE.. does the standard BIOS or any other BIOS chips provide this same functionality?

[Brendan]

Hi,

Would it be possibly to access the BIOS at location 0xF0000 once in protected mode using the original vector table locations and translating them into my protected mdoe address space?

For reading BIOS data, yes. For executing BIOS code (without emulation or virtual 8086 mode), no.

Also does anyone know anything about the BIOS32 and if it is relocated at memory 0xF0000000 or was the information i read bad?

When you first turn a modern computer on, there is no BIOS code/data at 0x000F0000. The CPU begins executing at 0xFFFFFFF0 (actually "0xFFFF000:0xFFF0" in real mode). The BIOS configures the chipset, copies itself to RAM at 0x000F0000, then tells the memory controller to treat the area at 0x000F0000 like ROM.

There is no architectural standard for what the BIOS ROM contains or how large it is. For e.g. it could be 2 MB and contain several different BIOSs in compressed form, where the best BIOS is selected (depending on which chipset or something) and decompressed into the memory at 0x000F0000. In this case the only code in this area would be initial chipset configuration code, and some decompression code.

I already know how to use Video BIOS in protected mode as it proves code to move it and do so using VBE.. does the standard BIOS or any other BIOS chips provide this same functionality?

I'm not aware of any device ROMs that provide any protected mode functionality (except for video cards). For the BIOS, most of it isn't designed for protected mode, but there are some extensions - APM (Advanced Power Management) and the "PCI BIOS" functions come to mind (there's probably some more).


Cheers,

Brendan

[JJeronimo]

When you first turn a modern computer on, there is no BIOS code/data at 0x000F0000. The CPU begins executing at 0xFFFFFFF0 (actually "0xFFFF000:0xFFF0" in real mode). The BIOS configures the chipset, copies itself to RAM at 0x000F0000, then tells the memory controller to treat the area at 0x000F0000 like ROM.

before configuring the chipset (or the North Bridge on old computers) it isn't possible to access RAM, isn't it?

Is it worth to reprogram the north bridge during the OS bootstrap? Is the interface uniform across diferent motherboards?

JJ

[Candy]

When you first turn a modern computer on, there is no BIOS code/data at 0x000F0000. The CPU begins executing at 0xFFFFFFF0 (actually "0xFFFF000:0xFFF0" in real mode). The BIOS configures the chipset, copies itself to RAM at 0x000F0000, then tells the memory controller to treat the area at 0x000F0000 like ROM.

before configuring the chipset (or the North Bridge on old computers) it isn't possible to access RAM, isn't it?

Is it worth to reprogram the north bridge during the OS bootstrap? Is the interface uniform across diferent motherboards?

It's unlikely that it's the same between versions of the same motherboard, let alone between different ones...

[JJeronimo]

before configuring the chipset (or the North Bridge on old computers) it isn't possible to access RAM, isn't it?

Is it worth to reprogram the north bridge during the OS bootstrap? Is the interface uniform across diferent motherboards?

It's unlikely that it's the same between versions of the same motherboard, let alone between different ones...

I'm already reading as thread (forum thread, not execution thread!) about that...

JJ

[Tyler]

Ok so assuming BIOS code is gone once in protected mode... is it standard practice to detect all devices and memory before entering protected mode or is there a simple call that can be done from protected mode?

[jcmatias]

To use bios services you need return to RM do the task and return to PM or LM. I had succes to do int 0x13 disk services. It´s slow and shoud have side efects that I don't detect but, nearly I will post a source here. (when well documented).
The basic concept is
1- trasnfer i\o data to predefined low memory address.
2 - tsave a PM state in a predefined low memory address
3 - call a 32 bits rotine inpredefined low memory address to return to
rm ( remap pic, change idt to rm idt, set segment register to valid
rm segments, disambe PM )
4 - jmp to rm predefined addres
5 - execute bios call
6 - restore PM state
7 - returm to PM
8 - transfer i\o data
ITs slow and I am not sure about secure but in my tests works fine.

[Brendan]

Hi,

Ok so assuming BIOS code is gone once in protected mode... is it standard practice to detect all devices and memory before entering protected mode or is there a simple call that can be done from protected mode?

It is standard practice to detect memory before entering protected mode.

For device detection it depends on how your OS does it - the BIOS doesn't really provide much useful information for this, except for ACPI (which is independant of processor mode), the Plug & Play BIOS functions (which have a 16-bit protected mode interface that should also work in long mode), and the PCI BIOS functions (which also has a 32-bit protected mode interface that should work in long mode). Of course there's also various problems with these interfaces.

The general idea is to use several hardware detection techniques, ranging from the best to the worst, and then allow manual configuration as a last resort for devices that can't be detected (e.g. something like "config.sys" for ISA devices that don't support Plug-n-Play).

To use bios services you need return to RM do the task and return to PM or LM. I had succes to do int 0x13 disk services. It´s slow and shoud have side efects that I don't detect but, nearly I will post a source here. (when well documented).

This technique can work badly on all machines and could even work acceptably on some machines in some situations for a while, but it's generally a bad idea for a number of reasons. The BIOS's code is designed for single-tasking, which works badly for a multi-tasking OS (e.g. a high priority task can be waiting for CPU time while the BIOS is wasting time waiting for an IRQ because some low priority task accessed the disk). For multi-CPU it's a nightmare.

There's also problems with IRQ handling. The basic problem is this part:

3 - call a 32 bits rotine inpredefined low memory address to return to
rm ( remap pic, change idt to rm idt, set segment register to valid
rm segments, disambe PM )
4 - jmp to rm predefined addres
5 - execute bios call
6 - restore PM state
7 - returm to PM

While these steps are executing your OS's entire interrupt handling is disabled. Consider devices like network cards, sound cards, serial ports, etc. For these devices the BIOS is useless, so your OS would have proper protected mode drivers. However, while you're running in real mode (e.g. for disk access) the BIOS would receive the IRQs for these devices that it knows nothing about. This means either lost IRQs (many devices locking up because an IRQ handler didn't send an EOI to the PIC) or messy hacks.

The first possible way is an IRQ handling system in real mode that catches these IRQs and sets "IRQ occured" flags, so that the IRQs can be handled correctly when the CPU returns to protected mode. The interrupt latency this introduces is intolerable. For example, imagine a 100 MHz ethernet card waiting a several seconds for it's IRQ to be handled because the BIOS is wasting time waiting for a floppy disk track to be formatted.

The other way is real mode IRQ handling stubs that switch back to protected mode so that those protected mode device drivers get their IRQs faster (plus more code to switch back to real mode if one of the BIOS's IRQs are received while this is happening). This is probably the best method possible, but it's also messy and doesn't completely fix things.

Lastly there's subtle race conditions caused by reprogramming the PIC - if an IRQ is received at the wrong time, can you guarantee that an IRQ won't be lost? Disabling IRQs with "CLI" won't help (that only stops the PIC from sending IRQs to the CPU, and doesn't stop devices from sending IRQs to the PIC).


Cheers,

Brendan

[Tyler]

Brendan... You wouldn't happen to know what sorts of devices Microsoft detects in Real Mode with its NTDETECT.COM program would you?... i am not out to emulate them in anyway but most answers are usually from the easiest toy os perspective and i was looking to do this in the "way it should be done" if you know what i mean.

[Brendan]

Hi,

Brendan... You wouldn't happen to know what sorts of devices Microsoft detects in Real Mode with its NTDETECT.COM program would you?... i am not out to emulate them in anyway but most answers are usually from the easiest toy os perspective and i was looking to do this in the "way it should be done" if you know what i mean.

I have very little knowledge of the internals of Microsoft OS's (except DOS I guess), but there's a Wikipedia page that contains some information about NTDETECT.COM...



Cheers,

Brendan