should a vendor layer override the base "u-boot" recipe?

should a vendor layer override the base "u-boot" recipe?

[Robert P. J. Day]

  sort of a policy question but i'm working with a vendor layer from
STMicroelectronics ("ST"), and that layer provides ST's version of
u-boot -- a recipe named "u-boot-stm32mp". fair enough, and they also
have an include file that makes that recipe the preferred provider:

  PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-stm32mp"

so, ideally, someone would not define their recipes to refer to u-boot
explicitly, but to virtual/bootloader.

  but i decided to build the "base" (OE) u-boot recipe just as a
baseline, and ran:

  $ bitbake u-boot

and was surprised that nothing further was done, and i noticed that it
tried to build ST's recipe, and then i noticed this:

  PREFERRED_PROVIDER_u-boot ??= "u-boot-stm32mp"

is that normal behaviour from a vendor? does that not mean i can't
even try to build OE's version of u-boot because ST's setting above
will hijack the recipe name?

  is this considered normal vendor behaviour?

rday

Re: [OE-core] should a vendor layer override the base "u-boot" recipe?

[Quentin Schulz]

Hi Robert,

On 1/20/26 2:36 PM, Robert P. J. Day via lists.openembedded.org wrote:
> 
>    sort of a policy question but i'm working with a vendor layer from
> STMicroelectronics ("ST"), and that layer provides ST's version of
> u-boot -- a recipe named "u-boot-stm32mp". fair enough, and they also
> have an include file that makes that recipe the preferred provider:
> 
>    PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-stm32mp"
> 
> so, ideally, someone would not define their recipes to refer to u-boot
> explicitly, but to virtual/bootloader.
> 
>    but i decided to build the "base" (OE) u-boot recipe just as a
> baseline, and ran:
> 
>    $ bitbake u-boot
> 
> and was surprised that nothing further was done, and i noticed that it
> tried to build ST's recipe, and then i noticed this:
> 
>    PREFERRED_PROVIDER_u-boot ??= "u-boot-stm32mp"
> 
> is that normal behaviour from a vendor? does that not mean i can't
> even try to build OE's version of u-boot because ST's setting above
> will hijack the recipe name?
> 
>    is this considered normal vendor behaviour?
> 

I don't understand what's abnormal there, can you explain what's 
bothering you?

You're including a BSP layer. This BSP layer provides you with include 
files for a specific architecture/SoC. This provides defaults for things 
your vendor tests, supports and maintains. This layer adds a recipe for 
their own U-Boot fork.

If you are including this specific architecture/SoC-specific include 
file, then you'll get those defaults. If you're building another 
machine, you'll not have those defaults.

You can always supersede those either at your machine conf level or any 
conf file (see the use of ??= which is the "weak weak" operator).

Imagine your vendor added support for a very recent SoC that upstream 
U-Boot hasn't merged yet, would you like to debug yourself why every 
image for your machine isn't compiling, or worse, why it isn't booting 
your image at all or would you rather have a sane default which is 
approved by your vendor?

BTW, this is what I've done in our layer too, see
https://git.embedded.cherry.de/yocto-layers/meta-cherry-es.git/tree/meta-bsp/conf/machine/jaguar.conf#n38
https://git.embedded.cherry.de/yocto-layers/meta-cherry-es.git/tree/meta-bsp/conf/machine/jaguar.conf#n40
for RK3588 Jaguar for example.

You can always override this in your machine conf if you want (or in any 
conf file).

Your vendor needs to have a U-Boot recipe that can replace the upstream 
U-Boot recipe (via the PROVIDES += "u-boot" stanza) so that you don't 
have to go and replace every u-boot dependency with u-boot-stm32mp for 
example. See u-boot in PREFERRED_PROVIDER_u-boot as 
PREFERRED_PROVIDER_virtual/u-boot if you prefer.

Cheers,
Quentin