OSDev.org

Uhm, I'm writing my own bootloader and now I've came up to this point where I need to load my kernel. At the beginning I saw only one option: writing ATAPI driver, because my laptop, on which I'll be testing my OS, is using it. I started reading ATAPI's docs, and it's so long, hard and boring, that I didn't have enough will to read it a few times. So I started searching for another solution and I came up with V86. But after a short research it became clear, that V86 is sometimes trouble maker and I should use it when it's really neccessary. And at the end, I still found out two solutions:

1. I'm not sure how fast it is, but some people do something like:
I. Load a piece of kernel using BIOS interrupts.
II. Jump to protected mode and copy it.
III. Jump back to real mode and do everything again, until you load it.

This seems kind of slow, but at least it works.

2. And... another one solution. I've never seen someone using it, but I hope at least someone heard about this method (or even used it) and could tell me if it works. The idea is simple: I could use unreal mode with A20 line enabled. Unreal mode consist of breaking the '64Kb' limit of real mode segments, but still keeping 16 bits instruction and segment*16+offset address formation by tweaking the descriptor caches. So I could use BIOS interrupts and load the kernel above 1MB and then go back to protected mode.

So, guys, if anyone has ever used or heard of these methods, please, tell me your opinion about them, which one is better, what have you heard/experienced with them and if it's worth using one of them.

This seems kind of slow, but at least it works.

Moving around stuff in ram goes in the order of gigabytes per second. You're not going to notice that when actually getting the data from the CD is a hundred times slower

So I could use BIOS interrupts and load the kernel above 1MB

Passing an address over 1MB to the BIOS is known to get occasionally truncated by some BIOSes. Hence there's always a copy needed to be safe.


What I do is just dumping everything I might need into ram (essentially building a ramdisk at 2MB with brief protected mode jumps), only then to leave for the kernel and never enter real mode again.

From my experience, although I worked on usb stick, the load time is dominated by the time for getting stuff from the media.
The time for switch to p.mode, copy, back to real mode is insignificant.

For 1MB of data (I purposely put a bmp file to make it huge), my first version take about a minute to load, then I implement some kind of cache for the super-block, and the time reduced to few seconds, I guess that's how fast the BIOS can do using PIO.

Okay, from what I've understood, these methods are fine and I can use them to load my kernel .

P.S. (a little off-topic) @bluemoon: I've heard that USB documentation is really not-well documented. Was it hard to implement USB support? How is the document? Is it really that not-well documented?

I don't have USB support yet, my boot loader uses BIOS's emulation.
Anyway, USB is well documented, but its a bit more complex than other drivers you may do in the early development stage (ie. keyboard, mouse, video, network card and pci). The usb specification is also differ on each version (1.0, 2.0, 3.0) and speed modes, and the hot plug nature adds extra complexity on the driver architecture design.