On Tuesday 08 October 2013 12:29 PM, Chen Baozi wrote: > Hi all, > > I have got a problem when booting dom0 kernel for Xen on OMAP5432 uEVM. > With a recent patch, Xen hypervisor is avoid to map "disabled" device > memory for dom0. In omap5-uevm.dts, we have got the &mmc4 node marked as > "disabled". So the Xen won't populate <0x480d1000 0x400> memory region > to the dom0. If dom0 is trying to access any memory address in this > area, the hypervisor would be panic with a tranlation fault. However, it > turns out that even the mmc4 is disabled in omap5-uevm.dts, Linux kernel > is trying to access the 0x480d1010 when booting, which then leads a > hypervisor panic as mentioned. > > The only point I know right now is that the 0x480d1010 is accessed by > the omap_hwmod_read(). However, what makes me confused is how the dom0 > kernel called omap_hwmod_read() to access 0x480d1010 while the mmc4 is > disabled. I guess it might relate to hard coded omap_hwmod structure but > have no idea what happen exactly when dom0 access the address due to the > lack of calling stack information when booting Xen hypervisor. > There is no hard-coding rather a different requirement why hwmod accesses the IP space. DT disabled is will ensure that the device won't get created but hwmod bus initially tries to put all the supported IPs in sane hardware state by doing reset on those IPs. We have proposals to address than in future where such resets are moved with device/driver probe etc to avoid such issues. Actually MMC4 is more for SDIO kind of usecase so you might even get rid of that in your case. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
