topic Re: Best practices for customizing Yocto BSP in i.MX Processors

Best practices for customizing Yocto BSP

stian — Fri, 11 Nov 2016 09:25:49 GMT

I'm new to Yocto, and would appreciate some pointers to best practices, as well as corrections of possible misconceptions.

I have a custom carrier board, which uses the Variscite VAR-SOM-MX6 module which contains an iMX6, DDR, NAND, eMMC, WiFi, BT, touch screen interfaces and so on. Variscite provides a BSP which supports these units together with a carrier board.

However, we need to change at least the following aspects:
- Base the distribution on a minimal image, with added packages as necessary (e.g. shell and standard Linux utilities, but no graphical software, web server etc)
- No screen/keyboard
- Custom device tree (GPIO mux setup etc)
- Custom kernel configuration (enable drivers for devices on the carrier board)
- Custom script configuration (e.g. network setup)

The goal is to be able to efficiently maintain and update these changes, as well as get updates from Variscite when necessary, and finally being able to create images for distribution.

I imagine there are several ways to achieve this, and would like opinions on which ones are more feasible (or even possible), and of course other ways if I have missed some.

1. Use Variscite's BSP, make all changes in local build directory (local.conf)
2. Copy Varisiscite's BSP and modify to our needs. This one seems to be the most straight-forward, but seems less elegant, and makes it hard to track updates from Variscite
3. Create a new BSP which refers to Variscite's. I am not sure if a BSP layer can be "on top of" another BSP layer?
4. Use Variscite's BSP and perform manual modifications (e.g. build kernel out of tree, or modify config settings on deployed image). During my few days of experiments, I have done this, which has been fine for prototyping. However, this is no good solution with regards to efficiency, version control and distribution.

Re: Best practices for customizing Yocto BSP

gusarambula — Fri, 11 Nov 2016 15:34:41 GMT

Hello,

The first option may work for testing, although as you mention it’s not as elegant not as appropriate if you wish to be able to distribute your modified BSP. The fourth option is fine for development but again, not meant for distribution.

Yocto is indeed not focused on development (in that regard it may be better to work on a local BSP and perform the changes and compile manually until it’s been debugged) but rather on distribution.

Yocto is meant to be used exactly as you mentioned on the third option, through layers that allow to customize and reuse a lot of code, packages and configurations. You should be able to create a new layer to add patches and packages unique to your customized BSP. There is some information on how to create a new layer on the following community document:

https://community.nxp.com/docs/DOC-331917

You should also go through the following training which is simple but very informative and well structured. I’m sure it will help:

https://community.nxp.com/docs/DOC-94849

Regards,

Re: Best practices for customizing Yocto BSP

lex — Wed, 17 Mar 2021 10:54:08 GMT

The training doesn't seem to be available anymore, is this correct?

Re: Best practices for customizing Yocto BSP

timblaktu — Tue, 19 Nov 2024 20:44:13 GMT

@lex @gusarambula it appears the training link is good but requires auth. I am signed into my nxp account, and get the attached error screen.

@stian I am working on a distribution layer to customize variscite-bsp-platform for some new products based on their var-som-iMX8mp, and would love to compare notes and discuss strategies.

Re: Best practices for customizing Yocto BSP

gusarambula — Tue, 19 Nov 2024 21:01:58 GMT

Hello, Tim!

Both links are now very outdated, with the second one having been decommissioned as information is obsolete for the current Yocto Project.

I would recommend going to the Yocto Project documentation for reference, which has improved a little since when this question was originally posted.

https://docs.yoctoproject.org/next/dev-manual/layers.html

Regards,
Gustavo

Re: Best practices for customizing Yocto BSP

timblaktu — Tue, 19 Nov 2024 23:29:00 GMT

Man, you are on it! Thanks for the fast response, Gustavo.

The real question here isn't "how to create a layer" or "how to append a recipe" which the documentation explains well, but a higher-level practical question of what is the best way of working with, customizing, and architecting around the existing yocto-based solutions provided by SoC/SoM vendors. It's nice that they provide yocto solutions for free, but IME they sometimes create confusion by fuzzing the lines between "bsp" and "distribution", and not following the Yocto Project's best practices in their documentation and reference platforms, e.g. using the yocto antipattern of modifying local.conf for customizations.

As I mentioned, I'm using the var-som-imx8mp "machine", with varigit/variscite-bsp-platform at mickledore as the "distribution". I was befuddled by their terminology and documentation, and the cognitive dissonance between it and the YP docs, until I forced myself to draw the diagram below, requiring me to dive deep.

variscite-bsp-platform is actually not a BSP. It "has a" BSP, defined in the depths of its `meta-{imx,var}-*-bsp` layers, but it is not a BSP. variscite-bsp-platform is a distribution. Even after understanding this distinction, it is confusing how to move forward with creating one's own distribution layer (per YP best-practices) which "uses" and modifies the variscite-bsp-platform distribution. The canonical "how-to" solution in the variscite documentation is "Add the following line to YOCTO_DIR/BUILD_DIR/conf/local.conf."

On top of these, the tooling used in these vendor BSPs is heterogenous and IMO a bit archaic:, e.g. using git-repo tool manifests instead of standard git submodules (yes, submodules are standard, folks, get used to it), and not standardizing on modern container tooling like kas.

I know the above are not your problem, nor your fault, Gustavo. I just wanted to provide some context around why I'm here, and perhaps what the OP found confusing.

..and to suggest and solicit feedback on a canonical solution for future users that like me want to follow YP best practices while using a vendor-provided yocto "distribution" which includes the "bsp" layers for "machine"-specific configuration. The approach is defined by the below list of requirements.

There is a top-level git super-project that refers to all yocto meta layers and other related software projects. This provides an omniscient single source of truth and logical place for e2e/system-level CI.
Yocto meta layers are contained in yocto/ subfolder, and are referred to by git submodules.
1. Where git-repo tool is used upstream, encapsulate its super-project in a yocto/<repo-tool-layer>/ subdirectory. Note that tooling must be updated to install and invoke the repo tool in all the right places, instead of just `git clone --recurse-submodules`.
2. I have automation that will convert git-repo based yocto projects to use git submodules, but have yet to work out the entire workflow.
3. Having consistency in this kind of tooling removes much of the barrier to accepting upstream changes, and contributing.
A new meta-custom-distro layer submodule is created under yocto which defines a new distro named custom-distro in the standard conf/distro/custom-distro.conf file.
1. The distro conf also provides the variable modifications required to implement the desired changes, e.g. tweaking DISTRO_FEATURES or *IMAGE_INSTALL vars to include or exclude features or packages. Notably, this is the YP best-practice way of customizing a distribution, as opposed to modifying local.conf, or worse, modifying the upstream sources in place without forking.
2. recipes may be added here to refine changes made to variables above, and to add new features, configuration, or packages that are truly specific to the purpose of custom-distro.

That's it. Everything else is not distro-specific, i.e. you can add other meta layers to the project as normal, to add new recipes or append existing ones.

I'd love to hear your feedback on this approach, @gusarambula or anyone. It all seems pretty standard to me. It was just helpful for me to write this all out explicitly since it goes against the grain of my "bsp platform" vendor's documentation. Thanks for reading my brain dump.

Visualization of variscite-bsp-platform, which I wish had been called a "variscite-reference-distro"