boot sector / file system

[sigler]

Hello,

I have a few questions/thoughts about what's in the boot sector.

Given that the boot sector is only 512 bytes (at least on floppy, haven't yet started on hd, but will eventually get there), you have to be very economic about what's in there. The first bytes in the boot sector is used by the fat file system, so this further restricts you.

Ideally, you would load the root dir entries and find the entry for a file that you load into memory. Is this the way it's usually done, will this fit in the 512 size boot sector? Or must one assume that the first entry is the file you want to load etc. ?

Is my assumption correct that the boot sector program code is tied to the file system that is on the disk? So that in the example above, the code to load the first file assumes FAT12, and that if the filesystem is FAT32, the boot code is also changed, I'm thinking that the filesystem header at the start of the boot sector is data that belongs to the program in the rest of the boot sector. And program code doesn't usually need to validate data that is embedded within the program. Would this also be applicable to ext filesystems? I mean that the boot sector code only supports ONE filesystem, and that there is different boot sector code for different filesystems.

--
Sigurd Lerstad

[Telgin]

I'm not terribly certain how the boot sector works within the FAT12 file system, or how it is handled with hard disks with multiple partitions (I think that the MBR contains information on where to find each boot sector for each partition or something).

But, I can say this about hard disks and boot loaders: for hard disks, the sector size is still 512 bytes. It's very hard to put a decent boot loader in 512 bytes, so instead something else is done: a second stage boot loader is loaded by the first, so that there is no size limitation. This could be done in any number of ways: you could make it the second sector on the disk, or it could be a file in the filesystem.

If you do the latter, you will need to have a filesystem in place, and yes, the boot sector will need to be able to find the second file on the filesystem. This is certainly possible within 512 bytes, just have the basic code to search in the appropriate locations for the second stage boot loader on disk, load it into memory, and jump to it to get it running. If you need more complicated filesystem stuff to be done before loading the kernel, you can do so in the second stage loader.

[bewing]

If all you will ever boot from is FAT12 with a non-LFN DOS directory structure, and the kernel name is fixed, you can certainly code it into the 510 bytes that you have in a boot sector (minus the bytes that FAT12 predefines, of course).

A hard disk MBR has 436 to 446 bytes (there is a 10 byte non-critical area that can be overwritten) for code, but what it does in that code is to load the OS/FS specific boot sector -- which was dealt with in the previous paragraph -- except that it is highly unlikely that you can use precisely the same boot sector for your OS on both a floppy and a hard disk partition. (You will need to preserve partition info from the MBR for your OS when you boot off an HD partition -- which does not need to happen at all on a floppy.)

The hard part comes if you try to add extra features to the OS/FS specific boot sector, or to the MBR itself. A user interface/overridable kernel names/initial OS command lines/detailed boot messages with pauses/fancy dual booting/extra memory testing/non-standard boot devices/pretty screens (graphics?)/multiple OS/FS support, etc. All of these things can easily push an MBR or boot sector over its limits.

But there are ways around all of it.
All OSes that I know of leave quite a large area at the beginning of any media/partition for the boot sector (much more than just 512 bytes). It is quite simple to merge the concept of a "second stage bootloader" with an extended boot sector. The boot sector simply needs to load more of itself off the beginning of the media/partition. Once it has loaded the extra code, it can become "smart" enough to load an arbitrary kernel with lots of pretty bells and whistles in "one" stage.

[Ready4Dis]

I have my boot sector load a second sector. The second sector does the initializing of the memory manager, and loads 4 base files (from a known location on the disk), kernel, i/o driver for the boot device, file system, and graphics driver. The first sector, I have a function that is used to read blocks from the disk, and the file system specific header. The second section (another 512) is the exact same for EVERY boot device I have, it is simply linked to the first sector for each file system and uses it's read function, so it doesn't care what device it's on, or if it's in a partition, whatever. It does a bunch of things besides just loading the 4 devices, like initializing my memory manager, setting up the page tables, and jumping to p-mode. So, in 1k bytes, I load just about my entire OS. My kernel then uses the supplied drivers to finish loading user applications, etc. This makes my kernel and boot loader code completely un-reliant on file system or media, and is very simple to update (only need to replace the first source file that has the media specific code, the 2nd sector is completely unchanged besides the linked function for reading a block).

[Dex]

Hello,
Given that the boot sector is only 512 bytes (at least on floppy, haven't yet started on hd, but will eventually get there), you have to be very economic about what's in there. The first bytes in the boot sector is used by the fat file system, so this further restricts you.

510 bytes is lots of room, i fitted a pmode OS with full vesa 640x480 32bpp graphics, along with basic GUI, vesa fonts and CDplayer in less than 512 bytes.
Other's fitted full multi-tasking demo, other a bootable tetris game etc.
So there lot of room, for a basic boot loader .

[jal]

[510 bytes is lots of room, i fitted a pmode OS with full vesa 640x480 32bpp graphics, along with basic GUI, vesa fonts and CDplayer in less than 512 bytes.

Though I know what ASM gurus can do with so little room, that would probably stretch the definition of "OS" a bit :). Do you by any chance have a download for that?


JAL

[Dex]

Sure http://dex4u.com/ASMcompo512b/CdPod.zip
NOTE: I was call ASHLEY4 when i wrote it, but in some country's it's a girls name.
It came second

[XCHG]

sigler,

512 bytes, as Dex said, is plenty of room. However, in my case also, I felt like it was pretty small compared to what I wanted to do. I wanted to have a small HDD driver in it. A small Text Mode graphics driver. GDT, IDT and etc had to be covered. To be exact, what I wanted was a small kernel on itself. So what I did was that I created two stages of my boot sector. I called them Boot Loader Stage #1 and Stage #2. The first stage does these:

• Finds the Stage#2 boot loader from the disk.
• Loads the Stage#2 boot loader from the disk into the memory at 0x0000:(0x7C00 + 512).

The Stage#1 will see if there are any other sectors attached to the Stage#2 boot loader. If yes, it will load them too. So as a result:

• The MBR's boot-strap code will load my Stage#1 Boot Loader.
• My Stage#1 boot loader will locate and load Stage#2 boot loader that could be as many as N-2 sectors long where N is the length of the partition in sectors and -2 = -1 + -1 = (-MBR + -Stage#1).
• My Stage#2 boot loader will take control and it will create a very basic kernel on its own. It will then find the loader using my file system's structure and it will load the kernel into the memory and jump to it.

All in all, the message that I'm trying to pass is that you shouldn't limit your boot loader just to 512 bytes of space. Think of an extended boot loader that could take more than 512 bytes of space just in case!

To give you a better idea of how the boot-sector of my file system (SSFS) looks like, I will attach its boot-sector documentation to this post.

Last but not least, Dex, Bravo