OSDev.org

I have seen lots tutorials; they both load the kernel from floppy. But i want load it from disk using LBA. Can i do this and how i do this?
Are there lots different from loading from floppy?
And there another problem bothered me a long time that can i load my kernel straight to 0x00000 where the start address of memory?
[/code]

Loading your kernel to 0x00000000 is a problem because important information is stored there (IIRC, it's the real mode IVT).

As for loading to hard disk, try reading up about MBR (master boot records) in the wiki. I don't know much about it though.

I have seen lots tutorials; they both load the kernel from floppy. But i want load it from disk using LBA. Can i do this and how i do this?

You see many tutorials on floppy because it's easier to implement. I think this is because there are no partitions on a floppy disk which makes it easier to implement a driver for it. And ofcourse you can load a kernel from a hard disk.

Following ways can do:

1) Write your own filesystem and IDE driver and load kerenl using it.
2) Use a precompiled Bootloader like Grub or Lilo and let them load you kernel into the memory.

Are there lots different from loading from floppy?

Yes there is. Harddisks are more complicated.

And there another problem bothered me a long time that can i load my kernel straight to 0x00000 where the start address of memory?

I never tried but I think that will have a conflict. You have many thing at 0x000000 like real mode IVT etc in that segment.

Loading your kernel to 0x00000000 is a problem because important information is stored there (IIRC, it's the real mode IVT).

yeah,it is.but if i rewrite the IVT.
I have seen the code of linux 0.11.it first load the kernel to 0x10000, then load it to 0x00000.Of course linus had the IVT rewritten.So i misunderstand, why linus didn't load it straight to 0x00000,Since he had the IVT rewritten.

negcit.K wrote:Can i load the kernel from disk?

Yes.

int 13h/02h for legacy (small) drives
int 13h/42h for modern (large) drives

When boot loader takes control ds:si contains pointer to active partition record stored by mbr loader.

On a hard disk is an MBR, as said above. This is different from a floppy. The BIOS just loads a bootsector straight off a floppy.

On a hard disk, the BIOS loads the MBR, and the MBR loads the bootsector. This is the main difference. There is one extra step. As said above, the MBR passes to the bootsector a pointer to the entry in the disk partition table, of the partition that got booted -- where the bootsector came from.

Other than that, the bootsector operates almost the same as it would when booting from a floppy. The INT0x13 command for reading the floppy can even be used for reading the hard disk. See the wiki: http://www.osdev.org/wiki/ATA_in_x86_Re ... %28BIOS%29

Memory:

The Real Mode interrupt table is in the first 1K of memory. You do not want to touch it. The next 256 bytes (0x400 to 0x4FF) is constantly modified by the BIOS. Anything you write to this memory will be destroyed. You can start putting things in memory at 0x500, if they will fit. Your bootsector code is running in memory at 0x7C00 (= 31K). And the partition table may be loaded just below that (it depends on the MBR, partition table = 66 bytes). So you have less than 30K of space right at the beginning of RAM. You are guaranteed that all the space between 32K and 512K is clear and usable. (32K = 0x8000, 512K = 0x80000). In Real Mode, that is all you should access. To move your kernel anywhere else, you need to switch into Protected Mode. You will eventually want to do this, but if your OS is just a hobby, you can wait, and just stay inside the 512K limit.

You mentioned Linux being at address 0. AFAIK this is not correct. But if it is, that is a "virtual" memory address -- not real memory. To use virtual addresses, you need to switch into Protected Mode, as said above. Once you switch into Protected Mode (or alternately, Unreal Mode) you can use all the memory on the computer (my computer has 256MB, for example).

bewing wrote:that is a "virtual" memory address -- not real memory. To use virtual addresses, you need to switch into Protected Mode

I misunderstand yet.
I just have seen the boot.s of linux0.01. It first loads system at 0x10000,then before getting into protected mode moves it down to 0x00000,and at last switch into protected mode.

And i have the file enclosured.

There's a reason that that was linux 0.01. It *will* have overwritten the IVT, but linus won't have worried about that at the time because his operating system never needed to use bios calls again after moving to protected mode.

This approach is not recommended.

negcit.K, save free the first physical page for all time and relax

I'm using the real mode boot loader with my strong kernel and that's all well:
0...0x3ff - IVT
0x400...0x4ff - BDA
0x500...0x7bff - boot loader's stack and data
0x7c00...0x7dff - first sector of boot block
0x7e00...07fff - any sector of boot block if needed or data
0x8000...AMT-1 - kernel file and one another (AMT=640 Kb or below; use int 0x12 for detection)

After initialization my kernel placed at the top of virtual user-space i.e. at 0x80000000 or above but physically it may be placed anywhere else.

negcit.K wrote:yeah,it is.but if i rewrite the IVT.
I have seen the code of linux 0.11.it first load the kernel to 0x10000, then load it to 0x00000.Of course linus had the IVT rewritten.So i misunderstand, why linus didn't load it straight to 0x00000,Since he had the IVT rewritten.

In realmode, the IVT is at 0000:0000. That's fixed, hardwired into the processor. Nothing you can do about it. After the IVT, there's the BIOS data area. Both are needed if you want to call BIOS interrupts. If you do not want to do that, you can move your kernel to 0000:0000 (after loading it somewhere else, as the loading needs the BIOS interrupts, just like Linux did).


JAL

jal wrote:In realmode, the IVT is at 0000:0000. That's fixed, hardwired into the processor. Nothing you can do about it.

It's simple to change IVT base. Just load IDTR with non-zero IDT base value.

It's simple to change IVT base. Just load IDTR with non-zero IDT base value.

Not in real mode.

JamesM wrote:

It's simple to change IVT base. Just load IDTR with non-zero IDT base value.

Not in real mode.

Apparently, it is:

The Manual wrote:8.6 Real-Mode Interrupt Control Transfers
In real mode, the IDT is a table of 4-byte entries, one entry for each of the 256 possible interrupts
implemented by the system. The real mode IDT is often referred to as an interrupt-vector table, or
IVT. Table entries contain a far pointer (CS:IP pair) to an exception or interrupt handler. The base of
the IDT is stored in the IDTR register, which is loaded with a value of 00h during a processor reset.
Figure 8-5 on page 230 shows how the real-mode interrupt handler is located by the interrupt
mechanism.

Combuster wrote:

JamesM wrote:

It's simple to change IVT base. Just load IDTR with non-zero IDT base value.

Not in real mode.

Apparently, it is:

The Manual wrote:8.6 Real-Mode Interrupt Control Transfers
In real mode, the IDT is a table of 4-byte entries, one entry for each of the 256 possible interrupts
implemented by the system. The real mode IDT is often referred to as an interrupt-vector table, or
IVT. Table entries contain a far pointer (CS:IP pair) to an exception or interrupt handler. The base of
the IDT is stored in the IDTR register, which is loaded with a value of 00h during a processor reset.
Figure 8-5 on page 230 shows how the real-mode interrupt handler is located by the interrupt
mechanism.

oooh, interesting.

JamesM wrote:oooh, interesting.

Indeed, one learns everyday.


JAL