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': [, , , , , ], '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': [, , , , , , , ], '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
