Mtools and fat32 first data sector calculation

[AndyB]

Hi,

As per my previous posts, I have been experimenting with FAT32 hard disk images rather than floppy disks.

I have tried using both of the following BPBs:

Code: Select all

BPB_OEM_ID 				db "MSDOS5.0"		;Must be 8 bytes long
BPB_BYTES_PER_SECTOR	dw 0x0200			;Bytes Per sector, Usually 512
BPB_SECTORS_PER_CLUSTER db 0x00				;Sectors Per Cluster
BPB_RESERVED_SECTORS	dw 0x0000			;Number of Reserved Sectors, Including Boot Record, Logical start of FAT
BPB_TOTAL_FATS			db 0x02				;Number of FAT tables, almost always 2
BPB_DIRECTORY_ENTRIES   dw 0x0000			;Number of Directory Entries
BPB_TOTAL_SECTORS		dw 0x0000			;Total sectors in the logical volume, if 0 it means there is over 65535
BPB_MEDIA_TYPE			db 0x00				;Media Descriptor Type
BPB_SECTORS_PER_FAT		dw 0x0000 			;Sectors per FAT,FAT12/FAT16 only
BPB_SECTORS_PER_TRACK   dw 0x0000 			;Sectors per track
BPB_TOTAL_HEADS			dw 0x0000			;Number of heads or sides on the storage media
BPB_HIDDEN_SECTORS		dd 0x00000000		;Number of hidden sectors, LBA of beginning of partition
BPB_LARGE_TOTAL_SECTORS dd 0x00000000		;Large amount of sectors on media, set if over 65535

;Extended Bios Parameter Block(EBPB), used in FAT32				
EBPB_SECTORS_PER_FAT	dd 0x00000000 		;Sectors per FAT
EBPB_FLAGS				dw 0x0000			;Flags
EBPB_FAT_VER			dw 0x0000			;FAT Version number
EBPB_ROOT_DIR_CLUSTER   dd 0x00000002		;The cluster number of the root directory, usually 2
EBPB_FSINFO_LBA    		dw 0x0000			;The Logical LBA of the FSInfo structure
EBPB_BACKUP_VBR_LBA     dw 0x0000			;The Logical LBA of the backup boot sector
EBPB_RESERVED times 12 	db 0x00				;RESERVED, 12 Bytes
EBPB_DISK_NUM			db 0x00				;Drive number, value is arbitrary
EBPB_NT_FLAGS			db 0x00				;Flags in Windows NT, Reserved
EBPB_SIGNATURE	   		db 0x29				;Signature, must be 0x28 or 0x29
EBPB_VOLUME_ID    		dd 0x00000000		;VolumeID 'Serial' number, used for tracking volumes between computers
EBPB_VOLUME_LABEL 		db "NO NAME    "	;Volume label string, 11 Bytes
EBPB_SYS_ID 	   		db "FAT32   "		;System identifier string, 8 Bytes

and

Code: Select all

	BPBOEM_ID				db		"GRAVITY "
	BPBBytesPerSector		dw		0x0200
	BPBSectorsPerCluster	db		0x08
	BPBReservedSectors		dw		0x0020
	BPBTotalFATs			db		0x02
	BPBMaxRootEntries		dw		0x0000
	BPBNumberOfSectors		dw		0x0000
	BPBMediaDescriptor		db		0xF8
	BPBSectorsPerFAT		dw		0x0000
	BPBSectorsPerTrack		dw		0x0000
	BPBSectorsPerHead		dw		0x0000
	BPBHiddenSectors		dd		0x00000000
	BPBTotalSectors			dd		0x00000000		
	BPBBigSectorsPerFAT		dd		0x00000000
	BPBFlags				dw		0x0000
	BPBFSVersion			dw		0x0000
	BPBRootDirectoryStart	dd		0x00000002
	BPBFSInfoSector			dw		0x0001
	BPBBackupBootSector		dw		0x0006
	
	times 13 db 0 ; jmp next offset

	BPBDriveNumber			db 		0x00
	BPBSignature			db 		0x29
	BPBVolumeID				dd 		0xFFFFFFFF
	BPBVolumeLabel			db 		"Gravity Vol"
	BPBSystemID				db 		"FAT32   "

Both very similar except for the single byte difference in the reserved space (13 vs 12 bytes).

I then create the disk image using bximage and mtools: (extract from makefile)

Code: Select all

bximage -hd -mode=flat -size=550 -q /tmp/hdd.img
echo -e \\t-Partitioning Image + MBR
mpartition -I -B $(OBJDIR)/mbr/mbr -s 63 -t 1117 -h 16 c:
mpartition -cpv -s 63 -t 1117 -h 16 c:
echo -e \\t-Formatting FAT32 Partition + VBR
mformat -t 1117 -h 16 -s 63 -F -B $(OBJDIR)/vbr/vbr c:

Of course my mtools config file contains the line "drive c: file="/tmp/hdd.img" partition=1"

So the disk image is created and during partitioning mtools writes my MBR to the disk and fills in the correct values to the partition table.
The single partition is then formatted with mformat, the VBR is written and the correct BPB values substituted in.

From all of the examples that I can find, the first step with FAT32 is to calculate the first data sector as (Sectors Per Fat * Total Fats) + Reserved Sectors.

I noticed that I was getting some very odd results from this calculation:

Code: Select all

	; compute location of root directory and store in 'ax'
	xor     ax, ax
	mov     al, BYTE [BPB_TOTAL_FATS]                ; number of FATs
	mul     WORD[EBPB_SECTORS_PER_FAT]              ; sectors used by FATs
	add     ax, WORD [BPB_RESERVED_SECTORS]          ; adjust for bootsector

This resulted in eax storing 0x2008.

Further printing out (and inspection through hex editor) shows the following BPB values are injected by mformat:

Code: Select all

BPB_SECTORS_PER_CLUSTER: 0x00000802
BPB_TOTAL_FATS: 0x00000000
EBPB_SECTORS_PER_FAT: 0x00044A00
BPB_RESERVED_SECTORS: 0x00002008

Obviously the total fats being 0 is causing the multiplication to result 0 and then the reserved sectors are being added on equalling 0x2008.

I know that the total fats should be 0x2 and I think that the sectors per cluster should be lower than 0x802.

My question is why are these values injected by mtools?
Is there an alternative tool? I like the fact that it writes the MBR/VBR and according to its man page: "Use the bootsector stored in the given file or device, instead of using its own. Only the geometry fields are updated to match the target disks parameters." So that I can easily change what disk I am using (image or physical disk) and mtools takes care of filling in the partition table and bpb.

For some reason it does not seem to be working.
Could someone please offer some advice?

Regards,
Andrew

[bluemoon]

Is there an alternative tool?

My choice is to write my own tool. But don't worry, the tool only need to generate an empty disk image - which require only a few tens line of code.
With the blank disk image you can then mount it as loopback device.

Furthermore, if CD is an option you have more alternatives.

[AndyB]

Is there an alternative tool?

My choice is to write my own tool. But don't worry, the tool only need to generate an empty disk image - which require only a few tens line of code.
With the blank disk image you can then mount it as loopback device.

Furthermore, if CD is an option you have more alternatives.

I had originally set out to write my own tool, shouldn't be too difficult. Its not about generating the empty disk, its about having the partition table and BPB fields filled with right values at time of generating the image not hard coded.

[bluemoon]

Why hard-code? Those value can be calculated from parameters provided by user, like disk-size.

[Combuster]

Use the bootsector stored in the given file or device, instead of using its own. Only the geometry fields are updated to match the target disks parameters.

In other words, if you tell mtools to include a bootsector, *your* bootsector must already contain perfectly valid values. You're expecting mtools to do things the document says it doesn't do and blaming the tool for that.

[AndyB]

Use the bootsector stored in the given file or device, instead of using its own. Only the geometry fields are updated to match the target disks parameters.

In other words, if you tell mtools to include a bootsector, *your* bootsector must already contain perfectly valid values.

My interpretation of that is that it will use the bootsector in the specified file but it will update the geometry fields within the boot sector to match the target disk. If "the geometry fields are updated to match the target disks parameters" does not mean that it will correct the BPB values, then what does it mean?

You're expecting mtools to do things the document says it doesn't do and blaming the tool for that.

As mentioned, it is my interpretation that this is what the document says that it does this. I have not placed blame or flamed anywhere, I merely inquired as to why I was not getting the results that I expected.

If it is the case that mtools wont touch the BPB values and that my VBR must contain correct values than why are does the number of FATs get changed. In both of the BPBs posted above, the total number of FATs field is set to 0x02 and yet after formatting with mtools it is set to 0x00.

[egos]

Both very similar except for the single byte difference in the reserved space (13 vs 12 bytes).

Use 12.

From all of the examples that I can find, the first step with FAT32 is to calculate the first data sector as (Sectors Per Fat * Total Fats) + Reserved Sectors.

Don't forget about HiddenSectors.

Code: Select all

	; compute location of root directory and store in 'ax'
	xor     ax, ax
	mov     al, BYTE [BPB_TOTAL_FATS]                ; number of FATs
	mul     WORD[EBPB_SECTORS_PER_FAT]              ; sectors used by FATs
	add     ax, WORD [BPB_RESERVED_SECTORS]          ; adjust for bootsector

"Sectors per FAT" (FATSize32) is 32-bit field. I use special routine that calculates datapos, a(ctive)fatpos, starting sector of cluster values by formula dword = dword + dword*byte:
datapos = (HiddenSectors+ReservedSectors) + FATSize32*FATs
afatpos = (HiddenSectors+ReservedSectors) + FATSize32*ActiveFAT
basesec = datapos + (cluster-2)*SectorsPerCluster
If you don't use 32-bit registers you should implement "double multiplication" operation because one of your multiplier is 32-bit.

I know that the total fats should be 0x2 and I think that the sectors per cluster should be lower than 0x802.

Did you mean "sectors per FAT"? "Sectors per cluster" value can be 1, 2, ..., 64, 128 (not recommended).

Is there an alternative tool?

I use fasm to make test disk images. I use own setup tools to install boot loaders separately (setupmbr/setupldr). Sometimes I use short scripts as well. For example:

setupldr.cmd

Code: Select all

@echo off
dd bs=1 count=3 if=boot.bin of=%1 2>NUL
dd bs=1 count=422 if=boot.bin of=%1 skip=90 seek=90 2>NUL
dd count=1 if=boot.bin of=%1 skip=1 seek=2 2>NUL
echo All done.
pause

backup-dump-setup.cmd

Code: Select all

@echo off
call c3 %1 backup.bin
fasm dump.asc dump.bin
call c3 dump.bin %1
echo All done.
pause

[JamesM]

Use the bootsector stored in the given file or device, instead of using its own. Only the geometry fields are updated to match the target disks parameters.

In other words, if you tell mtools to include a bootsector, *your* bootsector must already contain perfectly valid values.

My interpretation of that is that it will use the bootsector in the specified file but it will update the geometry fields within the boot sector to match the target disk. If "the geometry fields are updated to match the target disks parameters" does not mean that it will correct the BPB values, then what does it mean?

Like you just said - mtools will update the geometry fields but nothing else. So you can't expect the number of FATs to be modified by mtools.

[AndyB]

Like you just said - mtools will update the geometry fields but nothing else. So you can't expect the number of FATs to be modified by mtools.

Ok so the problem lies in my understanding of what the "geometry fields" are, I thought that this covered all of the values in the BPB (eg if I used "-H 2" it would set the BPB Hidden sectors field to 0x02.

Does anyone happen to know what exactly what fields get updated?

If I cant expect the number of FATs to be modified by mtools then how can I explain that in the coded BPB it is defined as 0x02 but after formatting it has a value of 0x00.

As per the suggestions and egos' kind script examples I am going to try write a script to complete the task rather than use mtools. (Only because I am obviously using it wrong myself and not because I think that it doesn't work).

Andrew

[JamesM]

The geometry fields will be the size of the volume - NumberOfSectors32 (FAT32), NumHeads,NumCyls,NumSectors.

That is, if mtools refers to "geometry" in the "normal" way.