There is currently an issue with exclusivity for software with the
same use cases (e.g., PROVIDES), and potential confusion for software
with similar use cases.  This is especially problematic for the Arm
boot flow, as there are a number of pieces of competing
software/firmware that stack on top of each other, and this boot flow
gives them similar names.  I believe it is a problem on x86 and others
as well.

The boot flow in a typical Arm system looks something like:

SCP -> TF-A -> EDK2 -> grub

However each one of those pieces _could_ be interchanged with an
alternative.  For example, u-boot instead of tianocore, systemd-boot
instead of grub (or neither if booting via u-boot), etc.  Grouping
like software, looks to me like:

Control Processor Firmware:
SCP
MCP

Secure world Firmware:
TF-A
TF-M
Standalone-MM

Non-secure world firmware:
EDK2/tianocore
u-boot

Boot manager:
grub
systemd-boot
efibootmgr


The current PROVIDES are:

u-boot
PROVIDES = "virtual/bootloader"

that's it...

My suggestions are roughly the names of the categories above.  So:

SCP/MCP = "virtual/control-processor-firmware"
TFA/TFM = "virtual/secure-firmware"
EDK2/u-boot = "virtual/boot-firmware"
grub, etc = "virtual/boot-manager"


These are different from what is there now for u-boot.  So, I don't
think there should be a name collision with legacy layers.

If these pieces were uniquely in meta-arm, I could easily address them
there.  However, given that some are in oe-core (and potentially in
other places), I would like some feedback on the PROVIDES names and an
agreement on them (if possible) to help address this issue.

Thanks,
Jon
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#164329): 
https://lists.openembedded.org/g/openembedded-core/message/164329
Mute This Topic: https://lists.openembedded.org/mt/90442900/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to