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.
Loading the kernel from CD
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: Loading the kernel from CD
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 slowerThis seems kind of slow, but at least it works.
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.So I could use BIOS interrupts and load the kernel above 1MB
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.
Re: Loading the kernel from CD
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.
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.
Re: Loading the kernel from CD
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?
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?
Re: Loading the kernel from CD
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.
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.