Xref: utzoo comp.unix.microport:768 comp.unix.xenix:2378 Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!cmcl2!brl-adm!umd5!umbc3!cbw1!brian From: brian@cbw1.UUCP (Brian Cuthie) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: Re: Microport Support for RLL Message-ID: <184@cbw1.UUCP> Date: 3 Jun 88 01:48:00 GMT References: <327@bdt.UUCP> <4274@killer.UUCP> Reply-To: brian@cbw1.UMD.EDU (Brian Cuthie) Organization: CBW, Columbia, MD 21046 Lines: 71 In article <4274@killer.UUCP> mikeh@killer.UUCP (Michael Hammond) writes: > > After hearing about the new RLL driver on the uport bbs I downloaded >it, built a new kernel, and ran the build on the system. Everything worked >just great! When I went to boot up the hard disk for the first time to install >the rest on the runtime system it died! I got > >............... > > >but not > > >............... >boot: 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 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. To fix the ROM, to include the correct number of sectors, you must have access to a ROM programmer and some appropriate ROMs. It is important to subtract, from another drive entry, the number of sectors added to the new entry. In otherwords, if you change an entry from 11 (hex) sectors per track to 22 (hex), be sure to subtract the 11 (hex) additional tracks from some other entry that you do not plan to use. Otherwise, the checksum gets munged and nothing works. I'm sure there is a better way to do this but, not knowing where the checksum code was, I decided this was the quickest fix for my problem. I have done this successfully and would be more than happy to give advice to anyone who wants to call. The ROM drive tables are described in the AT technical reference manual from IBM. They usually start at offset 6401 (hex) in the ROMs. 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. Incidentally, the new symptom is: ............. boot: /unix ------> Can't find /unix 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... I'll post whatever I find tomorrow from Microport about the second stage boot. -brian (301) 290 - 7443 -- Brian D. Cuthie uunet!umbc3!cbw1!brian Columbia, MD brian@umbc3.umd.edu "Captain, Captain! All the stars have gone out!" "No, you fool, you've leaned on the button. Turn the viewer back on!"