>> Ok, I changed it and was able to boot to the previous error. I think a >> logical next step would be to set up the uart somehow? > > Do you mean the UART used by Xen? Yes, to be able to switch between xen and dom0, to download a produced dt for dom0 for example. > >>> >>> But this feels weird to map then unmap the mmio. Instead, you should >>> blacklist the crossbar device. Have a look at the field blacklist_dev in >>> platform_desc. >> Hm, I can see that in the device tree the crossbar has a phandle >> property <0x00000008> and the main node has an interrupt-parent property >> 0x00000008. So, all the interrupts seems to be mapped to the crossbar. >> Wouldn't be that a problem if we blacklist the device? > > > The Device is owned by Xen, so technically Dom0 does not see the > hardware one. Instead it sees a virtual and therefore the node should be > created to reflect it. > > The purpose of recreating the node is you can alter it to match what we > actually exposed to the domain (property values may differ). It may > happen that a lot of information are exactly the same as the hardware > and can just be copied. > > This is, for instance, what we do for the GIC and timer. I mean if we expose only GIC to the dom0 then we need to change the interrupt-parent property to make all nodes have GIC's phandle as their interrupt-parent. And when dom0 tries to modify irq connections then xen should modify the crossbar. It seems to be a bit error prone approach. > >> Also, the tegra >> implementation blacklist only a uart. > > I don't understand this. In here [1] you can find that only uart is blacklisted (in tegra_blacklist_dev[]). So, in tegra they didn't blacklist their version of the crossbar.
[1] https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg00993.html -- Regards, Denis Obrezkov _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
