Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.hawaii.edu!ames!agate!tfs.com!tfs.com!julian
From: julian@tfs.com (Julian Elischer)
Subject: Re: It works, thanks, a few problems (Re: New scsi system beta3 (part 1 of 10))
Message-ID: <1992Oct7.085143.11262@tfs.com>
Organization: TRW Financial Systems
References: <1992Oct3.035858.13004@tfs.com> <BvqCEE.6FB@gate.demon.co.uk>
Date: Wed, 7 Oct 1992 08:51:43 GMT
Lines: 141
In article <BvqCEE.6FB@gate.demon.co.uk> ronald@gate.demon.co.uk (Ronald Khoo) writes:
>julian@tfs.com (Julian Elischer) wrote:
>
>> # This is a shell archive.
>
>Verily! Well, I've just tried it out with a aha 1742 and a horrid
>cheapo disc we had lying around, and didn't have too many problems.
>I started out with a stock 0.1, added Terry's beta patch kit, and, after
>upgrading to gcc 1.42 (2.2.2 is being compiled at the moment)
>the next step was to try out Julian's driver.
>
>My problems were:
>
> a) had to create a zero length pio.h file to keep aha1742.c
> happy (perhaps should omit the #include line from the .c file ?)
> Just curious: what is pio.h ?
My apologies... pio.h was in the boot blocks distribution and contains
inline macros for inb()... inl() and outb()...outl()
>
> b) locore.s didn't seem to have outl and inl defined.
> My 386 is close to nonexistent, so I guessed this:
> (is it right ?)
>
> .globl _inl
>_inl: movl 4(%esp),%edx
> subl %eax,%eax # clr eax, presumably unnecessary ?
> NOP
> inl %dx,%eax
> ret
>
> .globl _outl
>_outl: movl 4(%esp),%edx
> NOP
> movl 8(%esp),%eax
> outl %eax,%dx
> NOP
> ret
you are right, but use the macros in pio.h in preference.. they are faster/smaller
>
> c) The readme isn't quite clear about bootblocks to use ..
> Does it refer to using the standard asboot/bootas ?
> Disklabel seems to be unhappy if I don't specify them at all,
> but I don't actually want to boot off the slow old SCSI,
> since it's fine for archival use, but not much else.
> But for reference, I'd like to know which bootblocks the
> README refers to.
Using the 1542, the standard as bootblocks will work, but not
give you a choice at boot time. The New bootblocks (see your local
archive site)_ (yes the ones with pio.h 8-) use the BIOS
They however fail on a 1742 even in 1542 emulation mode.
so you HAVE to use the new ones.. But there is a catch.
You need to run the 1742 in 1542 mode because for a reason I
have not yet worked out, they do not like it in extended mode.
THIS IS OK, because as soon as the kernel spots the board,
it throws it into extended mode anyhow.
>
> d) I agree that a system for encoding target/luns into the system
> would be nice. The old drive I'm playing with seems to
> answer to ALL LUNs that the probe asks for, so the probe
> sees 8 devices where there is only one. I got fed up
> so I hacked the probe to look for LUN-0 only, and that
> seems to work fine, but I'd be interested to hear of a
> neater way to cope with old kit like this.
>
Actually I prefer NOT encoding the luns. but many people seem to want it
so it will probably happen. (but only as an option.. I prefer my way
8-)
The correct way of getting around broken devices that respond to ALL
luns has not been written yet, but this is how I plan to do it..
When you match a known device to the returned inquiry data,
one field in the matched table entry is a field that says
" Skip all other LUNs" So by default if a device
had this problem, you could set that bit on a table entry
that matched it closely, and wherever that device showed up
then other LUNs would not be looked at. The default disk
matching entry could probably have this bit set because
boards with multiple LUNs such as the aha4000 are getting so
rare now.
> e) it seems to be a fairly large driver, and I didn't seem to
> be able to delete the tape and cd sub-drivers (but then
> I haven't tried very hard yet). So I had to take quite
> a lot of stuff out of my kernel to get it small enough to
> boot.
>
to leave them out, just don't have them in the configuration file
I have some plans that will make them smaller, but unfortunatly,
making it modular means making it bigger, but a lot of the 'almost
duplicated' sections may get consolidated in the future. If
someone can patch the kernel so that it can be loaded above
1MB then the size wouldn't matter SO much, biut I agree, it
needs shrinking.. but I concentrated on getting it working first.
> f) I guessed that the geometry to use in calculating disktab
> was the rigid geometry as reported by the probe and not the
> BIOS remapped geometry ? Well it seems to work like that.
> Does this not have implications for /386bsd lying beyond
> 1024 cylinders or am I barking up the wrong tree ?
I think you're barking up the wrong tree.
The problem will occur with the DOS boot blocks first when the start of
the 386bsd partition is beyond the furtherest block BIOS can get to
(>1GB)
for 386bsd itself, it handles block numbers as a straight 32 bit integer
i.e. 2^32 x 512 byte blocks.. big enough?
>
>Lots of questions I know, but I'm sure lots of people would ask the same
>ones, so may I perhaps suggest that the author include a Q&A section
>in his next distrib ?
did you read the various README files?
also, I probably realy should make sure the boot block distribution
is made at the same time as the scsi distribution, and I should
put pio.h in both
>
>In any case, thank you for your wonderful work.
thanks
+----------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / On assignment
| / \ julian@tfs.com +------>x USA \ in a very strange
| ( OZ ) 2118 Milvia st. Berkeley CA. \___ ___ | country !
+- X_.---._/ USA+(510) 704-3137(wk) \_/ \\
v