What is the maximum physical RAM for a 32bit MIPS core?

I am just trying to fill in some more MIPS knowledge here. With a 32-bit MIPS processor, we are forever limited to a userspace of 2GB in size thanks to the kuser region. kseg0/1 map the same 512MB of physical memory. kseg2 is 1GB in size and hence it could address another 1GB of RAM. So, is the maximum amount of RAM for a 32bit MIPS core:

1) 1.5GB = 0.5GB kseg0/1 + 1.0GB kseg2

2) 4.0GB = largest 32-bit address

3) Something larger than 4.0GB by adding fancy external HW logic

Also, for choice #3, while it would be a hit in performance, could you use the fp registers for 64-bit pointers to address larger than 4.0GB?

Thanks in advance.

-Steve

Signature · 1 line

 Steven J. Hill - Embedded SW Engineer

You have to distinguish between physical and virtual memory. The MIPS32 architecture supports implementations with up to 36 bits of physical address space, however the virtual address space in kernel and user mode is as you describe below.

One note: Many MIPS32 implementations choose not to implement all 36 PA bits, but limit themselves to 32 bits. This saves a few bits in the TLB and a few address lines.

Quoted 6 lines · Hartvig Ekner

You have to distinguish between physical and virtual memory. The MIPS32 architecture supports implementations with up to 36 bits of physical address space, however the virtual address space in kernel and user mode is as you describe below.

I wasn't talking about the MIP32[tm] cores specifically, I was using a generalization of 32bit. However, this is good to know. All of the data sheets that I just downloaded from the MIPS site for the R4k[X] cores don't mention the 36-bit PA item. Care to elaborate?

Quoted 6 lines · Hartvig Ekner

You have to distinguish between physical and virtual memory. The MIPS32 architecture supports implementations with up to 36 bits of physical address space, however the virtual address space in kernel and user mode is as you describe below.

I wasn't talking about the MIP32[tm] cores specifically, I was using a generalization of 32bit. However, this is good to know. All of the data sheets that I just downloaded from the MIPS site for the R4k[X] cores don't mention the 36-bit PA item. Care to elaborate?

Quoted 4 lines

One note: Many MIPS32 implementations choose not to implement all 36 PA bits, but limit themselves to 32 bits. This saves a few bits in the TLB and a few address lines.

So, if someone did want 36 PA bits on Linux, the TLB exception handlers and a little of the page table construction/management code would have to change. The userspace contraints and such would still remain. Cool.

I'm not sure if it's a "little" though. Ralf has already done the work for 64bit memory support on 32bit kernels, but that only works currently on 64bit CPUs. I started hacking on the 64bit memory patch to get it to work on 32bit processors, but had to put that aside for a few weeks. I hope to get back to it soon.

Quoted 7 lines · Pete Popov

I'm not sure if it's a "little" though. Ralf has already done the work for 64bit memory support on 32bit kernels, but that only works currently on 64bit CPUs. I started hacking on the 64bit memory patch to get it to work on 32bit processors, but had to put that aside for a few weeks. I hope to get back to it soon.

Sure, the "little" is a relative term. As far as your patch is concerned, you are essentially trying to use a true 32-bit processor (my definition being that it is not a 64-bit processor running in 32-bit mode), to address address more than 4GB of physical memory. I don't see how that is possible with just the MMU and TLB unless you are using chip selects and customm logic.

Quoted 7 lines · Pete Popov

I'm not sure if it's a "little" though. Ralf has already done the work for 64bit memory support on 32bit kernels, but that only works currently on 64bit CPUs. I started hacking on the 64bit memory patch to get it to work on 32bit processors, but had to put that aside for a few weeks. I hope to get back to it soon.

Sure, the "little" is a relative term. As far as your patch is concerned, you are essentially trying to use a true 32-bit processor (my definition being that it is not a 64-bit processor running in 32-bit mode), to

address more than 4GB of physical memory. I don't see how that is possible with just the MMU and TLB unless you are using chip selects and customm logic.

As already mentioned, a MIPS TLB entry typically can point with 36 bits (that's 67TB of address space?) at physical memory. If you have more than

Quoted 2 lines · Bradley D. LaRonde

As already mentioned, a MIPS TLB entry typically can point with 36 bits (that's 67TB of address space?) at physical memory. If you have more than

At bit less: 64 GiB or approx. 69 GB :-)

Gr{oetje,eeting}s,

Geert

Signature · 5 lines

Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

The fact that idiot marketoids in some moronic HD maker decided "GB" ment "billion bytes" is not a good excuse for useing the term to refer to anything that has never been polluted this way. It's not an excuse to use it to refer to things that have been polluted this way either, but that won't stop ppl. How bout you say GB is gigabits and claim ~549 of your mythical "GB"?

Quoted 5 lines · Bradley D. LaRonde

Quoted 2 lines

As already mentioned, a MIPS TLB entry typically can point with 36 bits (that's 67TB of address space?) at physical memory. If you have more than

At bit less: 64 GiB or approx. 69 GB :-)

Quoted 2 lines

As already mentioned, a MIPS TLB entry typically can point with 36 bits (that's 67TB of address space?) at physical memory. If you have more

At bit less: 64 GiB or approx. 69 GB :-)

Quoted 4 lines

One note: Many MIPS32 implementations choose not to implement all 36 PA bits, but limit themselves to 32 bits. This saves a few bits in the TLB and a few address lines.

So, if someone did want 36 PA bits on Linux, the TLB exception handlers and a little of the page table construction/management code would have to change. The userspace contraints and such would still remain. Cool.

I am just trying to fill in some more MIPS knowledge here. With a 32-bit MIPS processor, we are forever limited to a userspace of 2GB in size thanks to the kuser region. kseg0/1 map the same 512MB of physical memory. kseg2 is 1GB in size and hence it could address another 1GB of RAM. So, is the

Quoted 4 lines

I am just trying to fill in some more MIPS knowledge here. With a 32-bit MIPS processor, we are forever limited to a userspace of 2GB in size thanks to the kuser region. kseg0/1 map the same 512MB of physical memory. kseg2 is 1GB in size and hence it could address another 1GB of RAM. So, is the

2gb virtual memory per process. In theory physical memory is limited by the size of the address bus with highmem; the practical limit for highmem should be in the range of 16-32gb RAM.