mikeh@killer.UUCP (Michael Hammond) (06/02/88)
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:
which I expected. At this point I looked at the bootstrap for a non-rll
vs a rll and find that while the non-rll bootstrap looks like code the
rll bootstrap looks like a table has ovrewritten it. Calls to tech support
and notes on the bulletin board have left me with no answers, just frustration.
Is there anyone out there that has gotten the new driver to work with
>17 sectors? If so did you have any trouble? Any Compaq 386/20 's out there
that have had better luck? E-mail me please. If a work around is found
I'll post it.
Thanx in advance
Mike Hammondbrian@cbw1.UUCP (Brian Cuthie) (06/03/88)
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!"
ewv@zippy.berkeley.edu (Eric Varsanyi) (06/04/88)
In article <184@cbw1.UUCP> brian@cbw1.UMD.EDU (Brian Cuthie) writes: >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 [...] >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.
jack@turnkey.TCC.COM (Jack F. Vogel) (06/05/88)
In article <184@cbw1.UUCP> brian@cbw1.UMD.EDU (Brian Cuthie) writes: >In article <4274@killer.UUCP> mikeh@killer.UUCP (Michael Hammond) writes: >> [ Stuff about not getting a boot prompt with new driver deleted ] > >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. As far as I know Microport relys on the ROM not only during boot but during actual operation as well, at least this was what I've heard. [ Stuff about hacking and burning a new ROM deleted ] This may not be happy news if you have already puchased an RLL controller but for those of you who have not there is a much better solution than custom burning the BIOS. Adaptec's RLL contoller, called ACB-2372 has its own BIOS that it will map into the drive table area, thus eliminating the need for fiddling with a rom burner. This ability is geared toward DOS users ( under SCO you don't really need it, we have it disabled ) but it sounds as though it might be just the thing for uport users as well. For those interested, we are running the 2372 controller with two Micropolis drives, a 1335 and I believe a 1330, under SCO 2.2.1. We disable the onboard bios and format with WD's 2.1 release format program (it does RLL and I think even ESDI). Interleave is 1 - 1. Given the nature of SCO's hdinit program you don't even need to worry about cmos, we just leave the old 17sec. entries in place. The Core test reports a throughput of 759K bytes/sec, performance under Xenix is great although I have no hard comparative data to present at the moment. I highly recommend this route as an economical alternative to going to full ESDI. If anyone out there is adventursome enough to give this hardware a test with Microport and can report on the results I would be very interested to hear your findings. Oh, by the way, the Adaptec line of controllers are available through Hamilton-Avnet. Single quantity on the 2372 was $145. Best of luck, -- Jack F. Vogel Turnkey Computer Consultants, Costa Mesa, CA UUCP: ...{nosc|uunet}!turnkey!jack Internet: jack@turnkey.TCC.COM
zeeff@b-tech.UUCP (Jon Zeeff) (06/06/88)
In article <211@turnkey.TCC.COM> jack@turnkey.TCC.COM (Jack F. Vogel) writes: >In article <184@cbw1.UUCP> brian@cbw1.UMD.EDU (Brian Cuthie) writes: >If anyone out there is adventursome enough to give this hardware a test with >Microport and can report on the results I would be very interested to hear >your findings. Oh, by the way, the Adaptec line of controllers are available >through Hamilton-Avnet. Single quantity on the 2372 was $145. > If anyone gets the Adaptec RLL controller to work on uport '386 unix w/o a new bios, please let us know. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
rbradbur@oracle.UUCP (Robert Bradbury) (06/06/88)
I am running a Compaq 386/16 with a WD1007A-WAH controller attached to
a Miniscribe 9380 Drive (15 hds, 34 sec/trk, 1224 trks) with about 195 Mb
available to UNIX and 64 Mb (in 2 partitions) available to DOS. I am
running UNIX 5.3 R2.2 with the new ESDI disk driver (beta release) and
have Merge 1.0 running under it.
... and believe me it was a S!$% load of work to get it working. I think
I reloaded the system a total of 9 times from floppies.
My recomendations would be:
- Get a good controller (like the WD1007). It handles 1:1 interleave,
has an on-board track cache, an on-board BIOS to format the disk,
setup alternate sectors (in the same track) from the manufacturers
defect list or can scan the entire disk if necessary. It increases
disk I/O speed on my machine from something like 323Kb/sec to 793Kb/sec
(using the Coretest utility). I think it cost me $220 from my local
Western Digital distributor.
- Throw out the standard Microport INSTALL script. It isn't going to
configure it the way you want anyway. The standard UNIX layout has
the boot cylinder (with the VTOC & Alternate sectors), followed by DOS,
followed by UNIX. It makes much more sense if you have to assign
alternate sectors (in UNIX) to have the UNIX partitions as close to
the alternates as possible and stick the DOS partition(s) after UNIX.
The best way to do this is to make a copy of the boot disk, setup the
files /tmp/partitions, /tmp/fdisk.data and /tmp/mkfs.data on it the
way you want your disk configured and then edit the install script
to use them (instead of using disksetup). The 3 key steps are:
- use mkpart to initialize the boot cylinder (-i)
- use fdisk to setup the partition table
- use mkpart to setup the VTOC and and write /etc/boot to the
boot track on the root
Then proceed with the mkfs's and copies as they are done in the
install script. It is easy if you are doing the configuration
to a 2nd hard drive. It is hard if you have to configure the boot
floppy to do things right after you have reformatted your only
hard disk. You might want to add some files; cat, ls, mknod, ed
to the standard boot floppy and fix /etc/inittab so you can boot
the floppy in single user mode (with a shell).
- MAKE SURE YOU HAVE EXTRA COPIES OF THE BOOT FLOPPY!! If UNIX
crashes or hangs when you are trying to setup the new hard disk
it will more than likely trash your floppy. Usually it "unformats"
track 1 of the floopy (don't ask me why cus I don't know).
- Don't try to use more than 1024 cylinders on the disk. None of the
software (UNIX, mkpart, fdisk, etc.) gives errors with larger cylinder
numbers but I'm fairly sure that those cylinders end up overlapping
lower ones.
- Ignore the documentation Microport sends out with the beta release
of the ESDI driver. Most of the files listed are not in the link
kit and one which is not listed (fd.o) but is on the disk will prevent
you from relinking with UNIX with Merge included. You *MUST* use the
new ESDI hd.o and the Merge link kit fd.o if you want to link UNIX
with Merge. (Microport doesn't think you can do this but it seems to
work for me.)
- Delete your old UNIX systems when you have the new system running.
Booting an old system can scramble your file systems.
I'd advise anyone undertaking a reconfiguration/reinstall be fairly
adventursome and be willing to spend some time with this. Though the
driver itself seems to be good the process of configuring the system
can be a nightmare.
--
Robert Bradbury
Oracle Corporation
(206) 784-9726 hplabs!oracle!rbradbur