Microport Support for RLL

[Eric Varsanyi]

In article <184 at cbw1.UUCP> brian at cbw1.UMD.EDU (Brian Cuthie) writes:
>In article <4274 at killer.UUCP> mikeh at killer.UUCP (Michael Hammond) writes:
>>
>>   After hearing about the new RLL driver on the uport bbs I downloaded
>>it, built a new kernel [...]
>AH !!  The problem, that you are facing, is that the RLL drive has more than
>17 sectors per track and the ROM BIOS doesn't know that.
It shouldn't have to, while it is convenient to have an entry in your bios
for your drive type, its not needed with (real) RLL controllers.

DTC's controller (and someone else's) have some on board RAM, when you
run their ROM based formatter, it asks for the drives paramters and
stores them in a secret teeny sector on C0T0, when the ROM bios call
the HD bios during boot, it reads this stuff off the disk and builds a
disk table entry for the drive (as it would look in the BIOS) and puts
it in its onboard ram. Then it points the hard disk vector (around
x'104) to this table and continues.

The RLL hd driver looks at this before it tries to read a VTOC and
configures appropriately. No new BIOS, minimal hassles. The only
problem is when the VTOC is wrong (you issued a bogus mkpart using
a partitions file for a 17 sector drive). The VTOC overrides the data
from the drive table and you are in trouble. 
 
>It seems that the First stage bootstrap depends on the ROM BIOS routines to
>read the partion table and then to read the Second stage bootstrap from the
>first track of the active partition.   The problem is that the ROM code
>thinks the drive has 17 sectors per track and thus munges the computation
>to the first track of the active partition.

Yes and no, the first stage loader uses the bios routines to read in the
second stage loader, but the BIOS does pay attention to the disk table.
As long as the controller does its trick correctly, your OK. Also, it
does not need the partitions table at this point, since the second stage
loader is just tacked on to the end of the first stage (on C0T0), all
is has to do is increment sector numbers and ask the bios for the next one.

>BUT: Once you've fixed this, you will find that the second stage bootstrap
>doesn't seem to be able to find the root file system.  This, I believe, is
>because the second stage bootstrap has some screwy 17 sector per track value
>hardwired into it.  I have been trying to contact Microport tech support to
>find out what the deal is, but we have been playing telephone tag.  I should
>know tomorrow.

Absolutely correct, the second stage loader looks for the VTOC at absolute
sector 17. The new loader look for the VTOC on the second track of the drive. (
(Whatever the geometry). It is on the Uport BBS I think.

>Incidentally, the new symptom is:
>
>	.............
>	boot: /unix
>------> Can't find /unix
>

A little trick here: If you use new boot code, make sure you put it in 
/etc/boot otherwise you will get the mess above if you add flaws with
mkpart -A (this unfortunately  re-writes the boot from /etc)

>I have spent a considerable amount of time looking at the "partitions" file
>that is built on the floppy by the program "disksetup" which is called in
>the "INSTALL" script.  I appears to be correct.  I have even mucked with it
>to try to move some things around (like the VTOC) to see if the second stage
>bootstrap would be any happier.  No luck though...

Unless you have a new disksetup, it does make a mistake, it puts the
VTOC on sector 17, the second stage loader wants it on the start of
the second track.