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 32260C4332F for ; Sat, 24 Dec 2022 16:13:51 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3E6D884FBF; Sat, 24 Dec 2022 17:13:49 +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="l3zzoYxt"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D4B858504A; Sat, 24 Dec 2022 17:13:47 +0100 (CET) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 915FC84D70 for ; Sat, 24 Dec 2022 17:13:44 +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-qt1-x832.google.com with SMTP id v14so3046089qtq.3 for ; Sat, 24 Dec 2022 08:13:44 -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=+zXldZ3pDpZ1PxCEDKweLy7pGLhaQOSHm+aoRnrXXV4=; b=l3zzoYxt78XqZNGgN1VnvFZ6VdqV+k+5qeyy72q6dxgKq+VJVr0/iuJPEiuix0AlLK NmChEPhdZoIu2s53U4Tcg4qH6V3d5iL3riIsWlTaDxvLxzLIR91WQt4xlC5Yn0Qm6u3p mTBkrTQHIAXtxC5IjSI2yPC1ZkrPvwTvWwWUc= 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=+zXldZ3pDpZ1PxCEDKweLy7pGLhaQOSHm+aoRnrXXV4=; b=GJbZESYGRcs4mIfdXdCQ4oqMu6zMg2fIZQhdPz+7UO1q/27VnsH5sH0Kz2wH00Z2CS hfi5Um14Xbueh0mP8QHz13wtV3Ho8lJy6Pt2fOBnV2XfcRcMIs0HQ5xvezBeAkmZEDlb pgnzx31L5sWL+utu1EuZddamZHm95KiDriqRv6skMMZ5Kjoa7Gb4SSoEATFgvlDj3mYU mEN69rZTpVE0UD2fL8i8r7niXdoeN1b2g++b2pwO4HJThviypKNJTQFAs0BbOm0MojKp 4TruN1gJkGX+93jTApl7XXXzVw+60hJ6AKDRJcufqE/PP5F74kkTylQctEItR+wg79m4 OJmg== X-Gm-Message-State: AFqh2kqmiKogGXtuVe0OeC/2ri6/tlfVA/ZemegXjOh2IEF/48ZK4k/1 sJMoz32MT62BKjGLpjU9EpqMtA== X-Google-Smtp-Source: AMrXdXuYwTSYjJJ2fcqAPhl5ssvJGkCxeTx5htwR6ouFIq5GOB+SFuBiPP5Le/ubFJ36YfbyKXNqRA== X-Received: by 2002:ac8:7cc:0:b0:3ab:67cc:e8fe with SMTP id m12-20020ac807cc000000b003ab67cce8femr11222437qth.27.1671898423100; Sat, 24 Dec 2022 08:13:43 -0800 (PST) Received: from bill-the-cat (2603-6081-7b00-6400-cc76-8437-1672-f49a.res6.spectrum.com. [2603:6081:7b00:6400:cc76:8437:1672:f49a]) by smtp.gmail.com with ESMTPSA id p16-20020a05620a057000b00704c1f4e756sm4256735qkp.14.2022.12.24.08.13.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Dec 2022 08:13:42 -0800 (PST) Date: Sat, 24 Dec 2022 11:13:41 -0500 From: Tom Rini To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: u-boot@lists.denx.de Subject: Re: Broken commit d433c74eecdce1e4952ef4e8c712a9289c0dfcc2 Message-ID: <20221224161341.GI3787616@bill-the-cat> References: <20221222074947.iqulzr3s77j5jbva@pali> <20221222142927.GK3787616@bill-the-cat> <20221222171306.2nzlippi6zcyhpiz@pali> <20221222173332.GM3787616@bill-the-cat> <20221222175640.kqtofoxaupfchfby@pali> <20221222182250.GO3787616@bill-the-cat> <20221223191014.yqcwxlibn2kxfqn3@pali> <20221223191832.GH3787616@bill-the-cat> <20221223213900.krjk6qtarowyf2dd@pali> <20221223223446.4sdpqsmnmcn4mcr7@pali> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OTyR3ZUjodGbNkAk" Content-Disposition: inline In-Reply-To: <20221223223446.4sdpqsmnmcn4mcr7@pali> 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 --OTyR3ZUjodGbNkAk Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 23, 2022 at 11:34:46PM +0100, Pali Roh=E1r wrote: > On Friday 23 December 2022 22:39:00 Pali Roh=E1r wrote: > > On Friday 23 December 2022 14:18:32 Tom Rini wrote: > > > On Fri, Dec 23, 2022 at 08:10:14PM +0100, Pali Roh=E1r wrote: > > > > On Thursday 22 December 2022 13:22:50 Tom Rini wrote: > > > > > On Thu, Dec 22, 2022 at 06:56:40PM +0100, Pali Roh=E1r wrote: > > > > > > On Thursday 22 December 2022 12:33:32 Tom Rini wrote: > > > > > > > I'm sorry you're frustrated here. I'm also frustrated here be= cause the > > > > > > > #ifdef games that PowerPC used, in a number of places have be= en very > > > > > > > hard to un-wrap so that we can have something other than a ho= me-grown > > > > > > > build system. > > > > > >=20 > > > > > > I was already trying to reduce it too, some patches I sent, som= e other I > > > > > > was preparing and some other are part of turris 1.x platform, w= hich is > > > > > > waiting there for 6 months. I planned to apply removal of MMC s= ymbols to > > > > > > other P1/P2 boards, like it is in turris patch, but after turri= s patch > > > > > > is merged... which did not happen yet. > > > > >=20 > > > > > Right, and thanks for what you've done already. > > > > >=20 > > > > > > > And I've tried to take your other feedback in to > > > > > > > consideration, which has resulted in a large number of symbol= s being > > > > > > > moved to CFG_... instead of Kconfig, as you're right, it wasn= 't the > > > > > > > right mechanism for them. > > > > > > >=20 > > > > > > > So, is it really just the 3 platforms that use p1_p2_rdb.h th= at need > > > > > > > neither SDCARD nor SPIFLASH for the NAND and no extra suffix = defconfigs? > > > > > > > Or is it the P1010RDB ones too? > > > > > >=20 > > > > > > It applies for e500 v1/v2 cores, which is cpu/mpc85xx in u-boot= and > > > > > > predates P3 platform. If there are not some suspicious symbol n= ames then > > > > > > it should match any board which uses ARCH_MPC85??? or ARCH_P1??= or > > > > > > ARCH_P2020 symbol. > > > > > >=20 > > > > > > P2040 and T???? do not have e500 v1/v2 cores (they have e500mc = or e5500 > > > > > > or e6500), so you can ignore these. > > > > >=20 > > > > > OK. > > > > >=20 > > > > > > Is there any tool which can list all defconfig files which defi= nes some > > > > > > of those symbols, including transitionally? > > > > >=20 > > > > > With the caveat of only symbols in Kconfig, tools/moveconfig.py -= b will > > > > > make a database that you can consult with -f. That takes both SYM= BOL and > > > > > ~SYMBOL to list configs with SYMBOL enabled or disabled, respecti= vely. > > > > > And you can chain them together. For example: > > > > > $ ./tools/moveconfig.py -f ARCH_P1010 SDCARD > > > > > 8 matches > > > > > P1010RDB-PB_36BIT_NOR P1010RDB-PA_NOR P1010RDB-PB_SDCARD P1010RDB= -PB_36BIT_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PA_36BIT_SDCARD P1010RDB-PB= _NOR P1010RDB-PA_SDCARD > > > > > $ ./tools/moveconfig.py -f ARCH_P1010 ~SDCARD > > > > > 8 matches > > > > > P1010RDB-PA_NAND P1010RDB-PB_SPIFLASH P1010RDB-PB_36BIT_SPIFLASH = P1010RDB-PA_36BIT_NAND P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_SPIFLASH P101= 0RDB-PB_NAND P1010RDB-PB_36BIT_NAND > > > >=20 > > > > Ok, I tried to build database and list of the affected defconfig fi= les: > > > > (all except T, P3+ and P204x) > > > >=20 > > > > $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kcon= fig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools= /moveconfig.py -f $arch SDCARD; done | grep -v ' matches\|^$' > > > > P1010RDB-PB_36BIT_NOR P1010RDB-PA_SDCARD P1010RDB-PB_NOR P1010RDB-P= B_SDCARD P1010RDB-PA_36BIT_NOR P1010RDB-PB_36BIT_SDCARD P1010RDB-PA_NOR P10= 10RDB-PA_36BIT_SDCARD > > > > P1020RDB-PC P1020RDB-PD_SDCARD P1020RDB-PC_SDCARD P1020RDB-PC_36BIT= P1020RDB-PD P1020RDB-PC_36BIT_SDCARD > > > > P2020RDB-PC_SDCARD P2020RDB-PC_36BIT P2020RDB-PC_36BIT_SDCARD P2020= RDB-PC > > > >=20 > > > > So it means that these defconfigs are broken and CONFIG_SDCARD for = them > > > > must be turned off: > > > >=20 > > > > P1010RDB-PB_36BIT_NOR > > > > P1010RDB-PB_NOR > > > > P1010RDB-PA_36BIT_NOR > > > > P1010RDB-PA_NOR > > > > P1020RDB-PC > > > > P1020RDB-PC_36BIT > > > > P1020RDB-PD > > > > P2020RDB-PC_36BIT > > > > P2020RDB-PC > > > >=20 > > > >=20 > > > > These defconfigs have already CONFIG_SDCARD turned off: > > > >=20 > > > > $ for arch in `git grep 'config ARCH' arch/powerpc/cpu/mpc85xx/Kcon= fig | sed 's/.* //' | grep -v 'ARCH_T\|ARCH_P[345]\|ARCH_P204'`; do ./tools= /moveconfig.py -f $arch ~SDCARD; done | grep -v ' matches\|^$' > > > > socrates > > > > MPC8548CDS MPC8548CDS_legacy MPC8548CDS_36BIT > > > > P1010RDB-PB_36BIT_NAND P1010RDB-PB_NAND P1010RDB-PA_36BIT_SPIFLASH = P1010RDB-PB_SPIFLASH P1010RDB-PA_36BIT_NAND P1010RDB-PA_NAND P1010RDB-PB_36= BIT_SPIFLASH P1010RDB-PA_SPIFLASH > > > > P1020RDB-PC_NAND P1020RDB-PC_36BIT_SPIFLASH P1020RDB-PD_SPIFLASH P1= 020RDB-PC_SPIFLASH P1020RDB-PD_NAND P1020RDB-PC_36BIT_NAND > > > > P2020RDB-PC_SPIFLASH P2020RDB-PC_36BIT_SPIFLASH P2020RDB-PC_NAND P2= 020RDB-PC_36BIT_NAND > > > > qemu-ppce500 > > > >=20 > > > > And seems that no of them is sd card related (hopefully). > > >=20 > > > Thanks! Does the following look reasonable to you > > > (CONFIG_FSL_FIXED_MMC_LOCATION was enabled due to SDCARD)? If so I'll > > > make a proper patch next: > >=20 > > Just to note that possibility of booting pre-PBL devices from SD or SPI > > is described in document AN3659 - Booting from On-Chip ROM (eSDHC or eS= PI): > > https://www.nxp.com/docs/en/application-note/AN3659.pdf > > In P2020 documentation it is named "On-chip boot ROM-eSDHC". > >=20 > > >=20 > > >=20 > > > diff --git a/boot/Kconfig b/boot/Kconfig > > > index 4a001bcee851..424ad0e466da 100644 > > > --- a/boot/Kconfig > > > +++ b/boot/Kconfig > > > @@ -724,16 +724,19 @@ config RAMBOOT_PBL > > > For more details refer to doc/README.pblimage > > > =20 > > > choice > > > - prompt "Freescale PBL load location" > > > + prompt "Freescale PBL (or predecessor) load location" > > > depends on RAMBOOT_PBL || ((TARGET_P1010RDB_PA || TARGET_P1010RDB_P= B \ > > > || TARGET_P1020RDB_PC || TARGET_P1020RDB_PD || TARGET_P2020RDB) \ > > > && !CMD_NAND) >=20 > And it should depends on CPU/ARCH, not at list of boards... as this is > bootrom/CPU feature, not board feature. So maybe on CONFIG_MPC85xx? But > needs to be ensured that SDCARD symbol is not enabled in defconfigs > where it is not. So, with the benefit of hindsight, I re-ran the before/after world build of the original bad migration, to see what changed where. That gives us: P2020RDB-PC P2020RDB-PC_36BIT P1020RDB-PC P1020RDB-PC_36BIT P1020RDB-PD P1010RDB-PA_36BIT_NOR P1010RDB-PA_NOR P1010RDB-PB_36BIT_NOR P1010RDB-PB_NOR T1024RDB_NAND T2080RDB_NAND T2080RDB_revD_NAND T2080QDS_NAND And aside from p1_p2_rdb those differences are just print related. But, that excludes include/configs/. And then if we look at what sets CONFIG_SDCARD in include/configs/ there might be a few pad sizes that then get migrated wrong, but I'm not sure. --=20 Tom --OTyR3ZUjodGbNkAk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmOnJTEACgkQFHw5/5Y0 tyzLuAv/ZJGFPRdiGwEG0t0pzZWNDSbGR+RzlnRMbpJJHIwc0pEZiTTRYmUbYfal jaNgYxjgTVtyYMEpMOUPxiTvpe4N+Xd/LtKtsqrzqACtHLnMUIKm8Bzh7ARGuNSg sZ3MtdYF0E4KSI6XS3loIFhHzXj7rmApERgUdtYNW+xGiy3tKknBcpP2X2CG69vW sjynE7KjvS3yyD83otKNK+kjlrwykB1fXmjmjpIQsfGqzxeCfGCNFeO9baF9sThM yWBx52zjBvSzos/wihGVgNHpbnkz6YjNjStr1/2CSzS0mBxHHlDcstVxcowW2ebx oBwZJYvu6QT9MYo+bJa0vOqrX+vbOP2kxDsLpIIdn6wMgNLCtLZKoMJHvKpjyjbG 0poGWUCmhYSvpJyopAGwAhnhL0MK7b3IBCX6aqrED11geexOSzUrKMCHurlxAObG TjmNHhQHPRdGkV8vLPNvUQaogEMtFBRI3WDaVoo+b50Q8FgkhpmOpJAdhVJ5z6ui LiYkF/Qk =3R4n -----END PGP SIGNATURE----- --OTyR3ZUjodGbNkAk--