OSDev.org

hi, while doing some work on my vfs and fat12 driver i'm having trouble figuring out where to put my lba2chs routine. i thought it was dead simple. i put it in the fdc driver, so that the fs/vfs code can use lba when talking to the fdc driver - but the values needed for the conversion is loaded from the bootsector in my fat12 code with direct chs values for now.

i feel like i got a chicken and egg scenario here. i need to load the bootsector to get the sectors per track and heads values, but i can't do that if i don't use direct chs. and i want to remove chs from the fdc.. so erhm.. also, when adding support for more file systems i would need another way of getting this. i would imagine that the same applies for a future hdd driver, at least if i'm supporting the older types.

i'm guessing the bios has this information somewhere, but would i really have to go back to 16 bit mode when initializing the fdc driver and in the future also for my hdd driver? and if not, if i try to get all this before entering pmode, how would i even know what drive number corresponds to what values, what drives there is to begin with, and that the bios actually has support for everything where i might need those values?

i haven't slept for quite a while so tell me if i'm having some kind of braindead moment here, or what the hell i'm suposed to do about this. i could just use hardcoded values for 1.44mb floppies right now and pretend like nothing.. but no, that just feels wrong, what if i found some old 386 or 486 with a 5.25" floppy and decides to add support for it.

advice from wiser (and more well rested) men appreciated!

For my design, the disk driver(or storage manager) need to read the boot sector to get basic information (including the fs type) in order to select fs driver.
So, you may just read the first sector on floppy by fdc driver, check the geometry *and* fs type and do initialization.

well, for me i let the fs drivers read the bootsector and tell if the fs is a match or not - not the device driver. i figured that the device driver shouldn't know about fs types and that i can loop a probe function for each fs driver i have instead. with maybe max 10-20 fs drivers (if i'm lucky and lives until a 100) and disk cache for most accessed sectors that would be fast enough.

i could add code to load first sector in the device driver itself too - and probably have to in order to support partitions on hard drives. but that won't help if the filesystem doesn't store tracksize and heads. so that's like a fat only solution, right?

also, i got functionality to drop back into real mode - but how would i even know which bios drive number something that i have detected corresponds to? at least that is how i expect any bios function to work, give it a bios internal drive number and get drive parameters out?

i'm not even sure how something so seemingly trivial can become an issue. i'm never going to finish or be satisfied...

bubach wrote:but that won't help if the filesystem doesn't store track size and heads. so that's like a fat only solution, right?

I think you only need geometry for floppy and ancient harddisk, if you rule out non-FAT floppy, the only problem is ancient harddisk which you may get info at boot stage and somehow match it in the OS(by vendor string or first sector's checksum).

bubach wrote:well, for me i let the fs drivers read the bootsector and tell if the fs is a match or not - not the device driver. i figured that the device driver shouldn't know about fs types and that i can loop a probe function for each fs driver i have instead. with maybe max 10-20 fs drivers (if i'm lucky and lives until a 100) and disk cache for most accessed sectors that would be fast enough.

For me, the storage manager ask the disk driver to create a partition list (single entry if no partition); the disk driver read the first sector, process it if partition table;
then for each partition it get the file system id, read the first sector(it's already read if no partiton table) and pass to that fs driver; if that fs driver refuse to handle it, the sector buffer is passed to all fs driver and see who want to handle that.

Well, the filesystem need not even be involved in the FDD mess - after all there are so many FD standards that you will have to find out if you're dealing with a 360k/720k/1.2m/1.4m/2.8m medium to be actually able to read it - and then we haven't even had all the standard-breaking formats meant to get more out of your floppy.

Also, the exact sector layout is stored on the floppy medium (and can theoretically differ per track) and only a copy appears in FAT's superblock. Therefore the FDC is the codebase to know what the CHS translation (and sector size) actually is.

Yeah, I have to do much more precise detection in my floppy and future hard disk drivers in the future. I'm investigating right now. But I am getting more and more picky about not assuming stuff, and for floppies I could assume sectors per track and heads based on the CMOS value for 1.44mb, 720kb and so on, but to be even more pedantic there's no guarantee that some low level format didn't change that on individual floppies - right?
And asking the BIOS just seems like a mess too - so I'm gonna try and see if I can directly talk to the floppy drive and see what information it can provide, been years since I dug into the FDC manuals.

I probably have to assume some values for now to get something done and get back to it some other time - even if I feel it sucks.

Hi,

bubach wrote:Yeah, I have to do much more precise detection in my floppy and future hard disk drivers in the future. I'm investigating right now. But I am getting more and more picky about not assuming stuff, and for floppies I could assume sectors per track and heads based on the CMOS value for 1.44mb, 720kb and so on, but to be even more pedantic there's no guarantee that some low level format didn't change that on individual floppies - right?

For some cases (e.g. different low level format on each track), the best option is not supporting it (e.g. assume all tracks are formatted the same), getting it wrong, and returning whatever error happens first.

bubach wrote:And asking the BIOS just seems like a mess too - so I'm gonna try and see if I can directly talk to the floppy drive and see what information it can provide, been years since I dug into the FDC manuals.

I've done that before. My approach was to have a table containing all the details for each media format the OS supports; then have a series of tests to narrow down the possibilities from "could be anything" to "this is the only option left".

First step is detecting the data rate and sector size - try to read the first sector on the first head on the first track (for each possible combination of data rate and sector size, in order from "most likely" to "least likely") until you successfully read it; then eliminate any formats that don't match.

If there's more than one format left (and they use a different "sectors per track" value), the next step would be trying to read the last sector on the first head on the first track (in order from "largest sectors per track" to "smallest"); then eliminate any formats that don't match.

If there's more than one format left (and they use a different "total heads" value), try to read the first sector on the second head on the first track; then eliminate any formats that don't match.

If there's more than one format left (and they use a different "total tracks" value), try to read the first sector on the first head on the last track (in order from "most total tracks" to "least total tracks"); then eliminate any formats that don't match.

After all that you should know exactly which format the disk uses; unless the disk uses a format that your OS doesn't support anyway.

For an example, the first test might tell you the floppy uses 512-byte sectors and a data rate of 1 Mbps. That narrows it down to 1720 KiB, 1680 KiB and 1440 KiB formats. The second test might tell you there's 21 sectors per track, so you'd be left with 1720 KiB and 1680 KiB formats. The next test won't help because both of these formats are "2 heads" (double sided) so you skip that test. The last test might tell you there's only 80 tracks, so now you know it's a 1680 KiB floppy.


Cheers,

Brendan

Yeah, I can tell this is going to be fun.. Ha ha, I'll have to revisit my older floppy driver source that was supposed to support 2 drives and other fancy stuff I never had the patience for at the time. This post could be worth looking into again for example: http://forum.osdev.org/viewtopic.php?f=1&t=10600
Thanks for the help, at least I don't feel quite as confused as I did in the middle of the night when I realized just how screwed up it all where.