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 15D85C00140 for ; Fri, 12 Aug 2022 21:01:28 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 42090848A8; Fri, 12 Aug 2022 23:01:26 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=amarulasolutions.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=amarulasolutions.com header.i=@amarulasolutions.com header.b="MuxLkLOj"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9150B848A8; Fri, 12 Aug 2022 23:01:24 +0200 (CEST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 755A684856 for ; Fri, 12 Aug 2022 23:01:20 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=amarulasolutions.com Authentication-Results: phobos.denx.de; spf=none smtp.helo=mail-wm1-x329.google.com Received: by mail-wm1-x329.google.com with SMTP id h1so1085220wmd.3 for ; Fri, 12 Aug 2022 14:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=913MTfTWT4/pyQilmr2fNN7e1Gbeuc3x3NRMdZJTQsI=; b=MuxLkLOjEgLC3Ca6JmOhMeacOTMArj2tMAXEwxuMrZInMV5Taq3AI/ibMvFzHYJu6e X9iaTqmpi/B1eFbyRV4cG5GI5iF1m8zxsQafGWz2v7AMahIhYx44NkntQvCXcq1xchtf B77KOHnaZVbqSN/GJME8VFduN9Gf7YvIOcwpw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=913MTfTWT4/pyQilmr2fNN7e1Gbeuc3x3NRMdZJTQsI=; b=vVrsPgeo3KAzC2qXIgJtI3I6bSx9oCJd0euSoQlVzrRhf2P6hrLRWC7+ij3rJFiu9X PH+c7vJh6T+Y+Lk4ZfDJnBOBanZzTvfZPrQYK68+PUaAaSeg0d/4gulILGxQ7D5y4Tv7 veK386h3S24z1zlLxoxBfyw8PRoeKwAkva5IGSRmk8zuZkGBWLUh82+dGzGL6XZv4fPw kNuiT71AxIgTsLzBe9ca1HyX6+m2klP58tffFmIcnMWsBHuFUFRzVUkbCDd2X92CmPiM vih8ttXFufUADKRNKPTekpnjfUQAoO6G4RdWP/G3uDi0upnblUA3xIlRZOW60PCBM8bI sqQw== X-Gm-Message-State: ACgBeo2mKR77Fi9Zl2g6f0NsIcpBIyhsgYYnhQU1bfJXQ8fX847Zoqqy Gw/+OBf/FT2B7JYorIQr9oG4Zg== X-Google-Smtp-Source: AA6agR6VfJLKEHsHOVHekL3NCgZSS5xMAunKyb/WskQ8PQge82ZPfB0Lt03pxbEXK9KAovjS+Wx6Og== X-Received: by 2002:a05:600c:1ca0:b0:3a5:3703:2a97 with SMTP id k32-20020a05600c1ca000b003a537032a97mr9833559wms.23.1660338079981; Fri, 12 Aug 2022 14:01:19 -0700 (PDT) Received: from pwmachine.localnet (85-170-37-153.rev.numericable.fr. [85.170.37.153]) by smtp.gmail.com with ESMTPSA id q9-20020adff509000000b0021efc75914esm354581wro.79.2022.08.12.14.01.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Aug 2022 14:01:19 -0700 (PDT) From: Francis Laniel To: Holger Brunck , Tom Rini Cc: Aleksandar Gerasimovski , "u-boot@lists.denx.de" , Marek Behun , Michael Nazzareno Trimarchi , Simon Glass , Wolfgang Denk , Harald Seiler , Heiko Schocher Subject: Re: [RFC PATCH v4 28/28] board: keymile: common: Use environment to store IVM_* variables. Date: Fri, 12 Aug 2022 23:01:18 +0200 Message-ID: <4760895.31r3eYUQgx@pwmachine> In-Reply-To: <20220620173324.GP2484912@bill-the-cat> References: <20220616223158.9225-1-francis.laniel@amarulasolutions.com> <20220620173324.GP2484912@bill-the-cat> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 Hi. Le lundi 20 juin 2022, 19:33:24 CEST Tom Rini a =E9crit : > On Mon, Jun 20, 2022 at 04:08:32PM +0000, Holger Brunck wrote: > > > > > On Fri, Jun 17, 2022 at 12:31:58AM +0200, Francis Laniel wrote: > > > > > > These boards used set_local_var() to store some variables as lo= cal > > > > > > shell. > > > > > > They then used get_local_var() to retrieve the variables values. > > > > > >=20 > > > > > > Instead of using local shell variables, they should use > > > > > > environment ones (like a majority of board). > > > > > > So, this patch converts using local variables to environment on= es. > > > >=20 > > > > why do we need to change that? It is intended that we use this hush > > > > variable infrastructure from u-boot (common/hush.c) for our IVM data > > > > and not the standard env. We read the IVM at boot time and store th= ese > > > > values in RAM. It is not intended to store them permanently in the > > > > flash or wherever the environment is saved. Especially in our case = we > > > > have some boards where the environment is in a i2c EEPROM and we do= n't > > > > want to write down to the EEPROM each time when the board is starti= ng. > > >=20 > > > So, the whole series is about updating hush to bring in a new baseline > > > version of the shell, from busybox. > >=20 > > Ok. > >=20 > > > > > > Signed-off-by: Francis Laniel > > > > > > > > > > > > --- > > > > > >=20 > > > > > > board/keymile/common/common.c | 8 ++++---- > > > > > > board/keymile/common/ivm.c | 9 +-------- > > > > > > 2 files changed, 5 insertions(+), 12 deletions(-) > > > > > >=20 > > > > > > diff --git a/board/keymile/common/common.c > > > > > > b/board/keymile/common/common.c index 3999f48719..72939af36e > > > > > > 100644 > > > > > > --- a/board/keymile/common/common.c > > > > > > +++ b/board/keymile/common/common.c > > > > > > @@ -219,7 +219,7 @@ static int do_setboardid(struct cmd_tbl > > > > > > *cmdtp, int > > > > >=20 > > > > > flag, int argc, > > > > >=20 > > > > > > unsigned char buf[32]; > > > > > > char *p; > > > > > >=20 > > > > > > - p =3D get_local_var("IVM_BoardId"); > > > > > > + p =3D env_get("IVM_BoardId"); > > > > > >=20 > > > > > > if (!p) { > > > > > > =09 > > > > > > printf("can't get the IVM_Boardid\n"); > > > > > > return 1; > > > > > >=20 > > > > > > @@ -228,7 +228,7 @@ static int do_setboardid(struct cmd_tbl > > > > > > *cmdtp, int > > > > >=20 > > > > > flag, int argc, > > > > >=20 > > > > > > env_set("boardid", (char *)buf); > > > > > > printf("set boardid=3D%s\n", buf); > > > > > >=20 > > > > > > - p =3D get_local_var("IVM_HWKey"); > > > > > > + p =3D env_get("IVM_HWKey"); > > > > > >=20 > > > > > > if (!p) { > > > > > > =09 > > > > > > printf("can't get the IVM_HWKey\n"); > > > > > > return 1; > > > > > >=20 > > > > > > @@ -272,14 +272,14 @@ static int do_checkboardidhwk(struct cmd_= tbl > > > > >=20 > > > > > *cmdtp, int flag, int argc, > > > > >=20 > > > > > > * first read out the real inventory values, these values are > > > > > > * already stored in the local hush variables > > > > > > */ > > > > > >=20 > > > > > > - p =3D get_local_var("IVM_BoardId"); > > > > > > + p =3D env_get("IVM_BoardId"); > > > > > >=20 > > > > > > if (!p) { > > > > > > =09 > > > > > > printf("can't get the IVM_Boardid\n"); > > > > > > return 1; > > > > > > =09 > > > > > > } > > > > > > rc =3D strict_strtoul(p, 16, &ivmbid); > > > > > >=20 > > > > > > - p =3D get_local_var("IVM_HWKey"); > > > > > > + p =3D env_get("IVM_HWKey"); > > > > > >=20 > > > > > > if (!p) { > > > > > > =09 > > > > > > printf("can't get the IVM_HWKey\n"); > > > > > > return 1; > > > > > >=20 > > > > > > diff --git a/board/keymile/common/ivm.c > > > > > > b/board/keymile/common/ivm.c index 67db0c50f4..e266d7ce81 100644 > > > > > > --- a/board/keymile/common/ivm.c > > > > > > +++ b/board/keymile/common/ivm.c > > > > > > @@ -44,14 +44,7 @@ static int ivm_calc_crc(unsigned char *buf, = int > > > > > > len) > > > > > >=20 > > > > > > static int ivm_set_value(char *name, char *value) { > > > > > >=20 > > > > > > - char tempbuf[256]; > > > > > > - > > > > > > - if (value) { > > > > > > - sprintf(tempbuf, "%s=3D%s", name, value); > > > > > > - return set_local_var(tempbuf, 0); > > > > > > - } > > > > > > - unset_local_var(name); > > > > > > - return 0; > > > > > > + return env_set(name, value); > > > >=20 > > > > this means we are now writing always down to the permanent environm= ent > > > > or? And this I would really like to avoid in our case. > > >=20 > > > Note that "env_set" does not force a save of the running environment. > >=20 > > Ah yes you are right. But still for the first boot of our board we will > > call saveenv to store an initial environment and with this change it > > would also write down the IVM data which is currently only stored > > temporary in RAM. > >=20 > > > These variables will be exposed to the CLI run-time, which I am not s= ure > > > if they are today, so if the user then does "saveenv" they will be > > > written. That I think would be a functional difference. > >=20 > > yes exactly and I wonder if this functionality will be also possible af= ter > > the rework. I mean our use case (even it seems we are the only ones usi= ng > > it) is quite useful I think. We read out inventory data from an EEPROM > > and they are parsed and temporary stored in RAM and then we are able to > > use them as any other environment variables without the need to store > > them permanently. I also would like to avoid this as the data should be > > permanently in the IVM only and not stored a second time permanently in > > flash. >=20 > So, I'll start by noting that the environment variable flag support > isn't as well documented as I would like. But my super quick glance > makes me wonder if ENV_FLAGS_VARACCESS_WRITEABLE does what you're > thinking about, and if not, if it would be useful to extend the flag > support to include a "hidden" flag, or otherwise way to indicate that > variables A/B/C should never be saved. This could be useful for other > cases as well. Again, sorry for the late reply. To be honest, this board is the only one which presents this behavior. I will think about a mechanism to handle your use case. Nonetheless, as you are the exception and this series begins to be a bit bi= g I=20 think in a first time I will not address it. I will just add these patches to make the CI happy, but I will mark them as= =20 "do not merge". So, we can merge this series and you can still use the old hush shell, as I= do=20 not think we plan about making the new version the default right now. What do you think? Does it seem acceptable for you?