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 76A6DC4332F for ; Thu, 22 Dec 2022 14:15:10 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C49948536D; Thu, 22 Dec 2022 15:15:07 +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="NUt9blV5"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A430F8533D; Thu, 22 Dec 2022 15:15:06 +0100 (CET) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 30F068536D for ; Thu, 22 Dec 2022 15:15:03 +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-vs1-xe34.google.com with SMTP id 128so1775381vsz.12 for ; Thu, 22 Dec 2022 06:15:03 -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=LTkJQ5ZrbjnUrBc7ZNxoAf8zG65sNtCkTcg7HSfPiSs=; b=NUt9blV5js6DtBaOCcZokvi2k7B0yM2etBohQdHNm7Okd82QkgbNxTwp7ZiFQ9LM6i 0+tSkEOLC5O6kfzRXPr4vTreS5cITqZt0YkCbCBiOnCovu6J4AalEBfVtHiqHYYBnkkQ 7uer9y04NNOYaf9AN8Gb8tkIoK6Zqd+mmaInc= 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=LTkJQ5ZrbjnUrBc7ZNxoAf8zG65sNtCkTcg7HSfPiSs=; b=oChO4JYHSJ1XiIuYfjseCDFPwYiI+WwrKsG+G/OwmVkkeNaCYwnFLPKGSZXhLgAmHV dKVjyObmkQ/2z8IFI1ksuMzAfIoSjyBdRz6E+u31aiuYs54CDg0AGDRbzA2fmMW22ndl fXHAD6e6Za3T+j1VWuli5USI3RdaYD3pxO3hf4weN5wuGCTy3OMbhseLxkAM2/aT/Eid tHLEoea5VVwwjraCxL3Hrlxx3443QFxaePMkxInQWHcEP8i/9YcaHWjpOU3bw2BUuknU RWdgLQFwneK/Gubb+HL2SDMz5cHPoUzYywxtx03BCgvlhwpKzxvjReVqHD133m4eef7I ckBw== X-Gm-Message-State: AFqh2kpwqEtO9vdp5MmSvRH7z5FTSRYMwRkKoi9ydcGheghlCuIJA00K XuEMTfB5GiNkHoqyqj73e3pXLw== X-Google-Smtp-Source: AMrXdXsCUpXUUNUZoCXqp91HYn7vnbpmmnZ1IERtM+dlokDukQDfJ4pMKCKl73Z/7XbqEENEXFxpEQ== X-Received: by 2002:a05:6102:419:b0:3b0:6b56:cbe5 with SMTP id d25-20020a056102041900b003b06b56cbe5mr2417814vsq.34.1671718501795; Thu, 22 Dec 2022 06:15:01 -0800 (PST) Received: from bill-the-cat (2603-6081-7b00-6400-0489-d0bf-dcad-62f5.res6.spectrum.com. [2603:6081:7b00:6400:489:d0bf:dcad:62f5]) by smtp.gmail.com with ESMTPSA id j6-20020a05620a288600b006fc9847d207sm347677qkp.79.2022.12.22.06.15.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Dec 2022 06:15:01 -0800 (PST) Date: Thu, 22 Dec 2022 09:14:59 -0500 From: Tom Rini To: Nikita Shubin Cc: Simon Glass , linux@yadro.com, Nikita Shubin , Pali =?iso-8859-1?Q?Roh=E1r?= , Heinrich Schuchardt , Marek =?iso-8859-1?Q?Beh=FAn?= , Quentin Schulz , u-boot@lists.denx.de Subject: Re: [PATCH] Makefile: add -W for BINMAN_ALLOW_MISSING Message-ID: <20221222141459.GI3787616@bill-the-cat> References: <20221216092745.31266-1-nikita.shubin@maquefel.me> <20221219112145.0708131d@redslave.neermore.group> <20221219133630.GL3787616@bill-the-cat> <20221222100116.5cc8a248@redslave.neermore.group> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PjaO40uToM9mp/aP" Content-Disposition: inline In-Reply-To: <20221222100116.5cc8a248@redslave.neermore.group> 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 --PjaO40uToM9mp/aP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 22, 2022 at 10:01:16AM +0300, Nikita Shubin wrote: > Hello Tom! >=20 > On Mon, 19 Dec 2022 08:36:30 -0500 > Tom Rini wrote: >=20 > > On Mon, Dec 19, 2022 at 11:21:45AM +0300, Nikita Shubin wrote: > > > Hello Tom and Simon! > > >=20 > > > On Sat, 17 Dec 2022 14:38:30 -0700 > > > Simon Glass wrote: > > > =20 > > > > +Tom Rini > > > >=20 > > > > We do actually want to report the failure, since it means that the > > > > image will not function. This was a recent change requested by a > > > > few people. =20 > > >=20 > > > It doesn't make sense to me - if i am passing "--allow-missing" than > > > binman shouldn't fail drastically, cause i literally told him "It's > > > okay if files are missing". What purpose does it have now, it we > > > are failing regardless we are providing this flag or not ? > > >=20 > > > This breaks old behaviour by the way, when passing "--allow-missing" > > > for missing blobs produced a warning instead of error. > > > =20 > > > >=20 > > > > Note that buildman looks for the message 'Some images are > > > > invalid' and either returning 103, or 0 if -W is given. > > > >=20 > > > > There is no attempt to produce a special exit code from the > > > > Makefile. It generally returns 2 (as per 'man make'), which is > > > > why buildman has this extra processing. =20 > > >=20 > > > Well, there are only 3 codes for make and 2 indicates any failure: > > >=20 > > > "A status of two will be returned if any errors were encountered." > > > (c) > > >=20 > > > This new behaviour looks the same with or without > > > BINMAN_ALLOW_MISSING flag from top point of view: > > >=20 > > > With BINMAN_ALLOW_MISSING=3D1: > > > Some images are invalid > > > make[1]: *** [Makefile:1114: .binman_stamp] Error 103 > > > make[1]: Leaving directory '/home/maquefel/workshop/overlord/u-boot' > > > make: *** [Makefile:271: u-boot/u > > >=20 > > > $ echo $? > > > 2-boot-nodtb.bin] Error 2 > > >=20 > > > Without BINMAN_ALLOW_MISSING: > > >=20 > > > binman: Filename 'fw_dynamic.bin' not found in input path > > > (.,.,./board/syntacore/scr7_elct,arch/riscv/dts) > > > (cwd=3D'/home/maquefel/workshop/overlord/u-boot') make[1]: *** > > > [Makefile:1114: .binman_stamp] Error 1 make[1]: Leaving directory > > > '/home/maquefel/workshop/overlord/u-boot' make: *** [Makefile:271: > > > u-boot/u-boot-nodtb.bin] Error 2 > > >=20 > > > $ echo $? > > > 2 > > >=20 > > > So that's the difference if build is failing either way ? =20 > >=20 > > So, with what is in master right now, BINMAN_ALLOW_MISSING=3D1 should > > work as intended, while it did not at its introduction. Please > > confirm if your use cases work now, or not.=20 >=20 > They don't actually, a few iterations ago i didn't even needed > BINMAN_ALLOW_MISSING (now it's clear for me that i never needed it), as > make produced only a warning and not a error. Yes, it would only ever produce a warning before. > I have kernel and ramdisk sections in my binman file and FIT image is > fully functional even if they are missing. >=20 > And now there is no way to tell u-boot not to fail if some blobs are > missing. What do you mean? That's what BINMAN_ALLOW_MISSING=3D1 does: $ make CROSS_COMPILE=3D~/.buildman-toolchains/gcc-12.2.0-nolibc/aarch64-lin= ux/bin/aarch64-linux- BINMAN_ALLOW_MISSING=3D1 -sj pine64_plus_defconfig al= l -sj;echo $? =2E.. Image 'main-section' is missing external blobs and is non-functional: atf-b= l31 scp /binman/u-boot-sunxi-with-spl/fit/images/atf/atf-bl31: Please read the section on ARM Trusted Firmware (ATF) in board/sunxi/README.sunxi64 /binman/u-boot-sunxi-with-spl/fit/images/scp/scp: SCP firmware is required for system suspend, but is otherwise optional. Please read the section on SCP firmware in board/sunxi/README.sunxi64 Some images are invalid 0 $ Is what I get on top of master right now. > > The problem we needed to > > solve was the one that by default previously, you could run "make > > fooboard_config all", not have BL31/etc available, get a warning > > printed and a zero exit code, leading to non-obvious failures if you > > build indirectly (buildroot, yocto/OE, etc). > >=20 >=20 > May be they shouldn't use BINMAN_ALLOW_MISSING when building u-boot at > all then ? >=20 > Or can we, at least, have some BINMAN_REALLY_ALLOW_MISSING option or > simply passing some flags with BINMAN_OPTS for example ? >=20 > Through: > -W, --ignore-missing Return success even if there are missing > blobs/bintools (requires -M) >=20 > seems to have really good synergy with: >=20 > -M, --allow-missing Allow external blobs and bintools to be > missing >=20 > For BINMAN_ALLOW_MISSING. Yes, that's what BINMAN_ALLOW_MISSING=3D1 does. If top of tree master doesn't work for you, can you please post a patch so that the rest of us can replicate the failure and see what to do next? Thanks. --=20 Tom --PjaO40uToM9mp/aP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmOkZl8ACgkQFHw5/5Y0 tyzGLQwAgU1HELQoGP6y2QmZyhIeQJBJrsK4CGkkzf2B6EAncD+4wLpJ2wTMCfh+ w0f0s+Aso0cDZ0pGu+pS6I5yatI6kxAXHtBrtKQvhVIy0DzUFaoy98+wJXde/WBZ m4hyd3f3Uqfu4pumuHEy3cTYT0/EfLQxhuv15LZGmkolZSPpYFc5AVCGAA1hDsr5 eEAXCyASzqcXP9LgLz/RLLvxoAcbY1LP+9i8og58z8qn7asFnvPshxZWZ0KeLvX5 ANVeY9z+2AGBidgSGyvM13Ay/etJjndgcxAgRormeD+GnOzUUNxL8UwN2MEV1CfM cwWUwj1D5c/dN7xsQDxaH//Ku12xT2EA87ImEQ0JLC7nGBJPTlD6RX5woiiRvdaQ zWeLHsKAhu1rW7GA7NJGwPW4Fg8jD/yN8EelY5FB4ZiMrnk9XambjHnjb7fAHQxI hdT/EL/V702m0KExuUOibR90wnmB/YOe7yBDO+JROmH237s/NvG/DMdeAp70PWRi EJCdxdES =z0M5 -----END PGP SIGNATURE----- --PjaO40uToM9mp/aP--