Booting to PMODE Approach

[indiocolifa]

Hi. I'm writing my kernel loader and I want to know what sequence is best to do hardware scan using the BIOS and switching to P-Mode. I'm aiming for the kernel to be put in the highest 1GB (3GB user mode / 1GB kernel).

1) Enable A20
2) Switch to PMODE
3) Create a V86 task to call BIOS (e.g: query memory map)

1) A20->PMODE->16-bit RM->BIOS->return to PMODE

1) Query BIOS, store data in low memory
2) A20
3) Switch to PMODE
4) Access BIOS data copied in 1)


Any ideas? I'm pretty confused at this point.

[AJ]

Hi,

I personally have a two stage boot loader system. The second stage starts of in real mode and gets the system memory map, enables A20 and then switches to PMode.

I switch back to real mode for loading disk sectors in the boot loader, ensuring that I preserve / backup any BIOS data I'm going to rely on later.

Cheers,
Adam

[CmpXchg]

I personally have a two stage boot loader system.

That's a great approach, I would advise to use it.

A20->PMODE->16-bit RM->BIOS->return to PMODE

Maybe query all data before switching to PMode, store it somewhere, then switch to PMode and never go back to Real Mode?

That's actually Microsoft Windows XP approach: second stage loader (ntldr) calls ntdetect.com to collect the hardware information, so the kernel (ntoskrnl.exe) gets started in protected mode with all the hardware information ready.

This way you can avoid all the V86 overhead.

I switch back to real mode for loading disk sectors in the boot loader, ... .

Why so? Why not to use INT13 to load your disk minidriver, and than rely on it, so you won't need to switch back to Realmode? What thinks indiocolifa?

Cheers,
CmpXchg

[AJ]

Why so? Why not to use INT13 to load your disk minidriver, and than rely on it...

Though theoretically possible, it is probably not a good idea. Most BIOS disk access will include IRQ handlers, DMA transfers (uncontrollable from within your VM monitor), and may stick in VM86 task while the BIOS waits for an interrupt response while a 'good' driver would have let the CPU free for other processes.

Windows 9x suffered from system freezing during disk access. Often due to an INT13-through-VM86 problem.

In my OS, the boot loader uses the BIOS for disk access via switching to real mode - this is to allow me to support any boot medium supported by the BIOS with a small boot loader executable size (I don't need to include separate drivers for FDD, SATA, PATA, ATAPI etc...).

Once the kernel is loaded, it uses native mode drivers for disk access. If I were to rely on v86 support here, it would be a problem for my long mode port.

Cheers,
Adam

[indiocolifa]

I personally have a two stage boot loader system.

That's a great approach, I would advise to use it.

A20->PMODE->16-bit RM->BIOS->return to PMODE

Maybe query all data before switching to PMode, store it somewhere, then switch to PMode and never go back to Real Mode?

That's actually Microsoft Windows XP approach: second stage loader (ntldr) calls ntdetect.com to collect the hardware information, so the kernel (ntoskrnl.exe) gets started in protected mode with all the hardware information ready.

This way you can avoid all the V86 overhead.

I switch back to real mode for loading disk sectors in the boot loader, ... .

Why so? Why not to use INT13 to load your disk minidriver, and than rely on it, so you won't need to switch back to Realmode? What thinks indiocolifa?

Cheers,
CmpXchg

Thank you very much, CXC for your reply.

My intention is to arrive to a very modular microkernel architecture, so I'm sure I should write some driver to access disk (i do not want to rely again on 16-bit RM disk access except on loading the disk driver).

My question is what this minimal driver should support and how it interfaces with the kernel at this stage.

[CmpXchg]

My question is what this minimal driver should support and how it interfaces with the kernel at this stage.

That's up to you to design

Once the kernel is loaded, it uses native mode drivers for disk access.

Ok, I see. How do you know if you are being booted from a harddrive, ATAPI, SATA etc. Is it necessary to create preconfigured images for each case? And finally, do you use classic INT13 or extended INT13?

Cheers,
CmpXchg

[AJ]

Ok, I see. How do you know if you are being booted from a harddrive, ATAPI, SATA etc. Is it necessary to create preconfigured images for each case?

My Boot Loader (still early stages) builds a fairly extensive hardware list, with the boot drive marked via a flag. The kernel is currently statically linked with drivers for ATA/ATAPI/SATA/FDD/USB. I hope to change this so that the boot loader loads the appropriate module, though. As the bootloader uses BIOS extensions, it doesn't need separate support for each version - it just has to support the appropriate filesystem.

And finally, do you use classic INT13 or extended INT13?

I detect whether extended int 13 extensions are available (via 41h) and have code for both, so that I can access across the whole HDD, where supported.

Cheers,
Adam

[bewing]

Once you get into Pmode, there is still a lot of initialization to do. I let a kernel init module handle all of that. Then I throw away the init module when the kernel is loaded and running. My single stage bootloader puts the kernel in low memory, and then the initialization stage of the kernel relocates the kernel.

My kernel insists that the E820 memory map must be supported, so I get extended INT13h support for free.

So the way my kernel boots goes like this:
1) bootloader is single stage, so it loads the rest of itself and relocates to 0x500
2) A20
3) Use extended INT13 to load/parse root directory and kernel into low mem
4) Call and store info from all the BIOS functions -- E820, PCI, Video, etc
5) Pmode
6) jump to kernel init code in low mem
7) decode memory map -- decide on final locations of all kernel structs
8) relocate only the non-init portion of the kernel to final physical address
Note: this is STILL running from low memory init code, below
9) allocate/init phys mem structures, data structures
10) PCI bus scan
11) media detection using statically linked, temporary, polling singletasking drivers (part of the init module that get thrown away) -- find the actual boot partition
12) allocate/init VFS structures
13) find the INIT program on the boot paritition and run it (still singletasking)
14) INIT loads and runs the scheduler -- turn on multitasking, load the appropriate multitasking drivers, load and run all the managers