Hi all,
On 03.05.2020 18:28, Nico Huber wrote:
Hi Zheng,
On 03.05.20 17:27, Zheng Bao wrote:
I am debugging the AMD Picasso board. When Linux kernel boots, there is some
error message in dmesg.
do_IRQ: 1.55 No irq handler for vector
We've noticed the same on PC Engines apu2, an older AMD board.
So, for me there are two mysteries:
1. Why is IRQ 7 triggerred?
IRQ 7 is a legacy spurious interrupt vector. It may be caused by the
timer tick interrupt,
see section 2.4.8.1.10 of [1] or appropriate document for other platforms.
However, from what we have observed, this happens more often than 50% of
time,
so there may be another interrupt involved, one that is deasserted e.g.
by INIT signal.
2. Why does the AP process interrupts before `sti`? (if my assessment
above is correct).
Did you run any payload between coreboot and the kernel?
APs are enabled by AGESA, the interrupt might be latched since then and
not because of
whatever payload was doing.
[1]
https://www.amd.com/system/files/TechDocs/52740_16h_Models_30h-3Fh_BKDG.pdf
--
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
