You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a naive software implementation of GIC / SGI handling, see eos_handle_intengine_gic().
Known bugs:
doesn't handle nested interrupts
sometimes cpu0 will intend to signal cpu1 but win the race and handle its own interrupt (and vice versa)
Currently we create an interrupt with cpu_interrupt(cpu_id, CPU_INTERRUPT_HARD), this presumably is visible to both cores (although you do have to specify a cpu id...) and maybe real SGI aren't? I assume the actual interrupt is some inter-core signal.
Possibly related, we don't store the cpu_id in the interrupt value we send via "iar". This is wrong according to ARM manual on GICC_IAR and GICC_EOIR. Unsure if this is used to route the interrupt or not, maybe it is on real hardware - we're not emulating this.
The text was updated successfully, but these errors were encountered:
Ugly multi-purpose commit, hard to dis-entangle since
I'm working from a patch file.
Adds minimal support for R5.
New work to improve SGI handling: cpu1 is now successfully
woken from wfi_sinkhole by cpu0! There are some known
problems:
#15
We have a naive software implementation of GIC / SGI handling, see eos_handle_intengine_gic().
Known bugs:
Currently we create an interrupt with cpu_interrupt(cpu_id, CPU_INTERRUPT_HARD), this presumably is visible to both cores (although you do have to specify a cpu id...) and maybe real SGI aren't? I assume the actual interrupt is some inter-core signal.
Possibly related, we don't store the cpu_id in the interrupt value we send via "iar". This is wrong according to ARM manual on GICC_IAR and GICC_EOIR. Unsure if this is used to route the interrupt or not, maybe it is on real hardware - we're not emulating this.
The text was updated successfully, but these errors were encountered: