Re: [yocto] Can anything be done about do_rootfs speed?
On Tue, Aug 27, 2013 at 05:10:42PM -0700, Paul D. DeRocco wrote:
From: Gary Thomas
As far as I understand, the 'do_rootfs' step in building an
image is basically
equivalent to running ${PKG_MGR} install
all_required_packages, where PKG_MGR
is your package management method of choice - ipk or rpm.
This seems to me to
be a very single-threaded process.
If there's a way to command the package manager to install a package
without enforcing dependencies (Is that what opkg --nodeps does?), then
couldn't the package manager be invoked on one package at a time in n
threads, just like the other tasks are now run? I don't really have any
sense of how long it takes to install the packages, as opposed to building
the final tarball or hddimage and applying the permissions from the pseudo
database, which would certainly be single-threaded.
Perhaps you should think more about how you are using this.
If you don't need
to rebuild the whole image every time, maybe you can use the
package management
tools instead? For example, I routinely build images as well
but I also try to
use 'opkg' as much as possible to manage package updates,
etc. This is a huge
time saver, especially when making small or incremental
changes. I only rely
on the full image builds when I want to checkpoint the
state of the system.
I'd like to try that, but I'm not sure how. If I've tweaked one recipe,
how do I get it to build it and package it, and then stop? Do I use
bitbake -c package? And then do I use opkg -d to manually install it
directly onto my SD card? If my rootfs is a loop mounted hddimage in a
FAT16 file (as it is on my Atom project), do I loop mount it on my build
system and install into that?
Installing directly to the card would be nice because copying the whole
damn rootfs to the card takes an annoying amount of time, too.
Are you sure that you're not building some unnecessary IMAGE_FSTYPES?
Last time someone asked my why it takes so long I've added some debug
output to do_rootfs and found out that only half of the time was opkg
installing packages and the rest was various IMAGE_FSTYPES.
e.g. tar.bz2 takes very long without pbzip2 or lbzip2
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] shared-state
Hi everyone ! I tried to share the shared-state folder on a build server for several people working on the same project. But I meet some unexpected problems, like errors callings the native dpkg tool. So I'm back to the basic question :-) Is it possible to share this cache between developers or not ? Are they others solutions to improve team working ? Note: still using yocto 1.3 Cheers David ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake -c populate_sdk -v poky-image
Hi, Following is my image file to generate rootfs image with SDK having Qt support.. I am able to build SDK successfully but on building any Qt application with generated SDK getting following error message- /opt/poky/1.3.2/sysroots/EBboard-poky-linux-gnueabi//usr/include/qtopia/QtCore/qglobal.h:68:21: fatal error: algorithm: No such file or directory compilation terminated. make[2]: *** [obj_rel/AdjustedTime.o] Error 1 Please suggest.. Thanks and Regards Navani Kamal Srivastava On Tue, Jul 30, 2013 at 4:18 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Tuesday 30 July 2013 14:35:40 Navani Srivastava wrote: I think the problem is this: require recipes-core/meta/meta-toolchain.bb Yes, it worked.. Thanks You shouldn't be adding this to an image recipe, and definitely not poky- image.bbclass. then? Is it possible to create .bbappend kind of file for .bbclass which can append the information or I have to duplicate toolchain-script.bbclass in my layer? Sure, you can add the script append and the additional TOOLCHAIN_HOST_TASK items in an additional bbclass in your layer and then inherit that in your image recipe; just don't require meta-toolchain.bb because that has other side-effects. What version of the build system are you using? I am using poky danny (8.0.2) OK, in that case why are you using poky-image.bbclass? That was replaced by core-image.bbclass in the edison release if I recall correctly, which was quite a while ago. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre poky-image.bb Description: Binary data ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] package-core-buildessential: missing dependency
Hi all,
I'm trying to install package-core-buildessential in my target (using
smart in my target) but it complains about:
error: Can't install libc6-dev-2.17-r3@armv7a_vfp_neon: no package
provides eglibc-thread-db-dev
Digging around it, I found that package should provide (eglibc-package.inc):
FILES_eglibc-thread-db = ${base_libdir}/libthread_db.so.*
${base_libdir}/libthread_db-*.so
but i found that those file are packaged as part of libc6-dev itself.
Do you have any hints?
Thanks very much,
Francesco
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] OE recipes- linphone build error in poky-9.0.0 build environment
Hi Amit, On Wednesday 28 August 2013 09:05:28 Amit Kumar wrote: I wants to build the recipes name linphone(SIP-based IP phone) with poky-9.0.0 build environment. I found he linphone recipes under the angstrom-openembedded. In my poky build environment I have created the new layer, name linphone, and copy the .bb files. But when i am building it through an dependency error. Do anyone have done it before, please guide me how to fix this error. yocto@yocto-HP:~/YOCTO/poky-dylan-9.0.0/build$ bitbake linphone-image Loading cache: 100% |## ###| ETA: 00:00:00 Loaded 1126 entries from dependency cache. Build Configuration: BB_VERSION= 1.18.0 BUILD_SYS = i686-linux NATIVELSBSTRING = Ubuntu-12.04 TARGET_SYS= arm-poky-linux-gnueabi MACHINE = qemuarm DISTRO= poky DISTRO_VERSION= 1.4 TUNE_FEATURES = armv5 thumb dsp TARGET_FPU= soft meta meta-yocto meta-yocto-bsp meta-linphone = unknown:unknown NOTE: Resolving any missing task queue dependencies ERROR: Nothing PROVIDES 'libosip2' (but /home/yocto/YOCTO/poky-dylan-9.0.0/meta-linphone/recipes-linphone/linphone/ linphone_1.6.0.bb DEPENDS on or otherwise requires it) NOTE: Runtime target 'linphone' is unbuildable, removing... Missing or unbuildable dependency chain was: ['linphone', 'libosip2'] ERROR: Required build target 'linphone-image' has no buildable providers. Missing or unbuildable dependency chain was: ['linphone-image', 'linphone', 'libosip2'] Looks like you've copied the linphone recipe and not its dependencies. As far as I know this is an OE-Classic recipe so it won't be a straight copy - it will need to be migrated. See here for information on what you will need to do: http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Syntax for specifying multiple URI's in a PREMIRRORS statement?
Am 2013-08-27 17:19, schrieb Glenn Schmottlach: I'm trying to figure out the syntax for specifying more than one URI in a single PREMIRROR statement, e.g. PREMIRRORS_append = git://.*/.* file://toplevel/premirror ftp://ftp.acme.com/pre_mirror/foo [1] n So for all git fetches I want it to *first* look in a local premirror directory and if the file is not found there then try to fetch from an FTP server. How do you separate the two destination URIs to search? I tried a space ' ' and semi-colon but neither appear to work. Is the syntax documented somewhere. Can anyone provide a suggestion? Links: -- [1] ftp://ftp.acme.com/pre_mirror/foo ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Hi, interesting question IMHO. Istn't there also 'MIRRORS' which you can set as a fallback? The documentation says (in faq.xml): When the build system searches for source code, it first tries the local download directory. If that location fails, Poky tries PREMIRRORS the upstream source, and then MIRRORS in that order. BR, Lothar Rubusch ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can anything be done about do_rootfs speed?
From: Martin Jansa Are you sure that you're not building some unnecessary IMAGE_FSTYPES? No, I'm not sure. Last time someone asked my why it takes so long I've added some debug output to do_rootfs and found out that only half of the time was opkg installing packages and the rest was various IMAGE_FSTYPES. e.g. tar.bz2 takes very long without pbzip2 or lbzip2 Is there a standard way to use those in a build? Do I replace bzip2 with a link to one of those? Or does Yocto build its own bzip2? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can anything be done about do_rootfs speed?
2013/8/28 Paul D. DeRocco pdero...@ix.netcom.com: From: Martin Jansa Are you sure that you're not building some unnecessary IMAGE_FSTYPES? No, I'm not sure. Last time someone asked my why it takes so long I've added some debug output to do_rootfs and found out that only half of the time was opkg installing packages and the rest was various IMAGE_FSTYPES. e.g. tar.bz2 takes very long without pbzip2 or lbzip2 Is there a standard way to use those in a build? Do I replace bzip2 with a link to one of those? Or does Yocto build its own bzip2? Hi, look/grep for IMAGE_FSTYPE, if there is a += tar.bz2 or multiple identical += lines then you can be sure that do_rootfs is wasting time. A virtual package manager which only composes the package database in a multi-threaded way could be seen as a silver bullet here. Also pigz [1] and pbzip2 [2] could save some minutes / seconds depending on the image size. [1] http://zlib.net/pigz/ [2] http://compression.ca/pbzip2/ -- Regards Samuel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can anything be done about do_rootfs speed?
On 2013-08-27 18:10, Paul D. DeRocco wrote:
From: Gary Thomas
As far as I understand, the 'do_rootfs' step in building an
image is basically
equivalent to running ${PKG_MGR} install
all_required_packages, where PKG_MGR
is your package management method of choice - ipk or rpm.
This seems to me to
be a very single-threaded process.
If there's a way to command the package manager to install a package
without enforcing dependencies (Is that what opkg --nodeps does?), then
couldn't the package manager be invoked on one package at a time in n
threads, just like the other tasks are now run? I don't really have any
sense of how long it takes to install the packages, as opposed to building
the final tarball or hddimage and applying the permissions from the pseudo
database, which would certainly be single-threaded.
Perhaps you should think more about how you are using this.
If you don't need
to rebuild the whole image every time, maybe you can use the
package management
tools instead? For example, I routinely build images as well
but I also try to
use 'opkg' as much as possible to manage package updates,
etc. This is a huge
time saver, especially when making small or incremental
changes. I only rely
on the full image builds when I want to checkpoint the
state of the system.
I'd like to try that, but I'm not sure how. If I've tweaked one recipe,
how do I get it to build it and package it, and then stop? Do I use
bitbake -c package? And then do I use opkg -d to manually install it
directly onto my SD card? If my rootfs is a loop mounted hddimage in a
FAT16 file (as it is on my Atom project), do I loop mount it on my build
system and install into that?
Not quite - you build the packages (recipes) on your build host, but manage
them directly on your target hardware. Of course, this assumes that your
build host and target hardware are network connected.
You can [re]build any single package like this:
% bitbake recipe-name
The '-c' option is used to select a particular build phase, not what you
are looking for here.
In order to use the package management on your target device, you need
to export the package set. This is typically done using HTTP, so you'll
need some sort of web server. If you don't already have one running
on your build host (or wherever you want to host the packages), I'd suggest
using 'lighttpd' which is very simple to set up. Once you have it running,
simply export the package set. For example, I run lighttpd on my build host
and export the packages for a particular machine/build like this:
% ln -s ${BUILD}/tmp/deploy/ipk /var/www/lighttpd/BOARD-feeds
As you can see, I use 'ipk' packaging, which on the board is handled by the
'opkg' tool.
One key thing is on your build host you must remember to update/rebuild the
package database(s) whenever you make any changes, be it building new packages
or just rebuilding extant ones. This is done using a special recipe:
% bitbake package-index
I typically mix these like this:
% bitbake some-recipe bitbake package-index
Notice that you can't put them both on the same command, e.g.
% bitbake some-recipe package-index
as the 'package-index' recipe can only be built when all other recipes are
complete and that won't happen if you try them both at the same time.
In the case of 'ipk' packages, you'll need to set up the board to make use of
the exported package sets. There are a number of ways to do this, but in the
case of 'ipk' you can do it all in a single file. Here's an example on my
SabreLite (i.MX6 ARM system):
root@sabrelite:~# cat /etc/opkg/base-feeds.conf
src/gz poky_am-all http://192.168.1.125/sabrelite-feeds/all
src/gz poky_am-armv7a-vfp-neon
http://192.168.1.125/sabrelite-feeds/armv7a-vfp-neon
src/gz poky_am-sabrelite http://192.168.1.125/sabrelite-feeds/sabrelite
This file tells 'opkg' where to find the various packages which have been
broken down
into board specific, architecture specific and general packages. This is how
Poky/Yocto
is setting things up, so this file is just making those connections. In the
example
above, 192.168.1.125 is the IP address of my build host (which you can specify
using
any DNS or IP notation) and 'sabrelite-feeds' is the link to my board specific
packages,
set up as above.
To use this set up on the board, first you need to update the board's copy of
the
package databases. This is used to figure out what packages are available,
what they
contain/provide and what the package dependencies are.
root@sabrelite:~# opkg update
Once the databases are up to date, you can install/remove/... as needed.
root@sabrelite:~# opkg install some-new-package
I'm sure there are many details I've left out, so feel free to ask questions
as needed. I also explicitly left out any discussion of 'rpm' packaging as I
don't use that on my targets and really don't know the details. Hopefully
someone will document all of this in great detail some day. (in fact I filed a
bug to this end many
Re: [yocto] Can anything be done about do_rootfs speed?
On 28 August 2013 11:55, Gary Thomas g...@mlbassoc.com wrote: Not quite - you build the packages (recipes) on your build host, but manage them directly on your target hardware. Of course, this assumes that your build host and target hardware are network connected. I threw together a minimal Raspberry Pi system image for a hobbyist group I run and do exactly this. I wrote a recipe to create the required feed config, it may be a useful template for others: https://bitbucket.org/homebrewtech/meta-mmmpi/src/master/recipes-core/mmmpi-feed/mmmpi-feed.bb You probably need to change the distro name, list of architectures and the URLs, but the structure is fine. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake -c populate_sdk -v poky-image
On Wednesday 28 August 2013 13:23:04 Navani Srivastava wrote: Following is my image file to generate rootfs image with SDK having Qt support.. I am able to build SDK successfully but on building any Qt application with generated SDK getting following error message- /opt/poky/1.3.2/sysroots/EBboard-poky-linux-gnueabi//usr/include/qtopia/QtCo re/qglobal.h:68:21: fatal error: algorithm: No such file or directory compilation terminated. make[2]: *** [obj_rel/AdjustedTime.o] Error 1 Please suggest.. I can't tell from the little amount of the error output you've given but it sounds like either standard C++ headers are not installed, or they are but the compiler can't find them for some reason. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] confusion about DEPENDS vs RDEPENDS
Hi, I am a little bit confused about how to handle these two and what they are supposed to solve. I have so far never used RDEPENDS but only DEPENDS. But I am also having severe problems when building a rootfs image when one of my user space libraries are changed from eg. libfoo.so.1 to libfoo.so.3. Even though all my packages that have dependencies to it includes it in a DEPENDS. The error I get during rootfs build is: | Computing transaction...error: Can't install someapp-1.0-r0@cortexa9_vfp: no package provides libfoo.so.1 But there is no libfoo.so.1 in my sysroot, it has been replaced by libfoo.so.3. I know for sure that 'someapp' was rebuilt, but still I got the error message. What do seem to help is to force a fetch of 'someapp' and then rebuild which sort of indicates that some garbage was left behind. But having a package listed in DEPENDS will not force a new fetch if I am not mistaken. Have I been using the DEPENDS variable incorrectly? Would it make a difference if I used RDEPENDS instead? Thanks. Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake -c populate_sdk -v poky-image
I just removed qt stuff and tried with the SDK built with 'bitbake -c populate_sdk poky-image' . I just compiled a simple program which includes stdio.h, while compiling got error that stdio.h: No such file or directory .. It seems problem is with SDK generated with it. But I am not able to understand that if problem is somewhere in declaring the correct architecture then how rootfs and all other binaries which got generated by executing bitbake poky-image are working on my target. Even though SDK generated by bitbake meta-toolhain-qte is also working fine.. Need some more research.. On Wed, Aug 28, 2013 at 8:11 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Wednesday 28 August 2013 13:23:04 Navani Srivastava wrote: Following is my image file to generate rootfs image with SDK having Qt support.. I am able to build SDK successfully but on building any Qt application with generated SDK getting following error message- /opt/poky/1.3.2/sysroots/EBboard-poky-linux-gnueabi//usr/include/qtopia/QtCo re/qglobal.h:68:21: fatal error: algorithm: No such file or directory compilation terminated. make[2]: *** [obj_rel/AdjustedTime.o] Error 1 Please suggest.. I can't tell from the little amount of the error output you've given but it sounds like either standard C++ headers are not installed, or they are but the compiler can't find them for some reason. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] confusion about DEPENDS vs RDEPENDS
Hi Hans,
On Wednesday 28 August 2013 17:08:41 Hans Beckérus wrote:
Hi, I am a little bit confused about how to handle these two and what
they are supposed to solve. I have so far never used RDEPENDS but only
DEPENDS.
DEPENDS means a build-time dependency i.e. between recipes, RDEPENDS means a
runtime dependency i.e. between packages. It is worth noting though that an
explicitly stated RDEPENDS will cause bitbake to actually build the recipe
providing the package named in the RDEPENDS value, just at a different time. To
explain exactly what each of these do:
* DEPENDS = b in recipe a will translate to a's do_configure task depending
on recipe b's do_populate_sysroot task, so that anything recipe b puts into
the sysroot is available for when a configures itself.
* RDEPENDS_${PN} = b in recipe a will translate to a's do_build task
depending on recipe b's do_package_write task, so that the package file b is
available when the output for a has been completely built (of course assuming
that recipe b produces a package called b, which it will with the default
value of PACKAGES). More importantly it will also ensure that package a is
marked as depending on b in a manner understood by the package manager being
used e.g. rpm / opkg / dpkg.
But I am also having severe problems when building a rootfs image when
one of my user space libraries are changed from eg. libfoo.so.1 to
libfoo.so.3. Even though all my packages that have dependencies to it
includes it in a DEPENDS.
The error I get during rootfs build is:
| Computing transaction...error: Can't install
someapp-1.0-r0@cortexa9_vfp: no package provides libfoo.so.1
But there is no libfoo.so.1 in my sysroot, it has been replaced by
libfoo.so.3. I know for sure that 'someapp' was rebuilt, but still I got
the error message. What do seem to help is to force a fetch of 'someapp'
and then rebuild which sort of indicates that some garbage was left behind.
But having a package listed in DEPENDS will not force a new fetch if I am
not mistaken.
By default, if recipe foo changes and it is mentioned in the someapp
recipe's DEPENDS, then someapp's do_configure and all tasks that depend upon it
will be re-executed next time it is called for i.e. you explicitly build
someapp or build an image that contains it or some other recipe that depends
upon it. The fact that you are getting the behaviour described suggests that
this is either not happening, or more likely it is not having the desired
effect; e.g. if internally someapp's build system doesn't drop or invalidate
all of its build output when it is reconfigured then you will get this kind of
behaviour. Setting up B (the directory in which a recipe's source code is
built) separate to S (the directory in which the recipe's source code has been
unpacked to) can help with this since if they are separate, our build system
will know it can delete B before re-executing do_compile after do_configure and
you'll never have stale build output. Being able to set this up however is
highly dependent on the software being built by the individual recipe; some
lend themselves to this and others don't.
Have I been using the DEPENDS variable incorrectly? Would it make a
difference if I used RDEPENDS instead?
RDEPENDS would not be appropriate in this situation, since we're talking about
a build-time dependency.
Hope that helps.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-freescale] [meta-fsl-ppc] MPC8572 Machine with Dylan
I am looking to build for MPC8572 with Dylan and checked out the meta-fsl-ppc BSP layer. Seems like support for that machine was removed in May [1]. The reason given was *u-boot code base can not support mpc85xx for sdk 1.3.2. Howerver, that was contested in a follow-up e-mail. Interestingly, the QorIQ-SDK-V1.3.2-20130325-yocto does contain meta-fsl-ppc with support for that machine. I grepped through the git log but could not even find the commit that removed it. Could someone please comment on the status? Is the BSP layer contained in QorIQ-SDK-V1.3.2-20130325-yocto compatible with Dylan? Thanks, Rudi [1] https://lists.yoctoproject.org/pipermail/meta-freescale/2013-May/002679.html ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto reference manual missing entries for MACHINE_DEVICETREE and KERNEL_DEVICETREE
Hi Scott, I noticed that the yocto reference manual is missing entries for MACHINE_DEVICETREE and KERNEL_DEVICETREE variables. I was trying to find out what the difference between the two were, and discovered that it's not described in the reference manual here: http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] IMAGE SATO BOOTARGS
Hello all, Im newbi with linux embedded. I bought a mini2440 boards and I downloaded the yocto project. I found some recipes for the same board from this guy. https://github.com/sakhnik/meta-mini2440 I have a kernel built for mini2440, and the core-image-sato-mini2440.rootfs.tar.bz2 I have some question, I hope someone can help me. -If the kernel was not build with HOB, would it work anyway? -Which are the bootargs to pass to the kernel so it will start with the graphical mode? Thank you very much Javier (Bs As, Argentina) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to work with linux-yocto kernel
On 13-08-28 01:48 PM, Elvis Dowson wrote: Hi, I just don't understand how to work with the linux-yocto kernel. For example, I created a local copy of the yocto kernel, and updated the linux-yocto_3.8.bb recipe to point to the local copy (git:///path;protocol=file, etc) Then I created a local branch meta, and another local branch standard/qemuarma9 and then updated the machine definitions in the meta branch for qemuarma9. When I run yocto, and bitbake linux-yocto, in the tmp folder, if I check the git branch, it's checked out *_standard/common-pc/atom-pc._* There were some old bugs which caused the wrong board description to be picked up, the seems similar. But without seeing your exact changes, as they sit in the tree, I can't be sure. Did you also update the meta and machine branch SRCREVs ? This is really weird. I've wasted a couple of days because the yocto build infrastructure was checkout out the wrong branch. Start with the yocto-bsp tool, it's probably the easiest way to define a new BSP in recipe space, and then move it to the kernel later. Cheers, Bruce Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to work with linux-yocto kernel
Hi, I just don't understand how to work with the linux-yocto kernel. For example, I created a local copy of the yocto kernel, and updated the linux-yocto_3.8.bb recipe to point to the local copy (git:///path;protocol=file, etc) Then I created a local branch meta, and another local branch standard/qemuarma9 and then updated the machine definitions in the meta branch for qemuarma9. When I run yocto, and bitbake linux-yocto, in the tmp folder, if I check the git branch, it's checked out standard/common-pc/atom-pc. This is really weird. I've wasted a couple of days because the yocto build infrastructure was checkout out the wrong branch. Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to work with linux-yocto kernel
Hi Bruce, On Aug 28, 2013, at 9:52 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: There were some old bugs which caused the wrong board description to be picked up, the seems similar. But without seeing your exact changes, as they sit in the tree, I can't be sure. Did you also update the meta and machine branch SRCREVs ? No, I didn't. I've just done this now. It's only after you mentioned it that I noticed the SRCREV_meta variable in linux-yocto_3.8.bb While obvious, once stated, it's better to explicitly document this step in the kernel development guide, so that people remember to do it: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html BTW, in qemuarma9-standard.scc, for the branch, do I specify standard/qemuarma9 or just qemuarma9 ? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to work with linux-yocto kernel
On 13-08-28 02:05 PM, Elvis Dowson wrote: Hi Bruce, On Aug 28, 2013, at 9:52 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: There were some old bugs which caused the wrong board description to be picked up, the seems similar. But without seeing your exact changes, as they sit in the tree, I can't be sure. Did you also update the meta and machine branch SRCREVs ? No, I didn't. I've just done this now. It's only after you mentioned it that I noticed the SRCREV_meta variable in linux-yocto_3.8.bb While obvious, once stated, it's better to explicitly document this step in the kernel development guide, so that people remember to do it: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html If you have a moment, drop a quick bugzilla and we can make sure that happens. BTW, in qemuarma9-standard.scc, for the branch, do I specify standard/qemuarma9 or just qemuarma9 ? Just qemuarma9. Branch names are automatically built up with inheritance. So if you include other features that branch (like the standard kernel), your name is appended. That frees your individual feature from needing to know where it sits in the include order. Cheers, Bruce Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to work with linux-yocto kernel
On Aug 28, 2013, at 10:07 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-08-28 02:05 PM, Elvis Dowson wrote: Hi Bruce, On Aug 28, 2013, at 9:52 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: There were some old bugs which caused the wrong board description to be picked up, the seems similar. But without seeing your exact changes, as they sit in the tree, I can't be sure. Did you also update the meta and machine branch SRCREVs ? No, I didn't. I've just done this now. It's only after you mentioned it that I noticed the SRCREV_meta variable in linux-yocto_3.8.bb While obvious, once stated, it's better to explicitly document this step in the kernel development guide, so that people remember to do it: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html If you have a moment, drop a quick bugzilla and we can make sure that happens. I've just done this now. https://bugzilla.yoctoproject.org/show_bug.cgi?id=5065 Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PATCH 0/1] meta: add new 3.4 cfg for LSI axm5500sim and elpaso
This is the meta cfg/scc for building from the standard/axxia/base and preempt-rt branches. David Mercado (1): meta: Add LSI axm5500sim and elpaso .../bsp/axm5500sim/axm5500sim-preempt-rt.cfg | 19 + .../bsp/axm5500sim/axm5500sim-preempt-rt.scc | 9 + .../bsp/axm5500sim/axm5500sim-standard.scc | 8 + .../cfg/kernel-cache/bsp/axm5500sim/axm5500sim.cfg | 599 + .../cfg/kernel-cache/bsp/axm5500sim/axm5500sim.scc | 1 + .../kernel-cache/bsp/elpaso/elpaso-preempt-rt.scc | 8 + .../kernel-cache/bsp/elpaso/elpaso-standard.scc| 8 + meta/cfg/kernel-cache/bsp/elpaso/elpaso.cfg| 157 ++ meta/cfg/kernel-cache/bsp/elpaso/elpaso.scc| 1 + 9 files changed, 810 insertions(+) create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.cfg create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.scc create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-standard.scc create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim.cfg create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim.scc create mode 100644 meta/cfg/kernel-cache/bsp/elpaso/elpaso-preempt-rt.scc create mode 100644 meta/cfg/kernel-cache/bsp/elpaso/elpaso-standard.scc create mode 100644 meta/cfg/kernel-cache/bsp/elpaso/elpaso.cfg create mode 100644 meta/cfg/kernel-cache/bsp/elpaso/elpaso.scc -- 1.8.4 ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 1/1] meta: Add LSI axm5500sim and elpaso
From: David Mercado david.merc...@windriver.com Adds cfg/scc support for the LSI axm5500sim and elpaso bsps. Signed-off-by: David Mercado david.merc...@windriver.com Signed-off-by: Paul Butler paul.but...@windriver.com --- .../bsp/axm5500sim/axm5500sim-preempt-rt.cfg | 19 + .../bsp/axm5500sim/axm5500sim-preempt-rt.scc | 9 + .../bsp/axm5500sim/axm5500sim-standard.scc | 8 + .../cfg/kernel-cache/bsp/axm5500sim/axm5500sim.cfg | 599 + .../cfg/kernel-cache/bsp/axm5500sim/axm5500sim.scc | 1 + .../kernel-cache/bsp/elpaso/elpaso-preempt-rt.scc | 8 + .../kernel-cache/bsp/elpaso/elpaso-standard.scc| 8 + meta/cfg/kernel-cache/bsp/elpaso/elpaso.cfg| 157 ++ meta/cfg/kernel-cache/bsp/elpaso/elpaso.scc| 1 + 9 files changed, 810 insertions(+) create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.cfg create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.scc create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-standard.scc create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim.cfg create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim.scc create mode 100644 meta/cfg/kernel-cache/bsp/elpaso/elpaso-preempt-rt.scc create mode 100644 meta/cfg/kernel-cache/bsp/elpaso/elpaso-standard.scc create mode 100644 meta/cfg/kernel-cache/bsp/elpaso/elpaso.cfg create mode 100644 meta/cfg/kernel-cache/bsp/elpaso/elpaso.scc diff --git a/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.cfg b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.cfg new file mode 100644 index 000..4cb5f5f --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.cfg @@ -0,0 +1,19 @@ +#. +#WARNING +# +# This file is a kernel configuration fragment, and not a full kernel +# configuration file. The final kernel configuration is made up of +# an assembly of processed fragments, each of which is designed to +# capture a specific part of the final configuration (e.g. platform +# configuration, feature configuration, and board specific hardware +# configuration). For more information on kernel configuration, please +# consult the product documentation. +# +#. + +# Set the base level of prempt_rt to CONFIG_PREEMPT_RTB. The preempt_rt +# kernel must be set with a minimal preempt model, to enable +# CONFIG_GENERIC_LOCKBREAK, which in turn allows spinlocks to work +# correctly across multiple clusters + +CONFIG_PREEMPT_RTB=y diff --git a/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.scc b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.scc new file mode 100644 index 000..ae2ab83 --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.scc @@ -0,0 +1,9 @@ +define KMACHINE axm5500sim +define KTYPE preempt-rt +define KARCH arm + +include ktypes/preempt-rt +branch standard/preempt-rt/lsi + +kconf hardware axm5500sim-preempt-rt.cfg +include axm5500sim.scc diff --git a/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-standard.scc b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-standard.scc new file mode 100644 index 000..ef4bdb4 --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-standard.scc @@ -0,0 +1,8 @@ +define KMACHINE axm5500sim +define KTYPE standard +define KARCH arm + +include ktypes/standard +branch standard/lsi + +include axm5500sim.scc diff --git a/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim.cfg b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim.cfg new file mode 100644 index 000..6fffa3f --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim.cfg @@ -0,0 +1,599 @@ +#. +#WARNING +# +# This file is a kernel configuration fragment, and not a full kernel +# configuration file. The final kernel configuration is made up of +# an assembly of processed fragments, each of which is designed to +# capture a specific part of the final configuration (e.g. platform +# configuration, feature configuration, and board specific hardware +# configuration). For more information on kernel configuration, please +# consult the product documentation. +# +#. + +# +# General setup +# + +CONFIG_FHANDLE=y +CONFIG_TASKSTATS=y +CONFIG_TASK_DELAY_ACCT=y +CONFIG_TASK_XACCT=y +CONFIG_TASK_IO_ACCOUNTING=y +CONFIG_AUDIT=y + +# +# RCU Subsystem +# + +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUP_DEBUG is not set +# CONFIG_CGROUP_FREEZER is not set +# CONFIG_CGROUP_DEVICE is not set +# CONFIG_CPUSETS is not set +# CONFIG_CGROUP_CPUACCT is not set +# CONFIG_RESOURCE_COUNTERS is not set +# CONFIG_RT_GROUP_SCHED is not set +#
Re: [yocto] confusion about DEPENDS vs RDEPENDS
On 2013-08-28 6:06, Paul Eggleton wrote:
Hi Hans,
On Wednesday 28 August 2013 17:08:41 Hans Beckérus wrote:
Hi, I am a little bit confused about how to handle these two and what
they are supposed to solve. I have so far never used RDEPENDS but only
DEPENDS.
DEPENDS means a build-time dependency i.e. between recipes, RDEPENDS means a
runtime dependency i.e. between packages. It is worth noting though that an
explicitly stated RDEPENDS will cause bitbake to actually build the recipe
providing the package named in the RDEPENDS value, just at a different time. To
explain exactly what each of these do:
* DEPENDS = b in recipe a will translate to a's do_configure task depending
on recipe b's do_populate_sysroot task, so that anything recipe b puts into
the sysroot is available for when a configures itself.
* RDEPENDS_${PN} = b in recipe a will translate to a's do_build task
depending on recipe b's do_package_write task, so that the package file b is
available when the output for a has been completely built (of course assuming
that recipe b produces a package called b, which it will with the default
value of PACKAGES). More importantly it will also ensure that package a is
marked as depending on b in a manner understood by the package manager being
used e.g. rpm / opkg / dpkg.
Thanks a lot! This was definitely more than I got from the description
of DEPENDS and RDEPENDS in the manual.
But I probably just read the wrong one ;)
But I am also having severe problems when building a rootfs image when
one of my user space libraries are changed from eg. libfoo.so.1 to
libfoo.so.3. Even though all my packages that have dependencies to it
includes it in a DEPENDS.
The error I get during rootfs build is:
| Computing transaction...error: Can't install
someapp-1.0-r0@cortexa9_vfp: no package provides libfoo.so.1
But there is no libfoo.so.1 in my sysroot, it has been replaced by
libfoo.so.3. I know for sure that 'someapp' was rebuilt, but still I got
the error message. What do seem to help is to force a fetch of 'someapp'
and then rebuild which sort of indicates that some garbage was left behind.
But having a package listed in DEPENDS will not force a new fetch if I am
not mistaken.
By default, if recipe foo changes and it is mentioned in the someapp
recipe's DEPENDS, then someapp's do_configure and all tasks that depend upon it
will be re-executed next time it is called for i.e. you explicitly build
someapp or build an image that contains it or some other recipe that depends
upon it. The fact that you are getting the behaviour described suggests that
this is either not happening, or more likely it is not having the desired
effect; e.g. if internally someapp's build system doesn't drop or invalidate
all of its build output when it is reconfigured then you will get this kind of
behaviour. Setting up B (the directory in which a recipe's source code is
built) separate to S (the directory in which the recipe's source code has been
unpacked to) can help with this since if they are separate, our build system
will know it can delete B before re-executing do_compile after do_configure and
you'll never have stale build output. Being able to set this up however is
highly dependent on the software being built by the individual recipe; some
lend themselves to this and others don't.
Well, I have been struggling before with packages not properly
supporting different build and source folders so I can definitely relate
to what you are saying. But, does that mean I actually *have* to do it
this way for build dependencies to work correctly? In my case we are
talking two simple autotools enabled packages and I (naively?) assumed
this was not something I had to take care of myself. What strikes me is
that you say if recipe foo changes, which is actually not the case
here! What is changed is the actual source code only. Is that what is
going wrong here? If I change my foo recipe version, would that be
different than to simply fetch/unpack the foo package source code? Is
someapp going to become purged differently in such a scenario?
Have I been using the DEPENDS variable incorrectly? Would it make a
difference if I used RDEPENDS instead?
RDEPENDS would not be appropriate in this situation, since we're talking about
a build-time dependency.
Hope that helps.
What is still somewhat unclear to me is the difference between DEPENDS
and RDEPENDS in a simple case as this.
A simple application needing a dynamic library is obviously a subject
for DEPENDS but to me that also sounds like a typical RDEPENDS?
However, when I build an image and include 'someapp', will 'libfoo.so.x'
automatically be installed or is that what I need to tell it to do using
RDEPENDS?
Cheers,
Paul
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PATCH 2/2] Revert timer_list: Split timer_list_show_tickdevices
This reverts commit 60cf7ea849e77c8782dee147cfb8c38d1984236e.
This is a temporary workaround for the dropbearkey hang issue in 3.10.
---
kernel/time/timer_list.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
index 380a589..af5a7e9 100644
--- a/kernel/time/timer_list.c
+++ b/kernel/time/timer_list.c
@@ -133,6 +133,7 @@ static void print_cpu(struct seq_file *m, int cpu, u64 now)
struct hrtimer_cpu_base *cpu_base = per_cpu(hrtimer_bases, cpu);
int i;
+ SEQ_printf(m, \n);
SEQ_printf(m, cpu: %d\n, cpu);
for (i = 0; i HRTIMER_MAX_CLOCK_BASES; i++) {
SEQ_printf(m, clock %d:\n, i);
@@ -186,7 +187,6 @@ static void print_cpu(struct seq_file *m, int cpu, u64 now)
#undef P
#undef P_ns
- SEQ_printf(m, \n);
}
#ifdef CONFIG_GENERIC_CLOCKEVENTS
@@ -195,6 +195,7 @@ print_tickdevice(struct seq_file *m, struct tick_device
*td, int cpu)
{
struct clock_event_device *dev = td-evtdev;
+ SEQ_printf(m, \n);
SEQ_printf(m, Tick Device: mode: %d\n, td-mode);
if (cpu 0)
SEQ_printf(m, Broadcast device\n);
@@ -229,11 +230,12 @@ print_tickdevice(struct seq_file *m, struct tick_device
*td, int cpu)
print_name_offset(m, dev-event_handler);
SEQ_printf(m, \n);
SEQ_printf(m, retries:%lu\n, dev-retries);
- SEQ_printf(m, \n);
}
-static void timer_list_show_tickdevices_header(struct seq_file *m)
+static void timer_list_show_tickdevices(struct seq_file *m)
{
+ int cpu;
+
#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
print_tickdevice(m, tick_get_broadcast_device(), -1);
SEQ_printf(m, tick_broadcast_mask: %08lx\n,
@@ -244,7 +246,12 @@ static void timer_list_show_tickdevices_header(struct
seq_file *m)
#endif
SEQ_printf(m, \n);
#endif
+ for_each_online_cpu(cpu)
+ print_tickdevice(m, tick_get_device(cpu), cpu);
+ SEQ_printf(m, \n);
}
+#else
+static void timer_list_show_tickdevices(struct seq_file *m) { }
#endif
static int timer_list_show(struct seq_file *m, void *v)
@@ -255,16 +262,12 @@ static int timer_list_show(struct seq_file *m, void *v)
SEQ_printf(m, Timer List Version: v0.7\n);
SEQ_printf(m, HRTIMER_MAX_CLOCK_BASES: %d\n, HRTIMER_MAX_CLOCK_BASES);
SEQ_printf(m, now at %Ld nsecs\n, (unsigned long long)now);
- SEQ_printf(m, \n);
for_each_online_cpu(cpu)
print_cpu(m, cpu, now);
-#ifdef CONFIG_GENERIC_CLOCKEVENTS
- timer_list_show_tickdevices_header(m);
- for_each_online_cpu(cpu)
- print_tickdevice(m, tick_get_device(cpu), cpu);
-#endif
+ SEQ_printf(m, \n);
+ timer_list_show_tickdevices(m);
return 0;
}
--
1.7.11.4
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 1/2] Revert timer_list: Convert timer list to be a proper seq_file
This reverts commit b3956a896ea57f25cacd74708b8fab611543a81d.
This is a temporary workaround for the dropbearkey hang issue in 3.10.
---
kernel/time/timer_list.c | 89 +++-
1 file changed, 12 insertions(+), 77 deletions(-)
diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
index 3bdf283..380a589 100644
--- a/kernel/time/timer_list.c
+++ b/kernel/time/timer_list.c
@@ -20,13 +20,6 @@
#include asm/uaccess.h
-
-struct timer_list_iter {
- int cpu;
- bool second_pass;
- u64 now;
-};
-
typedef void (*print_fn_t)(struct seq_file *m, unsigned int *classes);
DECLARE_PER_CPU(struct hrtimer_cpu_base, hrtimer_bases);
@@ -254,101 +247,43 @@ static void timer_list_show_tickdevices_header(struct
seq_file *m)
}
#endif
-static inline void timer_list_header(struct seq_file *m, u64 now)
-{
- SEQ_printf(m, Timer List Version: v0.7\n);
- SEQ_printf(m, HRTIMER_MAX_CLOCK_BASES: %d\n, HRTIMER_MAX_CLOCK_BASES);
- SEQ_printf(m, now at %Ld nsecs\n, (unsigned long long)now);
- SEQ_printf(m, \n);
-}
-
static int timer_list_show(struct seq_file *m, void *v)
{
- struct timer_list_iter *iter = v;
- u64 now = ktime_to_ns(ktime_get());
-
- if (iter-cpu == -1 !iter-second_pass)
- timer_list_header(m, now);
- else if (!iter-second_pass)
- print_cpu(m, iter-cpu, iter-now);
-#ifdef CONFIG_GENERIC_CLOCKEVENTS
- else if (iter-cpu == -1 iter-second_pass)
- timer_list_show_tickdevices_header(m);
- else
- print_tickdevice(m, tick_get_device(iter-cpu), iter-cpu);
-#endif
- return 0;
-}
-
-void sysrq_timer_list_show(void)
-{
u64 now = ktime_to_ns(ktime_get());
int cpu;
- timer_list_header(NULL, now);
+ SEQ_printf(m, Timer List Version: v0.7\n);
+ SEQ_printf(m, HRTIMER_MAX_CLOCK_BASES: %d\n, HRTIMER_MAX_CLOCK_BASES);
+ SEQ_printf(m, now at %Ld nsecs\n, (unsigned long long)now);
+ SEQ_printf(m, \n);
for_each_online_cpu(cpu)
- print_cpu(NULL, cpu, now);
+ print_cpu(m, cpu, now);
#ifdef CONFIG_GENERIC_CLOCKEVENTS
- timer_list_show_tickdevices_header(NULL);
+ timer_list_show_tickdevices_header(m);
for_each_online_cpu(cpu)
- print_tickdevice(NULL, tick_get_device(cpu), cpu);
+ print_tickdevice(m, tick_get_device(cpu), cpu);
#endif
- return;
-}
-static void *timer_list_start(struct seq_file *file, loff_t *offset)
-{
- struct timer_list_iter *iter = file-private;
-
- if (!*offset) {
- iter-cpu = -1;
- iter-now = ktime_to_ns(ktime_get());
- } else if (iter-cpu = nr_cpu_ids) {
-#ifdef CONFIG_GENERIC_CLOCKEVENTS
- if (!iter-second_pass) {
- iter-cpu = -1;
- iter-second_pass = true;
- } else
- return NULL;
-#else
- return NULL;
-#endif
- }
- return iter;
-}
-
-static void *timer_list_next(struct seq_file *file, void *v, loff_t *offset)
-{
- struct timer_list_iter *iter = file-private;
- iter-cpu = cpumask_next(iter-cpu, cpu_online_mask);
- ++*offset;
- return timer_list_start(file, offset);
+ return 0;
}
-static void timer_list_stop(struct seq_file *seq, void *v)
+void sysrq_timer_list_show(void)
{
+ timer_list_show(NULL, NULL);
}
-static const struct seq_operations timer_list_sops = {
- .start = timer_list_start,
- .next = timer_list_next,
- .stop = timer_list_stop,
- .show = timer_list_show,
-};
-
static int timer_list_open(struct inode *inode, struct file *filp)
{
- return seq_open_private(filp, timer_list_sops,
- sizeof(struct timer_list_iter));
+ return single_open(filp, timer_list_show, NULL);
}
static const struct file_operations timer_list_fops = {
.open = timer_list_open,
.read = seq_read,
.llseek = seq_lseek,
- .release= seq_release_private,
+ .release= single_release,
};
static int __init init_timer_list_procfs(void)
--
1.7.11.4
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 0/2] linux-yocto-3.10: revert timer_list patches
The following reverts fix the problem outlined in [Yocto #5062], which manifested as a dropbearkey hang: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5062 This is a temporary fix and this particular branch contains only a revert for common-pc-64-base, but the same revert should be done repo-wide. I'll be looking into creating a proper upstream fix for this, but this gets around the problem for now; this fix was for large-CPU systems and memory-fragmented conditions. The following changes since commit 6c1528b2b78d1ec7e75bb7a9880074ec35aa1aa0: perf annotate: replace 'expand' with equivalent sed expression (2013-08-22 14:34:00 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib.git tzanussi/proc_timer_list-revert http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=tzanussi/proc_timer_list-revert Tom Zanussi (2): Revert timer_list: Convert timer list to be a proper seq_file Revert timer_list: Split timer_list_show_tickdevices kernel/time/timer_list.c | 104 ++- 1 file changed, 21 insertions(+), 83 deletions(-) -- 1.7.11.4 ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] Is there a OE core based mgetty?
On Tue, Aug 27, 2013 at 6:56 PM, Brian Hutchinson b.hutch...@gmail.comwrote: Hi, I need mgetty and don't see it anywhere in any of the OE core based layers. Did something replace it? I'm trying to migrate some OE classic work to OE core based distros. Regards, Brian Ping! I'll take that as a No then. :) So I'm working on adding this to OE Core based distros ... should it go in meta/recipes-connectivity? The ppp stuff is in meta/recipes-connectivity so I'm thinking that's where it belongs??? Regards, Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is there a OE core based mgetty?
On 08/28/2013 03:19 PM, Brian Hutchinson wrote: On Tue, Aug 27, 2013 at 6:56 PM, Brian Hutchinson b.hutch...@gmail.com mailto:b.hutch...@gmail.com wrote: Hi, I need mgetty and don't see it anywhere in any of the OE core based layers. Did something replace it? I'm trying to migrate some OE classic work to OE core based distros. Regards, Brian Ping! I'll take that as a No then. :) So I'm working on adding this to OE Core based distros ... should it go in meta/recipes-connectivity? The ppp stuff is in meta/recipes-connectivity so I'm thinking that's where it belongs??? FWIW, linux-utils provides agetty; busybox also has a getty (was in tinylogin in earlier versions, but should be in busybox now). Dunno if those would meet your needs. Peter ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Deleted tag in poky master.
I jumped the gun and pushed a tag a few moments ago (1.5_M4.rc1). I've deleted this tag, so folks should git fetch --prune --tags if you've pulled in the past few moments. -b -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] confusion about DEPENDS vs RDEPENDS
On Wed, Aug 28, 2013 at 9:22 PM, Hans Beckerus hans.becke...@gmail.comwrote: Well, I have been struggling before with packages not properly supporting different build and source folders so I can definitely relate to what you are saying. But, does that mean I actually *have* to do it this way for build dependencies to work correctly? In my case we are talking two simple autotools enabled packages and I (naively?) assumed this was not something I had to take care of myself. What strikes me is that you say if recipe foo changes, which is actually not the case here! What is changed is the actual source code only. Is that what is going wrong here? If I change my foo recipe version, would that be different than to simply fetch/unpack the foo package source code? Is someapp going to become purged differently in such a scenario? if the source code changes, the version of the recipe needs to change too. if you change the source code without bumping the version, the package might not be rebuilt properly indeed. and that can explain the behavior you are seeing. if 'someapp' does not change, it would be rebuilt only if one of its dependencies was rebuilt. Have I been using the DEPENDS variable incorrectly? Would it make a difference if I used RDEPENDS instead? RDEPENDS would not be appropriate in this situation, since we're talking about a build-time dependency. Hope that helps. What is still somewhat unclear to me is the difference between DEPENDS and RDEPENDS in a simple case as this. A simple application needing a dynamic library is obviously a subject for DEPENDS but to me that also sounds like a typical RDEPENDS? However, when I build an image and include 'someapp', will 'libfoo.so.x' automatically be installed or is that what I need to tell it to do using RDEPENDS? some (most?) of the RDEPENDS are computed auto-magically. so bitbake will figure out the dependency between 'someapp' and 'libfoo.so.x' and will automatically update 'someapp' RDEPENDS, without the need to do it explicitely in the recipe! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is there a OE core based mgetty?
On Aug 28, 2013 4:39 PM, Peter A. Bigot p...@pabigot.com wrote: On 08/28/2013 03:19 PM, Brian Hutchinson wrote: On Tue, Aug 27, 2013 at 6:56 PM, Brian Hutchinson b.hutch...@gmail.com wrote: Hi, I need mgetty and don't see it anywhere in any of the OE core based layers. Did something replace it? I'm trying to migrate some OE classic work to OE core based distros. Regards, Brian Ping! I'll take that as a No then. :) So I'm working on adding this to OE Core based distros ... should it go in meta/recipes-connectivity? The ppp stuff is in meta/recipes-connectivity so I'm thinking that's where it belongs??? FWIW, linux-utils provides agetty; busybox also has a getty (was in tinylogin in earlier versions, but should be in busybox now). Dunno if those would meet your needs. Peter I need modem control. I'm moving an existing product (OE Classic based) into the OE Core world and it uses mgetty with modems (cellular modems). Regards, Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] confusion about DEPENDS vs RDEPENDS
From: Nicolas Dechesne if the source code changes, the version of the recipe needs to change too. if you change the source code without bumping the version, the package might not be rebuilt properly indeed. and that can explain the behavior you are seeing. if 'someapp' does not change, it would be rebuilt only if one of its dependencies was rebuilt. If you're making lots of changes in the course of debugging, isn't it reasonable just to do a cleansstate on the recipe to force it to be rebuilt? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] omxplayer building for Rpi
On Tue, Aug 20, 2013 at 2:38 PM, Belisko Marek marek.beli...@gmail.comwrote: Hello, I'm trying to build omxplayer for Rpi board but seems libav and other dependencies was removed (replaced by meta-oe). But libav was also removed from meta-oe [1]. I was trying to use patches [2] but it produce errors: ERROR: Multiple .bb files are due to be built which each provide virtual/libgles2 (/home/marek/projects/yocto/1.4.1/poky/meta-raspberrypi/recipes-graphics/userland/ userland_git.bb /home/marek/projects/yocto/1.4.1/poky/meta/recipes-graphics/mesa/ mesa_9.0.2.bb). This usually means one provides something the other doesn't and should. ERROR: Multiple .bb files are due to be built which each provide virtual/egl (/home/marek/projects/yocto/1.4.1/poky/meta-raspberrypi/recipes-graphics/userland/ userland_git.bb /home/marek/projects/yocto/1.4.1/poky/meta/recipes-graphics/mesa/ mesa_9.0.2.bb). This usually means one provides something the other doesn't and should. Is my procedure correct? Despite of fact there are error compilation continues. I believe this was fixed now. Can you check again? BTW You shouldn't need meta-oe anymore. -- *Andrei Gherzan* m: +40.744.478.414 | f: +40.31.816.28.12 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Status of 1.5_M4 release candidate.
All, Earlier today we attempted a spin of rc1. This attempt ended up having multiple issues. Due to that, we decided to end the build, tag and spin an rc2. So far, things are looking ok. I did drop the number of buildslaves on the autobuilder down from 3 to 2, so things might take a bit longer. The build should be available in a few hours at: http://autobuilder.yoctoproject.org/pub/releases/1.5_M4.rc2 meta-fsl-arm f2805add77f9e9d5f7a114ee99a632172d8f3ff6 meta-fsl-ppc 58a57096e4b7e2ceca3c33d3e7100c5434966cd9 meta-intel 164067980e18e8ba60b317677ced2d75c3725dbe meta-minnow 7719e114bd0c2118c3d4c2a1a7c06e966103ab09 meta-qt3 b73552fb998fd30a01dbee5a172e432a16078222 poky 5745e45b18e5099e94b4d5a73bc97dc6d4cdc91f -b -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Question] libxml: How about add --with-catalog to EXTRA_OECONF ?
Hi, I had build libxml and executed xmlcatalog It shows follow messages # xmlcatalog --help libxml was not compiled with catalog and output support meta/recipes-core/libxml/libxml2.inc: 32 EXTRA_OECONF = --without-python --without-debug --without-legacy --without-catalog --without-docbook --with-c14n --without-lzma --with-fexceptions Is it reasonable to add --without-catalog EXTRA_OECONF ? Thanks Best regards. Li Zhijian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-freescale] [meta-fsl-ppc] MPC8572 Machine with Dylan
Hi Rudi, Mpc85xx series is not supported and removed since FSL QorIQ SDK 1.4(QorIQ-SDK-V1.4-20130625-yocto) which is based on Yocto 1.4(dylan), the machine configure files are removed from dylan/master of meta-fsl-ppc layer to avoid unexpected issues. http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/commit/?h=dylanid=ee9e6378f4f2651b78bb5ccc804f7dda627569d6 QorIQ SDK 1.3.2 uses denzil of Poky, you can use danny/denzil/edison for image build of mpc85xx series. Best Regards, Zhenhua From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Rudolf Streif Sent: Thursday, August 29, 2013 12:34 AM To: Yocto Discussion Mailing List Subject: [yocto] [meta-freescale] [meta-fsl-ppc] MPC8572 Machine with Dylan I am looking to build for MPC8572 with Dylan and checked out the meta-fsl-ppc BSP layer. Seems like support for that machine was removed in May [1]. The reason given was *u-boot code base can not support mpc85xx for sdk 1.3.2. Howerver, that was contested in a follow-up e-mail. Interestingly, the QorIQ-SDK-V1.3.2-20130325-yocto does contain meta-fsl-ppc with support for that machine. I grepped through the git log but could not even find the commit that removed it. Could someone please comment on the status? Is the BSP layer contained in QorIQ-SDK-V1.3.2-20130325-yocto compatible with Dylan? Thanks, Rudi [1] https://lists.yoctoproject.org/pipermail/meta-freescale/2013-May/002679.html ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to work with linux-yocto kernel
On Wed, 2013-08-28 at 22:22 +0400, Elvis Dowson wrote: On Aug 28, 2013, at 10:07 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-08-28 02:05 PM, Elvis Dowson wrote: Hi Bruce, On Aug 28, 2013, at 9:52 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: There were some old bugs which caused the wrong board description to be picked up, the seems similar. But without seeing your exact changes, as they sit in the tree, I can't be sure. Did you also update the meta and machine branch SRCREVs ? No, I didn't. I've just done this now. It's only after you mentioned it that I noticed the SRCREV_meta variable in linux-yocto_3.8.bb While obvious, once stated, it's better to explicitly document this step in the kernel development guide, so that people remember to do it: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html If you have a moment, drop a quick bugzilla and we can make sure that happens. I've just done this now. https://bugzilla.yoctoproject.org/show_bug.cgi?id=5065 Thank you for taking the time to file the bug. This is crucial feedback and the only way for the documentation to improve is for people like you to review and provide feedback. Thank you! Please follow the bug as we may have questions for you to make sure we address the issue. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-freescale] [meta-fsl-ppc] MPC8572 Machine with Dylan
Thank you, Zhenhua. I ended up using meta-fsl-ppc from [1] which has support for mpc8572 and Dylan. It built the kernel, dtb and rootfs image. It does not boot right now though stopping after Uncompressing Kernel Image ... OK. I guess I have to do more debugging. Thanks, Rudi [1] http://git.freescale.com/git/cgit.cgi/ppc/sdk/meta-fsl-ppc.git/tree/?h=dylan On Wed, Aug 28, 2013 at 7:33 PM, Luo Zhenhua-B19537 b19...@freescale.comwrote: Hi Rudi, ** ** Mpc85xx series is not supported and removed since FSL QorIQ SDK 1.4(QorIQ-SDK-V1.4-20130625-yocto) which is based on Yocto 1.4(dylan), the machine configure files are removed from dylan/master of meta-fsl-ppc layer to avoid unexpected issues. http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/commit/?h=dylanid=ee9e6378f4f2651b78bb5ccc804f7dda627569d6 ** ** QorIQ SDK 1.3.2 uses denzil of Poky, you can use danny/denzil/edison for image build of mpc85xx series. ** ** ** ** Best Regards, ** ** Zhenhua ** ** *From:* yocto-boun...@yoctoproject.org [mailto: yocto-boun...@yoctoproject.org] *On Behalf Of *Rudolf Streif *Sent:* Thursday, August 29, 2013 12:34 AM *To:* Yocto Discussion Mailing List *Subject:* [yocto] [meta-freescale] [meta-fsl-ppc] MPC8572 Machine with Dylan ** ** I am looking to build for MPC8572 with Dylan and checked out the meta-fsl-ppc BSP layer. Seems like support for that machine was removed in May [1]. The reason given was *u-boot code base can not support mpc85xx for sdk 1.3.2. Howerver, that was contested in a follow-up e-mail. Interestingly, the QorIQ-SDK-V1.3.2-20130325-yocto does contain meta-fsl-ppc with support for that machine. ** ** I grepped through the git log but could not even find the commit that removed it. ** ** Could someone please comment on the status? Is the BSP layer contained in QorIQ-SDK-V1.3.2-20130325-yocto compatible with Dylan? ** ** ** ** Thanks, Rudi ** ** ** ** [1] https://lists.yoctoproject.org/pipermail/meta-freescale/2013-May/002679.html ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Status of 1.5_M4 release candidate.
An update on where we are at: rc1 is still churning. There was one autobuilder issue with regards to genericx86 in nightly-x86-lsb. I've built this out by hand and populated the release with it as well as corrected the ab issue. We're seeing a lot of sanity issues, but so far no build failures (other than the above known issue). -b On Wed, Aug 28, 2013 at 5:41 PM, Flanagan, Elizabeth elizabeth.flana...@intel.com wrote: All, Earlier today we attempted a spin of rc1. This attempt ended up having multiple issues. Due to that, we decided to end the build, tag and spin an rc2. So far, things are looking ok. I did drop the number of buildslaves on the autobuilder down from 3 to 2, so things might take a bit longer. The build should be available in a few hours at: http://autobuilder.yoctoproject.org/pub/releases/1.5_M4.rc2 meta-fsl-arm f2805add77f9e9d5f7a114ee99a632172d8f3ff6 meta-fsl-ppc 58a57096e4b7e2ceca3c33d3e7100c5434966cd9 meta-intel 164067980e18e8ba60b317677ced2d75c3725dbe meta-minnow 7719e114bd0c2118c3d4c2a1a7c06e966103ab09 meta-qt3 b73552fb998fd30a01dbee5a172e432a16078222 poky 5745e45b18e5099e94b4d5a73bc97dc6d4cdc91f -b -- Elizabeth Flanagan Yocto Project Build and Release -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [meta-freescale] How to build a custom ramdisk image
Thanks for your Response Zhenhua, do you know how to add or modify user account? Best Regards, Ivan 2013/8/23 Luo Zhenhua-B19537 b19...@freescale.com: -Original Message- From: Mercier Ivan [mailto:ivan.merc...@gmail.com] Sent: Friday, August 23, 2013 3:19 PM there is no way to edit files in the root filesystem? like /etc/hostname... [Luo Zhenhua-B19537] No, we can change such files. How do I know which file belong to which package? and How do I know where is the package directory? [Luo Zhenhua-B19537] find/grep should be useful to get the answer. For the specific case you mentioned, refer to meta-fsl-networking/recipes-append/sysvinit/files/auto-detect-hostname.patch. Best Regards, Zhenhua thanks a lot 2013/8/23 Luo Zhenhua-B19537 b19...@freescale.com: Hi Ivan, build_p3041ds_release/tmp/work/p3041ds-fsl_networking-linux/fsl-image- core/1.0-r20/rootfs is removed when you run bitbake fsl-image-core, and the folder will be recreated, so modification in the folder is missing. You need to do the modification in corresponding recipe folder of the package, e.g. interfaces is in meta-fsl-ppc/recipes-core/init- ifupdown/files/. You can rebuild the modified package to ensure the modification takes effect. * bitbake init-ifupdown -c cleansstate * bitbake fsl-image-core Best Regards, Zhenhua -Original Message- From: meta-freescale-boun...@yoctoproject.org [mailto:meta-freescale- boun...@yoctoproject.org] On Behalf Of Mercier Ivan Sent: Thursday, August 22, 2013 4:55 PM To: linux-yocto@yoctoproject.org; meta-freesc...@yoctoproject.org Subject: [meta-freescale] How to build a custom ramdisk image Hi everybody, I'm working on an yocto distrib with a freescale p3041 based board. I would like to modify the root file system, like hostname,udev rules and build my own ramdisk image. I use to create my image by $ bitbake fsl-image-core is it corret? should I modidy fsl-image-core.bb? I try to modify files in build_p3041ds_release/tmp/work/p3041ds-fsl_networking-linux/fsl-image - core/1.0-r20/rootfs but modifications are overwrited can anybody help me? thanks a lot ___ meta-freescale mailing list meta-freesc...@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/2] linux-yocto-3.10: revert timer_list patches
On 13-08-28 03:24 PM, Tom Zanussi wrote: The following reverts fix the problem outlined in [Yocto #5062], which manifested as a dropbearkey hang: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5062 This is a temporary fix and this particular branch contains only a revert for common-pc-64-base, but the same revert should be done repo-wide. I'll be looking into creating a proper upstream fix for this, but this gets around the problem for now; this fix was for large-CPU systems and memory-fragmented conditions. Thanks Tom. Merged, pushed and SRCREV update sent. Bruce The following changes since commit 6c1528b2b78d1ec7e75bb7a9880074ec35aa1aa0: perf annotate: replace 'expand' with equivalent sed expression (2013-08-22 14:34:00 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib.git tzanussi/proc_timer_list-revert http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=tzanussi/proc_timer_list-revert Tom Zanussi (2): Revert timer_list: Convert timer list to be a proper seq_file Revert timer_list: Split timer_list_show_tickdevices kernel/time/timer_list.c | 104 ++- 1 file changed, 21 insertions(+), 83 deletions(-) ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] meta: Add LSI axm5500sim and elpaso
On 13-08-28 02:26 PM, Paul Butler wrote: From: David Mercado david.merc...@windriver.com Adds cfg/scc support for the LSI axm5500sim and elpaso bsps. Signed-off-by: David Mercado david.merc...@windriver.com Signed-off-by: Paul Butler paul.but...@windriver.com --- .../bsp/axm5500sim/axm5500sim-preempt-rt.cfg | 19 + .../bsp/axm5500sim/axm5500sim-preempt-rt.scc | 9 + .../bsp/axm5500sim/axm5500sim-standard.scc | 8 + .../cfg/kernel-cache/bsp/axm5500sim/axm5500sim.cfg | 599 + .../cfg/kernel-cache/bsp/axm5500sim/axm5500sim.scc | 1 + .../kernel-cache/bsp/elpaso/elpaso-preempt-rt.scc | 8 + .../kernel-cache/bsp/elpaso/elpaso-standard.scc| 8 + meta/cfg/kernel-cache/bsp/elpaso/elpaso.cfg| 157 ++ meta/cfg/kernel-cache/bsp/elpaso/elpaso.scc| 1 + 9 files changed, 810 insertions(+) create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.cfg create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.scc create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-standard.scc create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim.cfg create mode 100644 meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim.scc create mode 100644 meta/cfg/kernel-cache/bsp/elpaso/elpaso-preempt-rt.scc create mode 100644 meta/cfg/kernel-cache/bsp/elpaso/elpaso-standard.scc create mode 100644 meta/cfg/kernel-cache/bsp/elpaso/elpaso.cfg create mode 100644 meta/cfg/kernel-cache/bsp/elpaso/elpaso.scc diff --git a/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.cfg b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.cfg new file mode 100644 index 000..4cb5f5f --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.cfg @@ -0,0 +1,19 @@ +#. +#WARNING +# +# This file is a kernel configuration fragment, and not a full kernel +# configuration file. The final kernel configuration is made up of +# an assembly of processed fragments, each of which is designed to +# capture a specific part of the final configuration (e.g. platform +# configuration, feature configuration, and board specific hardware +# configuration). For more information on kernel configuration, please +# consult the product documentation. +# +#. + +# Set the base level of prempt_rt to CONFIG_PREEMPT_RTB. The preempt_rt +# kernel must be set with a minimal preempt model, to enable +# CONFIG_GENERIC_LOCKBREAK, which in turn allows spinlocks to work +# correctly across multiple clusters + +CONFIG_PREEMPT_RTB=y diff --git a/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.scc b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.scc new file mode 100644 index 000..ae2ab83 --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-preempt-rt.scc @@ -0,0 +1,9 @@ +define KMACHINE axm5500sim +define KTYPE preempt-rt +define KARCH arm + +include ktypes/preempt-rt +branch standard/preempt-rt/lsi This should just be branch lsi + +kconf hardware axm5500sim-preempt-rt.cfg +include axm5500sim.scc diff --git a/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-standard.scc b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-standard.scc new file mode 100644 index 000..ef4bdb4 --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim-standard.scc @@ -0,0 +1,8 @@ +define KMACHINE axm5500sim +define KTYPE standard +define KARCH arm + +include ktypes/standard +branch standard/lsi Same here. Just branch lsi + +include axm5500sim.scc diff --git a/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim.cfg b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim.cfg new file mode 100644 index 000..6fffa3f --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/axm5500sim/axm5500sim.cfg @@ -0,0 +1,599 @@ +#. +#WARNING +# +# This file is a kernel configuration fragment, and not a full kernel +# configuration file. The final kernel configuration is made up of +# an assembly of processed fragments, each of which is designed to +# capture a specific part of the final configuration (e.g. platform +# configuration, feature configuration, and board specific hardware +# configuration). For more information on kernel configuration, please +# consult the product documentation. +# +#. + +# +# General setup +# + +CONFIG_FHANDLE=y +CONFIG_TASKSTATS=y +CONFIG_TASK_DELAY_ACCT=y +CONFIG_TASK_XACCT=y +CONFIG_TASK_IO_ACCOUNTING=y +CONFIG_AUDIT=y These shouldn't be set in a BSP config, what's the logic for including them ? + +# +# RCU Subsystem +# + +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUP_DEBUG is not set +#
