boot my kernel from HD

[blackoil]

Hi,

I want to boot my kernel from HD.
The code space in partition boot sector is 420 bytes left in FAT32,
Is it enough to enter protected mode, load FAT table & load the kernel?

[Merdini]

You could reduce the code a lot if you didn't load the kernel through the fat table.
If you know which sector(s) the kernel is in, you can just read the sector(s) with int 13h instead of searching for it.

[AJ]

Hi,

I'm not the best assembly coder, but that sounds like a lot for 420b, even with basic FAT read support. A more skilled asm coder may beg to differ.

Having said that, you could reserve more than one sector for your boot loader (reserved sectors in the BPB). The boot loader then loads its additional sectors before doing anything else, giving you more space in which to achieve FAT32 reading + A20 enabling + the PMode switch.

The main disadvantage of this is that you will always need to reformat the disk to install your boot loader, whereas a one sector bootloader could just be written to the start of a preformatted disk ( / image).

Cheers,
Adam

[Love4Boobies]

It cannot be done, at least not properly.

Your tasks (in no specific order):

• Detect whether you're using the conventional INT 13h interface or EDD
• Implement the reading routines (note that EDD will also need space for a packet; if you choose to have the packet outside the sector, you will still need instructions to modify the packet)
• Detect FAT type, parse it, find the kernel file
• Enable the A20 gate
• Jump to protected mode (or unreal, then protected)
• Handle errors (was the kernel found? did reading work?)

I'd go with what AJ suggested.

[Ferrarius]

Most (all) major bootloaders easily use 63 sectors following the MBR, grub even has a 3 stage system (stage 1, stage 1.5 and stage 2). There's no shame in suing up to 32K so just do it

[Love4Boobies]

Yes but using C is a big part of why they take up so much space. And GRUB does a lot more than what the OP asked (even if it does that poorly and even if it goes the extra mile to do stuff that no one even wants) - I'd say it's more then feasible in 2 sectors written in assembly.

[Ferrarius]

Even if you do it in one sector, it's never a bad idea to reserve some space for future additions.

[blackoil]

I think it's best to use reserved sectors to store initialization codes

[Love4Boobies]

Even if you do it in one sector, it's never a bad idea to reserve some space for future additions.

Meh, you could just reserve them when you need 'em... perhaps you never will.

[blackoil]

I figured out a idea to load kernel from HD easily.

Usually HD cluster is 4096bytes, there is enough space for enter PE, load fat table & kernel.

Design two stage kernel files,
one is called 'init' in root dir, that will be loaded by partition boot sector.
the other one is called 'kernel', that will be loaded by 'init'.

we only load one cluster from root dir, as we don't load the full FAT table,
so the 'init' file has to be less than cluster size, and be found in the first cluster of root dir.

[Selenic]

Most (all) major bootloaders easily use 63 sectors following the MBR, grub even has a 3 stage system (stage 1, stage 1.5 and stage 2). There's no shame in suing up to 32K so just do it

Also, a lot of partition management programs (not necessarily all, though) tend to start the first partition at cylinder 1, meaning you have (heads*spt) sectors to use. On modern disks, that tends to be a few hundred kilobytes or so, I think. Plenty of space for even the largest of bootloaders!

[djsilence]

Bootsector on FAT32 is same size as on other fs, not depending on cluster size. Why don't you create 2 stage bootloader? First stage just read stage2 loader into memory, stage2 loader is not 512 bytes in size, so you can go to pm, enable a20, etc.

[djsilence]

Try on this: