Re: Address mapping PPC 405

2 messages, 2 authors, 2005-09-15 · open the first message on its own page

Re: Address mapping PPC 405

From: Matt Porter <mporter@kernel.crashing.org>
Date: 2005-08-30 15:39:01

On Mon, Aug 29, 2005 at 02:11:22AM +0100, Jon Masters wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Grant Likely wrote:

| On 8/28/05, Jon Masters [off-list ref] wrote:
|
|>On 8/26/05, P. Sadik [off-list ref] wrote:
|>
|>Lovely. We don't do it that way on 405 but we could - since the MMU is
|>heavy soft assisted we could do that - we actually have everything run
|>through the MMU once we've done initial MMU setup, but we do have the
|>ability to mark ranges of addresses for IO and have the concept of TLB
|>pinning to lock ranges of kernel addresses in large translated (BAT
|>like for bigger PPC users) regions using just a few TLB slots. There
|>is also a ZPR (zone protection register), but that's mostly used to
|>fake the usual USER/KERNEL page distinction.

| I believe TLB pinning was removed in 2.6 in favor of large TLB entries
| for kernel space.  Matt Porter pointed this out to me about a week
| ago.  This will not matter of course if you're not using 2.6.

Maybe so. I'm thinking this is likely on 2.4  but I'd be interested to
know what you mean - this isn't hugetlb (that's different), and TLB
pinning on 2.4 means you only use a couple of (large) entries anyway. I
can go read the source I suppose :-)
The following is 405 specific.

Well, on 2.4 we have CONFIG_PIN_TLB which covers the first 32MB of
kernel lowmem with two fixed 16MB TLB entries. In 2.6, all of kernel
lowmem is mapped by large pages of 16MB and 4MB sizes.

hugetlbfs, ioremap, and io_block_map could all be hooked into the 405
large page replacement support. I've been looking at doing this for
405 and 440 in my copious spare time. :)

-Matt

PPC4xx cleanup

From: Stefan Roese <sr@denx.de>
Date: 2005-09-15 16:19:15

Hi,

I am right now testing and cleaning up some of the AMCC 4xx eval board ports 
to better support U-Boot as firmware. One question before I begin to send a 
few patches:

All of the 44x boards I looked at (e.g. Ocotea) have to be extended in the 
platform file (e.g. platforms/4xx/ocotea.c) to not only copy the bd_info 
struct from r3, but also check r4 and r6 for initrd and kernel command line 
passing from the bootloader. Instead of adding this code to all different 
platform files, I would like to move this code to the common function 
"ibm44x_platform_init" (syslib/ibm44x_common.c) like it is done in the 40x 
ports "ppc4xx_init" (syslib/ppc4xx_setup.c). 

Any objections/remarks?

Best regards,
Stefan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help