OSDev.org

Octocontrabass wrote:

ggodw000 wrote:I see large No. of sectors available. [...] It looks like a convenient place to put large bootloader related code.

The number of reserved sectors varies depending on the tool used to format the disk. Most tools provide only 32 reserved sectors (this number includes the boot sector, fsinfo sector, and backup boot sector).

Microsoft's FAT32 bootloaders use 2 sectors in total: the boot sector and one additional reserved sector. If you need more than that, you should probably store the rest of your bootloader as a file on the disk.

you should probably store the rest of your bootloader as a file on the disk.

that would defeat the purpose of writing bootloader. Part of the bootloader i am writing is for loading the file from full-fledged fat-32 partition.

from ~-s post: FAT32 Specification (https://staff.washington.edu/dittrich/m ... gen103.pdf)

it appears sector 6 of reserved region is used for boot loader recovery based on the section titled "FAT32 FSInfo Sector Structure and Backup Boot Sector ":

here is the excerpt:

"Another feature on FAT32 volumes that is not present on FAT16/FAT12 is the BPB_BkBootSec field.
FAT16/FAT12 volumes can be totally lost if the contents of sector 0 of the volume are overwritten or
sector 0 goes bad and cannot be read. This is a “single point of failure” for FAT16 and FAT12
volumes. The BPB_BkBootSec field reduces the severity of this problem for FAT32 volumes, because
starting at that sector number on the volume—6—there is a backup copy of the boot sector
information including the volume’s BPB.
In the case where the sector 0 information has been accidentally overwritten, all a disk repair utility
has to do is restore the boot sector(s) from the backup copy. In the case where sector 0 goes bad, this
allows the volume to be mounted so that the user can access data before replacing the disk.
This second case—sector 0 goes bad—is the reason why no value other than 6 should ever be placed
in the BPB_BkBootSec field. If sector 0 is unreadable, various operating systems are “hard wired” to
check for backup boot sector(s) starting at sector 6 of the FAT32 volume. Note that starting at the
BPB_BkBootSec sector is a
complete
boot record. The Microsoft FAT32 “boot sector” is actually
three 512-byte sectors long. There is a copy of all three of these sectors starting at the
BPB_BkBootSec sector. A copy of the FSInfo sector is also there, even though the BPB_FSInfo field
in this backup boot sector is set to the same value as is stored in the sector 0 BPB.
NOTE:
All 3 of these sectors have the 0xAA55 signature in sector offsets 510 and 511, just like the
first boot sector does (see the earlier discussion at the end of the BPB structure description). "

ggodw000 wrote:

Octocontrabass wrote:you should probably store the rest of your bootloader as a file on the disk.

that would defeat the purpose of writing bootloader. Part of the bootloader i am writing is for loading the file from full-fledged fat-32 partition.

You can fit the code to load files from a FAT32 disk in two sectors pretty easily, but what about the rest of your bootloader?

Octocontrabass wrote:

ggodw000 wrote:

Octocontrabass wrote:you should probably store the rest of your bootloader as a file on the disk.

that would defeat the purpose of writing bootloader. Part of the bootloader i am writing is for loading the file from full-fledged fat-32 partition.

You can fit the code to load files from a FAT32 disk in two sectors pretty easily, but what about the rest of your bootloader?

that would be all bootloader will need to do:
find and load the file (kernel) from FAT32 disk and execute it. It might not exactly how other bootloader/kernel works but i just decided to do this way . probably fit in 2-3 sectors

i think even erasing sector 6 from rsvd sectors is OK as it is not critical for my project.
i know sector 0 itself used to hold the volume information (volume ID).

i am just going to boot to efi shell utility and erase all sectors between volume: 2nd sector of the volume all the way to beginning of FAT32 1st copy (not including) to see any adverse effect and to see anything is messed up as a result.

Octocontrabass wrote:

ggodw000 wrote:

Octocontrabass wrote:you should probably store the rest of your bootloader as a file on the disk.

that would defeat the purpose of writing bootloader. Part of the bootloader i am writing is for loading the file from full-fledged fat-32 partition.

You can fit the code to load files from a FAT32 disk in two sectors pretty easily, but what about the rest of your bootloader?

ggodw000:

You will likely not be able to avoid a "stage two loader" on the partition, unless you like real mode development.

The key is to have a bootloader that loads a "stage two loader", which can be done in the VBR with a little room to spare. (e.g. My VBR can load a file upto one sub-directory deep from FAT16 OR FAT32 [no-LFN] HDD-VBR (BOS 0.0.5))

Though my VBR does have some major issues, such as trying to use it on a pre-386 or a system without BIOS INT 13h, AH=42h - which let's face it, who in their right mind would... (though the latter will fail gracefully, not sure what the former will do...)



Anyways, Best regards,


B!

ggodw000 wrote:that would be all bootloader will need to do:
find and load the file (kernel) from FAT32 disk and execute it. It might not exactly how other bootloader/kernel works but i just decided to do this way . probably fit in 2-3 sectors

What about getting the memory map, setting an appropriate video mode, enabling A20, and other tasks that must be done while in real mode? You'll quickly run out of sectors.

ggodw000 wrote:i think even erasing sector 6 from rsvd sectors is OK as it is not critical for my project.
i know sector 0 itself used to hold the volume information (volume ID).

i am just going to boot to efi shell utility and erase all sectors between volume: 2nd sector of the volume all the way to beginning of FAT32 1st copy (not including) to see any adverse effect and to see anything is messed up as a result.

There are three possible outcomes, and which one you receive will depend on which system is trying to access your invalid filesystem:

1. It works exactly like normal, and the invalid sectors are ignored.
2. It fails to mount with an error about the filesystem being corrupt.
3. The invalid sectors are silently overwritten.

BASICFreak wrote:Though my VBR does have some major issues, such as trying to use it on a pre-386 or a system without BIOS INT 13h, AH=42h - which let's face it, who in their right mind would... (though the latter will fail gracefully, not sure what the former will do...)

Your VBR will fail pretty hard if it isn't loaded by your MBR, since it assumes the segment registers and stack are all set up. I also notice you set SP to 0xFFF8 instead of 0...

Octocontrabass wrote:

BASICFreak wrote:Though my VBR does have some major issues, such as trying to use it on a pre-386 or a system without BIOS INT 13h, AH=42h - which let's face it, who in their right mind would... (though the latter will fail gracefully, not sure what the former will do...)

Your VBR will fail pretty hard if it isn't loaded by your MBR, since it assumes the segment registers and stack are all set up. I also notice you set SP to 0xFFF8 instead of 0...

I did mention "major issues" and "such as" right
Well, yes it will fail if not loaded by my MBR.
And for SP, it is now set to 0 - But at-least I kept the stack aligned, which was my goal.
I know of a few more issues, but that's for me to know (and fix) and why "copy and pasting" is always a bad idea

All my code on GIT is outdated, and I've been too lazy to do anything about it, plus my current build "does not work" - but that is by design as I am "attempting" to do tests on many aspects of early boot and basic system management. (By "attempting" I mean the up-to 4 hours a week I now get to actually OSDev... Which usually gets eaten up by other projects, of which I now have too many of.)

What about getting the memory map, setting an appropriate video mode, enabling A20, and other tasks that must be done while in real mode? You'll quickly run out of sectors.

I am thinking those or any other tasks to be a kernel's job. Now I am allocating mem address 10000000 (god forbid, there is nothing in there if so, I will have to bring down the upper limit from 9000:0000). If anytime file size becomes such that it will not fit in here, I will intro the 2nd stage loader. But that will still be a part of the kernel. What the 2nd stage will do is enter pmode and relocate the whole of itself to extended memory and continue. If it comes to that (sooner or later), I will dedicate certain part of the kernel block that can fit into low memory (<1mb) for this relocation code. For this, I dont see any technical challenges for this though. For now bigger challenge is the bootloader itself.

ggodw000 wrote:Now I am allocating mem address 10000000 (god forbid, there is nothing in there if so, I will have to bring down the upper limit from 9000:0000).

You could use int 0x12 to find the upper limit. That way, there's no guessing.

Some (old) computers may have 256 or 512 kiB of low memory instead of 640 kiB.

Octocontrabass wrote:

ggodw000 wrote:Now I am allocating mem address 10000000 (god forbid, there is nothing in there if so, I will have to bring down the upper limit from 9000:0000).

You could use int 0x12 to find the upper limit. That way, there's no guessing.

Some (old) computers may have 256 or 512 kiB of low memory instead of 640 kiB.

ok

i looked through sector 1 through 30 of the reserved sectors. Here is what i found:
sector 1 - BPB
sector 6 - was exact copy of BPB except one bit. (cant remember what that bit is for)
some of the sectors around 2-5, 7 with upwards of 10 is seem to be used. i see 55aa signature at some of the sector's end, and also rrAA signature at the beginning. I thought it is best not to touch those.

Sectors 10-30 were completely empty. I decided to use 10-18 sectors for boot loader's 2ns stage to see what happens.

just finished the code complete for a two-stage bootloader. i called the second part that is residing on the 1st volume's 10th and so on sector a "second stage bootloader". Compiled and verified the code but has not run yet. Also had to do a major revision for the bootloader installed code too accordingly. I am surprised how complicated and arduous it can become. Anyways I am going to run it on next few days and see what happens.