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 C72B5C433F5 for ; Tue, 1 Feb 2022 15:42:57 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 28610831B5; Tue, 1 Feb 2022 16:42:55 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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=chromium.org header.i=@chromium.org header.b="A7b+2CqN"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3F520831F9; Tue, 1 Feb 2022 16:42:53 +0100 (CET) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 9AC4180FDD for ; Tue, 1 Feb 2022 16:42:48 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=sjg@google.com Received: by mail-vs1-xe33.google.com with SMTP id t20so16589646vsq.12 for ; Tue, 01 Feb 2022 07:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rJCu+EIJ5+iNQ73szNOox/K5Q1dawl/YhlXLCzJBU+w=; b=A7b+2CqNzrlTm4d/YPEqFpZdiBcTh13Lb+nv3pXyThwFERdrcCNsEARtbWOUrOcpiB 8h3s0xo+XIh3sdOHYOcbGNNRGQGSswNlwngklV5j0+n87x/o95zL4L9Q98u7eYNxgp5z oPySdDTnhVEzyR0erMVWdFkrz0YY7AkUBqYCE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rJCu+EIJ5+iNQ73szNOox/K5Q1dawl/YhlXLCzJBU+w=; b=vI4gFnmfNFpD/IoXCsL5YWXy+lAAk2IU077OFrFOCo9qw7zKWBhhr0O+2940KCfkuN cUXNvWys/B/ZmWuw3838tpuojKH8H7GQBR6oq3b/2v4FjBqVJ9pKHeeFLJGtiauQRUM4 HtJqRUsU71jjoJATKWjJ3GbE0HMmoDziTVlHr0ajw3v3zpwrvCgq2WwkcnxAHVj09jbl FPgCh089ATUgDtonIhxD/1a94wNgdILQ65uhgBbqc7wiAGRDjry0qrJk77AMAFFTC36+ D8YN06z22vu/BgozXbNMKAcLtldZQc2O5r3A3LMieSP42f6cDGS9bbggSrnZOgZx8cK6 XBkg== X-Gm-Message-State: AOAM5332J+jBMwGX7rnNRsp5zuGhx3Y9AdkIkBRIyvb2Hp6cZKADto9c VLjgvsq3PP6YQJFwvFZvA8uONFS5n95Pi2feLJn7cQ== X-Google-Smtp-Source: ABdhPJxEZEub9kph5jvETyGG/AeWjGb+Si6s1DJsOaFDxdKASy9OEB23CcpNQfBL2zflYImii1PNBHqx4UAPc3rbLfU= X-Received: by 2002:a67:e0de:: with SMTP id m30mr9740560vsl.51.1643730166858; Tue, 01 Feb 2022 07:42:46 -0800 (PST) MIME-Version: 1.0 References: <20220131161544.GZ7515@bill-the-cat> <20220131180001.GC7515@bill-the-cat> <20220131204039.GG7515@bill-the-cat> <20220131220541.GH7515@bill-the-cat> <20220131232533.GK7515@bill-the-cat> <20220131233253.GL7515@bill-the-cat> In-Reply-To: From: Simon Glass Date: Tue, 1 Feb 2022 08:42:35 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR To: Tom Rini Cc: U-Boot Mailing List , Michal Simek , huang lin , Jeffy Chen , Kever Yang , "NXP i . MX U-Boot Team" , =?UTF-8?B?TWFyZWsgQmVow7pu?= , Masahiro Yamada Content-Type: text/plain; charset="UTF-8" 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.5 at phobos.denx.de X-Virus-Status: Clean -Philipp Hi Tom, On Tue, 1 Feb 2022 at 07:05, Simon Glass wrote: > > Hi Tom, > > On Mon, 31 Jan 2022 at 16:32, Tom Rini wrote: > > > > On Mon, Jan 31, 2022 at 06:25:33PM -0500, Tom Rini wrote: > > > On Mon, Jan 31, 2022 at 03:59:08PM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > (yes Mark I am trying to stop further boards going in that use the > > > > shell scripts) > > > > > > > > On Mon, 31 Jan 2022 at 15:05, Tom Rini wrote: > > > > > > > > > > On Mon, Jan 31, 2022 at 02:22:41PM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Mon, 31 Jan 2022 at 13:40, Tom Rini wrote: > > > > > > > > > > > > > > On Mon, Jan 31, 2022 at 12:57:57PM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Mon, 31 Jan 2022 at 11:00, Tom Rini wrote: > > > > > > > > > > > > > > > > > > On Mon, Jan 31, 2022 at 10:27:41AM -0700, Simon Glass wrote: > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > On Mon, 31 Jan 2022 at 09:15, Tom Rini wrote: > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote: > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 31 Jan 2022 at 07:24, Tom Rini wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > More than a year after this migration message appeared, we still have new > > > > > > > > > > > > > > boards being added with this option. Add a check against this. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > > > > > > > > > > > > > > > Please just make this an error in checkpatch.pl instead. > > > > > > > > > > > > > > > > > > > > > > > > I couldn't think of a way of doing that...do you have an idea? > > > > > > > > > > > > > > > > > > > > > > Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt > > > > > > > > > > > and initrd relocation") updates the check I had for fdt_high/initrd_high > > > > > > > > > > > being in the file at all to only be for additions. And yes, I check > > > > > > > > > > > every PR for new checkpatch ERROR lines and only ignore the ones for > > > > > > > > > > > code imported from other projects. > > > > > > > > > > > > > > > > > > > > Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for > > > > > > > > > > certain boards, so there is no need to mention it anywhere in the > > > > > > > > > > patch. Also someone could adjust the condition in the Kconfig to add > > > > > > > > > > other boards. > > > > > > > > > > > > > > > > > > Then you want something a bit more like the fdt|initrd_high check now, > > > > > > > > > along with updating the help around SPL_FIT_GENERATOR to note that this > > > > > > > > > option is deprecated, is the path forward then I think. > > > > > > > > > > > > > > > > I'm still a bit lost. > > > > > > > > > > > > > > > > What I want: break the build if someone adds a new board that uses > > > > > > > > SPL_FIT_GENERATOR > > > > > > > > > > > > > > > > What you are offering: checkpatch check for people adding that option > > > > > > > > > > > > > > > > But the patch doesn't generally include that option. > > > > > > > > > > > > > > > > I can certainly mention in the Kconfig help that the option is > > > > > > > > deprecated, but without checking if it is defined for a NEW board, I > > > > > > > > cannot prevent it from growing. > > > > > > > > > > > > > > > > What am I missing? Can you be more specific? > > > > > > > > > > > > > > How do you add a new board that enables SPL_FIT_GENERATOR without > > > > > > > "SPL_FIT_GENERATOR" being in the resulting patch, other than being > > > > > > > ARCH_ZYNQMP/ARCH_ROCKCHIP ? > > > > > > > > > > > > Well that's the case I am most concerned with, actually. Also, someone > > > > > > might add a new condition to SPL_FIT_GENERATOR. > > > > > > > > > > For the current cases, we just need to get them migrated since it's all > > > > > the same logic? So it would I think be a one-and-done thing. For a new > > > > > > > > Yes I think so and some of them are done. These are what I can find: > > > > > > > > ./arch/riscv/lib/mkimage_fit_opensbi.sh > > > > ./arch/arm/mach-zynqmp/mkimage_fit_atf.sh > > > > ./arch/arm/mach-imx/mkimage_fit_atf.sh > > > > ./arch/arm/mach-rockchip/make_fit_atf.py > > > > > > > > but they are not used by that many boards. > > > > > > > > I feel that the amount of pending migration is somewhat overwhelming > > > > and we should take a stronger line in mainline. > > > > > > > > Perhaps I should send a patch to simply remove the option? Would that > > > > be acceptable? > > > > > > Is there something technically preventing their migration to buildman? > > > Looking over examples for imx8* conversions, it's just adding a binman > > > node and describing things there, yes? > > > > Poking at this a bit more, it seems like the outstanding imx platforms > > to be converted still have pending patches and it's just part of the > > general imx backlog. The riscv one isn't used and should be removed. > > That leaves rockchip and zynqmp needing conversion. Michal has already > > commented in this thread and I'll leave it to him to say how long he > > needs to see how long zynqmp needs to update. That leaves Rockchip. > > Ah good! One option might be that I could try to convert > chromebook_bob, then see if we can just apply it to everything? > > +Kever Yang again for that but it is New Year over there It seems that rk3399 uses bl31.elf and splits out the sections into pieces. What a mess! I wonder if that is necessary for ATF to work? It seems to do the same for TEE. Regards, Simon