Tobias Netzel wrote:
> I have been browsing the git repository when I recieved your
> message :-).
Good to see that you are still there :)
> Did you already test the 2.6 kernel on the PowerBook again in the
Yes, I did.
As mentioned before it powers off shortly after interrupts are enabled.
Though I didn't invstigate it any further.
> The general changes you made to the Performa interrupt routines one
> should apply to the PowerBook's as well, should one?
Yes, it is basically the same structure for handling interrupts as before.
At first I was trying to completely rewrite the interrupt handlers by
checking IRQ-specific bits in the get-irq handler and not dispatching
the appropriate handler directly (as it is meant in the kernel).
But for my first try at that time (I will put that solution on a
different branch soon) it lead to missing interrupts.
> Well and I think one might apply the facts I learnt during my
> research for the PowerBook interrupt controlling to the Performa's. I
> suspect that in icr2 (or somewhere around icr1 or icr2) you'll find
> the 68k autovector interrupt level (as a number, not as bit flags)
> that will indicate which "1st level" device caused the interrupt
> (i.e. SCC, VIA1, VIA2 or NMI, see nbpmac_m2.c). So one could get rid
> of reading the serial interrupt "manually". And if you wait before
> checking the interrupt controllers' flags until there really *is* an
> autovector interrupt level you wouldn't have to check all the VIA1,
> VIA2, SLOT1, SLOT2 and so on every time but should be able to rely on
> the flags in the chain of interrupt controllers. So does m68k linux
> and so does nbpmac_m2.c - and the Mac OS 68k emulator needs to rely
> on the autovector interrupt level as well.
Exactly this is what I was looking for and the original design of the
Performa ISR code was aiming at.
At least I wanted to make sure that for each level of the cascade there
is a separate kernel "controller" -- like it is done for the gatwick IRQ
handler in the powermac platform.
For now the Performa interrupt handling might not be optimal but it is
working stable. The IDE controller and ADB is working fine so far.
Therefore I concentrated on the macsonic driver, since a working
Ethernet connection would make further development a lot easier.
Unfortunately this seems to be the least supported Performa-compatible
network driver. There has been progress since 2.4 to support the non-dma
mode, which seems to be required for the Performa as well.
I can make the driver work to initialize the card, show its MAC address,
etc. But receiving a packet fails since the driver seems to having
problems completing the transfer from the network card to the kernel.
The rx queue in the driver becomes full.
Taking into account my current schedule I assume that I won't have time
before mid of June to continue on the project. May be it makes sense to
stick to another network card on the Performa. Not sure, which is the
one which will work out of the box...