Different Splashscreens for OEMs

Technical Support
, , , ,
1

Hello!

I’m looking for a process to include different splashscreens for different build target.

For example, i would like to have the following bitbake targets:

mycompany-image
oem1-image
oem2-image
oemN-image

I was able to include the splashscreen as a patch in my own layer, but this solution will not work for different splashscreens.

What is the best/right way to integrate different splashscreens?

2

Hi @cheesi
Did you follow this article?
If so, you could create a separate machine for each OEM customer. In the kernel recipe (or better the bbappend) you may then do something like:

FILESEXTRAPATHS_prepend = "${THISDIR}/${PN}-${PV}:${THISDIR}/${PN}-${PV}/${MACHINE}:"

You can then add your machine specific patch into a folder with the machine name. e.g. linux-toradex-4.9-1.0.x/colibri-imx6-oem1

If you only want to hide the userspace boot (systemd) you can also think about using something like dietsplash. You could create a specific dietsplash recipe for each oem customer and include it in the oemN-image. This has the advantage that you don’t have to recompile the kernel for each customer but only dietsplash. You also don’t have to add a new machine which is maybe easier to maintain. The disadvantage is that it takes until the kernel has loaded to you see the splash screen.

Regards,
Stefan

3

Hi Stefan!

Thanks for the quick response, that is really helpful. I’m not sure, but as far as I can remember, changing the $MACHINE var in local.conf results into rebuilding everything? Because that would be quite annoying and increasing the build time radically. Please correct me, if I am wrong.

BR Christian

4

Hi @cheesi

Normally only changing the MACHINE in local.conf shouldn’t rebuild everything. Only the machine specific parts under tmp-glibc/work/colibri_imx6–angstrom-linux-gnueabi should be rebuild (e.g. kernel, u-boot). If it rebuilds everything something is wrong somewhere. Please come back to me if that should be the case.

Regards,
Stefan

5

Hi Stefan!

Okay thanks. Just another question: isn’t it risky to introduce new machine names? For example, if I take a look into the toradex-layer, there are many machine specific additions for colibri-imx6. Are these additions also applied for colibri-imx-*?

BR Christian

6

Hi @cheesi

It don’t think it’s risky it depends on how you implement it. I would recommend you that you include the colibri-imx6.conf in your own machine config. This has the advantage that you get updates if Toradex changes something. Please check meta-freescale-3rdparty/conf/machine/imx6qsabrelite.con for an example. They include nitrogen6x.conf there.

Regards,
Stefan

7

Hi Stefan!

Yes, that will work for the configuration in the machine files, but our image includes the /meta-toradex-demos/recipes-images/images/console-tdx-image.bb, so we use the toradex console image as a base.

And tdx-extra.inc for example has the following appends:

IMAGE_INSTALL_append_colibri-imx6 = " \
    u-boot-toradex-fsl-fw-utils \
    perf \
"

From my understanding, the append would not work, if I introduce new machine names.

8

Hi @cheesi

In principle you are right but please check the imx6qsabrelite.conf file as proposed above. You can use the MACHINEOVERRIDES to solve this issue:
https://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html#var-MACHINEOVERRIDES
You need to add colibri-imx6 there and it should work.

Regards,
Stefan

9

Hi Stefan!

Thanks for the response. I didn’t know about the MACHINEOVERRIDES.

I think, I now have all information I need. Big Thanks for your help.

BR Christian

10

You are welcome.

11

Hey @jaski.tx !

Currently, I’m trying to implement this, but this solution breaks the tar ball generation and the update.sh script.

I was able to fix the tar ball generation by overriding the BURNFLASH var, the update.sh script, however, cannot find certain files because of the changed machine name.

So for now, this is not a suitable solution for us. Are there any other ways to implement this?

12

hi @cheesi

Which files could not you find? I don’t know other way to implement this.

13

Hey @jaski.tx !

I can’t really remember the exact paths, but I can show you by reference to the update.sh script:
http://git.toradex.com/cgit/meta-toradex-demos.git/tree/recipes-images/images/files/library/imx6/update.sh?h=rocko#n101
L101: MODTYPE=colibri-imx6
L153: BINARIES=${MODTYPE}_bin (this for example is a folder name, that is affected by the change of the machine var)

This is just one example.

The tar ball generation breaks, because the flash instructions could not be found (because the folder name is set by the machine name, see tdx-image-fstype.inc « images « recipes-images - meta-toradex-demos.git - Toradex BSP layer, recipes for the demo images). However, I was able to fix that by linking the needed files.

14

Hi @cheesi

Unfortunately you are right and it needs some modifications for the tarball generation as well. Are you okay with your current solution? I don’t think there is a super simple way.

Regards,
Stefan

15

Hey @stefan_e.tx !

My current solution is to manually copy the corresponding patch file. I have both patch files in the my layer repo, so, yes I am okay with that.

However, if you do a refactoring some day, you should think about addressing this issue (if it’s even possible). I don’t know, if it’s only us, but I think it would be a common usage for companies to sell its products as OEM. And some of the reseller would like to have some customization.

BR Christian

16

Thanks for the update and the input. I will keep that on the radar and maybe we find a better approach for OEM products.

Regards,
Stefan