Getting screen coordinate of a window

Michael Grunditz michael.grunditz at gmail.com
Wed Jan 24 22:54:31 CET 2024


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 at 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 at genode-labs.com>
>>          Norman Feske <norman.feske at 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 at 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 at lists.genode.org
> https://lists.genode.org/listinfo/users



More information about the users mailing list