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 42DFAC6FD18 for ; Fri, 31 Mar 2023 08:40:13 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 0561785E44; Fri, 31 Mar 2023 10:40:11 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com 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=gmail.com header.i=@gmail.com header.b="j1eoVCkf"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E7C1785B6E; Fri, 31 Mar 2023 10:40:08 +0200 (CEST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 3E88F85E44 for ; Fri, 31 Mar 2023 10:40:05 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pbrobinson@gmail.com Received: by mail-lj1-x22b.google.com with SMTP id s20so1953581ljp.7 for ; Fri, 31 Mar 2023 01:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680252004; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=C1VJFFyO5HwP/FbOGUYpVo4miOHsHHAWHJejo60tVeg=; b=j1eoVCkfXr3atzo6HkAIGP41A94HBQqDYSueiiiJAjsNepvpIaKQ6KRtwlif6UJIdG iWSVjf4gaCH/s1DCr9G74F9SfsPTBsNlGU1OTiikKcIwe171e8N5+3GV8G/AIBkLYNmw tJz+SgY4k8UJCnudMgchwkMbA8YX9teSuC/k/W8KWwCRo6qm9ff5LfWW6GwiVYUY78Bk rQEcL2W1HLe9Z+DehhuqEXkoYUpquRvwC8JqbiwSEfEkWw9h4YcqUjJEzutUUf6wjgSC QvJwBxXKsjKZNMf2izESHqi2EywWNPg9IEsIW4RrA3KCaxdSrfKWGxvFLQA5iim3qBMi 1J4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680252004; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=C1VJFFyO5HwP/FbOGUYpVo4miOHsHHAWHJejo60tVeg=; b=lMkylQg4QDrI3kBlTodzSZgLDOrdtcoq7844cQpurJvEbA+/plMQC18oTbJ/gEkdni myHsGOwLGM3CtzhRFbuOmdOELMmn4q79oGJbMItO4eStEnQ/bCrV0yk/yWYgMRo5t73f s/Sg0U+0UyO8g86rEsSArtgMJioREinSbxZozHYyvN2mZDdN8coYUi/6gcM2gKp7hJ/V 0gCK6WZE5RgKB9keztZ76JeamB1G3ppTL39Hjjth0P+VCRRdei6Eu2gvF0374O4chE4+ fzxC+kSz1vHbStS311RpT5ohhQPHnrCjGuqhXgpw/4irjvKzMmjF64i4zk4/2ZhHKDxq gXxw== X-Gm-Message-State: AAQBX9dcwe1v+7pGLfC4Bj8bjeRDfdduM5hhj3Tb8mcDieGQYHnGHFhz XryfzIS9Awbmp5s+YKMNfxisoS6iKQexA1n6LJA= X-Google-Smtp-Source: AKy350bGgItHQ2et4DklRd1trbGzvg/rsOIaPtSE4huGS9MVlu2lvw5FUQHOdeLoPHFwOfziZR5rTp9JSq3o8BI4lVM= X-Received: by 2002:a2e:a556:0:b0:29b:d43f:f68f with SMTP id e22-20020a2ea556000000b0029bd43ff68fmr4542797ljn.5.1680252004508; Fri, 31 Mar 2023 01:40:04 -0700 (PDT) MIME-Version: 1.0 References: <20230324205816.2035181-1-trini@konsulko.com> <20230329145401.GE6083@bill-the-cat> In-Reply-To: From: Peter Robinson Date: Fri, 31 Mar 2023 09:39:53 +0100 Message-ID: Subject: Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration To: Simon Glass , Rob Herring Cc: Tom Rini , u-boot@lists.denx.de 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.8 at phobos.denx.de X-Virus-Status: Clean Hi Simon, > > > > > > I took a look at Simon's v3 series to fix the rk3399 bootstd migration, > > > > > > and it changed too much for everything else. I took about half of that > > > > > > series and then reworked a few things. Now only rk3399 platforms change > > > > > > at all and aside from bootcmd changes, the only thing is they now > > > > > > disable true/test/sysboot/showvar/false/exit commands as those were > > > > > > being pulled in from distro and now we don't set that flag. I think the > > > > > > way I changed how we enable BOOTSTD_DEFAULTS should make it easier to > > > > > > perform more SoC migrations. > > > > > > > > > > Thanks for digging into this. I haven't seen any comments on the rpi > > > > > conversion, so perhaps people could test that? > > > > > > > > I was planning on looking at that once 2023.04 was out but TBH I have > > > > wasted so much time over the last few cycles dealing with regressions > > > > through a bunch of these series that I now have so little time for > > > > enhancements I now shy away. I know a lot of these series should > > > > improve things in the future but they don't feel like when there's > > > > unnecessary changes for things that are clearly untested. > > > > > > I too am unhappy with how some of these have gone. The _intent_ here is > > > that getting the current "boot generic distro" framework is complex / > > > error prone, and we can do better. Unfortunately the first set of > > > platforms to switch to this are Rockchip and I think there was overlap > > > there with platforms that got broken at the end of the v2023.01 cycle to > > > fix other platforms, and then those sets of platforms flipped early in > > > v2023.04 and took until -rc2? to get resolved. Which was less than > > > ideal. > > > > > > > There's also a lot of change for changes sake, for example the > > > > rockchips ATF binaries needed is called bl31.elf by the default output > > > > of the ATF build process, for others it's bl31.bin, binman for what > > > > ever reason has changed that to be atf-bl31, now I have to change the > > > > entire build process to be able to work out what is what on a board by > > > > board basis to be able to set the required variable to be able to > > > > specify the ATF where previously it "just worked (tm)"..... I suppose > > > > there is some perceived goal and improvement here but with both my > > > > "U-Boot device maintainer" and "distro maintainer" hats on, both of > > > > which I do in my own spare time, I currently fail to see it and I end > > > > up. > > > > > > I wish I knew where to talk to with ATF / TF-A to get some agreed upon > > > naming scheme going as one of the things that is very frustrating is > > > getting the names and combinations of everything else that's required > > > Just Right for every chip. And feedback that things aren't working is > > > appreciated, since we do need to make things easier. > > > > In all of the various make_fit_atf.py the various vendors specified > > them, this is the case for the rockchip one [1]. This is the case for > > the Allwinner boards [2] but the rockchip ports have missed this so it > > also should be fixed for GA. Can you do a patch to fix this regression please and then specify the correct pieces in the binman section then? > > A side point is that binman should not be storing firmware build > > specifics in the device tree which is a means of describing the > > hardware, This really needs to be fixed as it really isn't the right > > place for that sort of things. I suspect a file in arch/arm/mach- > > is likely a better location, or if it's board specific in the board/ > > sub directory. > > Sorry, I don't agree with that at all. We store configuration > information in devicetree in firmware as this seems to be best format > for it, particularly with the growing number of firmware components > that need to share this information at runtime. The layout of firmware > is an important part of the system. We are still figuring out the > flows though. Also I have not attempted to upstream the binman > binding. I am very open to ideas on how best to do that. Rob what's your thoughts on the binman firmware build pieces being in device tree and the process on upstreaming the bindings? Regards, Peter > > [1] https://source.denx.de/u-boot/u-boot/-/blob/v2023.01/arch/arm/mach-rockchip/make_fit_atf.py#L227 > > [2] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/sunxi-u-boot.dtsi#L64