Re: [yocto] [meta-raspberrypi] how to customize kernel config?
On 12/06/2014 07:48, Jonatan Magnusson wrote:
> Hi
>
> I’m trying to use the meta-raspberrypi BSP with Yocto (1.6, Daisy).
>
> It works great, except I have no idea how to use a custom kernel config!
>
> I have a custom kernel recipe that bbappends to the meta-raspberrypi kernel
> recipe.
>
> I’ve tried using defconfig as well as configuration fragments, but neither
> work.
>
> I’ve also tried using the kernel_configure_variable function, and that almost
> works, except if I try to disable an option that is enabled earlier in the
> the config file, the option is still enabled since kernel_configure_variable
> only appends to the config file.
>
> Example:
>
> do_configure_append() {
> kernel_configure_variable SPI_SPIDEV n
> }
>
> So I wonder: how is this supposed to work?
>
I don't think the RPi kernel recipe supports the linux-yocto include and
thus kernel fragments, which would be the preferred way to do things.
(At least if it does I didn't manage to get it working - I am
considering trying to add support for this in).
In the meantime to create a configuration I
bitbake -c menuconfig virtual/kernel
Edit the settings and save the resulting .config file
Then if you go to
bitbake -c devshell virtual/kernel
You can copy the .config file out of there to your source tree
Then the recipe I use to build with that configuration is something like
this, with my_defconfig in a patch
containing linux-raspberrypi folder set for searching with the path prepend,
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
KERNEL_DEFCONFIG = "my_defconfig"
SRC_URI += "file://rov_defconfig"
do_configure_prepend() {
cp ${WORKDIR}/my_defconfig ${S}/arch/arm/configs
}
Regards,
Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] add recipe cim-schema, cim-schema-docs and license file DMTF.
On Thu, Jun 12, 2014 at 11:26:57AM +0800, Yao Xinpan wrote:
> Signed-off-by: Yao Xinpan
Why is this recipe needed in oe-core layer? Wouldn't meta-networking be
more suitable?
The patch also belongs to oe-core ML not yocto.
> ---
> meta/files/common-licenses/DMTF| 34
> ++
> .../cim-schema/cim-schema-docs_2.40.0.bb | 23 +++
> meta/recipes-support/cim-schema/cim-schema.inc | 9 ++
> .../cim-schema/cim-schema_2.40.0.bb| 31
> meta/recipes-support/cim-schema/files/LICENSE | 34
> ++
> 5 files changed, 131 insertions(+)
> create mode 100644 meta/files/common-licenses/DMTF
> create mode 100644 meta/recipes-support/cim-schema/cim-schema-docs_2.40.0.bb
> create mode 100644 meta/recipes-support/cim-schema/cim-schema.inc
> create mode 100644 meta/recipes-support/cim-schema/cim-schema_2.40.0.bb
> create mode 100644 meta/recipes-support/cim-schema/files/LICENSE
>
> diff --git a/meta/files/common-licenses/DMTF b/meta/files/common-licenses/DMTF
> new file mode 100644
> index 000..54a2812
> --- /dev/null
> +++ b/meta/files/common-licenses/DMTF
> @@ -0,0 +1,34 @@
> +// Copyright 1998-2008 Distributed Management Task Force, Inc. (DMTF).
> +// All rights reserved.
> +// DMTF is a not-for-profit association of industry members dedicated
> +// to promoting enterprise and systems management and interoperability.
> +// DMTF specifications and documents may be reproduced by
> +// members and non-members, provided that correct attribution is given.
> +// As DMTF specifications may be revised from time to time,
> +// the particular version and release date should always be noted.
> +//
> +// Implementation of certain elements of this standard or proposed
> +// standard may be subject to third party patent rights, including
> +// provisional patent rights (herein "patent rights"). DMTF makes
> +// no representations to users of the standard as to the existence
> +// of such rights, and is not responsible to recognize, disclose, or
> +// identify any or all such third party patent right, owners or
> +// claimants, nor for any incomplete or inaccurate identification or
> +// disclosure of such rights, owners or claimants. DMTF shall have no
> +// liability to any party, in any manner or circumstance, under any
> +// legal theory whatsoever, for failure to recognize, disclose, or
> +// identify any such third party patent rights, or for such party's
> +// reliance on the standard or incorporation thereof in its product,
> +// protocols or testing procedures. DMTF shall have no liability to
> +// any party implementing such standard, whether such implementation
> +// is foreseeable or not, nor to any patent owner or claimant, and shall
> +// have no liability or responsibility for costs or losses incurred if
> +// a standard is withdrawn or modified after publication, and shall be
> +// indemnified and held harmless by any party implementing the
> +// standard from any and all claims of infringement by a patent owner
> +// for such implementations.
> +//
> +// For information about patents held by third-parties which have
> +// notified the DMTF that, in their opinion, such patent may relate to
> +// or impact implementations of DMTF standards, visit
> +// http://www.dmtf.org/about/policies/disclosures.php.
> diff --git a/meta/recipes-support/cim-schema/cim-schema-docs_2.40.0.bb
> b/meta/recipes-support/cim-schema/cim-schema-docs_2.40.0.bb
> new file mode 100644
> index 000..06c0dd9
> --- /dev/null
> +++ b/meta/recipes-support/cim-schema/cim-schema-docs_2.40.0.bb
> @@ -0,0 +1,23 @@
> +require cim-schema.inc
> +
> +LICENSE = "DMTF"
> +
> +SRC_URI =
> "http://dmtf.org/sites/default/files/cim/cim_schema_v2400/cim_schema_${PV}Final-Doc.zip
> \
> + file://LICENSE \
> + "
> +SRC_URI[md5sum] = "3d01940bc1085c6c42184c25fb61f739"
> +SRC_URI[sha256sum] =
> "3174cf0f8657b19d80dc59e184778d8e553da424728cb2966fe9d5428dd84267"
> +LIC_FILES_CHKSUM =
> "file://${WORKDIR}/LICENSE;md5=eecc6f71a56ff3caf17f15bf7aeac7b4"
> +
> +do_unpack() {
> +unzip -q ${DL_DIR}/cim_schema_${PV}Final-Doc.zip -d ${S}
> +cp -f ${FILE_DIRNAME}/files/LICENSE ${WORKDIR}/
> +}
> +
> +do_install() {
> +install -d -m 0755 ${D}${datadir}/doc/cim-schema-${PV}-docs
> +cp -a ${S}/* ${D}${datadir}/doc/cim-schema-${PV}-docs
> +}
> +
> +FILES_${PN} = "${datadir}/doc/*"
> +FILES_${PN}-doc = ""
> diff --git a/meta/recipes-support/cim-schema/cim-schema.inc
> b/meta/recipes-support/cim-schema/cim-schema.inc
> new file mode 100644
> index 000..e35bff6
> --- /dev/null
> +++ b/meta/recipes-support/cim-schema/cim-schema.inc
> @@ -0,0 +1,9 @@
> +SUMMARY = "Common Information Model (CIM) Schema"
> +DESCRIPTION = "Common Information Model (CIM) is a model for describing
> overall\
> +management information in a network or enterprise environment. CIM\
> +consists of a specification an
Re: [yocto] dynamic library problem
On 12/06/2014 10:07, Ruud den Bekker wrote:
>
> Hi Alex,
>
>
>
> Recently you posted a fix for a dynamic library loading problem
>
> for the RaspberryPi and a graphic library.
>
>
>
> I'm now facing a dynamic library not found problem when using
>
> the BeagleBone board RFS in yocto. However, when I use the qemuarm
>
> RFS, everything is running fine.
>
>
>
> How can I determine the LDFLAGS that are being used for both builds?
>
>
>
>
>
Hi Ruud,
(Possibly helpful to others so cc:'d to the list)
If you're referring to the gstreamer1.0-omx work then yes, that was a
little tricky to track down.
It wasn't a "usual" library loading problem though as it was related to
some strange things that the library authors were doing to implement the
equivalent of a static constructor when the library was loaded. There
wasn't an explicit dependency on the library as the raspivid executable
didn't use any exported functions from that library, and bitbake was
passing an option that meant "unneeded" library dependencies were
stripped out. Thus the library wasn't loaded and didn't do the things it
needed to do.
Getting back to the point, it depends on the problem you are seeing, but
assuming that you are getting an error because of a missing library I
guess the first thing to do (which perhaps you already did?) is to look
for the missing library and do,
cd /
find -name libfoo.so
To see if it is actually in the board image.
If it is there then the next step is either to make sure it is being
picked up with something like
export LD_LIBRARY_PATH=/path/to/libfoo
./run_my_exe
It is also useful to install strace for this type of problem and look at
what libraries are being found and loaded
strace run_my_exe
To actually see what bitbake is doing on the server-side I would do
something like
bitbake -f -c devshell my_recipe
cd ../temp
nano log.do_configure
or
cd ../temp
grep LD_FLAGS
I've also found it to be useful to look at the config.log in ${S}
Hope this helps,
Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] add recipe cim-schema, cim-schema-docs and license file DMTF.
On 12 June 2014 09:56, Martin Jansa wrote: > Why is this recipe needed in oe-core layer? Wouldn't meta-networking be > more suitable? > > The patch also belongs to oe-core ML not yocto. Agreed, unless there's a strong reason then this should go to meta-networking (so send to the openembedded-devel list). Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] pseudo source gone missing?
Good Morning,
pseudo_1.5.1.bb refers to a URL like this
http://www.yoctoproject.org/downloads/${BPN}/${BPN}-${PV}.tar.bz2
but that is not were the sourcecode is located anymore. It looks
like an infrastructure problem? Should I report a bug somewhere
or can this be easily fixed?
holger
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [Repo Issue] x264: Unable to find revision
On Tuesday 03 June 2014 06:25:41 Kweh, Hock Leong wrote: > Hi, understand the patch below is to fix the x264 yocto build issue but it > is for "Daisy" branch. How about the "Dylan" branch? Can we use the same > commit id on the SRCREV? Here is the correct fix for dylan (where the recipe was in meta-oe, rather than OE-Core): http://patchwork.openembedded.org/patch/73547/ (My apologies for not replying sooner to this.) Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto-1.4 Build error.
Burton, Ross writes: > > On 15 July 2013 13:38, Amit Kumar wrote: > > Failed to fetch test data from the network. Please ensure your network > > is configured correctly. > > Assuming that you did have network connectivity, then the problem > normally is that you need to have a proxy configured in the terminal. > Exporting http_proxy=http://my-proxy/ (obviously fix that) in the > terminal should sort it. > > Ross > Hi Ross, I tried to do so by exproting the proxy setting into terminal but nothing much happen as still i am seeing the error. Thanks and regards, ATUL KUMAR SINGH -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to leave original git remote in unpacked repository?
Hi Alex, On Friday 30 May 2014 12:39:13 Alex J Lennon wrote: > When I drop into a devshell for an unpacked SRV_REV from a particular > git SRC_URI I have the git remote origin set to a local archive in the > ~/downloads tree. > > Is there a build variable, say, I can set to leave the original git > remote set as well so that I can more easily push back changes I make? > > (Or is that a bad idea for some reason?) There isn't a way to do this, and to be honest with the discussions we've had recently about developer workflow, I'm not sure we want to encourage doing development within the workdir for a recipe because it's managed by the build system, and if you're not careful (e.g. with -c clean, rm_work or just changing SRC_URI) the sources can vanish taking your changes with it. Our alternative at the moment is to use externalsrc [1]. This is a little more work though and at the OEDAM meeting [2] there was some discussion about how we could make this easier in future. Cheers, Paul [1] http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source [2] http://openembedded.org/wiki/OEDAM#Minutes -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to leave original git remote in unpacked repository?
On 12/06/2014 11:58, Paul Eggleton wrote:
> Hi Alex,
>
> On Friday 30 May 2014 12:39:13 Alex J Lennon wrote:
>> When I drop into a devshell for an unpacked SRV_REV from a particular
>> git SRC_URI I have the git remote origin set to a local archive in the
>> ~/downloads tree.
>>
>> Is there a build variable, say, I can set to leave the original git
>> remote set as well so that I can more easily push back changes I make?
>>
>> (Or is that a bad idea for some reason?)
> There isn't a way to do this, and to be honest with the discussions we've had
> recently about developer workflow, I'm not sure we want to encourage doing
> development within the workdir for a recipe because it's managed by the build
> system, and if you're not careful (e.g. with -c clean, rm_work or just
> changing SRC_URI) the sources can vanish taking your changes with it. Our
> alternative at the moment is to use externalsrc [1]. This is a little more
> work though and at the OEDAM meeting [2] there was some discussion about how
> we could make this easier in future.
>
OK thanks Paul. I understand what you mean, having wiped various changes
out in the past with inadvertent -c clean 'ing
That said I do find it quite productive to work in-tree with a
development git fork, ${AUTOREV} in the recipe and frequent work in
progress pushes to the remote repo just in case.
I'll take a look at what's involved in externalsrc as you recommend.
Thanks again,
Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Conditional patches on kernel depending on board, how to maintain?
I have a SoM which will be used on several boards, this SoM has a base kernel for it, with its board-*.c file. In each board I may have different peripherals, so I have to patch the same board-*.c file depending on my target board, and that patches may be conflicting one each other. For example, I could have a RF on first SPI bus on one board, and on another board a SD card on same first SPI bus. So basically I will have a different kernel(uImage) and rootfs (with kernel modules) for each board. I think to create a layer for each target board, with the linux-SoM.bbappend including the patches for that board..., so I enable the layer depending on target board I'm creating, but is too much file editions, or have a build directory for each target board, enabling the right layer on each local.conf, but this means mantaining build directories, or at last local.conf, which doesn't seem a good idea for me... Would be possible to do this relying only new layers and its configurations? Thanks in advance Cheers! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Conditional patches on kernel depending on board, how to maintain?
Can you compile the different device drivers as modules and load them at runtime? Can you compile the different device drivers statically and probe them based on a devicetree file? --wpd On Thu, Jun 12, 2014 at 7:54 AM, Daniel Hilst Selli wrote: > I have a SoM which will be used on several boards, this SoM has a base > kernel for it, with its board-*.c file. In each board I may have different > peripherals, so I have to patch the same board-*.c file depending on my > target board, and that patches may be conflicting one each other. For > example, I could have a RF on first SPI bus on one board, and on another > board a SD card on same first SPI bus. > > So basically I will have a different kernel(uImage) and rootfs (with kernel > modules) for each board. > > I think to create a layer for each target board, with the linux-SoM.bbappend > including the patches for that board..., so I enable the layer depending on > target board I'm creating, but is too much file editions, or have a build > directory for each target board, enabling the right layer on each > local.conf, but this means mantaining build directories, or at last > local.conf, which doesn't seem a good idea for me... > > Would be possible to do this relying only new layers and its configurations? > > Thanks in advance > Cheers! > -- > ___ > 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] Conditional patches on kernel depending on board, how to maintain?
On 06/12/2014 09:27 AM, Patrick Doyle wrote: Can you compile the different device drivers as modules and load them at runtime? Can you compile the different device drivers statically and probe them based on a devicetree file? Yes I do compile the device drivers as modules, but yet I have to register the *_board_info structs on board-*.c file, here is an example: http://pastebin.com/GMSDQERB Thanks in advance, Cheers! --wpd On Thu, Jun 12, 2014 at 7:54 AM, Daniel Hilst Selli wrote: I have a SoM which will be used on several boards, this SoM has a base kernel for it, with its board-*.c file. In each board I may have different peripherals, so I have to patch the same board-*.c file depending on my target board, and that patches may be conflicting one each other. For example, I could have a RF on first SPI bus on one board, and on another board a SD card on same first SPI bus. So basically I will have a different kernel(uImage) and rootfs (with kernel modules) for each board. I think to create a layer for each target board, with the linux-SoM.bbappend including the patches for that board..., so I enable the layer depending on target board I'm creating, but is too much file editions, or have a build directory for each target board, enabling the right layer on each local.conf, but this means mantaining build directories, or at last local.conf, which doesn't seem a good idea for me... Would be possible to do this relying only new layers and its configurations? Thanks in advance Cheers! -- ___ 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] Conditional patches on kernel depending on board, how to maintain?
On Thu, Jun 12, 2014 at 1:54 PM, Daniel Hilst Selli wrote: > I have a SoM which will be used on several boards, this SoM has a base > kernel for it, with its board-*.c file. In each board I may have different > peripherals, so I have to patch the same board-*.c file depending on my > target board, and that patches may be conflicting one each other. For > example, I could have a RF on first SPI bus on one board, and on another > board a SD card on same first SPI bus. > > So basically I will have a different kernel(uImage) and rootfs (with kernel > modules) for each board. > > I think to create a layer for each target board, with the linux-SoM.bbappend > including the patches for that board..., so I enable the layer depending on > target board I'm creating, but is too much file editions, or have a build > directory for each target board, enabling the right layer on each > local.conf, but this means mantaining build directories, or at last > local.conf, which doesn't seem a good idea for me... > > Would be possible to do this relying only new layers and its configurations? > you can do: SRC_URI_append_som1 = " file://som1.patch" assuming som1 is a valid machine name (e.g. you have conf/machines/som1.conf) you can do all builds with 1 layer, and 1 recipe for the kernel, with many such lines. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Linux Yocto style kernel errors with no config fragments
Hi, I was taking a quick look at converting the meta-raspberrypi kernel recipes to be linux-yocto style, to provide config frag support. I'm working with poky master, referencing linux-yocto-custom.bb in meta-skeleton This seems to be working as far as it goes, but I get an error when there are no configuration fragments supplied on the SRC_URI. | DEBUG: Executing shell function do_kernel_configme | [INFO] doing kernel configme | [INFO] Configuring target/machine combo: "standard/raspberrypi" | [INFO] collecting configs in ./.meta/meta-series | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or directory | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or directory | mv: cannot stat `[.]/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.21+gitcb53ea88f75180cc1ba74f7f197c8e3fd4f47cfe-r0/linux-raspberrypi-standard-build/.tmp.config*': No such file or directory | creation of pre-processed config data failed | config of "standard/raspberrypi" failed When I add an empty file://dummy.cfg file to the SRC_URI then I can build successfully. When I add a dummy option CONFIG_DUMMY=y into that fragment file do_kernel_configcheck correctly flags up that this is an unknown option for the kernel so it seems to be pulled in ok. Can anybody advise? Thanks, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo source gone missing?
Hi Holger,
On Wednesday 11 June 2014 06:19:49 Holger Freyther wrote:
> pseudo_1.5.1.bb refers to a URL like this
> http://www.yoctoproject.org/downloads/${BPN}/${BPN}-${PV}.tar.bz2
> but that is not were the sourcecode is located anymore. It looks
> like an infrastructure problem? Should I report a bug somewhere
> or can this be easily fixed?
I know you've already seen this but just to round this off, the issue is now
fixed:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6426
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Linux Yocto style kernel errors with no config fragments
On 14-06-12 09:46 AM, Alex J Lennon wrote: Hi, I was taking a quick look at converting the meta-raspberrypi kernel recipes to be linux-yocto style, to provide config frag support. I'm working with poky master, referencing linux-yocto-custom.bb in meta-skeleton This seems to be working as far as it goes, but I get an error when there are no configuration fragments supplied on the SRC_URI. | DEBUG: Executing shell function do_kernel_configme | [INFO] doing kernel configme | [INFO] Configuring target/machine combo: "standard/raspberrypi" | [INFO] collecting configs in ./.meta/meta-series | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or directory | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or directory | mv: cannot stat `[.]/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.21+gitcb53ea88f75180cc1ba74f7f197c8e3fd4f47cfe-r0/linux-raspberrypi-standard-build/.tmp.config*': No such file or directory | creation of pre-processed config data failed | config of "standard/raspberrypi" failed When I add an empty file://dummy.cfg file to the SRC_URI then I can build successfully. When I add a dummy option CONFIG_DUMMY=y into that fragment file do_kernel_configcheck correctly flags up that this is an unknown option for the kernel so it seems to be pulled in ok. Can anybody advise? I have a fix for a similar issue in a patch queue that I'm going to finish work on short (as part of 1.7 development work) .. the error message that is generated in that scenario is certainly not much help to anyone. To see if this is the same issue, I'll ask a quick clarification question. From what you describe .. when you see the message, do you also have a defconfig on the SRC_URI ? Bruce Thanks, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Linux Yocto style kernel errors with no config fragments
On 12/06/2014 14:53, Bruce Ashfield wrote: > On 14-06-12 09:46 AM, Alex J Lennon wrote: >> Hi, >> >> I was taking a quick look at converting the meta-raspberrypi kernel >> recipes to be linux-yocto style, to provide config frag support. >> >> I'm working with poky master, referencing linux-yocto-custom.bb in >> meta-skeleton >> >> This seems to be working as far as it goes, but I get an error when >> there are no configuration fragments supplied on the SRC_URI. >> >> | DEBUG: Executing shell function do_kernel_configme >> | [INFO] doing kernel configme >> | [INFO] Configuring target/machine combo: "standard/raspberrypi" >> | [INFO] collecting configs in ./.meta/meta-series >> | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or >> directory >> | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or >> directory >> | mv: cannot stat >> `[.]/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.21+gitcb53ea88f75180cc1ba74f7f197c8e3fd4f47cfe-r0/linux-raspberrypi-standard-build/.tmp.config*': >> >> No such file or directory >> | creation of pre-processed config data failed >> | config of "standard/raspberrypi" failed >> >> When I add an empty file://dummy.cfg file to the SRC_URI then I can >> build successfully. >> >> When I add a dummy option CONFIG_DUMMY=y into that fragment file >> do_kernel_configcheck correctly flags up that this is an unknown option >> for the kernel so it seems to be pulled in ok. >> >> Can anybody advise? > > I have a fix for a similar issue in a patch queue that I'm going to > finish work on short (as part of 1.7 development work) .. the error > message that is generated in that scenario is certainly not much > help to anyone. > > To see if this is the same issue, I'll ask a quick clarification > question. > > From what you describe .. when you see the message, do you also > have a defconfig on the SRC_URI ? Hi Bruce, Currently I'm using - SRC_URI = "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.12.y \ file://sl030raspberrypii2ckernel.patch \ file://dummy.cfg \ " The original RPi recipe seems to be trying to use KERNEL_DEFCONFIG to use an existing config within the tree so I had left that alone thus far, but I'm not sure it is being pulled in so am looking at this now too, # NOTE: For now we pull in the default config from the RPi kernel GIT tree. KERNEL_DEFCONFIG = "bcmrpi_defconfig" Thanks, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Linux Yocto style kernel errors with no config fragments
On 12/06/2014 14:59, Alex J Lennon wrote: > On 12/06/2014 14:53, Bruce Ashfield wrote: >> On 14-06-12 09:46 AM, Alex J Lennon wrote: >>> Hi, >>> >>> I was taking a quick look at converting the meta-raspberrypi kernel >>> recipes to be linux-yocto style, to provide config frag support. >>> >>> I'm working with poky master, referencing linux-yocto-custom.bb in >>> meta-skeleton >>> >>> This seems to be working as far as it goes, but I get an error when >>> there are no configuration fragments supplied on the SRC_URI. >>> >>> | DEBUG: Executing shell function do_kernel_configme >>> | [INFO] doing kernel configme >>> | [INFO] Configuring target/machine combo: "standard/raspberrypi" >>> | [INFO] collecting configs in ./.meta/meta-series >>> | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or >>> directory >>> | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or >>> directory >>> | mv: cannot stat >>> `[.]/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.21+gitcb53ea88f75180cc1ba74f7f197c8e3fd4f47cfe-r0/linux-raspberrypi-standard-build/.tmp.config*': >>> >>> No such file or directory >>> | creation of pre-processed config data failed >>> | config of "standard/raspberrypi" failed >>> >>> When I add an empty file://dummy.cfg file to the SRC_URI then I can >>> build successfully. >>> >>> When I add a dummy option CONFIG_DUMMY=y into that fragment file >>> do_kernel_configcheck correctly flags up that this is an unknown option >>> for the kernel so it seems to be pulled in ok. >>> >>> Can anybody advise? >> I have a fix for a similar issue in a patch queue that I'm going to >> finish work on short (as part of 1.7 development work) .. the error >> message that is generated in that scenario is certainly not much >> help to anyone. >> >> To see if this is the same issue, I'll ask a quick clarification >> question. >> >> From what you describe .. when you see the message, do you also >> have a defconfig on the SRC_URI ? > Hi Bruce, > > Currently I'm using - > > SRC_URI = > "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.12.y \ >file://sl030raspberrypii2ckernel.patch \ >file://dummy.cfg \ > " > > The original RPi recipe seems to be trying to use KERNEL_DEFCONFIG to use > an existing config within the tree so I had left that alone thus far, > but I'm not sure it > is being pulled in so am looking at this now too, > > # NOTE: For now we pull in the default config from the RPi kernel GIT tree. > KERNEL_DEFCONFIG = "bcmrpi_defconfig" > I think I see the problem now. A defconfig must be provided on SRC_URI (or a fragment) or we see the failure. I'll add in a SRC_URI defconfig instead of it reusing the in-tree config. Cheers, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Linux Yocto style kernel errors with no config fragments
On 14-06-12 09:59 AM, Alex J Lennon wrote: On 12/06/2014 14:53, Bruce Ashfield wrote: On 14-06-12 09:46 AM, Alex J Lennon wrote: Hi, I was taking a quick look at converting the meta-raspberrypi kernel recipes to be linux-yocto style, to provide config frag support. I'm working with poky master, referencing linux-yocto-custom.bb in meta-skeleton This seems to be working as far as it goes, but I get an error when there are no configuration fragments supplied on the SRC_URI. | DEBUG: Executing shell function do_kernel_configme | [INFO] doing kernel configme | [INFO] Configuring target/machine combo: "standard/raspberrypi" | [INFO] collecting configs in ./.meta/meta-series | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or directory | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or directory | mv: cannot stat `[.]/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.21+gitcb53ea88f75180cc1ba74f7f197c8e3fd4f47cfe-r0/linux-raspberrypi-standard-build/.tmp.config*': No such file or directory | creation of pre-processed config data failed | config of "standard/raspberrypi" failed When I add an empty file://dummy.cfg file to the SRC_URI then I can build successfully. When I add a dummy option CONFIG_DUMMY=y into that fragment file do_kernel_configcheck correctly flags up that this is an unknown option for the kernel so it seems to be pulled in ok. Can anybody advise? I have a fix for a similar issue in a patch queue that I'm going to finish work on short (as part of 1.7 development work) .. the error message that is generated in that scenario is certainly not much help to anyone. To see if this is the same issue, I'll ask a quick clarification question. From what you describe .. when you see the message, do you also have a defconfig on the SRC_URI ? Hi Bruce, Currently I'm using - SRC_URI = "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.12.y \ file://sl030raspberrypii2ckernel.patch \ file://dummy.cfg \ " The original RPi recipe seems to be trying to use KERNEL_DEFCONFIG to use an existing config within the tree so I had left that alone thus far, but I'm not sure it is being pulled in so am looking at this now too, Aha, so yes, that is likely the same thing that I was seeing before. If you have no configuration at all, the tools don't have anything to seed into the config_frag.txt file (and in earlier versions they didn't touch the file to ensure it is present, or use the missing file as a trigger for a more useful message). Bruce # NOTE: For now we pull in the default config from the RPi kernel GIT tree. KERNEL_DEFCONFIG = "bcmrpi_defconfig" Thanks, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Linux Yocto style kernel errors with no config fragments
On 14-06-12 10:52 AM, Alex J Lennon wrote: On 12/06/2014 14:59, Alex J Lennon wrote: On 12/06/2014 14:53, Bruce Ashfield wrote: On 14-06-12 09:46 AM, Alex J Lennon wrote: Hi, I was taking a quick look at converting the meta-raspberrypi kernel recipes to be linux-yocto style, to provide config frag support. I'm working with poky master, referencing linux-yocto-custom.bb in meta-skeleton This seems to be working as far as it goes, but I get an error when there are no configuration fragments supplied on the SRC_URI. | DEBUG: Executing shell function do_kernel_configme | [INFO] doing kernel configme | [INFO] Configuring target/machine combo: "standard/raspberrypi" | [INFO] collecting configs in ./.meta/meta-series | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or directory | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such file or directory | mv: cannot stat `[.]/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.21+gitcb53ea88f75180cc1ba74f7f197c8e3fd4f47cfe-r0/linux-raspberrypi-standard-build/.tmp.config*': No such file or directory | creation of pre-processed config data failed | config of "standard/raspberrypi" failed When I add an empty file://dummy.cfg file to the SRC_URI then I can build successfully. When I add a dummy option CONFIG_DUMMY=y into that fragment file do_kernel_configcheck correctly flags up that this is an unknown option for the kernel so it seems to be pulled in ok. Can anybody advise? I have a fix for a similar issue in a patch queue that I'm going to finish work on short (as part of 1.7 development work) .. the error message that is generated in that scenario is certainly not much help to anyone. To see if this is the same issue, I'll ask a quick clarification question. From what you describe .. when you see the message, do you also have a defconfig on the SRC_URI ? Hi Bruce, Currently I'm using - SRC_URI = "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.12.y \ file://sl030raspberrypii2ckernel.patch \ file://dummy.cfg \ " The original RPi recipe seems to be trying to use KERNEL_DEFCONFIG to use an existing config within the tree so I had left that alone thus far, but I'm not sure it is being pulled in so am looking at this now too, # NOTE: For now we pull in the default config from the RPi kernel GIT tree. KERNEL_DEFCONFIG = "bcmrpi_defconfig" I think I see the problem now. A defconfig must be provided on SRC_URI (or a fragment) or we see the failure. I'll add in a SRC_URI defconfig instead of it reusing the in-tree config. We crossed in the air. I just sent something similar, and I was going to go dig into the details .. but you are already there. Let me know if you have further issues, and I can also say that the error message will be more informative in the future :) Bruce Cheers, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Linux Yocto style kernel errors with no config fragments
On 12/06/2014 15:54, Bruce Ashfield wrote: > On 14-06-12 10:52 AM, Alex J Lennon wrote: >> >> On 12/06/2014 14:59, Alex J Lennon wrote: >>> On 12/06/2014 14:53, Bruce Ashfield wrote: On 14-06-12 09:46 AM, Alex J Lennon wrote: > Hi, > > I was taking a quick look at converting the meta-raspberrypi kernel > recipes to be linux-yocto style, to provide config frag support. > > I'm working with poky master, referencing linux-yocto-custom.bb in > meta-skeleton > > This seems to be working as far as it goes, but I get an error when > there are no configuration fragments supplied on the SRC_URI. > > | DEBUG: Executing shell function do_kernel_configme > | [INFO] doing kernel configme > | [INFO] Configuring target/machine combo: "standard/raspberrypi" > | [INFO] collecting configs in ./.meta/meta-series > | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such > file or > directory > | cat: .meta/cfg/standard/raspberrypi/config_frag.txt: No such > file or > directory > | mv: cannot stat > `[.]/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.21+gitcb53ea88f75180cc1ba74f7f197c8e3fd4f47cfe-r0/linux-raspberrypi-standard-build/.tmp.config*': > > > No such file or directory > | creation of pre-processed config data failed > | config of "standard/raspberrypi" failed > > When I add an empty file://dummy.cfg file to the SRC_URI then I can > build successfully. > > When I add a dummy option CONFIG_DUMMY=y into that fragment file > do_kernel_configcheck correctly flags up that this is an unknown > option > for the kernel so it seems to be pulled in ok. > > Can anybody advise? I have a fix for a similar issue in a patch queue that I'm going to finish work on short (as part of 1.7 development work) .. the error message that is generated in that scenario is certainly not much help to anyone. To see if this is the same issue, I'll ask a quick clarification question. From what you describe .. when you see the message, do you also have a defconfig on the SRC_URI ? >>> Hi Bruce, >>> >>> Currently I'm using - >>> >>> SRC_URI = >>> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.12.y >>> \ >>> file://sl030raspberrypii2ckernel.patch \ >>> file://dummy.cfg \ >>>" >>> >>> The original RPi recipe seems to be trying to use KERNEL_DEFCONFIG >>> to use >>> an existing config within the tree so I had left that alone thus far, >>> but I'm not sure it >>> is being pulled in so am looking at this now too, >>> >>> # NOTE: For now we pull in the default config from the RPi kernel >>> GIT tree. >>> KERNEL_DEFCONFIG = "bcmrpi_defconfig" >>> >> >> I think I see the problem now. A defconfig must be provided on SRC_URI >> (or a fragment) or we see the failure. >> >> I'll add in a SRC_URI defconfig instead of it reusing the in-tree >> config. > > We crossed in the air. I just sent something similar, and I was going > to go dig into the details .. but you are already there. > > Let me know if you have further issues, and I can also say that the error > message will be more informative in the future :) Thanks for the pointer :) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] populate_sdk_base: add auto-completion in setup
Hello Yocto-Community, It's really easy to add auto completion in the SDK setup scripts with BASH's "read -e -p". I attached a short patch that does this. Makes life very comfortable ;-). I already asked Paul Eggleton on IRC about the change, and our only concern is that it could break the script in other shells than BASH. However, since the script already starts with #!/bin/bash hopefully isn't a real problem. Any thoughts? I would love to see this in an upcoming release. Regards, Dennis 0001-populate_sdk_base-add-auto-completion-in-setup.patch Description: 0001-populate_sdk_base-add-auto-completion-in-setup.patch -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Conditional patches on kernel depending on board, how to maintain?
On 14-06-12 07:54 AM, Daniel Hilst Selli wrote: I have a SoM which will be used on several boards, this SoM has a base kernel for it, with its board-*.c file. In each board I may have different peripherals, so I have to patch the same board-*.c file depending on my target board, and that patches may be conflicting one each other. For example, I could have a RF on first SPI bus on one board, and on another board a SD card on same first SPI bus. So basically I will have a different kernel(uImage) and rootfs (with kernel modules) for each board. I think to create a layer for each target board, with the linux-SoM.bbappend including the patches for that board..., so I enable the layer depending on target board I'm creating, but is too much file editions, or have a build directory for each target board, enabling the right layer on each local.conf, but this means mantaining build directories, or at last local.conf, which doesn't seem a good idea for me... Would be possible to do this relying only new layers and its configurations? As was mentioned in the other replies, you can always have a single bbappend with board specific SRC_URI updates to add the patches you need onto the base board support. It's unfortunate that the patches conflict, since stacking hem in board specific SRC_URIs can lead to patch failures in some configs and not others .. if you change the baseline. Typically in this situation, I either #ifdef the patches and use a different configuration to conditionally build the consistent set of changes, or maintain the changes in a git repository with board specific patches on each branch. Again, that git approach avoids patch failures during build. Cheers, Bruce Thanks in advance Cheers! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] role of sstate-cache
I am a newbie to Yocto project... I wanted to know.. what is the role of the "sstate-cache" directory? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] role of sstate-cache
On Thu, Jun 12, 2014 at 6:26 PM, Arun Kumar wrote: > I am a newbie to Yocto project... > I wanted to know.. what is the role of the "sstate-cache" directory? are you asking for clarifications after reading this http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#shared-state-cache, or you haven't seen it yet? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to determine which tasks bitbake just ran?
I'm sure I'll get tired of looking at this eventually, and learn to love the normal ncurses style interface of bitbake. But things are still new enough to me that I want to know what's going on. As you know, when we bitbake a recipe, we see lots of messages about individual tasks that are run as they are being run (do_fetch, do_configure, etc…), and then a final summary message that reads something like: NOTE: Tasks Summary: Attempted 690 tasks of which 677 didn't need to be rerun and all succeeded. I'm curious: 1) What were the 13 tasks that ran? 2) Why are there 690 tasks for my simple recipe anyway? Is there some way to preserve the list of 13 tasks that were run? Are they listed in a logfile through which I could grep "running task " or "task skipped"? Also, as I've been playing with my simple recipe, I find myself frequently wanting to start from a totally clean slate, so I $ bitbake myrecipe -c cleanall But I notice that tmp/work/arm/myrecipe still exists, so, in my paranoia, I like to rm -rf tmp/work/arm/myrecipe just to make sure that my clean slate really is clean. I don't see a "cleanevenmorethanall" task listed with -c listtasks. 1) Is there any harm done in rm -rf tmp/work/arm/myrecipe? 2) Is there an eqivalent to a cleanevenmorethanall task that would do that for me? --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to determine which tasks bitbake just ran?
On 12 June 2014 19:53, Patrick Doyle wrote: > As you know, when we bitbake a recipe, we see lots of messages about > individual tasks that are run as they are being run (do_fetch, > do_configure, etc…), and then a final summary message that reads > something like: > > NOTE: Tasks Summary: Attempted 690 tasks of which 677 didn't need to > be rerun and all succeeded. > > I'm curious: > 1) What were the 13 tasks that ran? > 2) Why are there 690 tasks for my simple recipe anyway? You want to see the cooker log. If you want to see that as it happens, then for a one-off you can convince bitbake that it's not running on a vt (bitbake foo | cat -). After the event, the cooker logs are in tmp/logs/cooker/[machine]/[timestamp].log. For convenience, Chris Larson's excellent 'bb' command has a 'log' mode that if given no arguments will display the latest cooker log. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to determine which tasks bitbake just ran?
On Thu, Jun 12, 2014 at 12:00 PM, Burton, Ross wrote: > On 12 June 2014 19:53, Patrick Doyle wrote: > > As you know, when we bitbake a recipe, we see lots of messages about > > individual tasks that are run as they are being run (do_fetch, > > do_configure, etc…), and then a final summary message that reads > > something like: > > > > NOTE: Tasks Summary: Attempted 690 tasks of which 677 didn't need to > > be rerun and all succeeded. > > > > I'm curious: > > 1) What were the 13 tasks that ran? > > 2) Why are there 690 tasks for my simple recipe anyway? > > You want to see the cooker log. > > If you want to see that as it happens, then for a one-off you can > convince bitbake that it's not running on a vt (bitbake foo | cat -). > > After the event, the cooker logs are in > tmp/logs/cooker/[machine]/[timestamp].log. For convenience, Chris > Larson's excellent 'bb' command has a 'log' mode that if given no > arguments will display the latest cooker log. The new Toaster is pretty great at examining what your build did, if you ran your build in toaster context, afaik. I haven't spent much time playing with it, but it does seem like it's intended to answer just these sort of questions. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to determine which tasks bitbake just ran?
Thanks. bitbake foo | cat is most likely to be what I was looking for. I found the cooker log shortly after I asked my question. I'll go look through bitbake and see what it would take to create a symbolic link to the most recent logfile, as is done with the logfiles for the individual tasks. I'll also go see what I can learn about Toaster. --wpd On Thu, Jun 12, 2014 at 3:06 PM, Christopher Larson wrote: > > On Thu, Jun 12, 2014 at 12:00 PM, Burton, Ross > wrote: >> >> On 12 June 2014 19:53, Patrick Doyle wrote: >> > As you know, when we bitbake a recipe, we see lots of messages about >> > individual tasks that are run as they are being run (do_fetch, >> > do_configure, etc…), and then a final summary message that reads >> > something like: >> > >> > NOTE: Tasks Summary: Attempted 690 tasks of which 677 didn't need to >> > be rerun and all succeeded. >> > >> > I'm curious: >> > 1) What were the 13 tasks that ran? >> > 2) Why are there 690 tasks for my simple recipe anyway? >> >> You want to see the cooker log. >> >> If you want to see that as it happens, then for a one-off you can >> convince bitbake that it's not running on a vt (bitbake foo | cat -). >> >> After the event, the cooker logs are in >> tmp/logs/cooker/[machine]/[timestamp].log. For convenience, Chris >> Larson's excellent 'bb' command has a 'log' mode that if given no >> arguments will display the latest cooker log. > > > The new Toaster is pretty great at examining what your build did, if you ran > your build in toaster context, afaik. I haven't spent much time playing with > it, but it does seem like it's intended to answer just these sort of > questions. > -- > Christopher Larson > clarson at kergoth dot com > Founder - BitBake, OpenEmbedded, OpenZaurus > Maintainer - Tslib > Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] how to customize kernel config?
On 12/06/2014 07:48, Jonatan Magnusson wrote:
> Hi
>
> I’m trying to use the meta-raspberrypi BSP with Yocto (1.6, Daisy).
>
> It works great, except I have no idea how to use a custom kernel config!
>
> I have a custom kernel recipe that bbappends to the meta-raspberrypi kernel
> recipe.
>
> I’ve tried using defconfig as well as configuration fragments, but neither
> work.
>
> I’ve also tried using the kernel_configure_variable function, and that almost
> works, except if I try to disable an option that is enabled earlier in the
> the config file, the option is still enabled since kernel_configure_variable
> only appends to the config file.
>
> Example:
>
> do_configure_append() {
> kernel_configure_variable SPI_SPIDEV n
> }
>
> So I wonder: how is this supposed to work?
>
> In my case I need to enable CONFIG_IEEE802154_MRF24J40 and it’s dependencies
> and disable CONFIG_SPI_SPIDEV and a few more.
>
> I’ve found no help on IRC and all Google comes up with is this old
> discussion, which does not lead to a solution:
>
> https://lists.yoctoproject.org/pipermail/yocto/2013-November/017113.html
>
> I would be very happy to get any hints on how this is supposed to work!
Jonatan,
I have a patch set here which I believe will enable configuration
fragment support (yocto-ization) for the RPi as detailed in the Yocto
Kernel Development Manual.
It needs more testing before I would be comfortable releasing it, and I
am short of time right now. The kernel builds and my testing shows that
the config and config. fragments seem to get picked up, but I haven't
tested on a board yet as I have run into trouble moving up from Yocto
daisy to master.
I wonder if you would be interested in taking a look at it with me?
If/when it worked/works you should be able to simply add a foo.cfg file
with your CONFIG_foo to SRC_URI in a .bbappend and that should get
pulled in as you need.
Cheers,
Alex
Cheer
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Daisy 1.6.1 Build Complete (artifacts available)
Guys, http://autobuilder.yoctoproject.org/pub/releases/yocto-1.6.1/ poky: a43dba8c2904f9c1ce0425c53c5a7f4718121e6b oecore: d28b21e01fbc4b780d14495894c4253d422cd9d9 I don't have Beth's scripts to generate the complete list. -- Sau! Saul Wold Yocto Component Wrangler @ Intel Yocto Project / Poky Build System -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Out Friday the 13th from 10:30AM on.
Scott Rifenbark Intel Corporation Yocto Project Documentation 503.712.2702 503.341.0418 (cell) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
