PCI Memory mapping

Marc Leeman marc.leeman at barco.com
Thu Apr 1 22:33:40 EST 2004


> I'll masking PICR2 with this tomorrow...

I have obtained some results by setting some 8245 registers at bootup.

I tested the following:

. enabling NO_SNOOP_EN (27 in PICR2): nfs does not boot anymore
. increasing the snoop and address wait cycles to 5 (default ppc bootup),
no real change.
. disable speculative reads  (2 in PICR1): doesn't boot nfs anymore
(via eepro100?)

No real success, until I came accross the PCMBCR register which defines
the number of PCI to Local Memory Read and Write Buffers. When I set
both to 1 ( & 0xF0), the data copy back is no longer needed to assure
data consistency between the PPC and DSP (default is 4 32 byte buffers).

include/mpc824x.h:
#define PCMBCR          0x800000e1  /* PCI/Memory Buffer Configuration
Register */

cpu/mpc824x/cpu_init.c:
CONFIG_READ_BYTE(PCMBCR,val);
CONFIG_WRITE_BYTE(PCMBCR,(val | 0xF0));

Double checking this by setting both on 4 again (during cpu_init of
ppcboot) resulted in severe MPEG data corruption. These results at least
seems to point in the direction you suggested.

This is the only way I seem to be able to assure data consistency (the
kernel copy back is no longer required), but the documentation also
suggests that (obviously) this degrades performance and is mainly used
for debugging.0

Still, when reading the explanations that could case this behaviour
(copy back buffer and filling the PCMRBs) , they point to cache
operations, which, I thought, were disabled in the linux kernel for
these particular PCI mapped buffers.

By adding __asm__ __volatile__("eieio"); in user and kernel space,
which lets the CCU buffers to be flushed, no change is observed (sect.
5.4.3.1; CCU Responses to the Processor Transactions).

It looks to me as if I should disable the bus snooping, but as mentioned
before, initialising this in ppc boot inhibits the NFS boot process.

Can this be disabled at runtime (possibly with re-enabling it) and if
so, is this a good practice to do so?

  marc.

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





More information about the Linuxppc-dev mailing list