Slightly varying builds

Slightly varying builds

[colin.helliwell]

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

I need to build two slightly varying versions of our Yocto build - one for
the production units and one for development.

They differ in only a few ways - the kernel and apps are the same. But one
has Dropbear, whilst the other doesn't; and the U-Boot configs & patches are
different.

 

I'm wondering where to do the separation - image, distro, conf.?

Any thoughts on the cleanest way to split and/or inherit them would be
appreciated.

 


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

Re: Slightly varying builds

[Alexander Kanavin]

On 11/01/2017 06:43 PM, colin.helliwell@ln-systems.com wrote:
> I need to build two slightly varying versions of our Yocto build – one 
> for the production units and one for development.
> 
> They differ in only a few ways – the kernel and apps are the same. But 
> one has Dropbear, whilst the other doesn’t; and the U-Boot configs & 
> patches are different.
> 
> I’m wondering where to do the separation – image, distro, conf…?
> 
> Any thoughts on the cleanest way to split and/or inherit them would be 
> appreciated.


Image, certainly. Put the common bits into an include, and specific bits 
into image-production|development.bb files. Poky has plenty of examples 
for this.


Alex

Re: Slightly varying builds

[Colin Helliwell]

> On 01 November 2017 at 17:04 Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
> 
> On 11/01/2017 06:43 PM, colin.helliwell@ln-systems.com wrote:
> 
> > I need to build two slightly varying versions of our Yocto build – one
> > for the production units and one for development.
> > 
> > They differ in only a few ways – the kernel and apps are the same. But
> > one has Dropbear, whilst the other doesn’t; and the U-Boot configs &
> > patches are different.
> > 
> > I’m wondering where to do the separation – image, distro, conf…?
> > 
> > Any thoughts on the cleanest way to split and/or inherit them would be
> > appreciated.
> 
> Image, certainly. Put the common bits into an include, and specific bits
> into image-production|development.bb files. Poky has plenty of examples
> for this.
> 

Rootfs changes I can certainly do with different image recipes.
Am I right though in thinking that - because they'll have different variants of u-boot - I'll need to use separate build directories for each? (nb - I'm using signed FIT image, so the u-boot bin gets modified as part of the kernel building)

Re: Slightly varying builds

[Colin Helliwell]

> On 02 November 2017 at 07:10 Colin Helliwell <colin.helliwell@ln-systems.com> wrote:
> 
> > On 01 November 2017 at 17:04 Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
> > 
> > On 11/01/2017 06:43 PM, colin.helliwell@ln-systems.com wrote:
> > 
> > > I need to build two slightly varying versions of our Yocto build – one
> > > for the production units and one for development.
> > > 
> > > They differ in only a few ways – the kernel and apps are the same. But
> > > one has Dropbear, whilst the other doesn’t; and the U-Boot configs &
> > > patches are different.
> > > 
> > > I’m wondering where to do the separation – image, distro, conf…?
> > > 
> > > Any thoughts on the cleanest way to split and/or inherit them would be
> > > appreciated.
> > 
> > Image, certainly. Put the common bits into an include, and specific bits
> > into image-production|development.bb files. Poky has plenty of examples
> > for this.
> 
> Rootfs changes I can certainly do with different image recipes.
> 
> Am I right though in thinking that - because they'll have different variants of u-boot - I'll need to use separate build directories for each? (nb - I'm using signed FIT image, so the u-boot bin gets modified as part of the kernel building)
> --

Following on from this, I'm trying to be able to build my two versions of u-boot, in the *same* build directory.
I'm not sure if this is possible, but I figured it might be: since u-boot doesn't get put into the rootfs (?), I would ideally be able to build both and just pull down from tmp/deploy/images/.... the image that I want to program into a particular unit.
I've pushed common stuff into .inc file(s), and have two recipes which set different  'PROVIDES' values.
However, even after a cleanall on both recipes, bitbaking the second one throws an error "The recipe u-boot-mymachine-dev is trying to install files into a shared area when those files already exist".

Is it possible to do what I'm trying to do....?
Ta

Re: Slightly varying builds

[Alexander Kanavin]

On 11/02/2017 06:26 PM, Colin Helliwell wrote:

> Following on from this, I'm trying to be able to build my two versions of u-boot, in the *same* build directory.
> I'm not sure if this is possible, but I figured it might be: since u-boot doesn't get put into the rootfs (?), I would ideally be able to build both and just pull down from tmp/deploy/images/.... the image that I want to program into a particular unit.
> I've pushed common stuff into .inc file(s), and have two recipes which set different  'PROVIDES' values.
> However, even after a cleanall on both recipes, bitbaking the second one throws an error "The recipe u-boot-mymachine-dev is trying to install files into a shared area when those files already exist".

Can you share exactly how the two recipes differ?

It seems that you do need to have two different build directories that 
differ in what MACHINE is set to. And that would configure u-boot 
accordingly.


Alex

Re: Slightly varying builds

[Colin Helliwell]

> On 02 November 2017 at 16:29 Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
> 
> On 11/02/2017 06:26 PM, Colin Helliwell wrote:
> 
> > Following on from this, I'm trying to be able to build my two versions of u-boot, in the *same* build directory.
> > I'm not sure if this is possible, but I figured it might be: since u-boot doesn't get put into the rootfs (?), I would ideally be able to build both and just pull down from tmp/deploy/images/.... the image that I want to program into a particular unit.
> > I've pushed common stuff into .inc file(s), and have two recipes which set different 'PROVIDES' values.
> > However, even after a cleanall on both recipes, bitbaking the second one throws an error "The recipe u-boot-mymachine-dev is trying to install files into a shared area when those files already exist".
> 
> Can you share exactly how the two recipes differ?
>

Very little!
One is:
 
DESCRIPTION = "Das U-Boot for W2 [for development]"
DEP_IMG = "u-boot-dev"
PROVIDES = "u-boot-w2-dev"
require u-boot-w2_1.inc

The other is:

DESCRIPTION = "Das U-Boot for W2"
DEP_IMG = "u-boot-prodn"
PROVIDES = "u-boot-w2"
require u-boot-w2_1.inc

u-boot-w2_1.inc has the standard kind of recipe stuff. For creating env files, and files to be used for later signing, it has some _append steps, so I'm aiming to use 'DEP_IMG' to create the various files with different prefixes for the two variants.
Strangely though, an 'echo ${DEP_IMG}' is outputting the same value ("u-boot-prodn") from both recipes, even after a cleanall on both. Possibly some state info being pulled in somewhere?

> It seems that you do need to have two different build directories that
> differ in what MACHINE is set to. And that would configure u-boot
> accordingly.
> 

I *do* realise I'm trying to do something a bit unusual!
All I want between the two variants is to disable some functionality - the 'machine' is identical. I was going to patch one build to take the functionality out (for 'production'), but create my own specific environment for the system anyway. So I wonder if a cleaner/easier (aka working...!) approach would be to instead patch my own custom envar into the source, and then I could instead create two different env files for the two variants?

Re: Slightly varying builds

[Alexander Kanavin]

On 11/02/2017 06:50 PM, Colin Helliwell wrote:
>
> u-boot-w2_1.inc has the standard kind of recipe stuff. For creating env files, and files to be used for later signing, it has some _append steps, so I'm aiming to use 'DEP_IMG' to create the various files with different prefixes for the two variants.
> Strangely though, an 'echo ${DEP_IMG}' is outputting the same value ("u-boot-prodn") from both recipes, even after a cleanall on both. Possibly some state info being pulled in somewhere?


Not sure if this will help, but start by not using the -dev suffix. It 
will clash with -dev packages produced by (any) recipe.

Alex

Re: Slightly varying builds

[Colin Helliwell]

> On 02 November 2017 at 16:59 Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
> 
> On 11/02/2017 06:50 PM, Colin Helliwell wrote:
> >
> 
> > u-boot-w2_1.inc has the standard kind of recipe stuff. For creating env files, and files to be used for later signing, it has some _append steps, so I'm aiming to use 'DEP_IMG' to create the various files with different prefixes for the two variants.
> > Strangely though, an 'echo ${DEP_IMG}' is outputting the same value ("u-boot-prodn") from both recipes, even after a cleanall on both. Possibly some state info being pulled in somewhere?
> 
> Not sure if this will help, but start by not using the -dev suffix. It
> will clash with -dev packages produced by (any) recipe.
> 

Thanks Alex, that has indeed resolved the problem of DEP_IMG not changing.

Still getting the "trying to install files into a shared area when those files already exist" error on the second [-dvl] bitbake. And a cleanall throws

"ERROR: Multiple .bb files are due to be built which each provide u-boot:
  /home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2-dvl.bb
  /home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2.bb
A list of tasks depending on these providers is shown and may help explain where the dependency comes from.
/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2.bb has unique dependees:

/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2-dvl.bb has unique dependees:

It could be that one recipe provides something the other doesn't and should. The following provider and runtime provider differences may be helpful.
/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2-dvl.bb has unique provides:
  u-boot-w2-dvl
/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2-dvl.bb has unique rprovides:
  u-boot-w2-dvl-dev
  u-boot-w2-dvl-doc
  u-boot-w2-dvl
  u-boot-w2-dvl-staticdev
  u-boot-w2-dvl-dbg
  u-boot-w2-dvl-locale
  ^u-boot-w2-dvl-locale-.*
/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2.bb has unique provides:
  u-boot-w2
/home/colin/trunk/fsl-community-bsp/../meta-ln-karo/recipes-bsp/u-boot/u-boot-w2.bb has unique rprovides:
  u-boot-w2-doc
  ^u-boot-w2-locale-.*
  u-boot-w2-dev
  u-boot-w2-staticdev
  u-boot-w2
  u-boot-w2-dbg
  u-boot-w2-locale"

That doesn't seem to imply too much conflict, so might be something simple...
It's nearly dinnertime - :) - so I could, to make absolutely sure, try a thorough cleanout by deleting tmp/ and see what happens.