Hi,
Tyler wrote: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).
jcmatias wrote: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:
jcmatias wrote: 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
