Hi Tom, On Fri, 30 Sept 2022 at 10:51, Tom Rini <tr...@konsulko.com> 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 <tr...@konsulko.com> 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 <tr...@konsulko.com> 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-...@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
