BootLoader Design

[Pitchu]

I am trying to load a KernelLoader file from the Root Directory of Active Partition whose filesystem is FAT32.
Can somebody suggest me about any technique to access it in such a way that code limits to 512 bytes and there is no restriction on my KernelLoader file to have contigous clusters.
I mean dont you thing parsing the entire root directory cluster_by_cluster using FAT and sector_by_sector per cluster and then repeating same procedure to the file..

[mathematician]

I am trying to load a KernelLoader file from the Root Directory of Active Partition whose filesystem is FAT32.
Can somebody suggest me about any technique to access it in such a way that code limits to 512 bytes and there is no restriction on my KernelLoader file to have contigous clusters.
I mean dont you thing parsing the entire root directory cluster_by_cluster using FAT and sector_by_sector per cluster and then repeating same procedure to the file..

You can either do what Microsoft did with MS-DOS, and put the kernel in a fixed location, or you can do what they now do with Windows, and put the second stage loader in a fixed location.

[Pitchu]

You can either do what Microsoft did with MS-DOS, and put the kernel in a fixed location, or you can do what they now do with Windows, and put the second stage loader in a fixed location.

True.
I am interested in second stage loader that will load the actual KERNEL but I dont want to put this in a fixed location and to accomplish this code should remain confined to 512 bytes.
Is there an efficient technique to do it?

[Dex]

Yes, first you use int 13h to load the MBR and than you use code like this:

Code: Select all

	mov   esi,MBRloadAddress
	add   esi,450
	mov   al,byte[ds:esi]
	cmp   al,0x0B					; Fat32
	je    SysIdOk
	cmp   al,0x0C
	jne   LoadMbrErrorID
SysIdOk:

Once you have checked that its fat32, you can check for a active partion and if it is load the word at offset 446 into dx and load the word at 448 in to cx, and use this to load the BPB-Fat32 using int 13h, you should also store the dword from offset 454 as its the "partition_start_cluster" and will be needed later.
Now you have all the info you need to load a file of a certan name from the hdd.
And the code to do this can fit in 512 byits.

NOTE: The snip above is coded is run from pmode.

[Pitchu]

Well
I tried my best to confine code to 512 bytes but failed.
The problem is i am overwriting the Actual DBR for Active Partition this means 90 bytes for BPB and some bytes for strings like :
1. MyOS
2. Other OS on Drive
Somebytes for print procedure, relocation to 0600H,etc. and finally i am left with about 370 bytes in which i wasnt able to fit code for reading a kernel into memory....
But what i did was that i reserved 4 bytes for First cluster of SecondStage Boot loader in this DBR and used installation program to check the SecondStage loader's cluster number and populated the field within my DBR.
The second Stage bootloader will now contain code to load kernel as it can have a max size of 8KB as my DBR can read 16 consecutive sectors( actually BPB_SecPerClus).

[Dex]

Onething to remember is that the code need to fit into 512bytes, but the BSS data does not. See my CdPod example as a guide, it fits a boot to Pm, a set high-res vesa up, set simple GUI, vesa fonts, keyboard input, and a basic ATAPI driver, along with a CdPlayer all in the less than 512 bytes.
http://board.flatassembler.net/topic.ph ... c&start=60
Note: I was called ASHLEY4 when i wrote it.

[bewing]

An MBR needs to fit in 512 bytes. But it's not reasonable to try to fit a bootloader in that space. Make the bootloader bigger than 512 bytes. Say, 4K minimum. Have the first 512bytes of the bootloader just load the rest of the bootloader. Then you will have plenty of space to write nice code to search the directory for the kernel. It's not necessary to kill yourself with this artificial 512b limit.

[JJeronimo]

I am trying to load a KernelLoader file from the Root Directory of Active Partition whose filesystem is FAT32.
Can somebody suggest me about any technique to access it in such a way that code limits to 512 bytes and there is no restriction on my KernelLoader file to have contigous clusters.
I mean dont you thing parsing the entire root directory cluster_by_cluster using FAT and sector_by_sector per cluster and then repeating same procedure to the file..

Code for loading entire files from a FAT root directory fits OK in 512 bytes, so don't complicate!
Of course, if you want full support for paths and a driver that works for every FAT version and accepts long names, and parhaps more FS support, you will need a second stage. But you can fit code to look for a file, follow it's FAT linked list and load a file fully from a specific FAT version, w/o long name support and restricting it to the root directory in 512 bytes.

You can possibly reduce some of these limitations by carefully optimizing for speed... Code in 16 bit-only to save instruction space. Avoid address/operand size overrides. Put large data (for example, buffers for reading sectors) outside your code. Don't align stuff, even routines. Avoid structuring your code in routines.
Sacrifice speed in favor to space optimization. It's a boot sector, not critical code...

JJ