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 61C87C433EF for ; Wed, 20 Jul 2022 01:18:05 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 852DB83FAD; Wed, 20 Jul 2022 03:18:01 +0200 (CEST) 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="ombg8Hj1"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9E9C783FEA; Wed, 20 Jul 2022 03:17:59 +0200 (CEST) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 DE87683ACA for ; Wed, 20 Jul 2022 03:17:56 +0200 (CEST) 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-qv1-xf2d.google.com with SMTP id mz20so663351qvb.0 for ; Tue, 19 Jul 2022 18:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=NoyqacJbTtbzhn/TnNLKbWjKjqBYTxTgBW5jvMiCm4I=; b=ombg8Hj14CRqdKYYkRJAuVJyHM/3v4p63PWHPK8oC38yPZQ5so1FpwwgvAWDDVK/Ur 3fuAOvK0Pn+mm9Odua/m0pxIahbWNt7J6C5+2UavUwcn+uVxgyUYM3xpnGq8T9H6CjGe D+OzYfxVorWzOgXS7uCh3NGQ/mnjDA3s6M4Co= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=NoyqacJbTtbzhn/TnNLKbWjKjqBYTxTgBW5jvMiCm4I=; b=4qgyM/IkWGBOn5WylNGvtb96M1kjaNrkQg4tN3zQlpwk74rLGyVTlx3kjzfjOGBOfn YeLM/Sxk099i3F7WWSTpB0KNW+U33dJwqJpUnHxjIKFTxw9MKDWRzy4DyJJ9NTcZBAWC JJqzaveAxhkrb/g/RMerm53opqP4XNiWd2CB2P114A7g2FsaWn+xy158Q+lwr1u9fGww lMH2QXfzdkchmSVFu+7HSIuY3cf0gXp5AAkDkr4aXOnfD1xN5FldvE1LhqK5DABV/caY 8iNi6FXdeeREMdbZGNF9A1d9LJgviSiTCrn9pMsvV9fefDZ8UU2DIXOufV3lO6M78BY3 3kRg== X-Gm-Message-State: AJIora8VomMIhjUUX2QZdMpIzni757sr0T6j8IH/aMkBRLlCXEPAWgmy 1NJcoRHWys+9xiiGx4A82l/QqA== X-Google-Smtp-Source: AGRyM1sOUIjhQNnGptyvEyeJhKqFuj8zciy5F+jQUud/PQrzZ2DUDBwR3TlLyCwlFw0pO106nuicTg== X-Received: by 2002:a05:6214:d8b:b0:473:8dff:d2a2 with SMTP id e11-20020a0562140d8b00b004738dffd2a2mr26716961qve.14.1658279875677; Tue, 19 Jul 2022 18:17:55 -0700 (PDT) Received: from bill-the-cat (cpe-65-184-195-139.ec.res.rr.com. [65.184.195.139]) by smtp.gmail.com with ESMTPSA id d24-20020a05620a167800b006b5cb5d2fa0sm7051387qko.1.2022.07.19.18.17.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Jul 2022 18:17:54 -0700 (PDT) Date: Tue, 19 Jul 2022 21:17:52 -0400 From: Tom Rini To: Jassi Brar Cc: Jassi Brar , Ilias Apalodimas , Michal Simek , Sughosh Ganu , u-boot@lists.denx.de, Heinrich Schuchardt , Takahiro Akashi , Patrick Delaunay , Patrice Chotard , Simon Glass , Bin Meng , Etienne Carriere , Masami Hiramatsu Subject: Re: [PATCH v5 19/23] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox Message-ID: <20220720011752.GP1146598@bill-the-cat> References: <20220609123010.1017463-1-sughosh.ganu@linaro.org> <20220609123010.1017463-20-sughosh.ganu@linaro.org> <20220718210031.GG1146598@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mWc/4OXktgxu/9TL" Content-Disposition: inline In-Reply-To: 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 --mWc/4OXktgxu/9TL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2022 at 10:23:08AM -0500, Jassi Brar wrote: > On Mon, Jul 18, 2022 at 4:00 PM Tom Rini wrote: > > On Mon, Jul 18, 2022 at 10:31:56AM -0500, Jassi Brar wrote: >=20 > > > > > > > > > + > > > > > > > > > +#define PLAT_METADATA_OFFSET 0x510000 > > > > > > > > > +#define PLAT_METADATA_SIZE (sizeof(struct devbox_metad= ata)) > > > > > > > > > + > > > > > > > > > +struct __packed devbox_metadata { > > > > > > > > > + u32 boot_index; > > > > > > > > > + u32 boot_count; > > > > > > > > > > > > > > > > There is the whole bootcount infrastructure for this. I thi= nk it would be much > > > > > > > > better to use that framework instead of creating parallel o= ne. > > > > > > > > > > > > > > > Yes, this goes too. > > > > > > > > > > > > Is bootcount really suited for this case? > > > > > > AFAIK bootcount either requires device specific registers (whic= h won't > > > > > > reset on reboots), or an environment you can write data to. > > > > > > But what if a user wants to disable writing the env variables a= nd the > > > > > > device doesn't have a set of registers we can use? > > > > > > > > > > > Maybe it should be moved in 'struct fwu_mdata' ? > > > > > > > > I was mostly thinking on moving this count as another 'bootcount' > > > > method. So in case the user has disabled writing evn variables but= he > > > > is booting with EFI he can use that. > > > > > > Sorry, not sure I understand.... IIUIC there has to be some persisten= t storage. > > > > No, there just has to be "somewhere" to do the counting. We've got a > > DDR backed driver, for example. So yes, I think we should try and use > > the bootcount framework here. > > > OK, for platforms that can preserve ram across reboot, using > non-persistent storage can work. > My platform neither preserves ram, nor has any warmreset-proof > registers. So I have to choose between saving the bootcount in efi-env > or in vendor specific structure next to the metadata. I prefer > metadata because it is common to all stages of boot. Any corrections > to this approach? What I'm trying to say is that we have an abstraction for counting the number of times the system has booted since something reset the counter to zero, to signal the system is up and functional. I'll leave the details of how it's used here, and how / what backend is used or created for it up to everyone else on the thread. --=20 Tom --mWc/4OXktgxu/9TL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmLXV70ACgkQFHw5/5Y0 tyxDtgv9E/HtvZFm+Ym/2PgGX2tK4+Xqb+/LMS814Wxq+Tq2usvOW+6MBJGrNlhN kpA3W33X94LyVsLfooAHcS4qQQCTbH8vFbZsM9m7MDNrcWU3SLWYf8aVRj+oHaQ9 EVBlhuhjqrqlydUC2rx3Tax8wgN/3jIYhncQRWus09g0j979KUgnotWbgGy6GIp/ Ic3oIxqgXp5crFBYzs4zlP7t6euS+r1VBapgOxhAMdQoEvWzGKQSkQqx/RhxKt53 UHR0gGnq6f++t8YqbJyEG3ieQ1KcrG9svecx6NIrXi0UF7QUMkKduavzvn6yWtE6 fkGz2k9SSf8RtTtFJW6eBWmcZgj0bqcGxHVqEtIAhNYf8v0MRnAuexJBkHMCy6x+ FftGOteATf1w0EMkLHsI0nstyklCCLsI17bEBgIA29uO1nUvbdkJhFb0gK3RiJlH /6XrT/MC00XX1d5aHQFNKiE6h+s8j2XQeqaTtKKOqPEMcJtL3sXSdjERHnBcQHpZ Bp90/zJ5 =ucNG -----END PGP SIGNATURE----- --mWc/4OXktgxu/9TL--