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 01BD5C433FE for ; Mon, 10 Oct 2022 12:20:55 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 03FE284D8C; Mon, 10 Oct 2022 14:20:53 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="OpvmNony"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 425E784E1E; Mon, 10 Oct 2022 14:20:51 +0200 (CEST) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 2380984882 for ; Mon, 10 Oct 2022 14:20:47 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=kabel@kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7092460ECC; Mon, 10 Oct 2022 12:20:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F962C433C1; Mon, 10 Oct 2022 12:20:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665404444; bh=Ty5EvYnmCrgpyLV2Z/S+Vm1hXXDNLGyjZCJMNwG3HIg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OpvmNonyW4qXxXxm+9IHJPLQfKzWgfcNUm6oUGUGf3/m2GtCe6YyeZJ5B45n4gRUT I8TrILnlQEr33A/FAYrpajfeI92ZX/8iNWBIzhZpeZPrqbfyM2OrbQAwaSVrG4KP29 GhEJPVM9+KTC72yBMKhGLyHeTJBIesWTqJP12Ybd2togoEgwHVt52qm4B6Bo+MBmsJ YGpKHc1tCsTAPwvQZPRNNsg0mjon3o7wi7wU08G2uq+RsjEsrELWw3sQbCgG4zNNTc W4kjfBLgmgWh36nIHa2ZwZLstY0HzqtMbvFnfgdsMK/TqCHE8ij1CIPByX+LewF83e TSPW+8sOAFDIw== Date: Mon, 10 Oct 2022 14:20:20 +0200 From: Marek =?UTF-8?B?QmVow7pu?= To: Tom Rini Cc: Pali =?UTF-8?B?Um9ow6Fy?= , u-boot@lists.denx.de Subject: Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d Message-ID: <20221010142020.61190827@thinkpad> In-Reply-To: <20221009163202.GS3044094@bill-the-cat> References: <20220805155453.GC1146598@bill-the-cat> <20220805201701.7t37kxn64qaiye3n@pali> <20220805222019.GE1146598@bill-the-cat> <20220808095149.2e0ed3ff@thinkpad> <20220808133722.GM1146598@bill-the-cat> <20220817092908.diwaapf636fxpmuq@pali> <20220826145358.GG7942@bill-the-cat> <20221009124119.xp3tr4zqey7vv4q6@pali> <20221009124503.GR3044094@bill-the-cat> <20221009131045.22majcsxppyhgimk@pali> <20221009163202.GS3044094@bill-the-cat> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 On Sun, 9 Oct 2022 12:32:02 -0400 Tom Rini wrote: > On Sun, Oct 09, 2022 at 03:10:45PM +0200, Pali Roh=C3=A1r wrote: > > On Sunday 09 October 2022 08:45:03 Tom Rini wrote: =20 > > > On Sun, Oct 09, 2022 at 02:41:19PM +0200, Pali Roh=C3=A1r wrote: =20 > > > > On Friday 26 August 2022 10:53:58 Tom Rini wrote: =20 > > > > > On Wed, Aug 17, 2022 at 11:29:08AM +0200, Pali Roh=C3=A1r wrote: = =20 > > > > > > On Monday 08 August 2022 09:37:22 Tom Rini wrote: =20 > > > > > > > On Mon, Aug 08, 2022 at 09:51:49AM +0200, Marek Beh=C3=BAn wr= ote: =20 > > > > > > > > On Fri, 5 Aug 2022 18:20:19 -0400 > > > > > > > > Tom Rini wrote: > > > > > > > > =20 > > > > > > > > > On Fri, Aug 05, 2022 at 10:17:01PM +0200, Pali Roh=C3=A1r= wrote: =20 > > > > > > > > > > On Friday 05 August 2022 11:54:53 Tom Rini wrote: =20 > > > > > > > > > > > On Fri, Aug 05, 2022 at 05:51:35PM +0200, Pali Roh=C3= =A1r wrote: =20 > > > > > > > > > > > > On Friday 05 August 2022 11:44:00 Tom Rini wrote: = =20 > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 05:12:59PM +0200, Pali Ro= h=C3=A1r wrote: =20 > > > > > > > > > > > > > > On Friday 05 August 2022 11:03:40 Tom Rini wrot= e: =20 > > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:59:35PM +0200, Pal= i Roh=C3=A1r wrote: =20 > > > > > > > > > > > > > > > > On Friday 05 August 2022 10:47:31 Tom Rini = wrote: =20 > > > > > > > > > > > > > > > > > On Fri, Aug 05, 2022 at 04:21:24PM +0200,= Pali Roh=C3=A1r wrote: =20 > > > > > > > > > > > > > > > > > > On Wednesday 03 August 2022 12:13:18 To= m Rini wrote: =20 > > > > > > > > > > > > > > > > > > > On Wed, Aug 03, 2022 at 06:00:13PM +0= 200, Pali Roh=C3=A1r wrote: =20 > > > > > > > > > > > > > > > > > > > > On Tuesday 02 August 2022 06:58:26 = Tom Rini wrote: =20 > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 02, 2022 at 11:13:38A= M +0200, Pali Roh=C3=A1r wrote: > > > > > > > > > > > > > > > > > > > > > =20 > > > > > > > > > > > > > > > > > > > > > > Hello Tom! > > > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > > > > > Your commit de47ff536363289f92f= 85ed1e4901724d238432d ("Convert > > > > > > > > > > > > > > > > > > > > > > CONFIG_SYS_MPC85XX_NO_RESETVEC = to Kconfig") seems to be broken. =20 > > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > > > > I thought I had managed to mirror= the TPL/SPL/full usage that was there > > > > > > > > > > > > > > > > > > > > > prior, but apparently some got mi= ssed. =20 > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > > > Yea, conversion to Kconfig seems th= at was incorrect. =20 > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > > As the config files were just unclear= , but you seem to understand what > > > > > > > > > > > > > > > > > > > it's supposed to be, a patch to clean= it up would be most appreciated, > > > > > > > > > > > > > > > > > > > thanks. > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > > --=20 > > > > > > > > > > > > > > > > > > > Tom =20 > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > Broken is also commit d433c74eecdce1e49= 52ef4e8c712a9289c0dfcc2. Seems > > > > > > > > > > > > > > > > > > that all kconfig migration changes done= after that commit are broken. > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > I really do not have energy to investig= ate what and how was broken due > > > > > > > > > > > > > > > > > > to incorrect kconfig migration. > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > I did simple test. Applied following ch= ange: > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > diff --git a/include/configs/p1_p2_rdb_= pc.h b/include/configs/p1_p2_rdb_pc.h > > > > > > > > > > > > > > > > > > index a6523753d5ca..489f24df0ab1 100644 > > > > > > > > > > > > > > > > > > --- a/include/configs/p1_p2_rdb_pc.h > > > > > > > > > > > > > > > > > > +++ b/include/configs/p1_p2_rdb_pc.h > > > > > > > > > > > > > > > > > > @@ -624,3 +624,7 @@ __stringify(__PCIE_= RST_CMD)"\0" > > > > > > > > > > > > > > > > > > "bootm $norbootaddr - $norfdtaddr" > > > > > > > > > > > > > > > > > > =20 > > > > > > > > > > > > > > > > > > #endif /* __CONFIG_H */ > > > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > > > +#ifdef CONFIG_SDCARD > > > > > > > > > > > > > > > > > > +#error > > > > > > > > > > > > > > > > > > +#endif > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > And then called: > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > make CROSS_COMPILE=3Dpowerpc-linux-gnus= pe- P2020RDB-PC_defconfig u-boot.bin > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > And it failed, even when this defconfig= file is not SD card builds. =20 > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > Where is PBL in that case even then? =20 > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > > P2020 (and older) are pre-PBL boards, they = do not support NXP PBL > > > > > > > > > > > > > > > > header. =20 > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > Ah, OK, then it should just be removing TARGE= T_P2020RDB from the choice > > > > > > > > > > > > > > > on "Freescale PBL load location". > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > --=20 > > > > > > > > > > > > > > > Tom =20 > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > I just do not understand. > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > P10** and P20** do not support NXP PBL. They su= pport only pre-PBL and > > > > > > > > > > > > > > for SD card pre-PBL support I added option FSL_= PREPBL_ESDHC_BOOT_SECTOR. > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > But CONFIG_SDCARD is automatically set when SYS= _EXTRA_OPTIONS contains > > > > > > > > > > > > > > "SDCARD" string and CONFIG_SDCARD is used then = also in P10** and P20** > > > > > > > > > > > > > > SD-card version of SPL to load proper U-Boot. = =20 > > > > > > > > > > > > >=20 > > > > > > > > > > > > > So CONFIG_SDCARD was over-loaded? That's very fru= strating. That's what > > > > > > > > > > > > > needs to be corrected then. =20 > > > > > > > > > > > >=20 > > > > > > > > > > > > But it was correct, no? CONFIG_SDCARD ensures that = U-Boot is compiled in > > > > > > > > > > > > mode in which can be booted from SD card. Or what d= o you have in mind as > > > > > > > > > > > > purpose of this symbol? > > > > > > > > > > > >=20 > > > > > > > > > > > > The issue is that your Kconfig migration changes en= abled CONFIG_SDCARD > > > > > > > > > > > > also when building (parallel) NOR version of U-Boot= . =20 > > > > > > > > > > >=20 > > > > > > > > > > > To me, the biggest issue is that "CONFIG_SDCARD" exis= ts. It's very much > > > > > > > > > > > non-descriptive and that for some platforms it means = "we have NXP PBL" > > > > > > > > > > > and others means "we're booting from SDCARD". The for= mer should be > > > > > > > > > > > renamed to be descriptive, and the latter should re-u= se CONFIG_SD_CARD > > > > > > > > > > > which is still a bad name, but what everyone else use= s, so makes > > > > > > > > > > > renaming it later to something less bad easier. =20 > > > > > > > > > >=20 > > > > > > > > > > So I hope that you will do something with it. I already= spent lot of > > > > > > > > > > time to fix and improve powerpc support, but the result= is that my > > > > > > > > > > patches are on the list, mostly ignored; but changes wh= ich are breaking > > > > > > > > > > powerpc support are happily merging. In this state I'm = loosing any > > > > > > > > > > motivation to continue development as it is needed to d= o again to find > > > > > > > > > > out what new is broken. =20 > > > > > > > > >=20 > > > > > > > > > I'm not planning to try and further fiddle with those sym= bols. A > > > > > > > > > simple revert is not possible as CONFIG_SYS_EXTRA_OPTIONS= is gone. I > > > > > > > > > assume that Marek will be picking up your PowerPC patches= at this point, > > > > > > > > > so any further work you're doing in that area shouldn't b= e delayed. > > > > > > > > > I'll put re-examining this on my TODO list, but it's belo= w finishing my > > > > > > > > > CONFIG_SYS_* audit, and then renaming stuff to CFG_SYS. > > > > > > > > >=20 > > > > > > > > > You should fix whatever platforms you have access to and = ignore the > > > > > > > > > rest, I feel likely to be removing most of them shortly a= t this point. > > > > > > > > > =20 > > > > > > > >=20 > > > > > > > > I shall try to fix this on our platform by "reverting" thes= e to > > > > > > > > different names, so that there are no new CONFIG_ macros. = =20 > > > > > > >=20 > > > > > > > OK, thanks. I'll "fix" the corenet_ds platforms with a remova= l patch > > > > > > > soon, since they've been orphaned for a long while. =20 > > > > > >=20 > > > > > > Any progress on fixing this issue? Currently all this stuff is = not > > > > > > working in u-boot master due to broken kconfig migration. And a= ny > > > > > > continuation in kconfig migration just makes it worse and harde= r to fix > > > > > > later. =20 > > > > >=20 > > > > > I've removed the corenet_ds platforms now. =20 > > > >=20 > > > > I'm reminding this issue again. u-boot master branch is still broke= n. =20 > > >=20 > > > I don't really remember what the fix was at this point, but you should > > > fix whatever boards you have and care about as it's a matter of > > > selecting the correct option, yes? =20 > >=20 > > See: https://lore.kernel.org/u-boot/20220805142124.6swsha6aj62f33e3@pal= i/ > > Broken is Kconfig migration which you done. I wrote in that email simple > > test case how to check if it is OK or not. =20 >=20 > Yes, but I'm not un-migrating the symbol. As I think you're the only > person who cares about mpc85xx platforms right now, is your platform > working, or is there something that needs to be changed so that it does > work? >=20 He's not the only one. I am still rebasing Pali's patches on top of current master. Please give me some more time.