All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Michael Walle <michael@walle.cc>,
	Priyanka Jain <priyanka.jain@nxp.com>,
	u-boot@lists.denx.de, heiko.thiery@gmail.com
Subject: Re: incompatible device trees between u-boot and linux
Date: Wed, 25 Aug 2021 10:26:10 -0400	[thread overview]
Message-ID: <20210825142610.GU858@bill-the-cat> (raw)
In-Reply-To: <20210825141816.qfn25xlech55rwsg@skbuf>

[-- Attachment #1: Type: text/plain, Size: 11208 bytes --]

On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote:
> On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote:
> > On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote:
> >
> > > Hi,
> > >
> > > I noticed that there is a fallback to the u-boot device tree for linux
> > > (esp. EFI boot) if no other device tree was found, see [1]. It seems this
> > > is working fine for imx devices, for example, where you can just boot a
> > > stock installer iso via EFI. It will just work and it is quite a nice
> > > feature as a fallback.
> > >
> > > Now for the layerscape architecture, the ls1028a in my case, things are
> > > more difficult because the bindings differ between u-boot and linux - one
> > > which comes to mind is DSA and ethernet.
> > >
> > > Which begs the general question, is it encouraged to have both bindings
> > > diverge? To me it seems, that most bindings in u-boot are ad-hoc and there
> > > is no real review or alignment but just added as needed, which is ok if
> > > they are local to u-boot. But since they are nowadays passed to linux
> > > (by default!) I'm not so sure anymore.
> > >
> > > OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like
> > > they should (could?) be shared between linux and u-boot.
> > >
> > > -michael
> > >
> > > [1]
> > > https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471
> >
> > The U-Boot device tree is supposed to be able to be passed on to Linux
> > and Just Work.  The bindings are not supposed to be different between
> > the two (except for when we take the binding while it's being hashed out
> > upstream BUT THEN RESYNCED).
> 
> You might need to spell that out a bit clearer.
> 
> You are saying that both U-Boot and Linux are allowed to have their own
> custom properties (like 'u-boot,dm-spl' for U-Boot, and 'managed = "in-band-status"'
> for Linux), as long as the device tree files themselves are in sync, and
> the subset of the device tree blob understood by Linux (i.e. the U-Boot
> blob sans the U-Boot specifics) is compatible with the Linux DT blob?

I don't know what about the Linux example makes it Linux specific.  But
yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored
by Linux.  The whole reason we have the -u-boot.dtsi automatic drop-in
logic (as much as it can be used is that device trees are device trees
and describe the hardware and developers don't need to write a device
tree for Linux and a device tree for U-Boot and a device tree for
FreeBSD and ...  So yes, you're supposed to use the device tree for a
platform and it works here and there and every where.

> To expand even further on that, it means we should put 'managed = "in-band-status"'
> in U-Boot, which is a Linux phylink device tree property, even if U-Boot
> does not use phylink?

We should be able to drop in the device trees from Linux and use them.
Custodians should be re-syncing them periodically.  Some are, even.

> > Incompatible device trees / bindings are a
> > bug that needs to be fixed.
> 
> Curious that Michael mentions Ethernet and DSA on LS1028A.
> 
> I decompiled the two:
> 
> dtc -I dtb -O dts < arch/arm/dts/fsl-ls1028a-rdb.dtb > u-boot.dts
> dtc -I dtb -O dts < arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dtb > linux.dts
> 
> and analyzed the Ethernet portion.
> 
> U-Boot looks like this:
> 
> /dts-v1/;
> 
> / {
> 	compatible = "fsl,ls1028a-rdb", "fsl,ls1028a";
> 	interrupt-parent = <0x1>;
> 	#address-cells = <0x2>;
> 	#size-cells = <0x2>;
> 	model = "NXP Layerscape 1028a RDB Board";
> 
> 	pcie@1f0000000 {
> 		compatible = "pci-host-ecam-generic";
> 		bus-range = <0x0 0x0>;
> 		reg = <0x1 0xf0000000 0x0 0x100000>;
> 		#address-cells = <0x3>;
> 		#size-cells = <0x2>;
> 		device_type = "pci";
> 		ranges = <0x82000000 0x0 0x0 0x1 0xf8000000 0x0 0x160000>;
> 
> 		pci@0,0 {
> 			reg = <0x0 0x0 0x0 0x0 0x0>;
> 			status = "okay";
> 			phy-mode = "sgmii";
> 			phy-handle = <0x4>;
> 			phandle = <0x11>;
> 		};
> 
> 		pci@0,1 {
> 			reg = <0x100 0x0 0x0 0x0 0x0>;
> 			status = "disabled";
> 			phandle = <0x12>;
> 		};
> 
> 		pci@0,2 {
> 			reg = <0x200 0x0 0x0 0x0 0x0>;
> 			status = "okay";
> 			phy-mode = "internal";
> 			phandle = <0x9>;
> 
> 			fixed-link {
> 				speed = <0x9c4>;
> 				full-duplex;
> 			};
> 		};
> 
> 		pci@0,3 {
> 			#address-cells = <0x0>;
> 			#size-cells = <0x1>;
> 			reg = <0x300 0x0 0x0 0x0 0x0>;
> 			status = "okay";
> 			phandle = <0x13>;
> 
> 			fixed-link {
> 				speed = <0x3e8>;
> 				full-duplex;
> 			};
> 
> 			phy@2 {
> 				reg = <0x2>;
> 				phandle = <0x4>;
> 			};
> 
> 			phy@10 {
> 				reg = <0x10>;
> 				phandle = <0x5>;
> 			};
> 
> 			phy@11 {
> 				reg = <0x11>;
> 				phandle = <0x6>;
> 			};
> 
> 			phy@12 {
> 				reg = <0x12>;
> 				phandle = <0x7>;
> 			};
> 
> 			phy@13 {
> 				reg = <0x13>;
> 				phandle = <0x8>;
> 			};
> 		};
> 
> 		pci@0,5 {
> 			reg = <0x500 0x0 0x0 0x0 0x0>;
> 			status = "okay";
> 			phandle = <0x14>;
> 
> 			ports {
> 				#address-cells = <0x1>;
> 				#size-cells = <0x0>;
> 
> 				port@0 {
> 					reg = <0x0>;
> 					status = "okay";
> 					label = "swp0";
> 					phy-handle = <0x5>;
> 					phy-mode = "qsgmii";
> 					phandle = <0x15>;
> 				};
> 
> 				port@1 {
> 					reg = <0x1>;
> 					status = "okay";
> 					label = "swp1";
> 					phy-handle = <0x6>;
> 					phy-mode = "qsgmii";
> 					phandle = <0x16>;
> 				};
> 
> 				port@2 {
> 					reg = <0x2>;
> 					status = "okay";
> 					label = "swp2";
> 					phy-handle = <0x7>;
> 					phy-mode = "qsgmii";
> 					phandle = <0x17>;
> 				};
> 
> 				port@3 {
> 					reg = <0x3>;
> 					status = "okay";
> 					label = "swp3";
> 					phy-handle = <0x8>;
> 					phy-mode = "qsgmii";
> 					phandle = <0x18>;
> 				};
> 
> 				port@4 {
> 					reg = <0x4>;
> 					phy-mode = "internal";
> 					status = "okay";
> 					ethernet = <0x9>;
> 					phandle = <0x19>;
> 
> 					fixed-link {
> 						speed = <0x9c4>;
> 						full-duplex;
> 					};
> 				};
> 
> 				port@5 {
> 					reg = <0x5>;
> 					phy-mode = "internal";
> 					status = "disabled";
> 					phandle = <0x1a>;
> 
> 					fixed-link {
> 						speed = <0x3e8>;
> 						full-duplex;
> 					};
> 				};
> 			};
> 		};
> 
> 		pci@0,6 {
> 			reg = <0x600 0x0 0x0 0x0 0x0>;
> 			status = "disabled";
> 			phy-mode = "internal";
> 			phandle = <0x1b>;
> 		};
> 	};
> };
> 
> While Linux looks like this:
> 
> /dts-v1/;
> 
> / {
> 	soc {
> 		compatible = "simple-bus";
> 		#address-cells = <0x2>;
> 		#size-cells = <0x2>;
> 		ranges;
> 
> 		pcie@1f0000000 {
> 			compatible = "pci-host-ecam-generic";
> 			reg = <0x1 0xf0000000 0x0 0x100000>;
> 			#address-cells = <0x3>;
> 			#size-cells = <0x2>;
> 			msi-parent = <0x11>;
> 			device_type = "pci";
> 			bus-range = <0x0 0x0>;
> 			dma-coherent;
> 			msi-map = <0x0 0x11 0x17 0xe>;
> 			iommu-map = <0x0 0x12 0x17 0xe>;
> 			ranges = <0x82000000 0x1 0xf8000000 0x1 0xf8000000 0x0 0x160000 0xc2000000 0x1 0xf8160000 0x1 0xf8160000 0x0 0x70000 0x82000000 0x1 0xf81d0000 0x1 0xf81d0000 0x0 0x20000 0xc2000000 0x1 0xf81f0000 0x1 0xf81f0000 0x0 0x20000 0x82000000 0x1 0xf8210000 0x1 0xf8210000 0x0 0x20000 0xc2000000 0x1 0xf8230000 0x1 0xf8230000 0x0 0x20000 0x82000000 0x1 0xfc000000 0x1 0xfc000000 0x0 0x400000>;
> 
> 			ethernet@0,0 {
> 				compatible = "fsl,enetc";
> 				reg = <0x0 0x0 0x0 0x0 0x0>;
> 				status = "okay";
> 				phy-handle = <0x13>;
> 				phy-connection-type = "sgmii";
> 				managed = "in-band-status";
> 
> 				mdio {
> 					#address-cells = <0x1>;
> 					#size-cells = <0x0>;
> 
> 					ethernet-phy@2 {
> 						reg = <0x2>;
> 						phandle = <0x13>;
> 					};
> 				};
> 			};
> 
> 			ethernet@0,1 {
> 				compatible = "fsl,enetc";
> 				reg = <0x100 0x0 0x0 0x0 0x0>;
> 				status = "disabled";
> 			};
> 
> 			ethernet@0,2 {
> 				compatible = "fsl,enetc";
> 				reg = <0x200 0x0 0x0 0x0 0x0>;
> 				phy-mode = "internal";
> 				status = "okay";
> 				phandle = <0x18>;
> 
> 				fixed-link {
> 					speed = <0x9c4>;
> 					full-duplex;
> 				};
> 			};
> 
> 			mdio@0,3 {
> 				compatible = "fsl,enetc-mdio";
> 				reg = <0x300 0x0 0x0 0x0 0x0>;
> 				#address-cells = <0x1>;
> 				#size-cells = <0x0>;
> 
> 				ethernet-phy@10 {
> 					reg = <0x10>;
> 					phandle = <0x14>;
> 				};
> 
> 				ethernet-phy@11 {
> 					reg = <0x11>;
> 					phandle = <0x15>;
> 				};
> 
> 				ethernet-phy@12 {
> 					reg = <0x12>;
> 					phandle = <0x16>;
> 				};
> 
> 				ethernet-phy@13 {
> 					reg = <0x13>;
> 					phandle = <0x17>;
> 				};
> 			};
> 
> 			ethernet@0,4 {
> 				compatible = "fsl,enetc-ptp";
> 				reg = <0x400 0x0 0x0 0x0 0x0>;
> 				clocks = <0x2 0x2 0x3>;
> 				little-endian;
> 				fsl,extts-fifo;
> 			};
> 
> 			ethernet-switch@0,5 {
> 				reg = <0x500 0x0 0x0 0x0 0x0>;
> 				interrupts = <0x0 0x5f 0x4>;
> 				status = "okay";
> 
> 				ports {
> 					#address-cells = <0x1>;
> 					#size-cells = <0x0>;
> 
> 					port@0 {
> 						reg = <0x0>;
> 						status = "okay";
> 						label = "swp0";
> 						managed = "in-band-status";
> 						phy-handle = <0x14>;
> 						phy-mode = "qsgmii";
> 					};
> 
> 					port@1 {
> 						reg = <0x1>;
> 						status = "okay";
> 						label = "swp1";
> 						managed = "in-band-status";
> 						phy-handle = <0x15>;
> 						phy-mode = "qsgmii";
> 					};
> 
> 					port@2 {
> 						reg = <0x2>;
> 						status = "okay";
> 						label = "swp2";
> 						managed = "in-band-status";
> 						phy-handle = <0x16>;
> 						phy-mode = "qsgmii";
> 					};
> 
> 					port@3 {
> 						reg = <0x3>;
> 						status = "okay";
> 						label = "swp3";
> 						managed = "in-band-status";
> 						phy-handle = <0x17>;
> 						phy-mode = "qsgmii";
> 					};
> 
> 					port@4 {
> 						reg = <0x4>;
> 						phy-mode = "internal";
> 						status = "okay";
> 						ethernet = <0x18>;
> 
> 						fixed-link {
> 							speed = <0x9c4>;
> 							full-duplex;
> 						};
> 					};
> 
> 					port@5 {
> 						reg = <0x5>;
> 						phy-mode = "internal";
> 						status = "disabled";
> 
> 						fixed-link {
> 							speed = <0x3e8>;
> 							full-duplex;
> 						};
> 					};
> 				};
> 			};
> 
> 			ethernet@0,6 {
> 				compatible = "fsl,enetc";
> 				reg = <0x600 0x0 0x0 0x0 0x0>;
> 				phy-mode = "internal";
> 				status = "disabled";
> 
> 				fixed-link {
> 					speed = <0x3e8>;
> 					full-duplex;
> 				};
> 			};
> 
> 			rcec@1f,0 {
> 				reg = <0xf800 0x0 0x0 0x0 0x0>;
> 				interrupts = <0x0 0x5e 0x4>;
> 			};
> 		};
> 	};
> };
> 
> I mean, they look pretty similar to me? The biggest difference is that
> the ENETC ECAM is under the /soc node in Linux, but under / in U-Boot,
> as well as some BAR memory areas that are not marked as prefetchable or
> non-prefetchable in the U-Boot device tree. But excuse me, that isn't an
> Ethernet/DSA problem, is it?

I'll leave this part to Michael.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2021-08-25 14:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-25 13:58 incompatible device trees between u-boot and linux Michael Walle
2021-08-25 14:00 ` Tom Rini
2021-08-25 14:18   ` Vladimir Oltean
2021-08-25 14:26     ` Tom Rini [this message]
2021-08-25 15:12       ` Vladimir Oltean
2021-08-25 15:24         ` Tom Rini
2021-08-25 15:43           ` Vladimir Oltean
2021-08-25 20:09             ` Tom Rini
2021-08-25 23:03               ` Vladimir Oltean
2021-08-26  7:35                 ` Michael Walle
2021-08-26 16:32                   ` Vladimir Oltean
2021-08-28 23:12                     ` Michael Walle
2021-08-30  0:20                       ` Vladimir Oltean
2021-08-25 21:20         ` Mark Kettenis
2021-08-31 13:35         ` Rob Herring
2021-08-31 14:21           ` Sean Anderson
2021-08-31 18:36             ` Rob Herring
2021-08-25 14:30     ` Michael Walle
     [not found] <mailman.0.1630317603.18534.u-boot@lists.denx.de>
2021-08-30 11:39 ` François Ozog

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210825142610.GU858@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=heiko.thiery@gmail.com \
    --cc=michael@walle.cc \
    --cc=olteanv@gmail.com \
    --cc=priyanka.jain@nxp.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.