* [parisc-linux] sym53c8xx driver with 64-bit kernel on C200.
@ 2001-03-04 3:45 Ryan Bradetich
2001-03-04 4:18 ` Matthew Wilcox
2001-03-05 20:34 ` Richard Hirst
0 siblings, 2 replies; 5+ messages in thread
From: Ryan Bradetich @ 2001-03-04 3:45 UTC (permalink / raw)
To: parisc-linux
Hello parisc-linux hackers,
I have been working on writing the PDC Translation functions so a 64-bit
kernel will run using 32-bit firmware. I believe I have this done, and
I
am trying to verify my work by actually booting my C200 with a 64-bit
kernel. Currently I am stuck in the sym53c8xx driver with a HPMC that
I am unable to debug and was hopeing someone on this list could provide
some insight, help debugging, etc.
I have located the single command that causes the HPMC in the
ncr_snooptest function.
This is the scsi boot output:
SCSI subsystem driver Revision: 1.00
sym53c8xx: at PCI bus 0, device 19, function 0
sym53c8xx: setting PCI_COMMAND_IO PCI_COMMAND_MEMORY...
sym53c8xx: setting PCI_COMMAND_MASTER...(fix-up)
sym53c8xx: 53c875 detected
sym53c875-0: rev 0x4 on pci bus 0 device 19 function 0 irq 195
sym53c875-0: NCR clock is 40401KHz
sym53c875-0: ID 7, Fast-20, Parity Checking
sym53c875-0: on-chip RAM at 0xfffffffff2ffe000
/*
** Start script (exchange values)
*/
OUTL (nc_dsa, np->p_ncb);
OUTL (nc_dsp, pc); <-- This line of code causes the HPMC
/*
** Wait 'til done (with timeout)
*/
for (i=0; i<NCR_SNOOP_TIMEOUT; i++)
if (INB(nc_istat) & (INTF|SIP|DIP))
break;
/*
When I run OUTL(nc_dsp,pc) through the preprocessor the statement gets
expanded into this:
_gsc_writel(((__builtin_constant_p((__u32)((((pc))))) ? ({ __u32 __x =
(((((pc))))); ((__u32)( (((__u32)(__x) & (__u32)0x000000ffUL) << 24) |
(((__u32)(__x) & (__u32)0x0000ff00UL) << 8) | (((__u32)(__x) &
(__u32)0x00ff0000UL) >> 8) | (((__u32)(__x) & (__u32)0xff000000UL) >>
24) )); }) : __fswab32(((((pc))))))),(void *)((char *)np->reg +
(((size_t) &((struct ncr_reg *)0)->nc_dsp))));
The chassis codes for this HPMC are:
0xcbf0 HPMC Occurred
0x5002 Path Error: Processor 0
0x7d03 Memory MSI read timeout
0x5402 Path Error: IOA0
0x5508 Broadcast Error: IOA1
0xcbf4 Invalid HPMC checksum
0xcbfc PDCE_HPMC proccessing complete, but failed to branc
to OS_HPMC, halt this CPU
If I comment out that specific line of code, the cache test will fail,
but the boot process continues.
Here is the scsi output with the OUTL(nc_dsp,pc) commented out:
SCSI subsystem driver Revision: 1.00
sym53c8xx: at PCI bus 0, device 19, function 0
sym53c8xx: setting PCI_COMMAND_IO PCI_COMMAND_MEMORY...
sym53c8xx: setting PCI_COMMAND_MASTER...(fix-up)
sym53c8xx: 53c875 detected
sym53c875-0: rev 0x4 on pci bus 0 device 19 function 0 irq 195
sym53c875-0: NCR clock is 40401KHz
sym53c875-0: ID 7, Fast-20, Parity Checking
sym53c875-0: on-chip RAM at 0xfffffffff2ffe000
CACHE TEST FAILED: timeout.
CACHE INCORRECTLY CONFIGURED.
sym53c875-0: giving up ...
sim700: Configuring 53c710 (SCSI-ID 7) at ffffffffffd06100, IRQ 150,
options 0
scsi0: Revision 0x2
The sim700 HPMC is caused by the following line of code in the
sim700_init_host function.
#if 1
NCR_write32(DSP_REG, TARGDATA(HOST_ID)->ba->script+Ent_test1/4+3);
<-- This line of code causes the HPMC
#else
NCR_write32(DSP_REG, TARGDATA(HOST_ID)->ba->script+Ent_test1/4);
#endif
When I run the NCR_write32 line through the preprocessor the statement
gets expanded into this:
{ unsigned long a = (unsigned long)(host->base) + (unsigned long)(0x2c);
u32 v = (hostdata->options & 0x00000001) ?
(__builtin_constant_p((__u32)(((u32)(((struct sim700_target *)
(hostdata->targets + ((7) << 12)))->ba->script+0x000004a0/4+3)))) ? ({
__u32 __x = ((((u32)(((struct sim700_target *) (hostdata->targets + ((7)
<< 12)))->ba->script+0x000004a0/4+3)))); ((__u32)( (((__u32)(__x) &
(__u32)0x000000ffUL) << 24) | (((__u32)(__x) & (__u32)0x0000ff00UL) <<
8) | (((__u32)(__x) & (__u32)0x00ff0000UL) >> 8) | (((__u32)(__x) &
(__u32)0xff000000UL) >> 24) )); }) : __fswab32((((u32)(((struct
sim700_target *) (hostdata->targets + ((7) <<
12)))->ba->script+0x000004a0/4+3))))) : (u32)(((struct sim700_target *)
(hostdata->targets + ((7) << 12)))->ba->script+0x000004a0/4+3); if
(sim700_debug & 0x0002) printk("NCR: %08x => %lx\n", v, a);
_gsc_writel((v),(void *)(a)); };
Also, the HPMC chassis codes are identical to the sym53c8xx problem.
Following the previous idea of commenting out the offending lines
produces this as the scsi boot up code:
SCSI subsystem driver Revision: 1.00
sym53c8xx: at PCI bus 0, device 19, function 0
sym53c8xx: setting PCI_COMMAND_IO PCI_COMMAND_MEMORY...
sym53c8xx: setting PCI_COMMAND_MASTER...(fix-up)
sym53c8xx: 53c875 detected
sym53c875-0: rev 0x4 on pci bus 0 device 19 function 0 irq 195
sym53c875-0: NCR clock is 40401KHz
sym53c875-0: ID 7, Fast-20, Parity Checking
sym53c875-0: on-chip RAM at 0xfffffffff2ffe000
CACHE TEST FAILED: timeout.
CACHE INCORRECTLY CONFIGURED.
sym53c875-0: giving up ...
sim700: Configuring 53c710 (SCSI-ID 7) at ffffffffffd06100, IRQ 150,
options 0
scsi0: Revision 0x2
Post test1, istat 00, sstat0 00, dstat 80
sim700: WARNING IRQ probe failed, (returned 0)
scsi0: test 1 FAILED: dsps: exp 0xab93001d, got 0x00000000
scsi0: Chip register contents:
(script[0] at virt 0000000011f20000, bus a8000)
00 sien: af sdid: 00 scntl1:20 scntl0:cc
04 socl: 00 sodl: 00 sxfer: 00 scid: 80
08 sbcl: 00 sbdl: 00 sidl: 00 sfbr: 00
0C sstat2:00 sstat1:00 sstat0:00 dstat: 80
10 dsa: 00000000
14 ctest3:df ctest2:21 ctest1:f0 ctest0:00
18 ctest7:90 ctest6:00 ctest5:00 ctest4:00
1C temp: 00000000
20 lcrc: 00 ctest8:20 istat: 02 dfifo: 00
24 dbc: 00000000 dnad: 00000000 dsp: 00000000
30 dsps: 00000000 scratch:00000000
38 dcntl: c1 dwt: 00 dien: 3d dmode: e0
3C adder: 00000000
Warning : device (10, 0x56, 0x0, 0x82, 0x0) NOT claimed by Lasi SCSI
53c710
zalon_scsi_callback: Zalon vers field is 0x1, IRQ 67
ncr53c8xx: 53c720 detected
ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential
I have not taken this any further .... I just wanted to demonstrate that
line of code was causing the
HPMC.
Does anyone have any ideas on what might be causing this? Any pointers
on how to continue
debugging this problem?
Thanks,
- Ryan
P.S. I have quite a bit of code in my local tree reguarding the
PDC translation and some 64-bit
driver cleanups. I have been working on committing the 64-bit driver
cleanups ... I would
like to wait until I see the 64-bit kernel boot on the C200 before
I commit the PDC translation
code. If anyone wants a patch from my local tree for the
PDC translation stuff, send me
email and I'll produce them a patch.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [parisc-linux] sym53c8xx driver with 64-bit kernel on C200.
2001-03-04 3:45 [parisc-linux] sym53c8xx driver with 64-bit kernel on C200 Ryan Bradetich
@ 2001-03-04 4:18 ` Matthew Wilcox
2001-03-04 6:50 ` Ryan Bradetich
2001-03-05 20:34 ` Richard Hirst
1 sibling, 1 reply; 5+ messages in thread
From: Matthew Wilcox @ 2001-03-04 4:18 UTC (permalink / raw)
To: Ryan Bradetich; +Cc: parisc-linux
On Sat, Mar 03, 2001 at 08:45:03PM -0700, Ryan Bradetich wrote:
> When I run OUTL(nc_dsp,pc) through the preprocessor the statement gets
> expanded into this:
>
> _gsc_writel(((__builtin_constant_p((__u32)((((pc))))) ? ({ __u32 __x =
> (((((pc))))); ((__u32)( (((__u32)(__x) & (__u32)0x000000ffUL) << 24) |
> (((__u32)(__x) & (__u32)0x0000ff00UL) << 8) | (((__u32)(__x) &
> (__u32)0x00ff0000UL) >> 8) | (((__u32)(__x) & (__u32)0xff000000UL) >>
> 24) )); }) : __fswab32(((((pc))))))),(void *)((char *)np->reg +
> (((size_t) &((struct ncr_reg *)0)->nc_dsp))));
I guess you'd like this decoded? Let's see. `pc' is clearly not a constant,
so __builtin_constant_p returns false, so we can simplify this down to:
_gsc_writel(__fswab32(pc) ,
(void *)((char *)np->reg + (((size_t) &((struct ncr_reg *)0)->nc_dsp))));
which leads me to ask `what value does `pc' have?'
I suspect you want to put debugging code in _gsc_writel to tell you where
you're trying to perform IO to.
My suspicion is that you're writing to the 32 bit IO space in 64-bit mode,
which is juts not going to work.
--
Revolutions do not require corporate support.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [parisc-linux] sym53c8xx driver with 64-bit kernel on C200.
2001-03-04 4:18 ` Matthew Wilcox
@ 2001-03-04 6:50 ` Ryan Bradetich
2001-03-04 16:57 ` Ryan Bradetich
0 siblings, 1 reply; 5+ messages in thread
From: Ryan Bradetich @ 2001-03-04 6:50 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: parisc-linux
Willy,
Thanks for decoding that for me.... it does make more sense now :)
Here is the debug messages I added to sym53c8xx.c
pc = NCB_SCRIPTH0_PHYS (np, snooptest);
printk("pc: %x\n", pc);
host_wr = 1;
ncr_wr = 2;
/*
** Set memory and register.
*/
np->ncr_cache = cpu_to_scr(host_wr);
OUTL (nc_temp, ncr_wr);
/*
** Start script (exchange values)
*/
OUTL (nc_dsa, np->p_ncb);
printk("val: %x\n", __fswab32(pc));
printk("addr: %p\n", (void *)((char *)np->reg + (((size_t) &((struct ncr_reg
*)0)->nc_dsp))));
OUTL (nc_dsp, pc);
And here is the scsi boot output:
SCSI subsystem driver Revision: 1.00
sym53c8xx: at PCI bus 0, device 19, function 0
sym53c8xx: setting PCI_COMMAND_IO PCI_COMMAND_MEMORY...
sym53c8xx: setting PCI_COMMAND_MASTER...(fix-up)
sym53c8xx: 53c875 detected
sym53c875-0: rev 0x4 on pci bus 0 device 19 function 0 irq 195
sym53c875-0: NCR clock is 40401KHz
sym53c875-0: ID 7, Fast-20, Parity Checking
sym53c875-0: on-chip RAM at 0xfffffffff2ffe000
pc: 98dd8
val: d88d0900
addr: fffffffff2ffd02c
Here is the function for _gsc_writel:
void _gsc_writel(u32 val, void *addr)
So it appears to me the correct arguments are being passed to the _gsc_writel
function.
I'm not sure about the values being passed in, but the types look correct, and
the
address is properly sign extended.
- Ryan
Matthew Wilcox wrote:
> On Sat, Mar 03, 2001 at 08:45:03PM -0700, Ryan Bradetich wrote:
> > When I run OUTL(nc_dsp,pc) through the preprocessor the statement gets
> > expanded into this:
> >
> > _gsc_writel(((__builtin_constant_p((__u32)((((pc))))) ? ({ __u32 __x =
> > (((((pc))))); ((__u32)( (((__u32)(__x) & (__u32)0x000000ffUL) << 24) |
> > (((__u32)(__x) & (__u32)0x0000ff00UL) << 8) | (((__u32)(__x) &
> > (__u32)0x00ff0000UL) >> 8) | (((__u32)(__x) & (__u32)0xff000000UL) >>
> > 24) )); }) : __fswab32(((((pc))))))),(void *)((char *)np->reg +
> > (((size_t) &((struct ncr_reg *)0)->nc_dsp))));
>
> I guess you'd like this decoded? Let's see. `pc' is clearly not a constant,
> so __builtin_constant_p returns false, so we can simplify this down to:
>
> _gsc_writel(__fswab32(pc) ,
> (void *)((char *)np->reg + (((size_t) &((struct ncr_reg *)0)->nc_dsp))));
>
> which leads me to ask `what value does `pc' have?'
>
> I suspect you want to put debugging code in _gsc_writel to tell you where
> you're trying to perform IO to.
>
> My suspicion is that you're writing to the 32 bit IO space in 64-bit mode,
> which is juts not going to work.
>
> --
> Revolutions do not require corporate support.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [parisc-linux] sym53c8xx driver with 64-bit kernel on C200.
2001-03-04 6:50 ` Ryan Bradetich
@ 2001-03-04 16:57 ` Ryan Bradetich
0 siblings, 0 replies; 5+ messages in thread
From: Ryan Bradetich @ 2001-03-04 16:57 UTC (permalink / raw)
To: Matthew Wilcox, parisc-linux
I also put some debug code in the _gsc_writel command as you
suggested ..... Here is the output (I let it run overnight because
the added debug to _gsc_writel caused the run-time to slow
down quite considerably (I let it run over night....)
SCSI subsystem driver Revision: 1.00
sym53c8xx: at PCI bus 0, device 19, function 0
_gsc_writel val: 9804 addr: fffffffff2000064
_gsc_writel val: 9808 addr: fffffffff2000064
_gsc_writel val: 980c addr: fffffffff2000064
_gsc_writel val: 980c addr: fffffffff2000064
_gsc_writel val: 9804 addr: fffffffff2000064
sym53c8xx: setting PCI_COMMAND_IO PCI_COMMAND_MEMORY...
_gsc_writel val: 9800 addr: fffffffff2000064
_gsc_writel val: 9804 addr: fffffffff2000064
sym53c8xx: setting PCI_COMMAND_MASTER...(fix-up)
_gsc_writel val: 9800 addr: fffffffff2000064
_gsc_writel val: 9804 addr: fffffffff2000064
sym53c8xx: 53c875 detected
sym53c875-0: rev 0x4 on pci bus 0 device 19 function 0 irq 195
sym53c875-0: NCR clock is 40401KHz
sym53c875-0: ID 7, Fast-20, Parity Checking
sym53c875-0: on-chip RAM at 0xfffffffff2ffe000
_gsc_writel val: ffffffff addr: fffffffff2ffd00c
pc: 98dd8
_gsc_writel val: 2000000 addr: fffffffff2ffd01c
_gsc_writel val: 800800 addr: fffffffff2ffd010
val: d88d0900
addr: fffffffff2ffd02c
_gsc_writel val: d88d0900 addr: fffffffff2ffd02c
Anyways hope this additional information provide some insight.
Thanks,
- Ryan
Ryan Bradetich wrote:
> Willy,
>
> Thanks for decoding that for me.... it does make more sense now :)
> Here is the debug messages I added to sym53c8xx.c
>
> pc = NCB_SCRIPTH0_PHYS (np, snooptest);
> printk("pc: %x\n", pc);
> host_wr = 1;
> ncr_wr = 2;
> /*
> ** Set memory and register.
> */
> np->ncr_cache = cpu_to_scr(host_wr);
> OUTL (nc_temp, ncr_wr);
> /*
> ** Start script (exchange values)
> */
> OUTL (nc_dsa, np->p_ncb);
> printk("val: %x\n", __fswab32(pc));
> printk("addr: %p\n", (void *)((char *)np->reg + (((size_t) &((struct ncr_reg
> *)0)->nc_dsp))));
> OUTL (nc_dsp, pc);
>
> And here is the scsi boot output:
>
> SCSI subsystem driver Revision: 1.00
> sym53c8xx: at PCI bus 0, device 19, function 0
> sym53c8xx: setting PCI_COMMAND_IO PCI_COMMAND_MEMORY...
> sym53c8xx: setting PCI_COMMAND_MASTER...(fix-up)
> sym53c8xx: 53c875 detected
> sym53c875-0: rev 0x4 on pci bus 0 device 19 function 0 irq 195
> sym53c875-0: NCR clock is 40401KHz
> sym53c875-0: ID 7, Fast-20, Parity Checking
> sym53c875-0: on-chip RAM at 0xfffffffff2ffe000
> pc: 98dd8
> val: d88d0900
> addr: fffffffff2ffd02c
>
> Here is the function for _gsc_writel:
> void _gsc_writel(u32 val, void *addr)
>
> So it appears to me the correct arguments are being passed to the _gsc_writel
> function.
> I'm not sure about the values being passed in, but the types look correct, and
> the
> address is properly sign extended.
>
> - Ryan
>
> Matthew Wilcox wrote:
>
> > On Sat, Mar 03, 2001 at 08:45:03PM -0700, Ryan Bradetich wrote:
> > > When I run OUTL(nc_dsp,pc) through the preprocessor the statement gets
> > > expanded into this:
> > >
> > > _gsc_writel(((__builtin_constant_p((__u32)((((pc))))) ? ({ __u32 __x =
> > > (((((pc))))); ((__u32)( (((__u32)(__x) & (__u32)0x000000ffUL) << 24) |
> > > (((__u32)(__x) & (__u32)0x0000ff00UL) << 8) | (((__u32)(__x) &
> > > (__u32)0x00ff0000UL) >> 8) | (((__u32)(__x) & (__u32)0xff000000UL) >>
> > > 24) )); }) : __fswab32(((((pc))))))),(void *)((char *)np->reg +
> > > (((size_t) &((struct ncr_reg *)0)->nc_dsp))));
> >
> > I guess you'd like this decoded? Let's see. `pc' is clearly not a constant,
> > so __builtin_constant_p returns false, so we can simplify this down to:
> >
> > _gsc_writel(__fswab32(pc) ,
> > (void *)((char *)np->reg + (((size_t) &((struct ncr_reg *)0)->nc_dsp))));
> >
> > which leads me to ask `what value does `pc' have?'
> >
> > I suspect you want to put debugging code in _gsc_writel to tell you where
> > you're trying to perform IO to.
> >
> > My suspicion is that you're writing to the 32 bit IO space in 64-bit mode,
> > which is juts not going to work.
> >
> > --
> > Revolutions do not require corporate support.
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/cgi-bin/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [parisc-linux] sym53c8xx driver with 64-bit kernel on C200.
2001-03-04 3:45 [parisc-linux] sym53c8xx driver with 64-bit kernel on C200 Ryan Bradetich
2001-03-04 4:18 ` Matthew Wilcox
@ 2001-03-05 20:34 ` Richard Hirst
1 sibling, 0 replies; 5+ messages in thread
From: Richard Hirst @ 2001-03-05 20:34 UTC (permalink / raw)
To: Ryan Bradetich; +Cc: parisc-linux
On Sat, Mar 03, 2001 at 08:45:03PM -0700, Ryan Bradetich wrote:
> OUTL (nc_dsp, pc); <-- This line of code causes the HPMC
That line triggers the 53c8xx to start fetching and
executing scripts from memory.
> The sim700 HPMC is caused by the following line of code in the
> sim700_init_host function.
>
> #if 1
> NCR_write32(DSP_REG, TARGDATA(HOST_ID)->ba->script+Ent_test1/4+3);
> <-- This line of code causes the HPMC
That line triggers the 53c7xx to start fetching and
executing scripts from memory.
Richard
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-03-05 20:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-03-04 3:45 [parisc-linux] sym53c8xx driver with 64-bit kernel on C200 Ryan Bradetich
2001-03-04 4:18 ` Matthew Wilcox
2001-03-04 6:50 ` Ryan Bradetich
2001-03-04 16:57 ` Ryan Bradetich
2001-03-05 20:34 ` Richard Hirst
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.