State of NCR53c7xx based drivers

State of NCR53c7xx based drivers

[Christoph Hellwig]

[and now with the right address for the m68k list]

Hi folks,

what's the status of the 53c7xx based drivers, namely amiga7xx,
mvme16x and bvme6000?  These are the last ones still using the
old 53x7xx instead of the new 53c700 core which despite the
name also handles 53c710 chips.  As the 53c7xx driver hasn't
been updated to proper locking, error handling and bus mapping
APIs we'd really better get rid of it.  Porting to use 53c700
should be trivial in theory and we already have three nice example
drivers in the tree.

Could anyone who has the hardware try to do a port?  Or are they
actually completely dead (I could imagine that for the vme ones)
in which case we'd better just remove them from tree, as they're
really tiny wrapper only anywa.

As for amgia7xx is there a reason we have four different config
options for this single tiny driver?

Re: State of NCR53c7xx based drivers

[Richard Hirst]

I agree that porting them to use the 53c700 core is the right thing to
do.  I have the VME hardware, but don't know when I'll get time to look
at this - too much real work, etc.

Richard


On Sat, Nov 22, 2003 at 12:38:34PM +0100, Christoph Hellwig wrote:
> [and now with the right address for the m68k list]
> 
> Hi folks,
> 
> what's the status of the 53c7xx based drivers, namely amiga7xx,
> mvme16x and bvme6000?  These are the last ones still using the
> old 53x7xx instead of the new 53c700 core which despite the
> name also handles 53c710 chips.  As the 53c7xx driver hasn't
> been updated to proper locking, error handling and bus mapping
> APIs we'd really better get rid of it.  Porting to use 53c700
> should be trivial in theory and we already have three nice example
> drivers in the tree.
> 
> Could anyone who has the hardware try to do a port?  Or are they
> actually completely dead (I could imagine that for the vme ones)
> in which case we'd better just remove them from tree, as they're
> really tiny wrapper only anywa.
> 
> As for amgia7xx is there a reason we have four different config
> options for this single tiny driver?
> _______________________________________________
> Linux-m68k mailing list
> Linux-m68k@lists.linux-m68k.org
> http://lists.linux-m68k.org/mailman/listinfo/linux-m68k

Re: State of NCR53c7xx based drivers

[Geert Uytterhoeven]

On Sat, 22 Nov 2003, Christoph Hellwig wrote:
> As for amgia7xx is there a reason we have four different config
> options for this single tiny driver?

I already fixed this in my local tree, for both 2.4.x and 2.6.0, as Willy
suggested this a while ago.

However, I do lack the hardware (and the time, just in case you want to send me
more hardware ;-) to do more clean ups.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: State of NCR53c7xx based drivers

[Rask Ingemann Lambertsen]

On Sat, Nov 22, 2003 at 12:38:34PM +0100, Christoph Hellwig wrote:

> what's the status of the 53c7xx based drivers, namely amiga7xx,
> mvme16x and bvme6000?  These are the last ones still using the
> old 53x7xx instead of the new 53c700 core which despite the
> name also handles 53c710 chips.

It might be a good idea to update the comments in the code to say so more
clearly. At least in 2.6.0-test8, only two changelog entries say so.

What about the 53c770? This chip is supported by 53c7xx, isn't it? But it
seems as if 53c7xx uses the exact same code for both 53c710 and 53c770, so
perhaps you can deal with that easily. Grep did not find any drivers that
actually make use of the 53c770 support, although it is not unlikely that I
might have missed something.

And while we are at amiga7xx and 53c770: There are Amiga SCSI host adapters
with the 53c770 (CyberStorm PPC/MkIII), although amiga7xx doesn't support
them. Why?

-- 
Regards,
Rask Ingemann Lambertsen

Re: State of NCR53c7xx based drivers

[James Bottomley]

On Sun, 2003-11-23 at 10:50, Rask Ingemann Lambertsen wrote:
> What about the 53c770? This chip is supported by 53c7xx, isn't it? But it
> seems as if 53c7xx uses the exact same code for both 53c710 and 53c770, so
> perhaps you can deal with that easily. Grep did not find any drivers that
> actually make use of the 53c770 support, although it is not unlikely that I
> might have missed something.

The driver for the 53c720 and 53c770 is the ncr53c8xx---I know, wrong
name, but it's had all the 8xx PCI guts removed.  It now handles the
53c720 chips in both the zalon (parisc based) and NCRQ720 (MCA based)
boards.  It should be fairly easy to use this for amiga stuff.  The
advantage is that it does drive the chip as a multi-threaded scripts
engine.

James

Re: State of NCR53c7xx based drivers

[Geert Uytterhoeven]

On Sun, 23 Nov 2003, Rask Ingemann Lambertsen wrote:
> On Sat, Nov 22, 2003 at 12:38:34PM +0100, Christoph Hellwig wrote:
> > what's the status of the 53c7xx based drivers, namely amiga7xx,
> > mvme16x and bvme6000?  These are the last ones still using the
> > old 53x7xx instead of the new 53c700 core which despite the
> > name also handles 53c710 chips.
> 
> It might be a good idea to update the comments in the code to say so more
> clearly. At least in 2.6.0-test8, only two changelog entries say so.
> 
> What about the 53c770? This chip is supported by 53c7xx, isn't it? But it
> seems as if 53c7xx uses the exact same code for both 53c710 and 53c770, so
> perhaps you can deal with that easily. Grep did not find any drivers that
> actually make use of the 53c770 support, although it is not unlikely that I
> might have missed something.
> 
> And while we are at amiga7xx and 53c770: There are Amiga SCSI host adapters
> with the 53c770 (CyberStorm PPC/MkIII), although amiga7xx doesn't support
> them. Why?

The usual answer: because no one who has the hardware wrote the support and
submitted it?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: State of NCR53c7xx based drivers

[Rask Ingemann Lambertsen]

On Sun, Nov 23, 2003 at 06:07:22PM +0100, Geert Uytterhoeven wrote:
> On Sun, 23 Nov 2003, Rask Ingemann Lambertsen wrote:

> > And while we are at amiga7xx and 53c770: There are Amiga SCSI host adapters
> > with the 53c770 (CyberStorm PPC/MkIII), although amiga7xx doesn't support
> > them. Why?
> 
> The usual answer: because no one who has the hardware wrote the support and
> submitted it?

I don't know, that's why I asked. ;-)
I have an Amiga with a CyberStorm PPC board and wouldn't mind having Linux
running on it. What would be a good name for the driver?

-- 
Regards,
Rask Ingemann Lambertsen

Re: State of NCR53c7xx based drivers

[Ken Tyler]

On Sun, 23 Nov 2003, Rask Ingemann Lambertsen wrote:

> I have an Amiga with a CyberStorm PPC board and wouldn't mind having Linux
> running on it. What would be a good name for the driver?

Which Amiga and which PPC board?

SCSI works on ppc 1200s but not reliably on ppc 4000s.  I tried many, many 
times to fix 53c710.c (with endless help from Richard Hirst) all to no 
avail.

It will work for a variable amount of time and then machine locks up,
CDROMS and ZIPs seem to run longer than HDs.

A hacked together sim710.c behaved exactly the same.  This is with Quantum 
drives.

An odd as it might seem when I bought a Seagate drive for the PPC on board
SCSI it did the same thing too.

At this point I decided the driver was probably OK all along and the 
problem is else where, either in the logic that connects ZORRO to PPC or a 
deadlock in interrupt code but this is stabbing in the dark.

Good luck,

Ken.   

Re: State of NCR53c7xx based drivers

[Rask Ingemann Lambertsen]

On Mon, Nov 24, 2003 at 04:12:02PM +1100, Ken Tyler wrote:
> On Sun, 23 Nov 2003, Rask Ingemann Lambertsen wrote:
> 
> > I have an Amiga with a CyberStorm PPC board and wouldn't mind having Linux
> > running on it. What would be a good name for the driver?
> 
> Which Amiga and which PPC board?

Amiga 4000 desktop and CyberStorm PPC with '060@50 MHz and 604e@233 MHz.

> SCSI works on ppc 1200s but not reliably on ppc 4000s.  I tried many, many 
> times to fix 53c710.c (with endless help from Richard Hirst) all to no 
> avail.

I'm confused. What SCSI on PPC A4000s is that? Is it the 53c770 on the
CyberStorm PPC or the 53c710 on the A4000 tower motherboard?

> At this point I decided the driver was probably OK all along and the 
> problem is else where, either in the logic that connects ZORRO to PPC or a 
> deadlock in interrupt code but this is stabbing in the dark.

The Zorro<->PPC logic should be out of the equation on the CyberStorm PPC
since the 53c770 is connected directly to the processor bus.

-- 
Regards,
Rask Ingemann Lambertsen

Re: State of NCR53c7xx based drivers

[Ken Tyler]

On Mon, 24 Nov 2003, Rask Ingemann Lambertsen wrote:

> On Mon, Nov 24, 2003 at 04:12:02PM +1100, Ken Tyler wrote:

> I'm confused. What SCSI on PPC A4000s is that? Is it the 53c770 on the
> CyberStorm PPC or the 53c710 on the A4000 tower motherboard?

Sorry, not clear at all, 53c710 on DKB A4091 in A4000 (not tower) ZORRO 
slot, with Cyberstorm 060 and 200MHz 604e.

Is there a 53c710 in A4000 towers and if so is it on the mother board at a 
fixed address?

> The Zorro<->PPC logic should be out of the equation on the CyberStorm PPC
> since the 53c770 is connected directly to the processor bus.

I was meaning BUS REQ, GRANT and ACK bus arbitration logic and DMA cycle
control that is used to manage DMA transfers rather than the ZORRO auto 
config hardware. 

I recall reading that the PPC on the Cyberstorm cards is made to look like
a 68000 to talk on the ZORRO bus.

I assume that the same arbitration logic is used for bus control even 
though the Cyberstorm on board SCSI is at a fixed address and doesn't need 
to be allocated a ZORRO address range as a real plug in ZORRO card does.

Does that make any sense?

Ken.

Re: State of NCR53c7xx based drivers

[Geert Uytterhoeven]

On Tue, 25 Nov 2003, Ken Tyler wrote:
> On Mon, 24 Nov 2003, Rask Ingemann Lambertsen wrote:
> > On Mon, Nov 24, 2003 at 04:12:02PM +1100, Ken Tyler wrote:
> 
> > I'm confused. What SCSI on PPC A4000s is that? Is it the 53c770 on the
> > CyberStorm PPC or the 53c710 on the A4000 tower motherboard?
> 
> Sorry, not clear at all, 53c710 on DKB A4091 in A4000 (not tower) ZORRO 
> slot, with Cyberstorm 060 and 200MHz 604e.
> 
> Is there a 53c710 in A4000 towers and if so is it on the mother board at a 
> fixed address?

A4000T has the 4091 builtin. Look at amiga7xx.c for the fixed address.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: State of NCR53c7xx based drivers

[Ken Tyler]

On Mon, 24 Nov 2003, Geert Uytterhoeven wrote:

> A4000T has the 4091 builtin. Look at amiga7xx.c for the fixed address.

Yes, you're right, I've looked at amiga7xx.c often enough.

Does the 4000T and CyberStorm work reliably?

Ken.

Re: State of NCR53c7xx based drivers

[Rask Ingemann Lambertsen]

On Tue, Nov 25, 2003 at 06:13:48AM +1100, Ken Tyler wrote:

> > The Zorro<->PPC logic should be out of the equation on the CyberStorm PPC
> > since the 53c770 is connected directly to the processor bus.
> 
> I was meaning BUS REQ, GRANT and ACK bus arbitration logic and DMA cycle
> control that is used to manage DMA transfers rather than the ZORRO auto 
> config hardware. 

So was I. If the buffer memory is also on the CyberStorm board, the bus
cycles might not even be visible outside of the processor board. Even if
they are for motherboard memory, the Buster chip does not run bus cycles
on the Zorro bus in that case.

-- 
Regards,
Rask Ingemann Lambertsen

Re: State of NCR53c7xx based drivers

[Ken Tyler]

On Tue, 25 Nov 2003, Rask Ingemann Lambertsen wrote:

> So was I. If the buffer memory is also on the CyberStorm board, the bus
> cycles might not even be visible outside of the processor board. Even if
> they are for motherboard memory, the Buster chip does not run bus cycles
> on the Zorro bus in that case.

Depends on the how the hardware implements on and off board access.  I 
supposed a state machine takes the Zorro/m68k signals and generates 
appropriate signals for the ppc and vise versa.  The same state machine 
handles the onboard SCSI DMA but as you say there are differences.

According to www.thule.no/haynie/ even the last rev buster had problems, I 
have some emails from him some where on this.

It just seems too much of a coincidence that my A4091 and the onboard 
Cyberstorm SCSI have an identical problem but wether it's hardware or 
software I've no idea.

After replacing the 040 with the 060/PPC card the Amiga OS would 
freeze now and then. I think more frequently than when the 040 was in 
place.

Ken.

Using ncr53c8xx.c for a 53c770 chip (Was: State of NCR53c7xx based drivers)

[Rask Ingemann Lambertsen]

On Sun, Nov 23, 2003 at 10:59:55AM -0600, James Bottomley wrote:

> The driver for the 53c720 and 53c770 is the ncr53c8xx---I know, wrong
> name, but it's had all the 8xx PCI guts removed.  It now handles the
> 53c720 chips in both the zalon (parisc based) and NCRQ720 (MCA based)
> boards.  It should be fairly easy to use this for amiga stuff.

That's only for the 2.6.x kernels, isn't it?

I need some help filling in the ncr_chip structure. Where do I find the
device_id, revision_id, burst_max, nr_divisor and features settings? I can
figure some of it out:
.offset_max = 15 (the maximum allowed by the AmigaOS driver).
.features = FE_ULTRA | FE_WIDE | FE_RAM (but maybe more flags are needed?)

I also need some help filling in the ncr_slot structure. The registers are
memory mapped at bus address 0xf40000 and the script RAM is memory mapped at
bus address 0xf41000. So I guess base is for the registers, base2 is for
the script RAM and that *_v is for the virtual memory addresses of the above.
That still leaves me with io_port, base_c, base2_c and base_io.

Where do I tell the driver about the SCSI clock (50 MHz)?

-- 
Regards,
Rask Ingemann Lambertsen

Re: Using ncr53c8xx.c for a 53c770 chip

[Rask Ingemann Lambertsen]

On Tue, Jan 13, 2004 at 02:55:57PM +0100, Rask Ingemann Lambertsen wrote:

> I need some help filling in the ncr_chip structure. Where do I find the
> device_id, revision_id, burst_max, nr_divisor and features settings? I can
> figure some of it out:
> .offset_max = 15 (the maximum allowed by the AmigaOS driver).
> .features = FE_ULTRA | FE_WIDE | FE_RAM (but maybe more flags are needed?)

I just got hold of the 53c770 programming guide, and it helps a lot with
this part, but comments are still welcome, of course.

-- 
Regards,
Rask Ingemann Lambertsen

Re: Using ncr53c8xx.c for a 53c770 chip (Was: State of NCR53c7xx based drivers)

[James Bottomley]

On Tue, 2004-01-13 at 08:55, Rask Ingemann Lambertsen wrote:
> That's only for the 2.6.x kernels, isn't it?

it's only been cut apart to work nicely like this in 2.6 kernels, yes. 
There is a residue in 2.4 for driving the parisc zalon (53c720) card

> I need some help filling in the ncr_chip structure. Where do I find the
> device_id, revision_id, burst_max, nr_divisor and features settings? I can
> figure some of it out:
> .offset_max = 15 (the maximum allowed by the AmigaOS driver).
> .features = FE_ULTRA | FE_WIDE | FE_RAM (but maybe more flags are needed?)

I'd get it working in 53c720 mode first (i.e. drop the FE_ULTRA) and
then go back and add the ultra capability.

> I also need some help filling in the ncr_slot structure. The registers are
> memory mapped at bus address 0xf40000 and the script RAM is memory mapped at
> bus address 0xf41000. So I guess base is for the registers, base2 is for
> the script RAM and that *_v is for the virtual memory addresses of the above.
> That still leaves me with io_port, base_c, base2_c and base_io.

That should be correct...although I've not tested it, it might be wise
to begin without the FE_RAM as well.  I can check this with the
NCR_Q720, though if you get problems.  Although it doesn't have on-chip
ram for scripts, the board itself has 2Mb of ram behind the MCA window

> Where do I tell the driver about the SCSI clock (50 MHz)?

The driver will work it out...it has its own timing routine.

This is another reason for trying without FE_ULTRA.  Normally, a 770 in
Ultra mode requires an 80MHz clock.  For a 50MHz clock, you need to use
the 770s clock doubler mode, so when you're ready to try it, you'll need
FE_DBLR (and I don't think this has ever been tested on a 770 either...)

James

Re: Using ncr53c8xx.c for a 53c770 chip

[James Bottomley]

On Tue, 2004-01-13 at 09:15, Rask Ingemann Lambertsen wrote:
> I just got hold of the 53c770 programming guide, and it helps a lot with
> this part, but comments are still welcome, of course.

OK, I forgot to say that because you have a non-standard 50MHz clock,
you'll need to set FE_VARCLK to make the driver compute the clock speed.

James

Re: Using ncr53c8xx.c for a 53c770 chip

[Rask Ingemann Lambertsen]

On Tue, Jan 13, 2004 at 11:33:03AM -0500, James Bottomley wrote:
> On Tue, 2004-01-13 at 08:55, Rask Ingemann Lambertsen wrote:
> 
> > I also need some help filling in the ncr_slot structure. The registers are
> > memory mapped at bus address 0xf40000 and the script RAM is memory mapped at
> > bus address 0xf41000. So I guess base is for the registers, base2 is for
> > the script RAM and that *_v is for the virtual memory addresses of the above.
> > That still leaves me with io_port, base_c, base2_c and base_io.
> 
> That should be correct...although I've not tested it, it might be wise
> to begin without the FE_RAM as well.  I can check this with the
> NCR_Q720, though if you get problems.  Although it doesn't have on-chip
> ram for scripts, the board itself has 2Mb of ram behind the MCA window

OK. Btw, searching for paddr2 shows use of vtobus(). :-(

> > Where do I tell the driver about the SCSI clock (50 MHz)?
> 
> The driver will work it out...it has its own timing routine.

Good. I'm not entirely sure that all boards use a 50 MHz clock. Partly
because several models of the board exists and partly because some people
overclock their boards.

-- 
Regards,
Rask Ingemann Lambertsen