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 EBB37C54EAA for ; Fri, 27 Jan 2023 16:56:56 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8F0FF855D2; Fri, 27 Jan 2023 17:56:54 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=kicherer.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (1024-bit key; secure) header.d=kicherer.org header.i=@kicherer.org header.b="ZifxBAhk"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8555985706; Fri, 27 Jan 2023 17:56:52 +0100 (CET) Received: from mail.zeus06.de (www.zeus06.de [194.117.254.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id ED762855D2 for ; Fri, 27 Jan 2023 17:56:49 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=kicherer.org Authentication-Results: phobos.denx.de; spf=none smtp.mailfrom=dev@kicherer.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=kicherer.org; h= mime-version:date:from:to:cc:subject:in-reply-to:references :message-id:content-type:content-transfer-encoding; s=k1; bh=WDc vKcV4iQI0PYenYag1EOlA1scZHU262WTC4r6BE/8=; b=ZifxBAhkgsyGcJMBn7B iYWGbilFQwEcJ8oSNNQG3vltE2BaW4mK4Bd+55UV2AzKUUviemjlHjT7eBGuA1tX HA5y4JnqhFpvJeRSy71bIJBnFo9cFV4n8NEb7spjJg1Zn4+cX7yQnGLtQcECKV28 uHv54hjuSdntVw+2e16eOzCM= Received: (qmail 694113 invoked from network); 27 Jan 2023 17:56:48 +0100 Received: by mail.zeus06.de with ESMTPA; 27 Jan 2023 17:56:48 +0100 X-UD-Smtp-Session: l3s6476p2@Co5XwEHzqpXCdf4e MIME-Version: 1.0 Date: Fri, 27 Jan 2023 17:56:48 +0100 From: Mario Kicherer To: Tom Rini 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 In-Reply-To: References: <20230119152822.1214202-1-dev@kicherer.org> <20230119152822.1214202-2-dev@kicherer.org> Message-ID: X-Sender: dev@kicherer.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit 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 Hello Tom, 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! 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. 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: void board_boot_order(u32 *spl_boot_list) { spl_boot_list[0] = BOOT_DEVICE_NOR; spl_boot_list[1] = BOOT_DEVICE_NOR2; } 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. 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: unsigned long spl_nor_get_uboot_base(struct spl_boot_device *bootdev) { if (bootdev->boot_device == BOOT_DEVICE_NOR) { /* first address that is tried */ return UBOOT_PARTITION_1_IN_NOR; else if (bootdev->boot_device == BOOT_DEVICE_NOR2) { /* * if loading of the first image failed for whatever * reason, try this address as well: */ return UBOOT_PARTITION_2_IN_NOR; } } 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. Best regards, Mario