quoted
It appears to me that the inline functions in this file are missing the
CONFIG_8260 conditional compile. Can anyone confirm if this it true?
I can confirm it is not true. What would need to change for 8260? It
has worked for a long time.
Nothing needs to change to the 8260, it should be implemented like the 8xx
and 4xx processors, which it isn't without the conditional compiles. (It
appears to work either way) I do not see corresponding conditional compiles
in pgtable.c or the other mm/*.c which would indicate that the 8260 memory
management is implemented differently.
8260 memory translations were broken in HHL 2.0 (Linux 2.4.2) Just making
sure it isn't still broken in 2.4.17
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
acurtis@directvinternet.com wrote:
> .... it should be implemented like the 8xx
and 4xx processors, which it isn't without the conditional compiles.
No, it shouldn't. The 4xx/8xx are unique because of the way they
have to map memory in support of cache coherent (i.e. uncached)
windows. The 82xx processor family is a standard cache coherent 6xx
core and doesn't require any special software support.
8260 memory translations were broken in HHL 2.0 (Linux 2.4.2) Just making
sure it isn't still broken in 2.4.17
How were they broken?
Thanks.
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
No, it shouldn't. The 4xx/8xx are unique because of the way they
have to map memory in support of cache coherent (i.e. uncached)
windows. The 82xx processor family is a standard cache coherent 6xx
core and doesn't require any special software support.
Thanks, it makes sense that it would be more Mac like because of the 6xx
core.
quoted
8260 memory translations were broken in HHL 2.0 (Linux 2.4.2)
Just making
quoted
sure it isn't still broken in 2.4.17
The big one that I remember is that iopa() was essentially a null function
because it was missing the CONFIG_8260 conditional.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/