Slides: How to write a usable BSP :: Yocto Project Dev Day at OSS/ELC-E 2024 :: pretalx
Notes from the talk:
-
BSP is not a demo
-
in you told me 2007 that Sato would still be used in 2024, we may have done something differently
-
A truly usable BSP should be more like legos
-
flexible building blocks
-
able to build something vendors never considered
-
-
Modular layers
-
Bag of bricks = BSP layer
-
only does hardware enabling
-
should not be putting opengl into every image
-
core-image-base should just work, no unexpected dependencies – should not pull in video stuff
-
-
Instructions = Distro layer
- meta-unicorn-demo
-
(BSP and Distro are decoupled – you don’t need the Distro layer)
-
Want to be able to use BSP instead of fighting it
-
consider BBFILES_DYNAMIC
-
always run
yocto-check-layers -
add new layers OpenEmbedded Layer index
-
Please don’t fork poky as part of your BSP – all BSP layers should just work with stock Poky.
-
-
Machines
-
name machine after name on board instead of SOC
-
MACHINE_FEATURES
-
-
Modular recipes
-
linux-yocto, u-boot, trusted-firmware-a, op-tee
-
designed to be used by other BSPs
-
-
Work Upstream – Mo Forks Mo Problems
-
the longer you sit the harder it will be and the more bitter your customers get as recipes get more and more out of date.
-
consider the implications of shipping an unmaintained kernel to customers who have very strong opinions on security issues.
-
-
Modern
-
Listen to your users or you’ll lose them
-
Encourage and embrace the community
-
accept patches – don’t have an unmaintained git repo
-
any scripts that test the BSP should be public
-
-
Don’t ship your source code in BSP layer