Essentially, we extend the overrides to a generic-bsp, nxp-bsp, and
mainline-bsp.
So, for example, the mx8mq override is split into:
- imx-generic-bsp: compatible with every i.MX SoC and both BSP variants
- imx-nxp-bsp: compatible with every i.MX SoC but specific to NXP BSP
- imx-mainline-bsp: compatible with every i.MX SoC but specific to Mainline BSP
- mx8-generic-bsp: compatible with every i.MX8 SoC and both BSP variants
- mx8-nxp-bsp: compatible with every i.MX8 SoC but specific to NXP BSP
- mx8-mainline-bsp: compatible with every i.MX8 SoC but specific to Mainline BSP
- mx8m-generic-bsp: compatible with every i.MX8M SoC and both BSP variants
- mx8m-nxp-bsp: compatible with every i.MX8M SoC but specific to NXP BSP
- mx8m-mainline-bsp: compatible with every i.MX8M SoC but specific to Mainline BSP
- mx8mq-generic-bsp: compatible with every i.MX8MQ SoC and both BSP variants
- mx8mq-nxp-bsp: compatible with every i.MX8MQ SoC8 but specific to NXP BSP
- mx8mq-mainline-bsp: compatible with every i.MX8MQ SoC but specific to Mainline BSP
The extender mechanism is responsible for extending the override list to
include the generic overrides. We can then use the three different
variants to handle the metadata correctly.
Generically speaking, the conversion mainly was automated (with a lot of
back and forth until getting it right).
To convert an existing layer, the following script can be used:
```sh
git ls-files classes recipes-* \
| xargs sed -i \
-e 's,:\(mx[6-8]\w*\),:\1-nxp-bsp,g' \
-e 's,(\(mx[6-8]\w*\)),(\1-nxp-bsp),g' \
-e 's,\(mx[6-8]\w*\)|,\1-nxp-bsp|,g' \
-e 's,|\(mx[6-8]\w*\)),|\1-nxp-bsp),g' \
\
-e 's,:\(mx[5s]\w*\),:\1-generic-bsp,g' \
-e 's,(\(mx[5s]\w*\)),(\1-generic-bsp),g' \
-e 's,\(mx[5s]\w*\)|,\1-generic-bsp|,g' \
-e 's,|\(mx[5s]\w*\)),|\1-generic-bsp),g' \
\
-e 's,:\(vf\w*\),:\1-generic-bsp,g' \
-e 's,:\(vf[56]0\w*\),:\1-generic-bsp,g' \
-e 's,\(vf\w*\)|,\1-generic-bsp|,g' \
-e 's,|\(vf\w*\)),|\1-generic-bsp),g' \
-e 's,\(vf[56]0\w*\)|,\1-generic-bsp|,g' \
-e 's,|\(vf[56]0\w*\)),|\1-generic-bsp),g' \
\
-e 's,:\(imx\) ,:\1-nxp-bsp ,g' \
-e 's,(\(imx\)),(\1-nxp-bsp),g' \
-e 's,\(imx\)|,\1-nxp-bsp|,g' \
-e 's,|\(imx\)),|\1-nxp-bsp),g'
for d in $(find -type d | egrep '/mx[6-8]w*'); do
git mv $d $d-nxp-bsp
done
for d in $(find -type d | egrep '/imx$'); do
git mv $d $d-nxp-bsp
done
for d in $(find -type d | egrep '/mx[5s]w*'); do
git mv $d $d-generic-bsp
done
```
Fixes: #791.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
i.MX-specific headers are missing in SDK once generated via image
do_populate_sdk task.
This was caused by dropped ALLOW_EMPTY package-controlling variable
which is required for this recipe in order to indicate that package can
have RDEPENDS.
Additional RDEPENDS are also required by packages using new mechanisms
to include linux-imx-headers, this allows headers to be propagated to
the SDK when dependent package is included.
Introduce ALLOW_EMPTY in recipe and RDEPENDS in use-imx-headers bbclass
to have imx headers to be populated in the SDK.
Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
Certain packages are using linux-imx-headers, which enforces them to use
NXP BSP since headers are provided from the NXP kernel tree.
Those recipes, which requires NXP kernel headers, are now including the
use-imx-headers class to make sure the correct headers package is used.
Since the introduction of separation between NXP and Mainline BSP for
certain machines, recipes which are NXP-dependent are getting their
COMPATIBLE_HOST to be marked as (null) effectively making them
incompatible with mainline BSP which is expected behavior.
By extending this restriction into the use-imx-headers class, all
recipes which inherits is (because it is required) are getting
automatically restricted to NXP BSP, hence making package NXP-dependent
much easier.
linux-imx-headers is marked as "NXP-only" but it is done explicitly
inside the recipe in order to avoid confusion of inheriting the class.
Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
This allow to easy reuse of binary packages among similar SoCs. The
usual use for this is to share SoC specific packages among different
boards independently of the kernel version it is using, as far it is
ABI compatible with the official version it will just work.
Following recipes has been reworked to make use of the class:
- imx-lib
- imx-test
- imx-vpu-hantro
- imx-vpu
- imx-alsa-plugins
- gstreamer1.0-plugins-base
- gstreamer1.0-plugins-imx
- imx-gst1.0-plugin
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>