Hi Geert,
On 21/05/24 19:07, Geert Uytterhoeven wrote:
The interrupt vector number will tell us what interrupt level is causing
the storm (if it's an autovector int).
If it's _not_ an autovector int?
If it isn't an autovector interrupt, the vector address were generated
by the interrupting hardware, and its offset from the vector base
register won't tell us anything about the IPL.
Anyway, unlike Atari, Amiga only uses autovector interrupts, and most
expansion boards use IRQ_AMIGA_PORTS (IRQ_AUTO_2) (some can be jumpered
for IRQ_AMIGA_EXTER (IRQ_AUTO_6). As lots of other components use
IRQ_AUTO_2, these are all shared interrupts. Hence handle_badint()
is never called, the "bad" interrupt is never disabled by the irq core
code, and you end up with an eternal interrupt storm.
Makes perfect sense now. And Paolo's report on successful boot with
IRQ_AUTO_2 never getting enabled confirms this.
Shame the generic IRQ handlers do not return information about whether
an interrupt could be handled ...
Cheers,
Michael
that didn't change a bit. I understand it requires a new fw from the board
manufacturer or a quirk in the bootloader, but i would like to get something more
verbose before i ping them.
Interrupt level and vector number would help the manufacturer to give us
the information required to disable the problematic interrupt source.
IRQ_AMIGA_PORTS :-)
I guess the system would boot if you hack arch/m68k/amiga/amiints.c
to never enable IRQ_AMIGA_PORTS in amiga_custom.intena, but then you
would also lose the ability to use e.g. the builtin A1200 IDE.
BTW, code to reset/silence the hardware components on Warp 1260
could not only be added to Amiboot, but also to e.g.
arch/m68k/amiga/config.c:amiga_parse_bootinfo().
Reverse-engineering the AmigaOS interrupt handlers for the board may
also help.
Gr{oetje,eeting}s,
Geert
