Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
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?
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.
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) )
OS-LUX V0.0
Working on...
Memory management: the Pool
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
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.
If you have seen bad English in my words, tell me what's wrong, please.
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.
)
).
if gate A20 is enabled.
