diff mbox

[RFC,0/2] XEN booting on i.MX8M platform

Message ID 1559938596-5696-1-git-send-email-amittomer25@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Amit Tomer June 7, 2019, 8:16 p.m. UTC
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.

Mainline dts binding that are used for platform discover has GPC as root interrupt parent 
is not yet supported in XEN, therefore following changes is needed to boot XEN on this platform.


It has been tested on nitrogen8m board[2] by booting dom0 with RAMFS.

[1]:https://www.nxp.com/support/developer-resources/evaluation-and-development-boards/i.mx-evaluation-and-development-boards/evaluation-kit-for-the-i.mx-8m-applications-processor:MCIMX8M-EVK
[2]:https://boundarydevices.com/product/nitrogen8m/

Amit Singh Tomar (2):
  xen/arm: Add i.MX8MQ SoCs earlyprintk support
  xen/arm: Add UART driver for i.MX8MQ SoC

 xen/arch/arm/arm64/debug-imx8mq.inc |  54 +++++++
 xen/drivers/char/Kconfig            |   8 +
 xen/drivers/char/Makefile           |   1 +
 xen/drivers/char/imx8mq-uart.c      | 306 ++++++++++++++++++++++++++++++++++++
 4 files changed, 369 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-imx8mq.inc
 create mode 100644 xen/drivers/char/imx8mq-uart.c

Comments

Amit Tomer July 25, 2019, 2:15 p.m. UTC | #1
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
Julien Grall July 25, 2019, 2:22 p.m. UTC | #2
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,
Amit Tomer Aug. 3, 2019, 8:54 p.m. UTC | #3
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
Julien Grall Aug. 5, 2019, 8:38 a.m. UTC | #4
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,
Nathan Studer Aug. 6, 2019, 3:37 p.m. UTC | #5
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
>
Amit Tomer Aug. 6, 2019, 9:05 p.m. UTC | #6
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
Amit Tomer Aug. 6, 2019, 9:14 p.m. UTC | #7
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
Julien Grall Aug. 19, 2019, 10:16 a.m. UTC | #8
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 mbox

Patch

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>;