James Harris
2021-12-19 22:43:43 UTC
I've just started looking at booting from FAT16 and it's proving to be a
bit of a challenge. That's because of what I want it to do and because
space is soooo limited! I've set out my idea below. How does it look to
you?
For nomenclature, the sequence to boot from a hard disk can be seen as
MBR --> VBR --> OSloader
i.e. Master Boot Record (first sector of a disk) loads the Volume Boot
Record (first sector of a partition). It, in turn, loads the (larger) OS
loader which is big enough to include code to do a lot more.
As a reminder, the layout of a FAT16 volume is
<reserved><FATs><rootdir><filespace>
AIUI there are two 'traditional' approaches. One is to make the reserved
area large enough for plenty of code. The other (taken by LILO, IIRC) is
to have the os loader in unmovable sectors of the filespace and to
'hardcode' their location into the VBR.
It is /possible/ for there to be plenty of space in the reserved section
of a FAT volume but that cannot be counted on. AIUI it depends on how it
has been formatted. In an already formatted volume the reserved area
might be only one sector, the VBR itself and nothing else. So I don't
believe I can rely on there being any more than 512 bytes in that space.
I'd also like to avoid the LILO approach. It's a pain when a new OS
loader is installed, requiring something to update the hardcoded block
addresses in the VBR.
So, what can be done?
Going back to the boot steps the MBR will be 'standard', i.e. although
the BIOS will have loaded it to 0x7c00 it will move itself out of the
way (often to 0x600) and load the VBR to 0x7c00. It could be any MBR. It
would not need to be specific to a particular OS.
Effectively, the first point I will get control is when my VBR is loaded
to 0x7c00 and started.
I will then need to load the OS loader but than can be difficult in just
512 bytes as I would like it to be a normal file. No special sectors. No
unmovable sectors. My plan, then, is to split the work as follows.
The VBR will look through the root directory until it finds the OS
loader by name. When it finds it it will load just its first sector and
will transfer control to that sector.
The first sector of the OS loader won't have to include code to read the
root directory again meaning it will /hopefully/! have enough program
space to follow the FAT chain to load more of itself.
So loading would be in at least these parts:
1. VBR finds OS loader file and loads 1st sector of it.
2. OS loader's first sector follows the FAT chain to load more of (maybe
all of) OS loader.
3. The OS loader is then large enough to do whatever's necessary.
That's the plan. What do you think of it? Any better ideas? Suggestions
welcome.
bit of a challenge. That's because of what I want it to do and because
space is soooo limited! I've set out my idea below. How does it look to
you?
For nomenclature, the sequence to boot from a hard disk can be seen as
MBR --> VBR --> OSloader
i.e. Master Boot Record (first sector of a disk) loads the Volume Boot
Record (first sector of a partition). It, in turn, loads the (larger) OS
loader which is big enough to include code to do a lot more.
As a reminder, the layout of a FAT16 volume is
<reserved><FATs><rootdir><filespace>
AIUI there are two 'traditional' approaches. One is to make the reserved
area large enough for plenty of code. The other (taken by LILO, IIRC) is
to have the os loader in unmovable sectors of the filespace and to
'hardcode' their location into the VBR.
It is /possible/ for there to be plenty of space in the reserved section
of a FAT volume but that cannot be counted on. AIUI it depends on how it
has been formatted. In an already formatted volume the reserved area
might be only one sector, the VBR itself and nothing else. So I don't
believe I can rely on there being any more than 512 bytes in that space.
I'd also like to avoid the LILO approach. It's a pain when a new OS
loader is installed, requiring something to update the hardcoded block
addresses in the VBR.
So, what can be done?
Going back to the boot steps the MBR will be 'standard', i.e. although
the BIOS will have loaded it to 0x7c00 it will move itself out of the
way (often to 0x600) and load the VBR to 0x7c00. It could be any MBR. It
would not need to be specific to a particular OS.
Effectively, the first point I will get control is when my VBR is loaded
to 0x7c00 and started.
I will then need to load the OS loader but than can be difficult in just
512 bytes as I would like it to be a normal file. No special sectors. No
unmovable sectors. My plan, then, is to split the work as follows.
The VBR will look through the root directory until it finds the OS
loader by name. When it finds it it will load just its first sector and
will transfer control to that sector.
The first sector of the OS loader won't have to include code to read the
root directory again meaning it will /hopefully/! have enough program
space to follow the FAT chain to load more of itself.
So loading would be in at least these parts:
1. VBR finds OS loader file and loads 1st sector of it.
2. OS loader's first sector follows the FAT chain to load more of (maybe
all of) OS loader.
3. The OS loader is then large enough to do whatever's necessary.
That's the plan. What do you think of it? Any better ideas? Suggestions
welcome.
--
James Harris
James Harris