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.kalkow...@genode-labs.com>: > > Hi Michael, > >> On Tue, Jan 23, 2024 at 04:04:42PM +0100, Michael Grunditz wrote: >> In message <d35b0e7e-28ca-b4d5-d5e4-fb4bf3136...@genode-labs.com> >> Norman Feske <norman.fe...@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 _______________________________________________ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users