PCI caching question related to mvme5500

[gregory.menke at gsfc.nasa.gov]

Peter Dufault writes:
 > 
 > On Nov 1, 2005, at 7:38 AM, Kate Feng wrote:
 > 
 > >>
 > >> Much later when porting to vxWorks and again having it slow I
 > >> realized that the board does not properly say that its memory is pre-
 > >> fetchable.
 > >>
 > >
 > > Who was slow ? RTEMS or vxWorks ?
 > >
 > >
 > 
 > Both were.  I didn't have the PCI background to realize something was  
 > fishy when bringing up RTEMS - when the board doesn't claim to be pre- 
 > fetchable there isn't a reason to cache it.  Only when vxWorks was  
 > also slow did I get suspicious and looked into it further.
 > 
 > I'm hoping someone who knows the RTEMS PCI will tell me where to  
 > properly hack in obtaining a cached address for a board broken in  
 > such a manner.  I have to get a new system up and running, this time  
 > with Solaris-10 on an Opteron, and I want to be sure to get any  
 > changes into the RTEMS bug data base.  I won't have much time to  
 > spend until things are up and running, so I'm turning to the list to  
 > see if I can improve what I did before and get something into the  
 > database.

In the motorola_shared BSP, its the bootloader that sets up the PCI
address spaces.  PCI interrupt vectors are set up by the RTEMS kernel as
it initializes.

You should be able to force the PCI address allocation routine to detect
your hardware and force it to be allocated in cacheable space.  

You might start with recursive_bus_reconfigure() in
libbsp/powerpc/shared/bootloader/pci.c

It would kind of suck if you put a hardwired exception for your gizmo
into the source tree as a patch.  If it is desirable to feed back
hardware-specific hacks like this, then I think it would be preferable
to implement some kind of hack table in pci.c so that sort of thing
could be generalized without making a mess.

Regards,

Gregm