diff mbox series

[v2,8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux

Message ID 20210901085522.1712104-9-michael@walle.cc
State Superseded
Delegated to: Priyanka Jain
Headers show
Series arm: dts: ls1028a: sync device tree with linux | expand

Commit Message

Michael Walle Sept. 1, 2021, 8:55 a.m. UTC
Now that everything is prepared, copy the fsl-ls1028a.dtsi from the
linux kernel v5.14.

Signed-off-by: Michael Walle <michael@walle.cc>
---
changes since v1:
 - none

 arch/arm/dts/fsl-ls1028a.dtsi                 | 1212 +++++++++++++----
 .../dt-bindings/clock/fsl,qoriq-clockgen.h    |   15 +
 2 files changed, 958 insertions(+), 269 deletions(-)
 create mode 100644 include/dt-bindings/clock/fsl,qoriq-clockgen.h

Comments

Vladimir Oltean Sept. 1, 2021, 10:29 a.m. UTC | #1
On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
> -		pcie1: pcie@3400000 {
> -			   compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", "snps,dw-pcie";
> -			   reg = <0x00 0x03400000 0x0 0x80000
> -				   0x00 0x03480000 0x0 0x40000   /* lut registers */
> -				   0x00 0x034c0000 0x0 0x40000  /* pf controls registers */
> -				   0x80 0x00000000 0x0 0x20000>; /* configuration space */
> -			   reg-names = "dbi", "lut", "ctrl", "config";
> -			   #address-cells = <3>;
> -			   #size-cells = <2>;
> -			   device_type = "pci";
> -			   num-lanes = <4>;
> -			   bus-range = <0x0 0xff>;
> -			   ranges = <0x81000000 0x0 0x00000000 0x80 0x00020000 0x0 0x00010000   /* downstream I/O */
> -				   0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
> -		};
> +		pcie1: pcie@3400000 {
> +			compatible = "fsl,ls1028a-pcie";
> +			reg = <0x00 0x03400000 0x0 0x00100000>, /* controller registers */
> +			      <0x80 0x00000000 0x0 0x00002000>; /* configuration space */

This doesn't look good, the conversion is lossy. The Linux driver
(drivers/pci/controller/dwc/pci-layerscape.c) knows the lut_offset by
compatible string, but the U-Boot driver (drivers/pci/pcie_layerscape_rc.c)
calls fdt_get_named_resource("lut"). I.... don't think that the driver
works with a NULL pcie->lut pointer? The StreamID writes in
fdt_fixup_pcie_device_ls probably didn't explode because I don't have
any PCIe card plugged in.

Similar thing for the PEX PF control memory region. In the LS1028A RM,
technically this is part of the larger PEX_LUT memory map, just starting
from the 4_0014h offset.

U-Boot has this piece of logic to deduce pcie->ctrl based on pcie->lut,
but it seems that it needs to be extended to cover LS1028A:

	/*
	 * Fix the pcie memory map address and PF control registers address
	 * for LS2088A series SoCs
	 */
	svr = get_svr();
	svr = (svr >> SVR_VAR_PER_SHIFT) & 0xFFFFFE;
	if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
	    svr == SVR_LS2048A || svr == SVR_LS2044A ||
	    svr == SVR_LS2081A || svr == SVR_LS2041A) {
		pcie_rc->cfg_res.start = LS2088A_PCIE1_PHYS_ADDR +
					 LS2088A_PCIE_PHYS_SIZE * pcie->idx;
		pcie_rc->cfg_res.end = pcie_rc->cfg_res.start + cfg_size;
		pcie->ctrl = pcie->lut + 0x40000;
	}

As for pcie->lut itself, simplest would be to just default to what is
now the "dbi" reg value, plus a .lut_offset determined by compatible
string, in the case of "fsl,ls1028a-pcie" 0x80000, just like Linux.

Ah, and not to mention that the reg-names are not even the same between
U-Boot and Linux. What is "dbi" in U-Boot is "regs" in Linux :)
Vladimir Oltean Sept. 1, 2021, 11:24 a.m. UTC | #2
On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
> -		usb0: usb3@3100000 {
> -			compatible = "fsl,layerscape-dwc3";
> -			reg = <0x0 0x3100000 0x0 0x10000>;
> -			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
> -			dr_mode = "host";
> -			status = "disabled";
> -		};
> -
> -		usb1: usb3@3110000 {
> -			compatible = "fsl,layerscape-dwc3";
> -			reg = <0x0 0x3110000 0x0 0x10000>;
> -			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
> -			dr_mode = "host";
> +		usb0: usb@3100000 {
> +			compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
> +			reg = <0x0 0x3100000 0x0 0x10000>;
> +			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
> +			dr_mode = "host";
> +			snps,dis_rxdet_inp3_quirk;
> +			snps,quirk-frame-length-adjustment = <0x20>;
> +			snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
> +		};
> +
> +		usb1: usb@3110000 {
> +			compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
> +			reg = <0x0 0x3110000 0x0 0x10000>;
> +			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
> +			dr_mode = "host";
> +			snps,dis_rxdet_inp3_quirk;
> +			snps,quirk-frame-length-adjustment = <0x20>;
> +			snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
> +		};

I see the status = 'disabled' was lost in the new bindings? This is
strange considering that it is you who sent the patch to disable them in
Linux, just yesterday:
https://lkml.org/lkml/2021/8/31/426
Vladimir Oltean Sept. 1, 2021, 11:27 a.m. UTC | #3
On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
>  		sata: sata@3200000 {
>  			compatible = "fsl,ls1028a-ahci";
> -			reg = <0x0 0x3200000 0x0 0x10000	/* ccsr sata base */
> -				   0x7 0x100520  0x0 0x4>;		/* ecc sata addr*/
> -			reg-names = "sata-base", "ecc-addr";
> +			reg = <0x0 0x3200000 0x0 0x10000>,
> +				<0x7 0x100520 0x0 0x4>;
> +			reg-names = "ahci", "sata-ecc";

Again, same problem. The drivers/ata/sata_ceva.c driver calls
dev_read_resource_byname(dev, "ecc-addr") (but not for "sata-base",
apparently).

If you don't want to convert all occurrences of "ecc-addr" to
"sata-ecc", then at least add a fallback call to dev_read_resource_byname.
Vladimir Oltean Sept. 1, 2021, 11:43 a.m. UTC | #4
On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
> -		pcie1: pcie@3400000 {
> -			   ranges = <0x81000000 0x0 0x00000000 0x80 0x00020000 0x0 0x00010000   /* downstream I/O */
> -				   0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
> -		};
>  
> -		pcie2: pcie@3500000 {
> -			   ranges = <0x81000000 0x0 0x00000000 0x88 0x00020000 0x0 0x00010000   /* downstream I/O */
> -				   0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
> -		};
> +		pcie1: pcie@3400000 {
> +			ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000   /* downstream I/O */
> +				  0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
>  		};
>  
> +		pcie2: pcie@3500000 {
> +			ranges = <0x81000000 0x0 0x00000000 0x88 0x00010000 0x0 0x00010000   /* downstream I/O */
> +				  0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
> +		};

This change also makes an undocumented movement of the PCIe window in
the SoC memory space from 0x80_00020000 to 0x80_00010000 for pcie1, and
from 0x88_00020000 to 0x88_00010000 for pcie2.

It should probably work either way, considering that the SoC system
memory map lists the entire 32GB of address space starting from
0x0080_0000_0000 as belonging to PEX1, and 0x0088_0000_0000 belonging to
PEX2, but either way, is there no better way to make these changes?!
It seems like a lot to go through. At the very least do document the
changes in the commit message, it makes you be aware of what you're
changing, and it makes people get an overview instead of needing to do
dumpster diving.
Michael Walle Sept. 1, 2021, 11:46 a.m. UTC | #5
Am 2021-09-01 13:43, schrieb Vladimir Oltean:
> On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
>> -		pcie1: pcie@3400000 {
>> -			   ranges = <0x81000000 0x0 0x00000000 0x80 0x00020000 0x0 
>> 0x00010000   /* downstream I/O */
>> -				   0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* 
>> non-prefetchable memory */
>> -		};
>> 
>> -		pcie2: pcie@3500000 {
>> -			   ranges = <0x81000000 0x0 0x00000000 0x88 0x00020000 0x0 
>> 0x00010000   /* downstream I/O */
>> -				   0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* 
>> non-prefetchable memory */
>> -		};
>> +		pcie1: pcie@3400000 {
>> +			ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000 
>>   /* downstream I/O */
>> +				  0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* 
>> non-prefetchable memory */
>>  		};
>> 
>> +		pcie2: pcie@3500000 {
>> +			ranges = <0x81000000 0x0 0x00000000 0x88 0x00010000 0x0 0x00010000 
>>   /* downstream I/O */
>> +				  0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* 
>> non-prefetchable memory */
>> +		};
> 
> This change also makes an undocumented movement of the PCIe window in
> the SoC memory space from 0x80_00020000 to 0x80_00010000 for pcie1, and
> from 0x88_00020000 to 0x88_00010000 for pcie2.
> 
> It should probably work either way, considering that the SoC system
> memory map lists the entire 32GB of address space starting from
> 0x0080_0000_0000 as belonging to PEX1, and 0x0088_0000_0000 belonging 
> to
> PEX2, but either way, is there no better way to make these changes?!
> It seems like a lot to go through. At the very least do document the
> changes in the commit message, it makes you be aware of what you're
> changing, and it makes people get an overview instead of needing to do
> dumpster diving.

TBH, I haven't looked at PCI. Sorry. Shouldn't have rushed that patch 
series.
I'll have a look at all your findinds and will make a patch for each one 
so the uboot device tree and the linux device tree are similar, just 
like i did for the other peripherals.

-michael
Michael Walle Sept. 1, 2021, 11:51 a.m. UTC | #6
Am 2021-09-01 13:24, schrieb Vladimir Oltean:
> On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
>> -		usb0: usb3@3100000 {
>> -			compatible = "fsl,layerscape-dwc3";
>> -			reg = <0x0 0x3100000 0x0 0x10000>;
>> -			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
>> -			dr_mode = "host";
>> -			status = "disabled";
>> -		};
>> -
>> -		usb1: usb3@3110000 {
>> -			compatible = "fsl,layerscape-dwc3";
>> -			reg = <0x0 0x3110000 0x0 0x10000>;
>> -			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
>> -			dr_mode = "host";
>> +		usb0: usb@3100000 {
>> +			compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
>> +			reg = <0x0 0x3100000 0x0 0x10000>;
>> +			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
>> +			dr_mode = "host";
>> +			snps,dis_rxdet_inp3_quirk;
>> +			snps,quirk-frame-length-adjustment = <0x20>;
>> +			snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
>> +		};
>> +
>> +		usb1: usb@3110000 {
>> +			compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
>> +			reg = <0x0 0x3110000 0x0 0x10000>;
>> +			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
>> +			dr_mode = "host";
>> +			snps,dis_rxdet_inp3_quirk;
>> +			snps,quirk-frame-length-adjustment = <0x20>;
>> +			snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
>> +		};
> 
> I see the status = 'disabled' was lost in the new bindings? This is
> strange considering that it is you who sent the patch to disable them 
> in
> Linux, just yesterday:
> https://lkml.org/lkml/2021/8/31/426

Yes but that is on purpose. In the current u-boot device tree, it was
disabled, but the boards reenabled them again. So it didn't matter.

I want to have a specific sync point (that is the v5.14 tag) for the
.dtsi. At least where possible; for phy-mode and so on I needed to to
take additional patches which weren't picked up in linux yet, but
these just affect the sl28 board device trees.

-michael
Vladimir Oltean Sept. 1, 2021, 11:55 a.m. UTC | #7
On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote:
> Yes but that is on purpose. In the current u-boot device tree, it was
> disabled, but the boards reenabled them again. So it didn't matter.
> 
> I want to have a specific sync point (that is the v5.14 tag) for the
> .dtsi. At least where possible; for phy-mode and so on I needed to to
> take additional patches which weren't picked up in linux yet, but
> these just affect the sl28 board device trees.

Binary compatibility is one thing and I can understand it.
Textual compatibility, down to label names, and where the device is
being disabled from? Hmmmm, I'm having a hard time saying yes to that.

(btw I finished reviewing this patch, I have no other comments)
Michael Walle Sept. 1, 2021, 12:05 p.m. UTC | #8
Am 2021-09-01 13:55, schrieb Vladimir Oltean:
> On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote:
>> Yes but that is on purpose. In the current u-boot device tree, it was
>> disabled, but the boards reenabled them again. So it didn't matter.
>> 
>> I want to have a specific sync point (that is the v5.14 tag) for the
>> .dtsi. At least where possible; for phy-mode and so on I needed to to
>> take additional patches which weren't picked up in linux yet, but
>> these just affect the sl28 board device trees.
> 
> Binary compatibility is one thing and I can understand it.
> Textual compatibility, down to label names, and where the device is
> being disabled from? Hmmmm, I'm having a hard time saying yes to that.

It's a step back, yes. But only until v5.16 (I don't think the changes
will make it during the merge window). I guess you are concerned because
of your vendor fork? Mh, well actually I don't understand your concert,
because your tree isn't compatible anyway if we change the labels.

We'd trade the clear information where the device tree is from for
something that - in my opinion - is not worth it. I mean the device
tree (source) is used just here in u-boot for these three boards and
all have the usb nodes enabled.

> (btw I finished reviewing this patch, I have no other comments)

thanks for the efforts!

-michael
Vladimir Oltean Sept. 1, 2021, 12:21 p.m. UTC | #9
On Wed, Sep 01, 2021 at 02:05:34PM +0200, Michael Walle wrote:
> Am 2021-09-01 13:55, schrieb Vladimir Oltean:
> > On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote:
> > > Yes but that is on purpose. In the current u-boot device tree, it was
> > > disabled, but the boards reenabled them again. So it didn't matter.
> > > 
> > > I want to have a specific sync point (that is the v5.14 tag) for the
> > > .dtsi. At least where possible; for phy-mode and so on I needed to to
> > > take additional patches which weren't picked up in linux yet, but
> > > these just affect the sl28 board device trees.
> > 
> > Binary compatibility is one thing and I can understand it.
> > Textual compatibility, down to label names, and where the device is
> > being disabled from? Hmmmm, I'm having a hard time saying yes to that.
> 
> It's a step back, yes. But only until v5.16 (I don't think the changes
> will make it during the merge window). I guess you are concerned because
> of your vendor fork? Mh, well actually I don't understand your concert,
> because your tree isn't compatible anyway if we change the labels.

No, I don't care about "our vendor fork", it's been years since I've
stopped using that.

> We'd trade the clear information where the device tree is from for
> something that - in my opinion - is not worth it. I mean the device
> tree (source) is used just here in u-boot for these three boards and
> all have the usb nodes enabled.

My concern was actually much simpler: your v1 conversion of the label
names was buggy (see the LS1028A-QDS build breakage). You deleted a
bunch of comments which U-Boot had but Linux did not (luckily they did
not provide a lot of useful information anyway). You introduced some
comments which do not make sense for the U-Boot tree, because they were
in Linux: the ICIDs in the iommu-map being fixed up by the bootloader
(you can instead say that "we will fix these up for the operating system").
Again, not big issues, but if it would boil down to my common sense,
I'd focus more on the binary compatibility (after all, there will still
be U-Boot specifics, which will constitute textual differences, but
Linux will gladly ignore them, because this is what binary compatibility
is about), and if it is preferable to have status = 'disabled' in the
dtsi, and a patch was already sent to Linux but not yet accepted, I
would have kept U-Boot the way it was, and follow a model of
"eventual consistency".

If you still care more about textual consistency, I went through the patches
once already, so it's not like changing things now will make things easier,
or matter.
Michael Walle Sept. 1, 2021, 12:38 p.m. UTC | #10
Am 2021-09-01 14:21, schrieb Vladimir Oltean:
> On Wed, Sep 01, 2021 at 02:05:34PM +0200, Michael Walle wrote:
>> Am 2021-09-01 13:55, schrieb Vladimir Oltean:
>> > On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote:
>> > > Yes but that is on purpose. In the current u-boot device tree, it was
>> > > disabled, but the boards reenabled them again. So it didn't matter.
>> > >
>> > > I want to have a specific sync point (that is the v5.14 tag) for the
>> > > .dtsi. At least where possible; for phy-mode and so on I needed to to
>> > > take additional patches which weren't picked up in linux yet, but
>> > > these just affect the sl28 board device trees.
>> >
>> > Binary compatibility is one thing and I can understand it.
>> > Textual compatibility, down to label names, and where the device is
>> > being disabled from? Hmmmm, I'm having a hard time saying yes to that.
>> 
>> It's a step back, yes. But only until v5.16 (I don't think the changes
>> will make it during the merge window). I guess you are concerned 
>> because
>> of your vendor fork? Mh, well actually I don't understand your 
>> concert,
>> because your tree isn't compatible anyway if we change the labels.
> 
> No, I don't care about "our vendor fork", it's been years since I've
> stopped using that.
> 
>> We'd trade the clear information where the device tree is from for
>> something that - in my opinion - is not worth it. I mean the device
>> tree (source) is used just here in u-boot for these three boards and
>> all have the usb nodes enabled.
> 
> My concern was actually much simpler: your v1 conversion of the label
> names was buggy (see the LS1028A-QDS build breakage). You deleted a
> bunch of comments which U-Boot had but Linux did not (luckily they did
> not provide a lot of useful information anyway). You introduced some
> comments which do not make sense for the U-Boot tree, because they were
> in Linux: the ICIDs in the iommu-map being fixed up by the bootloader
> (you can instead say that "we will fix these up for the operating 
> system").
> Again, not big issues, but if it would boil down to my common sense,
> I'd focus more on the binary compatibility (after all, there will still
> be U-Boot specifics, which will constitute textual differences, but
> Linux will gladly ignore them, because this is what binary 
> compatibility
> is about), and if it is preferable to have status = 'disabled' in the
> dtsi, and a patch was already sent to Linux but not yet accepted, I
> would have kept U-Boot the way it was, and follow a model of
> "eventual consistency".
> 
> If you still care more about textual consistency, I went through the 
> patches
> once already, so it's not like changing things now will make things 
> easier,
> or matter.

Ok, I see. But shouldn't be the goal to make things easy and just copy
the device tree to u-boot once in a while? Otherwise, we will eventually
end up in the same mess as it is right now. Because well if they are
different anyway, then "we can just add another small thing right here
and there". So yes, if you mean that by textual consistency, I care
about that.

And about the lost/wrong comments. We should "fix"/add/reword them in
linux, no?

-michael
Vladimir Oltean Sept. 1, 2021, 12:57 p.m. UTC | #11
On Wed, Sep 01, 2021 at 02:38:15PM +0200, Michael Walle wrote:
> Am 2021-09-01 14:21, schrieb Vladimir Oltean:
> > On Wed, Sep 01, 2021 at 02:05:34PM +0200, Michael Walle wrote:
> > > Am 2021-09-01 13:55, schrieb Vladimir Oltean:
> > > > On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote:
> > > > > Yes but that is on purpose. In the current u-boot device tree, it was
> > > > > disabled, but the boards reenabled them again. So it didn't matter.
> > > > >
> > > > > I want to have a specific sync point (that is the v5.14 tag) for the
> > > > > .dtsi. At least where possible; for phy-mode and so on I needed to to
> > > > > take additional patches which weren't picked up in linux yet, but
> > > > > these just affect the sl28 board device trees.
> > > >
> > > > Binary compatibility is one thing and I can understand it.
> > > > Textual compatibility, down to label names, and where the device is
> > > > being disabled from? Hmmmm, I'm having a hard time saying yes to that.
> > > 
> > > It's a step back, yes. But only until v5.16 (I don't think the changes
> > > will make it during the merge window). I guess you are concerned
> > > because
> > > of your vendor fork? Mh, well actually I don't understand your
> > > concert,
> > > because your tree isn't compatible anyway if we change the labels.
> > 
> > No, I don't care about "our vendor fork", it's been years since I've
> > stopped using that.
> > 
> > > We'd trade the clear information where the device tree is from for
> > > something that - in my opinion - is not worth it. I mean the device
> > > tree (source) is used just here in u-boot for these three boards and
> > > all have the usb nodes enabled.
> > 
> > My concern was actually much simpler: your v1 conversion of the label
> > names was buggy (see the LS1028A-QDS build breakage). You deleted a
> > bunch of comments which U-Boot had but Linux did not (luckily they did
> > not provide a lot of useful information anyway). You introduced some
> > comments which do not make sense for the U-Boot tree, because they were
> > in Linux: the ICIDs in the iommu-map being fixed up by the bootloader
> > (you can instead say that "we will fix these up for the operating
> > system").
> > Again, not big issues, but if it would boil down to my common sense,
> > I'd focus more on the binary compatibility (after all, there will still
> > be U-Boot specifics, which will constitute textual differences, but
> > Linux will gladly ignore them, because this is what binary compatibility
> > is about), and if it is preferable to have status = 'disabled' in the
> > dtsi, and a patch was already sent to Linux but not yet accepted, I
> > would have kept U-Boot the way it was, and follow a model of
> > "eventual consistency".
> > 
> > If you still care more about textual consistency, I went through the
> > patches
> > once already, so it's not like changing things now will make things
> > easier,
> > or matter.
> 
> Ok, I see. But shouldn't be the goal to make things easy and just copy
> the device tree to u-boot once in a while? Otherwise, we will eventually
> end up in the same mess as it is right now. Because well if they are
> different anyway, then "we can just add another small thing right here
> and there".

So if we "just add another small thing here and there", where that thing
is a comment, or a 'status = "disabled"' structured differently but to
the same result, does that land us in the "same mess" where half of the
peripherals, and networking, would not work in Linux with the U-Boot
provided DT?

> So yes, if you mean that by textual consistency, I care about that.

Okay.

> And about the lost/wrong comments. We should "fix"/add/reword them in
> linux, no?

In the case of SMMU ICIDs, it is a matter of perspective (bootloader vs
kernel). If the phrasing is generic enough to cover both perspectives,
I've no problem. In this case, after the initial reaction, I might even
be ok with the current phrasing of "/* fixed up by bootloader */". It is
not very clarifying, but not outright wrong either.
My larger point was that if we now swing in the opposite direction,
and can't make a common-sense decision before making it in Linux first,
and then waiting for the next merge window, that's.. strange?

Anyway, quite a storm in a teacup.
Michael Walle Sept. 1, 2021, 1:30 p.m. UTC | #12
Am 2021-09-01 14:57, schrieb Vladimir Oltean:
> On Wed, Sep 01, 2021 at 02:38:15PM +0200, Michael Walle wrote:
>> Am 2021-09-01 14:21, schrieb Vladimir Oltean:
>> > On Wed, Sep 01, 2021 at 02:05:34PM +0200, Michael Walle wrote:
>> > > Am 2021-09-01 13:55, schrieb Vladimir Oltean:
>> > > > On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote:
>> > > > > Yes but that is on purpose. In the current u-boot device tree, it was
>> > > > > disabled, but the boards reenabled them again. So it didn't matter.
>> > > > >
>> > > > > I want to have a specific sync point (that is the v5.14 tag) for the
>> > > > > .dtsi. At least where possible; for phy-mode and so on I needed to to
>> > > > > take additional patches which weren't picked up in linux yet, but
>> > > > > these just affect the sl28 board device trees.
>> > > >
>> > > > Binary compatibility is one thing and I can understand it.
>> > > > Textual compatibility, down to label names, and where the device is
>> > > > being disabled from? Hmmmm, I'm having a hard time saying yes to that.
>> > >
>> > > It's a step back, yes. But only until v5.16 (I don't think the changes
>> > > will make it during the merge window). I guess you are concerned
>> > > because
>> > > of your vendor fork? Mh, well actually I don't understand your
>> > > concert,
>> > > because your tree isn't compatible anyway if we change the labels.
>> >
>> > No, I don't care about "our vendor fork", it's been years since I've
>> > stopped using that.
>> >
>> > > We'd trade the clear information where the device tree is from for
>> > > something that - in my opinion - is not worth it. I mean the device
>> > > tree (source) is used just here in u-boot for these three boards and
>> > > all have the usb nodes enabled.
>> >
>> > My concern was actually much simpler: your v1 conversion of the label
>> > names was buggy (see the LS1028A-QDS build breakage). You deleted a
>> > bunch of comments which U-Boot had but Linux did not (luckily they did
>> > not provide a lot of useful information anyway). You introduced some
>> > comments which do not make sense for the U-Boot tree, because they were
>> > in Linux: the ICIDs in the iommu-map being fixed up by the bootloader
>> > (you can instead say that "we will fix these up for the operating
>> > system").
>> > Again, not big issues, but if it would boil down to my common sense,
>> > I'd focus more on the binary compatibility (after all, there will still
>> > be U-Boot specifics, which will constitute textual differences, but
>> > Linux will gladly ignore them, because this is what binary compatibility
>> > is about), and if it is preferable to have status = 'disabled' in the
>> > dtsi, and a patch was already sent to Linux but not yet accepted, I
>> > would have kept U-Boot the way it was, and follow a model of
>> > "eventual consistency".
>> >
>> > If you still care more about textual consistency, I went through the
>> > patches
>> > once already, so it's not like changing things now will make things
>> > easier,
>> > or matter.
>> 
>> Ok, I see. But shouldn't be the goal to make things easy and just copy
>> the device tree to u-boot once in a while? Otherwise, we will 
>> eventually
>> end up in the same mess as it is right now. Because well if they are
>> different anyway, then "we can just add another small thing right here
>> and there".
> 
> So if we "just add another small thing here and there", where that 
> thing
> is a comment, or a 'status = "disabled"' structured differently but to
> the same result, does that land us in the "same mess" where half of the
> peripherals, and networking, would not work in Linux with the U-Boot
> provided DT?

I said eventually. My fear is that otherwise it will slowly diverge
again, because nobody really cares to keep them in sync.
Like once, I've tried to make the sl28 board dts look the same in
u-boot and linux, but as soon as I saw how different they were, I just
changed it like u-boot was expecting it.
IMHO it's the small things that get bigger and bigger. I suspect
the device tree for the LS1028A looked very similar in linux and u-boot
in the beginning. It's just that the main development was going on
in linux and nobody cared to bring that back into u-boot.

Until there is something severly different we should have a greater
goal to keep things the same and for uboot specifics we have 
-u-boot.dtsi.
It's not that device trees are changed very often once there is has
binding documentation.

> My larger point was that if we now swing in the opposite direction,
> and can't make a common-sense decision before making it in Linux first,
> and then waiting for the next merge window, that's.. strange?

That's not what I have in mind. No one is keeping you sending the
patch to both. Or maybe just to u-boot but you'd have to keep in mind
that it might be lost on a next sync if you didn't care to bring
it into linux - or if changes were suggested in linux, you'd need
to adapt u-boot afterwards.

-michael
Michael Walle Sept. 1, 2021, 2:51 p.m. UTC | #13
Am 2021-09-01 13:27, schrieb Vladimir Oltean:
> On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
>>  		sata: sata@3200000 {
>>  			compatible = "fsl,ls1028a-ahci";
>> -			reg = <0x0 0x3200000 0x0 0x10000	/* ccsr sata base */
>> -				   0x7 0x100520  0x0 0x4>;		/* ecc sata addr*/
>> -			reg-names = "sata-base", "ecc-addr";
>> +			reg = <0x0 0x3200000 0x0 0x10000>,
>> +				<0x7 0x100520 0x0 0x4>;
>> +			reg-names = "ahci", "sata-ecc";
> 
> Again, same problem. The drivers/ata/sata_ceva.c driver calls
> dev_read_resource_byname(dev, "ecc-addr") (but not for "sata-base",
> apparently).
> 
> If you don't want to convert all occurrences of "ecc-addr" to
> "sata-ecc", then at least add a fallback call to 
> dev_read_resource_byname.

This is also missing proper bindings documentation in linux :(
I guess it's safe to assume the current linux device tree binding
is the correct one.

-michael
Michael Walle Sept. 1, 2021, 9:34 p.m. UTC | #14
Am 2021-09-01 12:29, schrieb Vladimir Oltean:
> On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
>> -		pcie1: pcie@3400000 {
>> -			   compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", "snps,dw-pcie";
>> -			   reg = <0x00 0x03400000 0x0 0x80000
>> -				   0x00 0x03480000 0x0 0x40000   /* lut registers */
>> -				   0x00 0x034c0000 0x0 0x40000  /* pf controls registers */
>> -				   0x80 0x00000000 0x0 0x20000>; /* configuration space */
>> -			   reg-names = "dbi", "lut", "ctrl", "config";
>> -			   #address-cells = <3>;
>> -			   #size-cells = <2>;
>> -			   device_type = "pci";
>> -			   num-lanes = <4>;
>> -			   bus-range = <0x0 0xff>;
>> -			   ranges = <0x81000000 0x0 0x00000000 0x80 0x00020000 0x0 
>> 0x00010000   /* downstream I/O */
>> -				   0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* 
>> non-prefetchable memory */
>> -		};
>> +		pcie1: pcie@3400000 {
>> +			compatible = "fsl,ls1028a-pcie";
>> +			reg = <0x00 0x03400000 0x0 0x00100000>, /* controller registers */
>> +			      <0x80 0x00000000 0x0 0x00002000>; /* configuration space */
> 
> This doesn't look good, the conversion is lossy. The Linux driver
> (drivers/pci/controller/dwc/pci-layerscape.c) knows the lut_offset by
> compatible string, but the U-Boot driver 
> (drivers/pci/pcie_layerscape_rc.c)
> calls fdt_get_named_resource("lut"). I.... don't think that the driver
> works with a NULL pcie->lut pointer? The StreamID writes in
> fdt_fixup_pcie_device_ls probably didn't explode because I don't have
> any PCIe card plugged in.

I guess it didn't probe anyway, because there is no driver for that
compatible string ;)

> Similar thing for the PEX PF control memory region. In the LS1028A RM,
> technically this is part of the larger PEX_LUT memory map, just 
> starting
> from the 4_0014h offset.
> 
> U-Boot has this piece of logic to deduce pcie->ctrl based on pcie->lut,
> but it seems that it needs to be extended to cover LS1028A:

Only that one probably don't want to overwrite cfg_res.start and
cfg_res.end.

> 	/*
> 	 * Fix the pcie memory map address and PF control registers address
> 	 * for LS2088A series SoCs
> 	 */
> 	svr = get_svr();
> 	svr = (svr >> SVR_VAR_PER_SHIFT) & 0xFFFFFE;
> 	if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
> 	    svr == SVR_LS2048A || svr == SVR_LS2044A ||
> 	    svr == SVR_LS2081A || svr == SVR_LS2041A) {
> 		pcie_rc->cfg_res.start = LS2088A_PCIE1_PHYS_ADDR +
> 					 LS2088A_PCIE_PHYS_SIZE * pcie->idx;
> 		pcie_rc->cfg_res.end = pcie_rc->cfg_res.start + cfg_size;
> 		pcie->ctrl = pcie->lut + 0x40000;
> 	}

Oh the horror! Why didn't one just change the config register value in
the (u-boot) device tree instead of overwriting the value for some
specific SoCs.

> As for pcie->lut itself, simplest would be to just default to what is
> now the "dbi" reg value, plus a .lut_offset determined by compatible
> string, in the case of "fsl,ls1028a-pcie" 0x80000, just like Linux.
> 
> Ah, and not to mention that the reg-names are not even the same between
> U-Boot and Linux. What is "dbi" in U-Boot is "regs" in Linux :)

Well and there is a big-endian property, which of course is set for any
Layerscape but the LS1028A. linux has instead just one endianess, but
use a shift offset.

Mh, I'm for sure not going to fix all these hacks in there. I'm thinking
about bascially branching to a different probe for the ls1028a based on
the compatible string (or rather if .data is set or not).

-michael
Tom Rini Sept. 1, 2021, 9:38 p.m. UTC | #15
On Wed, Sep 01, 2021 at 03:30:59PM +0200, Michael Walle wrote:
> Am 2021-09-01 14:57, schrieb Vladimir Oltean:
> > On Wed, Sep 01, 2021 at 02:38:15PM +0200, Michael Walle wrote:
> > > Am 2021-09-01 14:21, schrieb Vladimir Oltean:
> > > > On Wed, Sep 01, 2021 at 02:05:34PM +0200, Michael Walle wrote:
> > > > > Am 2021-09-01 13:55, schrieb Vladimir Oltean:
> > > > > > On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote:
> > > > > > > Yes but that is on purpose. In the current u-boot device tree, it was
> > > > > > > disabled, but the boards reenabled them again. So it didn't matter.
> > > > > > >
> > > > > > > I want to have a specific sync point (that is the v5.14 tag) for the
> > > > > > > .dtsi. At least where possible; for phy-mode and so on I needed to to
> > > > > > > take additional patches which weren't picked up in linux yet, but
> > > > > > > these just affect the sl28 board device trees.
> > > > > >
> > > > > > Binary compatibility is one thing and I can understand it.
> > > > > > Textual compatibility, down to label names, and where the device is
> > > > > > being disabled from? Hmmmm, I'm having a hard time saying yes to that.
> > > > >
> > > > > It's a step back, yes. But only until v5.16 (I don't think the changes
> > > > > will make it during the merge window). I guess you are concerned
> > > > > because
> > > > > of your vendor fork? Mh, well actually I don't understand your
> > > > > concert,
> > > > > because your tree isn't compatible anyway if we change the labels.
> > > >
> > > > No, I don't care about "our vendor fork", it's been years since I've
> > > > stopped using that.
> > > >
> > > > > We'd trade the clear information where the device tree is from for
> > > > > something that - in my opinion - is not worth it. I mean the device
> > > > > tree (source) is used just here in u-boot for these three boards and
> > > > > all have the usb nodes enabled.
> > > >
> > > > My concern was actually much simpler: your v1 conversion of the label
> > > > names was buggy (see the LS1028A-QDS build breakage). You deleted a
> > > > bunch of comments which U-Boot had but Linux did not (luckily they did
> > > > not provide a lot of useful information anyway). You introduced some
> > > > comments which do not make sense for the U-Boot tree, because they were
> > > > in Linux: the ICIDs in the iommu-map being fixed up by the bootloader
> > > > (you can instead say that "we will fix these up for the operating
> > > > system").
> > > > Again, not big issues, but if it would boil down to my common sense,
> > > > I'd focus more on the binary compatibility (after all, there will still
> > > > be U-Boot specifics, which will constitute textual differences, but
> > > > Linux will gladly ignore them, because this is what binary compatibility
> > > > is about), and if it is preferable to have status = 'disabled' in the
> > > > dtsi, and a patch was already sent to Linux but not yet accepted, I
> > > > would have kept U-Boot the way it was, and follow a model of
> > > > "eventual consistency".
> > > >
> > > > If you still care more about textual consistency, I went through the
> > > > patches
> > > > once already, so it's not like changing things now will make things
> > > > easier,
> > > > or matter.
> > > 
> > > Ok, I see. But shouldn't be the goal to make things easy and just copy
> > > the device tree to u-boot once in a while? Otherwise, we will
> > > eventually
> > > end up in the same mess as it is right now. Because well if they are
> > > different anyway, then "we can just add another small thing right here
> > > and there".
> > 
> > So if we "just add another small thing here and there", where that thing
> > is a comment, or a 'status = "disabled"' structured differently but to
> > the same result, does that land us in the "same mess" where half of the
> > peripherals, and networking, would not work in Linux with the U-Boot
> > provided DT?
> 
> I said eventually. My fear is that otherwise it will slowly diverge
> again, because nobody really cares to keep them in sync.

It doesn't have to, especially if we get things in proper sync now.
There's a number of platforms that do regularly re-sync with the kernel.
It's also something that with a bit of CI work, we could also make sure
doesn't regress as well.  But that'll take some binding documentation
work to start with, along with updating / adding bindings upstream too.
But again, just doing an every kernel release re-sync to keep things
together is quite doable.
Vladimir Oltean Sept. 1, 2021, 9:59 p.m. UTC | #16
On Wed, Sep 01, 2021 at 11:34:50PM +0200, Michael Walle wrote:
> Am 2021-09-01 12:29, schrieb Vladimir Oltean:
> > On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
> > > -		pcie1: pcie@3400000 {
> > > -			   compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", "snps,dw-pcie";
> > > -			   reg = <0x00 0x03400000 0x0 0x80000
> > > -				   0x00 0x03480000 0x0 0x40000   /* lut registers */
> > > -				   0x00 0x034c0000 0x0 0x40000  /* pf controls registers */
> > > -				   0x80 0x00000000 0x0 0x20000>; /* configuration space */
> > > -			   reg-names = "dbi", "lut", "ctrl", "config";
> > > -			   #address-cells = <3>;
> > > -			   #size-cells = <2>;
> > > -			   device_type = "pci";
> > > -			   num-lanes = <4>;
> > > -			   bus-range = <0x0 0xff>;
> > > -			   ranges = <0x81000000 0x0 0x00000000 0x80 0x00020000 0x0
> > > 0x00010000   /* downstream I/O */
> > > -				   0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
> > > /* non-prefetchable memory */
> > > -		};
> > > +		pcie1: pcie@3400000 {
> > > +			compatible = "fsl,ls1028a-pcie";
> > > +			reg = <0x00 0x03400000 0x0 0x00100000>, /* controller registers */
> > > +			      <0x80 0x00000000 0x0 0x00002000>; /* configuration space */
> > 
> > This doesn't look good, the conversion is lossy. The Linux driver
> > (drivers/pci/controller/dwc/pci-layerscape.c) knows the lut_offset by
> > compatible string, but the U-Boot driver
> > (drivers/pci/pcie_layerscape_rc.c)
> > calls fdt_get_named_resource("lut"). I.... don't think that the driver
> > works with a NULL pcie->lut pointer? The StreamID writes in
> > fdt_fixup_pcie_device_ls probably didn't explode because I don't have
> > any PCIe card plugged in.
> 
> I guess it didn't probe anyway, because there is no driver for that
> compatible string ;)

omg, "ls1028" vs "ls1028a" :-/

> > Similar thing for the PEX PF control memory region. In the LS1028A RM,
> > technically this is part of the larger PEX_LUT memory map, just starting
> > from the 4_0014h offset.
> > 
> > U-Boot has this piece of logic to deduce pcie->ctrl based on pcie->lut,
> > but it seems that it needs to be extended to cover LS1028A:
> 
> Only that one probably don't want to overwrite cfg_res.start and
> cfg_res.end.

My internal parser is broken by this phrase's syntax, but yes.

> > 	/*
> > 	 * Fix the pcie memory map address and PF control registers address
> > 	 * for LS2088A series SoCs
> > 	 */
> > 	svr = get_svr();
> > 	svr = (svr >> SVR_VAR_PER_SHIFT) & 0xFFFFFE;
> > 	if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
> > 	    svr == SVR_LS2048A || svr == SVR_LS2044A ||
> > 	    svr == SVR_LS2081A || svr == SVR_LS2041A) {
> > 		pcie_rc->cfg_res.start = LS2088A_PCIE1_PHYS_ADDR +
> > 					 LS2088A_PCIE_PHYS_SIZE * pcie->idx;
> > 		pcie_rc->cfg_res.end = pcie_rc->cfg_res.start + cfg_size;
> > 		pcie->ctrl = pcie->lut + 0x40000;
> > 	}
> 
> Oh the horror! Why didn't one just change the config register value in
> the (u-boot) device tree instead of overwriting the value for some
> specific SoCs.

Code added in commit 3d8553f0a3ee ("pci: layerscape: add LS2088A series
SoC pcie support"). As to why the differentiation between LS2080A and
LS2088A/LS2084A and the 4-core variants is done through code rather than
through DT, Zhiqiang said:

| There isn't LS2088A DT file, actually it reuse LS2080A DT file
| under u-boot, while under kernel there are DT files for LS2080A
| and LS2088A respectively with different PCIe node compatible
| string.

https://u-boot.denx.narkive.com/XVDnIKG9/patchv3-1-2-pci-layerscape-add-ls2088a-series-soc-pcie-support

Again, as to why that is, no clue whatsoever.

> 
> > As for pcie->lut itself, simplest would be to just default to what is
> > now the "dbi" reg value, plus a .lut_offset determined by compatible
> > string, in the case of "fsl,ls1028a-pcie" 0x80000, just like Linux.
> > 
> > Ah, and not to mention that the reg-names are not even the same between
> > U-Boot and Linux. What is "dbi" in U-Boot is "regs" in Linux :)
> 
> Well and there is a big-endian property, which of course is set for any
> Layerscape but the LS1028A. linux has instead just one endianess, but
> use a shift offset.

You lost me here. How are registers accessed with the right endianness
in Linux and in U-Boot?

> Mh, I'm for sure not going to fix all these hacks in there. I'm thinking
> about bascially branching to a different probe for the ls1028a based on
> the compatible string (or rather if .data is set or not).

Makes sense to introduce a driver data structure for LS1028A.
Michael Walle Sept. 6, 2021, 8:37 a.m. UTC | #17
Am 2021-09-01 23:59, schrieb Vladimir Oltean:
>> 
>> > As for pcie->lut itself, simplest would be to just default to what is
>> > now the "dbi" reg value, plus a .lut_offset determined by compatible
>> > string, in the case of "fsl,ls1028a-pcie" 0x80000, just like Linux.
>> >
>> > Ah, and not to mention that the reg-names are not even the same between
>> > U-Boot and Linux. What is "dbi" in U-Boot is "regs" in Linux :)
>> 
>> Well and there is a big-endian property, which of course is set for 
>> any
>> Layerscape but the LS1028A. linux has instead just one endianess, but
>> use a shift offset.
> 
> You lost me here. How are registers accessed with the right endianness
> in Linux and in U-Boot?

Of all the ctrl registers, Linux seems to just use the lut_dbg register
for link state detection (via the .lut_dbg offset). It uses the 
.ltssm_shift
property to shift the read value of this register. That property is
either 0 or 24, which I suspect is the same as converting the endianess
(ie. in u-boot).

-michael
diff mbox series

Patch

diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 69850fe7f2..343ecf0e89 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -1,12 +1,16 @@ 
-// SPDX-License-Identifier: GPL-2.0+ OR X11
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 /*
- * NXP ls1028a SOC common device tree source
+ * Device Tree Include file for NXP Layerscape-1028A family SoC.
  *
- * Copyright 2019-2020 NXP
+ * Copyright 2018-2020 NXP
+ *
+ * Harninder Rai <harninder.rai@nxp.com>
  *
  */
 
+#include <dt-bindings/clock/fsl,qoriq-clockgen.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/thermal/thermal.h>
 
 / {
 	compatible = "fsl,ls1028a";
@@ -14,6 +18,54 @@ 
 	#address-cells = <2>;
 	#size-cells = <2>;
 
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0x0>;
+			enable-method = "psci";
+			clocks = <&clockgen QORIQ_CLK_CMUX 0>;
+			next-level-cache = <&l2>;
+			cpu-idle-states = <&CPU_PW20>;
+			#cooling-cells = <2>;
+		};
+
+		cpu1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72";
+			reg = <0x1>;
+			enable-method = "psci";
+			clocks = <&clockgen QORIQ_CLK_CMUX 0>;
+			next-level-cache = <&l2>;
+			cpu-idle-states = <&CPU_PW20>;
+			#cooling-cells = <2>;
+		};
+
+		l2: l2-cache {
+			compatible = "cache";
+		};
+	};
+
+	idle-states {
+		/*
+		 * PSCI node is not added default, U-boot will add missing
+		 * parts if it determines to use PSCI.
+		 */
+		entry-method = "psci";
+
+		CPU_PW20: cpu-pw20 {
+			  compatible = "arm,idle-state";
+			  idle-state-name = "PW20";
+			  arm,psci-suspend-param = <0x0>;
+			  entry-latency-us = <2000>;
+			  exit-latency-us = <2000>;
+			  min-residency-us = <6000>;
+		};
+	};
+
 	sysclk: sysclk {
 		compatible = "fixed-clock";
 		#clock-cells = <0>;
@@ -21,14 +73,33 @@ 
 		clock-output-names = "sysclk";
 	};
 
-	gic: interrupt-controller@6000000 {
-		compatible = "arm,gic-v3";
-		reg = <0x0 0x06000000 0 0x10000>, /* GIC Dist */
-			  <0x0 0x06040000 0 0x40000>;
-		#interrupt-cells = <3>;
-		interrupt-controller;
-		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_RAW(0xf) |
-					 IRQ_TYPE_LEVEL_LOW)>;
+	osc_27m: clock-osc-27m {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <27000000>;
+		clock-output-names = "phy_27m";
+	};
+
+	dpclk: clock-controller@f1f0000 {
+		compatible = "fsl,ls1028a-plldig";
+		reg = <0x0 0xf1f0000 0x0 0xffff>;
+		#clock-cells = <0>;
+		clocks = <&osc_27m>;
+	};
+
+	firmware {
+		optee: optee  {
+			compatible = "linaro,optee-tz";
+			method = "smc";
+			status = "disabled";
+		};
+	};
+
+	reboot {
+		compatible ="syscon-reboot";
+		regmap = <&rst>;
+		offset = <0>;
+		mask = <0x02>;
 	};
 
 	timer {
@@ -43,177 +114,127 @@ 
 					  IRQ_TYPE_LEVEL_LOW)>;
 	};
 
-	soc: soc {
-		compatible = "simple-bus";
+	pmu {
+		compatible = "arm,cortex-a72-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gic: interrupt-controller@6000000 {
+		compatible= "arm,gic-v3";
 		#address-cells = <2>;
 		#size-cells = <2>;
 		ranges;
-
-		clockgen: clocking@1300000 {
-			compatible = "fsl,ls1028a-clockgen";
-			reg = <0x0 0x1300000 0x0 0xa0000>;
-			#clock-cells = <2>;
-			clocks = <&sysclk>;
+		reg= <0x0 0x06000000 0 0x10000>, /* GIC Dist */
+			<0x0 0x06040000 0 0x40000>; /* GIC Redistributor */
+		#interrupt-cells= <3>;
+		interrupt-controller;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_RAW(0xf) |
+					 IRQ_TYPE_LEVEL_LOW)>;
+		its: gic-its@6020000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			reg = <0x0 0x06020000 0 0x20000>;/* GIC Translater */
 		};
+	};
 
-		fspi: flexspi@20c0000 {
-			compatible = "nxp,lx2160a-fspi";
-			#address-cells = <1>;
-			#size-cells = <0>;
-			reg = <0x0 0x20c0000 0x0 0x10000>,
-				  <0x0 0x20000000 0x0 0x10000000>;
-			reg-names = "fspi_base", "fspi_mmap";
-			clocks = <&clockgen 4 3>, <&clockgen 4 3>;
-			clock-names = "fspi_en", "fspi";
-			interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
-			status = "disabled";
-		};
+	thermal-zones {
+		ddr-controller {
+			polling-delay-passive = <1000>;
+			polling-delay = <5000>;
+			thermal-sensors = <&tmu 0>;
 
-		duart0: serial@21c0500 {
-			device_type = "serial";
-			compatible = "fsl,ns16550", "ns16550a";
-			reg = <0x0 0x21c0500 0x0 0x100>;
-			interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
-			status = "disabled";
-		};
+			trips {
+				ddr-ctrler-alert {
+					temperature = <85000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
 
-		duart1: serial@21c0600 {
-			device_type = "serial";
-			compatible = "fsl,ns16550", "ns16550a";
-			reg = <0x0 0x21c0600 0x0 0x100>;
-			interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
-			status = "disabled";
+				ddr-ctrler-crit {
+					temperature = <95000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
 		};
 
-		pcie1: pcie@3400000 {
-			   compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", "snps,dw-pcie";
-			   reg = <0x00 0x03400000 0x0 0x80000
-				   0x00 0x03480000 0x0 0x40000   /* lut registers */
-				   0x00 0x034c0000 0x0 0x40000  /* pf controls registers */
-				   0x80 0x00000000 0x0 0x20000>; /* configuration space */
-			   reg-names = "dbi", "lut", "ctrl", "config";
-			   #address-cells = <3>;
-			   #size-cells = <2>;
-			   device_type = "pci";
-			   num-lanes = <4>;
-			   bus-range = <0x0 0xff>;
-			   ranges = <0x81000000 0x0 0x00000000 0x80 0x00020000 0x0 0x00010000   /* downstream I/O */
-				   0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
-		};
+		core-cluster {
+			polling-delay-passive = <1000>;
+			polling-delay = <5000>;
+			thermal-sensors = <&tmu 1>;
 
-		pcie2: pcie@3500000 {
-			   compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", "snps,dw-pcie";
-			   reg = <0x00 0x03500000 0x0 0x80000
-				   0x00 0x03580000 0x0 0x40000   /* lut registers */
-				   0x00 0x035c0000 0x0 0x40000  /* pf controls registers */
-				   0x88 0x00000000 0x0 0x20000>; /* configuration space */
-			   reg-names = "dbi", "lut", "ctrl", "config";
-			   #address-cells = <3>;
-			   #size-cells = <2>;
-			   device_type = "pci";
-			   num-lanes = <4>;
-			   bus-range = <0x0 0xff>;
-			   ranges = <0x81000000 0x0 0x00000000 0x88 0x00020000 0x0 0x00010000   /* downstream I/O */
-				   0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
-		};
-
-		pcie@1f0000000 {
-			compatible = "pci-host-ecam-generic";
-			/* ECAM bus 0, HW has more space reserved but not populated */
-			bus-range = <0x0 0x0>;
-			reg = <0x01 0xf0000000 0x0 0x100000>;
-			#address-cells = <3>;
-			#size-cells = <2>;
-			device_type = "pci";
-			ranges= <0x82000000 0x0 0x00000000 0x1 0xf8000000 0x0 0x160000>;
-			enetc_port0: pci@0,0 {
-				reg = <0x000000 0 0 0 0>;
-				status = "disabled";
-			};
-			enetc_port1: pci@0,1 {
-				reg = <0x000100 0 0 0 0>;
-				status = "disabled";
-			};
-			enetc_port2: pci@0,2 {
-				reg = <0x000200 0 0 0 0>;
-				status = "disabled";
-				phy-mode = "internal";
+			trips {
+				core_cluster_alert: core-cluster-alert {
+					temperature = <85000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
 
-				fixed-link {
-					speed = <2500>;
-					full-duplex;
+				core_cluster_crit: core-cluster-crit {
+					temperature = <95000>;
+					hysteresis = <2000>;
+					type = "critical";
 				};
 			};
-			enetc_mdio_pf3: pci@0,3 {
-				#address-cells=<0>;
-				#size-cells=<1>;
-				reg = <0x000300 0 0 0 0>;
-				status = "disabled";
 
-				fixed-link {
-					speed = <1000>;
-					full-duplex;
+			cooling-maps {
+				map0 {
+					trip = <&core_cluster_alert>;
+					cooling-device =
+						<&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						<&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
 				};
 			};
+		};
+	};
 
-			mscc_felix: pci@0,5 {
-				reg = <0x000500 0 0 0 0>;
-				status = "disabled";
-
-				ports {
-					#address-cells = <1>;
-					#size-cells = <0>;
-
-					mscc_felix_port0: port@0 {
-						reg = <0>;
-						status = "disabled";
-					};
-
-					mscc_felix_port1: port@1 {
-						reg = <1>;
-						status = "disabled";
-					};
-
-					mscc_felix_port2: port@2 {
-						reg = <2>;
-						status = "disabled";
-					};
-
-					mscc_felix_port3: port@3 {
-						reg = <3>;
-						status = "disabled";
-					};
+	soc: soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
 
-					mscc_felix_port4: port@4 {
-						reg = <4>;
-						phy-mode = "internal";
-						status = "disabled";
+		ddr: memory-controller@1080000 {
+			compatible = "fsl,qoriq-memory-controller";
+			reg = <0x0 0x1080000 0x0 0x1000>;
+			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+			little-endian;
+		};
 
-						fixed-link {
-							speed = <2500>;
-							full-duplex;
-						};
-					};
+		dcfg: syscon@1e00000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "fsl,ls1028a-dcfg", "syscon", "simple-mfd";
+			reg = <0x0 0x1e00000 0x0 0x10000>;
+			ranges = <0x0 0x0 0x1e00000 0x10000>;
+			little-endian;
 
-					mscc_felix_port5: port@5 {
-						reg = <5>;
-						phy-mode = "internal";
-						status = "disabled";
+			fspi_clk: clock-controller@900 {
+				compatible = "fsl,ls1028a-flexspi-clk";
+				reg = <0x900 0x4>;
+				#clock-cells = <0>;
+				clocks = <&clockgen QORIQ_CLK_HWACCEL 0>;
+				clock-output-names = "fspi_clk";
+			};
+		};
 
-						fixed-link {
-							speed = <1000>;
-							full-duplex;
-						};
+		rst: syscon@1e60000 {
+			compatible = "syscon";
+			reg = <0x0 0x1e60000 0x0 0x10000>;
+			little-endian;
+		};
 
-					};
-				};
-			};
+		scfg: syscon@1fc0000 {
+			compatible = "fsl,ls1028a-scfg", "syscon";
+			reg = <0x0 0x1fc0000 0x0 0x10000>;
+			big-endian;
+		};
 
-			enetc_port3: pci@0,6 {
-				reg = <0x000600 0 0 0 0>;
-				status = "disabled";
-				phy-mode = "internal";
-			};
+		clockgen: clock-controller@1300000 {
+			compatible = "fsl,ls1028a-clockgen";
+			reg = <0x0 0x1300000 0x0 0xa0000>;
+			#clock-cells = <2>;
+			clocks = <&sysclk>;
 		};
 
 		i2c0: i2c@2000000 {
@@ -222,8 +243,8 @@ 
 			#size-cells = <0>;
 			reg = <0x0 0x2000000 0x0 0x10000>;
 			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
-			clock-names = "i2c";
-			clocks = <&clockgen 4 0>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(4)>;
 			status = "disabled";
 		};
 
@@ -233,8 +254,8 @@ 
 			#size-cells = <0>;
 			reg = <0x0 0x2010000 0x0 0x10000>;
 			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
-			clock-names = "i2c";
-			clocks = <&clockgen 4 0>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(4)>;
 			status = "disabled";
 		};
 
@@ -244,8 +265,8 @@ 
 			#size-cells = <0>;
 			reg = <0x0 0x2020000 0x0 0x10000>;
 			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
-			clock-names = "i2c";
-			clocks = <&clockgen 4 0>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(4)>;
 			status = "disabled";
 		};
 
@@ -255,8 +276,8 @@ 
 			#size-cells = <0>;
 			reg = <0x0 0x2030000 0x0 0x10000>;
 			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
-			clock-names = "i2c";
-			clocks = <&clockgen 4 0>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(4)>;
 			status = "disabled";
 		};
 
@@ -266,8 +287,8 @@ 
 			#size-cells = <0>;
 			reg = <0x0 0x2040000 0x0 0x10000>;
 			interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
-			clock-names = "i2c";
-			clocks = <&clockgen 4 0>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(4)>;
 			status = "disabled";
 		};
 
@@ -277,8 +298,8 @@ 
 			#size-cells = <0>;
 			reg = <0x0 0x2050000 0x0 0x10000>;
 			interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
-			clock-names = "i2c";
-			clocks = <&clockgen 4 0>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(4)>;
 			status = "disabled";
 		};
 
@@ -288,8 +309,8 @@ 
 			#size-cells = <0>;
 			reg = <0x0 0x2060000 0x0 0x10000>;
 			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
-			clock-names = "i2c";
-			clocks = <&clockgen 4 0>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(4)>;
 			status = "disabled";
 		};
 
@@ -299,145 +320,237 @@ 
 			#size-cells = <0>;
 			reg = <0x0 0x2070000 0x0 0x10000>;
 			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
-			clock-names = "i2c";
-			clocks = <&clockgen 4 0>;
-			status = "disabled";
-		};
-
-		lpuart0: serial@2260000 {
-			compatible = "fsl,ls1028a-lpuart";
-			reg = <0x0 0x2260000 0x0 0x1000>;
-			interrupts = <0 232 0x4>;
-			clocks = <&sysclk>;
-			clock-names = "ipg";
-			little-endian;
-			status = "disabled";
-		};
-
-		lpuart1: serial@2270000 {
-			compatible = "fsl,ls1028a-lpuart";
-			reg = <0x0 0x2270000 0x0 0x1000>;
-			interrupts = <0 233 0x4>;
-			clocks = <&sysclk>;
-			clock-names = "ipg";
-			little-endian;
-			status = "disabled";
-		};
-
-		lpuart2: serial@2280000 {
-			compatible = "fsl,ls1028a-lpuart";
-			reg = <0x0 0x2280000 0x0 0x1000>;
-			interrupts = <0 234 0x4>;
-			clocks = <&sysclk>;
-			clock-names = "ipg";
-			little-endian;
-			status = "disabled";
-		};
-
-		lpuart3: serial@2290000 {
-			compatible = "fsl,ls1028a-lpuart";
-			reg = <0x0 0x2290000 0x0 0x1000>;
-			interrupts = <0 235 0x4>;
-			clocks = <&sysclk>;
-			clock-names = "ipg";
-			little-endian;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(4)>;
 			status = "disabled";
 		};
 
-		lpuart4: serial@22a0000 {
-			compatible = "fsl,ls1028a-lpuart";
-			reg = <0x0 0x22a0000 0x0 0x1000>;
-			interrupts = <0 236 0x4>;
-			clocks = <&sysclk>;
-			clock-names = "ipg";
-			little-endian;
-			status = "disabled";
-		};
-
-		lpuart5: serial@22b0000 {
-			compatible = "fsl,ls1028a-lpuart";
-			reg = <0x0 0x22b0000 0x0 0x1000>;
-			interrupts = <0 237 0x4>;
-			clocks = <&sysclk>;
-			clock-names = "ipg";
-			little-endian;
-			status = "disabled";
-		};
-
-		usb0: usb3@3100000 {
-			compatible = "fsl,layerscape-dwc3";
-			reg = <0x0 0x3100000 0x0 0x10000>;
-			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
-			dr_mode = "host";
-			status = "disabled";
-		};
-
-		usb1: usb3@3110000 {
-			compatible = "fsl,layerscape-dwc3";
-			reg = <0x0 0x3110000 0x0 0x10000>;
-			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
-			dr_mode = "host";
+		fspi: spi@20c0000 {
+			compatible = "nxp,lx2160a-fspi";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0 0x20c0000 0x0 0x10000>,
+			      <0x0 0x20000000 0x0 0x10000000>;
+			reg-names = "fspi_base", "fspi_mmap";
+			interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&fspi_clk>, <&fspi_clk>;
+			clock-names = "fspi_en", "fspi";
 			status = "disabled";
 		};
 
-		dspi0: dspi@2100000 {
+		dspi0: spi@2100000 {
 			compatible = "fsl,ls1028a-dspi", "fsl,ls1021a-v1.0-dspi";
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0x0 0x2100000 0x0 0x10000>;
 			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
 			clock-names = "dspi";
-			clocks = <&clockgen 4 0>;
-			num-cs = <5>;
-			litte-endian;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			dmas = <&edma0 0 62>, <&edma0 0 60>;
+			dma-names = "tx", "rx";
+			spi-num-chipselects = <4>;
+			little-endian;
 			status = "disabled";
 		};
 
-		dspi1: dspi@2110000 {
+		dspi1: spi@2110000 {
 			compatible = "fsl,ls1028a-dspi", "fsl,ls1021a-v1.0-dspi";
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0x0 0x2110000 0x0 0x10000>;
 			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
 			clock-names = "dspi";
-			clocks = <&clockgen 4 0>;
-			num-cs = <5>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			dmas = <&edma0 0 58>, <&edma0 0 56>;
+			dma-names = "tx", "rx";
+			spi-num-chipselects = <4>;
 			little-endian;
 			status = "disabled";
 		};
 
-		dspi2: dspi@2120000 {
+		dspi2: spi@2120000 {
 			compatible = "fsl,ls1028a-dspi", "fsl,ls1021a-v1.0-dspi";
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0x0 0x2120000 0x0 0x10000>;
 			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
 			clock-names = "dspi";
-			clocks = <&clockgen 4 0>;
-			num-cs = <5>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			dmas = <&edma0 0 54>, <&edma0 0 2>;
+			dma-names = "tx", "rx";
+			spi-num-chipselects = <3>;
 			little-endian;
 			status = "disabled";
 		};
 
-		esdhc: esdhc@2140000 {
-			compatible = "fsl,esdhc";
+		esdhc: mmc@2140000 {
+			compatible = "fsl,ls1028a-esdhc", "fsl,esdhc";
 			reg = <0x0 0x2140000 0x0 0x10000>;
 			interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
-			big-endian;
+			clock-frequency = <0>; /* fixed up by bootloader */
+			clocks = <&clockgen QORIQ_CLK_HWACCEL 1>;
+			voltage-ranges = <1800 1800 3300 3300>;
+			sdhci,auto-cmd12;
+			little-endian;
 			bus-width = <4>;
 			status = "disabled";
 		};
 
-		esdhc1: esdhc@2150000 {
-			compatible = "fsl,esdhc";
+		esdhc1: mmc@2150000 {
+			compatible = "fsl,ls1028a-esdhc", "fsl,esdhc";
 			reg = <0x0 0x2150000 0x0 0x10000>;
 			interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
-			big-endian;
-			non-removable;
+			clock-frequency = <0>; /* fixed up by bootloader */
+			clocks = <&clockgen QORIQ_CLK_HWACCEL 1>;
+			voltage-ranges = <1800 1800 3300 3300>;
+			sdhci,auto-cmd12;
+			broken-cd;
+			little-endian;
 			bus-width = <4>;
 			status = "disabled";
 		};
 
+		can0: can@2180000 {
+			compatible = "fsl,lx2160ar1-flexcan";
+			reg = <0x0 0x2180000 0x0 0x10000>;
+			interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "ipg", "per";
+			status = "disabled";
+		};
+
+		can1: can@2190000 {
+			compatible = "fsl,lx2160ar1-flexcan";
+			reg = <0x0 0x2190000 0x0 0x10000>;
+			interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "ipg", "per";
+			status = "disabled";
+		};
+
+		duart0: serial@21c0500 {
+			compatible = "fsl,ns16550", "ns16550a";
+			reg = <0x00 0x21c0500 0x0 0x100>;
+			interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			status = "disabled";
+		};
+
+		duart1: serial@21c0600 {
+			compatible = "fsl,ns16550", "ns16550a";
+			reg = <0x00 0x21c0600 0x0 0x100>;
+			interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			status = "disabled";
+		};
+
+
+		lpuart0: serial@2260000 {
+			compatible = "fsl,ls1028a-lpuart";
+			reg = <0x0 0x2260000 0x0 0x1000>;
+			interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "ipg";
+			dma-names = "rx","tx";
+			dmas = <&edma0 1 32>,
+			       <&edma0 1 33>;
+			status = "disabled";
+		};
+
+		lpuart1: serial@2270000 {
+			compatible = "fsl,ls1028a-lpuart";
+			reg = <0x0 0x2270000 0x0 0x1000>;
+			interrupts = <GIC_SPI 233 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "ipg";
+			dma-names = "rx","tx";
+			dmas = <&edma0 1 30>,
+			       <&edma0 1 31>;
+			status = "disabled";
+		};
+
+		lpuart2: serial@2280000 {
+			compatible = "fsl,ls1028a-lpuart";
+			reg = <0x0 0x2280000 0x0 0x1000>;
+			interrupts = <GIC_SPI 234 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "ipg";
+			dma-names = "rx","tx";
+			dmas = <&edma0 1 28>,
+			       <&edma0 1 29>;
+			status = "disabled";
+		};
+
+		lpuart3: serial@2290000 {
+			compatible = "fsl,ls1028a-lpuart";
+			reg = <0x0 0x2290000 0x0 0x1000>;
+			interrupts = <GIC_SPI 235 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "ipg";
+			dma-names = "rx","tx";
+			dmas = <&edma0 1 26>,
+			       <&edma0 1 27>;
+			status = "disabled";
+		};
+
+		lpuart4: serial@22a0000 {
+			compatible = "fsl,ls1028a-lpuart";
+			reg = <0x0 0x22a0000 0x0 0x1000>;
+			interrupts = <GIC_SPI 236 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "ipg";
+			dma-names = "rx","tx";
+			dmas = <&edma0 1 24>,
+			       <&edma0 1 25>;
+			status = "disabled";
+		};
+
+		lpuart5: serial@22b0000 {
+			compatible = "fsl,ls1028a-lpuart";
+			reg = <0x0 0x22b0000 0x0 0x1000>;
+			interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "ipg";
+			dma-names = "rx","tx";
+			dmas = <&edma0 1 22>,
+			       <&edma0 1 23>;
+			status = "disabled";
+		};
+
+		edma0: dma-controller@22c0000 {
+			#dma-cells = <2>;
+			compatible = "fsl,ls1028a-edma", "fsl,vf610-edma";
+			reg = <0x0 0x22c0000 0x0 0x10000>,
+			      <0x0 0x22d0000 0x0 0x10000>,
+			      <0x0 0x22e0000 0x0 0x10000>;
+			interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "edma-tx", "edma-err";
+			dma-channels = <32>;
+			clock-names = "dmamux0", "dmamux1";
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+		};
+
 		gpio1: gpio@2300000 {
 			compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
 			reg = <0x0 0x2300000 0x0 0x10000>;
@@ -471,18 +584,579 @@ 
 			little-endian;
 		};
 
+		usb0: usb@3100000 {
+			compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
+			reg = <0x0 0x3100000 0x0 0x10000>;
+			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+			dr_mode = "host";
+			snps,dis_rxdet_inp3_quirk;
+			snps,quirk-frame-length-adjustment = <0x20>;
+			snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
+		};
+
+		usb1: usb@3110000 {
+			compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
+			reg = <0x0 0x3110000 0x0 0x10000>;
+			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+			dr_mode = "host";
+			snps,dis_rxdet_inp3_quirk;
+			snps,quirk-frame-length-adjustment = <0x20>;
+			snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
+		};
+
 		sata: sata@3200000 {
 			compatible = "fsl,ls1028a-ahci";
-			reg = <0x0 0x3200000 0x0 0x10000	/* ccsr sata base */
-				   0x7 0x100520  0x0 0x4>;		/* ecc sata addr*/
-			reg-names = "sata-base", "ecc-addr";
+			reg = <0x0 0x3200000 0x0 0x10000>,
+				<0x7 0x100520 0x0 0x4>;
+			reg-names = "ahci", "sata-ecc";
 			interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			status = "disabled";
+		};
+
+		pcie1: pcie@3400000 {
+			compatible = "fsl,ls1028a-pcie";
+			reg = <0x00 0x03400000 0x0 0x00100000>, /* controller registers */
+			      <0x80 0x00000000 0x0 0x00002000>; /* configuration space */
+			reg-names = "regs", "config";
+			interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
+				     <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>; /* aer interrupt */
+			interrupt-names = "pme", "aer";
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			dma-coherent;
+			num-viewport = <8>;
+			bus-range = <0x0 0xff>;
+			ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000   /* downstream I/O */
+				  0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+			msi-parent = <&its>;
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 7>;
+			interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 2 &gic 0 0 GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 3 &gic 0 0 GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 4 &gic 0 0 GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+			iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
 			status = "disabled";
 		};
 
-		cluster1_core0_watchdog: wdt@c000000 {
+		pcie2: pcie@3500000 {
+			compatible = "fsl,ls1028a-pcie";
+			reg = <0x00 0x03500000 0x0 0x00100000>, /* controller registers */
+			      <0x88 0x00000000 0x0 0x00002000>; /* configuration space */
+			reg-names = "regs", "config";
+			interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "pme", "aer";
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			dma-coherent;
+			num-viewport = <8>;
+			bus-range = <0x0 0xff>;
+			ranges = <0x81000000 0x0 0x00000000 0x88 0x00010000 0x0 0x00010000   /* downstream I/O */
+				  0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+			msi-parent = <&its>;
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 7>;
+			interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 2 &gic 0 0 GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 3 &gic 0 0 GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 4 &gic 0 0 GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+			iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+			status = "disabled";
+		};
+
+		smmu: iommu@5000000 {
+			compatible = "arm,mmu-500";
+			reg = <0 0x5000000 0 0x800000>;
+			#global-interrupts = <8>;
+			#iommu-cells = <1>;
+			stream-match-mask = <0x7c00>;
+			/* global secure fault */
+			interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			/* combined secure interrupt */
+				     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			/* global non-secure fault */
+				     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+			/* combined non-secure interrupt */
+				     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			/* performance counter interrupts 0-7 */
+				     <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
+			/* per context interrupt, 64 interrupts */
+				     <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		crypto: crypto@8000000 {
+			compatible = "fsl,sec-v5.0", "fsl,sec-v4.0";
+			fsl,sec-era = <10>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x0 0x00 0x8000000 0x100000>;
+			reg = <0x00 0x8000000 0x0 0x100000>;
+			interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
+			dma-coherent;
+
+			sec_jr0: jr@10000 {
+				compatible = "fsl,sec-v5.0-job-ring",
+					     "fsl,sec-v4.0-job-ring";
+				reg	= <0x10000 0x10000>;
+				interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			sec_jr1: jr@20000 {
+				compatible = "fsl,sec-v5.0-job-ring",
+					     "fsl,sec-v4.0-job-ring";
+				reg	= <0x20000 0x10000>;
+				interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			sec_jr2: jr@30000 {
+				compatible = "fsl,sec-v5.0-job-ring",
+					     "fsl,sec-v4.0-job-ring";
+				reg	= <0x30000 0x10000>;
+				interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			sec_jr3: jr@40000 {
+				compatible = "fsl,sec-v5.0-job-ring",
+					     "fsl,sec-v4.0-job-ring";
+				reg	= <0x40000 0x10000>;
+				interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+			};
+		};
+
+		qdma: dma-controller@8380000 {
+			compatible = "fsl,ls1028a-qdma", "fsl,ls1021a-qdma";
+			reg = <0x0 0x8380000 0x0 0x1000>, /* Controller regs */
+			      <0x0 0x8390000 0x0 0x10000>, /* Status regs */
+			      <0x0 0x83a0000 0x0 0x40000>; /* Block regs */
+			interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 251 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 252 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 253 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 254 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "qdma-error", "qdma-queue0",
+				"qdma-queue1", "qdma-queue2", "qdma-queue3";
+			dma-channels = <8>;
+			block-number = <1>;
+			block-offset = <0x10000>;
+			fsl,dma-queues = <2>;
+			status-sizes = <64>;
+			queue-sizes = <64 64>;
+		};
+
+		cluster1_core0_watchdog: watchdog@c000000 {
 			compatible = "arm,sp805", "arm,primecell";
 			reg = <0x0 0xc000000 0x0 0x1000>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(16)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(16)>;
+			clock-names = "wdog_clk", "apb_pclk";
+		};
+
+		cluster1_core1_watchdog: watchdog@c010000 {
+			compatible = "arm,sp805", "arm,primecell";
+			reg = <0x0 0xc010000 0x0 0x1000>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(16)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(16)>;
+			clock-names = "wdog_clk", "apb_pclk";
+		};
+
+		sai1: audio-controller@f100000 {
+			#sound-dai-cells = <0>;
+			compatible = "fsl,vf610-sai";
+			reg = <0x0 0xf100000 0x0 0x10000>;
+			interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "bus", "mclk1", "mclk2", "mclk3";
+			dma-names = "tx", "rx";
+			dmas = <&edma0 1 4>,
+			       <&edma0 1 3>;
+			fsl,sai-asynchronous;
+			status = "disabled";
+		};
+
+		sai2: audio-controller@f110000 {
+			#sound-dai-cells = <0>;
+			compatible = "fsl,vf610-sai";
+			reg = <0x0 0xf110000 0x0 0x10000>;
+			interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "bus", "mclk1", "mclk2", "mclk3";
+			dma-names = "tx", "rx";
+			dmas = <&edma0 1 6>,
+			       <&edma0 1 5>;
+			fsl,sai-asynchronous;
+			status = "disabled";
+		};
+
+		sai3: audio-controller@f120000 {
+			#sound-dai-cells = <0>;
+			compatible = "fsl,vf610-sai";
+			reg = <0x0 0xf120000 0x0 0x10000>;
+			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "bus", "mclk1", "mclk2", "mclk3";
+			dma-names = "tx", "rx";
+			dmas = <&edma0 1 8>,
+			       <&edma0 1 7>;
+			fsl,sai-asynchronous;
+			status = "disabled";
+		};
+
+		sai4: audio-controller@f130000 {
+			#sound-dai-cells = <0>;
+			compatible = "fsl,vf610-sai";
+			reg = <0x0 0xf130000 0x0 0x10000>;
+			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "bus", "mclk1", "mclk2", "mclk3";
+			dma-names = "tx", "rx";
+			dmas = <&edma0 1 10>,
+			       <&edma0 1 9>;
+			fsl,sai-asynchronous;
+			status = "disabled";
+		};
+
+		sai5: audio-controller@f140000 {
+			#sound-dai-cells = <0>;
+			compatible = "fsl,vf610-sai";
+			reg = <0x0 0xf140000 0x0 0x10000>;
+			interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "bus", "mclk1", "mclk2", "mclk3";
+			dma-names = "tx", "rx";
+			dmas = <&edma0 1 12>,
+			       <&edma0 1 11>;
+			fsl,sai-asynchronous;
+			status = "disabled";
+		};
+
+		sai6: audio-controller@f150000 {
+			#sound-dai-cells = <0>;
+			compatible = "fsl,vf610-sai";
+			reg = <0x0 0xf150000 0x0 0x10000>;
+			interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>,
+				 <&clockgen QORIQ_CLK_PLATFORM_PLL
+					    QORIQ_CLK_PLL_DIV(2)>;
+			clock-names = "bus", "mclk1", "mclk2", "mclk3";
+			dma-names = "tx", "rx";
+			dmas = <&edma0 1 14>,
+			       <&edma0 1 13>;
+			fsl,sai-asynchronous;
+			status = "disabled";
+		};
+
+		tmu: tmu@1f80000 {
+			compatible = "fsl,qoriq-tmu";
+			reg = <0x0 0x1f80000 0x0 0x10000>;
+			interrupts = <0 23 0x4>;
+			fsl,tmu-range = <0xb0000 0xa0026 0x80048 0x70061>;
+			fsl,tmu-calibration = <0x00000000 0x00000024
+					       0x00000001 0x0000002b
+					       0x00000002 0x00000031
+					       0x00000003 0x00000038
+					       0x00000004 0x0000003f
+					       0x00000005 0x00000045
+					       0x00000006 0x0000004c
+					       0x00000007 0x00000053
+					       0x00000008 0x00000059
+					       0x00000009 0x00000060
+					       0x0000000a 0x00000066
+					       0x0000000b 0x0000006d
+
+					       0x00010000 0x0000001c
+					       0x00010001 0x00000024
+					       0x00010002 0x0000002c
+					       0x00010003 0x00000035
+					       0x00010004 0x0000003d
+					       0x00010005 0x00000045
+					       0x00010006 0x0000004d
+					       0x00010007 0x00000055
+					       0x00010008 0x0000005e
+					       0x00010009 0x00000066
+					       0x0001000a 0x0000006e
+
+					       0x00020000 0x00000018
+					       0x00020001 0x00000022
+					       0x00020002 0x0000002d
+					       0x00020003 0x00000038
+					       0x00020004 0x00000043
+					       0x00020005 0x0000004d
+					       0x00020006 0x00000058
+					       0x00020007 0x00000063
+					       0x00020008 0x0000006e
+
+					       0x00030000 0x00000010
+					       0x00030001 0x0000001c
+					       0x00030002 0x00000029
+					       0x00030003 0x00000036
+					       0x00030004 0x00000042
+					       0x00030005 0x0000004f
+					       0x00030006 0x0000005b
+					       0x00030007 0x00000068>;
+			little-endian;
+			#thermal-sensor-cells = <1>;
+		};
+
+		pcie@1f0000000 { /* Integrated Endpoint Root Complex */
+			compatible = "pci-host-ecam-generic";
+			reg = <0x01 0xf0000000 0x0 0x100000>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			msi-parent = <&its>;
+			device_type = "pci";
+			bus-range = <0x0 0x0>;
+			dma-coherent;
+			msi-map = <0 &its 0x17 0xe>;
+			iommu-map = <0 &smmu 0x17 0xe>;
+				  /* PF0-6 BAR0 - non-prefetchable memory */
+			ranges = <0x82000000 0x1 0xf8000000  0x1 0xf8000000  0x0 0x160000
+				  /* PF0-6 BAR2 - prefetchable memory */
+				  0xc2000000 0x1 0xf8160000  0x1 0xf8160000  0x0 0x070000
+				  /* PF0: VF0-1 BAR0 - non-prefetchable memory */
+				  0x82000000 0x1 0xf81d0000  0x1 0xf81d0000  0x0 0x020000
+				  /* PF0: VF0-1 BAR2 - prefetchable memory */
+				  0xc2000000 0x1 0xf81f0000  0x1 0xf81f0000  0x0 0x020000
+				  /* PF1: VF0-1 BAR0 - non-prefetchable memory */
+				  0x82000000 0x1 0xf8210000  0x1 0xf8210000  0x0 0x020000
+				  /* PF1: VF0-1 BAR2 - prefetchable memory */
+				  0xc2000000 0x1 0xf8230000  0x1 0xf8230000  0x0 0x020000
+				  /* BAR4 (PF5) - non-prefetchable memory */
+				  0x82000000 0x1 0xfc000000  0x1 0xfc000000  0x0 0x400000>;
+
+			enetc_port0: ethernet@0,0 {
+				compatible = "fsl,enetc";
+				reg = <0x000000 0 0 0 0>;
+				status = "disabled";
+			};
+
+			enetc_port1: ethernet@0,1 {
+				compatible = "fsl,enetc";
+				reg = <0x000100 0 0 0 0>;
+				status = "disabled";
+			};
+
+			enetc_port2: ethernet@0,2 {
+				compatible = "fsl,enetc";
+				reg = <0x000200 0 0 0 0>;
+				phy-mode = "internal";
+				status = "disabled";
+
+				fixed-link {
+					speed = <2500>;
+					full-duplex;
+				};
+			};
+
+			enetc_mdio_pf3: mdio@0,3 {
+				compatible = "fsl,enetc-mdio";
+				reg = <0x000300 0 0 0 0>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
+
+			ethernet@0,4 {
+				compatible = "fsl,enetc-ptp";
+				reg = <0x000400 0 0 0 0>;
+				clocks = <&clockgen QORIQ_CLK_HWACCEL 3>;
+				little-endian;
+				fsl,extts-fifo;
+			};
+
+			mscc_felix: ethernet-switch@0,5 {
+				reg = <0x000500 0 0 0 0>;
+				/* IEP INT_B */
+				interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+				status = "disabled";
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					/* External ports */
+					mscc_felix_port0: port@0 {
+						reg = <0>;
+						status = "disabled";
+					};
+
+					mscc_felix_port1: port@1 {
+						reg = <1>;
+						status = "disabled";
+					};
+
+					mscc_felix_port2: port@2 {
+						reg = <2>;
+						status = "disabled";
+					};
+
+					mscc_felix_port3: port@3 {
+						reg = <3>;
+						status = "disabled";
+					};
+
+					/* Internal ports */
+					mscc_felix_port4: port@4 {
+						reg = <4>;
+						phy-mode = "internal";
+						status = "disabled";
+
+						fixed-link {
+							speed = <2500>;
+							full-duplex;
+						};
+					};
+
+					mscc_felix_port5: port@5 {
+						reg = <5>;
+						phy-mode = "internal";
+						status = "disabled";
+
+						fixed-link {
+							speed = <1000>;
+							full-duplex;
+						};
+					};
+				};
+			};
+
+			enetc_port3: ethernet@0,6 {
+				compatible = "fsl,enetc";
+				reg = <0x000600 0 0 0 0>;
+				phy-mode = "internal";
+				status = "disabled";
+
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+
+			rcec@1f,0 {
+				reg = <0x00f800 0 0 0 0>;
+				/* IEP INT_A */
+				interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+			};
+		};
+
+		/* Integrated Endpoint Register Block */
+		ierb@1f0800000 {
+			compatible = "fsl,ls1028a-enetc-ierb";
+			reg = <0x01 0xf0800000 0x0 0x10000>;
+		};
+
+		rcpm: power-controller@1e34040 {
+			compatible = "fsl,ls1028a-rcpm", "fsl,qoriq-rcpm-2.1+";
+			reg = <0x0 0x1e34040 0x0 0x1c>;
+			#fsl,rcpm-wakeup-cells = <7>;
+			little-endian;
+		};
+
+		ftm_alarm0: timer@2800000 {
+			compatible = "fsl,ls1028a-ftm-alarm";
+			reg = <0x0 0x2800000 0x0 0x10000>;
+			fsl,rcpm-wakeup = <&rcpm 0x0 0x0 0x0 0x0 0x4000 0x0 0x0>;
+			interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+		};
+	};
+
+	malidp0: display@f080000 {
+		compatible = "arm,mali-dp500";
+		reg = <0x0 0xf080000 0x0 0x10000>;
+		interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 223 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "DE", "SE";
+		clocks = <&dpclk>,
+			 <&clockgen QORIQ_CLK_HWACCEL 2>,
+			 <&clockgen QORIQ_CLK_HWACCEL 2>,
+			 <&clockgen QORIQ_CLK_HWACCEL 2>;
+		clock-names = "pxlclk", "mclk", "aclk", "pclk";
+		arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
+		arm,malidp-arqos-value = <0xd000d000>;
+
+		port {
+			dp0_out: endpoint {
+
+			};
 		};
 	};
 };
diff --git a/include/dt-bindings/clock/fsl,qoriq-clockgen.h b/include/dt-bindings/clock/fsl,qoriq-clockgen.h
new file mode 100644
index 0000000000..ddec7d0bdc
--- /dev/null
+++ b/include/dt-bindings/clock/fsl,qoriq-clockgen.h
@@ -0,0 +1,15 @@ 
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef DT_CLOCK_FSL_QORIQ_CLOCKGEN_H
+#define DT_CLOCK_FSL_QORIQ_CLOCKGEN_H
+
+#define QORIQ_CLK_SYSCLK	0
+#define QORIQ_CLK_CMUX		1
+#define QORIQ_CLK_HWACCEL	2
+#define QORIQ_CLK_FMAN		3
+#define QORIQ_CLK_PLATFORM_PLL	4
+#define QORIQ_CLK_CORECLK	5
+
+#define QORIQ_CLK_PLL_DIV(x)	((x) - 1)
+
+#endif /* DT_CLOCK_FSL_QORIQ_CLOCKGEN_H */