[Top] [All Lists]

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

Subject: Re: pseudo 32 bit physical addresses and the real 36 bit world
From: Ulrich Eckhardt <>
Date: Thu, 20 Jul 2006 08:58:52 +0200
In-reply-to: <>
Organization: Sator Laser GmbH
Original-recipient: rfc822;
References: <>
User-agent: KMail/1.9.1
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
> 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.


Visit our website at <>
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.

<Prev in Thread] Current Thread [Next in Thread>