PCI Memory mapping
marc.leeman at barco.com
Thu Apr 1 01:56:25 EST 2004
> How is the PICMRx configured? Do you have snoop enabled or disabled?
This is what I like about my job: problem based digging deeper into code
Anyway, the time of day difference between us enables me to try to come
up with some kind of founded answer. We are using ppcboot (yeah, I know,
but unfortunately, there are too many things in the todo queue to
upgraced to uboot).
After some digging into kernel code, ppcboot code and the mpc8245
documentation, I assume you are trying to point me to the following:
In Section 7.5:
"Because a snoop transaction is required to establish a lock, the
MPC8245 does not honour the assertion of a LOCK when PICR1[NO_SNOOP_EN]
is set."; when describing exclusive access to data.
/* bus master, respond to PCI accesses */
(val & (PICR1_RCS0)) |
PICR1_FLASH_WR_EN | PICR1_MCP_EN |
PICR1_CF_DPARK | PICR1_NO_BUSW_CK |
PICR1_DEC| PICR1_CF_APARK | 0x10);
/* 8245 UM says bit 4 must be set */
#define PICR1_RCS0 0x00100000
#define PICR1_PROC_TYPE_603E 0x00040000
#define PICR1_FLASH_WR_EN 0x00001000
#define PICR1_MCP_EN 0x00000800
#define PICR1_CF_DPARK 0x00000200
#define PICR1_NO_BUSW_CK 0x00000080 /* no bus width check for
flash writes */
#define PICR1_DEC 0x00000100 /* Time Base enable on
#define PICR1_CF_APARK 0x00000008
And for PICR2:
val= val & ~ (PICR2_CF_SNOOP_WS_MASK | PICR2_CF_APHASE_WS_MASK);
/*mask off waitstate bits*/
#define PICR2_CF_APHASE_WS_MASK 0x0000000c
#define PICR2_CF_SNOOP_WS_MASK 0x000c0000
k. I got the (relevant) registers states at bootup now, I am still
looking for the NO_SNOOP_EN bit, it must be somewhere in the docs...
4.7: Speculative PCI reads see Chapter 13;
but NO_SNOOP_EN is defined for PICR2 on bit 27, could it be that the
the description in section (note) 7.5 is referring to PICR2 instead of
the mentioned PICR1?
which should be 0x8000000
I'll masking PICR2 with this tomorrow...
> will sound obvious, but have you stuck a PCI bus analyzer into the
> system to watch the actual PCI transactions? They more than make up
> for their cost in time savings. :)
Not yet, mainly because we want to interactively PPC/DSP rule out other
possibilities (an infamous DSP reset which is extremely difficult to
pinpoint); combined with the usual growing to do list with continuous
interrupts for 'paramount' things to do...
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev