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 084EAC54EAA for ; Fri, 27 Jan 2023 17:10:25 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id BEA16856E7; Fri, 27 Jan 2023 18:10:23 +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="lPcbje/d"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2A43185708; Fri, 27 Jan 2023 18:10:22 +0100 (CET) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 BFDBB856E7 for ; Fri, 27 Jan 2023 18:10:18 +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-qt1-x832.google.com with SMTP id e8so4583443qts.1 for ; Fri, 27 Jan 2023 09:10:18 -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=N4xtupT9VZrV0vKZOoW87/MMlQlNYQKcCGmiq50KUkE=; b=lPcbje/duBsdPJft4d8OcwfgHF1c4Bh1O4dphQ1bD9pXmFfQV/B5ENju2cSfjGljnZ 2KZ/NgHzwQS6kWODJa/irucuShWDcDuuQbHkegm2DF9j1bJDE5dH1vnxTDDXvTtYP1/M CCIMB8kxOb/0t6R7E1uq3+fx2/p2xdmo0TgnA= 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=N4xtupT9VZrV0vKZOoW87/MMlQlNYQKcCGmiq50KUkE=; b=CU+napVBZwxPR25Alg3edUbCbyj/ab+kGj2z+A06Y5uQHrrNGWG7gfyJ3wTFf7Zx9I Mn821WMySAXB6anMEoaFkPlYmhItE9qGOsl/C9J4oXsdOtnsTMUR9LXiXwB/F8G2BAe1 iDSOOzH8YJh39QmZlHW8PtMwaJTZnsJUSNM4+ppAILy7Zr0GrmhuB9gHmawhWHy429QS mYF96WhJqvyJ5LywRRwHFS+dAeMtG2Vpp9bDoKtxXbXIRyh2i6G5na2IYjqkUvvvx2fu 1Ea270w8TI7NK5/Yb9jOOd9nWU6HEm9XnDGcrVSKpe16tLi0gTIhDDG51WS24p0WG/FB aI6g== X-Gm-Message-State: AO0yUKXaPHmkn2qCi3IOJr3g5/idWh5iNRJbS2bGuBRTAM/L0ZceHexL zV8UuZvauTIMfsVPlOEtyKzqTA== X-Google-Smtp-Source: AK7set8dlGmo7JBjTAmOKudTJ2H+IjKHIkFcrquh+XUgOm6EK5xjqihOG8E4oJYpBM7xuJa8tMMWcQ== X-Received: by 2002:a05:622a:1a9e:b0:3b8:2119:ec59 with SMTP id s30-20020a05622a1a9e00b003b82119ec59mr5132777qtc.32.1674839417284; Fri, 27 Jan 2023 09:10:17 -0800 (PST) Received: from bill-the-cat (2603-6081-7b00-6400-bacc-4546-b75d-3c88.res6.spectrum.com. [2603:6081:7b00:6400:bacc:4546:b75d:3c88]) by smtp.gmail.com with ESMTPSA id s20-20020a05620a29d400b00715c2c5b492sm3195010qkp.128.2023.01.27.09.10.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Jan 2023 09:10:16 -0800 (PST) Date: Fri, 27 Jan 2023 12:10:14 -0500 From: Tom Rini To: Mario Kicherer Cc: u-boot@lists.denx.de, sbabic@denx.de, festevam@gmail.com, uboot-imx@nxp.com, daniel.schwierzeck@gmail.com, weijie.gao@mediatek.com, GSS_MTK_Uboot_upstream@mediatek.com, rick@andestech.com, ycliang@andestech.com Subject: Re: [PATCH v2 1/2] spl: spl_nor: add BOOT_DEVICE_NOR2 as alternative SPL_LOAD_IMAGE_METHOD Message-ID: References: <20230119152822.1214202-1-dev@kicherer.org> <20230119152822.1214202-2-dev@kicherer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cdJrivMLZKZyMT5F" 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 --cdJrivMLZKZyMT5F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 27, 2023 at 05:56:48PM +0100, Mario Kicherer wrote: > Hello Tom, >=20 > On 2023-01-26 20:17, Tom Rini wrote: > > This breaks a lot of platforms, as it only covers a few of the cases > > where BOOT_DEVICE_NOR is listed. I would also really like to see how > > this ends up being used in the board specific case as I do wonder if we > > can't solve this some other way that won't have impact so many other > > platforms. Thanks! >=20 > Hm, I did a grep through the source code and that were the only places > where the new value is used as part of an enum. BOOT_DEVICE_NOR is used > in more places but they also #define this themselves - if I did not > miss something. Yes, all of the platforms that define the value (since it roughly means "ROM set this value in something we can check") instead of enum'ing it still compile that file and now fail to build. > Furthermore, BOOT_DEVICE_NOR2 will not be used by default. A board has > to define its own board_boot_order() function like this to use the new > BOOT_DEVICE_NOR2 value: >=20 > void board_boot_order(u32 *spl_boot_list) > { > spl_boot_list[0] =3D BOOT_DEVICE_NOR; > spl_boot_list[1] =3D BOOT_DEVICE_NOR2; > } >=20 > If they do not explicitly add BOOT_DEVICE_NOR2, they should not be > affected by this patch, as far as I understood the code. I tried to > model this similar to the BOOT_DEVICE_MMC1 and _MMC2 values. >=20 > Then, they can also define an own spl_nor_get_uboot_base() like the > following that should return an address where U-Boot tries to load > a valid image: >=20 > unsigned long spl_nor_get_uboot_base(struct spl_boot_device *bootdev) > { > if (bootdev->boot_device =3D=3D BOOT_DEVICE_NOR) { > /* first address that is tried */ > return UBOOT_PARTITION_1_IN_NOR; > else if (bootdev->boot_device =3D=3D BOOT_DEVICE_NOR2) { > /* > * if loading of the first image failed for whatever > * reason, try this address as well: > */ > return UBOOT_PARTITION_2_IN_NOR; > } > } >=20 > With this patch, it is possible to provide a fallback U-Boot image like > above or to use an A/B slot scheme in case a bootloader update could be > necessary in the field in the future. Ah, OK. Keep in mind that MMC1/MMC2 are for different physical MMC devices on a given platform. I think this is more like the case where you should be able to override spl_nor_get_uboot_base at the board level to say if you're loading A or B? --=20 Tom --cdJrivMLZKZyMT5F Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmPUBW8ACgkQFHw5/5Y0 tyyO/Av7BPXuS+s4e09+UIc82Hn5BmmNXr+j5RzffZZ0rBi5mDoOmIJ7aqI8k9Os 9d8owAU5Cqbr066znuxocU81bgPVn+QzLiRcffkNeErk6aZ3M4hNXNHTRJydLJzZ Dix+E3To4vVeVg/tuYwMeAg2ruchUCGOYhV013qUIJYWVqus8+YpOgQ9cGRM4Z+H WXWlNz/sFl0A+0xDFB/plPsdFwedeMAvrnbuFxI/qzvySwGwaewQ5xC+/kpOryY5 cwIoJVSgNkLtSbQP2L+sd5mTNCb5wYKt4OfECuPOBoiCmB1pZj5UqYwyjRak4hSB wlmHXawyrLYDtnt66BnGIq45RSubSApmXuf7kdBw5agkTBE5sBUhgIpK/rdDMO4m ExJvhwHdb+jrkOQMHdbxh8LT2ZFWNfZR9UDTOcrw50ZClX/oW6pNR7YLwYi4iXYJ ZKekPyarokzX0jmLLotPLiCl22YN7q+wBBgr5DAXFoteIVlCRarCCyoZJUqvvVy+ lJU8iwzE =ZP/H -----END PGP SIGNATURE----- --cdJrivMLZKZyMT5F--