mvme2600 netdemo: "

[Till Straumann]

I believe it should work.

You only need a interrupt routing table to correct
mistakes of the firmware. Ideally, the firmware should
initialize/configure all PCI devices. Usually, firmwares
have problems with PCI-PCI bridges and configuring
devices behind them  (read PCI-extenders, PMC
cards with bridges, ...). That's when the routing table
helps (or in the unlikely case that the firmware screws
up configuring on-board devices).

When you look at how PPCBug configures PCI devices
(i.e., inspecting the INTERRUPT_LINE register)
it might appear strange as the 'interrupt line' values look
completely messed-up. That's because most interrupts
on the 23xx (and I believe this applies to the 26xx, too)
are actually physically connected not only to the OpenPIC
as 'PCI' interrupts but also to the ISA interrupt controller
and PPCBug uses ISA interrupts by default! E.g., the
network chip is hooked to ISA IRQ 10 and also to
MPIC interrupt #2 (which would under RTEMS be
'PCI IRQ' 2 = 16+2 = 18). After boot, the INTERRUPT_LINE
register reads 10 which is the ISA interrupt but that's fine...

--> On-board devices should 'just work'.
--> However: the way the vmeUniverse driver is initialized
     is *broken* (I'm working on a fix). Currently, it can
     only be expected to work on the 23xx/26xx but definitively
     not on the 2100.

Hence, networking should work and VME interrupts may
or may not work (but are not hard to fix).

HTH
-- Till

rtwas wrote:

> Hello,
>
>
> Joel Sherrill <joel at OARcorp.com> wrote:
>
>> rtwas wrote:
>>
>>> Hello,
>>>
>>> I'm still trying to get "netdemo" to work.
>>>
> .
> .
> .
>
>>
>> It you don't have the interrupt map, the most it can do is recognize
>> the PCI device ID.  It won't work but it is a good sign.
>
>
> What else do I need to get the interrupts working?
>
> I assume you mean that everything about networking should work find 
> except it can't answer
> interrupts. Is this correct?
>
> In a earlier post:
>
> Joel Sherrill:
> >What CPU is in the mvme260x?  Till.. is it worth making the
> >mvme260x another recognized BSP variant?
>
> Till Straumann:
> >I hope not. Minimal differences should be detected at run-time
> >and not require rebuilding.
>
> It sounds like Till is saying the bsp for the 2307 should handle the 
> 260x variant but
> if interrupts are'nt working, I don't see how networking could have 
> ever worked. If networking
> does'nt/has'nt worked, then it seems to me the 260x is not properly 
> addressed by the 2307 bsp.
>
> Robert W.
>