customising a bsp

customising a bsp

[Sergio Torres Soldado]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

Hi,

 What is the best alternative to setting variables in local.conf? The
specific use-case is customising a meta-raspberrypi build, which has a
bunch of variables that are picked up by the MACHINE code to influence
build configurations. I want to version these customisations hence removing
them from local.conf.

 I have tried adding a machine definition in a separate layer that includes
the same files as those from the machines in meta-raspberry pi but there is
logic that depends on the machine name and building an image fails.

Many thanks,
Serj.

[-- Attachment #2: Type: text/html, Size: 664 bytes --]

Re: customising a bsp

[Dimitris Tassopoulos]

[-- Attachment #1: Type: text/plain, Size: 2907 bytes --]

Hi Serj,

I'm using the -r / -R options in bitbake in order to customize the image
via global
variables and be able to build different configurations for the same
machine and
distro. You you use the same option to create e.g. different versions. Have
a look
in the documentation

https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html

search for these lines:
-r PREFILE, --read=PREFILE
-R POSTFILE, --postread=POSTFILE

What those do is that you can add an extra configuration file wich either
prepends
or appends the local.conf file. I'm using it both ways, but for your case I
think you
need to add your default versions with ?= in the local.conf and then
override them
with an external conf file and use --read option.

So, let's say that you have the minimal-image then you can have a number or
versioned configuration files (e.g. version-1.0.conf, version-1.2.conf,
e.t.c.) then
you setup your environment as usual using your environment setup scripts or
just calling oe-init-build-env for your machine and then you'll be able to
build
different versions like this:

bitbake -R version-1.0.conf minimal-image


You can also build a single recipe using the version file

bitbake -R version-1.2.conf virtual/kernel


Then, if you like, you can create a wrapper script that actually simplifies
the call
and just pass the version. For example, you can create an executable bash
script
and these

#!/bin/bash
> CONF_VERSION="1.0"
> while getopts v:h" OPTION
> do
>     case $OPTION in
>     v) CONF_VERSION=${OPTARG} ;;
>     h) echo "Print some help" ;;
>     *) echo "Print some help" ;;
> esac
> done
> bitbake --postread=${CONF_VERSION} ${1}


And then call the script using -v to pass the version. Of course, that
assumes
that all version files are in the same folder with the local.conf. I
usually make
such scripts but they are doing much more stuff, for example use variables
from the extra conf file to run other tasks.

Hope that helps.

Cheers,
Dimitris

Sergio Torres Soldado <torres.soldado@gmail.com> schrieb am Sa., 30. März
2019, 18:34:

> Hi,
>
>  What is the best alternative to setting variables in local.conf? The
> specific use-case is customising a meta-raspberrypi build, which has a
> bunch of variables that are picked up by the MACHINE code to influence
> build configurations. I want to version these customisations hence removing
> them from local.conf.
>
>  I have tried adding a machine definition in a separate layer that
> includes the same files as those from the machines in meta-raspberry pi but
> there is logic that depends on the machine name and building an image fails.
>
> Many thanks,
> Serj.
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

[-- Attachment #2: Type: text/html, Size: 4597 bytes --]

Re: customising a bsp

[Sergio Torres Soldado]

[-- Attachment #1: Type: text/plain, Size: 4724 bytes --]

Hi Dimitris,

 That is very versatile thanks. It is a way of solving the issue.

 Just as a side note this is what I did so far trying to separate the
changes to the machine:

 added the following to a layer I created:
.
|-- conf
|   `-- machine
|       `-- raspberrypi3-custom.conf

Initially raspberrypi3-custom.conf was just a copy of raspberrpi3.conf in
meta-raspberry but I get the following excerpt of an error:
"""
ERROR: linux-raspberrypi-1_4.14.98+gitAUTOINC+5d63a4595d-r0
do_kernel_metadata: Could not locate BSP definition for
raspberrypi3-custom/standard and no defconfig was provided
"""

To remedy this I added the following line to raspberrypi3-custom.conf:
"""
KBUILD_DEFCONFIG_raspberrypi3-custom ?= "bcm2709_defconfig
"""

But then I get the error:
"""
ERROR: bcm2835-bootfiles-20190212-r3 do_populate_lic: QA Issue:
bcm2835-bootfiles: LIC_FILES_CHKSUM points to an invalid file:
/opt/yocto/workspace/build/tmp/work/raspberrypi3_custom-poky-linux-gnueabi/bcm2835-bootfiles/20190212-r3/firmware-83977fe3b6ef54c1d29c83b0a778d330f523441f/boot/LICENCE.broadcom
[license-checksum]
ERROR: bcm2835-bootfiles-20190212-r3 do_populate_lic: Fatal QA errors
found, failing task.
ERROR: bcm2835-bootfiles-20190212-r3 do_populate_lic: Function failed:
populate_lic_qa_checksum
ERROR: Logfile of failure stored in:
/opt/yocto/workspace/build/tmp/work/raspberrypi3_custom-poky-linux-gnueabi/bcm2835-bootfiles/20190212-r3/temp/log.do_populate_lic.30228
"""

I ended up editing raspberrypi3.conf directly basically branching
meta-raspberrypi.


On Mon, 1 Apr 2019 at 08:27, Dimitris Tassopoulos <dimtass@gmail.com> wrote:

> Hi Serj,
>
> I'm using the -r / -R options in bitbake in order to customize the image
> via global
> variables and be able to build different configurations for the same
> machine and
> distro. You you use the same option to create e.g. different versions.
> Have a look
> in the documentation
>
>
> https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html
>
> search for these lines:
> -r PREFILE, --read=PREFILE
> -R POSTFILE, --postread=POSTFILE
>
> What those do is that you can add an extra configuration file wich either
> prepends
> or appends the local.conf file. I'm using it both ways, but for your case
> I think you
> need to add your default versions with ?= in the local.conf and then
> override them
> with an external conf file and use --read option.
>
> So, let's say that you have the minimal-image then you can have a number or
> versioned configuration files (e.g. version-1.0.conf, version-1.2.conf,
> e.t.c.) then
> you setup your environment as usual using your environment setup scripts or
> just calling oe-init-build-env for your machine and then you'll be able to
> build
> different versions like this:
>
> bitbake -R version-1.0.conf minimal-image
>
>
> You can also build a single recipe using the version file
>
> bitbake -R version-1.2.conf virtual/kernel
>
>
> Then, if you like, you can create a wrapper script that actually
> simplifies the call
> and just pass the version. For example, you can create an executable bash
> script
> and these
>
> #!/bin/bash
>> CONF_VERSION="1.0"
>> while getopts v:h" OPTION
>> do
>>     case $OPTION in
>>     v) CONF_VERSION=${OPTARG} ;;
>>     h) echo "Print some help" ;;
>>     *) echo "Print some help" ;;
>> esac
>> done
>> bitbake --postread=${CONF_VERSION} ${1}
>
>
> And then call the script using -v to pass the version. Of course, that
> assumes
> that all version files are in the same folder with the local.conf. I
> usually make
> such scripts but they are doing much more stuff, for example use variables
> from the extra conf file to run other tasks.
>
> Hope that helps.
>
> Cheers,
> Dimitris
>
> Sergio Torres Soldado <torres.soldado@gmail.com> schrieb am Sa., 30. März
> 2019, 18:34:
>
>> Hi,
>>
>>  What is the best alternative to setting variables in local.conf? The
>> specific use-case is customising a meta-raspberrypi build, which has a
>> bunch of variables that are picked up by the MACHINE code to influence
>> build configurations. I want to version these customisations hence removing
>> them from local.conf.
>>
>>  I have tried adding a machine definition in a separate layer that
>> includes the same files as those from the machines in meta-raspberry pi but
>> there is logic that depends on the machine name and building an image fails.
>>
>> Many thanks,
>> Serj.
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>

[-- Attachment #2: Type: text/html, Size: 7200 bytes --]

Re: customising a bsp

[Paul Barker]

On Mon, 1 Apr 2019, at 08:49, Sergio Torres Soldado wrote:
> Hi Dimitris,
> 
>  That is very versatile thanks. It is a way of solving the issue.
> 
>  Just as a side note this is what I did so far trying to separate the 
> changes to the machine:
> 
>  added the following to a layer I created:
> . 
> |-- conf 
> | `-- machine 
> | `-- raspberrypi3-custom.conf 
> 
> Initially raspberrypi3-custom.conf was just a copy of raspberrpi3.conf 
> in meta-raspberry but I get the following excerpt of an error:
> """
> ERROR: linux-raspberrypi-1_4.14.98+gitAUTOINC+5d63a4595d-r0 
> do_kernel_metadata: Could not locate BSP definition for 
> raspberrypi3-custom/standard and no defconfig was provided
> """
> 
> To remedy this I added the following line to raspberrypi3-custom.conf:
> """
> KBUILD_DEFCONFIG_raspberrypi3-custom ?= "bcm2709_defconfig
> """
> 
> But then I get the error:
> """
> ERROR: bcm2835-bootfiles-20190212-r3 do_populate_lic: QA Issue: 
> bcm2835-bootfiles: LIC_FILES_CHKSUM points to an invalid file: 
> /opt/yocto/workspace/build/tmp/work/raspberrypi3_custom-poky-linux-gnueabi/bcm2835-bootfiles/20190212-r3/firmware-83977fe3b6ef54c1d29c83b0a778d330f523441f/boot/LICENCE.broadcom [license-checksum]
> ERROR: bcm2835-bootfiles-20190212-r3 do_populate_lic: Fatal QA errors 
> found, failing task.
> ERROR: bcm2835-bootfiles-20190212-r3 do_populate_lic: Function failed: 
> populate_lic_qa_checksum
> ERROR: Logfile of failure stored in: 
> /opt/yocto/workspace/build/tmp/work/raspberrypi3_custom-poky-linux-gnueabi/bcm2835-bootfiles/20190212-r3/temp/log.do_populate_lic.30228
> """
> 
> I ended up editing raspberrypi3.conf directly basically branching 
> meta-raspberrypi.
> 

Hi Sergio,

You could look at how we handle things in the BSP for the Sancloud BeagleBone Enhanced (BBE). This board is based on the BeagleBone Black and so in Yocto Project any overrides, COMPATIBLE_HOST values, etc which apply for the beaglebone should also apply for the bbe. To do this we add "beaglebone" to the MACHINEOVERRIDES list along with the appropriate separator which is ":". See https://bitbucket.sancloud.co.uk/projects/YB/repos/meta-sancloud/browse/conf/machine/bbe.conf for details.

So you should be able to add a line like this to your raspberrypi3-custom.conf file:

    MACHINEOVERRIDES =. "raspberrypi3:"

Thanks,

-- 
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd