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