iMX8MM seL4 12.1.0 running a VM
Hi, I have encountered a problem where the device tree is not correctly being parsed resulting in interrupts not being routed to the VM. A node which exhibits this issue is (there are several more in the iMX8MM device tree that also trigger the problem) ``` snvs@30370000 { compatible = "fsl,sec-v4.0-mon\0syscon\0simple-mfd"; reg = <0x30370000 0x10000>; phandle = <0x1b>; snvs-rtc-lp { compatible = "fsl,sec-v4.0-mon-rtc-lp"; regmap = <0x1b>; offset = <0x34>; interrupts = <0x00 0x13 0x04 0x00 0x14 0x04>; clocks = <0x02 0xe4>; clock-names = "snvs-rtc"; }; }; ``` Interrupts 0x13 and 0x14 should be included in the camkes_dtb_irqs[] variable but they are not. Looking at the node as it is parsed in macros.py via the function parse_dtb_node_interrupts {'compatible': ['fsl,sec-v4.0-mon', 'syscon', 'simple-mfd'], 'reg': [808910848, 65536], 'phandle': [27], 'snvs_rtc_lp': [<pyfdt.pyfdt.FdtPropertyStrings object at 0x7483b4c28f10>, <pyfdt.pyfdt.FdtPropertyWords object at 0x7483b4c28f70>, <pyfdt.pyfdt.FdtPropertyWords object at 0x7483b4c28fd0>, <pyfdt.pyfdt.FdtPropertyWords object at 0x7483b4c2f070>, <pyfdt.pyfdt.FdtPropertyWords object at 0x7483b4c2f0d0>, <pyfdt.pyfdt.FdtPropertyStrings object at 0x7483b4c2f130>], 'snvs_rtc_lp_compatible': ['fsl,sec-v4.0-mon-rtc-lp'], 'snvs_rtc_lp_regmap': [27], 'snvs_rtc_lp_offset': [52], 'snvs_rtc_lp_interrupts': [0, 19, 4, 0, 20, 4], 'snvs_rtc_lp_clocks': [2, 228], 'snvs_rtc_lp_clock_names': ['snvs-rtc'], 'snvs_powerkey': [<pyfdt.pyfdt.FdtPropertyStrings object at 0x7483b4c2f1f0>, <pyfdt.pyfdt.FdtPropertyWords object at 0x7483b4c2f250>, <pyfdt.pyfdt.FdtPropertyWords object at 0x7483b4c2f2b0>, <pyfdt.pyfdt.FdtPropertyWords object at 0x7483b4c2f310>, <pyfdt.pyfdt.FdtPropertyStrings object at 0x7483b4c2f370>, <pyfdt.pyfdt.FdtPropertyWords object at 0x7483b4c2f3d0>, <pyfdt.pyfdt.FdtProperty object at 0x7483b4c2f430>, <pyfdt.pyfdt.FdtPropertyStrings object at 0x7483b4c2f490>], 'snvs_powerkey_compatible': ['fsl,sec-v4.0-pwrkey'], 'snvs_powerkey_regmap': [27], 'snvs_powerkey_interrupts': [0, 4, 4], 'snvs_powerkey_clocks': [2, 228], 'snvs_powerkey_clock_names': ['snvs-pwrkey'], 'snvs_powerkey_linux_keycode': [116], 'snvs_powerkey_wakeup_source': [], 'snvs_powerkey_status': ['okay'], 'this_address_cells': [1], 'this_size_cells': [1], 'this_node_path': '/soc@0/bus@30000000/snvs@30370000'} The function is looking for 'interrupts' but the interrupt declaration in the child node has been renamed to 'snvs_rtc_lp_interrupts'. This explains why the interrupts are omitted from the template generated code. A hacky fix, that does appear to work, is to paste the interrupt declarations into the parent node. I'm sure there's a more elegant way to resolve this but my detailed knowledge in this area is lacking. I am going to have a look at seL4 13.0.0 to see if this has already been fixed with a view to a potential backport but thought I'd check here before starting to dig a new hole to fall into. Many thanks, Zippy
Does anybody have any ideas about this? I have been running my hacky fix without any issues but I'm wondering if there may be a better solution out there. Cheers, Zippy
Hello Zippy, On 2024-11-20 16:06, Zippy Manaic via Devel wrote:
Does anybody have any ideas about this? I have been running my hacky fix without any issues but I'm wondering if there may be a better solution out there.
For some reason I didn't receive your previous mail. In case that's true for others, Zippy's original message can be found at: https://lists.sel4.systems/hyperkitty/list/devel@sel4.systems/thread/AA7ZI5K... It's a problem in some CAmkES script, it seems it expects interrupt properties at a specific level or something, anything deeper gets weirdly renamed. I have no CAmkES experience, so I'm not much help. You can do your fixups in your own overlay file and apply it with KernelCustomDTSOverlay, instead of editing the original DTS file. An alternative to CAmkES is Microkit, but it depends on your use case what's better. Greetings, Indan
Hi Indan, Thanks for the reply. Our current system is CAmkES based so moving to MicroKit would be a large development exercise with no budget! The DTS in question is one of several VMs in our system which are tailored to our bespoke hardware. The VM in question now needs access to CAAM/SNVS SoC resources. My hack has been working for over 2 months without any problems. I guess anybody else with the same problem would come across these posts and at least be able to do the same. Perhaps I'll have a dig into macros.py and see if I can find a general fix unless Axel Heider is reading this an knows exactly what's wrong. Cheers, Richard
participants (2)
-
Indan Zupancic
-
Zippy Manaic