Thanks Stefan. I have actually tried routing it from gicv3 code. I have decide to rebase my interrupt Hal. Not home today but I think that it will fix my problem. Interrupts is to most hairy part of what I am doing now I need to do some init bits from the other core but at the same time not breaking it for Genode.
What’s the fun if everything works right away!
Michael
24 jan. 2024 kl. 11:53 skrev Stefan Kalkowski stefan.kalkowski@genode-labs.com:
Hi Michael,
On Tue, Jan 23, 2024 at 04:04:42PM +0100, Michael Grunditz wrote: In message d35b0e7e-28ca-b4d5-d5e4-fb4bf3136979@genode-labs.com Norman Feske norman.feske@genode-labs.com wrote: Another issue: I don't know if anyone knows about this but ( long shot :-) ), I am relying on the imx8 message unit (MU). I have been using polling against it, but now I need interrupts. But I can't get it to work. I am trying to enable it on CPUB side. no effect. So I tried it in Genode CPUA (Core 0) and after setting up interrupt in the MU chip I got interrupts from the cpu. So the qeustion is: Is it only possible to set it on Core 0 and if so , can I route it to Core 1 in Genode. I have been looking in the gicv3 code and it seems like it only does core 0. I have also tried to enable it in genode and after that setting affinity on the second core ( from the second core). No effect. Interresting enough is that I can enable SoC timer and get it to interrupt core 1 ( not setting anything in Genode / Core 0).
The reason why we use a fixed route to CPU 0 for all interrupts here, is the fact that till now only one thread (on CPU 0) in core serves the interrupt service in base-hw. Moreover, the platform driver intercepted in the recent past the interrupt service to support interrupt sharing (also having just one thread, typically running on CPU 0), although it doesn't do this necessarily anymore for devices having distinct interrupts. Finally, the current interrupt service does not provide a way to tell core/kernel which CPU affinity to use for a specific interrupt.
So that is the software architectural limitation right now. Technically it should be no problem at all to route your interrupt to CPU 1. One way to achieve this within an Genode-only system without changing the IRQ service would be, to use the affinity of the caller to set the CPU target. But if I remember correctly you want to route the interrupt to a different core, which is managed by RISC OS. So in that case you could either use a hack (just hardcode it for the designated interrupts), or in the longer run the IRQ session gets equipped with a way to express the affinity explicitely. The latter solution however is nothing I would pledge to do overhasty. However, we have to re-think the quite simple form of the IRQ session in the midterm future anyway, because of other limitations, and we shall keep your use-case in the back of our heads therefore.
For an instant hack, you might have a look at file: repos/base-hw/src/bootstrap/spec/arm/gicv3.cc where the affinity routing of all interupts is initialized now. The interesting register is `Distributor::Irouter` (line 53 in my version).
Best regards Stefan
Michael
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-- Stefan Kalkowski Genode labs
https://github.com/skalk | https://genode.org
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users