OSDev.org

I'm implementing boot loader for my Kernel but as wanna parse file system information within the loader I found it hard to do. Because within Partition boot record I have to read the rest sectors of the loader but I do not know where to find the sectors. Hmm , just too hard to implement it with pure assembly . Sigh , busy reading documents.......

hendric wrote:I'm implementing boot loader for my Kernel but as wanna parse file system information within the loader I found it hard to do. Because within Partition boot record I have to read the rest sectors of the loader but I do not know where to find the sectors. Hmm , just too hard to implement it with pure assembly . Sigh , busy reading documents.......

My boot loader isn't to bright, it simply loads a file from disk with a specified number of sectors. Actually, it has a loop that does this 3 times from different locations. The files it loads are the kernel, the disk i/o driver, and the file system driver. This does 2 things for me, I don't have to recompile my boot loader to load it up on another file system, simply point it to the correct driver on disk (which must be linear, might be tricky in some file systems), and the other is, I don't have to implement 2 file system drivers, one for rmode and one for pmode! I also split my boot loader into 2 sectors, the first sector contains a function to read a sector from disk and loads the 2nd sector into memory after itself. The 2nd sectors uses this function to load the kernel + drivers into memory, so to boot from different media, I simply supply it with a different first sector, point it to the proper disk i/o driver and file system driver, and it's good to boot off any media type with any file system! Very simple and effective.

yes, that may be a slightly easier way (though it isnt hard to parse the FAT structures), it is vastly inferior as well

by properly parsing the filesystem (not practical with more complex file systems) you get many advantages -- virtually unlimited growth of second stage/kernel, and any disk is automatically bootable -- to use a new copy of your code, all you have to do is copy the new files onto the disk, and its done -- you dont have to reformat like you do with fixed-location loading, or change any other files -- everything is easily availible within the filesystem, so its also easy to work with from within any existing OS

My boot loader isn't to bright, it simply loads a file from disk with a specified number of sectors. Actually, it has a loop that does this 3 times from different locations. The files it loads are the kernel, the disk i/o driver, and the file system driver. This does 2 things for me, I don't have to recompile my boot loader to load it up on another file system, simply point it to the correct driver on disk (which must be linear, might be tricky in some file systems), and the other is, I don't have to implement 2 file system drivers, one for rmode and one for pmode! I also split my boot loader into 2 sectors, the first sector contains a function to read a sector from disk and loads the 2nd sector into memory after itself. The 2nd sectors uses this function to load the kernel + drivers into memory, so to boot from different media, I simply supply it with a different first sector, point it to the proper disk i/o driver and file system driver, and it's good to boot off any media type with any file system! Very simple and effective.

omg! that is genius!! I would have never thought of doing that for some reason, I thought I had no choice but have filesystem and disk io drivers compiled into the kernel...

JAAman wrote:yes, that may be a slightly easier way (though it isnt hard to parse the FAT structures), it is vastly inferior as well

by properly parsing the filesystem (not practical with more complex file systems) you get many advantages -- virtually unlimited growth of second stage/kernel, and any disk is automatically bootable -- to use a new copy of your code, all you have to do is copy the new files onto the disk, and its done -- you dont have to reformat like you do with fixed-location loading, or change any other files -- everything is easily availible within the filesystem, so its also easy to work with from within any existing OS

Are you kidding? I can have my second stage any size as well, as long as the disk has that many consecutive sectors available. If it specific to FAT, then what if I want to work on linux Ext2/fs or similar, then I have to write a new bootloader. With my method, I copy the kernel, and supporting drivers to disk, taking care to make sure they are consecutive sectors!, then I point my second stage to these locations, and write it out, then I point my first stage to this location, and write it out as the first sector on the disk. Bam, done, no reformatting, can easily support many file system types, etc. Kinda sucks that those few files require consecutiveness, but I am willing to take a small hit like that over writing a custom boot loader for each and every file system type that I want to support!

This is kindof becoming an discussion about personal preference...
Just name one method LILO, name the other GRUB, and go figure what style you prefer. By now we've got all the arguments

Back to the original topic: unless you want to use an existing bootloader, you are pretty much stuck with assembly. What you can do is use up the reserved area of any sane file system format, load sectors from there, and bloat it full with whatever code you want. If you do it correctly, you can even get into protected mode and use C code for the rest.

Other remarks: Google, Browse the wiki, and click some people's signatures to see how they solved it. There's a lot of GPLed or Public Domain code around for you to use.

Hi,

Combuster wrote:This is kindof becoming an discussion about personal preference...
Just name one method LILO, name the other GRUB, and go figure what style you prefer. By now we've got all the arguments

Almost, but you're missing one - mine!

My method is to load everything the OS needs during boot into RAM (in the form of a "boot image"), and have a specification that defines exactly how the boot loader must setup the computer before starting the OS's boot code.

This allows you to have many extremely different boot loaders without caring which was actually used.

So far I've used this to boot from a RAW floppy, boot from CD, boot from GRUB, boot over the network and boot directly from ROM (a "BIOS-less" machine). I also have transparent/optional boot image compression that works with all of the above.

If someone wants to do something insane (like loading the boot image from a serial port transfer, from the sound card's microphone input or using their own home-made device) then it's easy...


Cheers,

Brendan

If someone wants to do something insane (like loading the boot image from a serial port transfer, from the sound card's microphone input or using their own home-made device) then it's easy...

@Brendan, that as insane as playing music through your monitor, but it can be done .

Dex wrote:

If someone wants to do something insane (like loading the boot image from a serial port transfer, from the sound card's microphone input or using their own home-made device) then it's easy...

@Brendan, that as insane as playing music through your monitor, but it can be done .

You might want to search for the DeCSS source code being distributed as a WAV file recording of a C64 tape image of the code. That's pretty weird too.

If you GZIP-compress it and then read the file as a little-endian number, it's a prime too. So that's an illegal prime .

I'm going for the home-made device though.

Ready4Dis wrote: Are you kidding? I can have my second stage any size as well, as long as the disk has that many consecutive sectors available. If it specific to FAT, then what if I want to work on linux Ext2/fs or similar, then I have to write a new bootloader. With my method, I copy the kernel, and supporting drivers to disk, taking care to make sure they are consecutive sectors!, then I point my second stage to these locations, and write it out, then I point my first stage to this location, and write it out as the first sector on the disk. Bam, done, no reformatting, can easily support many file system types, etc. Kinda sucks that those few files require consecutiveness, but I am willing to take a small hit like that over writing a custom boot loader for each and every file system type that I want to support!

you missed my point

first, your entire kernel must be written to specific sectors, my system also reuses the disk-load routines from the bootsector, but the second stage and kernel both exist simply as files copied onto the disk, while your method requires rewritting the bootsector every time you change anything in your OS (a change to the kernel requires a change to the secondstage, and a change to the secondstage requires a change to the bootsector -- or specifically writing the secondstage back to exactly the same sectors it was in, which any decent OS will not permit -- though most will)

under my system, any change to the second stage or kernel, and i just delete the old one and copy the new one, and im done -- no sector writes required at all -- and if i need a new bootdisk, all JaaOS formated disks are already bootable -- just copy the files onto the disk

and, contrary to what you said, my secondstage does not need to be changed between differing filesystems -- to change either disk types or filesystems, only the bootsector needs to be changed -- just like yours

This is kindof becoming an discussion about personal preference...
Just name one method LILO, name the other GRUB, and go figure what style you prefer. By now we've got all the arguments Cool

no, grub and lilo both use exactly the same method (the one proposed by Ready4Dis), the system i use, is very much like the MS bootloader

JAAman wrote:no, grub and lilo both use exactly the same method (the one proposed by Ready4Dis)

Uh, GRUB interprets file systems (and only needs to be installed once), LILO takes a sector list (and needs to be reinstalled after every and any change). Have a look at wikipedia if you doubt it.
The only thing you could be accusing GRUB of is that it loads stage 1.5 from a fixed location (the reserved area after the bootsector)

The only thing you could be accusing GRUB of is that it loads stage 1.5 from a fixed location (the reserved area after the bootsector)

which is exactly what i was talking about -- the secondstage (although Ready4Dis loads the kernel that way as well)

Which is exactly what i was talking about -- the secondstage

What Grub calls stage1.5 is not a second level loader but an extention to the first stage. Usually it's stored right after the bootsector, which is just too small to hold the code needed to access most filesystems.

- Bootsector (stage1) is loaded by the BIOS
- MBR code gets stage1.5 from a fixed location on the disk
- Stage1.5 contains code to access the partition
- Stage2 (actual booloader) and the kernel are loaded using the filesystem

cheers,
gaf