from:"Bruce"


On 12-12-24 02:59 PM, Brian Smucker wrote:

Hi,



Catching up on email from the holidays. Did you ever get an answer
to this ?


I'm a yocto mostly-newbie, trying to find my way.  I have a custom layer
that I am using to build a kernel. The layer right now consists of a few
kernel patches and a defconfig and is based on the standard kernel
otherwise.

When I do a diff on my defconfig and the bitbake generated .config, they
are quite similar, but the CONFIG_UNION_FS=y line magically shows up.
I'm wondering where it comes from and how to disable it.


CONFIG_UNION_FS is being enabled by the standard kernel (and all
kernels that inherit it). Since you are based on that kernel, you
get the option enabled.



I can do a bitbake -c menuconfig virtual/kernel and eliminate that
option giving me the kernel I want, but those changes are gone after a
bitbake -c cleansstate ...


Have you tried putting

# CONFIG_UNION_FS is not set

in your defconfig ? That should disable it.

Bruce



Could someone give me some help about where to go from here?

Thanks,
Brian
___
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] Magic kernel config option.

On 13-01-02 04:11 PM, Brian Smucker wrote:

On 1/2/2013 10:06 AM, Bruce Ashfield wrote:
 > On 12-12-24 02:59 PM, Brian Smucker wrote:
 >> Hi,
 >>
 >
 > Catching up on email from the holidays. Did you ever get an answer
 > to this ?
Not yet,  resumed my quest today.

 >> I'm a yocto mostly-newbie, trying to find my way.  I have a custom
layer
 >> that I am using to build a kernel. The layer right now consists of a
few
 >> kernel patches and a defconfig and is based on the standard kernel
 >> otherwise.
 >>
 >> When I do a diff on my defconfig and the bitbake generated .config,
they
 >> are quite similar, but the CONFIG_UNION_FS=y line magically shows up.
 >> I'm wondering where it comes from and how to disable it.
 >
 > CONFIG_UNION_FS is being enabled by the standard kernel (and all
 > kernels that inherit it). Since you are based on that kernel, you
 > get the option enabled.
 >
 >>
 >> I can do a bitbake -c menuconfig virtual/kernel and eliminate that
 >> option giving me the kernel I want, but those changes are gone after a
 >> bitbake -c cleansstate ...
 >
 > Have you tried putting
 >
 > # CONFIG_UNION_FS is not set
 >
 > in your defconfig ? That should disable it.
 >
I did try that, but that did not disable it.

Hmmm. It worked here. I'll run another test shortly (I'm working on
3.8-rc1 at the moment).

So after much pain and thrashing about to figure things out, now I see
that in the standard-nocfg.scc file, the unionfs feature is set. This
file is found in the following path: tmp/work/..
../linux/meta/cfg/kernel-cache/ktypes/standard/ directory.

My current burning question is:  Where is does this file come from? It
does not seem to be part of the kernel git repository.  I can changes
this file and affect the kernel build, but again, those changes are
transitory and do not persist after cleaning.

It's from the meta branch of the kernel git repository. Those
are all the fragments that are used to construct and configure
the kernel. Part of the build process makes them available to the
configuration phase.

As something else to try, call your file .cfg and add it to the
SRC_URI the same way you added the defconfig. defconfig's get special
processing, calling it .cfg will simply get your changes added
to the end of the build and they teka precedence. That being said, if
a feature with a Kconfig of the kernel has a "select UNIONFS" then you
can't override it with a config/defconfig option, you need to patch
the kernel.

If you send me your defconfig, I can run some test builds here.

Bruce

Thanks,

Brian

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

Re: [yocto] Magic kernel config option.

On Wed, Jan 2, 2013 at 4:47 PM, Brian Smucker  wrote:

> On 1/2/2013 1:12 PM, Bruce Ashfield wrote:
>
>> On 13-01-02 04:11 PM, Brian Smucker wrote:
>>
>>> On 1/2/2013 10:06 AM, Bruce Ashfield wrote:
>>>  > On 12-12-24 02:59 PM, Brian Smucker wrote:
>>>  >> Hi,
>>>  >>
>>>  >
>>>  > Catching up on email from the holidays. Did you ever get an answer
>>>  > to this ?
>>> Not yet,  resumed my quest today.
>>>
>>>  >> I'm a yocto mostly-newbie, trying to find my way.  I have a custom
>>> layer
>>>  >> that I am using to build a kernel. The layer right now consists of a
>>> few
>>>  >> kernel patches and a defconfig and is based on the standard kernel
>>>  >> otherwise.
>>>  >>
>>>  >> When I do a diff on my defconfig and the bitbake generated .config,
>>> they
>>>  >> are quite similar, but the CONFIG_UNION_FS=y line magically shows up.
>>>  >> I'm wondering where it comes from and how to disable it.
>>>  >
>>>  > CONFIG_UNION_FS is being enabled by the standard kernel (and all
>>>  > kernels that inherit it). Since you are based on that kernel, you
>>>  > get the option enabled.
>>>  >
>>>  >>
>>>  >> I can do a bitbake -c menuconfig virtual/kernel and eliminate that
>>>  >> option giving me the kernel I want, but those changes are gone after
>>> a
>>>  >> bitbake -c cleansstate ...
>>>  >
>>>  > Have you tried putting
>>>  >
>>>  > # CONFIG_UNION_FS is not set
>>>  >
>>>  > in your defconfig ? That should disable it.
>>>  >
>>> I did try that, but that did not disable it.
>>>
>>
>> Hmmm. It worked here. I'll run another test shortly (I'm working on
>> 3.8-rc1 at the moment).
>>
>>
>>> So after much pain and thrashing about to figure things out, now I see
>>> that in the standard-nocfg.scc file, the unionfs feature is set. This
>>> file is found in the following path: tmp/work/..
>>> ../linux/meta/cfg/kernel-**cache/ktypes/standard/ directory.
>>>
>>> My current burning question is:  Where is does this file come from? It
>>> does not seem to be part of the kernel git repository.  I can changes
>>> this file and affect the kernel build, but again, those changes are
>>> transitory and do not persist after cleaning.
>>>
>>
>> It's from the meta branch of the kernel git repository. Those
>> are all the fragments that are used to construct and configure
>> the kernel. Part of the build process makes them available to the
>> configuration phase.
>>
>> As something else to try, call your file .cfg and add it to the
>> SRC_URI the same way you added the defconfig. defconfig's get special
>> processing, calling it .cfg will simply get your changes added
>> to the end of the build and they teka precedence.
>>
>
> Tried your above suggestion, didn't seem to work.
>
> So with a bit of further testing it looks like by the time the defconfig
> and the .cfg are copied into the linux directory, the commented out
> config option: # CONFIG_UNION_FS is not set
> line is totally gone.
>
>
Interesting .. and not really possible if you are talking about the version
in $WORKDIR (i.e
the directory above the linux/ source directory). Those are straight copies
from your
layer, with zero processing. Same with the copy within the linux/meta/cfg/*
directory
structure, they are straight copies and are only processed after being
ordered and
concatenated.


>
>
>  That being said, if
>> a feature with a Kconfig of the kernel has a "select UNIONFS" then you
>> can't override it with a config/defconfig option, you need to patch
>> the kernel.
>>
> Not sure what you are saying here.  If you mean that the unionfs kernel
> option is required by another selected kernel config option, I'm pretty
> sure that's not the case.  I can bitbake -c menuconfig virtual/kernel and
> merely deselect the unionfs option and the kernel is good.
>
>
I can't see your source tree, so it was always an option. I know it
definitely isn't
the case in the linux-yocto tree. But the ability to deselect it in
menuconfig isn't
contingent on something else not selecting it from within another Kconfig.

Again, if you send me your defconfig and local.conf changes (for the BSP),
I'll
run a kernel configuration test and be able to easily tell you what is
happening.

Cheers,

Bruce


>
> Brian
>
>
>
>
>
>  If you send me your defconfig, I can run some test builds here.
>>
>> Bruce
>>
>>
>>
>>
>>
>>> Thanks,
>>>
>>> Brian
>>>
>>>
>>>
>>
> __**_
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.**org/listinfo/yocto<https://lists.yoctoproject.org/listinfo/yocto>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Magic kernel config option.

On 13-01-02 5:43 PM, Brian Smucker wrote:

I take everything back. The entry in the defconfig did the trick. My
problem was that the recipe was grabbing its defconfig from the wrong
directory, costing me much confusion.

So sorry for the false alarm. Thanks again for your help. When you said
the defconfig was a straight copy, the light finally dawned that there
was something else going on.

Aha! That is good news. Thanks for following up.

The silver lining to all this thrashing around for me was the fact that
I do understand the kernel bitbake process much better.

:) Always a good thing.

Bruce

Brian

On 1/2/2013 2:15 PM, Bruce Ashfield wrote:

On Wed, Jan 2, 2013 at 4:47 PM, Brian Smucker mailto:b...@bsmucker.eu.org>> wrote:

On 1/2/2013 1:12 PM, Bruce Ashfield wrote:

On 13-01-02 04:11 PM, Brian Smucker wrote:

On 1/2/2013 10:06 AM, Bruce Ashfield wrote:
> On 12-12-24 02:59 PM, Brian Smucker wrote:
>> Hi,
>>
>
> Catching up on email from the holidays. Did you ever get
an answer
> to this ?
Not yet, resumed my quest today.

>> I'm a yocto mostly-newbie, trying to find my way. I
have a custom
layer
>> that I am using to build a kernel. The layer right now
consists of a
few
>> kernel patches and a defconfig and is based on the
standard kernel
>> otherwise.
>>
>> When I do a diff on my defconfig and the bitbake
generated .config,
they
>> are quite similar, but the CONFIG_UNION_FS=y line
magically shows up.
>> I'm wondering where it comes from and how to disable it.
>
> CONFIG_UNION_FS is being enabled by the standard kernel
(and all
> kernels that inherit it). Since you are based on that
kernel, you
> get the option enabled.
>
>>
>> I can do a bitbake -c menuconfig virtual/kernel and
eliminate that
>> option giving me the kernel I want, but those changes
are gone after a
>> bitbake -c cleansstate ...
>
> Have you tried putting
>
> # CONFIG_UNION_FS is not set
>
> in your defconfig ? That should disable it.
>
I did try that, but that did not disable it.

Hmmm. It worked here. I'll run another test shortly (I'm
working on
3.8-rc1 at the moment).

So after much pain and thrashing about to figure things
out, now I see
that in the standard-nocfg.scc file, the unionfs feature
is set. This
file is found in the following path: tmp/work/..
../linux/meta/cfg/kernel-cache/ktypes/standard/ directory.

My current burning question is: Where is does this file
come from? It
does not seem to be part of the kernel git repository. I
can changes
this file and affect the kernel build, but again, those
changes are
transitory and do not persist after cleaning.

It's from the meta branch of the kernel git repository. Those
are all the fragments that are used to construct and configure
the kernel. Part of the build process makes them available to the
configuration phase.

As something else to try, call your file .cfg and add it
to the
SRC_URI the same way you added the defconfig. defconfig's get
special
processing, calling it .cfg will simply get your changes
added
to the end of the build and they teka precedence.

Tried your above suggestion, didn't seem to work.

So with a bit of further testing it looks like by the time the
defconfig and the .cfg are copied into the linux directory,
the commented out config option: # CONFIG_UNION_FS is not set
line is totally gone.

Interesting .. and not really possible if you are talking about the
version in $WORKDIR (i.e
the directory above the linux/ source directory). Those are straight
copies from your
layer, with zero processing. Same with the copy within the
linux/meta/cfg/* directory
structure, they are straight copies and are only processed after being
ordered and
concatenated.

That being said, if
a feature with a Kconfig of the kernel has a "select UNIONFS"
then you
can't override it with a config/defconfig option, you need to
patch
the kernel.

Not sure what you are saying here. If you mean

Re: [yocto] Build external module against Yocto kernel

2013-01-15 Thread Bruce Ashfield

On 13-01-15 12:54 PM, Patrick Turley wrote:

Thank you for directing me toward that documentation. As it happens, I
have already read that, and it doesn't apply.

The section you mentioned begins with this text:

While it is always preferable to work with sources integrated into
the Linux kernel sources, if you need an external kernel module, the
|hello-mod.bb| recipe is available as a template from which you can
create your own out-of-tree Linux kernel module recipe.

The approach here is to create a recipe that will build a module outside
the kernel tree, but still within the Yocto system.

That isn't what I'm doing.

I have source code for a kernel module that is entirely outside Yocto.
I'm *not* going to write a recipe for this module and integrate it
into a Yocto layer.

Here's a link to instructions on how I would do this in Ubuntu:

http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html

As you can see, Ubuntu (and, of course, other major distributions) have
"kernel-headers" packages that carry all the artifacts one needs to
build a module "after the fact."

Does Yocto have a mechanism for packaging up the necessary artifacts and
making them available *outside* the Yocto build system and long *after*
the Yocto build is finished? Does Yocto recognize the necessity of
this? The best I've been able to do is point my module build process at
something like this:

LINUX_DIR=/home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git

This works but it's messy, unreliable and inconvenient.

So, my question remains: Does Yocto have a graceful way of dealing with
this situation, perhaps like Ubuntu and friends?

There are ways to do this, your requirement is the same as the on-target
module building requirement. Have enough of the kernel source packaged
to build modules on the target, after it has booted.

The trick is packaging things properly to not get binary/target elements
in the SDK/native packages, and to package just enough for the build. But
the issues have been explored and there was a plan. I know that Darren
(cc'd) has looked into this more than I have recently.

I can't locate the bugzilla entries on this at the moment, but I recall
that some parts were still missing, but may be addressed in yocto 1.4,
when I find the bug numbers, I'll have a better idea.

Cheers,

Bruce

On Jan 15, 2013, at 11:09 AM, Brian Lloyd mailto:bll...@familyhonor.net>> wrote:

Or better yet, now that it is past initial, use
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules.
<http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules.%C2%A0>
:)
It worked fine for 1.2 (denzil) for me, though it is written for a
later one.

Brian

On Tue, 2013-01-15 at 11:07 -0600, Brian Lloyd wrote:

Try this in work documentation and let us know how it helps or if
there is something missing that would help more:
http://www.yoctoproject.org/docs/hart/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules

I just did the exact same thing and was happy to discover there is
support in yocto for doing just this.

Brian

On Mon, 2013-01-14 at 23:27 +, Patrick Turley wrote:

I have to build a module from a third-party that has nothing to do with Yocto.

I want to build this module against the kernel Yocto is giving me.

The Make file for this module has a build command like this:

make -C $(LINUX_DIR) M=`pwd` $(ENV) \
EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules

Obviously, this command needs to connect with either the Linux source tree or something
like a "kernel-headers" package.

I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it.
Unfortunately, I don't see a "kernel-header" equivalent in there.

This leads me to imagine I must point this command at some sub-tree within the
Yocto output (probably under tmp/sysroots). And, if I want that tree available
elsewhere, I have to package it up into a tarball and transport it.

Usually, Yocto is way ahead of me on these sorts of things, and there's already
a graceful way to deal with this -- I just haven't figure it out yet.

What am I missing?

___
yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] SDK environment LDFLAGS problem?

2013-01-15 Thread Bruce Ashfield

On 13-01-15 12:59 PM, Patrick Turley wrote:

On Jan 15, 2013, at 11:38 AM, Brian Lloyd mailto:bll...@familyhonor.net>>
wrote:

The kernel is a special case, where the SDK is really designed for
developing user applications (which the kernel is not).

Yes, it's clear to me that, in this one respect, the SDK is unsuitable
for building kernels or kernel modules.

My point is that this is a problem, and it might be reasonable to fix it.

You probably want Jessica or Richard to comment on the architecture /
design of the SDK with respect to kernel elements. The only packaging
for out of tree / non build system builds that I know I've ever looked
into are on target, or staging directory builds of modules.

I found it pretty easy to create a kernel-module-MYMODULE.bbclass file
and build the kernel and module in the OE/Poky build system directly,
and then have it included in the image made for the device.

See
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules
for details.

Thanks for pointing me at that. As it happens, I can't use that method
because I'm not going to create a recipe.

Everyone/Everything has their reasons for the different workflow(s).
(I maintain the ability to build all the boards covered in linux-yocto
without the need for any build system at all, as an example). And all
workflows are definitely valid, but it is expected that the primary
workflow for anything oe/bitbake based would be centered around recipes.

Cheers,

Bruce

Brian

On Tue, 2013-01-15 at 16:52 +, Patrick Turley wrote:

I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it.
Here's an interesting line from the environment setup script:

export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

All these linker options are preceded by "-Wl", which indicates the SDK is
*expecting* them to be given to gcc and then passed on to ld.

If you look at the help for the ld command line, all these options are available, but
with the "-Wl," omitted. In fact, if you use these options exactly as shown
here, ld will complain that they aren't recognized and fail.

So, the SDK is giving me a value of LDFLAGS that *cannot* be used with ld. Of
course, the C compiler driver can link and produce executables, and that
muddies the issue somewhat.

Here's an example where this is causing me real problems…

I'm building an external module against the kernel produced by Yocto. Here's an
extract from my output:

make -C
/home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git
M=`pwd` ARCH=arm
CROSS_COMPILE=/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-
\
EXTRA_CFLAGS="-DUSE_UDEV=1 -DMAX_POOLS=128" modules
.
.
.
LD [M]
/home/pturley/z3-work/z3-centaurus-dm814x_RPS-20120626/ezsdk/component-sources/linuxutils_3_22_00_02/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.ko
/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld:
unrecognized option '-Wl,-O1'

As you can see here, the kernel Make files are interpreting LDFLAGS as
something that *can* be given directly to ld, so they fail.

My questions are:

1) Has anyone else run into this before?

2) If so, how did you resolve it?

3) Since the Yocto kernel build is *not* failing, I infer that it is *not*
using the ld options the SDK gives me. So, the Yocto kernel build has its own
pathway through which it computes its value for LDFLAGS. Why would Yocto use
its own SDK in a way that no user is expected to?

___
yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] Build external module against Yocto kernel

2013-01-15 Thread Bruce Ashfield


On 13-01-15 01:26 PM, Patrick Turley wrote:

On Jan 15, 2013, at 12:00 PM, Bruce Ashfield 
  wrote:


On 13-01-15 12:54 PM, Patrick Turley wrote:

Thank you for directing me toward that documentation. As it happens, I
have already read that, and it doesn't apply.


There are ways to do this, your requirement is the same as the on-target
module building requirement. Have enough of the kernel source packaged
to build modules on the target, after it has booted.


Well, I still want to cross-compile them, but I see your point.


The trick is packaging things properly to not get binary/target elements
in the SDK/native packages, and to package just enough for the build. But
the issues have been explored and there was a plan. I know that Darren
(cc'd) has looked into this more than I have recently.

I can't locate the bugzilla entries on this at the moment, but I recall
that some parts were still missing, but may be addressed in yocto 1.4,
when I find the bug numbers, I'll have a better idea.


As I expected, someone else has already thought about this. This isn't the most 
common approach so it makes sense that it's been a lower priority. The good 
news for me is that I know I'm not missing something, so I can stop looking for 
it.


I finally found the entries that I was recalling earlier. They are:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968

1614 and 2968 are the most interesting for what you are asking.

As you can see the net result of those bugs is that you can get the
right parts of the kernel tree in SDK packages, since they include
dev packages, and with what is currently in kernel-dev .. it should
be enough to build against in the SDK (perhaps with just the LDFLAGS
tweaks mentioned in the other thread). The sources should be part
of the sysroot, and hence available when that is packaged for use
outside of bitbake/yocto.

If you aren't seeing kernel-dev in the SDK image, it might be that
TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something
else is different in the SDK that is being generated in your testing.

I'm only speculating about what might be missing, since I'm not 100%
familiar with the SDK, but perhaps Jessica or others can chime in if
I've led you astray :)

Cheers,

Bruce






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

Re: [yocto] Build external module against Yocto kernel

On 13-01-22 03:28 PM, Patrick Turley wrote:

On Jan 16, 2013, at 11:11 AM, Darren Hart wrote:

On 01/15/2013 10:38 AM, Bruce Ashfield wrote:

I finally found the entries that I was recalling earlier. They are:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968

1614 and 2968 are the most interesting for what you are asking.

As you can see the net result of those bugs is that you can get the
right parts of the kernel tree in SDK packages, since they include
dev packages, and with what is currently in kernel-dev .. it should
be enough to build against in the SDK (perhaps with just the LDFLAGS
tweaks mentioned in the other thread). The sources should be part
of the sysroot, and hence available when that is packaged for use
outside of bitbake/yocto.

If you aren't seeing kernel-dev in the SDK image, it might be that
TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something
else is different in the SDK that is being generated in your testing.

I'm only speculating about what might be missing, since I'm not 100%
familiar with the SDK, but perhaps Jessica or others can chime in if
I've led you astray :)

You have *not* led me astray. A fundamental problem was that I didn't comprehend the
distinction/correspondence between "target image" recipes and "SDK image"
recipes. I believe I get that now.

We've created a target image recipe, and an SDK image recipe that "require's"
the former (this is conventional, I believe). The SDK image recipe adds all the
development packages and, yes, it includes kernel-dev. So, when I install my SDK now, I
certainly *do* get all the kernel header files. As you know, I do *not* get the hostprogs.

As I described in an earlier post, I am currently reaching into the "tmp" directory,
pulling out the kernel work directory, and making it directly available to my external build
process. This solves my problem because the work directory contains all the header files I need
*and* the hostprogs. Of course, it's "bad" because it's not an intended way to use the
build artifacts, and it's awkward to distribute.

With the recent improvement, I can now get the kernel header files packaged in
the SDK. That's good because it's an intended mechanism and it's easy to
distribute.

With regard to:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614

This seems a reasonable solution to the problem of building modules on the
target, given the difficulties of dealing with executables. I'm not building
modules on the target (I'm cross-compiling them), but this seems to apply
anyway. It adds an extra step to SDK installation, but that's the least of our
problems.

One problem I ran into … When I tried to execute "make scripts," I got a whole bunch of
config questions that I *think* should have been answered with a .config file or something. Should
I have copied out the .config file from the kernel work directory into the SDK installation before
I ran that? Is that the "best" way to get around all the questions?

Interesting. I haven't seen this myself, so just a couple of quick
questions:

- without the .config, did you still get a working set of hostprogs, and
only had to suffer the warnings ?

- If the answer is yes, then the .config really doesn't matter for this
and the approach of grabbing a .config should work fine or even
having a dummy defconfig available with enough to keep the build
happy.

Definitely sounds like something we can address and it's worth putting into
bugzilla so it doesn't get lost.

Bruce

Patrick, please keep us posted if this continues to not work for you. I
will open a bug to include a section about this in the kernel
development manual.

It's very *nearly* working for me now. See my question above.

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

Re: [linux-yocto] a new kernel repo branch for emgd 1.16 driver


On 13-01-21 06:19 PM, Kamble, Nitin A wrote:

Hi Bruce,

  I have created a branch for emgd-1.16 kernel driver for the v3.4
kernel repo over here.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=nitin/emgd-1.16

It consists of mainly following 2 commits on top of the standard/base
branch.



Something is up with the contrib repository. I'm getting hundreds of
megs of data transfer while fetching this change, and being throttled,
so it is taking some time.

We should get the kernel contrib repo updated to the latest 3.8 mainline
kernel and drop the 2.6.37 name. I'll take care of starting that process.

Bruce


Can you pull this branch in the v3.4 YP kernel repository so that BSPs
can start using

emgd 1.16 driver for graphics?

Thanks,

Nitin

commit 39fa5392e05b98a1bd107a5c77f06679adc917e6

Author: Nitin A Kamble 

Date:   Fri Jan 18 21:02:20 2013 -0800

 emgd: enable building within the kernel sources

 Modify the build mechanism so that emgd can be configured and built

 as a feature of the kernel.

 Signed-off-by: Nitin A Kamble 

commit 99ae3010eeb048bd6fd63b554e2e3c6fddd80afa

Author: Nitin A Kamble 

Date:   Fri Jan 18 19:51:03 2013 -0800

 emgd: add emgd 1.16 driver sources

 This is starting-point code that subsequent patches will modify.
This is

 a virgin copy of the code from the emgd 1.16 driver.

 This code is coming from

  IEMGD_HEAD_Linux/common/drm/emgd_drm.tgz

 which is a piece from the 'Linux Tar Ball' release of EMGD 1.16
downloaded

 from here:


https://edc.intel.com/App_Shared/Downloads/LIN_IEMGD_1_16_GOLD_3228.tgz

 Signed-off-by: Nitin A Kamble 



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

Re: [linux-yocto] [PATCH 0/1] meta: add emgd-1.16 driver support


On 13-01-22 03:38 PM, nitin.a.kam...@intel.com wrote:

From: Nitin A Kamble 

Here is a commit which adds an scc file for emgd-1.16 feature. It
depends on the emgd-1.16 branch in the kernel repo, for which a pull
request is already sent.

This commit keeps the emgd-1.14 driver support in the repo intact.



merged. and pushed. SRCREV updates to follow, but you can test it locally
before I do the updates.

Bruce


Thanks,
Nitin

The following changes since commit c0b3904d60830e24b3930b0fa606a48b2758d979:

   meta: add config fragment for gma600 graphics driver (2013-01-18 23:07:15 
-0500)

are available in the git repository at:
   git://git.yoctoproject.org/linux-yocto-2.6.37-contrib nitin/meta
   
http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=nitin/meta

Nitin A Kamble (1):
   meta: add a kernel feature for drm-emgd-1.16 driver

  .../features/drm-emgd/drm-emgd-1.16.scc|2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
  create mode 100644 meta/cfg/kernel-cache/features/drm-emgd/drm-emgd-1.16.scc



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

Re: [linux-yocto] a new kernel repo branch for emgd 1.16 driver


On 13-01-21 06:19 PM, Kamble, Nitin A wrote:

Hi Bruce,

  I have created a branch for emgd-1.16 kernel driver for the v3.4
kernel repo over here.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=nitin/emgd-1.16

It consists of mainly following 2 commits on top of the standard/base
branch.


merged and pushed. the emgd-1.16 branch is now available.

Bruce



Can you pull this branch in the v3.4 YP kernel repository so that BSPs
can start using

emgd 1.16 driver for graphics?

Thanks,

Nitin

commit 39fa5392e05b98a1bd107a5c77f06679adc917e6

Author: Nitin A Kamble 

Date:   Fri Jan 18 21:02:20 2013 -0800

 emgd: enable building within the kernel sources

 Modify the build mechanism so that emgd can be configured and built

 as a feature of the kernel.

 Signed-off-by: Nitin A Kamble 

commit 99ae3010eeb048bd6fd63b554e2e3c6fddd80afa

Author: Nitin A Kamble 

Date:   Fri Jan 18 19:51:03 2013 -0800

 emgd: add emgd 1.16 driver sources

 This is starting-point code that subsequent patches will modify.
This is

 a virgin copy of the code from the emgd 1.16 driver.

 This code is coming from

  IEMGD_HEAD_Linux/common/drm/emgd_drm.tgz

 which is a piece from the 'Linux Tar Ball' release of EMGD 1.16
downloaded

 from here:


https://edc.intel.com/App_Shared/Downloads/LIN_IEMGD_1_16_GOLD_3228.tgz

 Signed-off-by: Nitin A Kamble 



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

Re: [linux-yocto] [PATCH 0/1] meta: add emgd-1.16 driver support


On 13-01-22 03:38 PM, nitin.a.kam...@intel.com wrote:

From: Nitin A Kamble 

Here is a commit which adds an scc file for emgd-1.16 feature. It
depends on the emgd-1.16 branch in the kernel repo, for which a pull
request is already sent.

This commit keeps the emgd-1.14 driver support in the repo intact.



Ack'd. I'll merge this shortly, once I get emgd pulled in .. which I'm
doing now, but being throttled by the servers.

Bruce


Thanks,
Nitin

The following changes since commit c0b3904d60830e24b3930b0fa606a48b2758d979:

   meta: add config fragment for gma600 graphics driver (2013-01-18 23:07:15 
-0500)

are available in the git repository at:
   git://git.yoctoproject.org/linux-yocto-2.6.37-contrib nitin/meta
   
http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=nitin/meta

Nitin A Kamble (1):
   meta: add a kernel feature for drm-emgd-1.16 driver

  .../features/drm-emgd/drm-emgd-1.16.scc|2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
  create mode 100644 meta/cfg/kernel-cache/features/drm-emgd/drm-emgd-1.16.scc



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

Re: [yocto] Build external module against Yocto kernel


On 13-01-22 9:26 PM, Patrick Turley wrote:

On Jan 22, 2013, at 2:34 PM, Bruce Ashfield  
wrote:

On 13-01-22 03:28 PM, Patrick Turley wrote:

One problem I ran into … When I tried to execute "make scripts," I got a whole bunch of 
config questions that I *think* should have been answered with a .config file or something. Should 
I have copied out the .config file from the kernel work directory into the SDK installation before 
I ran that? Is that the "best" way to get around all the questions?



Interesting. I haven't seen this myself, so just a couple of quick
questions:

  - without the .config, did you still get a working set of hostprogs, and
only had to suffer the warnings ?

  - If the answer is yes, then the .config really doesn't matter for this
and the approach of grabbing a .config should work fine or even
having a dummy defconfig available with enough to keep the build
happy.

Definitely sounds like something we can address and it's worth putting into
bugzilla so it doesn't get lost.


Below, please find a transcript of the commands I executed.

You'll see that I installed the SDK, tried to "make scripts," and then got 
attacked with a storm of config questions. I cut off the transcript at the second 
question, but there are dozens that follow.

There *is* a .config file in the SDK directory, and it is identical to the one 
in our kernel build directory:

/home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git

Unfortunately, I'm still something of a n00b when it comes to building the 
kernel. I suspect *most* of these questions are irrelevant to hostprogs, but I 
can't say that *all* of them are.

If I just hold down the "Enter" key, I believe all the defaults are taken, and 
I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to 
my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)



This will be fine, the defaults will work. The kernel build infrastructure
is picking up what it thinks is a change source -> to config and trying
to reconcile the differences.

If you throw in a 'make oldconfig' before you do the 'make scripts', does
that quiet things down a bit ?

Cheers,

Bruce




$ pwd
/home/pturley/yocto-mpu-build/tmp/deploy/sdk

$ ls
poky-eglibc-x86_64-arm-toolchain-1.3.sh

$ sudo ./poky-eglibc-x86_64-arm-toolchain-1.3.sh
Enter target directory for SDK (default: /opt/poky/1.3):
You are about to install the SDK to "/opt/poky/1.3". Proceed[Y/n]?
Extracting SDK...done
Setting it up...done
SDK has been successfully set up and is ready to be used.

$ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel

$ ls -a
.  firmware   lib scripts
.. fs MAINTAINERS security
arch   includeMakefilesound
block  init   mm  System.map-2.6.37
.configipcModule.symvers  tools
COPYINGKbuild net uImage
CREDITSKconfigpatches usr
crypto kernel README  virt
Documentation  kernel-abiversion  REPORTING-BUGS
driverskernel-image-name  samples

$ sudo make scripts
   HOSTCC  scripts/basic/fixdep
   HOSTCC  scripts/basic/docproc
   HOSTCC  scripts/kconfig/conf.o
   HOSTCC  scripts/kconfig/kxgettext.o
   SHIPPED scripts/kconfig/zconf.tab.c
   SHIPPED scripts/kconfig/lex.zconf.c
   SHIPPED scripts/kconfig/zconf.hash.c
   HOSTCC  scripts/kconfig/zconf.tab.o
   HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
Cross-compiler tool prefix (CROSS_COMPILE) []
Local version - append to kernel release (LOCALVERSION) []
Automatically append version information to the version string 
(LOCALVERSION_AUTO) [N/y/?] n
Kernel compression mode

1. Gzip (KERNEL_GZIP)

   2. Bzip2 (KERNEL_BZIP2) (NEW)
   3. LZMA (KERNEL_LZMA)
   4. LZO (KERNEL_LZO)
choice[1-4?]:
Support for paging of anonymous memory (swap) (SWAP) [N/y/?] n
System V IPC (SYSVIPC) [Y/n/?] y
POSIX Message Queues (POSIX_MQUEUE) [Y/n/?] y
BSD Process Accounting (BSD_PROCESS_ACCT) [Y/n/?] y
   BSD Process Accounting version 3 file format (BSD_PROCESS_ACCT_V3) [Y/n/?] y
Export task/process statistics through netlink (EXPERIMENTAL) (TASKSTATS) 
[Y/n/?] y
   Enable per-task delay accounting (EXPERIMENTAL) (TASK_DELAY_ACCT) [Y/n/?] y
   Enable extended accounting over taskstats (EXPERIMENTAL) (TASK_XACCT) 
[Y/n/?] y
 Enable per-task storage I/O accounting (EXPERIMENTAL) (TASK_IO_ACCOUNTING) 
[Y/n/?] y
Auditing support (AUDIT) [N/y/?] n
Kernel .config support (IKCONFIG) [Y/n/m/?] y
   Enable access to .con

Re: [yocto] Build external module against Yocto kernel


On 13-01-23 12:14 AM, Patrick Turley wrote:

On Jan 22, 2013, at 10:43 PM, Bruce Ashfield  
wrote:

On 13-01-22 9:26 PM, Patrick Turley wrote:

If I just hold down the "Enter" key, I believe all the defaults are taken, and 
I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to 
my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)


This will be fine, the defaults will work. The kernel build infrastructure
is picking up what it thinks is a change source ->  to config and trying
to reconcile the differences.

If you throw in a 'make oldconfig' before you do the 'make scripts', does
that quiet things down a bit ?


No -- "make oldconfig" caused the very same questions (see below).


Aha. of course (now that I think about it), the build was simply triggering
old config automatically.

silentoldconfig is what I really should have typed :)

Bruce



---

$ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel

$ ls
arch   drivers   Kbuild MAINTAINERS README  
System.map-2.6.37
block  firmware  KconfigMakefileREPORTING-BUGS  
tools
COPYINGfskernel mm  samples 
uImage
CREDITSinclude   kernel-abiversion  Module.symvers  scripts usr
crypto init  kernel-image-name  net securityvirt
Documentation  ipc   libpatches sound

$ sudo make oldconfig
   HOSTCC  scripts/basic/fixdep
   HOSTCC  scripts/basic/docproc
   HOSTCC  scripts/kconfig/conf.o
   HOSTCC  scripts/kconfig/kxgettext.o
   SHIPPED scripts/kconfig/zconf.tab.c
   SHIPPED scripts/kconfig/lex.zconf.c
   SHIPPED scripts/kconfig/zconf.hash.c
   HOSTCC  scripts/kconfig/zconf.tab.o
   HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
*
* Restart config...
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
Cross-compiler tool prefix (CROSS_COMPILE) []
Local version - append to kernel release (LOCALVERSION) []
Automatically append version information to the version string 
(LOCALVERSION_AUTO) [N/y/?] n
Kernel compression mode

1. Gzip (KERNEL_GZIP)

   2. Bzip2 (KERNEL_BZIP2) (NEW)
   3. LZMA (KERNEL_LZMA)
   4. LZO (KERNEL_LZO)
choice[1-4?]:



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

Re: [yocto] Build external module against Yocto kernel

2013-01-23 Thread Bruce Ashfield


On 13-01-23 12:34 AM, Patrick Turley wrote:


On Jan 22, 2013, at 11:17 PM, Bruce Ashfield  
wrote:


On 13-01-23 12:14 AM, Patrick Turley wrote:

On Jan 22, 2013, at 10:43 PM, Bruce Ashfield  
wrote:

On 13-01-22 9:26 PM, Patrick Turley wrote:

If I just hold down the "Enter" key, I believe all the defaults are taken, and 
I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to 
my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)


This will be fine, the defaults will work. The kernel build infrastructure
is picking up what it thinks is a change source ->  to config and trying
to reconcile the differences.

If you throw in a 'make oldconfig' before you do the 'make scripts', does
that quiet things down a bit ?


No -- "make oldconfig" caused the very same questions (see below).


Aha. of course (now that I think about it), the build was simply triggering
old config automatically.

silentoldconfig is what I really should have typed :)



Nope - still doesn't work.


Argh. I'll have to just run the commands myself and stop spamming the
list with ideas :) It's just a matter of making lkc accept the defaults
(i.e. you could also use allyesconfig, or allnoconfig) or even better
not trigger that config check at all.

Cheers,

Bruce





$ sudo make silentoldconfig
   HOSTCC  scripts/basic/fixdep
   HOSTCC  scripts/basic/docproc
   HOSTCC  scripts/kconfig/conf.o
   HOSTCC  scripts/kconfig/kxgettext.o
   SHIPPED scripts/kconfig/zconf.tab.c
   SHIPPED scripts/kconfig/lex.zconf.c
   SHIPPED scripts/kconfig/zconf.hash.c
   HOSTCC  scripts/kconfig/zconf.tab.o
   HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
Cross-compiler tool prefix (CROSS_COMPILE) []
Local version - append to kernel release (LOCALVERSION) []
Automatically append version information to the version string 
(LOCALVERSION_AUTO) [N/y/?] n
Kernel compression mode

1. Gzip (KERNEL_GZIP)

   2. Bzip2 (KERNEL_BZIP2) (NEW)
   3. LZMA (KERNEL_LZMA)
   4. LZO (KERNEL_LZO)
choice[1-4?]:



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

Re: [yocto] do_package task of the kernel takes extremely long

2013-01-24 Thread Bruce Ashfield

On Thu, Jan 24, 2013 at 6:29 AM, Daniel Kenji Morgan <
daniel.kenji.mor...@gmail.com> wrote:

> Hello,
>
> I'm still fairly new to Yocto, and having some trouble with kernel
> packaging taking an extremely long time.
> I will try and keep details as simple as possible to explain my situation.
>
> I am building images for the machine "imx6qsabrelite" in the
> "meta-fsl-arm" BSP layer using Poky 1.3 (danny).
> To make it easier to test out changes to the linux kernel source, I have
> a copy of the source in a local subversion repository, which is checked
> out to a local working copy.
>

kernel source in subversion, is obviously not an optimal configuration,
see below.


>
> I have created a kernel recipe to inherit "externalsrc" and set "S" to
> the local working copy directory.
> I have added a "configure_prepend" task to stage the build directory.
> I use "bitbake core-image-minimal" to build the image.
>
> Here is what I have found from checking the "do_package" task duration
> of the kernel in the build stats:
>
> 1. Using a local working copy directory (subversion 1.6), the duration
> exceeds 4000 seconds.
>
> 2. Using a local working copy directory (subversion 1.7), the duration
> takes approximately 800 seconds.
>
> 3. Using the original kernel recipe which obtains the kernel source off
> a Git repository from the internet, the duration takes approximately 400
> seconds.
>
>
As for the fetch, it is a one time cost, incremental updates to the tree are
simple and fast, so it can't and shouldn't be counted as a constant
overhead.
The development advantages of working out of a git repository based kernel
are significant (in terms of efficiency and diagnostics, etc) and shouldn't
be
discounted.

But as for some of the other comments, they are known and tracked by
several items in the bugtracker to address these issues:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=3517
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2686

as well as other bitbake/build system generic items (that I can't find at
the moment).

I already have some items in progress for 3517, and they'll be out shortly
for
inclusion in yocto 1.4.

Cheers,

Bruce



> Checking the "do_package" task, it seems like all directories and
> sub-directorys of the source are checked recursively in the process.
> I think it's safe to say that the number of subversion administrative
> directorys is affecting the "do_package" task duration.
>
> Is there any way to make the "do_package" task ignore .svn
> administrative directories?
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Build external module against Yocto kernel

2013-01-24 Thread Bruce Ashfield

On 13-01-24 02:58 PM, John Mehaffey wrote:

On Wed, Jan 23, 2013 at 7:17 AM, Patrick Turley
mailto:patricktur...@gamestop.com>> wrote:

On Jan 23, 2013, at 7:48 AM, Bruce Ashfield
mailto:bruce.ashfi...@windriver.com>>
  wrote:
 > On 13-01-23 12:34 AM, Patrick Turley wrote:
 >>
 >> On Jan 22, 2013, at 11:17 PM, Bruce Ashfield
mailto:bruce.ashfi...@windriver.com>>
wrote:
 >>
 >>> On 13-01-23 12:14 AM, Patrick Turley wrote:
 >>>> On Jan 22, 2013, at 10:43 PM, Bruce
Ashfieldmailto:bruce.ashfi...@windriver.com>>  wrote:
 >>>>> On 13-01-22 9:26 PM, Patrick Turley wrote:
 >
 > Argh. I'll have to just run the commands myself and stop spamming the
 > list with ideas :) It's just a matter of making lkc accept the
defaults
 > (i.e. you could also use allyesconfig, or allnoconfig) or even better
 > not trigger that config check at all.

You're very kind to have spent so much time on my problem already. I
look forward to hearing back.

It sounds like you are building for a board with an ARCH other than i386
(the default).

Ah yes .. it can definitely be this. I always have an ARCH on the
command line when I invoke the oldconfig.

In theory we shouldn't need the oldconfig at all either, just the arch
on the build line with making the scripts.

Cheers,

Bruce

You need to either run it in a devshell or use "make ARCH= oldconfig".

-mehaf

___
yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto

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

[yocto] FYI: new linux-yocto contrib option

2013-01-24 Thread Bruce Ashfield


Hi all,

We now have a more up to date kernel repository for contributions to
the linux-yocto kernel or linux-yocto meta data (configs, patches).

(Michael indulged me and help set this up really quickly, so he gets
all the credit for the work on this).

Enough rambling, and onto the link:

  git://git.yoctoproject.org/linux-yocto-contrib
  http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/

This is just like the old contrib repository (linux-yocto-2.6.37-contrib),
except that it is up to date with the mainline kernel, and doesn't
have a version number stuck in the middle. There's a cron job that
will ensure that it stays up to date, saving bandwith on pushes
and pulls from the repo.

Anyone sending kernel pull requests should switch to using this repository.

We'll hide the old linux-yocto-2.6.37-contrib repository from the main
cgit page to reduce clutter, but the repo will still be present and
accessible.

Cheers,

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

Re: [yocto] SRC_URI scope and kernel fragments in non-yocto kernel recipes

2013-01-28 Thread Bruce Ashfield


On 13-01-28 12:47 PM, stephen.lawre...@renesas.com wrote:

Hi,

I'm wondering if SRC_URI has some limitations as to where it will be
expanded.

I have a bsp with 2 kernel recipes. One for mainline, the other for the
yocto kernel.
The kernel may be used with some middleware that requires some further
patches and kernel configuration.
I hoped to isolate these into a separate file that could be easily
commented in or out from the kernel bb file.
This file would have a SRC_URI += for the patches and a kernel fragment
.cfg, e.g:
# Add some m/w patches
SRC_URI += " file://some.patch"

# Add some m/w kernel req
SRC_URI += " file://mw-kernel-config.cfg"

I first tried following the bsp tooling example and placed this within a
scc file but the SRC_URI wasn't picked up.
I most recently tried placing it in an include but had the same result.

I finally tried adding two SRC_URIs directly into the kernel recipe.
The one listing the patches was applied. The one listing the kernel
fragment was not.

I suspect the kernel fragment issue is down to the fact that a yocto
kernel recipe is not being used,
i.e. it relies on the yocto kernel meta data mechanism?


I can confirm this part. Your recipe must inherit kernel-yocto bbclass
if you want the fragment to be applied to the base config. But you can
use linux-yocto-custom, to build your mainline recipe AND have the
fragment work.



Why is the SRC_URI containing the additional patches applied when
referenced directly in the bb file,
but not when referenced in an include or scc file?


Keeping the question isolated to just the patch on the SRC_URI is a
good idea to make sure we are talking about the simplest case.

Which type of recipe isn't having the patch applied, the mainline one ?
The linux-yocto one, or both ?

Bruce



I suspect this has come up before, but I can't find anything in the doc or
list archives.

I'm using the poky master branch rev
93c04c16e45a3c8f60f8ffc0b26a78c24bda71da

Thanks for any suggestions. My aim is to get to a point I can upstream the
bsp.

Cheers

Steve


Stephen  Lawrence, Senior Engineer, Systems, Linux/SDK, Renesas Electronics 
Europe Ltd, Dukes Meadow, Millboard Road, SL8 5FH, Bourne End, UK,  Phone:+44 
1628 651-789, Fax:+44 1628 651-804, mailto:stephen.lawre...@renesas.com, 
http://www.renesas.eu

This message is intended only for the use of the addressee(s) and may contain 
confidential and/or legally privileged information. If you are not the intended 
recipient, you are hereby notified that any dissemination of this email 
(including any attachments thereto) is strictly prohibited. If you have 
received this email in error, please notify the sender immediately by telephone 
or email  and permanently destroy the original without making any copy. Please 
note that any material and advice from this mail is provided free of charge and 
shall be used as an example for demonstration purposes only.
RENESAS MAKES NO WARRANTIES THAT THE USAGE OF INFORMATION OR ADVICE FROM THIS 
E-MAIL WILL NOT INFRINGE ANY INTELLECTUAL PROPERTY RIGHTS (E.G. PATENTS, 
COPYRIGHTS). RENESAS CANNOT GUARANTEE BUG FREE OPERATION AND THE RECIPIENT WILL 
USE AND/OR DISTRIBUTE IT ONLY AT HIS OWN RISK. IN NO EVENT SHALL RENESAS BE 
LIABLE FOR ANY DAMAGE.  The communication with Renesas Electronics Europe Ltd 
does not amend any written agreement in place.

Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK.  Registered in England & Wales under Registered 
No. 04586709.
___
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] SRC_URI scope and kernel fragments in non-yocto kernel recipes

2013-01-28 Thread Bruce Ashfield


On 13-01-28 01:34 PM, stephen.lawre...@renesas.com wrote:

Bruce Ashfield  wrote on 28/01/2013
18:01:57:
[snip]

I suspect the kernel fragment issue is down to the fact that a yocto
kernel recipe is not being used,
i.e. it relies on the yocto kernel meta data mechanism?


I can confirm this part. Your recipe must inherit kernel-yocto bbclass
if you want the fragment to be applied to the base config. But you can
use linux-yocto-custom, to build your mainline recipe AND have the
fragment work.


ok sounds hopeful. I'm not familiar with linux-yocto-custom.
I'll have a dig in the meta tree and google.


You'll fine a reference recipe in meta-skeleton in the yocto/oe-core
tree.





Why is the SRC_URI containing the additional patches applied when
referenced directly in the bb file,
but not when referenced in an include or scc file?


Keeping the question isolated to just the patch on the SRC_URI is a
good idea to make sure we are talking about the simplest case.

Which type of recipe isn't having the patch applied, the mainline one ?
The linux-yocto one, or both ?


Currently I've only tried the mainline one.

I would need to revert and try again tomorrow, but when the SRC_URI
containing the additional patches was in an include, I recall the patch
files were not listed in the build prep logs such as do_fetch.
Not surprising in that case, but they were also not copied over into the
git tree of the work area.

So it was as if the include was parsed but the SRC_URI was ignored.


I'll try a test here and see what happens in the mean time.

Bruce




Regards

Steve


Stephen  Lawrence, Senior Engineer, Systems, Linux/SDK, Renesas Electronics 
Europe Ltd, Dukes Meadow, Millboard Road, SL8 5FH, Bourne End, UK,  Phone:+44 
1628 651-789, Fax:+44 1628 651-804, mailto:stephen.lawre...@renesas.com, 
http://www.renesas.eu

This message is intended only for the use of the addressee(s) and may contain 
confidential and/or legally privileged information. If you are not the intended 
recipient, you are hereby notified that any dissemination of this email 
(including any attachments thereto) is strictly prohibited. If you have 
received this email in error, please notify the sender immediately by telephone 
or email  and permanently destroy the original without making any copy. Please 
note that any material and advice from this mail is provided free of charge and 
shall be used as an example for demonstration purposes only.
RENESAS MAKES NO WARRANTIES THAT THE USAGE OF INFORMATION OR ADVICE FROM THIS 
E-MAIL WILL NOT INFRINGE ANY INTELLECTUAL PROPERTY RIGHTS (E.G. PATENTS, 
COPYRIGHTS). RENESAS CANNOT GUARANTEE BUG FREE OPERATION AND THE RECIPIENT WILL 
USE AND/OR DISTRIBUTE IT ONLY AT HIS OWN RISK. IN NO EVENT SHALL RENESAS BE 
LIABLE FOR ANY DAMAGE.  The communication with Renesas Electronics Europe Ltd 
does not amend any written agreement in place.

Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK.  Registered in England & Wales under Registered 
No. 04586709.



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

Re: [yocto] SRC_URI scope and kernel fragments in non-yocto kernel recipes

2013-01-28 Thread Bruce Ashfield


On 13-01-28 01:35 PM, Bruce Ashfield wrote:

On 13-01-28 01:34 PM, stephen.lawre...@renesas.com wrote:

Bruce Ashfield  wrote on 28/01/2013
18:01:57:
[snip]

I suspect the kernel fragment issue is down to the fact that a yocto
kernel recipe is not being used,
i.e. it relies on the yocto kernel meta data mechanism?


I can confirm this part. Your recipe must inherit kernel-yocto bbclass
if you want the fragment to be applied to the base config. But you can
use linux-yocto-custom, to build your mainline recipe AND have the
fragment work.


ok sounds hopeful. I'm not familiar with linux-yocto-custom.
I'll have a dig in the meta tree and google.


You'll fine a reference recipe in meta-skeleton in the yocto/oe-core
tree.





Why is the SRC_URI containing the additional patches applied when
referenced directly in the bb file,
but not when referenced in an include or scc file?


Keeping the question isolated to just the patch on the SRC_URI is a
good idea to make sure we are talking about the simplest case.

Which type of recipe isn't having the patch applied, the mainline one ?
The linux-yocto one, or both ?


Currently I've only tried the mainline one.

I would need to revert and try again tomorrow, but when the SRC_URI
containing the additional patches was in an include, I recall the patch
files were not listed in the build prep logs such as do_fetch.
Not surprising in that case, but they were also not copied over into the
git tree of the work area.

So it was as if the include was parsed but the SRC_URI was ignored.


I'll try a test here and see what happens in the mean time.


I can confirm that in my simple test, I can have a kernel recipe
linux-.bbappend in a layer that includes .inc file,
who's only contents are:

SRC_URI += "file://0001-makefile-add-comment.patch"

And I get the patch applied to the tree. Am I understanding correctly ?
or is that different from what you are trying to do?

Bruce




Bruce




Regards

Steve


Stephen  Lawrence, Senior Engineer, Systems, Linux/SDK, Renesas
Electronics Europe Ltd, Dukes Meadow, Millboard Road, SL8 5FH, Bourne
End, UK,  Phone:+44 1628 651-789, Fax:+44 1628 651-804,
mailto:stephen.lawre...@renesas.com, http://www.renesas.eu

This message is intended only for the use of the addressee(s) and may
contain confidential and/or legally privileged information. If you are
not the intended recipient, you are hereby notified that any
dissemination of this email (including any attachments thereto) is
strictly prohibited. If you have received this email in error, please
notify the sender immediately by telephone or email  and permanently
destroy the original without making any copy. Please note that any
material and advice from this mail is provided free of charge and
shall be used as an example for demonstration purposes only.
RENESAS MAKES NO WARRANTIES THAT THE USAGE OF INFORMATION OR ADVICE
FROM THIS E-MAIL WILL NOT INFRINGE ANY INTELLECTUAL PROPERTY RIGHTS
(E.G. PATENTS, COPYRIGHTS). RENESAS CANNOT GUARANTEE BUG FREE
OPERATION AND THE RECIPIENT WILL USE AND/OR DISTRIBUTE IT ONLY AT HIS
OWN RISK. IN NO EVENT SHALL RENESAS BE LIABLE FOR ANY DAMAGE.  The
communication with Renesas Electronics Europe Ltd does not amend any
written agreement in place.

Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne
End, Buckinghamshire, SL8 5FH, UK.  Registered in England & Wales
under Registered No. 04586709.



___
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] SRC_URI scope and kernel fragments in non-yocto kernel recipes

2013-01-29 Thread Bruce Ashfield


On 13-01-29 06:24 AM, stephen.lawre...@renesas.com wrote:

Bruce Ashfield  wrote on 28/01/2013
18:56:02:


Why is the SRC_URI containing the additional patches applied when
referenced directly in the bb file,
but not when referenced in an include or scc file?


Keeping the question isolated to just the patch on the SRC_URI is a
good idea to make sure we are talking about the simplest case.

Which type of recipe isn't having the patch applied, the mainline

one ?

The linux-yocto one, or both ?


Currently I've only tried the mainline one.

I would need to revert and try again tomorrow, but when the SRC_URI
containing the additional patches was in an include, I recall the

patch

files were not listed in the build prep logs such as do_fetch.
Not surprising in that case, but they were also not copied over into

the

git tree of the work area.

So it was as if the include was parsed but the SRC_URI was ignored.


I'll try a test here and see what happens in the mean time.


I can confirm that in my simple test, I can have a kernel recipe
linux-.bbappend in a layer that includes .inc file,
who's only contents are:

SRC_URI += "file://0001-makefile-add-comment.patch"

And I get the patch applied to the tree. Am I understanding correctly ?
or is that different from what you are trying to do?



Thank you for taking the time Bruce. Yes, that is essentially what I was
trying to do. Two SRC_URI += in a .inc, one listing the patches, the other
just listing a cfg file. The only difference is that as it was a mainline
kernel recipe I included it from a .bb, not a .bbappend. The .bb inherits
'kernel'.

I originally had the additional patches in a subdirectory to separate them
out, but to eliminate file paths as a cause, I moved them in with the main
patches with no luck. I'll revert the changes and try again so I can
provide some specific log results.


Sounds good. I (un)fortunately had my tests work here, so I'll wait for
logs and try and help out then!

Cheers,

Bruce



Steve


Stephen  Lawrence, Senior Engineer, Systems, Linux/SDK, Renesas Electronics 
Europe Ltd, Dukes Meadow, Millboard Road, SL8 5FH, Bourne End, UK,  Phone:+44 
1628 651-789, Fax:+44 1628 651-804, mailto:stephen.lawre...@renesas.com, 
http://www.renesas.eu

This message is intended only for the use of the addressee(s) and may contain 
confidential and/or legally privileged information. If you are not the intended 
recipient, you are hereby notified that any dissemination of this email 
(including any attachments thereto) is strictly prohibited. If you have 
received this email in error, please notify the sender immediately by telephone 
or email  and permanently destroy the original without making any copy. Please 
note that any material and advice from this mail is provided free of charge and 
shall be used as an example for demonstration purposes only.
RENESAS MAKES NO WARRANTIES THAT THE USAGE OF INFORMATION OR ADVICE FROM THIS 
E-MAIL WILL NOT INFRINGE ANY INTELLECTUAL PROPERTY RIGHTS (E.G. PATENTS, 
COPYRIGHTS). RENESAS CANNOT GUARANTEE BUG FREE OPERATION AND THE RECIPIENT WILL 
USE AND/OR DISTRIBUTE IT ONLY AT HIS OWN RISK. IN NO EVENT SHALL RENESAS BE 
LIABLE FOR ANY DAMAGE.  The communication with Renesas Electronics Europe Ltd 
does not amend any written agreement in place.

Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK.  Registered in England & Wales under Registered 
No. 04586709.



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

Re: [yocto] PREFERRED_PROVIDER in image recipes

2013-01-29 Thread Bruce Ashfield


On 13-01-28 11:16 AM, Daniel Kenji Morgan wrote:

Sorry to bring up an old post, but I haven't managed to find information in the 
mail archives and bugzilla on how the issue stands as of today.

The post I am referring to is as follows:
https://lists.yoctoproject.org/pipermail/yocto/2011-December/005951.html

I have two separate recipes for the same kernel version.
One with a kernel configuration with various options enabled to assist 
debugging.
The other with said options disabled.

Ideally, I would like to be able to set PREFERRED_PROVIDER to the kernel 
recipes in custom image recipes for the same machine.
This is something that is being discussed in the referred post above.
Does anyone know if such functionality is being pursued in a future release of 
Poky?


I haven't heard of anything myself, local.conf, distro configs or
separate machines are how this is still currently being done.

We have quite a bit of flexibility in the way that kernel configs
can be stacked and used since the thread that you noticed, so there
are options in that area to pursue as well. There's been planning
around image creation and construction lately, that could also end
up helping a use case such as this down the road.

As to whether or not work is planned in the areas of images and
preferred providers, Richard would know.

Cheers,

Bruce



___
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] Build external module against Yocto kernel

2013-01-31 Thread Bruce Ashfield


On 13-01-23 10:17 AM, Patrick Turley wrote:


On Jan 23, 2013, at 7:48 AM, Bruce Ashfield
  wrote:

On 13-01-23 12:34 AM, Patrick Turley wrote:


On Jan 22, 2013, at 11:17 PM, Bruce Ashfield  
wrote:


On 13-01-23 12:14 AM, Patrick Turley wrote:

On Jan 22, 2013, at 10:43 PM, Bruce Ashfield   
wrote:

On 13-01-22 9:26 PM, Patrick Turley wrote:


Argh. I'll have to just run the commands myself and stop spamming the
list with ideas :) It's just a matter of making lkc accept the defaults
(i.e. you could also use allyesconfig, or allnoconfig) or even better
not trigger that config check at all.


You're very kind to have spent so much time on my problem already. I look 
forward to hearing back.


I'm not sure if you are still interested in this topic, but I took
a few minutes to look into this more today .. just to understand
exactly what is happening.

It is what was discussed on the thread already, when you invoke
make scripts, there is an explicit dependency on auto.conf and
that is what triggers the make oldconfig if the .config is newer
than it is. Technically we are safe from this, assuming that the
.config and captured auto.conf match, and that auto.conf is in the
SDK.

The other way that oldconfig is triggered in my experience (and
testing today) is what we mentioned before. If your .config was
generated with ARCH= (even ARCH=i386 the default) and you then
execute 'make scripts', you'll trigger the oldconfig.

So to avoid it, you should execute your make scripts with ARCH=
on the command line.

As for saving ARCH in the .config, it has been considered in the past,
but never implemented. Other elements such as CROSS_COMPILE are now
saved, but not ARCH= since it isn't directly used in the .config, it's
a Makefile construct.

Cheers,

Bruce





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

Re: [yocto] Build external module against Yocto kernel

2013-02-01 Thread Bruce Ashfield


On 13-02-01 7:48 PM, Patrick Turley wrote:


On Jan 31, 2013, at 10:50 PM, Bruce Ashfield  
wrote:


On 13-01-23 10:17 AM, Patrick Turley wrote:


On Jan 23, 2013, at 7:48 AM, Bruce Ashfield
  wrote:

On 13-01-23 12:34 AM, Patrick Turley wrote:


On Jan 22, 2013, at 11:17 PM, Bruce Ashfield   
wrote:


On 13-01-23 12:14 AM, Patrick Turley wrote:

On Jan 22, 2013, at 10:43 PM, Bruce Ashfield
wrote:

On 13-01-22 9:26 PM, Patrick Turley wrote:


Argh. I'll have to just run the commands myself and stop spamming the
list with ideas :) It's just a matter of making lkc accept the defaults
(i.e. you could also use allyesconfig, or allnoconfig) or even better
not trigger that config check at all.


You're very kind to have spent so much time on my problem already. I look 
forward to hearing back.


I'm not sure if you are still interested in this topic, but I took
a few minutes to look into this more today .. just to understand
exactly what is happening.

It is what was discussed on the thread already, when you invoke
make scripts, there is an explicit dependency on auto.conf and
that is what triggers the make oldconfig if the .config is newer
than it is. Technically we are safe from this, assuming that the
.config and captured auto.conf match, and that auto.conf is in the
SDK.

The other way that oldconfig is triggered in my experience (and
testing today) is what we mentioned before. If your .config was
generated with ARCH=  (even ARCH=i386 the default) and you then
execute 'make scripts', you'll trigger the oldconfig.

So to avoid it, you should execute your make scripts with ARCH=
on the command line.

As for saving ARCH in the .config, it has been considered in the past,
but never implemented. Other elements such as CROSS_COMPILE are now
saved, but not ARCH= since it isn't directly used in the .config, it's
a Makefile construct.


I absolutely *am* still interested in this issue, and thank you for taking 
another look.

There are two commands that I'm interested in executing:

 -- make oldconfig

 -- make scripts

(Since I install the SDK under /opt, I use sudo when running these commands, 
but I don't *think* that's important.)


Here's what happens with the first command:

$ sudo make oldconfig ARCH=arm
   HOSTCC  scripts/basic/fixdep
   HOSTCC  scripts/basic/docproc
   HOSTCC  scripts/kconfig/conf.o
   HOSTCC  scripts/kconfig/kxgettext.o
   SHIPPED scripts/kconfig/zconf.tab.c
   SHIPPED scripts/kconfig/lex.zconf.c
   SHIPPED scripts/kconfig/zconf.hash.c
   HOSTCC  scripts/kconfig/zconf.tab.o
   HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
#
# configuration written to .config
#

As you say, adding "ARCH=arm" puts the build at ease and it completes just fine.


Here's what happens with the second command:

$ sudo make scripts ARCH=arm
scripts/kconfig/conf --silentoldconfig Kconfig
   HOSTCC  scripts/genksyms/genksyms.o
   SHIPPED scripts/genksyms/lex.c
   SHIPPED scripts/genksyms/parse.h
   SHIPPED scripts/genksyms/keywords.c
   HOSTCC  scripts/genksyms/lex.o
   SHIPPED scripts/genksyms/parse.c
   HOSTCC  scripts/genksyms/parse.o
   HOSTLD  scripts/genksyms/genksyms
   CC  scripts/mod/empty.o
cc1: error: unrecognized command line option "-mlittle-endian"
cc1: error: unrecognized command line option "-mapcs"
cc1: error: unrecognized command line option "-mno-sched-prolog"
cc1: error: unrecognized command line option "-mabi=aapcs-linux"
cc1: error: unrecognized command line option "-mno-thumb-interwork"
scripts/mod/empty.c:1: error: bad value (armv5t) for -march= switch
scripts/mod/empty.c:1: error: bad value (armv5t) for -mtune= switch
make[2]: *** [scripts/mod/empty.o] Error 1
make[1]: *** [scripts/mod] Error 2
make: *** [scripts] Error 2

Recall that, when I do *not* give the "ARCH=arm" argument, I get reams of 
config questions, but the build works.



The thing is that the timestamps of the .config and the kernel's auto.conf
should match and not trigger any more oldconfig executions.

I trust that if you still try "make scripts" without the ARCH,
even after the oldconfig step #1, you are still seeing the
questions. Thinking about it .. that does make sense that you'd
be seeing the oldconfig questions .. since the ARCH did change.

.. and just so I'm clear, you are building a ARM machine on a
x86 host and creating a SDK for that same x86 host, correct ?

The kernel's scripts target are really just a set of helpers for
building the kernel, and in this case, you aren't actually building
on a ARM machine, but on your x86 host. But the ARCH= is triggering
the ARM toolchain settings to be passed to your host compiler, since
CROSS_COMPILE= wasn't passed to the build.

So there's a couple of things more to consider:

1) go back to phase #1 and back to the idea of generating a 
allnoconfig/a

Re: [yocto] Build external module against Yocto kernel

2013-02-01 Thread Bruce Ashfield

On 13-02-01 11:35 PM, Brian Lloyd wrote:

While, I'm not an expert, I would like to point out:
http://kernel.org/doc/index-old.html (the new index references this but
the information isn't on the new index page directly).

One thing mentioned is that a make distclean is required for reasonable
results between any run with different architectures. So you can't run a
make scripts to get scripts for the local system in a build directory
configured for cross compiling for the device and expect it to work
correctly.

Also, about the config prompts: during dependency checking, the .config
file is validated, and if it fails validation, make oldconfig is run, as
it assumes the config was pulled from a previous kernel version. Since a
.config file is ARCH specific, it will almost always be invalid when
checked against a different architecture, and thus fire off a make
oldconfig. This is why you get prompted to answer questions when you do
"make scripts" and have a .config for another architecture.

Also, I suspect you need to ensure the cross compiler is being called
when necessary for the make scripts. It looks like the errors are from
passing arm gcc parameters to an x86 gcc. You can try "make ARCH=arm
CROSS_COMPILE=/???/" instead, where /???/ is the prefix to your arm
cross compiler. The kernel build actually uses both cross and non-cross
compilers during build so you have some support tools compiled to run
natively and others that run on the end machine, so you don't want to
override CXX and C++ to be the cross compiler.

We crossed while my email client was offline and I was typing up
a response. All of the above is definitely true, and what I had in
my rambling reply as well.

When building with the SDK, to avoid oldconfig AND get the build
infrastructure both CROSS_COMPILE and ARCH are required, just as bitbake
was providing during the original build.

The trick is to still generate modules that will work against the running
kernel .. but that's another story :)

Cheers,

Bruce

Brian

On Sat, 2013-02-02 at 00:48 +, Patrick Turley wrote:

On Jan 31, 2013, at 10:50 PM, Bruce Ashfieldmailto:bruce.ashfi...@windriver.com>>  wrote:

>  On 13-01-23 10:17 AM, Patrick Turley wrote:
>>
>>  On Jan 23, 2013, at 7:48 AM, Bruce Ashfieldmailto:bruce.ashfi...@windriver.com>>
>>   wrote:
>>>  On 13-01-23 12:34 AM, Patrick Turley wrote:
>>>>
>>>>  On Jan 22, 2013, at 11:17 PM, Bruce Ashfieldmailto:bruce.ashfi...@windriver.com>>   wrote:
>>>>
>>>>>  On 13-01-23 12:14 AM, Patrick Turley wrote:
>>>>>>  On Jan 22, 2013, at 10:43 PM, Bruce Ashfieldmailto:bruce.ashfi...@windriver.com>>wrote:
>>>>>>>  On 13-01-22 9:26 PM, Patrick Turley wrote:
>>>
>>>  Argh. I'll have to just run the commands myself and stop spamming the
>>>  list with ideas :) It's just a matter of making lkc accept the defaults
>>>  (i.e. you could also use allyesconfig, or allnoconfig) or even better
>>>  not trigger that config check at all.
>>
>>  You're very kind to have spent so much time on my problem already. I look 
forward to hearing back.
>
>  I'm not sure if you are still interested in this topic, but I took
>  a few minutes to look into this more today .. just to understand
>  exactly what is happening.
>
>  It is what was discussed on the thread already, when you invoke
>  make scripts, there is an explicit dependency on auto.conf and
>  that is what triggers the make oldconfig if the .config is newer
>  than it is. Technically we are safe from this, assuming that the
>  .config and captured auto.conf match, and that auto.conf is in the
>  SDK.
>
>  The other way that oldconfig is triggered in my experience (and
>  testing today) is what we mentioned before. If your .config was
>  generated with ARCH=  (even ARCH=i386 the default) and you then
>  execute 'make scripts', you'll trigger the oldconfig.
>
>  So to avoid it, you should execute your make scripts with ARCH=
>  on the command line.
>
>  As for saving ARCH in the .config, it has been considered in the past,
>  but never implemented. Other elements such as CROSS_COMPILE are now
>  saved, but not ARCH= since it isn't directly used in the .config, it's
>  a Makefile construct.

I absolutely *am* still interested in this issue, and thank you for taking 
another look.

There are two commands that I'm interested in executing:

 -- make oldconfig

 -- make scripts

(Since I install the SDK under /opt, I use sudo when running these commands, 
but I don't *think* that's important.)

Here's what happens with the first command:

$ sudo make oldconfig ARCH=arm
   HOSTCC  scripts/basic/fixdep
   HOSTCC

Re: [yocto] Build external module against Yocto kernel

2013-02-01 Thread Bruce Ashfield


On 13-02-02 12:12 AM, Brian Lloyd wrote:

I would like to point out the reason CROSS_COMPILE is used is because
kernel makes things that run natively and also things that are for the
end environment. Thus $(CROSS_COMPILE)$(CXX) is used to prepend when
building something for the end system, and $(CXX) is used for local run
items. So even with CROSS_COMPILE defined, not everything uses the
CROSS_COMPILE. Let's hope the kernel maintainers got the use and not use
right for us, because I sure don't want to be second guessing on this mess.


Absolutely .. the kernel always gets this right, native utilities never
use the prefix. In fact, in 12 years I've only run into one mix up
between target and native .o's in a kernel build.

Cheers,

Bruce



I do know make scripts does create items intended to run in the final
environment.

Since I build for i386 on an x64 these days, I don't usually have
problems where I can't run the cross compiled tools, so my personal
recent experience is limited as well as bad parameters issues from using
the wrong compiler (as my compiler can generally make for both).

Brian

On Fri, 2013-02-01 at 23:48 -0500, Bruce Ashfield wrote:

On 13-02-01 7:48 PM, Patrick Turley wrote:
>
>  On Jan 31, 2013, at 10:50 PM, Bruce Ashfieldmailto:bruce.ashfi...@windriver.com>>   wrote:
>
>>  On 13-01-23 10:17 AM, Patrick Turley wrote:
>>>
>>>  On Jan 23, 2013, at 7:48 AM, Bruce Ashfieldmailto:bruce.ashfi...@windriver.com>>
>>>wrote:
>>>>  On 13-01-23 12:34 AM, Patrick Turley wrote:
>>>>>
>>>>>  On Jan 22, 2013, at 11:17 PM, Bruce Ashfieldmailto:bruce.ashfi...@windriver.com>>wrote:
>>>>>
>>>>>>  On 13-01-23 12:14 AM, Patrick Turley wrote:
>>>>>>>  On Jan 22, 2013, at 10:43 PM, Bruce Ashfieldmailto:bruce.ashfi...@windriver.com>> wrote:
>>>>>>>>  On 13-01-22 9:26 PM, Patrick Turley wrote:
>>>>
>>>>  Argh. I'll have to just run the commands myself and stop spamming the
>>>>  list with ideas :) It's just a matter of making lkc accept the defaults
>>>>  (i.e. you could also use allyesconfig, or allnoconfig) or even better
>>>>  not trigger that config check at all.
>>>
>>>  You're very kind to have spent so much time on my problem already. I look 
forward to hearing back.
>>
>>  I'm not sure if you are still interested in this topic, but I took
>>  a few minutes to look into this more today .. just to understand
>>  exactly what is happening.
>>
>>  It is what was discussed on the thread already, when you invoke
>>  make scripts, there is an explicit dependency on auto.conf and
>>  that is what triggers the make oldconfig if the .config is newer
>>  than it is. Technically we are safe from this, assuming that the
>>  .config and captured auto.conf match, and that auto.conf is in the
>>  SDK.
>>
>>  The other way that oldconfig is triggered in my experience (and
>>  testing today) is what we mentioned before. If your .config was
>>  generated with ARCH=   (even ARCH=i386 the default) and you then
>>  execute 'make scripts', you'll trigger the oldconfig.
>>
>>  So to avoid it, you should execute your make scripts with ARCH=
>>  on the command line.
>>
>>  As for saving ARCH in the .config, it has been considered in the past,
>>  but never implemented. Other elements such as CROSS_COMPILE are now
>>  saved, but not ARCH= since it isn't directly used in the .config, it's
>>  a Makefile construct.
>
>  I absolutely *am* still interested in this issue, and thank you for taking 
another look.
>
>  There are two commands that I'm interested in executing:
>
>   -- make oldconfig
>
>   -- make scripts
>
>  (Since I install the SDK under /opt, I use sudo when running these commands, 
but I don't *think* that's important.)
>
>
>  Here's what happens with the first command:
>
>  $ sudo make oldconfig ARCH=arm
> HOSTCC  scripts/basic/fixdep
> HOSTCC  scripts/basic/docproc
> HOSTCC  scripts/kconfig/conf.o
> HOSTCC  scripts/kconfig/kxgettext.o
> SHIPPED scripts/kconfig/zconf.tab.c
> SHIPPED scripts/kconfig/lex.zconf.c
> SHIPPED scripts/kconfig/zconf.hash.c
> HOSTCC  scripts/kconfig/zconf.tab.o
> HOSTLD  scripts/kconfig/conf
>  scripts/kconfig/conf --oldconfig Kconfig
>  #
>  # configuration written to .config
>  #
>
>  As you say, adding"ARCH=arm"  puts the build at ease and it completes just 
fine.
>
>
>  Here's what happens with the second command:
>
>

Re: [yocto] PROVIDES for Yocto Kernel Recipes

2013-02-07 Thread Bruce Ashfield

On Thu, Feb 7, 2013 at 8:22 PM, Rudolf Streif wrote:

> I apologize if that has been brought up before.
>
> The linux-yocto kernel recipes include the git tags into PV by explicitly
> setting:
>
> PV = "${LINUX_VERSION}+git${SRCPV}"
>
> This means that you cannot for example do
>
> bitbake linux-yocto-3.2
>
> anymore because PROVIDES does not contain linux-yocto-3.2 but only the
> rather cumbersome string linux-yocto-3.2+git${SRCPV}, with ${SRCPV}
> expanded of course.
>
> The percent notation only works for
>
> PREFERRED_VERSION_linux-yocto = "3.2%"
>
> but does not work for
>
> bitbake linux-yocto-3.2%
>
> That really only leaves you with setting PREFERRED_VERSION which is not
> that convenient if you just want to build a different kernel version.
>
> I am not sure how others feel about that and maybe I am missing something
> but it would be rather simple to add that back by setting
>
> PV = "${LINUX_VERSION} ${LINUX_VERSION}+git${SRCPV}"
>

You mean with a space in the version string ? I know that I don't want
directories floating around
with spaces, since they cause no end of troubles. But maybe it's just the
font in gmail playing
tricks with my eyes.

Perhaps Richard has a suggestion, but in 3+ years, this is the first time
that this particular issue
has come up. Most everyone is setting the PREFERRED_VERSION in their bsps,
or local.conf
and not using that particular mechanism of switching between kernels ..
myself included, and I
probably build more versions of linux-yocto than anyone you'll find :)

Don't get me wrong, I'm not dead set against changing it, but we do need
both the meta and
machine git hashes in the version to uniquely identify the tree (and my no
spaces comment!).
Maybe someone knows of a better way for command line switching of the
version ?

Cheers,

Bruce

>
>

> Well, kind of, you still would have to know the minor version number.
>
> Cheers,
> Rudi
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PROVIDES for Yocto Kernel Recipes

2013-02-07 Thread Bruce Ashfield


On 13-02-07 8:52 PM, Rudolf Streif wrote:

Yes, of course with a space. Proportional fonts don't work that well
with code. :)


Back to my work account with a sane client now!



That's why I am asking if anyone else found that to be a nuisance. Of
course, for a BSP you have to set PREFERRED_VERSION. But for testing and
working with different kernel version I would find it more convenient if
I had not to change PREFERRED_VERSION in the machine file or override it
in local.conf.

It's also sort of an inconsistency. Typically, one would expect that you
could run bitbake against a recipe by specifying the package name and


I'd have to leave this comment up to others with respect to consistency,
since I'm a kernel guy and not a long time oe-classic user (just my time
with yocto and oe-core). But I've never switched versions on the command
line like this myself. A matter of taste and habits I suppose.

I quick survey shows roughly:

../meta]> find . -name '*.bb' | xargs grep PV | grep SRCPV | wc -l
87

Almost 90 other recipes with some variant of SRCPV in their version string.
So unless I'm mistaken .. they'd all suffer the same issue as linux-yocto.

Cheers,

Bruce



version. Using -b with the recipe file name is not an option since you
would not get the bbappends.

Cheers,
Rudi


On Thu, Feb 7, 2013 at 5:39 PM, Bruce Ashfield mailto:bruce.ashfi...@gmail.com>> wrote:




On Thu, Feb 7, 2013 at 8:22 PM, Rudolf Streif
mailto:rudolf.str...@linux.com>> wrote:

I apologize if that has been brought up before.

The linux-yocto kernel recipes include the git tags into PV by
explicitly setting:

PV = "${LINUX_VERSION}+git${SRCPV}"

This means that you cannot for example do

bitbake linux-yocto-3.2

anymore because PROVIDES does not contain linux-yocto-3.2 but
only the rather cumbersome string linux-yocto-3.2+git${SRCPV},
with ${SRCPV} expanded of course.

The percent notation only works for

PREFERRED_VERSION_linux-yocto = "3.2%"

but does not work for

bitbake linux-yocto-3.2%

That really only leaves you with setting PREFERRED_VERSION which
is not that convenient if you just want to build a different
kernel version.

I am not sure how others feel about that and maybe I am missing
something but it would be rather simple to add that back by setting

PV = "${LINUX_VERSION} ${LINUX_VERSION}+git${SRCPV}"


You mean with a space in the version string ? I know that I don't
want directories floating around
with spaces, since they cause no end of troubles. But maybe it's
just the font in gmail playing
tricks with my eyes.

Perhaps Richard has a suggestion, but in 3+ years, this is the first
time that this particular issue
has come up. Most everyone is setting the PREFERRED_VERSION in their
bsps, or local.conf
and not using that particular mechanism of switching between kernels
.. myself included, and I
probably build more versions of linux-yocto than anyone you'll find :)

Don't get me wrong, I'm not dead set against changing it, but we do
need both the meta and
machine git hashes in the version to uniquely identify the tree (and
my no spaces comment!).
Maybe someone knows of a better way for command line switching of
the version ?

Cheers,

Bruce


Well, kind of, you still would have to know the minor version
number.

Cheers,
Rudi


___
yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto




--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"




--
--
*Rudolf J. Streif*
Director of Embedded Solutions
The Linux Foundation

rudolf.str...@linux.com <mailto:rudolf.str...@linux.com>
Phone: +1.619.631.5383
Skype: rudolfstreif
PGP: RSA 2048/2048 D6E7D28B

Linux Foundation Events Schedule: events.linuxfoundation.org
<http://events.linuxfoundation.org/>
Linux Foundation Training Schedule: training.linuxfoundation.org
<http://training.linuxfoundation.org/>



___
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] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine

2013-02-10 Thread Bruce Ashfield


On 13-02-08 6:18 PM, kishore.k.bo...@intel.com wrote:

From: Kishore Bodke


Hi,

This patch set is to remove the Cedartail Machine from
Linux-yocto-3.4 Kernel.
Cedartrail BSP will not be supported for Yocto 1.4 Release.

Also Please remove the standard/cedartrail branch.

Please pull into linux-yocto-3.4/meta branch.


Ack'd. I'll merge and push this out on Monday.

Cheers,

Bruce



Thanks
Kishore.

The following changes since commit f697e099bc76d5df3a307a5bc0cc25021dd6dfe0:

   meta: bump to v3.4.28, rt-40 (2013-02-04 00:14:21 -0500)

are available in the git repository at:

   git://git.pokylinux.org/linux-yocto-contrib kishore/cedartrail_remove
   
http://git.pokylinux.org/cgit.cgi/linux-yocto-contrib/log/?h=kishore/cedartrail_remove

Kishore Bodke (1):
   meta: Remove Cedartrail Machine

  .../bsp/cedartrail/cedartrail-preempt-rt.scc   |   13 --
  .../bsp/cedartrail/cedartrail-standard.scc |8 
  .../cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg |   46 
  .../cfg/kernel-cache/bsp/cedartrail/cedartrail.scc |   15 ---
  4 files changed, 82 deletions(-)
  delete mode 100755 
meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-preempt-rt.scc
  delete mode 100755 
meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc
  delete mode 100755 meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg
  delete mode 100644 meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.scc



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

Re: [yocto] Building uio-pci-generic into core-image-minimal

2013-02-12 Thread Bruce Ashfield


On 13-02-12 6:47 PM, David Mulder wrote:

I need to use the uio-pci-generic kernel module, but I don’t know how to
make it available in my image.

Yocto 1.3, core-image-minimal, did ‘bitbake linux-yocto –c menuconfig’
and added “Generic driver for PCI 2.3”. It took a while to bitbake
core-image-minimal after that change, and I saw uio-pci-generic.o, so I
assume it rebuilt the kernel and built the module, but I don’t see any
traces of the module in my image (‘find / -name *uio*’, /sys/class/uio
or /sys/bus/pci/drivers/uio-pci-generic).

I added uio and uio-pci-generic to a recipe’s RDEPENDS, but it can’t
find a provider. I added them to IMAGE_FEATURES in local.conf, but that


You need to add the modules to IMAGE_INSTALL via their individual package
name, or if you just want all modules, use the virtual package 
"kernel-modules"


You can also get it in the image via MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS.

Cheers,

Bruce



didn’t seem to do anything. I set ‘module_autoload_uio = “uio”’ in
local.conf, which also seemed to do nothing. Same for setting it in
linux-yocto_3.4.bbappend (some patches indicate that it used to be set
in that file). I don’t know what else to try.

What might I be missing? Where could I look to see if that module has
been built and copied to my image?

Thanks!



___
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] uboot.bin and rootfs but not uImage

2013-03-01 Thread Bruce Ashfield


On 13-03-01 03:53 AM, Satya Swaroop Damarla wrote:

Hi Rudy,

Thank you for the basic file... I have a question here... The git
directory is already saved on my work pc. What is the necessity to
download it again? The reason behind my asking this question is, it is
secured and so password is required. So, in order to avoid confusion I
already downloaded it to a directory called
"/home/damarla/linux-skidata.git". So can I just write

SRC_URI = "dir://home/damarla/linux-skidata.git"

I think in the above way I can just simply remove the KSRC and KBRANCH
variables from the linux-skidata.bb <http://linux-skidata.bb> file. The
revision tag is also not required in this cases as we are using the
kernel provided by the company itself, I mean for the first basic build.


The example code that was posted, already does this. KSRC points to
a git repository on your local machine:

   KSRC ?= "/linux-skidata.git"

And the protocol is set to "file" in the SRC_URI

   SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel \
   file://defconfig"

There's nothing more that you need to do.



One more thing is the skidata-carrier_defconfig is already in the
directory git I mentioned above at
"/home/damarla/linux-skidata.git/arch/arm/configs/skidata-carrier_defconfig"
... When compiling the kernel how can we tell the build system to build
the kernel using that specific defconfig file?


Putting the defconfig on the SRC_URI is all that you have to do.

This information is also covered in the quickstart and development
guides .. have you had a look at them ? If you have a look, you'll
see that more options are available with linux-yocto based recipes
(custom or the ones part of oe-core), which will allow you some more
flexibility in handling modifications to the kernel.

Cheers,

Bruce





Thanks Rudy in advance,
Satya






On Thu, Feb 28, 2013 at 9:31 PM, Rudolf Streif
mailto:rstr...@linuxfoundation.org>> wrote:

Hi Satya,

You will first need a kernel recipe, let's call it linux-skidata.bb
<http://linux-skidata.bb>. It can look like this:

DESCRIPTION = "Skidata Linux Kernel"
SECTION = "kernel"
LICENSE = "GPLv2"

LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"

PV = "3.2"

inherit kernel

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

# GIT repository location
KSRC ?= "/linux-skidata.git"

# Branch to check out
KBRANCH ?= ""

# Revision tag or AUTOREV
SRCREV ?= "${AUTOREV}"

SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel \
   file://defconfig \
"

S = "${WORKDIR}/git"


You will need to provide a defconfig file next to your recipe
containing the kernel configuration settings. Your kernel GIT repo
may contain a .config that is good for your hardware. In that case
you do not need a defconfig but is still a good practice and will
allow you to easily change the settings.

Then you need to adjust your machine configuration file:

PREFERRED_PROVIDER_virtual/kernel ?= "linux-skidata"
PREFERRED_VERSION_skidata ?= "3.2%"


That should do it.

:rjs


On Thu, Feb 28, 2013 at 11:21 AM, Satya Swaroop Damarla
mailto:swaroop.dama...@gmail.com>> wrote:

Yes I got an error message when I was building the kernel...
  Actuallly I have a kernel git given by the company I
downloaded it and is in my work pc.. How can I tell the build
system to use that kernel?


On Thu, Feb 28, 2013 at 8:17 PM, Rudolf Streif
mailto:rstr...@linuxfoundation.org>> wrote:

Satya,

your machine configuration file looks ok as far as I can
tell. Did you get an error message when building the kernel?
Did you try to build just the kernel e.g. bitbake linux-yocto?

:rjs


On Mon, Feb 25, 2013 at 11:31 PM, Satya Swaroop Damarla
mailto:swaroop.dama...@gmail.com>> wrote:

Hello Guys... I think uImage is important but it is not
being generated by the yocto project. It only generated
the rootfs and uboot.bin. Is there any variable that has
to be introduced in the machine.conf (in my case it is
skidata-tamonten.conf)

Here is the configuration file

#@TYPE: Machine
#@NAME: skidata-tamonten machine
#@DESCRIPTION: Machine configuration for the Tamonten board

PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"

IMAGE_FEATURES += "package-management"
EXTRA_IMAGEDEPENDS +=

Re: [yocto] linux 3.8

2013-03-01 Thread Bruce Ashfield


On 13-03-01 11:42 AM, Trevor Woerner wrote:

Given that Greg KH has publicly stated linux-3.8 is not a long term
stable kernel, is it worth the effort to support it in Yocto?


We don't need LTSI to make a kernel worth supporting. We pick our
kernels based on the timing of the Yocto release schedule (the
time and criteria are documented on the yoctoproject wiki IIRC).

But note, Greg is talking specifically about LTSI, we don't
expect more than one LTSI per year, and we are already locked into
the LTSI 3.4. We've known Greg's strategy and plans for a while, so
this isn't a surprise. He'll do his normal -stable releases for
3.8 and drop them once 3.9 arrives, which is also expected.

Cheers,

Bruce





http://www.kroah.com/log/linux/3.8-is_not_longterm_stable.html
___
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] linux 3.8

2013-03-01 Thread Bruce Ashfield


On 13-03-01 02:15 PM, Rudolf Streif wrote:

Bruce,

On Fri, Mar 1, 2013 at 9:29 AM, Bruce Ashfield
mailto:bruce.ashfi...@windriver.com>> wrote:

But note, Greg is talking specifically about LTSI, we don't
expect more than one LTSI per year, and we are already locked into
the LTSI 3.4.

However, as far as I understand it the 3.4 snapshot in
git.yoctoproject.org <http://git.yoctoproject.org> is from kernel.org
<http://kernel.org> and not from
http://git.linuxfoundation.org/ltsi-kernel.git. GregKH has been merging
patches into the LTSI kernel, such as AF_BUS, that have not been
accepted by upstream. I do not think that those patches are being merged
into the YP kernel tree. But please correct me if I am wrong.


The 3.4 LTSI patches are all present on the 3.4 kernel tree, directly
from Greg's patch queue.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.4/log/?h=ltsi

And that branch is merged into each and every other branch in the
linux-yocto tree.

We've been involved with Greg and LTSI for quite a while now, and are
tracking it via our tree as we discussed with the interested parties.

Cheers,

Bruce



Cheers,
Rudi


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

Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Bruce Ashfield


On 13-03-05 12:35 PM, Kamble, Nitin A wrote:


So the topic branch commit is present much deeper in the branch with

different commit-id.

May be merging of the emgd branch resulted it. Is it issue with the
emgd branch rebased to an undesired point?


It shouldn't be. That commit shouldn't be present in the repository at all (it
isn't in mine). The emgd branches are off master, same repo and can't bring
in something like this.


Right. I think it got placed there after merge with the emgd branch done by the
kernel-tools.


That doesn't make sense either. The merge of the emgd branch is just
the git merge of a locally staged branch in the linux-yocto repository.
That commit you reference shouldn't be in the emgd branch, or any
branch if a clean linux-yocto-3.8 tree is being used.

Cheers,

Bruce





So something is getting tied in a knot when the repository is fetched into the
source dir.


I don't see any issue with the fetch. As noemgd BSPs are working as expected.



For your builds that work, do you have that commit present ?



The emenlow-noemgd build sees the right HEAD commit. So the issue is definitely 
something to do
with the merge with the emgd branch.

Nitin




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

Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Bruce Ashfield

On 13-03-05 12:56 PM, Kamble, Nitin A wrote:

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, March 05, 2013 9:50 AM
To: Kamble, Nitin A
Cc: linux-yo...@yoctoproject.org
Subject: Re: v3.8 kernel recipes in meta-intel

On 13-03-05 12:35 PM, Kamble, Nitin A wrote:

So the topic branch commit is present much deeper in the branch with

different commit-id.

May be merging of the emgd branch resulted it. Is it issue with the
emgd branch rebased to an undesired point?

It shouldn't be. That commit shouldn't be present in the repository
at all (it isn't in mine). The emgd branches are off master, same
repo and can't bring in something like this.

Right. I think it got placed there after merge with the emgd branch
done by the kernel-tools.

That doesn't make sense either. The merge of the emgd branch is just the git
merge of a locally staged branch in the linux-yocto repository.
That commit you reference shouldn't be in the emgd branch, or any branch if
a clean linux-yocto-3.8 tree is being used.

Right, so the kernl tools are producing unwanted state of the topic branch when
emgd branch is considered. And I guess you would know better why kernl tools 
are doing it.

Not exactly, I must not be understanding what you are describing.
There's no way for the kern-tools to create a commit ID. They can only
work with what's present in the tree.

If you see the SRCREV to "foo", and validate_branches is telling you
that "foo" isn't present in the tree at all, that's not related to
the kern tools at all. It's related to the repository that is cloned
into the WORKDIR for building.

If you can make your recipes and updates public, I can try and do a build
here.

Bruce

Nitin

Cheers,

Bruce

So something is getting tied in a knot when the repository is fetched
into the source dir.

I don't see any issue with the fetch. As noemgd BSPs are working as

expected.

For your builds that work, do you have that commit present ?

The emenlow-noemgd build sees the right HEAD commit. So the issue is
definitely something to do with the merge with the emgd branch.

Nitin

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

Re: [yocto] A question on adding a new program to a new meta layer


On 13-03-05 1:54 AM, Insop Song wrote:

Hi,

I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called "meta-dl". I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/


FYI: I've already merged and staged sched_dl in linux-yocto_3.8:

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf

I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.

Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.

Cheers,

Bruce



With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.


Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.

- problem: adding a new software into my meta-dl layer

- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do "bitbake schedtool-dl -c install" it builds and install,
but at "i586" location instead of my machine staging rootfs
(dl-qemux86)



- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = "schedtool-dl (scheduler test tool) for deadline scheduler"
HOMEPAGE = "https://github.com/insop/schedtool-dl";
SECTION = "base"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM =
"file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984"
PR = "r1"

SRC_URI = "git://github.com/insop/schedtool-dl.git;protocol=git"
SRCREV = "${AUTOREV}"

S = "${WORKDIR}/git"

do_compile() {
 oe_runmake
}

do_install() {
 oe_runmake install DESTDIR=${D}
}

PARALLEL_MAKE = ""

BBCLASSEXTEND = "native"

COMPATIBLE_MACHINE_dl-qemux86 = "dl-qemux86"



- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"

# We have a recipes directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
 ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "dl-qemux86"
BBFILE_PATTERN_dl-qemux86 := "^${LAYERDIR}/"
BBFILE_PRIORITY_dl-qemux86 = "6"
=



Thank you.

Regards,

Insop


- ref:
1. sched_deadline:
https://events.linuxfoundation.org/events/linuxcon-europe/song
2. sched_deadline:
http://events.linuxfoundation.org/images/stories/slides/elc2013_kobayashi.pdf?a
___
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] A question on adding a new program to a new meta layer


On 13-03-06 11:24 PM, Juri Lelli wrote:

Hi,

On 03/06/2013 08:00 PM, Bruce Ashfield wrote:

On 13-03-05 1:54 AM, Insop Song wrote:

Hi,

I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called "meta-dl". I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/


FYI: I've already merged and staged sched_dl in linux-yocto_3.8:

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf


I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.

Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.



Thanks a lot for your support! I'm already in contact with Insop, it
would be great to coordinate among ourselves.


Thanks Juri, I was going to add you to my linux-yocto-3.8 announcement
email and due to some last minute debug activities .. it slipped my
mind. So I'm using this thread to let you, and anyone else that is
interested know that sched_deadline support is available to try out
in linux-yocto-3.8.



As I already told to Insop, I don't have any automated test for the
patchset, but I usually run different scenarios using basically this
two tools (and giving a look at simple cases through kernelshark):

1- schedtool-dl: https://github.com/jlelli/schedtool-dl
the idea here is to let a 'yes' run through SCHED_DEADLINE and
check through kernelshark that the bandwidth enforcement
mechanism works.

2- rt-app: https://github.com/gbagnoli/rt-app
with this I usually let some tasksets run for several hours on
a 48-cores machine we have in our lab, I can provide the tasksets
(json files) and the script to run them.

Please let me know how I can help further.


This is a good start. I have some old references to tests that I'll
dig up as well.

I'm looking to develop some "real world" examples of the scheduler
class in action, since as we've been saying .. getting those examples
will both help the approach and perhaps help get it merged into the
mainline kernel.

Cheers,

Bruce



Best Regards,

- Juri



With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.


Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.

- problem: adding a new software into my meta-dl layer

- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do "bitbake schedtool-dl -c install" it builds and install,
but at "i586" location instead of my machine staging rootfs
(dl-qemux86)



- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb

===
DESCRIPTION = "schedtool-dl (scheduler test tool) for deadline
scheduler"
HOMEPAGE = "https://github.com/insop/schedtool-dl";
SECTION = "base"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM =
"file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984"
PR = "r1"

SRC_URI = "git://github.com/insop/schedtool-dl.git;protocol=git"
SRCREV = "${AUTOREV}"

S = "${WORKDIR}/git"

do_compile() {
  oe_runmake
}

do_install() {
  oe_runmake install DESTDIR=${D}
}

PARALLEL_MAKE = ""

BBCLASSEXTEND = "native"

COMPATIBLE_MACHINE_dl-qemux86 = "dl-qemux86"



- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"

# We have a recipes directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
  ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "dl-qemux86"
BBFILE_PATTERN_dl-qemux86 := "^${LAYERDIR}/"
BBFILE_PRIORITY_dl-qemux86 = "6"
=



Thank you.

Regards,

Insop


- ref:
1. sched_deadline:
https://events.linuxfoundation.org/events/linuxcon-europe/song
2. sched_deadline:
http://events.linuxfoundation.org/images/stories/slides/elc2013_kobayashi.pdf?a

___
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] A question on adding a new program to a new meta layer


On 13-03-07 12:05 AM, Insop Song wrote:

Bruce,

That's very good. I will bring linux-yocto-3.8 kernel to meta-dl.
(https://github.com/insop/meta-dl/tree/linux-yocto-3.8)


I have another suggestion to offer here, one I've been wanting to
do for a bit.

I've added Darren Hart to the thread, since I'd like to hear from
him on this as well.

I have a use for the scheduling tools and benchmark cases for some
virtualization usecases (meta-virtualization on git.yoctoproject.org).

We already have "recipes-rt" in oe-core, and the preempt-rt kernel
available from linux-yocto, and as we've been discussing I've added
support for EDF/sched_dealine in linux-yocto-3.8.

I'm not a fan of having to many layers, but rather than putting these
efforts in github layers, hiding them in meta-virtualiation and they
aren't yet "core" enough to go in oe-core .. I'd rather see them
conslidated in a "meta-realtime" (or whatever name we decide on)
layer on git.yoctoproject.org.

There are also ideas around interrupt management, AMP, and alternative
system partitioning that I'd like to drive into such a layer.

A quick scan of the layer index, doesn't show anything that matches
this description. So I'm suggesting that we create a new layer
to consolidate these approaches, and a layer that can be consumed by
some of the other layers that are currently in progress.

Comments ? In particular, point out a layer that already does this that
I've missed.



The purposes of meta-dl are the following three:
1. easy to use sched_deadline by providing recipes-kernel that includes
- git url including github and from yocto-kernel

2. easy to test and validate sched_deadline with automated
reproducible test suits
- currently, rt-app and schedtool are included in meta-dl
- will add test scripts

3. provide and test on different targets/bsps
- will prepare and test on different targets (bsp)

#1 is done as I've tested with kernel from github from Juri and
yocto-kernel-3.8 that you've merged.
#2 and #3 are in-progress.

I've talked Juri the other day and gather information on testing
methods and scripts so I will include this to meta-dl.

I agree that it's good to coordinate the effort, so please feel free
to let me know if you have any suggestion.


See above. I'd like to consolidate things even more :)

Cheers,

Bruce



Regards,

Insop

* updated kernel recipes
@ -9,12 +9,15 @@ inherit kernel

  #SRCREV ="031d31cfaa1e0c00122bf52639e340353d3b8360"
  SRCREV ="${AUTOREV}"
-KBRANCH = "sched-dl-V7"
-SRC_URI = "git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#KBRANCH = "sched-dl-V7"
+#SRC_URI = 
"git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#   file://defconfig "
+KBRANCH = "standard/edf"
+SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-3.8;protocol=git;branch=${KBRANCH}
\
 file://defconfig "

  PV = "3.8"
-PR = "dl7"
+PR = "dl"

  KSRC ?= ""
  S = '${@base_conditional("KSRC", "", "${WORKDIR}/git", "${KSRC}", d)}'

Thank you.

Insop

On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
 wrote:

On 13-03-05 1:54 AM, Insop Song wrote:


Hi,

I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called "meta-dl". I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/



FYI: I've already merged and staged sched_dl in linux-yocto_3.8:

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf

I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.

Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.

Cheers,

Bruce



With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.


Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.

- problem: adding a new software into my meta-dl layer

- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do "bitbake schedtool-dl -c install" it builds and install,
but at "i586" location instead of my machine staging rootfs
(dl-qemux86)



- Here is my .bb file that pulls an additional program.

https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtoo

Re: [yocto] A question on adding a new program to a new meta layer


On 13-03-07 03:26 AM, Insop Song wrote:

Hi Bruce,

One more question on 3.8 kernel.
Is "meta/recipes-kernel/linux/linux-yocto_3.8.bb" added soon as well in 1.4?


It's in master as of a few days ago. So it's available and
ready for use.

Cheers,

Bruce



I am using 1.4_M4.final now.

Thank you.

Insop

On Wed, Mar 6, 2013 at 9:05 PM, Insop Song  wrote:

Bruce,

That's very good. I will bring linux-yocto-3.8 kernel to meta-dl.
(https://github.com/insop/meta-dl/tree/linux-yocto-3.8)

The purposes of meta-dl are the following three:
1. easy to use sched_deadline by providing recipes-kernel that includes
- git url including github and from yocto-kernel

2. easy to test and validate sched_deadline with automated
reproducible test suits
- currently, rt-app and schedtool are included in meta-dl
- will add test scripts

3. provide and test on different targets/bsps
- will prepare and test on different targets (bsp)

#1 is done as I've tested with kernel from github from Juri and
yocto-kernel-3.8 that you've merged.
#2 and #3 are in-progress.

I've talked Juri the other day and gather information on testing
methods and scripts so I will include this to meta-dl.

I agree that it's good to coordinate the effort, so please feel free
to let me know if you have any suggestion.

Regards,

Insop

* updated kernel recipes
@ -9,12 +9,15 @@ inherit kernel

  #SRCREV ="031d31cfaa1e0c00122bf52639e340353d3b8360"
  SRCREV ="${AUTOREV}"
-KBRANCH = "sched-dl-V7"
-SRC_URI = "git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#KBRANCH = "sched-dl-V7"
+#SRC_URI = 
"git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#   file://defconfig "
+KBRANCH = "standard/edf"
+SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-3.8;protocol=git;branch=${KBRANCH}
\
 file://defconfig "

  PV = "3.8"
-PR = "dl7"
+PR = "dl"

  KSRC ?= ""
  S = '${@base_conditional("KSRC", "", "${WORKDIR}/git", "${KSRC}", d)}'

Thank you.

Insop

On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
 wrote:

On 13-03-05 1:54 AM, Insop Song wrote:


Hi,

I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called "meta-dl". I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/



FYI: I've already merged and staged sched_dl in linux-yocto_3.8:

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf

I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.

Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.

Cheers,

Bruce



With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.


Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.

- problem: adding a new software into my meta-dl layer

- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do "bitbake schedtool-dl -c install" it builds and install,
but at "i586" location instead of my machine staging rootfs
(dl-qemux86)



- Here is my .bb file that pulls an additional program.

https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = "schedtool-dl (scheduler test tool) for deadline scheduler"
HOMEPAGE = "https://github.com/insop/schedtool-dl";
SECTION = "base"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM =
"file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984"
PR = "r1"

SRC_URI = "git://github.com/insop/schedtool-dl.git;protocol=git"
SRCREV = "${AUTOREV}"

S = "${WORKDIR}/git"

do_compile() {
  oe_runmake
}

do_install() {
  oe_runmake install DESTDIR=${D}
}

PARALLEL_MAKE = ""

BBCLASSEXTEND = "native"

COMPATIBLE_MACHINE_dl-qemux86 = "dl-qemux86"



- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"

# We have a recipes directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
  ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS +

Re: [yocto] A question on adding a new program to a new meta layer


On 13-03-07 12:05 AM, Insop Song wrote:

Bruce,

That's very good. I will bring linux-yocto-3.8 kernel to meta-dl.
(https://github.com/insop/meta-dl/tree/linux-yocto-3.8)

The purposes of meta-dl are the following three:
1. easy to use sched_deadline by providing recipes-kernel that includes
- git url including github and from yocto-kernel

2. easy to test and validate sched_deadline with automated
reproducible test suits
- currently, rt-app and schedtool are included in meta-dl
- will add test scripts

3. provide and test on different targets/bsps
- will prepare and test on different targets (bsp)

#1 is done as I've tested with kernel from github from Juri and
yocto-kernel-3.8 that you've merged.
#2 and #3 are in-progress.

I've talked Juri the other day and gather information on testing
methods and scripts so I will include this to meta-dl.

I agree that it's good to coordinate the effort, so please feel free
to let me know if you have any suggestion.

Regards,

Insop

* updated kernel recipes
@ -9,12 +9,15 @@ inherit kernel

  #SRCREV ="031d31cfaa1e0c00122bf52639e340353d3b8360"
  SRCREV ="${AUTOREV}"
-KBRANCH = "sched-dl-V7"
-SRC_URI = "git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#KBRANCH = "sched-dl-V7"
+#SRC_URI = 
"git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#   file://defconfig "
+KBRANCH = "standard/edf"
+SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-3.8;protocol=git;branch=${KBRANCH}
\
 file://defconfig "


What do you have in your "defconfig" ? I'm about to push patches that
will make enabling sched_dealine a KERNEL_FEATURE option, which makes
it even easier to use.

But in the meantime, if you want to enable the support on a yocto BSP,
you can change your "defconfig" to be "sched-deadline.cfg" and only
put the kernel options required to enable the feature.

Cheers,

Bruce



  PV = "3.8"
-PR = "dl7"
+PR = "dl"

  KSRC ?= ""
  S = '${@base_conditional("KSRC", "", "${WORKDIR}/git", "${KSRC}", d)}'

Thank you.

Insop

On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
 wrote:

On 13-03-05 1:54 AM, Insop Song wrote:


Hi,

I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called "meta-dl". I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/



FYI: I've already merged and staged sched_dl in linux-yocto_3.8:

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf

I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.

Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.

Cheers,

Bruce



With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.


Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.

- problem: adding a new software into my meta-dl layer

- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do "bitbake schedtool-dl -c install" it builds and install,
but at "i586" location instead of my machine staging rootfs
(dl-qemux86)



- Here is my .bb file that pulls an additional program.

https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = "schedtool-dl (scheduler test tool) for deadline scheduler"
HOMEPAGE = "https://github.com/insop/schedtool-dl";
SECTION = "base"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM =
"file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984"
PR = "r1"

SRC_URI = "git://github.com/insop/schedtool-dl.git;protocol=git"
SRCREV = "${AUTOREV}"

S = "${WORKDIR}/git"

do_compile() {
  oe_runmake
}

do_install() {
  oe_runmake install DESTDIR=${D}
}

PARALLEL_MAKE = ""

BBCLASSEXTEND = "native"

COMPATIBLE_MACHINE_dl-qemux86 = "dl-qemux86"



- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"

# We have a recipes directory, add to BBFILES
BBFILES := "${BBFILES

Re: [yocto] A question on adding a new program to a new meta layer


On 13-03-07 4:43 PM, Insop Song wrote:

Hi Bruce,



What do you have in your "defconfig" ? I'm about to push patches that
will make enabling sched_dealine a KERNEL_FEATURE option, which makes
it even easier to use.



Here is my defconfg
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-kernel/linux/linux/defconfig

I've asked this to Juri, too. So this is for the config for sched_deadline
"Every defconfig kernel should compile and work
fine (given HZ=1000, NO_HZ not set and HRTIMERS=y)"

And here are the CONFIG that should set  (Juri, please let us know if
I miss anything)
--
CONFIG_EXPERIMENTAL = y
CONFIG_CGROUPS = y
CONFIG_CGROUP_SCHED = n
CONFIG_HIGH_RES_TIMERS = y
CONFIG_PREEMPT = y
CONFIG_PREEMPT_RT = y
CONFIG_HZ_1000 = y


So this is all that you should have in your configuration fragment addon.
We are trying to get people to separate BSP configuration from policy
with feature addons being incremental blocks of CONFIG_ items aded
at the end.

There's a base policy in place for every linux-yocto based BSP, all
you need to do is turn on the options that you want for your feature.

That way, as we migrate through kernel versions, tweak performance
options, etc, there is a central policy fragment that is changed and
all BSPs are updated. Versus hunting down hundreds of defconfigs, in
various layers and attempting to get them all synchronized and updated.

For non linux-yocto BSPs, as of 1.4 we can share the out of tree
kernel configuration fragments, and implement a similar policy. If we
are seeking to synchronize efforts, trying to use the configuration
extensions that are available makes a lot of sense to me!



# CONFIG_NO_HZ is not set

--


But in the meantime, if you want to enable the support on a yocto BSP,
you can change your "defconfig" to be "sched-deadline.cfg" and only
put the kernel options required to enable the feature.


I will pick up yocto-3.8 bb file from "master" branch and will try
this way shortly.



Sounds good!

Bruce



Regards,

Insop



Cheers,

Bruce




   PV = "3.8"
-PR = "dl7"
+PR = "dl"

   KSRC ?= ""
   S = '${@base_conditional("KSRC", "", "${WORKDIR}/git", "${KSRC}", d)}'

Thank you.

Insop

On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
  wrote:


On 13-03-05 1:54 AM, Insop Song wrote:



Hi,

I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called "meta-dl". I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/




FYI: I've already merged and staged sched_dl in linux-yocto_3.8:


http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf

I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.

Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.

Cheers,

Bruce



With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.


Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.

- problem: adding a new software into my meta-dl layer

- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do "bitbake schedtool-dl -c install" it builds and install,
but at "i586" location instead of my machine staging rootfs
(dl-qemux86)



- Here is my .bb file that pulls an additional program.


https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = "schedtool-dl (scheduler test tool) for deadline
scheduler"
HOMEPAGE = "https://github.com/insop/schedtool-dl";
SECTION = "base"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM =
"file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984"
PR = "r1"

SRC_URI = "git://github.com/insop/schedtool-dl.git;protocol=git"
SRCREV = "${AUTOREV}"

S = "${WORKDIR}/git"

do_compile() {
   oe_runmake
}

do_install() {
   oe_runmake install DESTDIR=${D}
}

PARALLEL_MAKE = ""

BBCLASSEXTEND = "native"

COMPATIBLE_MACHINE_dl-qemux86 = "dl-qemux86"



- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"

# We have a recipes di

Re: [yocto] A question on adding a new program to a new meta layer


On 13-03-07 4:49 PM, Insop Song wrote:


Thanks Juri, I was going to add you to my linux-yocto-3.8 announcement
email and due to some last minute debug activities .. it slipped my
mind. So I'm using this thread to let you, and anyone else that is
interested know that sched_deadline support is available to try out
in linux-yocto-3.8.



Could you also add me in the announcement list?


I can definitely do that.

Also if you sign up for the linux-yo...@yoctoproject.org
mailing list, that's where announcements and kernel feature discussions
happen around linux-yocto. It would be a great place (versus this
main yocto mailing list) to talk about sched_deadline in particular.







As I already told to Insop, I don't have any automated test for the
patchset, but I usually run different scenarios using basically this
two tools (and giving a look at simple cases through kernelshark):

1- schedtool-dl: https://github.com/jlelli/schedtool-dl
 the idea here is to let a 'yes' run through SCHED_DEADLINE and
 check through kernelshark that the bandwidth enforcement
 mechanism works.

2- rt-app: https://github.com/gbagnoli/rt-app
 with this I usually let some tasksets run for several hours on
 a 48-cores machine we have in our lab, I can provide the tasksets
 (json files) and the script to run them.

Please let me know how I can help further.



This is a good start. I have some old references to tests that I'll
dig up as well.



You can check this recipes-tool to find out the above programs
(configuration and installation) in here,
https://github.com/insop/meta-dl/tree/sched-dl-V7/recipes-tools



I'm looking to develop some "real world" examples of the scheduler
class in action, since as we've been saying .. getting those examples
will both help the approach and perhaps help get it merged into the
mainline kernel.



I've been looking application descriptions when I was in Ericsson, and
provided cases to Thomas and Juri.
I am interested in this as well, and include them in easy-to test/validate form.


Great!

Bruce



I will also reply to your other mail shortly.

Regards,

Insop


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

Re: [yocto] A question on adding a new program to a new meta layer


On 13-03-07 5:02 PM, Insop Song wrote:

One observation and question:

1. I can build core-image-minimal/sato with meta-dl (with github 3.8
or yocto-3.8 kernel) with yocto on "danny-8.0" tag
2. I cannot build a successfully bootable core-image-minimal (with
meta-dl) with yocto on "1.4_M4" tag,
the image was stuck during booting..

My build machine is Ubuntu 12.04 LTS.

Before I debug more, I want to check with you to see if there is any
thing that you can think of.
Since I am planning to move to the yocto's master, so that I can pick
up "linux-yocto_3.8.bb".


Nothing comes to mind. It all depends on what target you are using, and
if you are using the 'defconfig' that you mentioned earlier. Switching
to the linux-yocto policy and BSP fragments will likely fix your problem.

Bruce



Thank you,

Insop


On Thu, Mar 7, 2013 at 6:05 AM, Bruce Ashfield
  wrote:

On 13-03-07 03:26 AM, Insop Song wrote:


Hi Bruce,

One more question on 3.8 kernel.
Is "meta/recipes-kernel/linux/linux-yocto_3.8.bb" added soon as well in
1.4?



It's in master as of a few days ago. So it's available and
ready for use.

Cheers,

Bruce




I am using 1.4_M4.final now.

Thank you.

Insop

On Wed, Mar 6, 2013 at 9:05 PM, Insop Song  wrote:


Bruce,

That's very good. I will bring linux-yocto-3.8 kernel to meta-dl.
(https://github.com/insop/meta-dl/tree/linux-yocto-3.8)

The purposes of meta-dl are the following three:
1. easy to use sched_deadline by providing recipes-kernel that includes
- git url including github and from yocto-kernel

2. easy to test and validate sched_deadline with automated
reproducible test suits
- currently, rt-app and schedtool are included in meta-dl
- will add test scripts

3. provide and test on different targets/bsps
- will prepare and test on different targets (bsp)

#1 is done as I've tested with kernel from github from Juri and
yocto-kernel-3.8 that you've merged.
#2 and #3 are in-progress.

I've talked Juri the other day and gather information on testing
methods and scripts so I will include this to meta-dl.

I agree that it's good to coordinate the effort, so please feel free
to let me know if you have any suggestion.

Regards,

Insop

* updated kernel recipes
@ -9,12 +9,15 @@ inherit kernel

   #SRCREV ="031d31cfaa1e0c00122bf52639e340353d3b8360"
   SRCREV ="${AUTOREV}"
-KBRANCH = "sched-dl-V7"
-SRC_URI =
"git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#KBRANCH = "sched-dl-V7"
+#SRC_URI =
"git://github.com/insop/sched-deadline;protocol=git;branch=${KBRANCH}
\
+#   file://defconfig "
+KBRANCH = "standard/edf"
+SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.8;protocol=git;branch=${KBRANCH}
\
  file://defconfig "

   PV = "3.8"
-PR = "dl7"
+PR = "dl"

   KSRC ?= ""
   S = '${@base_conditional("KSRC", "", "${WORKDIR}/git", "${KSRC}", d)}'

Thank you.

Insop

On Wed, Mar 6, 2013 at 8:00 PM, Bruce Ashfield
  wrote:


On 13-03-05 1:54 AM, Insop Song wrote:



Hi,

I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called "meta-dl". I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/




FYI: I've already merged and staged sched_dl in linux-yocto_3.8:


http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/log/?h=standard/edf

I'll be supporting it there as well, so it makes sense to coordinate
our efforts around kernels, configurations and benchmarks.

Juri and I talked about this @ ELC a few weeks ago (I've added
him to the cc as well), and rather than hiding sched_deadline
kernel support in a custom kernel layer, I'd like to try and get
more eyes on it via linux-yocto .. so if we can all coordinate our
efforts here, that would be much better.

Cheers,

Bruce



With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.


Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.

- problem: adding a new software into my meta-dl layer

- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do "bitbake schedtool-dl -c install" it builds and install,
but at "i586" location instead of my machine staging rootfs
(dl-qemux86)



- Here is my .bb file that pulls an additional program.


https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = "schedtool-dl (scheduler test tool) for deadline
scheduler"
HOMEPAGE = "https://github.com/insop/schedtool-dl";
SECTION = "base"

Re: [yocto] uboot.bin and rootfs but not uImage


On 13-03-08 03:46 AM, Khem Raj wrote:


On Mar 3, 2013, at 4:12 AM, Satya Swaroop DAMARLA mailto:swar...@weisser.at>> wrote:


hi Rudy, hi guys

Thank you for the chnages to be made. I always do in two steps, I
fetch all and then compile the image...
After fetching then I renamed the file to defconfig. but can you tell
where should I add "do_fetch_append". Should I add in
linux-skidata.bbappend (if here where should this append file should
be?) or in linux-skidata.bb <http://linux-skidata.bb/> itself?

An other important question is how does the kernel decide about the
device compiler tree... I have several device tree compilers and I
want to know which parameter is used to and where should this
parameter be placed so that the kernel and uboot use the right device
tree compiler. I think this would end my troubles on the whole and I
can start playing witht the kernel in the near future :)


for device tee you would

require recipes-kernel/linux/linux-dtb.inc

in your kernel recipe and then in your machine config
data define KERNEL_DEVICETREE = "${S}/git/.…."
this is the path to dts file and you can have more than
one fie each separated by a space in above definition
resulting dtb files will show up in deploy_dir


Thanks Khem, I had meant to reply to this myself .. and then managed
to forget!

Bruce



HTH

-Khem



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

Re: [yocto] A question on adding a new program to a new meta layer


On 13-03-08 08:27 AM, Insop Song wrote:

On Thu, Mar 7, 2013 at 6:04 AM, Bruce Ashfield
 wrote:

On 13-03-07 12:05 AM, Insop Song wrote:


Bruce,

That's very good. I will bring linux-yocto-3.8 kernel to meta-dl.
(https://github.com/insop/meta-dl/tree/linux-yocto-3.8)



I have another suggestion to offer here, one I've been wanting to
do for a bit.

I've added Darren Hart to the thread, since I'd like to hear from
him on this as well.

I have a use for the scheduling tools and benchmark cases for some
virtualization usecases (meta-virtualization on git.yoctoproject.org).

We already have "recipes-rt" in oe-core, and the preempt-rt kernel
available from linux-yocto, and as we've been discussing I've added
support for EDF/sched_dealine in linux-yocto-3.8.

I'm not a fan of having to many layers, but rather than putting these
efforts in github layers, hiding them in meta-virtualiation and they
aren't yet "core" enough to go in oe-core .. I'd rather see them
conslidated in a "meta-realtime" (or whatever name we decide on)
layer on git.yoctoproject.org.



meta-realtime sounds good to me, and this can include schedulers
real-time application and testing suits.


There are also ideas around interrupt management, AMP, and alternative
system partitioning that I'd like to drive into such a layer.



Good idea to add these continuously to the "meta-realtime"



A quick scan of the layer index, doesn't show anything that matches
this description. So I'm suggesting that we create a new layer
to consolidate these approaches, and a layer that can be consumed by
some of the other layers that are currently in progress.

Comments ? In particular, point out a layer that already does this that
I've missed.




I've took out machine related from my previous meta-dl-qemux86 and put
together meta-realtime as a starting point. It has two sched_deadline
testing program.
It's on github for now for your reference, but I am willing to move or
merge to git.yocto.

https://github.com/insop/meta-realtime


Thanks. I'll have a look, I have my own local meta-realtime as well,
so I can consolidate the two and see about getting them hosted on
git.yoctoproject.org.

Cheers,

Bruce



Thank you,

Insop



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

Re: [yocto] How do I control what kernel modules are being loaded?


On 13-03-08 07:08 AM, Hans Beckérus wrote:

Hi. I have built some custom kernel modules (.ko) using a .bb that
inherits from the module.bbclass. There is one main kernel module and
the rest are dependent on the first. Building and installing the
modules to the rootfs works fine. Next question is how do I control
what actual modules are loaded at boot, or actually how do I control
this through Yocto? To my surprise one of the kernel module loaded
automatically!? How could this happen? I did not have an entry for it
in /etc/modules. And what do I need to do to actually add entries to
/etc/modules? Or is there some other mechanism that I should use. I
tried going through the module.bbclass but must admit I lost it
somewhere in the middle ;) Any guidance would be appreciated.


module_autoload_, in your module recipe, will
trigger the load on boot.

Cheers,

Bruce



Hans
___
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] A question on adding a new program to a new meta layer


On 13-03-08 12:03 PM, Darren Hart wrote:



On 03/07/2013 06:04 AM, Bruce Ashfield wrote:

On 13-03-07 12:05 AM, Insop Song wrote:

Bruce,

That's very good. I will bring linux-yocto-3.8 kernel to meta-dl.
(https://github.com/insop/meta-dl/tree/linux-yocto-3.8)


I have another suggestion to offer here, one I've been wanting to
do for a bit.

I've added Darren Hart to the thread, since I'd like to hear from
him on this as well.

I have a use for the scheduling tools and benchmark cases for some
virtualization usecases (meta-virtualization on git.yoctoproject.org).

We already have "recipes-rt" in oe-core, and the preempt-rt kernel
available from linux-yocto, and as we've been discussing I've added
support for EDF/sched_dealine in linux-yocto-3.8.

I'm not a fan of having to many layers, but rather than putting these
efforts in github layers, hiding them in meta-virtualiation and they
aren't yet "core" enough to go in oe-core .. I'd rather see them
conslidated in a "meta-realtime" (or whatever name we decide on)
layer on git.yoctoproject.org.



I'm fine with that. We should probably consider adding a realtime distro
definition as well at some point soon.


Agreed.






There are also ideas around interrupt management, AMP, and alternative
system partitioning that I'd like to drive into such a layer.

A quick scan of the layer index, doesn't show anything that matches
this description. So I'm suggesting that we create a new layer
to consolidate these approaches, and a layer that can be consumed by
some of the other layers that are currently in progress.

Comments ? In particular, point out a layer that already does this that
I've missed.



No objection. Something outside of core would be better do to the
experimental nature of so much of this stuff.


Also agreed. I'll move on getting some parts of this enabled on the
yocto resources.

Cheers,

Bruce






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

Re: [yocto] How do I control what kernel modules are being loaded?


On 13-03-08 12:40 PM, Hans Beckérus wrote:



8 mar 2013 kl. 18:12 skrev Bruce Ashfield :


On 13-03-08 07:08 AM, Hans Beckérus wrote:

Hi. I have built some custom kernel modules (.ko) using a .bb that
inherits from the module.bbclass. There is one main kernel module and
the rest are dependent on the first. Building and installing the
modules to the rootfs works fine. Next question is how do I control
what actual modules are loaded at boot, or actually how do I control
this through Yocto? To my surprise one of the kernel module loaded
automatically!? How could this happen? I did not have an entry for it
in /etc/modules. And what do I need to do to actually add entries to
/etc/modules? Or is there some other mechanism that I should use. I
tried going through the module.bbclass but must admit I lost it
somewhere in the middle ;) Any guidance would be appreciated.


module_autoload_, in your module recipe, will
trigger the load on boot.

Cheers,

Bruce


Great! But there must be a catch? My actual module package builds six modules. 
One mandatory and the rest are optional. How can it know which modules that 
should actually be loaded? For some to me unknown reason the mandatory one was 
loaded on boot even though I did nothing to my.bb?


I'd assume that udev or some other kernel -> userspace event triggered
the load of the required module.

If you need more advanced logic than modprobe or udev/systemd can provide,
then custom startup scripts for the services would be in order.

Cheers,

Bruce



Hans



Hans
___
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] A question on adding a new program to a new meta layer


On 13-03-08 12:01 PM, Darren Hart wrote:



On 03/04/2013 08:04 PM, Insop Song wrote:

Hi,

I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called "meta-dl". I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/


Note that qemux86 doesn't support the EMGD graphics driver. You mention
this and its license in the README, but it isn't necessary. If you are
pulling that in, there is a problem with your recipes.


wow. mailing list delays are making this conversation *extremely*
painful and disjointed.



I highly recommend you do not use USB keys for real-time storage. I
would also suggest avoiding the hddimg as a test vehicle as it consumes
memory and other resources for the live image. If anything, use the live
image as an installer only.

For some added safety, consider using poky/contrib/ddimage instead of
dd. It is a simple wrapper script around DD which offers a device
blacklist and uses sysfs to present the user with some helpful
information to confirm the operation.

So you are using the sched_deadline patches, but not PREEMPT_RT, is that
right? I had always assumed sched_deadline ran on top of PREEMPT_RT (but
I haven't every tried building it myself).


sched_deadline applies to mainline, right on top of CFS as a scheduler
class. So in fact, I wouldn't suggest it with preempt-rt at all at the
moment.



What you have here is a good experimental layer. Looking forward, please
consider:

o Incorporating sched_deadline as a kernel feature into the
linux-yocto_3.8 kernel. We can easily add recipes to build a
linux-yocto-deadline kernel and you will get all the benefits of the
yocto tooling, testing, bugfixing, and free forward porting.


Already done. I've had it in linux-yocto-3.8 since I first introduced
it. We just need the supporting userspace to easily change the
scheduler class for a process.



o Incorporating your tests into (poky|oe-core)/meta/recipes-rt


Or if they aren't fully 'core', our new meta-realtime that I'd like
to have created shortly.

Cheers,

Bruce





With the help of hands-on kernel lab (thank you Tom and Darren), I am
able to make kernel with sched_deadline enabled.


Now, I am having some trouble of adding testing tools to this meta-dl,
and hope I can get some help from you.

- problem: adding a new software into my meta-dl layer

- symtom and questions?
1. bitbake core-image-minimal (normal image build) won't include the
additional program that I listed in .bb file below
2. If I do "bitbake schedtool-dl -c install" it builds and install,
but at "i586" location instead of my machine staging rootfs
(dl-qemux86)



- Here is my .bb file that pulls an additional program.
https://github.com/insop/meta-dl/blob/sched-dl-V7/recipes-tools/schedtool-dl/schedtool-dl.bb
===
DESCRIPTION = "schedtool-dl (scheduler test tool) for deadline scheduler"
HOMEPAGE = "https://github.com/insop/schedtool-dl";
SECTION = "base"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM =
"file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984"
PR = "r1"

SRC_URI = "git://github.com/insop/schedtool-dl.git;protocol=git"
SRCREV = "${AUTOREV}"

S = "${WORKDIR}/git"

do_compile() {
oe_runmake
}

do_install() {
oe_runmake install DESTDIR=${D}
}

PARALLEL_MAKE = ""



Hopefully you can find the missing dependency in your makefile that
makes this necessary. This slows the build down and cumulatively, this
becomes a problem. This setting should always be considered a band-aid
and should have a comment starting with "FIXME: " ;-)




BBCLASSEXTEND = "native"

COMPATIBLE_MACHINE_dl-qemux86 = "dl-qemux86"



- I've updated my conf/layer.conf file to include above file
https://github.com/insop/meta-dl/blob/sched-dl-V7/conf/layer.conf

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"

# We have a recipes directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "dl-qemux86"
BBFILE_PATTERN_dl-qemux86 := "^${LAYERDIR}/"
BBFILE_PRIORITY_dl-qemux86 = "6"
=



Thank you.

Regards,

Insop


- ref:
1. sched_deadline:
https://events.linuxfoundation.org/events/linuxcon-europe/song
2. sched_deadline:
http://events.linuxfoundation.org/images/stories/slides/elc2013_kobayashi.pdf?a





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

Re: [yocto] How do I control what kernel modules are being loaded?


On 13-03-08 2:00 PM, Hans Beckerus wrote:

On 2013-03-08 7:12, Eric Bénard wrote:

Hi Hans,

Le Fri, 8 Mar 2013 13:08:21 +0100,
Hans Beckérus  a écrit :


Hi. I have built some custom kernel modules (.ko) using a .bb that
inherits from the module.bbclass. There is one main kernel module and
the rest are dependent on the first. Building and installing the
modules to the rootfs works fine. Next question is how do I control
what actual modules are loaded at boot, or actually how do I control
this through Yocto? To my surprise one of the kernel module loaded
automatically!? How could this happen? I did not have an entry for it
in /etc/modules. And what do I need to do to actually add entries to
/etc/modules? Or is there some other mechanism that I should use. I
tried going through the module.bbclass but must admit I lost it
somewhere in the middle ;) Any guidance would be appreciated.


when the module is built by the kernel recipe you can use :
module_autoload and you can see somme usage examples here :
http://cgit.openembedded.org/meta-handheld/tree/conf/machine/palmtx.conf
http://cgit.openembedded.org/meta-handheld/tree/conf/machine/include/palm.inc


maybe you could get inspiration from kernel.bbclass to do the same
thing in your recipe.

Eric

Thanks guys for your quick feedback. I can see that using
module_autoload_${PN} seems like a good approach, if a package maps 1:1
to a module.
In my case that is not so. The package/recipe builds six (or even more)
.ko files using one makefile.
I guess one option could be to split each module build in its own
recipe, but that is not supported by the makefile and thus would require
patching from my side in the source tree. I think the only option I have
left is to try to use /etc/modules and add the modules there in a
do_install_append().
But the problem then is, what happens if some other package also add a
/etc/modules.conf to the image folder? Will it be merged or only copied?
In the latter case last package wins which would not work out very well :(

Out of curiosity, what will module_autoload do? Will it add the .ko to
/etc/modules or does it implement some other mechanism to make a module
load automatically at boot?


It depends on what release you are using. In yocto 1.3 and before the
autoload variables translated to mod-util loading, using just what you'd
think. In yocto 1.4 and kmod in the picture:

# If autoloading is requested, output 
/etc/modules-load.d/.conf and append

# appropriate modprobe commands to the postinst
autoload = d.getVar('module_autoload_%s' % basename, True)
if autoload:
name = '%s/etc/modules-load.d/%s.conf' % (dvar, basename)
f = open(name, 'w')
for m in autoload.split():
f.write('%s\n' % m)
f.close()
postinst = d.getVar('pkg_postinst_%s' % pkg, True)
if not postinst:
bb.fatal("pkg_postinst_%s not defined" % pkg)
postinst += d.getVar('autoload_postinst_fragment', True) % 
autoload

d.setVar('pkg_postinst_%s' % pkg, postinst)

# Write out any modconf fragment
modconf = d.getVar('module_conf_%s' % basename, True)
if modconf:
name = '%s/etc/modprobe.d/%s.conf' % (dvar, basename)
    f = open(name, 'w')
f.write("%s\n" % modconf)
f.close()

Cheers,

Bruce




I do not think that the mandatory module that is loaded originates from
udev. This is a network CM driver that basically hooks into the Linux
network stack. I do not think that udev will ever make this driver load
automatically. But I can not say for sure of course.

Hans



___
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] Can I disable RT throttling?


On 13-03-08 5:36 PM, David Mulder wrote:

Hi.

I’m running a 10us control loop by (under vxWorks) setting one thread’s
priority to max and not yielding ever (letting other tasks run on other
cores), but Linux seems to thwart that capability: Ubuntu swaps out my
thread occasionally for hundreds of microseconds; Yocto prints a
“[sched_delayed] sched: RT throttling activated” message as soon as I
start my thread, so it seems likely that it will swap out my thread
periodically (I’m not quite able to confirm that yet), and even the
fastest thread swap that I’ve heard of is too slow.


You are looking for kernel functionality that doesn't exist yet. In
any SMP system there are sources of cross cpu interference that can't
be removed, if you do, the global state machines of the kernel will
break and the system will eventually come to a halt.

The system is trying to save you from yourself, by throttling the
RT task from taking the entire system down.

There is work in the mainline kernel and -rt communities around cpu
and cpu isolation (some of which we'll try and make available via
the yocto meta-virtualization or meta-realtime layer, when they are
ready), it goes by names such as task_nohz or adaptive_nohz. It's
a complex problem to solve (interrupts, rcu, lapic), and there's not
likely to be anything available in the short term.

That's the mainline/scalable point of view, there are plenty of "custom"
and one off solutions to the problem, such as hotplugging the cpu out
of the system and running in an AMP configuration where a bare metal,
or RTOS can monopolize a CPU since the global state machines don't
interfere. These have their advantages and disadvantages, but if you
are coming from an existing RTOS application, they might be the
closest options to get you the performance you are looking for.

Alternatively, there's the preempt-rt kernel (that we make available
in linux-yocto, if that suits) that if your control loop is
interrupt driven, you'll be closer to your needs since the kernel
is far more preemptible and deterministic and might be able to meet
your deadlines.

There are experimental patches like sched_deadline (EDF) that might
also be applicable, depending on your application architecture.

Searching for "making Linux hard realtime", you'll find plenty of
talks and research over the years for yet more custom ways to get
things done.

So that's my summary, as you can see, it's a long standing, evolving
and complex story .. and not something that likely has an 'out of the
box' solution at the moment.

Cheers,

Bruce



I 0tried changing the kernel’s Preemption Model to “No Forced Preemption
(Server)”, but that didn’t remove the RT throttling message. I browsed
the rest of menuconfig but nothing looked related. I read an article
from 2008 that talked about the kernel reserving 5% of the CPU for
non-SCHED_FIFO tasks, so that’s the direction and terminology I looked
for in menuconfig.

So maybe disabling RT throttling is all I need to do, maybe some other
approach is needed. Hopefully someone will know more than I do.

Thanks!

Dave Mulder



___
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] Can I disable RT throttling?

2013-03-09 Thread Bruce Ashfield

On Sat, Mar 9, 2013 at 12:12 PM, Vin Shelton  wrote:
> On Fri, Mar 8, 2013 at 10:28 PM, Bruce Ashfield
>  wrote:
>> On 13-03-08 5:36 PM, David Mulder wrote:
>>> I’m running a 10us control loop by (under vxWorks) setting one thread’s
>>> priority to max and not yielding ever (letting other tasks run on other
>>> cores), but Linux seems to thwart that capability: Ubuntu swaps out my
>>> thread occasionally for hundreds of microseconds; Yocto prints a
>>> “[sched_delayed] sched: RT throttling activated” message as soon as I
>>> start my thread, so it seems likely that it will swap out my thread
>>> periodically (I’m not quite able to confirm that yet), and even the
>>> fastest thread swap that I’ve heard of is too slow.
>>
>>
>> You are looking for kernel functionality that doesn't exist yet. In
>> any SMP system there are sources of cross cpu interference that can't
>> be removed, if you do, the global state machines of the kernel will
>> break and the system will eventually come to a halt.
>>
>> The system is trying to save you from yourself, by throttling the
>> RT task from taking the entire system down.
>>
>> There is work in the mainline kernel and -rt communities around cpu
>> and cpu isolation (some of which we'll try and make available via
>> the yocto meta-virtualization or meta-realtime layer, when they are
>> ready), it goes by names such as task_nohz or adaptive_nohz. It's
>> a complex problem to solve (interrupts, rcu, lapic), and there's not
>> likely to be anything available in the short term.
>
> At ELC, Steve Rostedt said that this feature is currently targeted at
> the June mainline kernel release, but there's a lot of work still to
> be done, so that's not a firm date.

Absolutely. There's no such thing as a firm date for anything, I (among
others) are following the development closely, testing, and helping wherever
possible.

Cheers,

Bruce

>
> Regards,
>   Vin Shelton
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can I disable RT throttling?

2013-03-10 Thread Bruce Ashfield

On Sun, Mar 10, 2013 at 7:42 AM, Fredrik Markström
 wrote:
> The RT-throttling can be disabled with:
>
> echo -1 >/proc/sys/kernel/sched_rt_runtime_us
> echo -1 >/proc/sys/kernel/sched_rt_period_us
>
> But as mentioned in the other answers things like the system tick, ipi:s
> etc. will interfere. But significantly less then the rt-throttling :)

Absolutely! And as long as you really know what you are doing, you
won't kill the
system .. turning off the throttling definitely gives a bit more rope
to that end as
well :P

Cheers,

Bruce

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



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] A question on adding a new program to a new meta layer

2013-03-10 Thread Bruce Ashfield


On 13-03-09 5:32 AM, Insop Song wrote:

On Fri, Mar 8, 2013 at 3:35 PM, Bruce Ashfield
  wrote:

On 13-03-08 12:01 PM, Darren Hart wrote:




On 03/04/2013 08:04 PM, Insop Song wrote:


Hi,

I am preparing a new meta layer for testing and promoting a
sched_deadline scheduler, called "meta-dl". I am planning to add
scheduler testing tools and different kernel versions as well.
- http://insop.github.com/meta-dl/



Note that qemux86 doesn't support the EMGD graphics driver. You mention
this and its license in the README, but it isn't necessary. If you are
pulling that in, there is a problem with your recipes.



wow. mailing list delays are making this conversation *extremely*
painful and disjointed.



Darren,
Those that you've mentioned were from yocto kernel lab examples.
I went over and cleaned them up. https://github.com/insop/meta-dl

However, at this point, I am more looking at meta-realtime that uses
yocto-linux-3.8 instead as Bruce's suggestion.
https://github.com/insop/meta-realtime



Expect that the yocto project hosted meta-realtime will appear in a
week or so. I'm doing the legwork at the moment, but with some travel
in the upcoming week, the initial push will be delayed by a few days.

Cheers,

Bruce






So you are using the sched_deadline patches, but not PREEMPT_RT, is that
right? I had always assumed sched_deadline ran on top of PREEMPT_RT (but
I haven't every tried building it myself).



sched_deadline applies to mainline, right on top of CFS as a scheduler
class. So in fact, I wouldn't suggest it with preempt-rt at all at the
moment.




Right, previously, Juri maintained sched_deadline on top of
preempt-rt, but not any more.



What you have here is a good experimental layer. Looking forward, please
consider:

o Incorporating sched_deadline as a kernel feature into the
linux-yocto_3.8 kernel. We can easily add recipes to build a
linux-yocto-deadline kernel and you will get all the benefits of the
yocto tooling, testing, bugfixing, and free forward porting.



Already done. I've had it in linux-yocto-3.8 since I first introduced
it. We just need the supporting userspace to easily change the
scheduler class for a process.




Yup, two apps that can test sched_deadline is at meta-realtime now.
I will prepare some script to make it easier as well.



o Incorporating your tests into (poky|oe-core)/meta/recipes-rt



Or if they aren't fully 'core', our new meta-realtime that I'd like
to have created shortly.



I will be playing with meta-realtime at github until you create one.
Please let me know if you have any other requested program on this layer.

Regards,

Insop


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

Re: [yocto] Fwd: How do I control what kernel modules are being loaded?


On 13-03-11 09:28 AM, Hans Beckérus wrote:


On Sat, Mar 9, 2013 at 12:45 AM, Bruce Ashfield
mailto:bruce.ashfi...@windriver.com>> wrote:

On 13-03-08 2:00 PM, Hans Beckerus wrote:

On 2013-03-08 7:12, Eric Bénard wrote:

Hi Hans,

Le Fri, 8 Mar 2013 13:08:21 +0100,
Hans Beckérus mailto:hans.becke...@gmail.com>> a écrit :

Hi. I have built some custom kernel modules (.ko) using
a .bb that
inherits from the module.bbclass. There is one main
kernel module and
the rest are dependent on the first. Building and
installing the
modules to the rootfs works fine. Next question is how
do I control
what actual modules are loaded at boot, or actually how
do I control
this through Yocto? To my surprise one of the kernel
module loaded
automatically!? How could this happen? I did not have an
entry for it
in /etc/modules. And what do I need to do to actually
add entries to
/etc/modules? Or is there some other mechanism that I
should use. I
tried going through the module.bbclass but must admit I
lost it
somewhere in the middle ;) Any guidance would be
appreciated.

when the module is built by the kernel recipe you can use :
module_autoload and you can see somme usage examples here :

http://cgit.openembedded.org/__meta-handheld/tree/conf/__machine/palmtx.conf

<http://cgit.openembedded.org/meta-handheld/tree/conf/machine/palmtx.conf>

http://cgit.openembedded.org/__meta-handheld/tree/conf/__machine/include/palm.inc

<http://cgit.openembedded.org/meta-handheld/tree/conf/machine/include/palm.inc>


maybe you could get inspiration from kernel.bbclass to do
the same
thing in your recipe.

Eric

Thanks guys for your quick feedback. I can see that using
module_autoload_${PN} seems like a good approach, if a package
maps 1:1
to a module.
In my case that is not so. The package/recipe builds six (or
even more)
.ko files using one makefile.
I guess one option could be to split each module build in its own
recipe, but that is not supported by the makefile and thus would
require
patching from my side in the source tree. I think the only
option I have
left is to try to use /etc/modules and add the modules there in a
do_install_append().
But the problem then is, what happens if some other package also
add a
/etc/modules.conf to the image folder? Will it be merged or only
copied?
In the latter case last package wins which would not work out
very well :(

Out of curiosity, what will module_autoload do? Will it add the
.ko to
/etc/modules or does it implement some other mechanism to make a
module
load automatically at boot?


It depends on what release you are using. In yocto 1.3 and before the
autoload variables translated to mod-util loading, using just what you'd
think. In yocto 1.4 and kmod in the picture:

 # If autoloading is requested, output
/etc/modules-load.d/.__conf and append
 # appropriate modprobe commands to the postinst
 autoload = d.getVar('module_autoload_%s' % basename, True)
 if autoload:
 name = '%s/etc/modules-load.d/%s.__conf' % (dvar, basename)
 f = open(name, 'w')
 for m in autoload.split():
 f.write('%s\n' % m)
 f.close()
 postinst = d.getVar('pkg_postinst_%s' % pkg, True)
 if not postinst:
 bb.fatal("pkg_postinst_%s not defined" % pkg)
 postinst += d.getVar('autoload_postinst___fragment',
True) % autoload
 d.setVar('pkg_postinst_%s' % pkg, postinst)

 # Write out any modconf fragment
 modconf = d.getVar('module_conf_%s' % basename, True)
 if modconf:
 name = '%s/etc/modprobe.d/%s.conf' % (dvar, basename)
 f = open(name, 'w')
 f.write("%s\n" % modconf)
 f.close()

Cheers,

Bruce

I do not have much luck getting this to work I am afraid. No matter what
I try with module_autoload it does not seem to have any effect on my
system (no file(s) created in /etc). I have tried adding module_autoload
to both my machine config

Re: [yocto] Fwd: How do I control what kernel modules are being loaded?


On 13-03-11 09:46 AM, Eric Bénard wrote:

Hi Bruce,

Le Mon, 11 Mar 2013 09:37:44 -0400,
Bruce Ashfield  a écrit :

Can you post your exact changes where we can see them ? You need to put
the module_autload variable in a .conf file, whether that be your
local.conf, your machine.conf or you distro configuration file (which
it appears that you are doing), but you also must have the name of
the module package correct, and the module needs to be part of your
IMAGE_INSTALL, since the code fragment I pasted above is from the
post installation fragment created for the various module packages
as they are created.

i.e. I have this in a .conf file:

 module_autoload_nfsd = "nfsd"

To ensure that the nfsd .ko is loaded on boot, when the module is built
and present on the rootfs.


I think the problem is that this works when building modules inside the
kernel (module_autoload is handled in kernel.bbclass), but not when


Not in master anymore, but agreed, we are talking Danny here IIRC.


building a module with its own recipe (using module.bbclass) as Hans
is doing, that's why I previously told him to "get inspiration from
kernel.bbclass to do the same thing in your recipe".


Ah yes. I do recall a nuance of a package with mixed kernel modules and
userspace code.

The new module-split class from master would handle this nicely, so
taking inspiration from master's would would probably be an even
shorter route to getting something working.

Cheers,

Bruce



Eric



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

Re: [yocto] A question on adding a new program to a new meta layer


On 13-03-10 11:32 PM, Insop Song wrote:

On Sun, Mar 10, 2013 at 8:28 PM, Bruce Ashfield


Expect that the yocto project hosted meta-realtime will appear in a
week or so. I'm doing the legwork at the moment, but with some travel
in the upcoming week, the initial push will be delayed by a few days.

Cheers,

Bruce




That's great!
I saw the place holder on the git.yoctoproject this morning.
Please let me know if you need anything for me to do or test.



I've pushed a bit more of the initial layer structure to the repository.
I'm not rationalizing a few items from your existing layers, and similar
repositories into the single meta-realtime.

As an example, I have a schedtool recipe that uses the 
git://gitorious.org/sched_deadline/schedtool-dl.git

repository with a 4 patch series to enable full sched_deadline/EDF
support versus the custom repository that you created on github.
We'll work to unify the edf and other -rt support in the upstream
projects, so we want to reference those trees whenever possible (unless
we get so much development, that a tracking tree makes sense).

Also, don't be concerned that I show up as the only maintainer in the
meta-realtime layer, as I merge parts from your existing layer, credit
will be given and if it is ok with you, I'll have you down as a maintainer
or co-maintainer where it makes sense.

Since I'm going to be out of the office for the next few days, I may
push out my initial merges without much testing, so if you have a
chance to test, and send patches .. that would be a great help.

Cheers,

Bruce


Regards,

Insop



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

Re: [yocto] A question on adding a new program to a new meta layer

On Mon, Mar 11, 2013 at 12:07 PM, Insop Song  wrote:
> On Mon, Mar 11, 2013 at 7:34 AM, Bruce Ashfield
>  wrote:
>>
>> As an example, I have a schedtool recipe that uses the
>> git://gitorious.org/sched_deadline/schedtool-dl.git
>> repository with a 4 patch series to enable full sched_deadline/EDF
>> support versus the custom repository that you created on github.
>> We'll work to unify the edf and other -rt support in the upstream
>> projects, so we want to reference those trees whenever possible (unless
>> we get so much development, that a tracking tree makes sense).
>>
>
> Agree, It's better to unify. I will look into and will update you more on 
> this.
>
>
>> Also, don't be concerned that I show up as the only maintainer in the
>> meta-realtime layer, as I merge parts from your existing layer, credit
>> will be given and if it is ok with you, I'll have you down as a maintainer
>> or co-maintainer where it makes sense.
>>
>> Since I'm going to be out of the office for the next few days, I may
>> push out my initial merges without much testing, so if you have a
>> chance to test, and send patches .. that would be a great help.
>>
>
> Could you tell me how to get the access to the git.yoctoproject?
> If you are busy due to OOO, don't worry on this. I should be able to
> manage in local git until you come back.

If you are looking for push access, we'll wait on that for a bit. I'd like
to throttle changes into the new layer by sending them to the linux-yocto
mailing list first, have some review and then we can do a pull request
and merge model.

Once the things are stable and predictable, we can work on getting merge
access for various maintainers.

Cheers,

Bruce

>
> Thank you.
>
> Insop
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can I disable RT throttling?


On 13-03-11 01:38 PM, David Mulder wrote:

From: Trevor Woerner [mailto:twoer...@gmail.com]
You can call sched_setaffinity() before fork()ing your task, or use
taskset on the cmdline.


Will that work on a core that's offline?


Nope. Only with an online core controlled by the Linux scheduler.
If you do end up trying to get AMP working, you need to plumbing
to load the other OS/kernel in a reserved memory location, set the
program counter and start the OS.

But that secondary OS has to know how to behave in a system that
it doesn't control, and you'll need ways to communicate with it
from Linux.

remoteproc/rpmsg can solve some of the issues that I mention, but
it is far from out of the box.

That's why there's more interest in running a single task with
exclusive CPU in userspace. The work and scaffolding required to
get an AMP system up and running is non trivial.

Cheers,

Bruce


___
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] Can I disable RT throttling?


On 13-03-11 2:13 PM, David Mulder wrote:

Will that work on a core that's offline?


Nope. Only with an online core controlled by the Linux scheduler.
If you do end up trying to get AMP working, you need to plumbing
to load the other OS/kernel in a reserved memory location, set the
program counter and start the OS.

But that secondary OS has to know how to behave in a system that
it doesn't control, and you'll need ways to communicate with it
from Linux.

remoteproc/rpmsg can solve some of the issues that I mention, but
it is far from out of the box.

That's why there's more interest in running a single task with
exclusive CPU in userspace. The work and scaffolding required to
get an AMP system up and running is non trivial.


I kinda thought so, but I was hopeful.

After speaking with some co-workers, I have a new perspective on these delays:  
yes, we are trying to do a 10us control loop, but if we miss a step or two 
occasionally we can accept that.  And looking online I see people indicating 
context switch times well below 10us (Core-i cpus), which is better than I had 
anticipated, and should be workable.  So I'm going to approach this problem by 
just trying to squeeze the kernel as much as I can.  Some things that I see to 
squeeze are /dev/cpu_dma_latency (should be 0) or max_cstate (should be as low 
as possible (0, maybe 1)), possibly idle=poll.  Are there other kernel 
parameters that can minimize kernel interference/time?  And perhaps hints about 
how to set them in Yocto or menuconfig?


There's nothing "out of the box" that I can recommend, outside of saying
"it depends on your platform". It's a matter of knowing your devices,
their interrupts, and the configuration of your kernel. Using things
like CONFIG_NOHZ will remove the timer tick, and hence ticks that you
may not need, you want to move device interrupts off your core, except
for the one that you want. Use cgroups/cpusets to control resources and
the scheduler off your core with "other" tasks. pin/lock memory to
avoid page faults, etc.

If you check out the preempt-rt wiki page on kernel.org, a lot of the
information there applies to making sure that your prioritized thread
gets the most run time that it can.

As we progress with the meta-realtime layer, scripts for the above,
system configuration, services and will be part of the layer and might
be of use.

Cheers,

Bruce




Thanks!
Dave


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

Re: [yocto] [PATCH] [meta-realtime] Add rt-app and define core-image-realtime


On 13-03-14 12:52 PM, Insop Song wrote:

Hi Bruce,

This is for adding rt-app, please let me know what you think.
For next patch, I will add schedtool_dl


This patch looks ok, what are the differences from your original
layer ? I've already imported changes from there, so I'd just
like to hear about differences between the two.

I also have schedtool staged in the tree already, if you wait
until tomorrow, I can push that tree and you can test and extend
that base.

Cheers,

Bruce



Regards,

Insop

--

- "rt-app" is a test application that starts multiple periodic threads
   in order to simulate a real-time periodic load

   - run example

   root@qemux86:~# rt-app -t 10:35000:d -D 1
   [rt-app]  [0] Using SCHED_DEADLINE policy:
   [rt-app]  [0] starting thread with period: 10, exec:
   35000,deadline: 10, priority: 10
   [rt-app]  [0] Locking pages in memory
   deadline dur.slack   Budget  Used Budget
   010  35000   35000   64705   305724113   305759126
   30582410535013   64979
   010  35000   35000   165100  305824508   305859531
   
   010  35000   35000   864955  306524363   306559381
   30662410535019   64724
   010  35000   35000   965099  306624507   306659526
   30672410535019   64578
   [rt-app]  [0] Exiting.
---
  recipes-extended/images/core-image-realtime.bb |   12 +
  ...adline-as-a-default-to-go-around-yocto-bu.patch |   26 ++
  recipes-tools/rt-app/rt-app.bb |   28 
  3 files changed, 66 insertions(+)
  create mode 100644 recipes-extended/images/core-image-realtime.bb
  create mode 100644
recipes-tools/rt-app/files/0001-set-with-deadline-as-a-default-to-go-around-yocto-bu.patch
  create mode 100644 recipes-tools/rt-app/rt-app.bb

diff --git a/recipes-extended/images/core-image-realtime.bb
b/recipes-extended/images/core-image-realtime.bb
new file mode 100644
index 000..624aacf
--- /dev/null
+++ b/recipes-extended/images/core-image-realtime.bb
@@ -0,0 +1,12 @@
+require recipes-core/images/core-image-minimal-dev.bb
+
+DEPENDS = "linux-yocto"
+
+IMAGE_FEATURES += "package-management ssh-server-dropbear"
+EXTRA_IMAGE_FEATURES = "tools-debug debug-tweaks tools-profile dbg-pkgs"
+
+IMAGE_INSTALL = "\
+   ${CORE_IMAGE_BASE_INSTALL} \
+   rt-app \
+   libgcc \
+   "
diff --git 
a/recipes-tools/rt-app/files/0001-set-with-deadline-as-a-default-to-go-around-yocto-bu.patch
b/recipes-tools/rt-app/files/0001-set-with-deadline-as-a-default-to-go-around-yocto-bu.patch
new file mode 100644
index 000..a697e89
--- /dev/null
+++ 
b/recipes-tools/rt-app/files/0001-set-with-deadline-as-a-default-to-go-around-yocto-bu.patch
@@ -0,0 +1,26 @@
+From 041b2b65889c44c47f90313c5bf9ce61effa96df Mon Sep 17 00:00:00 2001
+From: Insop Song 
+Date: Sat, 9 Mar 2013 01:23:24 -0800
+Subject: [PATCH] set "--with-deadline" as a default to go around yocto build
+ error on deadline enabled
+
+---
+ configure.ac |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index a5e2990..64e57e4 100644
+--- a/configure.ac
 b/configure.ac
+@@ -34,7 +34,7 @@ AC_ARG_WITH([deadline],
+   [AS_HELP_STRING([--with-deadline],
+  [Add support for SCHED_DEADLINE])],
+   [],
+-  [with_deadline=no])
++  [with_deadline=yes])
+
+ AS_IF([test "x$with_deadline" != xno],
+   [AC_DEFINE([DLSCHED], [1], [Define if you have SCHED_DEADLINE support])
+--
+1.7.9.5
+
diff --git a/recipes-tools/rt-app/rt-app.bb b/recipes-tools/rt-app/rt-app.bb
new file mode 100644
index 000..acce437
--- /dev/null
+++ b/recipes-tools/rt-app/rt-app.bb
@@ -0,0 +1,28 @@
+DESCRIPTION = "rt-app is a test application that starts multiple
periodic threads in order to simulate a real-time periodic load"
+SECTION = "devel"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM =
"file://COPYING;endline=339;md5=e43fc16fccd8519fba405f0a0ff6e8a3"
+PR = "r1"
+
+SRCREV = "e81cbe9f76ee298feded17bb7455d4deb2fb32af"
+
+SRC_URI = "git://github.com/gbagnoli/rt-app.git \
+   file://0001-set-with-deadline-as-a-default-to-go-around-yocto-bu.patch \
+   "
+
+S = "${WORKDIR}/git"
+
+inherit autotools gettext pkgconfig
+
+do_configure_prepend() {
+   autoreconf --install --verbose --force
+}
+
+do_install() {
+   install -d ${D}${bindir}
+   install -m 0755 src/rt-app ${D}${bindir}
+}
+
+FILES_{PN} = "${bindir}/rt-app"
+
+PARALLEL_MAKE = ""



___
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] [PATCH] [meta-realtime] Add rt-app and define core-image-realtime


On 13-03-14 12:52 PM, Insop Song wrote:

Hi Bruce,

This is for adding rt-app, please let me know what you think.
For next patch, I will add schedtool_dl


Reading this more closely, can you split this into two patches ?
We need to review this in chunks, patch 1 for the rt-app (it
looks fine), and another for the image definition ?

oe-core already has core-image-rt and core-image-rt-sdk, so the
naming and content here will be a bit confusing. We should
determine where we want the image definition, and if we can
simply extend the oe-core ones versus introducing new ones.

Cheers,

Bruce



Regards,

Insop

--

- "rt-app" is a test application that starts multiple periodic threads
   in order to simulate a real-time periodic load

   - run example

   root@qemux86:~# rt-app -t 10:35000:d -D 1
   [rt-app]  [0] Using SCHED_DEADLINE policy:
   [rt-app]  [0] starting thread with period: 10, exec:
   35000,deadline: 10, priority: 10
   [rt-app]  [0] Locking pages in memory
   deadline dur.slack   Budget  Used Budget
   010  35000   35000   64705   305724113   305759126
   30582410535013   64979
   010  35000   35000   165100  305824508   305859531
   
   010  35000   35000   864955  306524363   306559381
   30662410535019   64724
   010  35000   35000   965099  306624507   306659526
   30672410535019   64578
   [rt-app]  [0] Exiting.
---
  recipes-extended/images/core-image-realtime.bb |   12 +
  ...adline-as-a-default-to-go-around-yocto-bu.patch |   26 ++
  recipes-tools/rt-app/rt-app.bb |   28 
  3 files changed, 66 insertions(+)
  create mode 100644 recipes-extended/images/core-image-realtime.bb
  create mode 100644
recipes-tools/rt-app/files/0001-set-with-deadline-as-a-default-to-go-around-yocto-bu.patch
  create mode 100644 recipes-tools/rt-app/rt-app.bb

diff --git a/recipes-extended/images/core-image-realtime.bb
b/recipes-extended/images/core-image-realtime.bb
new file mode 100644
index 000..624aacf
--- /dev/null
+++ b/recipes-extended/images/core-image-realtime.bb
@@ -0,0 +1,12 @@
+require recipes-core/images/core-image-minimal-dev.bb
+
+DEPENDS = "linux-yocto"
+
+IMAGE_FEATURES += "package-management ssh-server-dropbear"
+EXTRA_IMAGE_FEATURES = "tools-debug debug-tweaks tools-profile dbg-pkgs"
+
+IMAGE_INSTALL = "\
+   ${CORE_IMAGE_BASE_INSTALL} \
+   rt-app \
+   libgcc \
+   "
diff --git 
a/recipes-tools/rt-app/files/0001-set-with-deadline-as-a-default-to-go-around-yocto-bu.patch
b/recipes-tools/rt-app/files/0001-set-with-deadline-as-a-default-to-go-around-yocto-bu.patch
new file mode 100644
index 000..a697e89
--- /dev/null
+++ 
b/recipes-tools/rt-app/files/0001-set-with-deadline-as-a-default-to-go-around-yocto-bu.patch
@@ -0,0 +1,26 @@
+From 041b2b65889c44c47f90313c5bf9ce61effa96df Mon Sep 17 00:00:00 2001
+From: Insop Song 
+Date: Sat, 9 Mar 2013 01:23:24 -0800
+Subject: [PATCH] set "--with-deadline" as a default to go around yocto build
+ error on deadline enabled
+
+---
+ configure.ac |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index a5e2990..64e57e4 100644
+--- a/configure.ac
 b/configure.ac
+@@ -34,7 +34,7 @@ AC_ARG_WITH([deadline],
+   [AS_HELP_STRING([--with-deadline],
+  [Add support for SCHED_DEADLINE])],
+   [],
+-  [with_deadline=no])
++  [with_deadline=yes])
+
+ AS_IF([test "x$with_deadline" != xno],
+   [AC_DEFINE([DLSCHED], [1], [Define if you have SCHED_DEADLINE support])
+--
+1.7.9.5
+
diff --git a/recipes-tools/rt-app/rt-app.bb b/recipes-tools/rt-app/rt-app.bb
new file mode 100644
index 000..acce437
--- /dev/null
+++ b/recipes-tools/rt-app/rt-app.bb
@@ -0,0 +1,28 @@
+DESCRIPTION = "rt-app is a test application that starts multiple
periodic threads in order to simulate a real-time periodic load"
+SECTION = "devel"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM =
"file://COPYING;endline=339;md5=e43fc16fccd8519fba405f0a0ff6e8a3"
+PR = "r1"
+
+SRCREV = "e81cbe9f76ee298feded17bb7455d4deb2fb32af"
+
+SRC_URI = "git://github.com/gbagnoli/rt-app.git \
+   file://0001-set-with-deadline-as-a-default-to-go-around-yocto-bu.patch \
+   "
+
+S = "${WORKDIR}/git"
+
+inherit autotools gettext pkgconfig
+
+do_configure_prepend() {
+   autoreconf --install --verbose --force
+}
+
+do_install() {
+   install -d ${D}${bindir}
+   install -m 0755 src/rt-app ${D}${bindir}
+}
+
+FILES_{PN} = "${bindir}/rt-app"
+
+PARALLEL_MAKE = ""



___
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] [meta-realtime][PATCH] add sched_deadline reckpies-kernel for 3.8 kernel


On 13-03-14 10:09 PM, Insop Song wrote:

Hi Bruce,

I've added recipes-kernel to use edf branch and cfg.


FYI: your email keeps bouncing from the linux-yocto mailing list,
check to be sure you signed up with your gmail account, I keep
approving them for now :)



- tested on qemux86
===

root@qemux86:~# uname -a
Linux qemux86 3.8.1-yocto-standard #1 SMP PREEMPT Thu Mar 14 21:57:12
PDT 2013 i686 GNU/Linux
root@qemux86:~# rt-app -t 10:35000:d -D 2
[rt-app]  [0] Using SCHED_DEADLINE policy:
[rt-app]  [0] starting thread with period: 10, exec:
35000,deadline: 10, priority: 10
[rt-app]  [0] Locking pages in memory
#idxperiod  min_et  max_et  rel_st  start   end 
deadlinedur.slack   Budget  Used
Budget
0   10  35000   35000   65466   354577907   354612918   
354677899   35011   64981
0   10  35000   35000   165585  354678026   354713105   
354777899   35079   64794
...
0   10  35000   35000   1965672 356478113   356513126   
356577899   35014   64772
[rt-app]  [0] Exiting.
root@qemux86:~#

===

Let me know what you think.

Regards,

Insop

===


Subject: [meta-realtime][PATCH] add sched_deadline reckpies-kernel for 3.8
  kernel

---
  recipes-kernel/linux/linux-yocto/edf.cfg  |4 
  recipes-kernel/linux/linux-yocto_3.8.bbappend |   14 ++
  2 files changed, 18 insertions(+)
  create mode 100644 recipes-kernel/linux/linux-yocto/edf.cfg
  create mode 100644 recipes-kernel/linux/linux-yocto_3.8.bbappend

diff --git a/recipes-kernel/linux/linux-yocto/edf.cfg
b/recipes-kernel/linux/linux-yocto/edf.cfg
new file mode 100644
index 000..ccf004f
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/edf.cfg
@@ -0,0 +1,4 @@
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_DEADLINE_GROUP_SCHED=y


We don't need this fragment in recipe space, it's already in the
kernel tree itself.

I've already sent the pull request for the meta SRCREVs to be updated,
so it's available for all builds now.


+
diff --git a/recipes-kernel/linux/linux-yocto_3.8.bbappend
b/recipes-kernel/linux/linux-yocto_3.8.bbappend
new file mode 100644
index 000..c6a969f
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_3.8.bbappend
@@ -0,0 +1,14 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+COMPATIBLE_MACHINE_qemux86 = "qemux86"
+COMPATIBLE_MACHINE_fri2 = "fri2"


These are already taken care of by meta-intel, we don't need to
duplicate them here.


+
+KBRANCH_qemux86 = "standard/edf"
+KBRANCH_fri2 = "standard/edf"
+
+KMACHINE_qemux86 = "qemux86"
+KMACHINE_fri2 = "fri2"


We don't need these two KMACHINE lines, this is the default.

Cheers,

Bruce


+
+SRCREV_machine_qemux86 = "62d98f6b12f91cc7419b88dfa2e0abe077c94f9f"
+SRCREV_machine_fri2 = "62d98f6b12f91cc7419b88dfa2e0abe077c94f9f"
+
+KERNEL_FEATURES_append =" cfg/edf.scc"



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

Re: [yocto] [meta-realtime][PATCH] add sched_deadline reckpies-kernel for 3.8 kernel

On Thu, Mar 14, 2013 at 10:59 PM, Insop Song  wrote:
> On Thu, Mar 14, 2013 at 10:15 PM, Bruce Ashfield
>  wrote:
>
>>
>> FYI: your email keeps bouncing from the linux-yocto mailing list,
>> check to be sure you signed up with your gmail account, I keep
>> approving them for now :)
>>
>
> I've signed up last time you suggested, I will try one more and send a
> separate email to the arbiter.

Hmm. One of the arbiters is me .. if it doesn't work this time, let me know
and I'll check the list membership.

> Thank you for reminding me.
>
>>
>>>
>>> - tested on qemux86
>>> ===
>>>
>>> root@qemux86:~# uname -a
>>> Linux qemux86 3.8.1-yocto-standard #1 SMP PREEMPT Thu Mar 14 21:57:12
>>> PDT 2013 i686 GNU/Linux
>>> root@qemux86:~# rt-app -t 10:35000:d -D 2
>>> [rt-app]  [0] Using SCHED_DEADLINE policy:
>>> [rt-app]  [0] starting thread with period: 10, exec:
>>> 35000,deadline: 10, priority: 10
>>> [rt-app]  [0] Locking pages in memory
>>> #idxperiod  min_et  max_et  rel_st  start   end
>>> deadlinedur.slack   Budget  Used
>>> Budget
>>> 0   10  35000   35000   65466   354577907   354612918
>>> 354677899   35011   64981
>>> 0   10  35000   35000   165585  354678026   354713105
>>> 354777899   35079   64794
>>> ...
>>> 0   10  35000   35000   1965672 356478113   356513126
>>> 356577899   35014   64772
>>> [rt-app]  [0] Exiting.
>>> root@qemux86:~#
>>>
>>> ===
>>>
>>> Let me know what you think.
>>>
>>> Regards,
>>>
>>> Insop
>>>
>>> ===
>>>
>>>
>>> Subject: [meta-realtime][PATCH] add sched_deadline reckpies-kernel for 3.8
>>>   kernel
>>>
>>> ---
>>>   recipes-kernel/linux/linux-yocto/edf.cfg  |4 
>>>   recipes-kernel/linux/linux-yocto_3.8.bbappend |   14 ++
>>>   2 files changed, 18 insertions(+)
>>>   create mode 100644 recipes-kernel/linux/linux-yocto/edf.cfg
>>>   create mode 100644 recipes-kernel/linux/linux-yocto_3.8.bbappend
>>>
>>> diff --git a/recipes-kernel/linux/linux-yocto/edf.cfg
>>> b/recipes-kernel/linux/linux-yocto/edf.cfg
>>> new file mode 100644
>>> index 000..ccf004f
>>> --- /dev/null
>>> +++ b/recipes-kernel/linux/linux-yocto/edf.cfg
>>> @@ -0,0 +1,4 @@
>>> +CONFIG_CGROUPS=y
>>> +CONFIG_CGROUP_SCHED=y
>>> +CONFIG_DEADLINE_GROUP_SCHED=y
>>
>>
>> We don't need this fragment in recipe space, it's already in the
>> kernel tree itself.
>>
>> I've already sent the pull request for the meta SRCREVs to be updated,
>> so it's available for all builds now.
>>
>>
>
> removed.
>
>>> +
>>> diff --git a/recipes-kernel/linux/linux-yocto_3.8.bbappend
>>> b/recipes-kernel/linux/linux-yocto_3.8.bbappend
>>> new file mode 100644
>>> index 000..c6a969f
>>> --- /dev/null
>>> +++ b/recipes-kernel/linux/linux-yocto_3.8.bbappend
>>> @@ -0,0 +1,14 @@
>>> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>> +COMPATIBLE_MACHINE_qemux86 = "qemux86"
>>> +COMPATIBLE_MACHINE_fri2 = "fri2"
>>
>>
>> These are already taken care of by meta-intel, we don't need to
>> duplicate them here.
>>
>>
>
> You meant two lines of "COMPATIBLE_MACHINE..."?
> removed.

Correct! and thanks!

>
>>> +
>>> +KBRANCH_qemux86 = "standard/edf"
>>> +KBRANCH_fri2 = "standard/edf"
>>> +
>>> +KMACHINE_qemux86 = "qemux86"
>>> +KMACHINE_fri2 = "fri2"
>>
>>
>> We don't need these two KMACHINE lines, this is the default.
>>
>
> removed.
>
> I was do some testing on "make localmodconfig", which will gets me the
> using module build .config.
> So let me me ask you this before I send out an updated patch.
>
> I ran "lsmod > /tmp/lsmod" on my qemux86
> On dev host, run "make LSMOD=/tmp/lsmod localmodconfig" to get this
> localmodconfig_qemux86.cfg file, which has less module configurations.
>
> Then I use this in bbappend file like below:
>
> ---
> SRC_URI = 
> "git://git.yocto

Re: [yocto] [meta-realtime][PATCH] add sched_deadline reckpies-kernel for 3.8 kernel

On Thu, Mar 14, 2013 at 10:09 PM, Insop Song  wrote:
> Hi Bruce,
>
> I've added recipes-kernel to use edf branch and cfg.

I was just merging your changes, and realized that gmail may have dropped
your schedtool-dl recipe.

Can you resend it with your updated series ? I have another schedtool
recipe here, but it's against an older sched_dl release, so I'd like to
compare it to yours and merge the two of them together.

Cheers,

Bruce

>
> - tested on qemux86
> ===
>
> root@qemux86:~# uname -a
> Linux qemux86 3.8.1-yocto-standard #1 SMP PREEMPT Thu Mar 14 21:57:12
> PDT 2013 i686 GNU/Linux
> root@qemux86:~# rt-app -t 10:35000:d -D 2
> [rt-app]  [0] Using SCHED_DEADLINE policy:
> [rt-app]  [0] starting thread with period: 10, exec:
> 35000,deadline: 10, priority: 10
> [rt-app]  [0] Locking pages in memory
> #idxperiod  min_et  max_et  rel_st  start   end 
> deadlinedur.slack   Budget  Used
> Budget
> 0   10  35000   35000   65466   354577907   354612918   
> 354677899   35011   64981
> 0   10  35000   35000   165585  354678026   354713105   
> 354777899   35079   64794
> ...
> 0   10  35000   35000   1965672 356478113   356513126   
> 356577899   35014   64772
> [rt-app]  [0] Exiting.
> root@qemux86:~#
>
> ===
>
> Let me know what you think.
>
> Regards,
>
> Insop
>
> ===
>
>
> Subject: [meta-realtime][PATCH] add sched_deadline reckpies-kernel for 3.8
>  kernel
>
> ---
>  recipes-kernel/linux/linux-yocto/edf.cfg  |4 
>  recipes-kernel/linux/linux-yocto_3.8.bbappend |   14 ++
>  2 files changed, 18 insertions(+)
>  create mode 100644 recipes-kernel/linux/linux-yocto/edf.cfg
>  create mode 100644 recipes-kernel/linux/linux-yocto_3.8.bbappend
>
> diff --git a/recipes-kernel/linux/linux-yocto/edf.cfg
> b/recipes-kernel/linux/linux-yocto/edf.cfg
> new file mode 100644
> index 000..ccf004f
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-yocto/edf.cfg
> @@ -0,0 +1,4 @@
> +CONFIG_CGROUPS=y
> +CONFIG_CGROUP_SCHED=y
> +CONFIG_DEADLINE_GROUP_SCHED=y
> +
> diff --git a/recipes-kernel/linux/linux-yocto_3.8.bbappend
> b/recipes-kernel/linux/linux-yocto_3.8.bbappend
> new file mode 100644
> index 000..c6a969f
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-yocto_3.8.bbappend
> @@ -0,0 +1,14 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +COMPATIBLE_MACHINE_qemux86 = "qemux86"
> +COMPATIBLE_MACHINE_fri2 = "fri2"
> +
> +KBRANCH_qemux86 = "standard/edf"
> +KBRANCH_fri2 = "standard/edf"
> +
> +KMACHINE_qemux86 = "qemux86"
> +KMACHINE_fri2 = "fri2"
> +
> +SRCREV_machine_qemux86 = "62d98f6b12f91cc7419b88dfa2e0abe077c94f9f"
> +SRCREV_machine_fri2 = "62d98f6b12f91cc7419b88dfa2e0abe077c94f9f"
> +
> +KERNEL_FEATURES_append =" cfg/edf.scc"
> --
> 1.7.9.5
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-realtime][PATCH] add sched_deadline reckpies-kernel for 3.8 kernel


On 13-03-14 11:36 PM, Insop Song wrote:

On Thu, Mar 14, 2013 at 11:13 PM, Bruce Ashfield
 wrote:




Hmm. One of the arbiters is me .. if it doesn't work this time, let me know
and I'll check the list membership.


I've just signed up and got a confirmation email.




I was do some testing on "make localmodconfig", which will gets me the
using module build .config.
So let me me ask you this before I send out an updated patch.

I ran "lsmod > /tmp/lsmod" on my qemux86
On dev host, run "make LSMOD=/tmp/lsmod localmodconfig" to get this
localmodconfig_qemux86.cfg file, which has less module configurations.

Then I use this in bbappend file like below:

---
SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-3.8.git;protocol=git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta
\
 file://localmodconfig_qemux86.cfg \
 "


what do you think?


We want to track the modules and policies of the main qemu BSP,
not override them all here. Extra layers should be only changing board
functionality that is specific to their functionality, not the base board
configuration.

If you think there are modules that are enabled that shouldn't be, we
can address that by looking at the base policy and deciding if that
base policy is wrong.

Cheers,



I see, let me follow up the current patch update and do some more look
on qemu bsp and deal with a separate patch.

Here are the update patches 2/2.

And let me know if you want to see in different ways of patch
delivery? since, I haven't set up my gmail smtp set up yet (due to
application specific athentication), so I manually copy and paste and
attach the files.


Are you trying to send via git send-email ? The following is the
way that I'd relay through gmail:

  > git send-email --smtp-server smtp.gmail.com --smtp-user 
bruce.ashfi...@gmail.com --smtp-pass  --smtp-ssl ~/rr/


And to generate the patches and introductory email, look at
the oe-core scripts/create-pull-request.

That's the best and easiest way to send patches.


--


Subject: [meta-realtime][PATCH 2/2] remove edf.cfg and follow up review
  feedback

---
  recipes-kernel/linux/linux-yocto/edf.cfg  |4 
  recipes-kernel/linux/linux-yocto_3.8.bbappend |5 -
  2 files changed, 9 deletions(-)
  delete mode 100644 recipes-kernel/linux/linux-yocto/edf.cfg


This looks good. I'll stage it locally and do a quick test build.

Cheers,

Bruce



diff --git a/recipes-kernel/linux/linux-yocto/edf.cfg
b/recipes-kernel/linux/linux-yocto/edf.cfg
deleted file mode 100644
index ccf004f..000
--- a/recipes-kernel/linux/linux-yocto/edf.cfg
+++ /dev/null
@@ -1,4 +0,0 @@
-CONFIG_CGROUPS=y
-CONFIG_CGROUP_SCHED=y
-CONFIG_DEADLINE_GROUP_SCHED=y
-
diff --git a/recipes-kernel/linux/linux-yocto_3.8.bbappend
b/recipes-kernel/linux/linux-yocto_3.8.bbappend
index c6a969f..175ab91 100644
--- a/recipes-kernel/linux/linux-yocto_3.8.bbappend
+++ b/recipes-kernel/linux/linux-yocto_3.8.bbappend
@@ -1,13 +1,8 @@
  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-COMPATIBLE_MACHINE_qemux86 = "qemux86"
-COMPATIBLE_MACHINE_fri2 = "fri2"

  KBRANCH_qemux86 = "standard/edf"
  KBRANCH_fri2 = "standard/edf"

-KMACHINE_qemux86 = "qemux86"
-KMACHINE_fri2 = "fri2"
-
  SRCREV_machine_qemux86 = "62d98f6b12f91cc7419b88dfa2e0abe077c94f9f"
  SRCREV_machine_fri2 = "62d98f6b12f91cc7419b88dfa2e0abe077c94f9f"



___
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] [linux-yocto] [meta-realtime][PATCH] add sched_deadline reckpies-kernel for 3.8 kernel


On 13-03-14 11:44 PM, Bruce Ashfield wrote:

On 13-03-14 11:36 PM, Insop Song wrote:

On Thu, Mar 14, 2013 at 11:13 PM, Bruce Ashfield
 wrote:




Hmm. One of the arbiters is me .. if it doesn't work this time, let
me know
and I'll check the list membership.


I've just signed up and got a confirmation email.




I was do some testing on "make localmodconfig", which will gets me the
using module build .config.
So let me me ask you this before I send out an updated patch.

I ran "lsmod > /tmp/lsmod" on my qemux86
On dev host, run "make LSMOD=/tmp/lsmod localmodconfig" to get this
localmodconfig_qemux86.cfg file, which has less module configurations.

Then I use this in bbappend file like below:

---
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.8.git;protocol=git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta

\
 file://localmodconfig_qemux86.cfg \
 "


what do you think?


We want to track the modules and policies of the main qemu BSP,
not override them all here. Extra layers should be only changing board
functionality that is specific to their functionality, not the base
board
configuration.

If you think there are modules that are enabled that shouldn't be, we
can address that by looking at the base policy and deciding if that
base policy is wrong.

Cheers,



I see, let me follow up the current patch update and do some more look
on qemu bsp and deal with a separate patch.

Here are the update patches 2/2.

And let me know if you want to see in different ways of patch
delivery? since, I haven't set up my gmail smtp set up yet (due to
application specific athentication), so I manually copy and paste and
attach the files.


Are you trying to send via git send-email ? The following is the
way that I'd relay through gmail:

   > git send-email --smtp-server smtp.gmail.com --smtp-user
bruce.ashfi...@gmail.com --smtp-pass  --smtp-ssl ~/rr/

And to generate the patches and introductory email, look at
the oe-core scripts/create-pull-request.

That's the best and easiest way to send patches.


--


Subject: [meta-realtime][PATCH 2/2] remove edf.cfg and follow up review
  feedback

---
  recipes-kernel/linux/linux-yocto/edf.cfg  |4 
  recipes-kernel/linux/linux-yocto_3.8.bbappend |5 -
  2 files changed, 9 deletions(-)
  delete mode 100644 recipes-kernel/linux/linux-yocto/edf.cfg


This looks good. I'll stage it locally and do a quick test build.


I hit send too soon, I meant to point out that in a situation such
as this, you can ammend your original commit with your second set
of change and re-submit just the single patch. I can squash the
commits here, but it's easier to do on your end.

Just summarize the v2 in your new patch email when you ammend/squash
changes, so we won't forget what was changed :)

Cheers,

Bruce



Cheers,

Bruce



diff --git a/recipes-kernel/linux/linux-yocto/edf.cfg
b/recipes-kernel/linux/linux-yocto/edf.cfg
deleted file mode 100644
index ccf004f..000
--- a/recipes-kernel/linux/linux-yocto/edf.cfg
+++ /dev/null
@@ -1,4 +0,0 @@
-CONFIG_CGROUPS=y
-CONFIG_CGROUP_SCHED=y
-CONFIG_DEADLINE_GROUP_SCHED=y
-
diff --git a/recipes-kernel/linux/linux-yocto_3.8.bbappend
b/recipes-kernel/linux/linux-yocto_3.8.bbappend
index c6a969f..175ab91 100644
--- a/recipes-kernel/linux/linux-yocto_3.8.bbappend
+++ b/recipes-kernel/linux/linux-yocto_3.8.bbappend
@@ -1,13 +1,8 @@
  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-COMPATIBLE_MACHINE_qemux86 = "qemux86"
-COMPATIBLE_MACHINE_fri2 = "fri2"

  KBRANCH_qemux86 = "standard/edf"
  KBRANCH_fri2 = "standard/edf"

-KMACHINE_qemux86 = "qemux86"
-KMACHINE_fri2 = "fri2"
-
  SRCREV_machine_qemux86 = "62d98f6b12f91cc7419b88dfa2e0abe077c94f9f"
  SRCREV_machine_fri2 = "62d98f6b12f91cc7419b88dfa2e0abe077c94f9f"



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



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


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

Re: [yocto] remove /boot/uImage and /usr/share/terminfo


On 13-03-15 06:33 AM, Hans Beckérus wrote:

Hi. In an effort to shrink our rootfs by some major numbers we found two
low-hanging fruits that we would like to address before cherry picking
and removing lots of good linux functionality. We have no need for the
uImage (3MB) stored in /boot and also we can leave out the terminfo tree
(2.5MB).
My question here now is if the build system provide functionality to
actually tell the image builder not to include these specific components?


From kernel.bbclass, you just need to clear RDEPENDS_kernel-base
in your .conf files:

# Allow machines to override this dependency if kernel image files are
# not wanted in images as standard
RDEPENDS_kernel-base ?= "kernel-image"

You'll still get your kernel modules installed after making this change.

Bruce


Or do we need to write some post installer for our rootfs that mounts
the image, removes the files, and then umount it?
If we remove inclusion of any kernel modules it seems that /boot is
never populated? But we need the modules. Also, what package brings in
terminfo?
Is it as simple as writing a .bbappend to remove it att deploy time?

Hans



___
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] building yocto image from git always switches branch


On 13-03-15 02:02 AM, Volker Vogelhuber wrote:

Volker Vogelhuber  writes:


When I change to the build directory and start building the image using
bitbake, there seems to be a git call somewhere in the recipes that
switches the branch of the poky git checkout back to master. Of course
that results in a total misbehaviour of the build process, as the
underlaying recipes changes during the build.

It turned out, my own kernel recipe included
recipes-kernel/linux/linux-yocto.inc
which seems to require that the kernel is checked out from a git
repository. After removing this include and only inherit from
kernel.bbclass it worked as expected.


Interesting. Are you working out of yocto/oe-core master ? The linux
yocto kernel support should always fail if the kernel source dir
isn't a git repo (or convert it into one) and not impact the main
yocto/oe-core tree.

Cheers,

Bruce




___
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] remove /boot/uImage and /usr/share/terminfo


On 13-03-15 07:36 AM, Hans Beckérus wrote:



On Fri, Mar 15, 2013 at 3:20 PM, Bruce Ashfield
mailto:bruce.ashfi...@windriver.com>> wrote:

On 13-03-15 06:33 AM, Hans Beckérus wrote:

Hi. In an effort to shrink our rootfs by some major numbers we
found two
low-hanging fruits that we would like to address before cherry
picking
and removing lots of good linux functionality. We have no need
for the
uImage (3MB) stored in /boot and also we can leave out the
terminfo tree
(2.5MB).
My question here now is if the build system provide functionality to
actually tell the image builder not to include these specific
components?


 From kernel.bbclass, you just need to clear RDEPENDS_kernel-base
in your .conf files:

# Allow machines to override this dependency if kernel image files are
# not wanted in images as standard
RDEPENDS_kernel-base ?= "kernel-image"

You'll still get your kernel modules installed after making this change.

Bruce


Thanks Bruce.How could I have missed that? I believe I scanned through
the kernel.bbclass for something like this.
Also got some good tip regarding /usr/share/terminfo? Guess I need to
figure out what package drags it in ;)


Not off the top of my head. Hopefully someone else with experience in
that area will notice the traffic and jump in :)

I'm fairly certain that is is controllable, since in the past, I've
known it to be removed and tuned for small systems, so it's not a
completely uncommon thing to do.

Cheers,

Bruce



Hans



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

Re: [yocto] [PATCH 1/1] add scheedtool-dl for testing sched_deadline use jiri's github as a main repo


On 13-03-15 04:47 AM, Insop Song wrote:

---
  recipes-extended/images/core-image-realtime.bb |1 +
  recipes-tools/schedtool-dl/schedtool-dl.bb |   23 +++
  2 files changed, 24 insertions(+)
  create mode 100644 recipes-tools/schedtool-dl/schedtool-dl.bb

diff --git a/recipes-extended/images/core-image-realtime.bb 
b/recipes-extended/images/core-image-realtime.bb
index 624aacf..386b16b 100644
--- a/recipes-extended/images/core-image-realtime.bb
+++ b/recipes-extended/images/core-image-realtime.bb
@@ -8,5 +8,6 @@ EXTRA_IMAGE_FEATURES = "tools-debug debug-tweaks tools-profile 
dbg-pkgs"
  IMAGE_INSTALL = "\
${CORE_IMAGE_BASE_INSTALL} \
rt-app \
+   schedtool-dl \
libgcc \
"


This part of the patch is still a problem, so I'll drop  it on merge.
We still need to rationalize why we can't extend the oe-core
rt images:

./recipes-rt/images/core-image-rt.bb
./recipes-rt/images/core-image-rt-sdk.bb

For this addition. Until we work through that, you can carry a local
patch, or add the tools back via your local.conf adding it to IMAGE_INSTALL.


diff --git a/recipes-tools/schedtool-dl/schedtool-dl.bb 
b/recipes-tools/schedtool-dl/schedtool-dl.bb
new file mode 100644
index 000..6b298f1
--- /dev/null
+++ b/recipes-tools/schedtool-dl/schedtool-dl.bb
@@ -0,0 +1,23 @@
+DESCRIPTION = "schedtool-dl (scheduler test tool) for deadline scheduler"
+SECTION = "devel"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = 
"file://Makefile;endline=55;md5=e4b4e8ed9c2132e1d727a1bb5e3bd984"
+PR = "r1"
+
+SRC_URI = "git://github.com/jlelli/schedtool-dl.git;protocol=git"
+SRCREV = "${AUTOREV}"


We also want to lock down the SRCREV vs autorev. I'd expect that going 
forward,

you can maintain/update this once we've merged it, so when a SRCREV
is known to be good, you can send update patches with the new values
(just like I do with linux-yocto in oe-core). But in the general case,
we want to have consistent and reproducible builds and to do that,
we need a well defined SRCREV.

So one more version of the series and we should be good (you can
drop the image addition as part of that) .. sorry for all the
iterations, the first merges always take the longest.

Cheers,

Bruce


+
+S = "${WORKDIR}/git"
+
+do_compile() {
+   oe_runmake
+}
+
+do_install() {
+   install -d ${D}${bindir}
+   install -m 0755 schedtool ${D}${bindir}
+}
+
+FILES_{PN} = "${bindir}/schedtool"
+
+PARALLEL_MAKE = ""



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

Re: [yocto] building yocto image from git always switches branch