linux-apus-devel

Re: First cut at rework to abstract processor stuff

[Geert U. <ge...@li...>]

On Sun, 22 Oct 2000, Tom Rini wrote:
> On Sun, Oct 22, 2000 at 11:04:07PM -0500, Corey Minyard wrote:
> > These goals are not going to be realistically achievable in one big
> > patch, the code has a very long way to go to reach these goals.  APUS,
> > in particular, is going to cause quite a bit more work.
> 
> Yeap. :(  The other problem is right now I don't _think_ any of the APUS people
> are on this list.  Perhaps we should get one or two on here (As I understand it
> what they need for 2.4 is minimal, but I dont follow too closely) or at least
> CC them in this discussion.

Indeed. I'm the `closest' to an APUS developer on this list, I think (I have
an m68k Amiga and a PPC LongTrail, but not in one box :-).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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: Symbios 53c770 driver

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

In <Pine.LNX.4.10.10010221201370.474-100000@cassiopeia.home>, on 10/22/00 
   at 12:04 PM, Geert Uytterhoeven <ge...@li...> said:

>On Sun, 22 Oct 2000 fh...@at... wrote:
>> In <Pine.LNX.4.10.10010181211150.841-100000@cassiopeia.home>, on 10/18/00 
>>    at 12:46 PM, Geert Uytterhoeven <ge...@li...> said:
>> 
>> >On Tue, 17 Oct 2000 fh...@at... wrote:
>> >> In <Pine.LNX.4.10.10010171602340.394-100000@cassiopeia.home>, on 10/17/00 
>> >>    at 04:09 PM, Geert Uytterhoeven <ge...@li...> said:
>> >> 

Thanks for the tip Geert.

>> I got the driver to pass the cache test finally.

>Good! What exactly did you have to change?

Well my excitement has been dashed to pieces.  It seems there is a memory
corruption problem in the driver.

>> I also found out something interesting:  There is a limit as
>> to how many printks you can have in a driver. :)

>Really?

Probably not.  I think the memory stack or heap is getting
corrupted that is causing the problem.

I sent a message to Richard early this after noon I have
attached the message I sent him in the hope that someone
can explain/help.

In <200...@li...>, on 10/17/00 
   at 10:09 AM, Richard Hirst <rh...@li...> said:

Richard,

I sent you a message previously about how the driver successfully
completes the cache test.  After doing some more examination of the  code
regarding the change I made, I have found something that puzzles me.

This is in the ncr_attach function:

		
	/*
	**	Align np and first ccb to 32 boundary for cache line 
	**	bursting when copying the global header.
	*/
/* Fred */
	 np        = (ncb_p) (((u_long) &host_data->_ncb_data) & NCB_ALIGN_MASK);
	 
The above line is the original code that "came with" the driver I am
working on. The following line is in the newer sym53c8xx driver.  When I
use the m_calloc function to allocate the np structure, the resultant
structure is either not aligned properly or ends up in the wrong place in
memory for the cache test to work.  As  you can see the np data structure
physical address is 82f2000.  Using the above line puts the np structure
at bf34080 and the cache test works fine.  Here's my puzzlement:  I don't
see how the  above line allocates any storage for the np/ncb data
structure.  What makes  me think that the structure is not really
allocated properly results from the  last line of the latest dmesg.  You
notice the inst_name (before the colon)  is not printed, possibly
indicating that the memory has  become corrupted.   (The result of trying
to boot is that the computer locks up, with no panic.)

What do you think?

/* 4643 *//*        np = m_calloc(sizeof(struct ncb), "NCB", MEMO_WARN);
*/

The line above is borrowed from the newer sym53c8xx driver code.

/* 4644 */        if (!np)
/* 4645 */                 goto attach_error;
	/* NCR_INIT_LOCK_NCB(np); *//* Fred   */ /* No SMP on APUS */
	host_data->ncb = np;
	/* bzero (np, sizeof (*np)); */ /* Fred */ /* Not in newer Symbios  */

Does this bzero do some sort of memory allocations?  I think all it  does
is clear the memory?

	/* Fred */ /* Next two lines Not in newer Symbios */
	
	np->ccb   = (ccb_p) (((u_long) &host_data->_ccb_data) & CCB_ALIGN_MASK);
	bzero (np->ccb, sizeof (*np->ccb));

Part of old dmesg:

virt_to_phys(np): 82f2000
np: c02f2000
ncr_cache: 00000000 pc: 0bf32e50
ncr_cache: c02f2078 0 78
start=0bf32e50, pc=0bf32e50, end=0bf32e7c
c0000004 082f2078
00f40034 c0000004
00f4001c 082f2078
c0000004 082f2078
00f4001c 98080000
00000063 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000


This is the latest dmesg from my testing:
ncr53c8xx: 53c770 detected 
ncr53c770-0: rev=0x00, base=0xf40000, io_port=0x0, irq=12
new SCRIPT[3772] @c02f2000.
new SCRIPTH[3708] @c3f33000.
Peparing...
myaddr: 0
myaddr: 7
myaddr: 7
ncr53c770- 0: ID 7, Fast-20, Parity Checking
ncr53c770- 0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex)
05/c0/20/00/00/04 ncr53c770- 0: final   SCNTL3/DMODE/DCNTL/CTEST3/4/5 =
(hex) 05/82/20/00/08/24 SCSI reset
cleared
test: aabbff11 aabbff11
virt_to_phys(np): bf34080
np: c3f34080
ncr_cache: 00000000 pc: 0bf33e50
ncr_cache:ptr: c3f340d8 val: 0 offset: 58
np->ncr_cache: faedbeef
ncr_wr: deadfead
cache addr: bf340d8
t_istat: 1 dstat: 84 (1 128)
dsp: bf33e7c dsps: 63 (200490620 99)  <-- Snooptest runs successfully
sstat2: a (10)
term pc: bf33e7c
requesting irq...  <-- now we request a shared IRQ
shared irq
: resetting, command processing suspended for 2 seconds  <-- This should
be printing ncr53c770-x before the colon.  That inst_name is in the np/ncb
data structure.  See following code.

Some more code:

static void ncr_start_reset(ncb_p np, int settle_delay)
{
	u_long flags;
	save_flags(flags); cli();
	if (!np->settle_time) {
		if /* (bootverbose > 1) */ (1)
			printf("%s: resetting, command processing suspended for %d seconds\n",
				ncr_name(np), settle_delay);
		np->settle_time	= jiffies + settle_delay * HZ;
		OUTB (nc_istat, SRST);


Fred

Re: Symbios 53c770 driver

[Geert U. <ge...@li...>]

On Sun, 22 Oct 2000 fh...@at... wrote:
> In <Pine.LNX.4.10.10010181211150.841-100000@cassiopeia.home>, on 10/18/00 
>    at 12:46 PM, Geert Uytterhoeven <ge...@li...> said:
> 
> >On Tue, 17 Oct 2000 fh...@at... wrote:
> >> In <Pine.LNX.4.10.10010171602340.394-100000@cassiopeia.home>, on 10/17/00 
> >>    at 04:09 PM, Geert Uytterhoeven <ge...@li...> said:
> >> 
> >> >On Tue, 17 Oct 2000 fh...@at... wrote:
> >> >> So, have I got this right?  Setup has:
> >> >To find out that unknown location, you can replace the `7' by some easy
> >> >to find unique value (whatever that may mean, e.g. 0xdeadbeef or
> >> >0xdeadcode or 0xfAedbeef (looks like Fredbeef :-)) and search for it in
> >> >memory after running the DSP script.
> >> 
> >> How to I search the memory? grep deadcode /dev/kmem ?
> 
> >No, you search from 0xc0000000 to 0xc4000000 in your driver.
> 
> Never did figure out out to search memory by address in the
> driver.  Could you use a for loop with a readl() in it?

It's very simple:

    int *p;
    for (p = (int *)0xc0000000; p < (int *)0xc4000000; p++)
	if (*p == 0xxxxxxxxx)
	    printk("Match at %p\n", p);

If you want to catch unaligned occurrencies as well, it becomes a bit more
complex.

> I got the driver to pass the cache test finally.

Good! What exactly did you have to change?

> I also found out something interesting:  There is a limit as
> to how many printks you can have in a driver. :)

Really?

> Now hopefully I can get to more of the "fun" stuff.

Good luck!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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: Symbios 53c770 driver

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

In <Pine.LNX.4.10.10010181211150.841-100000@cassiopeia.home>, on 10/18/00 
   at 12:46 PM, Geert Uytterhoeven <ge...@li...> said:

>On Tue, 17 Oct 2000 fh...@at... wrote:
>> In <Pine.LNX.4.10.10010171602340.394-100000@cassiopeia.home>, on 10/17/00 
>>    at 04:09 PM, Geert Uytterhoeven <ge...@li...> said:
>> 
>> >On Tue, 17 Oct 2000 fh...@at... wrote:
>> >> So, have I got this right?  Setup has:
>> >To find out that unknown location, you can replace the `7' by some easy
>> >to find unique value (whatever that may mean, e.g. 0xdeadbeef or
>> >0xdeadcode or 0xfAedbeef (looks like Fredbeef :-)) and search for it in
>> >memory after running the DSP script.
>> 
>> How to I search the memory? grep deadcode /dev/kmem ?

>No, you search from 0xc0000000 to 0xc4000000 in your driver.

Never did figure out out to search memory by address in the
driver.  Could you use a for loop with a readl() in it?

I got the driver to pass the cache test finally.

I also found out something interesting:  There is a limit as
to how many printks you can have in a driver. :)

Now hopefully I can get to more of the "fun" stuff.

Fred

CVS Update: 2.3

[Roman Z. <zi...@us...>]

CVSROOT:	/cvsroot/linux-apus
Module name:	2.3
Repository:	2.3/drivers/scsi/
Changes by:	zi...@sl....	00/10/19 13:45:20

Modified files:
	2.3/drivers/scsi/: a3000.c 

Log message:
	ordering fixes from 2.2

CVS Update: 2.3

[Roman Z. <zi...@us...>]

CVSROOT:	/cvsroot/linux-apus
Module name:	2.3
Repository:	2.3/include/asm-m68k/
Changes by:	zi...@sl....	00/10/19 13:44:04

Modified files:
	2.3/arch/m68k/amiga/: amisound.c chipram.c config.c 
	2.3/arch/ppc/amiga/: chipram.c config.c 
	2.3/drivers/video/: amifb.c fbmem.c 
	2.3/include/asm-m68k/: amigahw.h 

Log message:
	chip ram resource fixes and turn off video w/o amifb

Re: A3000T: Kernel 2.4.0-test9 working?

[<fp...@zu...>]

On Thu, Oct 19, 2000 at 08:53:49PM +0200, Reinhard Nissl wrote:
> Could any of the registerd developers apply this patch to the cvs sources?

Why don't you put it into the patch manager?
-- 
Frank Petzold, IBM Zurich Research Laboratory, Säumerstrasse 4,
CH-8803 Rüschlikon/Switzerland, Tel.  +41-1-724-84-42  Fax.   +41-1-724-89-56
 Business email: fp...@zu...          Private email: pe...@he...
   The opinions expressed here are mine and not necessarily those of IBM.

Re: A3000T: Kernel 2.4.0-test9 working?

[Reinhard N. <rn...@gm...>]

Hi,

Arno Griffioen wrote:
> 
> > When I disable PCI support, I cannot use CVPPC and therefore open the console
> > on my CV64/3D. There I get the following lines:
> >
> >       Non-serviced A3000 SCSI-Interrupt? ISTR xxxx
> 
> Whooo.. That's an *old* problem. Write-reordering to the WD33C93 chip.
> 
> Check out drivers/scsi/a3000.c. Are there any [rw]mb() calls in there?

You are right, they were missing. The changes you've mentioned got it going
:-)

I've attached a diff file that makes the required changes in 2.3, so that the
file is similar to 2.2 in this concern.
Could any of the registerd developers apply this patch to the cvs sources?

Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rn...@gm...

Re: A3000T: Kernel 2.4.0-test9 working?

[<gri...@ps...>]

> When I disable PCI support, I cannot use CVPPC and therefore open the console
> on my CV64/3D. There I get the following lines:
> 
> 	Non-serviced A3000 SCSI-Interrupt? ISTR xxxx

Whooo.. That's an *old* problem. Write-reordering to the WD33C93 chip.

Check out drivers/scsi/a3000.c. Are there any [rw]mb() calls in there? 

If not then the original fix for APUS is missing..

Add these lines (sorry, no line numbers.. Just quick cut'n'paste):

     /* start DMA */
+    mb();                      /* make sure setup is completed */
     DMA(a3000_host)->ST_DMA = 1;
+    mb();                      /* make sure DMA has started before next IO */
 

And:

 
     DMA(instance)->CNTR = cntr;
+    mb();                      /* make sure CNTR is updated before next IO */
 
     /* flush if we were reading */
     if (HDATA(instance)->dma_dir) {
        DMA(instance)->FLUSH = 1;
+       mb();                   /* don't allow prefetch */
        while (!(DMA(instance)->ISTR & ISTR_FE_FLG))
-           ;
+           barrier();
+       mb();                   /* no IO until FLUSH is done */
     }

Also:

     /* stop DMA */
     DMA(instance)->SP_DMA = 1;
+    mb();                      /* make sure DMA is stopped before next IO */
 
     /* restore the CONTROL bits (minus the direction flag) */
     DMA(instance)->CNTR = CNTR_PDMD | CNTR_INTEN;
+    mb();                      /* make sure CNTR is updated before next IO */
 
     /* copy from a bounce buffer, if necessary */

That should fix it..


								Bye, Arno.

-- 
PSINetworks Europe           Fax: +31-23-5699841 | One disk to rule them all,
Siriusdreef 34               Tel: +31-23-5699840 | One disk to bind them,
2132WT Hoofddorp+--------------------------------+ One disk to hold the files
The Netherlands |   *  Musical Interlude  *      | And in the darkness grind 'em
----------------+--------------------------------+------------------------------

 We say Retribution, We say Vengeance is bliss, We say Revolution,
 With a Cast-Iron fist!                  (Megadeth, 'The Disintegrators')

--------------------------------------------------------------------------------

Re: Kernel support for UW-SCSI Controller

[Alan B. <al...@ms...>]

hi,

> I am trying to get some information about the support of the AMIGA UW-SCSI
> controller of the Cyberstorm  604 board. 

the UW-SCSI interface on the CS_PPC is still not supported.

> Why must I use a IDE drive, when I have a fine UW-controller inside?

because not enough people helping to finish the driver?  the guys who are
working on the problem are working as hard as they can on it.

alan

PS blame it on the very very very slow/reluctant release of information
from Phase5 et al

Re: Kernel support for UW-SCSI Controller

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

In <yam...@ma...>, on 10/18/00 
   at 08:17 PM, Ach...@t-... (Achim Klopsch) said:

>Hello,

>I am trying to get some information about the support of the AMIGA
>UW-SCSI controller of the Cyberstorm  604 board. 

There are people working on it.  I can't say when it will work, if ever.
Could be a couple weeks.  Could be never (but I doubt it.)

>Why must I use a IDE drive, when I have a fine UW-controller inside?

Because there is no driver for the UW controller silly.

>Thanks for your help.

No problem.

Fred

A3000T: Kernel 2.4.0-test9 working?

[Reinhard N. <rn...@gm...>]

Hi,

I've successfully installed Debian Potato some days ago and was now going to
compile a recent developer kernel. I've got the 2.3 module via cvs as
mentioned on the web site and successfully compiled a kernel.

I've started the kernel configuration from scratch, so it could be that I
forgot some essential options.

My first problem is, that when I enable PCI support for Permedia2, the kernel
stops after the first heartbeat (bootmesg indicates, that the kernel was
started), with no output on console.

When I disable PCI support, I cannot use CVPPC and therefore open the console
on my CV64/3D. There I get the following lines:

	Non-serviced A3000 SCSI-Interrupt? ISTR xxxx

where xxxx changes from 64b1 to 44b1 then to 4b1 and finally to b1. Each value
remains stable for about a second or two before the next value appears. The
last value stays constant forever (<= 15 min).

A note on the message frequency: my console is 1280x1024-8 and I can see max.
two of the above mentioned values on the screen at the same time.

Finally: has anyone such a system up and running with a recent cvs kernel (e.
g. from today 20:00)?

Can anyone send me a .config file for an A3000T with CVPPC?

Is this a known problem and has anyone an idea what could be wrong?

Thanks in advance.

Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rn...@gm...

Kernel support for UW-SCSI Controller

[<Ach...@t-...>]

Hello,

I am trying to get some information about the support of the AMIGA UW-SCSI
controller of the Cyberstorm  604 board. 
Why must I use a IDE drive, when I have a fine UW-controller inside?

Thanks for your help.
-- 
Bye Achim

Achim Klopsch __________________________________
Winkelweg 46, D-91091 Grossenseebach
\\ Email: Ach...@t-...
\\ A4000/60, 64MB, SCSI, Cybervision64, Cyberstorm PPC233, Canon BJC 610

Re: Symbios 53c770 driver

[Geert U. <ge...@li...>]

On Tue, 17 Oct 2000 fh...@at... wrote:
> In <Pine.LNX.4.10.10010171602340.394-100000@cassiopeia.home>, on 10/17/00 
>    at 04:09 PM, Geert Uytterhoeven <ge...@li...> said:
> 
> >On Tue, 17 Oct 2000 fh...@at... wrote:
> >> So, have I got this right?  Setup has:
> >To find out that unknown location, you can replace the `7' by some easy
> >to find unique value (whatever that may mean, e.g. 0xdeadbeef or
> >0xdeadcode or 0xfAedbeef (looks like Fredbeef :-)) and search for it in
> >memory after running the DSP script.
> 
> How to I search the memory? grep deadcode /dev/kmem ?

No, you search from 0xc0000000 to 0xc4000000 in your driver.

> >> 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?
> 
> >Indeed weird. Perhaps the DSP doesn't have access to all memory.
> 
> The script code is allocated by a different method then the ncb structure.
> (I think.)  The cache variable is in the ncb structure.
> 
> >That 64 MB RAM is on the CSPPC and not on your A4000 motherboard, right?
> 
> I have 64MB of RAM on the CSPPC. 
> 
> >> Are virt_to_bus() and virt_to_phys() the same on your platform?
> 
> >I don't think we know that yet...
> 
> What should be the difference?

A virtual address is an address as seen by the CPU after translation by the
A physical address is an address as seen by the CPU before translation by the
MMU.
MMU.
A bus address is an address as seen by a controller on the bus.

Example: the NCR53c770 on the CSPPC
  - Physical: 0x00f4000 (in Zorro II space)0
  - Virtual: ZTWO_VADDR(0x00f4000) = 0x80f4000
  - Bus address: not needed here

Example: your RAM on the CSPPC.
  - Physical: 0x08000000-0x0bffffff
  - Virtual: 0xc0000000-0xc3ffffff
  - Bus address, as seen from the NCR53c770: we're not really sure about that

To make sure the NCR53c770 can transfer data to/from memory using DMA, it
needs to be given the _bus_ address of the buffer in memory you want to use,
hence you need to convert the virtual address of the buffer as seen by the CPU
in kernel mode to the bus address using virt_to_bus(). The driver should take
care of that.

Other example: 32 kB of RAM on the Ariadne Ethernet card at offset 0x8000 on
the card. Let's assume the card is at physical 0x00e90000, so the RAM is at
  - Physical: 0x00e98000 (in Zorro II space).
  - Virtual: ZTWO_VADDR(0x00e98000) = 0x80e98000
  - Bus address, as seen from the Ethernet chip: 0x00080000

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

New Bug Category: DevKernel

[<fp...@zu...>]

I would like to propose a new bug category: DevKernel. With that we 
can seperate bugs in the sable release from work to be done in the dev.
version.

Therefore I propose a new bug category: DevKernel

;->
-- 
Frank Petzold, IBM Zurich Research Laboratory, Säumerstrasse 4,
CH-8803 Rüschlikon/Switzerland, Tel.  +41-1-724-84-42  Fax.   +41-1-724-89-56
 Business email: fp...@zu...          Private email: pe...@he...
   The opinions expressed here are mine and not necessarily those of IBM.

[Bug #117164] 2.4: Printing with parport_mfc3 hangs

[<no...@so...>]

Bug #117164, was updated on 2000-Oct-18 04:16
Here is a current snapshot of the bug.

Project: Linux/APUS Kernel
Category: Kernel
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.4: Printing with parport_mfc3 hangs

Details: Sending data to /dev/lp connected to a parport_mfc3 hangs the machine. Heartbeat continues, though.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117164&group_id=5907

[Bug #117163] 2.4: parport_amiga does not work

[<no...@so...>]

Bug #117163, was updated on 2000-Oct-18 04:11
Here is a current snapshot of the bug.

Project: Linux/APUS Kernel
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.4: parport_amiga does not work

Details: Printing to a printer on the internal parallel port
does not work.

This problem seemed to have existed in the 2.1 tree, but was
fixed there once.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117163&group_id=5907

Report on test9

[<fp...@zu...>]

Yesterday I compiles -test9. The following does not work:

Printing with parport_amiga (garbled output)
Printing with parport_mfc3  (hangs the machine)

I have not tested floppy access. sg is fine again.
-- 
Frank Petzold, IBM Zurich Research Laboratory, Säumerstrasse 4,
CH-8803 Rüschlikon/Switzerland, Tel.  +41-1-724-84-42  Fax.   +41-1-724-89-56
 Business email: fp...@zu...          Private email: pe...@he...
   The opinions expressed here are mine and not necessarily those of IBM.

Re: Symbios 53c770 driver

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

In <Pine.LNX.4.10.10010171602340.394-100000@cassiopeia.home>, on 10/17/00 
   at 04:09 PM, Geert Uytterhoeven <ge...@li...> said:

>On Tue, 17 Oct 2000 fh...@at... wrote:
>> So, have I got this right?  Setup has:
>To find out that unknown location, you can replace the `7' by some easy
>to find unique value (whatever that may mean, e.g. 0xdeadbeef or
>0xdeadcode or 0xfAedbeef (looks like Fredbeef :-)) and search for it in
>memory after running the DSP script.

How to I search the memory? grep deadcode /dev/kmem ?

>> 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?

>Indeed weird. Perhaps the DSP doesn't have access to all memory.

The script code is allocated by a different method then the ncb structure.
(I think.)  The cache variable is in the ncb structure.

>That 64 MB RAM is on the CSPPC and not on your A4000 motherboard, right?

I have 64MB of RAM on the CSPPC. 

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

>I don't think we know that yet...

What should be the difference?

Fred

Re: Amiga Memory map

[Geert U. <ge...@li...>]

On Tue, 17 Oct 2000, Arno Griffioen wrote:
> In the 2.2.10 kernel in arch/ppc/mm/init.c it reads:
> 
> setbat(1, zTwoBase,   0x00000000, 0x01000000, IO_PAGE);
> 
> Which seems to indicate that the entire 16Mb lower block from 0x00000000
> up to 0x01000000 is mapped to 0x80000000 as IO_PAGE, which expands
> to:
> 
> 	PAGE_NO_CACHE
> 	PAGE_GUARDED
> 	PAGE_RW
> 
> Not sure what 'GUARDED' is. The others should be self-explanatory.

IIRC< `GUARDED' means that no reordering should be done on accesses to this
area.

> So CS-PPC access for you should probably happen to/from 0x80F40000+offset.
> (should be the same as ZTWO_VADDR(F40000 + offset))

Or `ZTWO_VADDR(0xF40000)+offset', so you have to use ZTWO_VADDR() only once.

The disadvantage of using plain 0x80F40000+offset is that it will break when
we change the mapping of Zorro II space :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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: Symbios 53c770 driver

[Geert U. <ge...@li...>]

On Tue, 17 Oct 2000 fh...@at... wrote:
> 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 the `0' in the SCRATCHA register was copied from some unknown location in
the address map of the CPU, and not from ncr_cache.

Furthermore the `7' was written to that same unknown location. Since it could
be read back and stored into the TEMP register (TEMP is still `7', and not
garbage), this unknown location must be memory.

To find out that unknown location, you can replace the `7' by some easy to
find unique value (whatever that may mean, e.g. 0xdeadbeef or 0xdeadcode or
0xfAedbeef (looks like Fredbeef :-)) and search for it in memory after running
the DSP script.

> 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?

Indeed weird. Perhaps the DSP doesn't have access to all memory.

That 64 MB RAM is on the CSPPC and not on your A4000 motherboard, right?

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

I don't think we know that yet...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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: Symbios 53c770 driver

[<gri...@ps...>]

Perhaps this has already been suggested, but what happens when you
change (in 2.2.10) arch/ppc/mm/init.c line 1609 from:

#define RAM_PAGE (_PAGE_RW)

to

#define RAM_PAGE (_PAGE_NO_CACHE | _PAGE_RW)

It should run *slow*, but any CPU caching should be gone.

								Bye, Arno.


-- 
PSINetworks Europe           Fax: +31-23-5699841 | One disk to rule them all,
Siriusdreef 34               Tel: +31-23-5699840 | One disk to bind them,
2132WT Hoofddorp+--------------------------------+ One disk to hold the files
The Netherlands |   *  Musical Interlude  *      | And in the darkness grind 'em
----------------+--------------------------------+------------------------------

 We say Retribution, We say Vengeance is bliss, We say Revolution,
 With a Cast-Iron fist!                  (Megadeth, 'The Disintegrators')

--------------------------------------------------------------------------------

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...
-----------------------------------------------------------

Re: Amiga Memory map

[<gri...@ps...>]

> >$E90000 -	$EFFFFF		64K Autoconfig slots
> >$F00000 -	$FFFFFF		ROM space
> 
> Hmmm.  This is where the CSPPC SCSI is located.  This seems to be in the
> wrong spot?  

Doesn't have to be as the CS-PPC does the initial bootstrapping before
kickstart is started (eg. the pre-boot menu of the CyberStorm). So I guess
it would be logical to find it there.

> Does the APUS kernel mark this memory as read only?

Doesn't look like it.

In the 2.2.10 kernel in arch/ppc/mm/init.c it reads:

setbat(1, zTwoBase,   0x00000000, 0x01000000, IO_PAGE);

Which seems to indicate that the entire 16Mb lower block from 0x00000000
up to 0x01000000 is mapped to 0x80000000 as IO_PAGE, which expands
to:

	PAGE_NO_CACHE
	PAGE_GUARDED
	PAGE_RW

Not sure what 'GUARDED' is. The others should be self-explanatory.

So CS-PPC access for you should probably happen to/from 0x80F40000+offset.
(should be the same as ZTWO_VADDR(F40000 + offset))

								Bye, Arno.

-- 
PSINetworks Europe           Fax: +31-23-5699841 | One disk to rule them all,
Siriusdreef 34               Tel: +31-23-5699840 | One disk to bind them,
2132WT Hoofddorp+--------------------------------+ One disk to hold the files
The Netherlands |   *  Musical Interlude  *      | And in the darkness grind 'em
----------------+--------------------------------+------------------------------

 We say Retribution, We say Vengeance is bliss, We say Revolution,
 With a Cast-Iron fist!                  (Megadeth, 'The Disintegrators')

--------------------------------------------------------------------------------

Re: Amiga Memory map

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

In <200...@su...>, on 10/16/00 
   at 07:25 PM, gri...@ps... (Arno Griffioen) said:

Thanks for the memory map!


>Finally dug up the A3000 schematics at home.

>This is the list in the schematics document:

>$000000	-	$1FFFFF		Up to 2Megs of CHIP mem
>$200000 -	$9FFFFF		Auto-Config memory space (Z-II)
>$A00000 -	$BFFFFF		IO Space (8520s)
>$C00000 -	$D7FFFF		A500 'ranger' memory
>$D80000 -	$D9FFFF		Custom chip register mirror or RTC
>$DA0000 -	$DBFFFF		Unused
>$DC0000 -	$DDFFFF		RTC
>$DE0000 -	$DFFFFF		Custom Chip Registers
>$E00000 -	$E7FFFF		Unused
>$E80000 -	$E8FFFF		Autoconfig Slot
>$E90000 -	$EFFFFF		64K Autoconfig slots
>$F00000 -	$FFFFFF		ROM space

Hmmm.  This is where the CSPPC SCSI is located.  This seems to be in the
wrong spot?  Does the APUS kernel mark this memory as read only?

0xf40000

>$01000000 -	$07FFFFFF	On-board 32 bit RAM. Grows DOWN from $07FFFFFF
>$08000000 -	$0FFFFFFF	32 bit expansion. Grows UP from $08000000 $10000000
>-	$EFFFFFFF	32 bit 'other' expansion space

>								Bye, Arno.

Fred