Configuring a layer to support multiple targets

Configuring a layer to support multiple targets

[Chris Tapp]

What is the best way to configure a layer to support multiple targets  
that share a common base?

For example, a set of targets that use the Vortex86DX SOC share common  
peripherals and also have per-variant peripherals.

I was thinking:

1) Have a conf/machine file for each variant;
2) Make these use an include for the Vortex86DX SOC.

However, I can't work out how to get a per-machine defconfig file. Is  
there some way of using the machine name to do this? Can I just use

FILESEXTRAPATHS := "${THISDIR}/${PN}/${MACHINE}"

in a kernel .bbappend file?

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Configuring a layer to support multiple targets

[Gary Thomas]

On 2011-08-12 16:31, Chris Tapp wrote:
> What is the best way to configure a layer to support multiple targets that share a common base?
>
> For example, a set of targets that use the Vortex86DX SOC share common peripherals and also have per-variant peripherals.
>
> I was thinking:
>
> 1) Have a conf/machine file for each variant;
> 2) Make these use an include for the Vortex86DX SOC.
>
> However, I can't work out how to get a per-machine defconfig file. Is there some way of using the machine name to do this? Can I just use
>
> FILESEXTRAPATHS := "${THISDIR}/${PN}/${MACHINE}"
>
> in a kernel .bbappend file?

That shouldn't even be necessary. Just something like this:
   FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}"
and it will look for files in various directories
   ${THISDIR}/${PN}/${MACHINE}
   ${THISDIR}/${PN}
(and maybe some others)

For example, I have one layer for a project which supports
three different targets (all part of the same platform) using
this technique.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Missing patch files in SRC_URIs

[Chris Tapp]

bitbake doesn't seem to be detecting missing patch files. In  
a .bbappend file (for linux-wrs_git) I have:

SRC_URI += " file://defconfig"

SRC_URI_append_Vortex86DX = "\
	   file://there-is-no.patch;patch=1 "

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}"

bitbake -c patch -f virtual/kernel

runs without reporting any errors, even though linux-wrs_Vortex86DX/  
does not contain 'there-is-no.patch'.

However, if I change the append to specify a (non-existent) file:

SRC_URI_append_Vortex86DX = "\
	   file://there-is-no-file "

then bitbake reports an error, as I would expect.

Am I doing something wrong here?

Bitbake version is 1.11.0 and MACHINE is Vortex86DX.


Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Missing patch files in SRC_URIs

[Paul Eggleton]

Hi Chris,

On Wednesday 24 August 2011 08:59:15 Chris Tapp wrote:
> bitbake doesn't seem to be detecting missing patch files. In
> a .bbappend file (for linux-wrs_git) I have:
> 
> SRC_URI += " file://defconfig"
> 
> SRC_URI_append_Vortex86DX = "\
> 	   file://there-is-no.patch;patch=1 "

FYI patch=1 is no longer necessary as of quite some time ago - the .patch (or 
.diff) extension is enough to indicate that it's a patch.

> bitbake -c patch -f virtual/kernel
> 
> runs without reporting any errors, even though linux-wrs_Vortex86DX/
> does not contain 'there-is-no.patch'.

Are you sure there is no patch of this name elsewhere in the search path for 
this recipe? This is buggy behaviour if there isn't. (bitbake -e linux-wrs | 
grep "^FILESPATH" will give you the entire path it is using.) In any case the 
directory it should search for the patch in is linux-wrs/Vortex86DX not linux-
wrs_Vortex86DX.

I'd also recommend for consistency if it's not too difficult to change at this 
point that you use an all-lowercase machine name.
 
Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Missing patch files in SRC_URIs

[Chris Tapp]

Hi Paul,

On 24 Aug 2011, at 12:11, Paul Eggleton wrote:

> Hi Chris,
>
> On Wednesday 24 August 2011 08:59:15 Chris Tapp wrote:
>> bitbake doesn't seem to be detecting missing patch files. In
>> a .bbappend file (for linux-wrs_git) I have:
>>
>> SRC_URI += " file://defconfig"
>>
>> SRC_URI_append_Vortex86DX = "\
>> 	   file://there-is-no.patch;patch=1 "
>
> FYI patch=1 is no longer necessary as of quite some time ago -  
> the .patch (or
> .diff) extension is enough to indicate that it's a patch.

It seems as if it's this that's causing the problem. I had a 'real'  
patch file in place and it wasn't being processed during do_unpack.  
Removing the 'patch=1' fixed this and it was processed as expected. It  
seems as if adding the 'patch=1' to the file means it's not used as a  
file or patch and is simply ignored, which would explain what I was  
seeing. A 'missing' file without 'patch=1' is reported as an error.

>> bitbake -c patch -f virtual/kernel
>>
>> runs without reporting any errors, even though linux-wrs_Vortex86DX/
>> does not contain 'there-is-no.patch'.
>
> Are you sure there is no patch of this name elsewhere in the search  
> path for
> this recipe? This is buggy behaviour if there isn't. (bitbake -e  
> linux-wrs |
> grep "^FILESPATH" will give you the entire path it is using.) In any  
> case the
> directory it should search for the patch in is linux-wrs/Vortex86DX  
> not linux-
> wrs_Vortex86DX.

I'm certain - I made this file name up specially for testing ;-)

My, doesn't FILESPATH get complicated !

> I'd also recommend for consistency if it's not too difficult to  
> change at this
> point that you use an all-lowercase machine name.

Easily done, as this is only experimental at the moment. I'll try and  
remember to change it when I finish later on so I can run a complete  
rebuild over night.

Thanks for the pointer.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Configuring a layer to support multiple targets

[Bruce Ashfield]

On 11-08-12 06:31 PM, Chris Tapp wrote:
> What is the best way to configure a layer to support multiple targets
> that share a common base?
>
> For example, a set of targets that use the Vortex86DX SOC share common
> peripherals and also have per-variant peripherals.
>
> I was thinking:
>
> 1) Have a conf/machine file for each variant;
> 2) Make these use an include for the Vortex86DX SOC.
>
> However, I can't work out how to get a per-machine defconfig file. Is
> there some way of using the machine name to do this? Can I just use

What's your yocto release / base kernel ? IF you happen to
be using linux-yocto there are several ways to avoid using
defconfigs at all, and share your common base of kernel
configuration items.

Cheers,

Bruce

>
> FILESEXTRAPATHS := "${THISDIR}/${PN}/${MACHINE}"
>
> in a kernel .bbappend file?
>
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Configuring a layer to support multiple targets

[Chris Tapp]

On 13 Aug 2011, at 02:22, Bruce Ashfield wrote:

> What's your yocto release / base kernel ? IF you happen to
> be using linux-yocto there are several ways to avoid using
> defconfigs at all, and share your common base of kernel
> configuration items.

Plan is to move to linux-yocto (currently using wrs). How do I  
configure it without using a defconfig?

Also, is it possible to use a .config rather than a defconfig? I've  
got a lot of stuff turned off to reduce the size of the kernel, but a  
defconfig doesn't quite do. For example, if I have

# CONFIG_USB_SERIAL is not set

in a defconfig, then this gets in to the .config at build time.  
However, this doesn't disable any dependencies that are enabled in  
linux-wrs. This means that modules for the likes of the ftdi and  
pl2303 USB serial devices are still included in the kernel image.

The use of a complete .config would stop this.


Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Configuring a layer to support multiple targets

[Bruce Ashfield]

On 11-08-17 03:59 AM, Chris Tapp wrote:
> On 13 Aug 2011, at 02:22, Bruce Ashfield wrote:
>
>> What's your yocto release / base kernel ? IF you happen to
>> be using linux-yocto there are several ways to avoid using
>> defconfigs at all, and share your common base of kernel
>> configuration items.
>
> Plan is to move to linux-yocto (currently using wrs). How do I configure
> it without using a defconfig?

I depends on how you host your BSP, and the release. In
yocto 1.1, there's new functionality that makes it easier
to graft a BSP onto the tree without needing to have the
BSP merged somewhere.

But to configure and work without a defconfig, you simply
need a BSP that branches from yocto/standard/base. Even the
autogenerated descriptions in 1.0 will automatically include
the standard kernel configs and settings and pass them to
your BSP. Once this is in place, you simply need a config
fragment (a .cfg file) for your board that adds/modifies the
base configuration.

>
> Also, is it possible to use a .config rather than a defconfig? I've got
> a lot of stuff turned off to reduce the size of the kernel, but a
> defconfig doesn't quite do. For example, if I have
>
> # CONFIG_USB_SERIAL is not set
>
> in a defconfig, then this gets in to the .config at build time. However,
> this doesn't disable any dependencies that are enabled in linux-wrs.
> This means that modules for the likes of the ftdi and pl2303 USB serial
> devices are still included in the kernel image.
>
> The use of a complete .config would stop this.

In this sense, the defconfig is simply a name to trigger
specific processing. Just capture and call your .config
'defconfig' and you'll get a translation of those settings
into the build.

Bruce

>
>
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Configuring a layer to support multiple targets

[Chris Tapp]

On 17 Aug 2011, at 16:18, Bruce Ashfield wrote:

> In this sense, the defconfig is simply a name to trigger
> specific processing. Just capture and call your .config
> 'defconfig' and you'll get a translation of those settings
> into the build.


That's what I've done. I used 'make xconfig' to modify the .config  
file (resulting from bitbake -c compile virtual/kernel). However,  
turning off CONFIG_USB_SERIAL and saving the result as a defconfig  
isn't quite what's needed.

Consider the .config fragment:

CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_FTDI_SIO=y

The corresponding defconfig fragment produced when usb serial is  
disabled in xconfig results is simply:

# CONFIG_USB_SERIAL is not set

When the defconfig is merged with the .config I get:

# CONFIG_USB_SERIAL is not set
CONFIG_USB_SERIAL_FTDI_SIO=y

This means the FTDI module is still present in the kernel.

I can get rid of these by manually adding 'not set' entries in the  
defconfig, but it would be easier if I could replace the .config  
rather than patch it.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Configuring a layer to support multiple targets

[Bruce Ashfield]

On 11-08-17 03:07 PM, Chris Tapp wrote:
> On 17 Aug 2011, at 16:18, Bruce Ashfield wrote:
>
>> In this sense, the defconfig is simply a name to trigger
>> specific processing. Just capture and call your .config
>> 'defconfig' and you'll get a translation of those settings
>> into the build.
>
>
> That's what I've done. I used 'make xconfig' to modify the .config file
> (resulting from bitbake -c compile virtual/kernel). However, turning off
> CONFIG_USB_SERIAL and saving the result as a defconfig isn't quite
> what's needed.
>
> Consider the .config fragment:
>
> CONFIG_USB_SERIAL=y
> CONFIG_USB_SERIAL_FTDI_SIO=y
>
> The corresponding defconfig fragment produced when usb serial is
> disabled in xconfig results is simply:
>
> # CONFIG_USB_SERIAL is not set
>
> When the defconfig is merged with the .config I get:
>
> # CONFIG_USB_SERIAL is not set
> CONFIG_USB_SERIAL_FTDI_SIO=y
>
> This means the FTDI module is still present in the kernel.
>
> I can get rid of these by manually adding 'not set' entries in the
> defconfig, but it would be easier if I could replace the .config rather
> than patch it.

The model is that you must explicitly chose values to modify
them, otherwise, they flow through. Last through the gate wins.
If you don't speak, others parts speak for the configuration.

In this case, you must be inheriting the common-pc kernel
configuration.

It's something to configure for the future, but that is working
as designed at the moment. The point is to be able to set a policy
for options that inheriting BSPs must explicitly disable.

The solutions two this are:

   - inherit from a base branch vs common-pc (assuming that
     I guessed right)
   - do the explicit disabling of already set options
   - convince us that the common-pc shouldn't be turning this
     on and trickle this option out to the leaf BSPs.

Cheers,

Bruce


>
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Configuring a layer to support multiple targets

[Chris Tapp]

On 17 Aug 2011, at 20:15, Bruce Ashfield wrote:

> The model is that you must explicitly chose values to modify
> them, otherwise, they flow through. Last through the gate wins.
> If you don't speak, others parts speak for the configuration.

That's what I was trying to say ;-)

> In this case, you must be inheriting the common-pc kernel  
> configuration.

I am.

> The solutions two this are:
> ...
>  - inherit from a base branch vs common-pc (assuming that I guessed  
> right)

Sounds like a plan. Where can I find a list of the branches in the  
4.0.1 meta data? I'm using the following to select one at the moment:

WRMACHINE_Vortex86DX  = "common_pc" --- I'm guessing I need something  
else here.

SRCREV_machine_pn-linux-wrs_Vortex86DX ?=  
"0431115c9d720fee5bb105f6a7411efb4f851d26"

>  - convince us that the common-pc shouldn't be turning this
>    on and trickle this option out to the leaf BSPs.

No, it seems perfectly reasonable to have this in 'common-pc'.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Configuring a layer to support multiple targets

[Chris Tapp]

On 17 Aug 2011, at 21:24, Bruce Ashfield wrote:

> I have to head out for the day, but I'll loop around on this.
> Technically I'm out of the office for the next 2 days, but can
> sneak this in. I just need to double check a couple things in
> the 2.6.34 support to see if inheriting from 'standard' directly
> will work for you .. and if it won't, I can give you patch
> to carry locally for a bit.

Thanks, but please don't speed too much time on it if 'standard' isn't  
going to work. This is only a research project at the moment and I can  
patch my defconf easily enough for now (especially as it seems I need  
to re-enable USB_SERIAL with USB_SERIAL_GENERIC to get the CM119 usb  
audio on the SoC to work, which means a defconf will now do what I  
want).

It would be nice to have a proper (generic) solution going forward,  
but I plan to switch to linux-yocto-stable in the pending release.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Configuring a layer to support multiple targets

[Bruce Ashfield]

On 11-08-17 04:42 PM, Chris Tapp wrote:
> On 17 Aug 2011, at 21:24, Bruce Ashfield wrote:
>
>> I have to head out for the day, but I'll loop around on this.
>> Technically I'm out of the office for the next 2 days, but can
>> sneak this in. I just need to double check a couple things in
>> the 2.6.34 support to see if inheriting from 'standard' directly
>> will work for you .. and if it won't, I can give you patch
>> to carry locally for a bit.
>
> Thanks, but please don't speed too much time on it if 'standard' isn't
> going to work. This is only a research project at the moment and I can
> patch my defconf easily enough for now (especially as it seems I need to
> re-enable USB_SERIAL with USB_SERIAL_GENERIC to get the CM119 usb audio
> on the SoC to work, which means a defconf will now do what I want).
>
> It would be nice to have a proper (generic) solution going forward, but
> I plan to switch to linux-yocto-stable in the pending release.

As it turns out, you would need some tweaks to the kern tools
(backports) to get this working. There's low value in this, so
as you said, if you don't need it. I'll consider this a closed
issue and I can help on newer releases (and have some docs) to
show you what is required.

Bruce

>
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Configuring a layer to support multiple targets

[Chris Tapp]

On 22 Aug 2011, at 19:52, Bruce Ashfield wrote:

> As it turns out, you would need some tweaks to the kern tools
> (backports) to get this working. There's low value in this, so
> as you said, if you don't need it. I'll consider this a closed
> issue and I can help on newer releases (and have some docs) to
> show you what is required.

Thanks Bruce, that sounds good it me :-)

Chris Tapp

opensource@keylevel.com
www.keylevel.com