[yocto] Adding kernel module to yocto core-image-base

[pravas kumar Panda]

Hi all,

I want to know how to add a kernel module using my own layer and recipe in
yocto.
Can someone suggest me the step by step process how to do it. how to edit
or add
new files so that i could build my image and the module should
automatically loaded
at the time of boot.please reply me with the step by step procedure.

Thanks in advance.

Regards,
Pravas Kumar Panda
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding kernel module to yocto core-image-base

[Iván Castell]

Hello.

First you need to reconfigure your kernel configuration (ncurses must be
properly installed in your host PC):

$ bitbake -c menuconfig virtual/kernel

After you need to generate a fragment.cfg (containing a diff betweeen your
default and your recently customized kernel config):

$ bitbake -c diffconfig  virtual/kernel

Thak will generate the fragment.cfg fine into your ${WORKDIR}

Then you need to create a bbappend in your own BSP layer extending the
content of your working kernel recipe. Something similar to this:

$ cat your-custom-bsp-layer/recipes-kernel/linux/linux-kernel_%.bbappend

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

SUMMARY = "Linux kernel customization for your board"
LINUX_VERSION = "x.y.z"

inherit kernel

SRC_URI += " \
file://fragment.cfg \
"

Just replace x.y.z by your specific kernel version. The fragment.cfg file
must be available inside your own kernel recipe, in a directory named ${PN}
(as indicated by FILESEXTRAPATHS_prepend):

$ ls your-custom-bsp-layer/recipes-kernel/linux/linux-kernel
fragment.cfg

Then you already can build your new kernel:

$ bitbake virtual/kernel

Hope this helps!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] YOCTO kernel PF_CAN feature set and socketCAN layer of the shelf?

[Mirza Krak]

On 6 June 2018 at 11:35, Zoran Stojsavljevic
 wrote:
> Hello to YOCTO community,
>
> I am looking into the new CAN FD (CAN Flexible Data rate) protocol. It
> is very similar to classical CAN.
>
> I am wondering the following (I'll ask very basic questions, just to
> see if I am on the right tracks):
> [1] Do YOCTO kernels have CAN drivers left as mandatory drivers in the
> drivers/ tree (CAN drivers exist on kernel.org kernels)?
> [2] If YES, are these drivers enabled by default, or I need to enable
> them? Anybody to quickly refresh me how to manipulate make menuconfig
> in YOCTO tree?

SocketCAN is very hardware specific and you do not mention which
hardware you are using.

>
> I also need the feature called: SocketCAN. The following questions arise:
> [3] Do we have in the socket I/Fs added PF_CAN protocol family handling?
>  https://en.wikipedia.org/wiki/SocketCAN
> [4] Does added SocketCAN layer exist, which covers this topic? It'll
> be layer on the top of the YOCTO-BSP layer, my best guess. Any
> examples, using such a layer? Or any Open Source example(s) of such a
> layer?

I am not aware of any layers and I do not believe that there is any.
SocketCAN is a Linux kernel feature and there are a set of utils to
use SocketCAN [1] and there seems to be a recipe for can-utils in
meta-oe [2] which should be enough to get you started.

[1]. https://github.com/linux-can/can-utils
[2]. http://layers.openembedded.org/layerindex/recipe/24252/

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Target CPU architectures that Yocto Project Support

[Alexander Kanavin]

You start by defining 'works'. It can be anything from quickly
building an image and booting it on the target hardware to see a login
prompt, to running a massive test suite and achieving 100% pass rate.

Alex

2018-06-12 2:14 GMT+03:00 Ricardo Ramirez :
> Thanks for the reply, Khem!
>
> What steps should I follow to be able to verify the build I put together for
> SPARCv9 works (or doesn't)?
>
> I realize it is a pretty non-conventional (newbie like) question but I'd
> like to follow a methodological procedure to validate the build.
>
> I appreciate your answer.
>
> -R
>
> On Mon, Jun 11, 2018 at 5:41 PM, Khem Raj  wrote:
>>
>> Hi Ricardo
>>
>> On 6/10/18 7:06 PM, Ricardo Ramirez wrote:
>>>
>>> Hi David,
>>>
>>> Thanks for the prompt reply!
>>>
>>> My question was a follow up of Khem's inquire (posted on 2014-05-02)
>>>
>>> https://lists.yoctoproject.org/pipermail/yocto/2014-May/019387.html
>>>
>>
>> this reply still holds as of today.
>>
>>> Using the links you sent me, I found that the old OE-Classic branch
>>> supports sparc32 but didn't see any sparc64
>>>
>>> http://layers.openembedded.org/layerindex/oe-classic/recipes/
>>>
>>> As such, I'd like to know what steps I need to follow in order to enable
>>> a SPARCv9 machine in Yocto.
>>>
>>
>> We support arm/aarch64/mips/mips64/ppc/ppc64/riscv64/x86/x86_64 for major
>> arches in OE-Core, we also carry patches to support SH4 but do not test
>> actively for it. sparc support is in there atleast I see basic constructs
>> are there. Its should be possible to build upon that easily. But it will not
>> work out of box to set your expectations right.
>>
>>> I appreciate your answer.
>>>
>>> -R
>>>
>>>
>>> On Sun, Jun 10, 2018 at 7:17 PM, Reyna, David >> > wrote:
>>>
>>> Hi Ricardo,
>>>
>>> __ __
>>>
>>> If you are asking about the list of MACHINE types that Yocto Project
>>> supports, then the best place to look is in the Layer Index:
>>>
>>> __ __
>>>
>>> https://layers.openembedded.org/layerindex/branch/master/layers/
>>>
>>> 
>>>
>>> __ __
>>>
>>> Click on the “Machines” tab, click on the “Search” tab with or
>>> without a search value, and see the glorious list.
>>>
>>> __ __
>>>
>>> The same goes for supported layers, recipes, classes, and distro
>>> values.
>>>
>>> __ __
>>>
>>> You can change the “Branch” value to see the MACHINE’s per
>>> release.
>>>
>>> __ __
>>>
>>> - David Reyna
>>>
>>> __ __
>>>
>>> *From:*yocto-boun...@yoctoproject.org
>>> 
>>> [mailto:yocto-boun...@yoctoproject.org
>>> ] *On Behalf Of *Ricardo
>>> Ramirez
>>> *Sent:* Sunday, June 10, 2018 5:07 PM
>>> *To:* yocto@yoctoproject.org 
>>> *Subject:* Re: [yocto] Target CPU architectures that Yocto Project
>>> Support
>>>
>>> __ __
>>>
>>> Hi,
>>>
>>> __ __
>>>
>>> Naive question from a newbie. How can this be achieved? I'd
>>> appreciate if you could please shed some light on what steps need to
>>> be followed?
>>>
>>> __ __
>>>
>>> Thanks in advance,
>>>
>>> __ __
>>>
>>> -R
>>>
>>>
>>>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Target CPU architectures that Yocto Project Support

[Ricardo Ramirez]

 Hi Alex,

You are right. I didn't define a clear scope for what I wanted to validate.
Apologies about that imprecision.

If possible, I'd like to divide the validation process into three stages

1. The system has a clean boot up process
2. The system is tested using a C-based benchmark (e.g. SPEC CPU2006)
3. The system is validated using a more complex set of testbench frameworks
(e.g. http://www.phoronix-test-suite.com/))

My immediate goal is to accomplish stages 1 and 2.

Considering the stages listed above, what steps would I need to follow?

I appreciate your help.


On Tue, Jun 12, 2018 at 4:37 AM, Alexander Kanavin 
wrote:

> You start by defining 'works'. It can be anything from quickly
> building an image and booting it on the target hardware to see a login
> prompt, to running a massive test suite and achieving 100% pass rate.
>
> Alex
>
> 2018-06-12 2:14 GMT+03:00 Ricardo Ramirez :
> > Thanks for the reply, Khem!
> >
> > What steps should I follow to be able to verify the build I put together
> for
> > SPARCv9 works (or doesn't)?
> >
> > I realize it is a pretty non-conventional (newbie like) question but I'd
> > like to follow a methodological procedure to validate the build.
> >
> > I appreciate your answer.
> >
> > -R
> >
> > On Mon, Jun 11, 2018 at 5:41 PM, Khem Raj  wrote:
> >>
> >> Hi Ricardo
> >>
> >> On 6/10/18 7:06 PM, Ricardo Ramirez wrote:
> >>>
> >>> Hi David,
> >>>
> >>> Thanks for the prompt reply!
> >>>
> >>> My question was a follow up of Khem's inquire (posted on 2014-05-02)
> >>>
> >>> https://lists.yoctoproject.org/pipermail/yocto/2014-May/019387.html
> >>>
> >>
> >> this reply still holds as of today.
> >>
> >>> Using the links you sent me, I found that the old OE-Classic branch
> >>> supports sparc32 but didn't see any sparc64
> >>>
> >>> http://layers.openembedded.org/layerindex/oe-classic/recipes/
> >>>
> >>> As such, I'd like to know what steps I need to follow in order to
> enable
> >>> a SPARCv9 machine in Yocto.
> >>>
> >>
> >> We support arm/aarch64/mips/mips64/ppc/ppc64/riscv64/x86/x86_64 for
> major
> >> arches in OE-Core, we also carry patches to support SH4 but do not test
> >> actively for it. sparc support is in there atleast I see basic
> constructs
> >> are there. Its should be possible to build upon that easily. But it
> will not
> >> work out of box to set your expectations right.
> >>
> >>> I appreciate your answer.
> >>>
> >>> -R
> >>>
> >>>
> >>> On Sun, Jun 10, 2018 at 7:17 PM, Reyna, David <
> david.re...@windriver.com
> >>> > wrote:
> >>>
> >>> Hi Ricardo,
> >>>
> >>> __ __
> >>>
> >>> If you are asking about the list of MACHINE types that Yocto
> Project
> >>> supports, then the best place to look is in the Layer Index:
> >>>
> >>> __ __
> >>>
> >>> https://layers.openembedded.org/layerindex/branch/master/layers/
> >>>
> >>> 
> >>>
> >>> __ __
> >>>
> >>> Click on the “Machines” tab, click on the “Search” tab with or
> >>> without a search value, and see the glorious list.
> >>>
> >>> __ __
> >>>
> >>> The same goes for supported layers, recipes, classes, and distro
> >>> values.
> >>>
> >>> __ __
> >>>
> >>> You can change the “Branch” value to see the MACHINE’s per
> >>> release.
> >>>
> >>> __ __
> >>>
> >>> - David Reyna
> >>>
> >>> __ __
> >>>
> >>> *From:*yocto-boun...@yoctoproject.org
> >>> 
> >>> [mailto:yocto-boun...@yoctoproject.org
> >>> ] *On Behalf Of *Ricardo
> >>> Ramirez
> >>> *Sent:* Sunday, June 10, 2018 5:07 PM
> >>> *To:* yocto@yoctoproject.org 
> >>> *Subject:* Re: [yocto] Target CPU architectures that Yocto Project
> >>> Support
> >>>
> >>> __ __
> >>>
> >>> Hi,
> >>>
> >>> __ __
> >>>
> >>> Naive question from a newbie. How can this be achieved? I'd
> >>> appreciate if you could please shed some light on what steps need
> to
> >>> be followed?
> >>>
> >>> __ __
> >>>
> >>> Thanks in advance,
> >>>
> >>> __ __
> >>>
> >>> -R
> >>>
> >>>
> >>>
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Target CPU architectures that Yocto Project Support

[Alexander Kanavin]

On 06/12/2018 04:07 PM, Ricardo Ramirez wrote:

You are right. I didn't define a clear scope for what I wanted to 
validate. Apologies about that imprecision.


If possible, I'd like to divide the validation process into three stages

1. The system has a clean boot up process
2. The system is tested using a C-based benchmark (e.g. SPEC CPU2006)
3. The system is validated using a more complex set of 
testbench frameworks (e.g. http://www.phoronix-test-suite.com/ 
))


My immediate goal is to accomplish stages 1 and 2.

Considering the stages listed above, what steps would I need to follow?


1. You need to create and boot an image for the target system, and run 
basic smoke tests (e.g. that you can log in, and the network is up and 
runing etc). We do this in a fully automated fashion when the target 
hardware is QEMU emulation of various machines:


bitbake -c testimage 

2. You need to place the benchmark software into the target image, by 
building and packaging it via yocto recipes that you need to write. I 
don't know if the recipes for benchmarks you mentioned are already 
available somewhere; in that case you can simply re-use that, and 
configure your image to include that. Then you boot the image on the 
target hardware and run the benchmarks.


Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mono][PATCH] layer.conf: define LAYERSERIES_COMPAT_mono = "sumo"

[Ioan-Adrian Ratiu]

Newer versions of bitbake require each layer to explicitely state
their OE/Yocto release compatibility. The consensus is for each layer
to use the latest released version codename for the master branch.

Signed-off-by: Ioan-Adrian Ratiu 
---
 conf/layer.conf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/conf/layer.conf b/conf/layer.conf
index 017a7c7..e3a10b9 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,3 +14,5 @@ PREFERRED_VERSION_mono ?= "5.4.1.6"
 PREFERRED_VERSION_mono-native ?= "5.4.1.6"
 
 PREFERRED_VERSION_nuget ?= "3.5.0"
+
+LAYERSERIES_COMPAT_mono = "sumo"
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Adding package's license to the final image

[Mathieu Alexandre-Tétreault]

Howdy,

I am working on a project that requires the final image to contain a license 
manifest for all the packaged installed on the image.

At first I though about using the tmp/deploy/licenses/xxx/license.manifest but 
this file is deployed by the IMAGE_POSTPROCESS_COMMAND_prepend which happens 
after the rootfs is done.

Would anyone have a suggestion on how to this properly without using any weird 
hack?

Cheers,
Mathieu
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] YOCTO kernel PF_CAN feature set and socketCAN layer of the shelf?

[Zoran Stojsavljevic]

Hello Mirza,

Thank you for giving me the hand here... But now (as we speak), I need
to have a short wait for the slipping milestone, before I apply all
this what you have given to me.

All of these are very/extremely useful info, and I'll report (when
time comes) what I got out of it. At least Open Source test info,
which, my best guess, I'll keep open for anybody who has the
same/similar problems/feature sets!

Please, stay tuned!
Zoran Stojsavljevic
___

On Tue, Jun 12, 2018 at 11:12 AM, Mirza Krak  wrote:
> On 6 June 2018 at 11:35, Zoran Stojsavljevic
>  wrote:
>> Hello to YOCTO community,
>>
>> I am looking into the new CAN FD (CAN Flexible Data rate) protocol. It
>> is very similar to classical CAN.
>>
>> I am wondering the following (I'll ask very basic questions, just to
>> see if I am on the right tracks):
>> [1] Do YOCTO kernels have CAN drivers left as mandatory drivers in the
>> drivers/ tree (CAN drivers exist on kernel.org kernels)?
>> [2] If YES, are these drivers enabled by default, or I need to enable
>> them? Anybody to quickly refresh me how to manipulate make menuconfig
>> in YOCTO tree?
>
> SocketCAN is very hardware specific and you do not mention which
> hardware you are using.
>
>>
>> I also need the feature called: SocketCAN. The following questions arise:
>> [3] Do we have in the socket I/Fs added PF_CAN protocol family handling?
>>  https://en.wikipedia.org/wiki/SocketCAN
>> [4] Does added SocketCAN layer exist, which covers this topic? It'll
>> be layer on the top of the YOCTO-BSP layer, my best guess. Any
>> examples, using such a layer? Or any Open Source example(s) of such a
>> layer?
>
> I am not aware of any layers and I do not believe that there is any.
> SocketCAN is a Linux kernel feature and there are a set of utils to
> use SocketCAN [1] and there seems to be a recipe for can-utils in
> meta-oe [2] which should be enough to get you started.
>
> [1]. https://github.com/linux-can/can-utils
> [2]. http://layers.openembedded.org/layerindex/recipe/24252/
>
> --
> Med Vänliga Hälsningar / Best Regards
>
> Mirza Krak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Generating license/manifest for a specific layer?

[Ulf Samuelsson]

I have been working on a release-notes bbclass which will for each recipe 
included in am image extract stuff like package name, license info, cve info, 
SUMMARY, DESCRIPTION etc. and generate LaTex files.
repo diffmanifests is used to extract the difference between a previous 
manifest and the current manifest. 
Each patch committed has a JIRA ticket number, and a LaTex file is generated 
with a symbolic link to our JIRA server.
Everything is collected by a separate project, and once the LaTex files are 
complete,
I only have to do 
make -release-notes.pdf.

Once it is merged locally, I am considering upstreaming.

Best Regards,
Ulf Samuelsson

> 11 juni 2018 kl. 15:46 skrev Michael Habibi :
> 
> Our use case is to capture the license files, manifest (package/version), and 
> download information only for packages we modify/add. We use our own layer to 
> modify/add packages, everything coming from standard Yocto layers are 
> untouched.
> 
> Is there a way to generate this information on a layer-by-layer basis, 
> instead of a full manifest that includes all standard, unmodified packages?
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Fwd: image-mklibs.bbclass fails

[Ulf Samuelsson]

I am currently upgrading a morty based rootfs to rocko, and today I found that 
the morty based poky layer had a patch which they sent upstream over one year 
ago.
Author Peter Liu
This is similar to what You suggested, and the fix works also in rocko.

We will decide tomorrow how to proceed.
Best Regards,
Ulf

> 29 maj 2018 kl. 21:43 skrev Khem Raj :
> 
>> On Mon, May 28, 2018 at 2:10 AM, Ulf Samuelsson  wrote:
>> Checked out poky
>> git checkout -b rocko origin/rocko
>> export MACHINE=beaglebone
>> . ./oe-init-build-env
>> 
>> Added to local.conf:
>> MKLIBS_OPTIMIZED_IMAGES_append = " core-image-minimal"
>> 
>> Result:
>> 
>> /core-image-minimal/1.0-r0/temp/run.mklibs_optimize_image.13363: line
>> 133: i586-poky-linux-readelf: command not found
>> ...
>> Exception: Cannot find
>> lib/home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/lib/ld-linux.so.2
>> WARNING:
>> /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/run.mklibs_optimize_image.13363:1
>> exit 1 from 'mklibs -v --ldlib ${dynamic_loader} --libdir lib --sysroot
>> /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot
>> --gcc-options
>> "--sysroot=/home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot"
>> --root
>> /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs
>> --target `echo i586-poky-linux- | sed 's/-$//' ` -d
>> /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/mklibs/dest
>> `cat
>> /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/mklibs/executables.list`'
>> ...
>> 
>> Looks like image-mklibs.bbclass has not been tested since the move to a
>> local sysroot happened.
> 
> It seems class should be adding a dependency on
> virtual/${TARGET_PREFIX}binutils-cross
> if that fixes the problem, please send the patch if not file a bug
> since there might be more to it.

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How handle files needing updates in read-only filesystem

[Ulf Samuelsson]

Thanks,

We want most of /etc to be read-only for security reasons,
and the overlayfs will make the whole of /etc writeable.

I tried mount —bind /etc/timezone /persistent/etc/timezone, and it complained 
that they were not directories. Bind mounting /etc again will make all of /etc 
writeable.

Symlinking to /persistent is fine, so the question is what an acceptable method 
is to have a simple way of ensuring that a certain file is converted to that 
symlink.



Best Regards,
Ulf Samuelsson
+46 722 427 437

10 juni 2018 kl. 01:36 skrev Peter Kjellerstedt :

>> -Original Message-
>> From: yocto-boun...@yoctoproject.org [mailto:yocto-
>> boun...@yoctoproject.org] On Behalf Of Ulf Samuelsson
>> Sent: den 9 juni 2018 11:51
>> To: yocto@yoctoproject.org
>> Subject: [yocto] How handle files needing updates in read-only
>> filesystem
>> 
>> We have a rootfs which is read-only.
>> For files that needs to be updated, like "/etc/localtime"
>> we will create a symbolic link to a partition (/persistent) which
>> is retained between rootfs image updates.
>> 
>> /etc/localtime -> /persistent/etc/localtime
>> 
>> The original recipe will generate the real /etc/localtime of course.
>> 
>> To support the file beeing updated, the following needs to be done in a
>> rootfs postprocess.
>> 
>> mv   /etc/localtime /update/etc/localtime
>> ln   -sf /persistent/etc/localtime /etc/localtime
>> install -m 0644 /update/etc/localtime /persistent/etc/localtime
>> chown : /persistent/etc/localtime
>> 
>> The last two commands needs to be executed on the running system,
>> since /persistent is not part of the rootfs.
>> 
>> To ensure that the file can be updated is an ad-hoc activity for each
>> affected file. It would be better if there was a class where you
>> declare
>> a file to be writeable, and then a post process
>> would move the file to /update (or similar) and create a symbolic link
>> 
>> SETTINGS ?= "/persistent"
>> =
>> inherit writeable
>> 
>> WRITEABLE = "/etc/localtime"
>> =
>> 
>> This would generate the first two commands for each listed file.
>> 
>> mv   /etc/localtime /update/etc/localtime
>> ln   -sf ${SETTINGS}/etc/localtime /etc/localtime
>> 
>> The file would also be added to a file indicating that it may need
>> to be copied to the ${SETTINGS}
>> 
>> Is it a good solution to modify "populate_volatiles.sh"
>> to support a second file parameter for the f (file) command
>> in the /etc/default/volatiles file?
>> 
>> Today the file create command looks like:
>> f 
>> 
>> An idea would be to have the following syntax:
>> f 
>> 
>> If  is a valid filepath, then copy this file to 
>> If  is not a valid filepath, create  using "touch"
>> 
>> This would break any build which has a "funny" volatiles file.
>> Otherwise a script called populate_persistent.sh could be
>> created with such an extension.
>> 
>> Comments?
>> 
>> BR
>> Ulf Samuelsson
> 
> Since a  lot of files in /etc typically need to be writable, one way to 
> handle this is by using an overlayfs for /etc. That is what we do and 
> it works very well.
> 
> An alternative, more along your suggestion, is to use bind mounts. The 
> advantage of using a bind mount instead of a symbolic link is that it 
> will look as a normal file.
> 
> You should look into the volatile-binds recipe and the VOLATILE_BINDS 
> variable. It is used to handle directories that need to be writable. 
> It will create systemd service files that copies the non-volatile 
> directory to the volatile directory (if it does not already exists), 
> and the bind mounts it back. 
> 
> I am not sure volatile-binds works out-of-the-box for files, but I 
> believe it does. If not, it should not be too hard to modify it so 
> that it can handle files as well.
> 
> //Peter
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Issue when integrating different bsp-layers on a single bblayers.conf

[Ulf Samuelsson]

You can BBMASK away that bbappend when you are not building the rockchip 
machine.

Best Regards,
Ulf Samuelsson

> 7 juni 2018 kl. 16:39 skrev Iván Castell :
> 
> Hello forum.
> 
> I am trying to integrate several BSP-layers for different platforms on a 
> single Yocto repository to build a Linux Yocto-based distro for all those 
> platforms easily.
> 
> The idea is maintaining a single bblayers.conf with all the layers available, 
> set PLATFORM and DISTRO on local.conf, call bitbake  and get the final 
> image for that platform.
> 
> When setting the "build" directory with a bblayers.conf customized for a 
> single platform, each platform builds the image recipe properly.
> 
> However, when I have integrated all bsp-layers in a single bblayers.conf, the 
> compilation of some platforms has been broken.
> 
> The specific problem is this: one bsp layer (meta-rockchip + 
> meta-rockchip-extra) defines a recipes-graphics/mesa/mesa_%.bbappend with 
> this content inside:
> 
> PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl 
> virtual/libwayland-egl"
> 
> That alters gstreamer recipe on the poky layer, getting this error when 
> building for a meta-intel platform:
> 
> ERROR: Nothing PROVIDES 'virtual/egl' (but 
> /data/yocto/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.2.bb,
>  
> /data/yocto/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.12.2.bb
>  DEPENDS on or otherwise requires it)
> 
> My questions:
> 
> - Is a good practice to define a custom bblayers.conf depending on the 
> choosen PLATFORM?
> - Is there some any other way to disable a BSP-layer completely when 
> building for a different one?
> - Can you suggest a fix to solve this issue?
> 
> Thanks a lot in advance! :)
> 
> Kind regards.
>   -- Ivan
> 
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Image specific configuration files

[Ulf Samuelsson]

You can create three separate recipes that generate three different nginx 
configurations and include one if them in each image recipe.


Best Regards,
Ulf Samuelsson

> 1 juni 2018 kl. 07:46 skrev Damien LEFEVRE :
> 
> Hi,
> 
> For the same MACHINE I create the following images:
> - myimage-production
> - myimage-rnd
> - myimage-retail
> 
> The production one has production assisted tools for flashing peripheral HW, 
> testing vital HW components, writing some serial numbers, etc.
> 
> The rnd one has more packages than the retail one just to help rnd work and 
> debugging in device, but none of the rnd image extra packages. 
> 
> The retail one has the final product image.
> 
> I'm using web and FTP servers. I would like for the rnd version of the image 
> to have a different nginx configuration to set the root directory to a 
> development folder, or set an alias.
> 
> Furthermore, I'll have different variant of the device where only the device 
> SW changes but the platform is identical. So I'll end up with 
> - myimage2-production
> - myimage2-rnd
> - myimage2-retail
> 
> I know how to make MACHINE based configuration. How could I do this in my 
> nginx.bbappend based on image name?
> 
> Thanks,
> -Damien
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Issue when integrating different bsp-layers on a single bblayers.conf

[Ulf Samuelsson]

Maybe something similar to this in local.conf

BBMASK .= "${@base_conditional('MACHINE', '', 
'','|meta-rockchip/recipes-*', d)}"
(did not test)
If there are multiple machines in the meta-rockchip layer, you have to look for 
a unique variable which is true only if a machine in the meta-rockchip layer is 
used.


Best Regards,
Ulf Samuelsson

> 7 juni 2018 kl. 16:39 skrev Iván Castell :
> 
> Hello forum.
> 
> I am trying to integrate several BSP-layers for different platforms on a 
> single Yocto repository to build a Linux Yocto-based distro for all those 
> platforms easily.
> 
> The idea is maintaining a single bblayers.conf with all the layers available, 
> set PLATFORM and DISTRO on local.conf, call bitbake  and get the final 
> image for that platform.
> 
> When setting the "build" directory with a bblayers.conf customized for a 
> single platform, each platform builds the image recipe properly.
> 
> However, when I have integrated all bsp-layers in a single bblayers.conf, the 
> compilation of some platforms has been broken.
> 
> The specific problem is this: one bsp layer (meta-rockchip + 
> meta-rockchip-extra) defines a recipes-graphics/mesa/mesa_%.bbappend with 
> this content inside:
> 
> PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl 
> virtual/libwayland-egl"
> 
> That alters gstreamer recipe on the poky layer, getting this error when 
> building for a meta-intel platform:
> 
> ERROR: Nothing PROVIDES 'virtual/egl' (but 
> /data/yocto/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.2.bb,
>  
> /data/yocto/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.12.2.bb
>  DEPENDS on or otherwise requires it)
> 
> My questions:
> 
> - Is a good practice to define a custom bblayers.conf depending on the 
> choosen PLATFORM?
> - Is there some any other way to disable a BSP-layer completely when 
> building for a different one?
> - Can you suggest a fix to solve this issue?
> 
> Thanks a lot in advance! :)
> 
> Kind regards.
>   -- Ivan
> 
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding kernel module to yocto core-image-base

[Ulf Samuelsson]

There is an example in meta-skeleton/recipes-kernel

Best Regards,
Ulf Samuelsson

> 12 juni 2018 kl. 09:33 skrev Iván Castell :
> 
> Hello.
> 
> First you need to reconfigure your kernel configuration (ncurses must be 
> properly installed in your host PC):
> 
> $ bitbake -c menuconfig virtual/kernel
> 
> After you need to generate a fragment.cfg (containing a diff betweeen your 
> default and your recently customized kernel config):
> 
> $ bitbake -c diffconfig  virtual/kernel
> 
> Thak will generate the fragment.cfg fine into your ${WORKDIR}
> 
> Then you need to create a bbappend in your own BSP layer extending the 
> content of your working kernel recipe. Something similar to this:
> 
> $ cat your-custom-bsp-layer/recipes-kernel/linux/linux-kernel_%.bbappend
> 
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> 
> SUMMARY = "Linux kernel customization for your board"
> LINUX_VERSION = "x.y.z"
> 
> inherit kernel
> 
> SRC_URI += " \
> file://fragment.cfg \
> "
> 
> Just replace x.y.z by your specific kernel version. The fragment.cfg file 
> must be available inside your own kernel recipe, in a directory named ${PN} 
> (as indicated by FILESEXTRAPATHS_prepend):
> 
> $ ls your-custom-bsp-layer/recipes-kernel/linux/linux-kernel
> fragment.cfg
> 
> Then you already can build your new kernel:
> 
> $ bitbake virtual/kernel
> 
> Hope this helps!
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Image specific configuration files

[Ulf Samuelsson]

In my current project they have defined bbclass files to allow variants of 
recipes.
The recipe would then contain  do_install_append_XYZ’s for each class.

BBCLASSEXTEND = ”production rnd retail”

would ensure you would get nginx-production, nginx-rnd, nginx-retail ipks.

This way you have one recipe generating three variants in the same build.

Don’t have the source in front of me  so I can’t share the bbclass (right now 
at least)

Best Regards,
Ulf Samuelsson
+46 722 427 437

> 1 juni 2018 kl. 12:40 skrev Alan Martinovic :
> 
> Yes, much better phrasing:
> 
> > A single bitbake invocation always builds a single distro for a specific 
> > target machine
> 
> Thanks 
> 
>> On Fri, Jun 1, 2018 at 12:18 PM, Alexander Kanavin  
>> wrote:
>> If a build is 'a single bitbake invocation', then yes - it builds for a 
>> single distro and for a specific target machine, but it can build multiple 
>> recipes (which includes multiple images, as images are defined with recipes).
>> 
>> Alex
>> 
>> 
>> 2018-06-01 13:07 GMT+03:00 Alan Martinovic :
>>> Hey Alexander,
>>> you seem to have a good understanding on the concepts.
>>> Would you say that:
>>> 
>>> > A build always builds a single distro
>>> 
>>> is somewhat of a rule?
>>> 
>>> 
>>> 
>>> 
 On Fri, Jun 1, 2018 at 11:24 AM, Alexander Kanavin 
  wrote:
 I have to say defining multiple distros and then tweaking recipes 
 according to those definitions is not a good practice, as recipes should 
 generally only access DISTRO_FEATURES and otherwise be distro-agnostic. 
 The above iptables scenario should be handled with different image 
 recipes, which pull in (via packages) or create different configurations.
 
 Alex
 
 2018-06-01 12:04 GMT+03:00 Iván Castell :
> I can provide more details. My custom layer has these files related with 
> distro:
> 
> my_layer/conf/distro/include/common.conf
> my_layer/conf/distro/develop.conf
> my_layer/conf/distro/production.conf
> my_layer/conf/distro/integration.conf
> 
> As an example of the previous files, 
> my_layer/conf/distro/include/develop.conf has this content:
> 
> require conf/distro/include/common.conf
> DISTRO = "my-distro-development"
> DISTRO_NAME = "OS Development"
> DISTRO_STAGE = "development"
> # And here more customizations as setting root password, PRSERV_HOST, 
> or PACKAGE_FEED_URIS
> 
> In common.conf I define all features common to all my distros 
> (PACKAGE_CLASSES and so on)
> 
> I have custom iptables rules, then I have different files for that rules:
> 
> my/layer/recipes-extended/iptables/files/iptables.rules.development
> my/layer/recipes-extended/iptables/files/iptables.rules.production
> my/layer/recipes-extended/iptables/files/iptables.rules.integration
> 
> I use a bbappend recipe for iptables, modifiying do_install_append task 
> like this:
> 
> install -m 0600 ${WORKDIR}/iptables.rules.${DISTRO_STAGE} 
> ${D}/etc/iptables/iptables.rules
> 
> I use a single image recipe to define all packages installed in my final 
> image (all of them have the same set if packages, but with different 
> customizations)
> 
> Finally, I wrote a setup-build-env.sh script in my custom layer to 
> configure the build easily. That script creates 
> build-${DISTRO_STAGE}/conf/bblayers.conf and 
> build-${DISTRO_STAGE}/conf/local.conf files with the proper setup, 
> setting MACHINE, DISTRO and DL_DIR (shared by all distros) properly.
> 
> Hope this helps!
> 
> 
> 
> 
> 
> 2018-06-01 10:21 GMT+02:00 Alan Martinovic :
>> Hey,
>> would really like to see your example.
>> Am struggling to get creation of these types of images for a while now.
>> 
>> So far have avoided diving into multiple distros because would like to 
>> have the option
>> of building all the images at the same time (so they are basically the 
>> same distro).
>> 
>>> On Fri, Jun 1, 2018 at 8:13 AM, Iván Castell 
>>>  wrote:
>>> I fixed this issue defining different distro.conf files in my custom 
>>> layer, adding a custom variable DISTRO_STAGE with the name of my distro 
>>> (production, rnd, retail, and so on), Then you setup DISTRO in your 
>>> local.conf to the proper value you want to use. Finally you can use 
>>> that DISTRO_STAGE variable in your custom .bb or .bbappend recipes to 
>>> decide the proper configuration files you want to install in your final 
>>> image. That works as expected. Hope this helps!
>>> 
>>> 
>>> 
>>> 
>>> 2018-06-01 7:46 GMT+02:00 Damien LEFEVRE :
 Hi,
 
 For the same MACHINE I create the following images:
 - myimage-production
 - myimage-rnd
 - myimage-retail
 
 The productio

Re: [yocto] Patch for custom imager plugin in wic.

[Paul Knopf]

Can anybody see this message? lol

On Tue, Jun 5, 2018 at 10:05 AM, Paul Knopf  wrote:

> Can someone instruct me on the proper protocol to request a change?
>
> On Wed, May 23, 2018 at 1:37 PM, Paul Knopf 
> wrote:
>
>> Can this change be merged into master?
>>
>> On Mon, May 21, 2018 at 5:00 PM, Paul Knopf 
>> wrote:
>>
>>> From 136d6214b6fc2c1118dac5b7f3e029ed006fab8a Mon Sep 17 00:00:00 2001
>>> From: Paul Knopf 
>>> Date: Mon, 21 May 2018 16:56:51 -0400
>>> Subject: [PATCH] Support for changing the imager used in wic.
>>>
>>> ---
>>>  scripts/lib/wic/engine.py | 2 +-
>>>  scripts/wic   | 1 +
>>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/scripts/lib/wic/engine.py b/scripts/lib/wic/engine.py
>>> index edcfab3..d7c5c11 100644
>>> --- a/scripts/lib/wic/engine.py
>>> +++ b/scripts/lib/wic/engine.py
>>> @@ -191,7 +191,7 @@ def wic_create(wks_file, rootfs_dir, bootimg_dir,
>>> kernel_dir,
>>>  if not os.path.exists(options.outdir):
>>>  os.makedirs(options.outdir)
>>>
>>> -pname = 'direct'
>>> +pname = options.imager
>>>  plugin_class = PluginMgr.get_plugins('imager').get(pname)
>>>  if not plugin_class:
>>>  raise WicError('Unknown plugin: %s' % pname)
>>> diff --git a/scripts/wic b/scripts/wic
>>> index 7392bc4..255e524 100755
>>> --- a/scripts/wic
>>> +++ b/scripts/wic
>>> @@ -360,6 +360,7 @@ def wic_init_parser_create(subparser):
>>>  subparser.add_argument("-v", "--vars", dest='vars_dir',
>>>help="directory with .env files that store
>>> "
>>> "bitbake variables")
>>> +subparser.add_argument("-i", "--imager", dest="imager",
>>> default="direct", help="the wic imager plugin")
>>>  subparser.add_argument("-D", "--debug", dest="debug",
>>> action="store_true",
>>>default=False, help="output debug information")
>>>  return
>>> --
>>> 2.7.4
>>>
>>>
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Adding package's license to the final image

[Mathieu Alexandre-Tétreault]

Howdy,

I am working on a project that requires the final image to contain a license 
manifest for all the packaged installed on the image.

At first I though about using the tmp/deploy/licenses/xxx/license.manifest but 
this file is deployed by the IMAGE_POSTPROCESS_COMMAND_prepend which happens 
after the rootfs is done.

Would anyone have a suggestion on how to this properly without using any weird 
hack?

Cheers,
Mathieu
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Adding package's license to the final image

[Mathieu Alexandre-Tétreault]

Howdy,

I am working on a project that requires the final image to contain a license 
manifest for all the packaged installed on the image.

At first I though about using the tmp/deploy/licenses/xxx/license.manifest but 
this file is deployed by the IMAGE_POSTPROCESS_COMMAND_prepend which happens 
after the rootfs is done.

Would anyone have a suggestion on how to this properly without using any weird 
hack?

Cheers,
Mathieu
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Patch for custom imager plugin in wic.

[Anuj Mittal]

On 06/13/2018 02:47 AM, Paul Knopf wrote:
> From 136d6214b6fc2c1118dac5b7f3e029ed006fab8a Mon Sep 17 00:00:00 2001
> From: Paul Knopf mailto:pauldotkn...@gmail.com>>
> Date: Mon, 21 May 2018 16:56:51 -0400
> Subject: [PATCH] Support for changing the imager used in wic.
> 
> ---
>  scripts/lib/wic/engine.py | 2 +-
>  scripts/wic               | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)

Patches to OE-core should be sent to
openembedded-c...@lists.openembedded.org. Are you using a custom imager
plugin?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] QA cycle report for 2.4.3 RC2

[Yeoh, Ee Peng]

Hello All,

This is the full report for 2.4.3 RC2:  
https://wiki.yoctoproject.org/wiki/WW24_-_2018-06-12-_Full_Test_Cycle_-_2.4.3_rc2

=== Summary 

The QA cycle for release 2.4.3 RC2 was completed.  Team had found that 
virtual/kernel build time had increased by 10% and 18% accordingly on Centos 7 
and Ubuntu 1604 performance machines.  Team found that libxml2 pTest was 
failed.  No other new bugs were discovered. 

=== QA-Hints

QA shows no major bug.

=== Bugs 

New Bugs
[1] Bug 12782 - [2.4.3.rc2] libxml2 ptest failed
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12782

Regards
Ee Peng 


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding package's license to the final image

[Andrea Galbusera]

Hi!

On Tue, Jun 12, 2018 at 8:53 PM Mathieu Alexandre-Tétreault
 wrote:
>
> Howdy,
>
> I am working on a project that requires the final image to contain a license 
> manifest for all the packaged installed on the image.

Take a look at [1]. There's background on licence tacking and a
technique to include licenses in target images (never tested myself).

[1] 
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#providing-license-text

>
> At first I though about using the tmp/deploy/licenses/xxx/license.manifest 
> but this file is deployed by the IMAGE_POSTPROCESS_COMMAND_prepend which 
> happens after the rootfs is done.
>
> Would anyone have a suggestion on how to this properly without using any 
> weird hack?
>
> Cheers,
> Mathieu
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto