Path: utzoo!attcan!uunet!seismo!sundc!newstop!sun-barr!cs.utexas.edu!mailrus!cornell!uw-beaver!fluke!ssc-vax!bcsaic!paula
From: paula@bcsaic.UUCP (Paul Allen)
Newsgroups: comp.os.minix
Subject: Re: Booting Minix from 1.44m floppies (long)
Message-ID: <18823@bcsaic.UUCP>
Date: 11 Jan 90 19:06:03 GMT
References: <7806@nigel.udel.EDU>
Reply-To: paula@bcsaic.UUCP (Paul Allen)
Organization: Boeing Computer Services AI Center, Seattle
Lines: 60

In article <7806@nigel.udel.EDU> Peter_Van_Epp@cc.sfu.ca writes:
>The following uue encoded shar file will allow Minix to be booted from 1.44m
>3.5 inch floppies (and 1.2m AT floppies and 720k 3.5 floppies and last but
>not least 360k 5.25 floppies) and has been booted succesfully from all of them!

Great!  Thanks!

[Description of problems determining floppy type]

>To fix this (and to start addressing a similar problem in floppy.c!) I looked
>at the data in the DOS boot sector (in Advanced MSDOS by Ray Duncan good book!).
>and discovered that the total number of sectors, number of sectors per track,
>and number of heads are written into offset 0x13 to 0x1B of the boot block.
>I have now modified bootblok.s (here in source form since the cdif was 10k and
>the source was 11k and change!), build.c and the makefile. 
[...]
>                At boot time, bootblok.s has been modified to read the 
>total size of the disk from location 0x13 (put there by build) and checks that
>it is one of 720, 1440, 2400, or 2800 sectors (360k etc.) and selects the 
>correct parameter block for the floppy controller (or complains if the drive
>doesn't match!). As mentioned, this code has been used to succesfully boot
>all of these disks (and 720k in 1.44m drives but not 360k in 1.2m) and it all
>seems to work. I intend to now look at doing the same thing to floppy.c and 
>mkfs  [...]

All this is fine for boot disks and disks with filesystems on them.  People
tinkering with code to do floppy formatting under Minix should probably try
to create a bootblock as close to the one DOS creates as possible.

But please remember that not all floppies have boot blocks.  Since I have a
nice big hard disk, I almost never put a file system on a floppy.  99% of my
Minix floppies contain raw data such as tar archives.  I suppose we could 
redefine the meaning of "raw device" such that the first block on a floppy is
reserved, but that invalidates all my existing backup disks.  It would seem that
the only reliable way to 'discover' the media type at run time is to try
various combinations of sector numbers and track numbers to find out what works.
Does it destroy a 40-track drive if you seek to track 41?  Is there a hard
stop that prevents seeking one track past the last track?

Here, briefly, is a restatement of what I think may be a solution for the
floppy problem:

Create dev_open() and dev_close() routines to replace the floppy driver's current null
routines.  The new fl_open() uses some heuristic (probably some combination of seeks 
and reads) to determine the drive/media combination.  A message is sent to fs informing
it of the current size of the device.  Now fs can do the right thing at end-of-volume
without the size-in-the-inode kluge.  The floppy driver doesn't need the logic to
try different values for the drive/media code, since fl_open() has already figured it
out.  The new fl_close() routine sends a message to the fs invalidating the device
size information for the drive.

I haven't implemented any of this, and probably won't have time to try for another
week or so.  If anybody can see problems with what I propose, please let me know.
(Gently, please!  I'm a sensitive sort of guy!  :-)

Paul Allen
-- 
------------------------------------------------------------------------
Paul L. Allen                       | pallen@atc.boeing.com
Boeing Advanced Technology Center   | ...!uw-beaver!bcsaic!pallen