[parisc-linux] Re: Status SPIFI SCSI
Christoph Plattner
christoph.plattner@gmx.at
Tue, 17 Sep 2002 23:31:28 +0200
Hello,
the problem I wanted to point out is, that not the SCSI
interface problem is the point.
IMO we have a simple (take the word "simple" not too
critical ...) software setup problem. It seems, that
we do not access the chip physically.
I have no NDA, I have no possibility to look into the
source codes of HP-UX (but I want to have it !!), I have
no hardware docu, no chip docu (although I am able to
read them and I want to have access), so my help here
is very restricted !!!
But one small hint: The "chip selelct" line and the
low order address bits, to see if there is really a
hardware access to this chip. Further perhaps the
read and write control line. I do not know the
HP own bus system (I also miss such documentation),
but I use simple the words of a standard bus access
(RD, WR, CS or CE, address lines, data lines).
HOW CAN I GET DOCUMENTATIONS ????
Bye
Christoph
Thibaut VARENE wrote:
>
> Le mardi, 17 sep 2002, à 20:33 Europe/Paris, Christoph Plattner a écrit
> :
>
> Hi Christoph,
> > Hello Ryan,
> >
> > I think usinf the logic analyser will not help you on the
> > SCSI bus. You need the logic analyser on the SPIFI chip!!!
> That's not a problem,
> atm we have a 16channels analyser (we can have up to 128 if needed),
> we tried using the HP 2423A SCSI preprocessor, but ours seems b0rken,
> therefore we decided to plug directly onto the scsi board.
>
> So plugging onto SPIFI chip shouldn't be a pb, as long as we have its
> pinout,
> so that we can isolate signals we're trying to find.
>
> So if you can provide us with the pin numbers we should plug on,
> that would help a lot ! :)
> >
> > As I already mentioned in another mail, I think, we
> > DO NOT access the real device. As I have mentioned,
> > we only read out 0x0000ff00 at each address and we
> > "write" the SCSI command in an invalid space ! So this
> > is "OK", that the chip do not produce any interrupts !
> >
> > I think, this is a very basic problem of the bus or
> > i/o bus initilization or the Loquix init, or whatever.
> >
> > I do not expect any frame on the SCSI output !
> >
> > Bye
> > Christoph
> >
> >
> > Ryan Bradetich wrote:
> >>
> >> Hello Christoph,
> >>
> >> On Sun, 2002-09-15 at 17:25, Christoph Plattner wrote:
> >>> Hallo Ryan,
> >>>
> >>> here some comments on my non-successful work so far.
> >>>
> >>> I did code reading and used debug instrumented code
> >>> to understand the structure behind the linux SCSI
> >>> handling.
> >>>
> >>> Further I studied the NetBSD code.
> >>>
> >>> One major point: We do not get any interrupts.
> >>> For my analysis I only had a look on the first
> >>> steps of SCSI initialization, so this was the
> >>> INQUERY command.
> >>
> >> This is where I am also currently stuck :( The
> >> ESIEE guys are going to hook up an analyzer to the
> >> box and see if the target device is getting the command
> >> (ie... did we send the command correctly to the device)
> >> or if the device returns a command (do we catch the
> >> command the device is returning). I have been studyting
> >> the setup routines in the HP-UX driver and I believe
> >> I have the chip initialized properly ... but I am not
> >> sure why I am not getting any interrupts. Hopefully
> >> between ESIEE, you, and myself and anyone else
> >> interested we can figure this out.
> >>
> >>> The spifi command routine is called correctly,
> >>> but it has a wrong logical implementation. As I
> >>> have seen on other (older) linux driver, the
> >>> xxx_command() has to block, after the command was
> >>> successful completed by interrupt. But the interrupt
> >>> never comes !! Even a "long" delay for simulating
> >>> blocking does not solve this problem.
> >>
> >> That is highly possible. The driver skeleton is just
> >> a test harness for me right now. I am just trying to see
> >> what I can get returned from the spifi chip (that is why
> >> most of the functions are stubs with printk. Once I see
> >> an interrupt come in, I'll start working on putting that piece
> >> togeather.
> >>
> >>> From base of the NetBSD code, I cannot follow your
> >>> code resetting the spifi subsystem. I think you have
> >>> this from HP-UX code. Especially the
> >>>
> >>> __raw_writel(CMD_RESET, dev->hpa + IO_MODULE_COMMAND);
> >>
> >> Yes, this is part of the initizlization from the HP-UX
> >> driver. The Loquix chip sits between the HP-PB bus, and
> >> the spifi scsi chip. According to the HP-UX driver, the
> >> Loquix chip also required some setup. Once again, I
> >> do not actually have the Loquix documentation, but I might
> >> have a lead on it. Will have to wait and see if that lead
> >> pans out.
> >>
> >>> Is this a reset method via the IO PDC address space
> >>> common for all HP devices ? In the NetBSD the full
> >>> reset is done only via the `auxctrl' register, which
> >>> you use for releasing the reset state.
> >>
> >> I am not sure about all the HP devices. It might be an iodc
> >> specific call. I will have to look at the driver again,
> >> but that might reset the loquix chip *shrug* I'll take
> >> a look and see what I can find.
> >>
> >>> So we have a principal problem here, not having correct
> >>> access to the spifi subsystem. Except: the SCSI-ID is
> >>> read out correctly, I think, as ...
> >>>
> >>> SCSI subsystem driver Revision: 1.00
> >>> DEBUG: 0xfff74c00
> >>> Device: Sahp Baat Kiuh SCSI
> >>> scsi0 : SPIFI SCSI: scsi_id: 7 IRQ: 34 type: SPIFI-3 (SE) parity
> >>> checking: enabled
> >>>
> >>> ... is reported !
> >>
> >> That is where I am also. We actually read the type SPIFI-3 (SE) for
> >> the
> >> SKUNK card, and SPIFI-3 (DF) for the wizard (16-bit) card. I have
> >> tested this on both cards so I know it works. I am convinced we are
> >> reading the correct information from the card, but what I am not
> >> convinced of is that we have it setup properly yet :) The problem is
> >> I
> >> do not know what I am missing yet :(
> >>
> >>> Is everything around the interrupt subsystem setup correctly ?
> >>> The `cat /proc/interrupts' tells ...
> >>>
> >>> bash# cat /proc/interrupts
> >>> CPU396195552
> >>> 32: 124925 PARISC-CPU timer
> >>> 33: 19767 PARISC-CPU lasi
> >>> 34: 0 PARISC-CPU spifi
> >>> 87: 19767 Lasi i82596
> >>>
> >>> ... which is no surprise ... !
> >>>
> >>
> >> I do not think the fact the interrupt is registered is very
> >> infomative,
> >> I think you can register an interrupt for device even if it doesn't
> >> have
> >> an real irq assocaitated with it (ie... the serial mux).
> >>
> >> Yeah, thanks for looking at it ... we will have to beat on it some
> >> more
> >> and see what we can find. Hopefully the ESIEE guys will be able to
> >> provide us with some good information!
> >>
> >> Thanks
> >>
> >> - Ryan
> >>
> >>> Till soon,
> >>> Christoph P.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> -------------------------------------------------------
> >>> private: christoph.plattner@gmx.at
> >>> company: christoph.plattner@alcatel.at
> >>>
> >>
> >> _______________________________________________
> >> parisc-linux mailing list
> >> parisc-linux@lists.parisc-linux.org
> >> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> >
> > --
> > -------------------------------------------------------
> > private: christoph.plattner@gmx.at
> > company: christoph.plattner@alcatel.at
> > _______________________________________________
> > parisc-linux mailing list
> > parisc-linux@lists.parisc-linux.org
> > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at