OSDev.org

Hi to all.

I have a (design?) question. I have done this so far:

• Bootloader that reads (from FAT formatted disk) second stage
  Second stage reads kernel from disk
  Enable A20
  Enter protected mode
  Move kernel to 0x100000
  Jump to kernel

My question is, after kernel is running (in protected mode), how can it read modules, drivers (or any other data) from hard disk?
int 0x13 isn't available, is it?

Or can I access address 0x100000 in real mode?

Hi,

If you're intent on having your ATA driver in a module (as I do), you can group a clump of modules together and have them loaded as a (GRUB-parlance) 'module' alongside your kernel. The kernel can then read this 'module', and load every module it finds in there.

A real-life example - all of my kernel modules get tarred up (standard GNU Tar format), then that file gets loaded alongside the kernel. The kernel knows where it is (GRUB passes its address on X86, my bootloader passes its address on other architectures), and it knows how to access a Tar file. It then loads each file it finds as a module. This is how my ATA driver gets installed.

A similar method is used by many!

Hope this helps,

James

posman wrote:My question is, after kernel is running (in protected mode), how can it read modules, drivers (or any other data) from hard disk?
int 0x13 isn't available, is it?

Or can I access address 0x100000 in real mode?

Do what JamesM said. You can load the 'module' under 0x100000 in Real Mode, or you can enter Unreal Mode to load it above 0x100000. A third solution is the GRUB way of shifting between Protected Mode (to access all memory) and Real Mode (to access BIOS functions).

If I were you, I'd make some progress on the kernel(Timing done, at least!) before loading modules. Besides, you do need an interrupt handler before you can create a basic kernel-mode ATA driver.

Well... you could have your bootloader load the modules as said before, but honestly, who'd do that? (If your second stage bootloader is in asm, its more assembly for you(and it probably means switching between protected and real mode a few times) )

Hi,

cr2 wrote:Well... you could have your bootloader load the modules as said before, but honestly, who'd do that? (If your second stage bootloader is in asm, its more assembly for you(and it probably means switching between protected and real mode a few times) )

It's not more work to do it this way, because the kernel will need the other code, modules, etc sooner or later anyway (unless it's for a diskless headless system with no networking ).

The basic idea is to load everything you need into RAM during boot, so that it's already in RAM when the kernel/OS needs it to access file systems and/or network.


Cheers,

Brendan

Its more work to do it in ASM.

P.S. You might want to move "Cheers,\n\nBrendan" into your signature.

Dear Cr2,

RE: Kernel Modules

For a modular micro-kernel, I'd be tempted to put timing and PIC/APIC handling in separate modules; so that the correct module can be selected by the boot code after auto-detection. That way you'd only have HPET code if HPET is present, and only have I/O APIC code is I/O APICs are present, only have x2APIC code if x2APIC is present, etc; and if some strange embedded device has it's own unusual timer or interrupt controller you'd only have to write a new module to support it.

If you take this approach for everything, you'd end up with a highly flexible configurable kernel with very little bloat and with no need for end-user configuration; but, you'd need to be able to load modules from RAM during boot before any of the kernel is actually working (as almost everything in the kernel would be modules).


Yours Sincerely,

Brendan Trotter

My bootloader loads kernel and boot device & file system driver into base memory from the root of boot device. The kernel moves self and driver to their customary position during initialization and runs the driver later for loading other modules.

posman wrote:Or can I access address 0x100000 in real mode?

No, but you can in unreal mode (check the wiki). The BIOS functions will not access any high memory (regardless whether you are in real or unreal mode), but you can load, then copy to high mem.


JAL

The range 0x100000-0x10FFEF is available in real mode on i286+ if gate A20 is enabled.