From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70D5CC4338F for ; Wed, 25 Aug 2021 14:26:25 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 79E7461058 for ; Wed, 25 Aug 2021 14:26:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 79E7461058 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1BF6080A22; Wed, 25 Aug 2021 16:26:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="pCSVhHnw"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 5436480612; Wed, 25 Aug 2021 16:26:20 +0200 (CEST) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 7957C80A22 for ; Wed, 25 Aug 2021 16:26:14 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf35.google.com with SMTP id z2so9250376qvl.10 for ; Wed, 25 Aug 2021 07:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=oSbS+fB0WsmQwQdWjpVEs+VdHVUqYuPvHSWi+WIWPhM=; b=pCSVhHnw9jEw3DbO8moWoPl1xwvZPLXm6O2HQ/RNeaVQD6ivm3Q5WhHDnDHd8T4VQf XBNnGBUAF6CApE12b0a8GAhwQk7lD0J02i40g7IccQkqhQmRA4XfY0hzAu4vvJwYz54W mqbapFgm70UoSWDeJNurcJkcrNXh8WB6hfFNo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=oSbS+fB0WsmQwQdWjpVEs+VdHVUqYuPvHSWi+WIWPhM=; b=P5nEE3qxg8g0kx9uF1ZwtfmAkAV2bnNOLp39mo/19sQVMgIb+R2s3hDNMT/coyZTfK FBETf5Bya3PAomAqCCbmf5IXwGSecxvLhaQ/lcx7UvLTs1PeE56ZLeII/TH/I+dhf3IX of8iAemc6gJp1koYjpwDQHIuvpZu6DBvtHPq/pmdVcbVGM0LYiwqJWsvB2hubBWJsdeK doVxdqnszrIKxeTaU4IuCKqJNaLi1acstUxABoPUW7Q/POzerT5QoGcdTUKUHaADvjIc PNGdf48mMzHrkZ3Xlg4xjkd/NMh7uZ3TEM/FK1kzBHNnIfcnCncrh6RwwX3EWG4im9jU mh9A== X-Gm-Message-State: AOAM533vOwZ8JSHKq7NWtTclS/5z05oCxVTSvylnnCPO4ss1HhI+P0Lj A5Wecni3OoFdP3/ku2NvhJ+wAQ== X-Google-Smtp-Source: ABdhPJxvkuoXBdq9z+m2We6i5qNyMzO+1bMF3QMwprIMce2LBb5CiWlKQFAuU+JQGoVGpv0nmCNQPw== X-Received: by 2002:a05:6214:d83:: with SMTP id e3mr44418811qve.23.1629901573260; Wed, 25 Aug 2021 07:26:13 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-519a-4843-2801-9790.res6.spectrum.com. [2603:6081:7b01:cbda:519a:4843:2801:9790]) by smtp.gmail.com with ESMTPSA id b1sm2631522qtj.76.2021.08.25.07.26.12 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Aug 2021 07:26:12 -0700 (PDT) Date: Wed, 25 Aug 2021 10:26:10 -0400 From: Tom Rini To: Vladimir Oltean Cc: Michael Walle , Priyanka Jain , u-boot@lists.denx.de, heiko.thiery@gmail.com Subject: Re: incompatible device trees between u-boot and linux Message-ID: <20210825142610.GU858@bill-the-cat> References: <51c2a92f6bf771769f1e2da5157727e8@walle.cc> <20210825140045.GR858@bill-the-cat> <20210825141816.qfn25xlech55rwsg@skbuf> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wC7TH3KTUS2JWJkB" Content-Disposition: inline In-Reply-To: <20210825141816.qfn25xlech55rwsg@skbuf> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean --wC7TH3KTUS2JWJkB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 a= re > > > 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 bindin= gs > > > 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). >=20 > You might need to spell that out a bit clearer. >=20 > 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 =3D "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 =3D "in-b= and-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. >=20 > Curious that Michael mentions Ethernet and DSA on LS1028A. >=20 > I decompiled the two: >=20 > 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 > l= inux.dts >=20 > and analyzed the Ethernet portion. >=20 > U-Boot looks like this: >=20 > /dts-v1/; >=20 > / { > compatible =3D "fsl,ls1028a-rdb", "fsl,ls1028a"; > interrupt-parent =3D <0x1>; > #address-cells =3D <0x2>; > #size-cells =3D <0x2>; > model =3D "NXP Layerscape 1028a RDB Board"; >=20 > pcie@1f0000000 { > compatible =3D "pci-host-ecam-generic"; > bus-range =3D <0x0 0x0>; > reg =3D <0x1 0xf0000000 0x0 0x100000>; > #address-cells =3D <0x3>; > #size-cells =3D <0x2>; > device_type =3D "pci"; > ranges =3D <0x82000000 0x0 0x0 0x1 0xf8000000 0x0 0x160000>; >=20 > pci@0,0 { > reg =3D <0x0 0x0 0x0 0x0 0x0>; > status =3D "okay"; > phy-mode =3D "sgmii"; > phy-handle =3D <0x4>; > phandle =3D <0x11>; > }; >=20 > pci@0,1 { > reg =3D <0x100 0x0 0x0 0x0 0x0>; > status =3D "disabled"; > phandle =3D <0x12>; > }; >=20 > pci@0,2 { > reg =3D <0x200 0x0 0x0 0x0 0x0>; > status =3D "okay"; > phy-mode =3D "internal"; > phandle =3D <0x9>; >=20 > fixed-link { > speed =3D <0x9c4>; > full-duplex; > }; > }; >=20 > pci@0,3 { > #address-cells =3D <0x0>; > #size-cells =3D <0x1>; > reg =3D <0x300 0x0 0x0 0x0 0x0>; > status =3D "okay"; > phandle =3D <0x13>; >=20 > fixed-link { > speed =3D <0x3e8>; > full-duplex; > }; >=20 > phy@2 { > reg =3D <0x2>; > phandle =3D <0x4>; > }; >=20 > phy@10 { > reg =3D <0x10>; > phandle =3D <0x5>; > }; >=20 > phy@11 { > reg =3D <0x11>; > phandle =3D <0x6>; > }; >=20 > phy@12 { > reg =3D <0x12>; > phandle =3D <0x7>; > }; >=20 > phy@13 { > reg =3D <0x13>; > phandle =3D <0x8>; > }; > }; >=20 > pci@0,5 { > reg =3D <0x500 0x0 0x0 0x0 0x0>; > status =3D "okay"; > phandle =3D <0x14>; >=20 > ports { > #address-cells =3D <0x1>; > #size-cells =3D <0x0>; >=20 > port@0 { > reg =3D <0x0>; > status =3D "okay"; > label =3D "swp0"; > phy-handle =3D <0x5>; > phy-mode =3D "qsgmii"; > phandle =3D <0x15>; > }; >=20 > port@1 { > reg =3D <0x1>; > status =3D "okay"; > label =3D "swp1"; > phy-handle =3D <0x6>; > phy-mode =3D "qsgmii"; > phandle =3D <0x16>; > }; >=20 > port@2 { > reg =3D <0x2>; > status =3D "okay"; > label =3D "swp2"; > phy-handle =3D <0x7>; > phy-mode =3D "qsgmii"; > phandle =3D <0x17>; > }; >=20 > port@3 { > reg =3D <0x3>; > status =3D "okay"; > label =3D "swp3"; > phy-handle =3D <0x8>; > phy-mode =3D "qsgmii"; > phandle =3D <0x18>; > }; >=20 > port@4 { > reg =3D <0x4>; > phy-mode =3D "internal"; > status =3D "okay"; > ethernet =3D <0x9>; > phandle =3D <0x19>; >=20 > fixed-link { > speed =3D <0x9c4>; > full-duplex; > }; > }; >=20 > port@5 { > reg =3D <0x5>; > phy-mode =3D "internal"; > status =3D "disabled"; > phandle =3D <0x1a>; >=20 > fixed-link { > speed =3D <0x3e8>; > full-duplex; > }; > }; > }; > }; >=20 > pci@0,6 { > reg =3D <0x600 0x0 0x0 0x0 0x0>; > status =3D "disabled"; > phy-mode =3D "internal"; > phandle =3D <0x1b>; > }; > }; > }; >=20 > While Linux looks like this: >=20 > /dts-v1/; >=20 > / { > soc { > compatible =3D "simple-bus"; > #address-cells =3D <0x2>; > #size-cells =3D <0x2>; > ranges; >=20 > pcie@1f0000000 { > compatible =3D "pci-host-ecam-generic"; > reg =3D <0x1 0xf0000000 0x0 0x100000>; > #address-cells =3D <0x3>; > #size-cells =3D <0x2>; > msi-parent =3D <0x11>; > device_type =3D "pci"; > bus-range =3D <0x0 0x0>; > dma-coherent; > msi-map =3D <0x0 0x11 0x17 0xe>; > iommu-map =3D <0x0 0x12 0x17 0xe>; > ranges =3D <0x82000000 0x1 0xf8000000 0x1 0xf8000000 0x0 0x160000 0xc2= 000000 0x1 0xf8160000 0x1 0xf8160000 0x0 0x70000 0x82000000 0x1 0xf81d0000 = 0x1 0xf81d0000 0x0 0x20000 0xc2000000 0x1 0xf81f0000 0x1 0xf81f0000 0x0 0x2= 0000 0x82000000 0x1 0xf8210000 0x1 0xf8210000 0x0 0x20000 0xc2000000 0x1 0x= f8230000 0x1 0xf8230000 0x0 0x20000 0x82000000 0x1 0xfc000000 0x1 0xfc00000= 0 0x0 0x400000>; >=20 > ethernet@0,0 { > compatible =3D "fsl,enetc"; > reg =3D <0x0 0x0 0x0 0x0 0x0>; > status =3D "okay"; > phy-handle =3D <0x13>; > phy-connection-type =3D "sgmii"; > managed =3D "in-band-status"; >=20 > mdio { > #address-cells =3D <0x1>; > #size-cells =3D <0x0>; >=20 > ethernet-phy@2 { > reg =3D <0x2>; > phandle =3D <0x13>; > }; > }; > }; >=20 > ethernet@0,1 { > compatible =3D "fsl,enetc"; > reg =3D <0x100 0x0 0x0 0x0 0x0>; > status =3D "disabled"; > }; >=20 > ethernet@0,2 { > compatible =3D "fsl,enetc"; > reg =3D <0x200 0x0 0x0 0x0 0x0>; > phy-mode =3D "internal"; > status =3D "okay"; > phandle =3D <0x18>; >=20 > fixed-link { > speed =3D <0x9c4>; > full-duplex; > }; > }; >=20 > mdio@0,3 { > compatible =3D "fsl,enetc-mdio"; > reg =3D <0x300 0x0 0x0 0x0 0x0>; > #address-cells =3D <0x1>; > #size-cells =3D <0x0>; >=20 > ethernet-phy@10 { > reg =3D <0x10>; > phandle =3D <0x14>; > }; >=20 > ethernet-phy@11 { > reg =3D <0x11>; > phandle =3D <0x15>; > }; >=20 > ethernet-phy@12 { > reg =3D <0x12>; > phandle =3D <0x16>; > }; >=20 > ethernet-phy@13 { > reg =3D <0x13>; > phandle =3D <0x17>; > }; > }; >=20 > ethernet@0,4 { > compatible =3D "fsl,enetc-ptp"; > reg =3D <0x400 0x0 0x0 0x0 0x0>; > clocks =3D <0x2 0x2 0x3>; > little-endian; > fsl,extts-fifo; > }; >=20 > ethernet-switch@0,5 { > reg =3D <0x500 0x0 0x0 0x0 0x0>; > interrupts =3D <0x0 0x5f 0x4>; > status =3D "okay"; >=20 > ports { > #address-cells =3D <0x1>; > #size-cells =3D <0x0>; >=20 > port@0 { > reg =3D <0x0>; > status =3D "okay"; > label =3D "swp0"; > managed =3D "in-band-status"; > phy-handle =3D <0x14>; > phy-mode =3D "qsgmii"; > }; >=20 > port@1 { > reg =3D <0x1>; > status =3D "okay"; > label =3D "swp1"; > managed =3D "in-band-status"; > phy-handle =3D <0x15>; > phy-mode =3D "qsgmii"; > }; >=20 > port@2 { > reg =3D <0x2>; > status =3D "okay"; > label =3D "swp2"; > managed =3D "in-band-status"; > phy-handle =3D <0x16>; > phy-mode =3D "qsgmii"; > }; >=20 > port@3 { > reg =3D <0x3>; > status =3D "okay"; > label =3D "swp3"; > managed =3D "in-band-status"; > phy-handle =3D <0x17>; > phy-mode =3D "qsgmii"; > }; >=20 > port@4 { > reg =3D <0x4>; > phy-mode =3D "internal"; > status =3D "okay"; > ethernet =3D <0x18>; >=20 > fixed-link { > speed =3D <0x9c4>; > full-duplex; > }; > }; >=20 > port@5 { > reg =3D <0x5>; > phy-mode =3D "internal"; > status =3D "disabled"; >=20 > fixed-link { > speed =3D <0x3e8>; > full-duplex; > }; > }; > }; > }; >=20 > ethernet@0,6 { > compatible =3D "fsl,enetc"; > reg =3D <0x600 0x0 0x0 0x0 0x0>; > phy-mode =3D "internal"; > status =3D "disabled"; >=20 > fixed-link { > speed =3D <0x3e8>; > full-duplex; > }; > }; >=20 > rcec@1f,0 { > reg =3D <0xf800 0x0 0x0 0x0 0x0>; > interrupts =3D <0x0 0x5e 0x4>; > }; > }; > }; > }; >=20 > 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. --=20 Tom --wC7TH3KTUS2JWJkB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmEmUv8ACgkQFHw5/5Y0 tyxH3Qv/c9p5Ezgfxl9Mp4xKa1Q4Cw2zO9B9B73qrLz+6Rd5vQ3bkwWtdBp/Fj5Q zgsJOV2MdKqzjly2BPwWZaPSVnHqgKcPYqnzhjALCCkd2x5/wQlXbPdr9ASMUoBP VC5L3PeG+DMRB2Q499UJqluJEvsHQUVWpXg3vsk2Zpf6rbw+ldoB+1liMX35dCHR Q7ATua+OA8IyHEh8sQCSdb+W2Unsr5Ck//nmr4uKlP8h86WuXprhcHLfc+9nkCvT tkoADXohDrDrm2LXGRnjTHycStjErilcfgfJsLJaUGUqqirAgYfSWoCuRWKY3jdx weEWYHRtyCQw0QHqe3XicsB2Bha9/VnM9zQiFp0oVuRychvejoCUfRgafPi+NYgh N1/nh5hJ3BJDJldcANvHuN8fNhf7ANaelFo9EAfw/lNvWzo2Y5tOfhqzhU5vWhxG TgPsLhr3Tf3qcTDpGY8XuFTBd1HtsrzEmtSeMwoTGe+/xyMkQt/XzVmS0T/58Bz5 8iSo9UCR =UiHa -----END PGP SIGNATURE----- --wC7TH3KTUS2JWJkB--