OSDev.org

Isn't this what the "count of reserved logical sectors" field does?

Hello,Boot records spanning multiple sectors is common for complex file system parsing. Even for something as simple as fat, it might be helpful to have multiple sectors reserved for additional boot code for additional checks, error recovery, and message output. Don't need a custom file system, just set the reserved sector count field in the BPB. Given this post, the original poster has one program file; where the first 512 bytes is loaded by the firmware. My response was directed at that.

We are entirely in agreement however that he should be using a file system and loading the actual boot loader ("second stage") which in turn should load the kernel. However he needs to be able to read a sector before any of this. Given the difficulty the original poster appears to be having, it might be better to use an existing boot loader like GrUB for now.

I don't want to use Grand Unified Bootloader.

I know how to read a sector. The sector is my kernel. I want to load my kernel if it's more than 512 bytes. Do I have to read two sectors? I believe I am using FAT12. I am using disk dump.

A sector is a part of a track.

I might just need a very good resource on filesystems.

I did not say that everything should be crammed into one sector. All I said was that the binary code in the boot sector shouldn't just "overflow" into other sectors, but that the code in the other sectors should be its own separate code. If your filesystem-parsing code is too big to fit in one sector, then put it somewhere else and use the first sector to load and execute it. Even GRUB does this: the MBR (first-stage) loads the second-stage from a fixed location on disk (which corresponds to certain files in the /boot partition, which is why the MBR must be updated if /boot is moved), and the second-stage contains the filesystem-parsing code to properly load the third-stage from the filesystem. Nobody writes the subsequent sectors/files of their bootloader as part of the same binary as the boot sector.

Always talking to someone else...

Hello,
I completely agree. But that is what he is doing, and calling the second sector his "kernel." I believe this is where a lot of the confusion stems from.

You sound somewhat confused to me. Let me try to explain.

• FAT is a filesystem, which is a way for you (and other operating systems) to figure out which sectors contain which files. It has nothing to do with actually reading the sectors.
• You can read any sector you want, ignoring the filesystem.
• You can put your data wherever you want, without a filesystem.
• The size of your kernel is irrelevant.

You have two options:

• Create a bootloader (may be more than 512 bytes) that can read the FAT filesystem, and thereby load your kernel. Copy your kernel to the disk as an ordinary file using e.g. Windows Explorer.
• Create a boot sector with the location (on disk) and size of your kernel hardcoded (contained in the boot sector code itself), and load your kernel from this location on disk. Copy your kernel to disk using a utility that lets you write a file to any arbitrary location on the disk (instructions for how to do this depend on what operating system and tools you are using).

My advice would be to go with the former option, using an actual filesystem. This will be less confusing and more robust in the future.

The code for reading the FAT filesystem probably won't fit in the boot sector, so you will need to put it elsewhere on the disk. Your boot sector will contain, hardcoded, the location on the disk of the code that reads the FAT filesystem and loads your kernel. You will write this code to disk using a special utility that lets you write to any arbitrary location on the disk. Your boot sector will load these hardcoded sectors into memory and then jump to it to execute it.

Now the code for reading the FAT filesystem takes over. This code will need to be able to read any single sector from disk into any memory location, so you should write a subroutine/function/method that you can call with parameters giving the sector that you want to read and the memory location that you want it to be read into. At this point you will be working with sectors numbered from 0 at the beginning of the disk all the way to 2879 at the end (assuming that you're working with a regular floppy disk) - this is called LBA (logical block addressing) - so write your sector-reading function such that it will calculate the correct cylinder, head, and sector within the track from a logical block address. Now you can read the FAT filesystem tables, parse them to find the location of your kernel file, and then read the kernel. At this point, hopefully, you can understand why the size of your kernel doesn't matter, because you will simply read whichever sectors contain your kernel according to the filesystem, no matter how many there are and where they are on the disk (note that the sectors may not be contiguous, called fragmentation).

I think the only confusion is coming from people who propose treating the entire bootloader as a single binary (you). It doesn't matter if he calls his second sector a kernel; at this point there's probably not much difference between a second-stage bootloader and a kernel. The important part is that it's a separate piece of code that's loaded into memory and executed.

I do still need a 512 byte bootloader...

I think this will be less confusing. I will still need an 512 byte bootloader but I will have an unlimited kernel. How would I start implementing the FAT filesystem? I don't want code. However, an example and some resources might be helpful.

I hope my bootloader won't get too FAT

Hello,

Perhaps I should just remove my original suggestion? I never encouraged nor recommended using a single binary image for the boot code; yet it appears that some members believe I have - that certainly was not the intent. The original poster appeared to have been trying to do this given the links I provided hence why I provided the suggestion. Should I have just ignored what I believed that he was trying to do and instead just encouraged the proper way?

Any case, if you do have a separate kernel binary then please ignore my suggestion -- it didn't seem like it from your responses. You should really be creating a proper boot loader that loads the kernel anyways (see onlyonemac's post.)

If you do believe that you know how to read arbitrary sectors and can write a function to do it, then I encourage supporting fat12. I probably won't respond farther since other members can provide support for it.

You "believe" that you are using FAT12?

Honestly, if you are not even sure what file system you are trying to read it's time to stand back, go back to school, do a lot more learning, and then try again when you know what you are doing.

I have a horrible feeling that you are going to be one of those " how do I do X", " how do I do X+1", etc. posters. Do some reading, do some research before jumping in at the shallow end.

Where are resources for implementing FAT12? Is there a small example? I've done my searching. Search engine I use is down.

I can recommend a very good search engine called Google. (Disclaimer - I have a relative who works for Google.) It's very good, I've never known it to be down, and it has a host of information about FAT12.

I would recommend that you rethink your decision to avoid GRUB. It's a great bootloader and does a lot of the donkey work for you. What have you got against it?

Exactly what you said. I want to do all the donkey work. What would happen if GRUB didn't exist? I don't want to make an Unix operating system. I love Unix. However, I want to do everything myself. I don't want to decrease my effort.

GRUB is nothing to do with UNIX (or Linux or any other nix).

You want to do the donkey work yourself? Great. I've every sympathy with people who want to do it all by themselves. So just do it and don't post questions here about every little problem you run into. The information is all out there on the web; do a modicum of research for yourself.