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.2 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,URIBL_BLOCKED,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 A9A57C4338F for ; Wed, 11 Aug 2021 21:04:59 +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 A0C0460F46 for ; Wed, 11 Aug 2021 21:04:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A0C0460F46 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 4BF5D8022E; Wed, 11 Aug 2021 23:04:56 +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="RRpNbS2O"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 418268022E; Wed, 11 Aug 2021 23:04:54 +0200 (CEST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 3A54B82903 for ; Wed, 11 Aug 2021 23:04:46 +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-qt1-x829.google.com with SMTP id z24so3245156qtn.8 for ; Wed, 11 Aug 2021 14:04:46 -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=WqG8Dbh+EAGJB4CfoL7b9q6NJyY3dMvqpsCVrRf8kfA=; b=RRpNbS2OssTHgWlsZWp2HEt1EJXYk/nhRW4xnFqam8mYc6hJ5Ee4h2m1qEwiMifbxM YGjYdWv6I8FZMFKaRR+RRYda+IeMG5QBbp2BJsum87R9S6qzU+Y/Scbewdm0YZVT5Cug 2zZk9ZSNHHWl0l/ZygIlXVq89ZzlsmQRUOt3E= 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=WqG8Dbh+EAGJB4CfoL7b9q6NJyY3dMvqpsCVrRf8kfA=; b=njmzVMJ5C8UjBh3Ni32vGW5Wjfwv5hSmzErOljQ2OkN3sAWy/wY30DJU8vxOPjAqOQ I3y57657va0ODGX22MqfQBbNd0nigaYcY7ZdRuW1zW6xMGanWRMynsU0LnK8VMrmnm7V nQyuTh1SpmfbGL2iDiw9REWw8LuZlk4+7stP2xtA9JXP3fN3z9dXCYvjk//g5VyUmv16 JnDplKEaQeystTPLOVvHEswayMkBMk0qUItem2zXGbmvuiQ2q1M035ta2dB/DLCTL26X k7iLV2QhVHnZR+ROh5pT+KCMgpZj3oEzlGQCWQMBOgNa0vQUJz1pn7vKbW3FErYJBaM5 NjPA== X-Gm-Message-State: AOAM530250e4W6o81B5TNk84Er1QtaTnpcYb4u9PWrnmusTFFoTefg7S TO47lpVXig85atkD+OUEVQSVoQ== X-Google-Smtp-Source: ABdhPJwGA7jUgk7uv9iX0tPsWmZ2R1VrNrYy6mx42IZH1mRY0yM0j8pHRDH+0J7kt2CPA1tnTpllSg== X-Received: by 2002:a05:622a:14d:: with SMTP id v13mr642683qtw.241.1628715884686; Wed, 11 Aug 2021 14:04:44 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-ddfe-3f7e-6e5c-2811.res6.spectrum.com. [2603:6081:7b01:cbda:ddfe:3f7e:6e5c:2811]) by smtp.gmail.com with ESMTPSA id d129sm157243qkf.136.2021.08.11.14.04.43 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 11 Aug 2021 14:04:43 -0700 (PDT) Date: Wed, 11 Aug 2021 17:04:41 -0400 From: Tom Rini To: Simon Glass Cc: U-Boot Mailing List , Marek Vasut , Masahiro Yamada , Heinrich Schuchardt , Bin Meng , Stefan Roese , Marek =?iso-8859-1?Q?Beh=FAn?= , Sean Anderson , Aaron Williams Subject: Re: RFC: Support for U-Boot phases in Kconfig Message-ID: <20210811210441.GL858@bill-the-cat> References: <20210809191111.GD858@bill-the-cat> <20210810193809.GL858@bill-the-cat> <20210811140220.GX858@bill-the-cat> <20210811143132.GC858@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nLFWHeLI3WgDCk6A" Content-Disposition: inline In-Reply-To: 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 --nLFWHeLI3WgDCk6A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2021 at 08:47:24AM -0600, Simon Glass wrote: > Hi Tom, >=20 > On Wed, 11 Aug 2021 at 08:31, Tom Rini wrote: > > > > On Wed, Aug 11, 2021 at 08:11:41AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 11 Aug 2021 at 08:02, Tom Rini wrote: > > > > > > > > On Wed, Aug 11, 2021 at 06:56:31AM -0600, Simon Glass wrote: > > > > [snip] > > > > > Having thought a bit more, perhaps we have the wrong attitude to > > > > > Kconfig. The CONFIG() macro I am talking about works by building = an > > > > > xxx or SPL_xxx config. If we have separate autoconf.h files for e= ach > > > > > phase (autoconf_spl.h etc.) then we don't actually need this. We = just > > > > > need to include the correct file. Any SPL_xxx config can be writt= en as > > > > > xxx. Similarly the Makefile rules can drop the $(P) I was proposi= ng. > > > > > > > > > > We can, in fact, generate separate autoconf.h files for each phase > > > > > today, with no other changes. Unless I am missing something...? > > > > > > > > If we can spit out {spl_,tpl_,}autoconf.h files that might help a b= it. > > > > But would it help with the recent case of SPL has SATA+AHCI+!PCI wh= ile > > > > full U-Boot has SATA+AHCI+!PCI AND SATA+AHCI+PCI ? Today we can't > > > > support the SPL case without adding the handful of SPL_xxx symbols = so > > > > that we can say we have SATA+AHCI without PCI. > > > > > > My thought is that: > > > > > > - where there is no SPL_xxx symbol, it we would have CONFIG_xxx=3Dy in > > > all autoconf.h files > > > - where there is an SPL_xxx symbol, it we would only have it in > > > spl_autoconf.h if the SPL_xxx symbol is enabled > > > > > > So it does not reduce the power/flexibility of what we have to cover > > > all cases. It is just a phase-specific way of presenting the configs > > > to the build, so we can do: > > > > > > obj-$(CONFIG_FOO) +=3D foo.o > > > > > > as well as > > > > > > if (CONFIG(FOO)) > > > > > > I'm still thinking about Kconfig. To me it seems that separating the > > > phases so completely is giving up quite a bit. There is no-longer a > > > unified build, so dependencies between phases may become a problem. I > > > think in fact our problem is the use of SPL_ and TPL_ prefixes on > > > Kconfigs, which you have highlighted. Perhaps we just shouldn't do > > > that. It would be nice if kconfig could support multiple interrelated > > > build phases and output a separate autoconf.h for each one. > > > > What are the dependencies we have between phases? You've mentioned > > bloblist, but to me that's like BOARD_INIT and MISC_INIT_R and all of > > the other things you need to have select'd on a platform because they're > > non-optional. >=20 > Well if you enable BLOBLIST in U-Boot proper then it had better be > enabled in SPL or it won't work. Same with HANDOFF. Other things on my > list in this vein are console recording through the phases. Logging is > best enabled globally, with different default levels for SPL. We also > have a lot of things like LOCALVERSION. The main Makefile looks at > CONFIG_SPL_FRAMEWORK to decide whether to expect u-boot.img or not, so > we'd have to have another symbol like CONFIG_FRAMEWORK that people > keep in sync (or just complete the *&^#$&^# migration :-) >=20 > We have quite a bit of: >=20 > config SPL_SYS_ICACHE_OFF > depends on SPL > default SYS_ICACHE_OFF >=20 > I think we are throwing away a lot by separating them at the > configuration stage. I'm not saying it's a disaster but I am worried > that it might not lead to a good place. My first reaction is that things will be fine with either select's (a platform using HANDOFF/BLOBLIST should be select'ing that since it's require) or matching defaults. The *CACHE_OFF example isn't actually a needs to be in sync thing, there's platforms today that disable in SPL but not full. I'm fully willing to admit there's pitfalls I'm not seeing. And I'll further say I don't think this should be our top goal right now. > > And I'm really not seeing now how we would support the example I gave as > > for them SPL with SATA+AHCI+PCI is not desired nor possible. I asked. > > The answer was no, don't want it. Or do you really just mean that if we > > had spl_autoconf.h the only thing that would change is that we would > > never test on CONFIG_SPL_xxx only CONFIG_xxx, but we would still need to > > Kconfig SPL_xxx? >=20 > Yes, that's what I am saying. We can make that change now (to clean up > Makefile and add CONFIG()) with no change to Kconfig. >=20 > We can support the case you mention and yes we want it and need it, of > course. Otherwise we are back to the SPL #undef horror. OK. We can certainly see how it works out, if you make a patch for it. --=20 Tom --nLFWHeLI3WgDCk6A Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmEUO2IACgkQFHw5/5Y0 tyz0iwwAtOIhzkdDLvrXg0FtWN5pyN1rVvCndl/Y3w0rN6MgKJD5dAWY6rKu+kll jMRWm2mlTivTo82qSx1V04lycu9A5NvQtFvdVqucP93ZuZOxgsb8sraSLKBSs7z7 0fQpd/ae09dygB6jfsFpO1UI6k62ZOMPYoA1h+vWVN57AxP0053Oiq+sn9+66wGe mmHVeN91a2LLrCiotZa9E5sS4CSk8jylrGqx+TqFuLpu453R+9MnSWBzIrucPJ3v TH/uCXIQTrUIg0W4+4QwMT5ZpsmsOrzsHvEQrY/Nz5hoAEjlyl9hvdcZYr4snB91 /s7b18lW8BaIV/s0J4SOhEvDy1Rt93WKXJiz+qBMYHUlS6DiccgAEYhO86ovQZw1 qPVAW3Kg00GljP1NUYPr+U6BUICuOrVqwrotgO+pxnGJCmdiklXZz8BI2AhY1ocG spi3csFqzad/tzAkt6tnVIMqcRPMI9n1oLsWlbea2BL1t+W8IgiVe1c7DgXrcOxs VML4Tew+ =x5A8 -----END PGP SIGNATURE----- --nLFWHeLI3WgDCk6A--