**** BEGIN LOGGING AT Mon Jul 01 02:59:57 2019 Jul 01 10:24:40 abhishek_: Can you please explain how the RPMsg code should work on the firmware side? i.e. after we write data in the character device files rpmsg_pru30/31. The assembly code looks up for 4 bytes for no. of iterations in the SRAM. Each iteration takes 2 steps (10ns) and hence the max frequency of pwm is 1MHz when duty cycle is passed as an X:100 ratio. The no of iterations are to be written into the SRAM based on Jul 01 10:24:42 frequency and duty cycle. Jul 01 10:27:54 The assembly code is here https://github.com/pratimugale/PRUSS-Bindings/blob/wip/examples/firmware_examples/example3-pwm/pwm-assembly/pru-asm-pwm.asm Jul 01 10:37:36 ds2: apritzel sstabellini julieng so, I was looking for my error and I can see that it is happening around here: kernel/irq/irqdomain.c:766:irq_create_fwspec_mapping Jul 01 10:41:49 I believe that the reason might be that Linux doesn't receive the right DT Jul 01 10:44:49 Here is the mistake: https://pastebin.com/U0gch9us (line 193) and here is the interesting part of a device tree parsing by xen: https://drive.google.com/open?id=15YTsCKYUTbG2i-siWezJXKWuG0H1VfQz (line 9856) Jul 01 11:00:35 Also I have explained it a bit more: https://pratimugale.github.io/gsoc/2019/07/01/Post6.html Jul 01 15:46:38 embden[m]: I would try to somehow dump the device tree that Xen generates, then check the node(s) that cause troubles Jul 01 15:47:17 sstabellini: ^ how can I do this? Jul 01 19:49:37 embden[m]: hi Jul 01 19:49:42 embden[m]: are you online now? Jul 01 19:52:22 yes Jul 01 19:52:22 embden[m]: I read the logs, this is where things get interesting! Jul 01 19:52:36 embden[m]: you found the first sympton of the real issue we knew we were going to have Jul 01 19:52:50 embden[m]: the irq in question is not connected to the GIC interrupt controller but to another interrupt controller Jul 01 19:53:00 embden[m]: it seems to be called "crossbar" Jul 01 19:53:29 embden[m]: if you recall from when we were doing "scoping" on this project, the major challenge was to support a different interrupt cotroller Jul 01 19:53:32 and here we are :-) Jul 01 19:53:37 Xen only understands the GIC Jul 01 19:53:49 Xen cannot deal with interrupt controllers other than the GIC Jul 01 19:54:21 to make this work, you need to make crossbar work with Xen Jul 01 19:54:41 even just for dom0, it would be a start Jul 01 19:55:11 one thing you could try would be to remap the whole crossbar interrupt controller to dom0 Jul 01 19:55:18 including registers, MMIO and everything Jul 01 19:55:40 but I am not sure if crossbar is connected to the GIC somehow, or if it is connected directly to the CPU Jul 01 19:55:51 does somebody know? Jul 01 19:56:31 sstabellini: ok, so, I need to check the architecture of the soc Jul 01 19:56:50 embden[m]: Yes: I don't know for sure how to virtualize crossbar Jul 01 19:57:07 embden[m]: if it is connected via the GIC, there needs to be some support in Xen to do it Jul 01 19:57:22 it could be that we need a crossbar driver in Xen Jul 01 19:57:39 and then Xen emulates crossbar to dom0, and sets up interrupt mappings accordingly Jul 01 19:57:59 this is how probably it will have to work Jul 01 19:58:11 so we need a little crossbar driver in Xen and a little crossbar emulator in Xen for dom Jul 01 19:58:13 dom0 Jul 01 19:58:24 but we might be able to take some shortcuts of the architecture is simple Jul 01 19:58:43 such as: not emulate everything just the bare minimum necessary to make it work Jul 01 19:59:57 ok **** ENDING LOGGING AT Tue Jul 02 02:59:56 2019