linux-apus-devel

Re: APUS bus access

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

> >Or if the device you write to immediately processes the input and in the
> >process mangles the external view of the register. 
> 
> >It is a read/write register I hope.. (just checking..)
> 
> The register is listed in the docs as R/W.   Whether that means it does
> not mangle; I don't know.

Hmm.. Any hints in the docs? (BTW. Where could I get those? A PDF file
somewhere?)

> Maybe I should try writing the register in two 16 bit chunks.  The only
> problem I see with that is that I think the SCSI chip starts execution of
> the script upon filling of that register with the address.

Is there another register which you can abuse in some way? Is there perhaps
a status/control register which will enable you to test some read/write
actions by flipping some bits? 

								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: APUS bus access

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

On Wed, 9 Aug 2000 fh...@at... wrote:
> In <Pine.LNX.4.10.10008091645550.416-100000@cassiopeia.home>, on 08/09/00 
>    at 04:56 PM, Geert Uytterhoeven <ge...@li...> said:
> 
> >On Wed, 9 Aug 2000 hei...@at... wrote:
> 
> >Ideally, readl() and friends are meant for _PCI_ memory space only, and
> >PCI is per definition little endian.
> 
> Hmmm.  So those functions are meant for folks that use PowerMacs? I was
> thinking today that those functions had to be OK because APUS drivers must
> use them.  Perhaps this is not the case?

They are used for PPC boxes with PCI. Hence the CyberversionPPC could use them
as well.

> >to sym53c8xx_defs.h (or use le32 if the wiring on the board turns out to
> >be different), for clarity.
> 
> I really don't want to open my Amiga to see how the '770 chip is wired to
> the PPC.   I'm not sure if I could tell by just looking at it anyway.   It
> is  most likely possible to find out with a logic probe, since I think the
>  endianess is set by wiring some pins with the correct logic values.  At
> least I thought I read that somewhere.

I did not mean you have to open it :-) It would indeed still be hard to find
out...

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: APUS bus access

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

> Hmm.. Any hints in the docs? (BTW. Where could I get those? A PDF file
> somewhere?)

Forget it.. Found 'em..

Printing now :-)

								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: APUS bus access

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

In <200...@su...>, on 07/18/00 
   at 01:21 PM, gri...@ps... (Arno Griffioen) said:

>Is there another register which you can abuse in some way? Is there
>perhaps a status/control register which will enable you to test some
>read/write actions by flipping some bits? 

Yes.  There may be some.  I was browsing the programmers manual last
night.  There are some various debugging registers.

BTW  Gerard said the driver should be MMIO and not IO_MAPPED. I may try
turning off I/O mapped and see what happens.  He also said he would have
liked to work on MMIO, on non-PC hardware I presume, but has no hardware
to do the work.  Does anyone have any ideas on MMIO vs IO MAPPED?  On
first thought I'm not sure I understand the differences.

Fred

Re: APUS bus access

[Sven L. <lu...@dp...>]

On Tue, Jul 18, 2000 at 07:57:36AM -0400, fh...@at... wrote:
> In <200...@su...>, on 07/18/00 
>    at 01:21 PM, gri...@ps... (Arno Griffioen) said:
> 
> >Is there another register which you can abuse in some way? Is there
> >perhaps a status/control register which will enable you to test some
> >read/write actions by flipping some bits? 
> 
> Yes.  There may be some.  I was browsing the programmers manual last
> night.  There are some various debugging registers.
> 
> BTW  Gerard said the driver should be MMIO and not IO_MAPPED. I may try
> turning off I/O mapped and see what happens.  He also said he would have
> liked to work on MMIO, on non-PC hardware I presume, but has no hardware
> to do the work.  Does anyone have any ideas on MMIO vs IO MAPPED?  On
> first thought I'm not sure I understand the differences.

Is not mmio when you see the registers as one big memory chunk, like we are
used to on amiga, and io_mapped, when you see the register as a pair address +
data to be passed to the device like they used to do on pc hardware ?

Friendly,

Sven LUTHER

Re: APUS bus access

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

> BTW  Gerard said the driver should be MMIO and not IO_MAPPED. I may try
> turning off I/O mapped and see what happens.  He also said he would have
> liked to work on MMIO, on non-PC hardware I presume, but has no hardware
> to do the work.  Does anyone have any ideas on MMIO vs IO MAPPED?  On
> first thought I'm not sure I understand the differences.

Probably some subtle difference. MMIO should be the way we're used to on the
680x0 and PPC. 'flat' register space in memory. No special tricks required,
just a base-address and some offsets.

I'm not sure what the difference would be between MMIO and IO_MAPPED, but 
perhaps it's some way of mapping the Intel I/O port concept onto 
memory. That my require some tricks when accessing (eg. write register 
number first, then read or write data).

Perhaps Geert has seen this difference before in video-cards? They also
have all sorts of MMIO and I/O mapping stuff.

								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: APUS bus access

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

On Tue, 18 Jul 2000, Arno Griffioen wrote:
> > BTW  Gerard said the driver should be MMIO and not IO_MAPPED. I may try
> > turning off I/O mapped and see what happens.  He also said he would have
> > liked to work on MMIO, on non-PC hardware I presume, but has no hardware
> > to do the work.  Does anyone have any ideas on MMIO vs IO MAPPED?  On
> > first thought I'm not sure I understand the differences.
> 
> Probably some subtle difference. MMIO should be the way we're used to on the
> 680x0 and PPC. 'flat' register space in memory. No special tricks required,
> just a base-address and some offsets.
> 
> I'm not sure what the difference would be between MMIO and IO_MAPPED, but 
> perhaps it's some way of mapping the Intel I/O port concept onto 
> memory. That my require some tricks when accessing (eg. write register 
> number first, then read or write data).
> 
> Perhaps Geert has seen this difference before in video-cards? They also
> have all sorts of MMIO and I/O mapping stuff.

Intel CPUs have separate memory and I/O spaces, while a 680x0 has memory space
only.

I/O space is meant for I/O devices (obviously) and uses special I/O
instructions ({in,out}[bwl]) to access I/O registers.

Memory space I/O (MMIO) means you just read/write from/to memory to access the
I/O registers that are located at the specified memory address.

I/O space allows you to have the full memory space populated with RAM, and
still room for I/O devices in I/O space. But since you need more bus signals
(to differentiate between memory and I/O accesses) and more instructions
(normal memory access + special I/O instructions), modern CPUs don't have I/O
space anymore. If they need it, they just reserve some piece of memory for it,
and use the ordinary memory instructions to access it, while the host bridge
takes care of converting them to I/O accesses on the I/O bus (usually PCI
these days, with ISA behind a PCI/ISA bridge).

Under Linux/m68k, inb() and friends don't do anything on Amiga, since Amiga
doesn't have I/O space (except with your GG2, Arno :-).

Under Linux/PPC, inb() and friends just access MMIO at isa_io_base+offset
(cfr. <asm/io.h>). Indeed, on PReP and CHRP ISA and PCI I/O space is not real
I/O space, but MMIO at some specific address. On APUS, there's no I/O space
(AFAIK), so you always have to use MMIO.

Since you used I/O space (through inb() and friends), data written ended up
somewhere at the wrong address (uninitialized isa_io_base on APUS), which was
probably a 16-bit only address of whatever. Reading it back thus gave the
wrong value. Instead of inb() and friends you should read/write from/to memory
space directly, using in_be32() and friends. These do eieio as well, to
protect against reorderings.

BTW, I see some things in <asm/io.h> that shouldn't be there:

#if defined(CONFIG_APUS)
#define inw(port)               in_be16((u16 *)((port)+_IO_BASE))
#define outw(val, port)         out_be16((u16 *)((port)+_IO_BASE), (val))
#define inl(port)               in_be32((u32 *)((port)+_IO_BASE))
#define outl(val, port)         out_be32((u32 *)((port)+_IO_BASE), (val))
#else

Since APUS doesn't have I/O space, these should not be defined at all.

[ Hmm, they are defined to in_be16() and friends. Why??? ]

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: APUS bus access

[<hei...@at...>]

----- Original Message -----
From: "Geert Uytterhoeven" <ge...@li...>
To: "Arno Griffioen" <gri...@ps...>
Cc: <fh...@at...>; <lin...@li...>
Sent: Tuesday, July 18, 2000 2:18 PM
Subject: Re: APUS bus access


> On Tue, 18 Jul 2000, Arno Griffioen wrote:

> BTW, I see some things in <asm/io.h> that shouldn't be there:
>
> #if defined(CONFIG_APUS)
> #define inw(port)               in_be16((u16 *)((port)+_IO_BASE))
> #define outw(val, port)         out_be16((u16 *)((port)+_IO_BASE), (val))
> #define inl(port)               in_be32((u32 *)((port)+_IO_BASE))
> #define outl(val, port)         out_be32((u32 *)((port)+_IO_BASE), (val))
> #else
>
> Since APUS doesn't have I/O space, these should not be defined at all.
>
> [ Hmm, they are defined to in_be16() and friends. Why??? ]
>

In the MMIO 53c770 driver readw, readl, writew, writel are used when both
the driver and SCSI chip are in big endian mode.   I was just looking in
asm-ppc
and in io.h it has #define readw(addr)  in_le16((volatile unsigned short
*)addr))
and #define readl(addr)  in_le32((volatile unsigned  *)addr)).  Why is the
"le"?
Shouldn't this be "be".    The writel is also defined as out_le32().
Is APUS big endian or little endian.  Is M68K Linux big endian or little
endian?
Am I so confused about this?  Can someone explain it to me?   I always think
big endian == m68k, sparc; little endian == intel, alpha.
Is the Amiga different?  What is Power Macintosh Linux?

BTW I tried writing 0xee00ff11 to a 32 bit register on the '770 chip and got
0xff11 back.

Fred

Re: APUS bus access

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

On Wed, 9 Aug 2000 hei...@at... wrote:
> In the MMIO 53c770 driver readw, readl, writew, writel are used when both
> the driver and SCSI chip are in big endian mode.   I was just looking in
> asm-ppc
> and in io.h it has #define readw(addr)  in_le16((volatile unsigned short
> *)addr))
> and #define readl(addr)  in_le32((volatile unsigned  *)addr)).  Why is the
> "le"?
> Shouldn't this be "be".    The writel is also defined as out_le32().

Ideally, readl() and friends are meant for _PCI_ memory space only, and PCI is
per definition little endian.

However, the MMIO 53c770 driver currently works on SPARC only. At least on
SPARC64, you can specify the endiannes of a page in the MMU page tables. So on
SPARC64, the page tables will be set up such that readl() will be little endian
on PCI memory space and big endian on SBUS memory space. Nice for driver
writers, readl() is always correct :-)

I suggest you add

    #elif defined(CONFIG_APUS)
    #define readl_l2b(a,b)	in_be32(b,a)
    ...

to sym53c8xx_defs.h (or use le32 if the wiring on the board turns out to be
different), for clarity.

> Is APUS big endian or little endian.  Is M68K Linux big endian or little
> endian?
> Am I so confused about this?  Can someone explain it to me?   I always think
> big endian == m68k, sparc; little endian == intel, alpha.
> Is the Amiga different?  What is Power Macintosh Linux?

m68k is big endian
PPC can be both (PPC had to run NT, sigh), but Linux/PPC is big endian
MIPS can be both: little endian on e.g. DECstation, big endian on SGI

> BTW I tried writing 0xee00ff11 to a 32 bit register on the '770 chip and got
> 0xff11 back.

And it's a register that allows reading back the same value?

OK, so you know at least how to access the least significant short.
Now you have to find out where the upper part went to, or where it has to go
to.

Is there any read register for which you can guess what you should read? Some
chip id or revision number register?

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: APUS bus access

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

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

>On Wed, 9 Aug 2000 hei...@at... wrote:

>Ideally, readl() and friends are meant for _PCI_ memory space only, and
>PCI is per definition little endian.

Hmmm.  So those functions are meant for folks that use PowerMacs? I was
thinking today that those functions had to be OK because APUS drivers must
use them.  Perhaps this is not the case?

>However, the MMIO 53c770 driver currently works on SPARC only. At least
>on SPARC64, you can specify the endiannes of a page in the MMU page
>tables. So on SPARC64, the page tables will be set up such that readl()
>will be little endian on PCI memory space and big endian on SBUS memory
>space. Nice for driver writers, readl() is always correct :-)

I gather the '770 chip is used on an SBUS card and there is a Linux driver
for it then?  I have a rather old version of the 53c770 files that was
made known to me by someone on the APUS list.  Perhaps I should be using
the SPARC version instead.

>I suggest you add

>    #elif defined(CONFIG_APUS)
>    #define readl_l2b(a,b)	in_be32(b,a)
>    ...

If I define that both the PPC and and the '770 chip are big endian then I
don't think that the readl_l2b is defined.  But I will experiment with
using the in_be32 function.

>to sym53c8xx_defs.h (or use le32 if the wiring on the board turns out to
>be different), for clarity.

I really don't want to open my Amiga to see how the '770 chip is wired to
the PPC.   I'm not sure if I could tell by just looking at it anyway.   It
is  most likely possible to find out with a logic probe, since I think the
 endianess is set by wiring some pins with the correct logic values.  At
least I thought I read that somewhere.

>> Is APUS big endian or little endian.  Is M68K Linux big endian or little
>> endian?
>> Am I so confused about this?  Can someone explain it to me?   I always think
>> big endian == m68k, sparc; little endian == intel, alpha.
>> Is the Amiga different?  What is Power Macintosh Linux?

>m68k is big endian
>PPC can be both (PPC had to run NT, sigh), but Linux/PPC is big endian
>MIPS can be both: little endian on e.g. DECstation, big endian on SGI

>> BTW I tried writing 0xee00ff11 to a 32 bit register on the '770 chip and got
>> 0xff11 back.

>And it's a register that allows reading back the same value?

There are three registers, off hand, that should be able to R/W 32 bit
values, they are TEMP, SCRATCHA, and SCRATCHB.  Actually there are a
number of SCRATCHx registers, so probably more than three. 

>OK, so you know at least how to access the least significant short. Now
>you have to find out where the upper part went to, or where it has to go
>to.

Yep.

>Is there any read register for which you can guess what you should read?
>Some chip id or revision number register?

I don't see one by looking in the programming guide, right at the moment.
 
Fred

Re: APUS bus access

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

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

>On Wed, 9 Aug 2000 hei...@at... wrote:

>OK, so you know at least how to access the least significant short. Now
>you have to find out where the upper part went to, or where it has to go
>to.

>Is there any read register for which you can guess what you should read?
>Some chip id or revision number register?

I inserted the in_be32 and out_be32 instructions in the driver code. Now
when I write 0xee00ff11 to a 32 bit register I get back "2". That's
right..."2".   

This is just too wierd...

Fred

Re: APUS bus access

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

On Thu, 10 Aug 2000 fh...@at... wrote:
> In <Pine.LNX.4.10.10008091645550.416-100000@cassiopeia.home>, on 08/09/00 
>    at 04:56 PM, Geert Uytterhoeven <ge...@li...> said:
> 
> >On Wed, 9 Aug 2000 hei...@at... wrote:
> 
> >OK, so you know at least how to access the least significant short. Now
> >you have to find out where the upper part went to, or where it has to go
> >to.
> 
> >Is there any read register for which you can guess what you should read?
> >Some chip id or revision number register?
> 
> I inserted the in_be32 and out_be32 instructions in the driver code. Now
> when I write 0xee00ff11 to a 32 bit register I get back "2". That's
> right..."2".   
> 
> This is just too wierd...

You did take into account that writel_l2b(), writel(), out_be32() and
out_le32() all don't use the same order of the arguments?

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