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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 8F5A6C61DA4 for ; Thu, 23 Feb 2023 22:36:04 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 06DF4857FB; Thu, 23 Feb 2023 23:36:02 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (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="Bz6lHQ8A"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 71AB68598E; Thu, 23 Feb 2023 23:35:48 +0100 (CET) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 2079985AFF for ; Thu, 23 Feb 2023 23:35:14 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf2e.google.com with SMTP id ff4so12352243qvb.2 for ; Thu, 23 Feb 2023 14:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=5TDQXxl+FX0fRazZmsOFaDn8hdf8TptupQVbcaS3P9Q=; b=Bz6lHQ8AkEl14uMqOCipoOZ3zjjTbCQHOFQrnbmw0JeimzrffclqI+l9ukGCSuzMYT JjlnSqTe29P7TC55v9EKK+scgG19RB5bg4XqfY3fK2vlthykkcBpVT6fwb2CqRqIsvEm vk6biogK5yFNQwnZHzE7tQTyFa71vKBh+Pcpw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5TDQXxl+FX0fRazZmsOFaDn8hdf8TptupQVbcaS3P9Q=; b=algxneUCWFOzS8hSpBXgIfGjIAwq2x/5nut76Qlria71msPG5N+FXM3RWjNsoFn6IT qavlnGONyRMmoGWerWkrDdkWrpbCgu1GRxbPhXcNWmA8cUx6L+39iHLpjkgcHsmh7PMt BqD+dx/8y0LeQrBldDenh5SrlcjQA1xgW29WbblETOEz2TcDxC0bDcszXd+dW6JiSbgw jNo3v9XVGG+PPNgxGjCwWa4+7v95zdhKg62nlQWQaICc4d1Hlibjqwy0Ec+JkpdCXYZW V4vp71BCqNZxmuQJ3KAiWOxBTEZNtH9yg1OdDWYbYgF2sgHYIfbms+npA3qsXku9dbS2 46ng== X-Gm-Message-State: AO0yUKVcGLe3+NLjtn9dXk0GyTuTyDqpPaYgLAdImUF3496Vtglt8GPB +b4SxRZZnxRzIy+zSpZNABrYdA== X-Google-Smtp-Source: AK7set9jqjNRAVuT/ujGFL2lCKuiXu/aQwCtREUj+Dm1NS5dhPzMuBW2pK7DykWK2rjCPFydU+c6Ag== X-Received: by 2002:a05:6214:5010:b0:56e:a96a:2be1 with SMTP id jo16-20020a056214501000b0056ea96a2be1mr22934548qvb.48.1677191712605; Thu, 23 Feb 2023 14:35:12 -0800 (PST) Received: from bill-the-cat (2603-6081-7b00-6400-7b76-35a4-b335-d04d.res6.spectrum.com. [2603:6081:7b00:6400:7b76:35a4:b335:d04d]) by smtp.gmail.com with ESMTPSA id q205-20020a3743d6000000b0073b75718428sm5349722qka.134.2023.02.23.14.35.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 14:35:12 -0800 (PST) Date: Thu, 23 Feb 2023 17:35:10 -0500 From: Tom Rini To: Patrick DELAUNAY Cc: Miquel Raynal , Patrice Chotard , Francesco Dolcini , Simon Glass , u-boot@lists.denx.de, Marcel Ziswiler , Francesco Dolcini , Marek Vasut , linux-mtd@lists.infradead.org Subject: Re: [PATCH v1 0/3] fdt: Fix mtparts fixup Message-ID: References: <20230113184547.487322-1-francesco@dolcini.it> <20230113193411.GW3787616@bill-the-cat> <20230123110606.56110e40@xps-13> <20230123200131.GD631605@bill-the-cat> <5a01a9d1-9068-576a-7028-53415cc03ed8@foss.st.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fgdlogPFaVxQHz81" Content-Disposition: inline In-Reply-To: <5a01a9d1-9068-576a-7028-53415cc03ed8@foss.st.com> X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.6 at phobos.denx.de X-Virus-Status: Clean --fgdlogPFaVxQHz81 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 23, 2023 at 11:23:41AM +0100, Patrick DELAUNAY wrote: > Hi, >=20 > On 1/23/23 21:01, Tom Rini wrote: > > On Mon, Jan 23, 2023 at 11:06:06AM +0100, Miquel Raynal wrote: > > > Hi Tom, > > >=20 > > > trini@konsulko.com wrote on Fri, 13 Jan 2023 14:34:11 -0500: > > >=20 > > > > On Fri, Jan 13, 2023 at 07:45:44PM +0100, Francesco Dolcini wrote: > > > >=20 > > > > > From: Francesco Dolcini > > > > >=20 > > > > > Recently we had a boot regression on colibri-imx7 because of a cl= eanup change > > > > > on Linux imx7.dtsi setting nand controller node #size-cells from = 1 to 0. > > > > >=20 > > > > > Because of that Linux partition parser was no longer able to prop= erly > > > > > parse the OF partitions leading to a boot failure, the above chan= ge was > > > > > reverted in the meantime as an immediate workaround, but some imp= rovement > > > > > is required on both Linux and U-Boot. > > > > >=20 > > > > > This change improve the U-Boot part of it, #size-cell is set to 1= when > > > > > it has an invalid value. This has the limitation to work only wit= h devices > > > > > smaller than 4GiB. In general the suggestion from the Linux MTD m= aintainer would > > > > > be to just deprecate using this U-Boot function and pass the MTD = partitions > > > > > from the command line, unless they are statically defined in the = DTS file > > > > > in the first place. > > > > >=20 > > > > > This series therefore convert colibri-imx6ull and colibri-imx7 to= pass the > > > > > partition list from the command line instead of fixing up the DT. > > > > >=20 > > > > > Link: https://lore.kernel.org/all/20221202071900.1143950-1-france= sco@dolcini.it/ > > > > > Link: https://lore.kernel.org/all/Y4dgBTGNWpM6SQXI@francesco-nb.i= nt.toradex.com/ > > > > My higher level question / concern here is, is using one of the dts > > > > partition schemes still valid / preferred, or should everyone now h= ave > > > > reverted to passing via the kernel command line? If device tree st= ill, > > > > is mtd/partitions/fixed-partitions.yaml the one to follow or someth= ing > > > > else? > > > I don't think we can "prefer" one mode over the other between cmdline > > > and DTS. Both should work pretty well. Of course on the cmdline you c= an > > > only define fixed partitions and many devices require more advanced > > > parsers, which are only available through DTS, but for simple > > > partitions, it works totally okay. > > When both are present, which one is used? > >=20 > > > The only thing that I would like to avoid is the need to write code in > > > the bootloaders to tweak the FDT in order to add partitions. That is > > > clearly not needed, error prone, and do not follow evolution of the > > > "standard", as we just discovered. > > I'm not sure about this. Looking around in U-Boot today, I see two types > > of cases. One of which, the colibri case, can clearly be not done and > > either passed on the command line, or put in to the device tree as > > there's nothing run-time related being tweaked here. That's a fine path > > to take on those platforms and Francesco's patches should be updated to > > remove the unused C code too from the board code. > >=20 > > But the other cases are doing something dynamic and run-time related. > > There's the omap3 igep00x0 family (which yes, legacy) that is doing NAND > > or oneNAND and adjusting things at run time. I don't know how much > > anyone has interest in those platforms at this point, nor exactly who to > > contact (for Linux or U-Boot). There's also the stm32mp1 family doing > > something that's very not obvious at first glance, so I've cc'd the > > maintainers there. > >=20 >=20 > For information, today for stm32mp1 family we are using the build >=20 > =A0of MTDPARTS and fdt fixup, only for backward compatibility issue >=20 > (the MTD partitions change for boot with or without OP-TEE, >=20 > with or wihtout FIP, with SPL). >=20 >=20 > Today we are already plan to remove this dynamic management >=20 > and to switch to static MTD partition defined in device tree, >=20 > as already proposed by Tom in the serie >=20 > =A0"mtd: spi: nor: force mtd name to "nor%d"" >=20 > http://patchwork.ozlabs.org/project/uboot/patch/20210916155040.v3.2.Ia461= e670c7438478aa8f8939209d45c818ccd284@changeid/ >=20 >=20 > This patchset is already ready, we are currently testing it internally >=20 > and it should be pushed when it will be validated in our donwstream. Great, thanks. --=20 Tom --fgdlogPFaVxQHz81 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmP36h4ACgkQFHw5/5Y0 tyw+bwwAjmh/Sd3o/7CPbh4rpOP7buBNm3A3BcQvAK6rFBShQrCQXw76hc/mgwDY ZEdSHTYoz+/5U3DOrFtT9v8Wm9WDgC07Hh+en4KYSliX/KjW3OARsha89u2heDAb sUhm8uOZHRYZ3DLtYElIVqniAgMP/lrnAEMOZN/m7YxgHk55wC84PC3z6JHiQCNx QOhcI3McvekvqJa+rMn5g0vKYFiRNFd8IbgkpEqOPdq8o721+JQJL0zaKR2inQAT sdvHf2L8mCRgxxhTST4Th4gMJTr2MbVS7VIm6/oei9ioaNCwou2YrPFC9e8eJSck 0FwsnXWulkhuCEmIhNlceexcjsQR1WW2dzoAFpAbB/Uoydc7+o7MyzWoOOqmw7EB OWZv8osrphIxwi8K+gfgAExpdcIY7Sk2l4HDxMW+paOqnnn6FXTU7YU6g0p0w4Cv uD9xEpojIMBJ3NpD3rsknlQNIj/DTl7Hfb+4xSESXskPs8wuzDNNIPKIX4sRpYYw MmhUXOHb =KRDt -----END PGP SIGNATURE----- --fgdlogPFaVxQHz81--