pseudo 32 bit physical addresses and the real 36 bit world

pseudo 32 bit physical addresses and the real 36 bit world

[Freddy Spierenburg]

[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]

Hi,

The AU1100 processor uses internally a 36-bit address bus. The
kernel (32 bits) is only able to work with 32-bit addresses.
Well, there must exist some sort of scheme for the kernel to work
with these 36-bit addresses, but I don't quiet get it yet. Is
anybody willing to give me some insight?

I'm looking at the pcmcia implementation at this moment and I
don't get it. If I look at drivers/pcmcia/au1000_generic.h I see
AU1X_SOCK0_IO defines as 0xF00000000 (note the 36 bit length).
This one is used in drivers/pcmcia/au1000_generic.c
au1x00_pcmcia_socket_probe() where it get cast to phys_t. phys_t
is a typedef from include/asm-mips/types.h as an unsigned long.
Of course the compiler warns us during compilation of
drivers/pcmcia/au1000_generic.c:

drivers/pcmcia/au1000_generic.c:403: warning: integer constant is too large for "long" type
drivers/pcmcia/au1000_generic.c:406: warning: integer constant is too large for "long" type
drivers/pcmcia/au1000_generic.c:414: warning: integer constant is too large for "long" type

And this is where I'm sort of lost. How can this scheme work? I
must be missing something, but I don't understand it. I expect
from reading the au1100 databook and 'See MIPS Run (chapter 6)
that the TLB is involved, but I'm not yet able to link it
altogether.

I also expect more is happening with the
AU1X_SOCK0_PSEUDO_PHYS_ATTR and AU1X_SOCK0_PSEUDO_PHYS_MEM, but
not that I can find any clue how this appears to work.

To end this email into a happy end I shall also explain what I
really want to do. We've built our own computer using the AU1100
processor. We've connected two SC16C652 dual UART's, one to RCS2
and one to RCS3. Now I want to map those UARTS at AE000000 and
AE040000. I've configured the mem_stcfg[23], mem_sttime[23] and
mem_staddr[23] registers in yamon:

  #define MEM_STCFG[23]   0x00000001
  #define MEM_STTIME[23]  0x03FFC7C7
  #define MEM_STADDR2     0x1AE03FFF
  #define MEM_STADDR3     0x1AE07FFF

But after that I'm sort of lost in the dark. What should I do
inside the kernel so that when I refer to AE000000 in my driver
the processor triggers chip select 2 (RCS2)?

Any hints would be appreciated.


-- 
$ cat ~/.signature
Freddy Spierenburg <freddy@dusktilldawn.nl>  http://freddy.snarl.nl/
GnuPG: 0x7941D1E1=C948 5851 26D2 FA5C 39F1  E588 6F17 FD5D 7941 D1E1
$ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pseudo 32 bit physical addresses and the real 36 bit world

[Dan Malek]

On Jul 19, 2006, at 11:58 AM, Freddy Spierenburg wrote:

> The AU1100 processor uses internally a 36-bit address bus. The
> kernel (32 bits) is only able to work with 32-bit addresses.
> Well, there must exist some sort of scheme for the kernel to work
> with these 36-bit addresses, but I don't quiet get it yet. Is
> anybody willing to give me some insight?

On the Alchemy processors, only some peripherals exist
above the 32-bit boundary.  We use a 64-bit version of
ioremap() to access this space.

> Of course the compiler warns us during compilation of
> drivers/pcmcia/au1000_generic.c:
>
> drivers/pcmcia/au1000_generic.c:403: warning: integer constant is  
> too large for "long" type

It looks like your configuration file is not enabling the
64-bit IO option.

> ....  I expect
> from reading the au1100 databook and 'See MIPS Run (chapter 6)
> that the TLB is involved, but I'm not yet able to link it
> altogether.

This has already been done for you :-)  There is nothing
for you to invent.  You didn't mention which version of
the kernel you are using, but the default configuration
files for boards with Alchemy processors should have
all of this properly configured.

Thanks.

	-- Dan

Re: pseudo 32 bit physical addresses and the real 36 bit world

[Pete Popov]

On Wed, 2006-07-19 at 17:58 +0200, Freddy Spierenburg wrote:
> Hi,
> 
> The AU1100 processor uses internally a 36-bit address bus. The
> kernel (32 bits) is only able to work with 32-bit addresses.
> Well, there must exist some sort of scheme for the kernel to work
> with these 36-bit addresses, but I don't quiet get it yet. Is
> anybody willing to give me some insight?
> 
> I'm looking at the pcmcia implementation at this moment and I
> don't get it. If I look at drivers/pcmcia/au1000_generic.h I see
> AU1X_SOCK0_IO defines as 0xF00000000 (note the 36 bit length).
> This one is used in drivers/pcmcia/au1000_generic.c
> au1x00_pcmcia_socket_probe() where it get cast to phys_t. phys_t
> is a typedef from include/asm-mips/types.h as an unsigned long.
> Of course the compiler warns us during compilation of
> drivers/pcmcia/au1000_generic.c:
> 
> drivers/pcmcia/au1000_generic.c:403: warning: integer constant is too large for "long" type
> drivers/pcmcia/au1000_generic.c:406: warning: integer constant is too large for "long" type
> drivers/pcmcia/au1000_generic.c:414: warning: integer constant is too large for "long" type
> 
> And this is where I'm sort of lost. How can this scheme work? 

PCMCIA is one of the peripherals on the Au1x processors that is accessed
on a 36bit physical address. The actual phys address is 36 bit, however,
the generic Linux pcmcia layer doesn't support 36 bit phys addresses. In
order to avoid having to modify that common code, the Au1x 36 bit
support uses, in this case, 32 bit pseudo phys address. If you take a
look at ioremap(), you'll see a call to a fixup function. This function
detects the pseudo phys address and returns the real 36 bit phys address
that then gets ioremapped.

> I
> must be missing something, but I don't understand it. I expect
> from reading the au1100 databook and 'See MIPS Run (chapter 6)
> that the TLB is involved, but I'm not yet able to link it
> altogether.
> 
> I also expect more is happening with the
> AU1X_SOCK0_PSEUDO_PHYS_ATTR and AU1X_SOCK0_PSEUDO_PHYS_MEM, but
> not that I can find any clue how this appears to work.
> 
> To end this email into a happy end I shall also explain what I
> really want to do. We've built our own computer using the AU1100
> processor. We've connected two SC16C652 dual UART's, one to RCS2
> and one to RCS3. Now I want to map those UARTS at AE000000 and
> AE040000. I've configured the mem_stcfg[23], mem_sttime[23] and
> mem_staddr[23] registers in yamon:
> 
>   #define MEM_STCFG[23]   0x00000001
>   #define MEM_STTIME[23]  0x03FFC7C7
>   #define MEM_STADDR2     0x1AE03FFF
>   #define MEM_STADDR3     0x1AE07FFF
> 
> But after that I'm sort of lost in the dark. What should I do
> inside the kernel so that when I refer to AE000000 in my driver
> the processor triggers chip select 2 (RCS2)?

Assuming you've setup mem_xxxx correctly, and AE000000 does not overlap
with some other phys address already used, then you should be ioremap
that address and use it directly.

Pete

Re: pseudo 32 bit physical addresses and the real 36 bit world

[Ulrich Eckhardt]

On Wednesday 19 July 2006 17:58, Freddy Spierenburg wrote:
> The AU1100 processor uses internally a 36-bit address bus. The
> kernel (32 bits) is only able to work with 32-bit addresses.
> Well, there must exist some sort of scheme for the kernel to work
> with these 36-bit addresses, but I don't quiet get it yet. Is
> anybody willing to give me some insight?
[...]
> I expect
> from reading the au1100 databook and 'See MIPS Run (chapter 6)
> that the TLB is involved, but I'm not yet able to link it
> altogether.

As others already said, the TLB is involved. However, there are two modes in 
which you can compile the kernel, with 32 and 64 bit physical addresses. For 
the 32 bit case (which is a bit hackish) its "physical addresses" are not 
always what the real physical addresses are for the Alchemy CPU, there is a 
functions called fixup or so that converts some parts of this range when 
creating real physical addresses for the TLB.

> I'm looking at the pcmcia implementation at this moment and I
> don't get it. If I look at drivers/pcmcia/au1000_generic.h I see
> AU1X_SOCK0_IO defines as 0xF00000000 (note the 36 bit length).
> This one is used in drivers/pcmcia/au1000_generic.c
> au1x00_pcmcia_socket_probe() where it get cast to phys_t. phys_t
> is a typedef from include/asm-mips/types.h as an unsigned long.
> Of course the compiler warns us during compilation of
> drivers/pcmcia/au1000_generic.c:
>
> drivers/pcmcia/au1000_generic.c:403: warning: integer constant is too large
> for "long" type drivers/pcmcia/au1000_generic.c:406: warning: integer
> constant is too large for "long" type drivers/pcmcia/au1000_generic.c:414:
> warning: integer constant is too large for "long" type

This is possibly an error. I know there are some cases where this causes  
runtime errors when you don't have 64 bit physical addresses, but I thought 
the configuration ("make config" & Co) had been fixed to not allow this case. 
I had also proposed to add a preprocessor check that generates an error but 
that was refused, I hope this is not the case where it would have fired here.

Turn on 64 bit physical addresses when in doubt.

> I also expect more is happening with the
> AU1X_SOCK0_PSEUDO_PHYS_ATTR and AU1X_SOCK0_PSEUDO_PHYS_MEM, but
> not that I can find any clue how this appears to work.
>
> To end this email into a happy end I shall also explain what I
> really want to do. We've built our own computer using the AU1100
> processor. We've connected two SC16C652 dual UART's, one to RCS2
> and one to RCS3. Now I want to map those UARTS at AE000000 and
> AE040000. I've configured the mem_stcfg[23], mem_sttime[23] and
> mem_staddr[23] registers in yamon:
>
>   #define MEM_STCFG[23]   0x00000001
>   #define MEM_STTIME[23]  0x03FFC7C7
>   #define MEM_STADDR2     0x1AE03FFF
>   #define MEM_STADDR3     0x1AE07FFF
>
> But after that I'm sort of lost in the dark. What should I do
> inside the kernel so that when I refer to AE000000 in my driver
> the processor triggers chip select 2 (RCS2)?

I didn't check above values, but inside the kernel you simply need to 
ioremap() or ioremap_nocache() the range you want to access, specified by the 
physical address of the device (this address is probably not AE000000!).

ioremap() gives you a pointer to a virtual address (32 bit, regardless of 
physical address size) which you can use to access the UARTs. Note that this 
doesn't map to the addresses AE000000 and AE040000 but selects a virtual 
address itself, but you shouldn't depend on that. If you do, you will need to 
take different measures.

Uli

****************************************************
Visit our website at <http://www.domino-printing.com/>
****************************************************
This Email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any reading, redistribution, disclosure or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please contact the sender immediately and delete the material from your computer.

E-mail may be susceptible to data corruption, interception, viruses and unauthorised amendment and Domino UK Limited does not accept liability for any such corruption, interception, viruses or amendment or their consequences.
****************************************************