* customising a bsp @ 2019-03-30 17:33 Sergio Torres Soldado 2019-04-01 7:27 ` Dimitris Tassopoulos 0 siblings, 1 reply; 4+ messages in thread From: Sergio Torres Soldado @ 2019-03-30 17:33 UTC (permalink / raw) To: yocto [-- 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 --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: customising a bsp 2019-03-30 17:33 customising a bsp Sergio Torres Soldado @ 2019-04-01 7:27 ` Dimitris Tassopoulos 2019-04-01 7:48 ` Sergio Torres Soldado 0 siblings, 1 reply; 4+ messages in thread From: Dimitris Tassopoulos @ 2019-04-01 7:27 UTC (permalink / raw) To: Sergio Torres Soldado; +Cc: Yocto discussion list [-- 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 --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: customising a bsp 2019-04-01 7:27 ` Dimitris Tassopoulos @ 2019-04-01 7:48 ` Sergio Torres Soldado 2019-04-01 14:45 ` Paul Barker 0 siblings, 1 reply; 4+ messages in thread From: Sergio Torres Soldado @ 2019-04-01 7:48 UTC (permalink / raw) To: Dimitris Tassopoulos; +Cc: Yocto discussion list [-- 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 --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: customising a bsp 2019-04-01 7:48 ` Sergio Torres Soldado @ 2019-04-01 14:45 ` Paul Barker 0 siblings, 0 replies; 4+ messages in thread From: Paul Barker @ 2019-04-01 14:45 UTC (permalink / raw) To: Sergio Torres Soldado, Dimitris Tassopoulos; +Cc: Yocto discussion list 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-04-01 14:55 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-30 17:33 customising a bsp Sergio Torres Soldado 2019-04-01 7:27 ` Dimitris Tassopoulos 2019-04-01 7:48 ` Sergio Torres Soldado 2019-04-01 14:45 ` Paul Barker
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.