On Sunday, December 19, 2021 at 4:43:46 PM UTC-6, James Harris wrote:
> 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
>
>
>
> 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
Q. Is this fat-LFN?
Q. What is the size of the OS?
Q. Are you sure the VBR cannot be made to load the entire OS? - eliminating
the separate OS Loader?
The MBR I use is a vanilla ibm ~32 mb with one volume bootable, with the VBR
expected at LBA = 20h.
The VBR is at LB 20h, The hobby OS begins at LB 21h and runs for 63.5k, it is
outside the file system. The file system directory follows the OS, the file
data follows the directory area. The file system is under development, it
isn't needed to boot
the OS, it will be needed to save data to files and to load utilities. - non
fat.
I don't support fat, nor LFN, LFN is covered by ms patents, so I dropped my
work on it. But back when I was working with fat, that VBR code was enough to
load a hobby os off the fat filesystem --non-lfn.
The VBR that I'm using is of course loaded at 07C00h, it then relocates itself
to below the EBDA and continues on to load the OS to 80:0000h, then far jumps
to the OS. The self relocation is simple enough, and gets the vbr boot code
out of the way of
loading the OS, avoiding the possibility of over-writing itself.
Steve
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
