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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#229737):
https://lists.openembedded.org/g/openembedded-core/message/229737
Mute This Topic: https://lists.openembedded.org/mt/117362611/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
