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 BEE69C433FE for ; Fri, 30 Sep 2022 16:56:10 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5AC0084D9C; Fri, 30 Sep 2022 18:56:08 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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=chromium.org header.i=@chromium.org header.b="geD9Kqaq"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 154E984DA5; Fri, 30 Sep 2022 18:56:07 +0200 (CEST) Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [IPv6:2001:4860:4864:20::33]) (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 C496E84D9A for ; Fri, 30 Sep 2022 18:56:03 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-12803ac8113so6100417fac.8 for ; Fri, 30 Sep 2022 09:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=TmeFI56omegVORu/44rDOjFDKZam6C1lFa5zsNiMqVs=; b=geD9Kqaqp23Loi3pHu4gh+Mr4T3gv0Pl0zbSqM3rLhjp5PKTchWb8WYDKt8LSsRoja JqwOTLy9JIM5+AFszWVCOZHzr4YOIUQYcdTSx6E/sqqlqFlG2bnEM7r3Ux3vKCDG+ayd INSFUqGGtGDKS6MwDlooHMIA/qjIS2bp/vqMc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=TmeFI56omegVORu/44rDOjFDKZam6C1lFa5zsNiMqVs=; b=3LktysIsP7qsnHALOHiP2LBjH8fOjjF+btjqmDt6sV0a8rzBKKHQ8EEypI3jlYfDwh DEG3Zfw8ps2qM4J9RakOWeLO9HsH5QxaH2Xj+Jzx1hbdCdQ4s9QIqgi7JlpyKzyKyxSQ 9VZDE5ZAi9axdz0tWzAv1c4IPGdHTEpYq1ysT+6Q7VPf4Ua0GNVFDyi4QmaQe3eng5wi SG6ahMsI/10wX8XKG2b79WYK14RxcAqBvMt6h/E5PnOIFoe65MCw6+PUbMSxwcqoHKW+ V7mf0Vh3riWn/EHlJyRe4217FK50fKNZ6ak0jAFXEuV7Qe6Ew2j4zwVhv8JYmB71GxgL xFOw== X-Gm-Message-State: ACrzQf3/hQHCeWCL5JUlmwHj8LeaPLRW/u/SZibFDLc4uRCzJlnD1dqw uROMowVV0kXH+CqG7fIOGTmSkaH8pjHNlKBXons4Iw== X-Google-Smtp-Source: AMsMyM7OOiGLJswMUg7dlv2DvLnWjBjLBCE62bbVPCLfOL7hi+nqHqTh+27I0tKSHQsiSfG//5GjEU90TpbJNnvQ+gw= X-Received: by 2002:a05:6870:390b:b0:127:42b1:e5d0 with SMTP id b11-20020a056870390b00b0012742b1e5d0mr5540419oap.64.1664556962146; Fri, 30 Sep 2022 09:56:02 -0700 (PDT) MIME-Version: 1.0 References: <20220925150248.2524421-1-sjg@chromium.org> <20220925150248.2524421-32-sjg@chromium.org> <20220930162829.GV3044094@bill-the-cat> <20220930163900.GX3044094@bill-the-cat> <20220930165058.GY3044094@bill-the-cat> In-Reply-To: <20220930165058.GY3044094@bill-the-cat> From: Simon Glass Date: Fri, 30 Sep 2022 10:55:50 -0600 Message-ID: Subject: Re: [PATCH 31/45] spl: Allow multiple loaders of the same type To: Tom Rini Cc: U-Boot Mailing List , Alper Nebi Yasak , =?UTF-8?B?TWFyZWsgQmVow7pu?= , =?UTF-8?Q?Pali_Roh=C3=A1r?= , Stefan Roese 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.6 at phobos.denx.de X-Virus-Status: Clean Hi Tom, On Fri, 30 Sept 2022 at 10:51, Tom Rini wrote: > > On Fri, Sep 30, 2022 at 10:45:01AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Fri, 30 Sept 2022 at 10:39, Tom Rini wrote: > > > > > > On Fri, Sep 30, 2022 at 10:37:26AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Fri, 30 Sept 2022 at 10:28, Tom Rini wrote: > > > > > > > > > > On Sun, Sep 25, 2022 at 09:02:34AM -0600, Simon Glass wrote: > > > > > > > > > > > At present we only support a single loader of each time. Extra ones are > > > > > > > > > > Of each type not time, I assume. > > > > > > > > > > > ignored. This means that only one BOOT_DEVICE_BOARD can be used in the SPL > > > > > > image. > > > > > > > > > > > > This is inconvenient since we sometimes want to provide several > > > > > > board-specific drivers, albeit at different priorties. Add support for > > > > > > this. > > > > > > > > > > > > This should have no functional change for existing boards. > > > > > > > > > > To be clearer here. Today I can build am335x_evm_defconfig, and it will > > > > > have support for (among others) X/Y-MODEM and SD/MMC booting, and if SPL > > > > > loads via SD card, it will look at that same slot and find U-Boot, or > > > > > fail. > > > > > > > > > > This patch doesn't change that, yes? > > > > > > > > > > A later part of this series makes it possible, but not default? > > > > > > > > That's right, there is no change for existing boards, since they only > > > > have only loader of each type. But it allows boards to change that and > > > > have two loaders for a single type. This is done later for sandbox, > > > > but it would actually be useful for a few other boards too, e.g. where > > > > there are two board-specific ways of booting and we want to try both. > > > > > > I'm not following now, sorry. Can you elaborate on the example you're > > > talking about please, either for sandbox or what it would look like on a > > > hardware platform? > > > > For sandbox we want to boot with VBE if available, but if not then we > > want to use the existing loader, which just runs the next executable > > (e.g. spl/u-boot-spl). Both of these are board-specific methods. The > > current enum of boot methods is a bit of a pain, e.g. we have things > > like this in ARM's spl.h because we cannot have more than one loader > > of a certain type: > > > > BOOT_DEVICE_MMC1, > > BOOT_DEVICE_MMC2, > > BOOT_DEVICE_MMC2_2, > > > > BTW the loaders already have a priority which we can use to choose > > which is more desirable. > > OK, so it's so that we could do VBE, but fall back if not possible? Is > that really advisable? The historical reasoning behind that enum is that > we want to know if we came from $X we want to use-or-fail the next stage > also being $X. We do have a few cases I believe where the board knows > "if $X then $Y" instead for some specific use cases. Yes, but that is implemented using the firmware handoff thing. https://patchwork.ozlabs.org/project/uboot/patch/20220925150248.2524421-43-sjg@chromium.org/ We can of course enforce this, such that when VBE is active it has to be used. At present errors from spl_load_image() are ignored, so it has to be done in the loader itself. But we could change that. Regards, Simon