| Message ID | 1559938596-5696-1-git-send-email-amittomer25@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Sat, Jun 8, 2019 at 1:46 AM Amit Singh Tomar <amittomer25@gmail.com> wrote: > > This series tries to enable XEN booting on i.MX 8MQuad Applications Processors[1]. > > Patch-set includes driver for UART controller found on i.MX8MQ SoC and debug code > for earlyprintk support. > Gentle Ping. Thanks -Amit
On 25/07/2019 15:15, Amit Tomer wrote: > Hi, Hi, > On Sat, Jun 8, 2019 at 1:46 AM Amit Singh Tomar <amittomer25@gmail.com> wrote: >> >> This series tries to enable XEN booting on i.MX 8MQuad Applications Processors[1]. >> >> Patch-set includes driver for UART controller found on i.MX8MQ SoC and debug code >> for earlyprintk support. >> > Gentle Ping. This is in my long list of patches to review and work to do. Any help to reduce the list will mean I can reach your series quicker... I have seen multiple threads from you pointing at issues on the IMX.8. Have they been resolved? Is this series enough to get Xen and Dom0 booting on the NXP platform? Cheers,
Hi, Sorry for the late reply. > I have seen multiple threads from you pointing at issues on the IMX.8. Have they > been resolved? Is this series enough to get Xen and Dom0 booting on the NXP > platform? Yeah, most of issues are resolved now and mainline DTS is used to bring XEN on this i.MX8 platform. Though there is small change that comment out GPC (which is used root interrupt parent) and instead use GIC is done in DTS. The patches has been tested booting DOM0 with ramfs. Thanks, -Amit
Hi, I have CCed one person from Donerworks. IIRC they have been using the IMX8 in the past. On 03/08/2019 21:54, Amit Tomer wrote: >> I have seen multiple threads from you pointing at issues on the IMX.8. Have they >> been resolved? Is this series enough to get Xen and Dom0 booting on the NXP >> platform? > > Yeah, most of issues are resolved now and mainline DTS is used to > bring XEN on this i.MX8 platform. > > Though there is small change that comment out GPC (which is used root > interrupt parent) and instead use GIC > is done in DTS. What are the consequences to change the interrupt parent? > > The patches has been tested booting DOM0 with ramfs. I don't think this is enough to claim support for Xen on the I.MX8M platform. What I don't want to end up is having yet another UART driver to maintain in Xen but the platform is still unusable. You should at least be able to boot multiple domains and use a fully fledge distro (yocto, Debian...) from a mass storage (and possibly network). Cheers,
On 8/5/19 4:38 AM, Julien Grall wrote: > CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > Hi, > > I have CCed one person from Donerworks. IIRC they have been using the IMX8 in > the past. Amit, Have you checked out the NXP Xen fork? https://source.codeaurora.org/external/imx/imx-xen/ While the work there hasn't been upstreamed yet, the support for the iMX8QM (QuadMax) is fairly complete. There are some important differences between the iMX8M and that SoC beyond those you've noted (no A72 cluster, no SMMU, and no System Control Unit (SCU)), but it might solve some of the issues you've been running into or avoid yet unknown issues when you attempt to boot a guest domain. Nate > > On 03/08/2019 21:54, Amit Tomer wrote: >>> I have seen multiple threads from you pointing at issues on the IMX.8. Have they >>> been resolved? Is this series enough to get Xen and Dom0 booting on the NXP >>> platform? >> >> Yeah, most of issues are resolved now and mainline DTS is used to >> bring XEN on this i.MX8 platform. >> >> Though there is small change that comment out GPC (which is used root >> interrupt parent) and instead use GIC >> is done in DTS. > > What are the consequences to change the interrupt parent? > >> >> The patches has been tested booting DOM0 with ramfs. > > I don't think this is enough to claim support for Xen on the I.MX8M platform. > What I don't want to end up is having yet another UART driver to maintain in Xen > but the platform is still unusable. > > You should at least be able to boot multiple domains and use a fully fledge > distro (yocto, Debian...) from a mass storage (and possibly network). > > Cheers, > > -- > Julien Grall > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel >
Hi Nate , Hi Julien, > > Amit, > > Have you checked out the NXP Xen fork? > > https://source.codeaurora.org/external/imx/imx-xen/ > > While the work there hasn't been upstreamed yet, the support for the iMX8QM > (QuadMax) is fairly complete. There are some important differences between the > iMX8M and that SoC beyond those you've noted (no A72 cluster, no SMMU, and no > System Control Unit (SCU)), but it might solve some of the issues you've been > running into or avoid yet unknown issues when you attempt to boot a guest domain. I looked around the work done for iMX8QM but the UART IP used on i.MX8MQ is completely different than that used on i.MXQM. The initial agenda of this series is to get particular uart driver(used on i.IMX8MQ) in first and then start booting domUs. Thanks, -Amit
Hi > > What are the consequences to change the interrupt parent? I am not entirely sure about it at the moment but looks like it controllers power domain for various devices like GPU, VPU and OTG etc. So, we may not be able to support these devices for XEN domains ? Also, this IP is not present on other i.MX8 platforms, for instance iMX8QM. > > > > The patches has been tested booting DOM0 with ramfs. > > I don't think this is enough to claim support for Xen on the I.MX8M platform. > What I don't want to end up is having yet another UART driver to maintain in Xen > but the platform is still unusable. > > You should at least be able to boot multiple domains and use a fully fledge > distro (yocto, Debian...) from a mass storage (and possibly network). > Yeah, I can understand this and would try to work on it (but not sure when can I have access to H/W). Thanks, Amit
On 8/6/19 10:14 PM, Amit Tomer wrote: > Hi Hi, >> What are the consequences to change the interrupt parent? > > I am not entirely sure about it at the moment but looks like it > controllers power domain > for various devices like GPU, VPU and OTG etc. > > So, we may not be able to support these devices for XEN domains ? I haven't used the platform so I can't for sure know what can happen here. The risk is if all the power domains are turned off at boot, then Dom0 would not be able to turn them on. Therefore all the devices you listed may be unusable. Cheers,
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi index 6d635ba..7eac1786 100644 --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi @@ -13,7 +13,7 @@ #include "imx8mq-pinfunc.h" / { - interrupt-parent = <&gpc>; + interrupt-parent = <&gic>; #address-cells = <2>; #size-cells = <2>;