> I've looked at the HAL2 driver,
> and everything is looking strange hardware- wise.
I was actually thinking exactly the same thought.
> The driver first resets the hardware by clearing the isr register and setting
> the appropriate bits afterwards.
I was looking at the sgiseeq.c, and I've actually stolen some ideas from it. For
example are we doing the reset (trying to do?) in about the same way.
> But reading back isr indicates, that the hardware is still in reset state.
> I've removed clearing of the isr, so the driver just writes the same value as
> was before. This still leads to a HAL2 in reset state. Even removing the reset
> code completly the HAL2 acts very strange. Doing the first indirect register
> access, causes as set busy bit in isr, that's all. Any ideas
Hm, I haven't been able to set the busy bit, how did you manage to do that?
It looks to me like some volatile bug, causing the driver not to read back the
values directly from the card. But everything seems to be ok.
By the way, did you notice that isr is 0x0018 before you reset the card? This is
one of the strange things. Maybe it's because Alex didn't reboot his computer
after reinserting the driver again. If this is the case, why doesn't the card
enter active mode again before the driver has failed to activate it?