mvme2604 confidence test.

[Till Straumann]

BTW:

One of my in-numerable patches I intend to merge for 4.7 is making use
of the 'opts' field in the _int_map structure so BSPs can instruct the 
'fixup'
routine to enforce the given mapping. Right now, if there's a conflict 
between
the _int_map and what's already in the device's pci config registers, the
fixup code just gives a warning but doesn't enforce the fixup.

New feature:
If PCI_FIXUP_OPT_OVERRIDE_NAME (1<<0) is raised in 'opts' the
conflict is resolved in favor of _int_map.

-- Till

gregory.menke at gsfc.nasa.gov wrote:

>"Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
> > gregory.menke at gsfc.nasa.gov wrote:
> > > rtwas writes:
> > >  > Hello,
> > >  > 
> > >  > Question: What does this mean "pci : Interrupt routing not available for
> > >  > this bsp"?
> > >  > 
> > > 
> > > The bsp is not aware of how PCI bus interrupt lines are mapped to the interrupt controller interrupt lines.
> > > 
> > 
> > And... do tell more :)
> > 
> > The message is printed in libbsp/powerpc/shared/startup/bspstart.c
> > based upon calling motorolaIntMap(myBoard). myBoard is set earlier to 
> > the return value from getMotorolaBoard().
> > 
> > The code in libbsp/powerpc/shared/motorola must be enhanced to
> > recognize the board and pick the right interrupt map.  The interrupt
> > map table might have to be added.
> > 
> > Richard and I did the mvme2100 version in here.  The board has to be
> > recognized and there needs to be a minimal interrupt map.
> > 
> > Nothing too terrible to pull out of the board manual.  :)
> > 
> > You are getting there... don't stop yet.
> > 
> > 
>
>
>Sorry sent too fast- stupid Mac keyboard I keep hitting 2 control C's...
>This message too.  Macs make great Linux boxes but turning the left
>apple button into a middle click & trying to compose email with vm in
>emacs can be troublesome if you hit the wrong keys by accident...
>
>anyhow,
>
>the "swizzle" table- named from Linux, contains the mappings of the 4
>PCI interrupt lines to the local board's interrupt controller.  The
>vector space inside RTEMS maps all the interrupt controller inputs, so
>the swizzle table is there to relate the PCI lines to the vector space.
>
>As the final step in prepping the PCI hardware, the motorola_shared pci
>routines computes the interrupt vector associated with each device using
>the swizzle table & stores the vector in the device's pci config space.
>If a driver or app software wants to use the device later, it just reads
>out the interrupt vector and uses it directly.
>
>PCI makes the swizzling necessary because the interrupt lines are
>assigned "mod 4" to the slots- slot 1 gets int a, slot 2 gets int b,
>slot 5 gets int a again, etc.. and pci bridges also rotate the interrupt
>assignments.  The idea is to spread the interrupts over the 4 lines
>rather than concentrate all the interrupts on one.
>
>Onboard peripherals (even PCI ones) will often be either hardwired or
>pre-configured with their interrupt info by the rom monitor.  But the
>rom monitor may not handle devices down past the pci bridges.  There is
>an argument in favor of that...
>
>Greg
>
>  
>