mpc755, sandpoint port and 1Gb of ram

[Mark A. Greer]

Michael J. Accetta wrote:

>Hello all,
>
>We have a custom board built around the mpc755 and patterned after the
>Sandpoint reference design using the MontaVista Pro 3.0 distribution.
>This is a base 2.4.18 kernel which, according to the MV web, page includes the
>2.4.17 linuxppc code.  When 1Gb ram is used, CONFIG_HIGHMEM is required
>to access the top 256Mb.  However, the sandpoint port does
>
>   io_block_mapping(0xfe000000, 0xfe000000, 0x02000000, _PAGE_IO);
>
>whichs maps all of virtual 0xfexxxxxx to physical 0xfexxxxxx.  This call
>ends up using BAT#0 to map the entire block.  However, the CONFIG_HIGHMEM
>support in the base ppc port sets PKMAP_BASE to 0xfe000000 and expects
>these virtual addresses to be available for dynamic mapping via kmap()
>of high memory.  The conflicting mapping in the BAT takes precedence,
>wreaking havoc with any accesses to high memory.  In our case NFS mounts
>of the root file system was the first high memory user and init could
>not be found.
>
>I've made a stab at fixing this by configuring PKMAP_BASE down to 0xfc000000
>and things now seem to work fine.  Is this a correct solution?  Are there
>likely to be any negative side effects of this approach?  Are there
>better solutions?
>
>
>
You have basically 2 choices:

a) change the mapping such that the io_block_mapping doesn't cover the
default PKMAP_BASE area
b) change PKMAP_BASE--which is what you did--however, if you didn't, you
should use the config facility that allows you to do this (look at 'Code
maturity level options'/'Prompt for advanced kernel configuration options').

Its probably just a personal preference but I think changing the mapping
and leaving PKMAP_BASE alone is a better way.  Someday I will do that
for the sandpoint port.

In short, what you did, assuming you did it properly, should work fine.

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/