MCP750 PCI

[gregory.menke at gsfc.nasa.gov]

Till Straumann writes:
 > Hi Gregory.
 > 
 > 
 > Although I don't know if your 'strange results' (what exactly are you 
 > observing??) could be caused by this, I wanted to bring to your 
 > attention that the ld_xx/st_xxx macros don't enforce in-order execution 
 > on PPC. PCI-space is mapped as 'guarded' hence stores are always 
 > in-order, i.e.
 > 
 > st_le32(address1, val1);
 > st_le32(address2, val2);
 > 
 > is guaranteed to store val1 to addr1 prior to storing val2 to addr2.


On Linux, I can dump the card's PCI and 1553 tranceiver registers and
get a reasonable "idle state".  I know the card is working because
theres a 16 bit timer register that I can see ticking by printing it
several times.

When I print the same registers under RTEMS, I don't get the idle
state values- nothing even close.  The PCI chipset registers come back
as 0xffffffff, as if the addresses was out of range whereas under
Linux, they come back as 0x0.  The tranceiver registers come back as
all 0 except for the weird ones, some of which yield the same
"uninitialized" value that they give under Linux.  The timer tick
register is not incrementing either.

My test code only does ld_le16 for the tranceiver and ld_le32 for the
pci chipset. 

Maybe I can ask more intelligent questions;

Are there any magic enable operations that are done with the mcp750
onboard peripherals (in this case the dec21140) that I'm missing?

Linux implements ioremap to get address ranges mapped thu the vm
subsystem, are there BAT or mapping configuration changes needed to
talk to other pci hardware under RTEMS?

Could there be extra incantations needed to get transactions out onto
the backplane?  I've looked thru the bsp fairly closely but haven't
found anything.

Thanks,

Greg