Re: Symbios 53c770 driver

[<fh...@at...>]

[ This is a forwarded copy of a message I sent to Richard Hirst and he
replied. regarding my CSPPC driver fun.  Any thoughts or suggestions are
welcome.  Or at least you will find it interesting. ;)]

Hi Fred,
  I don't know that the following will help much, but it shows my thought
processes anyway.  Let me know if you (dis)agree.

Richard


On Sun, Oct 15, 2000 at 08:04:41PM -0400, fh...@at... wrote: >
What follows is the dmesg from the 53c770 driver I am working on. AFAICT >
this cache test should be working.  What else can I try? I've been reading
> the Symbios programmers manual.  Does the DSA register mean anything to
> me?

DSA is not relevant to the snoop test.

> Do you know of anyway I can printout or see how the SCSI chip is seeing my
> main memory?  It appears to be accessing the script OK so maybe that's not
> an issue.  Perhaps the SCSI chip is not initialized correctly for the
> hardware?
> 
> >From looking at the Symbios manual, it looks like the chip
> is hardwired to "act correctly" by tying certain pins to their correct
> logic levels.
> 
> I would feel more comfortable changing over to your driver
> code, if I could get the cache test to work.  Then I would
> at least know that the chip can (probably) access the Amigas  memory all
> right.

Sure, if snooptest doesn't work in your driver it probably wont work in
mine either.

> Trying to detect PuP SCSI...
> ncr53c8xx: 53c770 detected 
> ncr53c770-0: rev=0x00, base=0xf40000, io_port=0x0, irq=12
> new NCB[2928] @c02f2000.
> Storing input
> new SCRIPT[3772] @c3f33000.
> new SCRIPTH[3708] @c3f32000.
> np: ID: 770 REV: 0 FEA: 15382 CLCK: 5 OF: 10
> Initialize timer
> paddr: f40000 paddr2: 0
> vaddr: 80f40000
> SCSI reset
> istat: 40
> cleared
> istat: 0
> test: aabbff11 aabbff11  <--- This value is written and read back from
> scratcha offset: c
> virt_to_phys(np): 82f2000
> np: c02f2000                        <---- The virtual address of the np
> data structure ncr_cache: 00000000 pc: 0bf32e50
> ncr_cache:ptr: c02f2058 val: 0 offset: 58    <--- The virtual address of
> the cache variable start=0bf32e50, pc=0bf32e50, end=0bf32e7c  <---
> Printout of the snooptest script. c0000004 082f2058    <--- The physical
> address of the cache variable? 00f40034 c0000004
> 00f4001c 082f2058

So the first script instruction is

c0000004 082f2058 00f40034

Move 4 bytes from 082f2058 to 00f40034.

082f2058 should presumably be a physical address for ncr_cache, as seen by
the NCR chip.  This shoud be an address in main memory.

00f40034 should be the address of NCR reg SCRATCHA, as seen by the NCR
chip.

You write DSP with 0bf32e50 which should also be a physical memory
address, as seen by the NCR chip.  We can assume that is correct, as
indeed the script does run.

If 082f2058 and 0bf32e50 are both in physical memory, I'd guess you have
physical memory from 0x8000000->0x0c000000 = 64MB.  I'd also say that the
memory is visible at physical address 0x8000000 to both cpu
(virt_to_phys(np) above shows that), and to the NCR chip (the PC value
written to DSP is in that range).

Also it seems the NCR registers are available at physical address
0x00f40000 and virtual address 80f4000.  I'd also
say that the memory is visible at physical address 0x8000000 to both cpu
(virt_to_phys(np) above shows that), and to the NCR chip (the PC value
written to DSP is in that range).

Also it seems the NCR registers are available to the cpu at physical
address 00f40000 and virtual address 80f400000.  The driver is assuming
they are available to the NCR chip at the same physical address.

> c0000004 082f2058
> 00f4001c 98080000
> 00000063 00000000
> 00000000 00000000
> 00000000 00000000
> 00000000 00000000
> 00000000 00000000
> np->ncr_cache: 00000005
> ncr_wr: 00000007
> cache addr: 82f2058      <----   A printf of the physical address of the
> cache variable t_istat: 1 dstat: 84 (1 128)
> dsp: bf32e7c dsps: 63 (200486524 99)  <----  The script seemed to run and
> exit normally sstat2: a (10)
> term pc: bf32e7c
> CACHE TEST FAILED: host wrote 5, ncr read 0 (0).  <--- cache test failed
> again but value
>                                                                            I
> put in scratcha has changed to 0 CACHE TEST FAILED: ncr wrote 7, host read
> 5.
> CACHE INCORRECTLY CONFIGURED.
> ncr53c770-0: detaching...

So, have I got this right?  Setup has:

ncr_cache variable set to 5
TEMP reg set to 7
SCRATCHA reg set to aabbff11

The script is run and should:

move ncr_cache (5) in to SCRATCHA
move TEMP (7) in to ncr_cache
move ncr_cache (now 7) back in to TEMP

That should result in:

ncr_cache variable set to 7
TEMP reg set to 7
SCRATCHA reg set to 5

But what you get is:

ncr_cache variable set to 5
TEMP reg set to 7
SCRATCHA reg set to 0

So, the only thing that changed is SCRATCHA.  That implies 00f40034 really
is the correct address for SCRATCHA as seen by the NCR chip. It also
implies that 082f2058 is NOT the correct address for ncr_cache as seen by
the NCR chip (but but we know the DSP value we are using is correct, as
the script runs).

So, why is the physical address of the script at the top of memory but the
physical address of ncr_cache down at the bottom of memory?

Are virt_to_bus() and virt_to_phys() the same on your platform?

np->scripth0 comes from m_calloc_dma(), and np itself comes from
__m_calloc_dma() [in my 2.4.0 ncr53c8xx.c, anyway].

I don't see why they should be in such wildly different areas of memory...

What kernel are you using? Mine is 2.4.0-testX, and all the memory
allocation is handled via SCSI_NCR_DYNAMIC_DMA_MAPPING.

> >My snooptest looks like this:
> 
> That is the same as in my code.
> 
> >}/*-------------------------< SNOOPTEST >-------------------*/,{
> >        /*
> >        **      Read the variable.
> >        */
> >        SCR_COPY (4),
> >                NADDR(ncr_cache),
> >                RADDR (scratcha),
> >        /*
> >        **      Write the variable.
> >        */
> >        SCR_COPY (4),
> >                RADDR (temp),
> >                NADDR(ncr_cache),
> >        /*
> >        **      Read back the variable.
> >        */
> >        SCR_COPY (4),
> >                NADDR(ncr_cache),
> >                RADDR (temp),
> >}/*-------------------------< SNOOPEND >-------------------*/,{
> >        /*
> >        **      And stop.
> >        */
> >        SCR_INT,
> >                99,
> >}/*--------------------------------------------------------*/
> 
> >so I'd expect the DSP at the end of the test to have moved on 11*4 bytes
> >= 0x2c.  Yours above has only moved 0x0c (typo on your part?).
> 
> No.  The pc start variable seemed to change somehow.  Perhaps because I
> read the value back to see if it was correct.  Now I understand that I
> can't do that.

Ah yes, only touch ISTAT while the chip is running.

Richard


-----------------------------------------------------
 -- End of forwarded message
-----------------------------------------------------
OS/2!! OS/2!!
-- 
-----------------------------------------------------------
fh...@at...
-----------------------------------------------------------