Hi,
I'm developing some drivers for the AU1000 under
Mountain Vista's 2.4.17 sherman release. The AU1000 is
a MIPS based SOC with a 36 bit internal address bus
and a 32 bit MIPS cpu. According to the documentation
the MIPS' TLB is able to map 32 bit virtual addresses
to 36 bit physical addresses, however I cannot figure
out how to get Linux to set this up. I've looked at
ioremap which only takes unsigned long (32bits) as an
argument to assign a virtual address. Is there
another way?
thanks
Padraig
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
On Tue, 15 Oct 2002, Padraig O Mathuna wrote:
> I'm developing some drivers for the AU1000 under
> Mountain Vista's 2.4.17 sherman release. The AU1000 is
> a MIPS based SOC with a 36 bit internal address bus
> and a 32 bit MIPS cpu. According to the documentation
> the MIPS' TLB is able to map 32 bit virtual addresses
> to 36 bit physical addresses, however I cannot figure
> out how to get Linux to set this up. I've looked at
> ioremap which only takes unsigned long (32bits) as an
> argument to assign a virtual address. Is there
> another way?
You should probably look at how CONFIG_HIGHMEM and CONFIG_64BIT_PHYS_ADDR
support is implemented and add an option like CONFIG_36BIT_PHYS_ADDR (or
just use CONFIG_HIGHMEM for that) plus a few necessary bits to the mm code
so that ioremap() can make use of the additional bits. It doesn't seem
too difficult to develop, but you may want to work on a current snapshot
from the CVS.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
Followup to: <[email protected]>
By author: Padraig O Mathuna <[email protected]>
In newsgroup: linux.dev.kernel
>
> I'm developing some drivers for the AU1000 under
> Mountain Vista's 2.4.17 sherman release. The AU1000 is
> a MIPS based SOC with a 36 bit internal address bus
> and a 32 bit MIPS cpu. According to the documentation
> the MIPS' TLB is able to map 32 bit virtual addresses
> to 36 bit physical addresses, however I cannot figure
> out how to get Linux to set this up. I've looked at
> ioremap which only takes unsigned long (32bits) as an
> argument to assign a virtual address. Is there
> another way?
>
Oh no, the x86 madness is spreading!!!!
(It's depressing this happening on a MIPS system, which has been 64
bits since who-knows-when...)
*Vomit*
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
From: "H. Peter Anvin" <[email protected]>
Date: 15 Oct 2002 15:54:35 -0700
Oh no, the x86 madness is spreading!!!!
It's actually old madness, some sparc32 systems were 32+36 as well :-)
On Tue, Oct 15, 2002 at 03:54:35PM -0700, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Padraig O Mathuna <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > I'm developing some drivers for the AU1000 under
> > Mountain Vista's 2.4.17 sherman release. The AU1000 is
> > a MIPS based SOC with a 36 bit internal address bus
> > and a 32 bit MIPS cpu. According to the documentation
> > the MIPS' TLB is able to map 32 bit virtual addresses
> > to 36 bit physical addresses, however I cannot figure
> > out how to get Linux to set this up. I've looked at
> > ioremap which only takes unsigned long (32bits) as an
> > argument to assign a virtual address. Is there
> > another way?
> >
>
> Oh no, the x86 madness is spreading!!!!
>
> (It's depressing this happening on a MIPS system, which has been 64
> bits since who-knows-when...)
>
> *Vomit*
>
> -hpa
Can't say exactly when but my MIPS RISC Architecture manual
for the R2000/R3000 shows it to be a _strictly_ 32 bit
architecture in 1988 and i distinctly remember the working
with the newest R400x in 1993 which was still 32bit. I
know MIPS went to 64bit sometime not too long after that
(mid 90's?) but by then Alpha and Sparc had beaten them to
the punch.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
From: jw schultz <[email protected]>
Date: Wed, 16 Oct 2002 00:23:45 -0700
i distinctly remember the working
with the newest R400x in 1993 which was still 32bit.
You remember wrong, R400x can run happily in either 32-bit or 64-bit
mode.
jw schultz <[email protected]> writes:
> i distinctly remember the working with the newest R400x in 1993 which
> was still 32bit. I know MIPS went to 64bit sometime not too long
> after that (mid 90's?) but by then Alpha and Sparc had beaten them to
> the punch.
You're wrong -- the R4000 was absolutely 64-bit, and was released in
1991. The 64-bit sparc was circa '93, and alpha I dunno, but I think
'91-'92.
[note that I'm talking about chips, not software; I believe it was quite
a while before the OS stuff caught up with the 64-bit mips processors]
-Miles
--
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.
On Wed, Oct 16, 2002 at 05:20:15PM +0900, Miles Bader wrote:
> jw schultz <[email protected]> writes:
> > i distinctly remember the working with the newest R400x in 1993 which
> > was still 32bit. I know MIPS went to 64bit sometime not too long
> > after that (mid 90's?) but by then Alpha and Sparc had beaten them to
> > the punch.
>
> You're wrong -- the R4000 was absolutely 64-bit, and was released in
> 1991. The 64-bit sparc was circa '93, and alpha I dunno, but I think
> '91-'92.
>
> [note that I'm talking about chips, not software; I believe it was quite
> a while before the OS stuff caught up with the 64-bit mips processors]
OK. I guess i'm wrong. It may be that the hardware was
locked into 32bit mode. The development period was a couple
of years so we were running on essentially 89-90 tech with a
faster clock.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
On 15 Oct 2002, H. Peter Anvin wrote:
> Oh no, the x86 madness is spreading!!!!
>
> (It's depressing this happening on a MIPS system, which has been 64
> bits since who-knows-when...)
Yep, but the reasons are different -- the embedded people are paranoid on
cutting away any possible bit of silicon and, admittedly, they are right,
to some extent. Why do they need 36-bit physical addressing in 32-bit
cores remains a mystery to me, though, yet the MIPS32 ISA spec permits up
to 36 bits (implementation-specific) here. Even more interesting is why
an implementation chose mapping of I/O devices there -- it's usually
easier for an OS to have them mapped within the low 29-bit address space
where they can be accessed bypassing the TLB.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Wed, 16 Oct 2002, David S. Miller wrote:
> i distinctly remember the working
> with the newest R400x in 1993 which was still 32bit.
>
> You remember wrong, R400x can run happily in either 32-bit or 64-bit
> mode.
Many system implementations sticked to a 32-bit operation of R4k
processors, though, possibly because of a few intriguing processor errata
in early silicon revisions that hurt badly certain 64-bit operations.
This might have created an illusion these processors were 32-bit.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Wed, 16 Oct 2002, jw schultz wrote:
> OK. I guess i'm wrong. It may be that the hardware was
> locked into 32bit mode. The development period was a couple
> of years so we were running on essentially 89-90 tech with a
> faster clock.
I'm not sure if you can lock a MIPS system into the 32-bit mode at all,
certainly not the processor -- it always runs with 64-bit operations
enabled when in the kernel mode (for the user and supervisor modes it's
selectable), though you may disable 64-bit addressing. A system may be
incapable of 64-bit operation if its system controller doesn't support
doubleword transfers on the host bus, but I'm not sure if it's possible to
force an R4k CPU to only use 32-bit transfers for cache fills and
writebacks. Probably not. So that's really the matter of software only.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Wed, Oct 16, 2002 at 05:20:15PM +0900, Miles Bader wrote:
> jw schultz <[email protected]> writes:
> > i distinctly remember the working with the newest R400x in 1993 which
> > was still 32bit. I know MIPS went to 64bit sometime not too long
> > after that (mid 90's?) but by then Alpha and Sparc had beaten them to
> > the punch.
>
> You're wrong -- the R4000 was absolutely 64-bit, and was released in
> 1991. The 64-bit sparc was circa '93, and alpha I dunno, but I think
> '91-'92.
The 64bit mode of the original r4k was so buggy that you couldn't use
it in practice..
On Wed, 16 Oct 2002, Christoph Hellwig wrote:
> > You're wrong -- the R4000 was absolutely 64-bit, and was released in
> > 1991. The 64-bit sparc was circa '93, and alpha I dunno, but I think
> > '91-'92.
>
> The 64bit mode of the original r4k was so buggy that you couldn't use
> it in practice..
Any specific references? Recently I've been able to get seemingly quite
stable builds of MIPS64/Linux running on an R4000SC rev. 3.0 (I believe
the initial commercial release was 2.2 and that only differs by two
additional errata documented that are not related to 64-bit operation
anyway) and an R4400SC rev. 1.0 (the initial one). It wasn't entirely
straightforward to get proper workarounds implemented and the errata used
to bite badly without them, but now the kernel seems to run quite well --
I used to get uptimes of a week with only an administrative shutdown
breaking them.
But that's the kernel only -- we still lack a 64-bit userland which may
reveal additional gotchas. Do you know of anything I should be aware of
beside the errata as officially documented by MIPS? What is documented is
somewhat painful but not a showstopper -- I hope nothing else exists.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +