Re: [yocto] Can I disable RT throttling?

[Bruce Ashfield]

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] How do I control what kernel modules are being loaded?

[Bruce Ashfield]

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

[Bruce Ashfield]

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] Licencing OpenSource fonts

[Trevor Woerner]

On Fri, Mar 8, 2013 at 12:15 PM, Chris Tapp  wrote:
> In the 7 hours it's taken this to get to the list (no ideas where it got 
> stuck!)

I'm seeing emails arrive hours after their date-stamps too. In fact
this email just arrived in my inbox, but according to the date stamp,
you sent it 5 hours ago!
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Can I disable RT throttling?

[David Mulder]

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.

I tried 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

Re: [yocto] ERROR: Nothing RPROVIDES 'mdev'

[Khem Raj]

On Mar 8, 2013, at 7:02 AM, Hans Beckérus  wrote:

> Hi. I get his error when trying to override udev with mdev
> 
> ERROR: Nothing RPROVIDES 'mdev' (but 
> /poky/meta/recipes-core/packagegroups/packagegroup-core-boot.bb RDEPENDS on 
> or otherwise requires it)
> 
> is it not possible to replace udev with mdev?
> 
> What I have done is adding the following to the distro/mydistro.conf
> 
> VIRTUAL-RUNTIME_dev_manager = "mdev"
> 
> In packagegroup-core-boot.bb it looks like it should be possible, but then 
> how to do it?
> 
> packagegroup-core-boot.bb:
> ...
> # Distro can override the following VIRTUAL-RUNTIME providers:
> VIRTUAL-RUNTIME_dev_manager ?= "udev"
> VIRTUAL-RUNTIME_login_manager ?= "tinylogin"
> VIRTUAL-RUNTIME_init_manager ?= "sysvinit"
> VIRTUAL-RUNTIME_initscripts ?= "initscripts"
> VIRTUAL-RUNTIME_keymaps ?= "keymaps"
> …
> 

Look ar poky-tiny.conf distro


> 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] How do I control what kernel modules are being loaded?

[Hans Beckerus]

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


Coming to think about it, module_autoload should actually specify 
module, not package right?
That would work then. But is this only supported in a machine.conf? Can 
it not be used also in e.g. the image.bb or a distro.conf?
The reason is that I do not have a machine.conf in my highest layer! My 
layer is a simple distro that does not have any real knowledge of what 
hardware it is running on. My local.conf points out the actual MACHINE.  
The kernel modules are not hardware dependent either since they are pure 
network extensions so it would be wrong to have them in the machine.conf.


Hans


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

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

[Trevor Woerner]

On Fri, Mar 8, 2013 at 7:08 AM, Hans Beckérus  wrote:
> I
> tried going through the module.bbclass but must admit I lost it
> somewhere in the middle ;) Any guidance would be appreciated.

Have you had a chance to look at the Yocto hands-on kernel lab?
https://lists.yoctoproject.org/pipermail/yocto/2013-February/014408.html
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Patching gcc-4.7.2 to add support for Xilinx MicroBlaze

[Trevor Woerner]

On Fri, Mar 8, 2013 at 2:07 AM, Khem Raj  wrote:
> We have moved away
> from snapshots for gcc since git repo for gcc is in terabytes and

It sure would be nice if git had a feature whereby one could grab just
a specific snapshot without any history, or meta-information etc...
just the code of one specific hash.

(btw, I'm aware of shallow clones, they don't do what I'm asking for)
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Hans Beckerus]

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?


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

Re: [yocto] SDK-only build

[Trevor Woerner]

Hi Khem,

Thanks for adding your thoughts; you were exactly who I was hoping
would have input to my question :-)

On Fri, Mar 8, 2013 at 3:59 AM, Khem Raj  wrote:
>> Sometimes I like to work with a "sub-Linux" device, something that is
>> too small to run Linux, or a device on which, for whatever reason,
>> I've decided I don't want to run Linux.
>
> However adding a pure bare metal
> SDK generation is a whole different story and may be out of scope here
>
>> I've been wondering lately if, theoretically, it would be possible to
>> use yocto to create a development environment for such projects
>> (specifically an SDK).

I watched the video of your presentation a couple years ago at some
ELC(E?) where you discussed using Yocto to generate an SDK. That
presentation struck a chord with me because I know exactly how I would
use such an SDK. I knew, of course, of using Yocto to create a Linux
distribution, and I was aware of creating a -dev form of that
distribution for doing development on the target, but I wasn't aware
of the SDK option for putting together the -native programs, sysroot,
and cross-development tools for independent development for a given
distribution.

I recently started working with a Cortex-M4 based device. Knowing that
simply pushing my code to github wasn't going to help many people
unless I provided instructions on how to setup an environment to work
with the code and the device, I wrote a script that aims to easily
setup someone's environment to be the same as mine. Setting up an
environment involves generating cross-development tools, building a
set of native tools which are used with the device (for example some
sort of flash programmer or openOCD), and having a sysroot-like area
populated with libraries, linker scripts, and header files specific to
the device which the cross-development tools can find without
requiring any -L and -I options.

The whole time I was writing my script I couldn't help think to myself
how nice it would be to be able to write recipes instead of a script,
how nice it would be to make use of bitbake's fetchers, and the
ability to apply patches etc., and then have that all wrapped up into
a nice, self-extracting SDK! Why re-invent the wheel?

Somehow I can't help think this could/should be possible. I can
perform all the necessary steps by hand, but when I consider using
OE/Yocto I feel a bit overwhelmed. Maybe all I need is just bitbake?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Eric Bénard]

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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Bruce Ashfield]

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] How do I control what kernel modules are being loaded?

[Hans Beckérus]

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?

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

[Bruce Ashfield]

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] Licencing OpenSource fonts

[Chris Tapp]

On 8 Mar 2013, at 10:18, Chris Tapp wrote:

> Sorry if this is off-topic for this list, but I'm hoping that someone on here 
> may be able to help with a licensing question.
> 
> I am working on a document which is to be published using the Google 'Open 
> Sans' font. This is licensed under an Apache Licence.
> 
> The licence lists all the 'usual' things to do when distributing / modifying 
> the font, but it doesn't say what to do if the font is used.
> 
> We plan to add something like "This document was typeset using OpenSans; this 
> font is distributed under the terms of the Apache licence — see 
> www.apache.org/licenses/LICENSE-2.0.html" to the acknowledgements section of 
> the document. Would we need to go further than this?

In the 7 hours it's taken this to get to the list (no ideas where it got 
stuck!) we've changed our words to reflect the information in the font itself:

"This document was typeset using Open Sans. Open Sans is a trademark of Google 
and may be registered in certain jurisdictions. Digitized data copyright © 
2010-2011, Google Corporation. Licensed under the Apache License, Version 2.0"

Chris Tapp

opensou...@keylevel.com
www.keylevel.com



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

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

[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



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] Problem with applying a patch using default -pnum

[Hans Beckérus]

On Fri, Mar 8, 2013 at 2:49 AM, Daniel Lazzari wrote:

> > On 2013-03-07 8:11, Jerrod Peach wrote:
> > > Hans,
> > >
> > > Are you sure you're seeing the patch system use $WORKDIR instead of $S
> > > as the root for patching?  I've had to do a lot of patching in our own
> > > layers recently and I've always seen $S used as the root for the
> > > patch.  Are you explicitly setting S = "${WORKDIR}/git"?  That's what
> > > we do for our git recipes.  That's how you get the system to recognize
> > > the source somewhere other than just $WORKDIR.
> > >
> > > As for specifying a different -pnum, you absolutely can do that like
> so:
> > >
> > > /SRC_URI += "file://my-change.patch*;striplevel=X*"/
> > >
> > > X is the pnum that you want.  Its default value is 1.
> > >
> > > You may also find this page useful -- it contains all sorts of hints
> > > for setting up your recipes in a Yocto-standard way:
> > >
> > > https://wiki.yoctoproject.org/wiki/Recipe_&_Patch_Style_Guide
> > >
> > > That's where I learned about striplevel and the preference for it over
> > > the deprecated pnum parameter.
> > >
> > > Kind regards,
> > >
> > > Jerrod
> > >
> > >
> > Hi Jarod. Thanks, the pointer you gave will most certainly be of great
> aid. I will
> > try the striplevel approach instead of writing my own do_patch()
> override.
> > Regarding how certain I am that the root folder is ${WORKDIR} when
> > patching, not at all ;) In my do_patch() function is simply did `pwd`
> and it was
> > not set to ${S} as I set it to.
> > That does not mean that the built-in patch system is using ${WORKDIR}, I
> am
> > aware of that.
> > Things here is, even though my patch is placed in ${W} and I set ${S} to
> eg.
> > ${W}/git/some/folder, why would it not work? In another package I set
> ${S}
> > to ${WORKDIR}/git and it works just fine. I can not understand why
> setting
> > ${S} to something else breaks the logic?
> > It's not that bitbake can not find the patch file, it definitely does
> that, but the
> > -pnum seems to get messed up. But maybe that is the whole point of having
> > the striplevel=X in the first place.
> >
> > Hans
> >
> >
> > >
> > >
> > >
> > >
> > > On Thu, Mar 7, 2013 at 7:33 AM, Hans Beck?rus  > > > wrote:
> > >
> > > On Thu, Mar 7, 2013 at 1:12 PM, Hans Beck?rus
> > > mailto:hans.becke...@gmail.com>>
> > wrote:
> > > > Hi. More problems ;)
> > > > I have a patch file that needs to be applied to a source tree
> > > and the
> > > > patch file is copied properly to the ${WORKDIR} directory.
> > > > So far so good. But, the problem with this source tree is that
> it is
> > > > not built from the traditional root folder of the repo.
> > > > This means I need to change ${S} to point somewhere else. This
> also
> > > > causes the patch system to fail!
> > > > I did an override of do_patch() in my .bb and that seems to
> > > work, but
> > > > I do not like to use overrides unless I really have to.
> > > > So basically, is there some way to tell the built-in patch
> system to
> > > > use a different -pnum value?
> > > > If there is, I could stick with the do_patch() as provided by
> > > default.
> > > >
> > > > Hans
> > >
> > > Hmm, ok a correction from my side. Forget parts of what I said ;)
> > > The patch system does not seem to use the value of ${S}, it is
> using
> > > ${WORKDIR} as the root for patching, this is also where the patch
> file
> > > is placed. The problem in my case does not seem to be that is built
> > > from a non-standard path. The reason why it fails seems to be
> because
> > > the actual source is not in ${WORKDIR}, it is in ${WORKDIR}/git.
> The
> > > patch file does include git as part of the source path for obvious
> > > reasons. What am I doing wrong? Having actual source code in
> > > ${WORKDIR}/git I assume is very common for git based downloads.
> > >
> > > Hans
> > > ___
> > > yocto mailing list
> > > yocto@yoctoproject.org 
> > > https://lists.yoctoproject.org/listinfo/yocto
> > >
> > >
>
> I also found another useful patch param called patchdir that sets the
> directory from which the patch is applied. This is useful when ${S} is set
> to a directory deeper than you want to patch from but don't want to mess
> with setting ${S}. I needed it to apply a patch to wpa_supplicant's src
> directory.
>
> Ex.
>
> file://gpio-sysfs-power-onoff-change.patch;patchdir=${WORKDIR}/wpa_supplicant-${PV}
>
> Thanks Daniel, that did the trick for me!
I set my patchdir=${W}/git and then used S=${W}/git/some/where/else as
build source.
No more need to override do_patch() :)

Hans

Daniel Lazzari Jr.
> Firmware Engineer
> dlazz...@leapfrog.com
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yo

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

[Darren Hart]

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.


> 
> 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.


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
___
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

[Darren Hart]

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.

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).

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.

o Incorporating your tests into (poky|oe-core)/meta/recipes-rt

> 
> 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
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Patching gcc-4.7.2 to add support for Xilinx MicroBlaze

[Elvis Dowson]

Hi Khem,

On Mar 8, 2013, at 6:47 PM, Khem Raj  wrote:

>> | configure: error: cannot compute suffix of object files: cannot compile
>> | See `config.log' for more details.
>> | make: *** [configure-target-libgcc] Error 1
> 
> seems some missing header or libs but doesn't say much. where is config.log ?

Here is the build report against the gcc-4.7.2 build:

| checking for microblaze-poky-linux-gcc...  
/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/./gcc/xgcc
 
-B/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/./gcc/
 -m32-mhard-float  
-isystem/tool/yocto/poky/build/tmp/sysroots/spartan-6-sp601-microblaze/usr/include
 
-B/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/bin/
 
-B/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/lib/
 -isystem 
/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/include
 -isystem 
/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/sys-include
 
--sysroot=/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/tmpsysroot
| checking for suffix of object files... configure: error: in 
`/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/microblaze-poky-linux/libgcc':
| configure: error: cannot compute suffix of object files: cannot compile
| See `config.log' for more details.
| make: *** [configure-target-libgcc] Error 1
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (see 
/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/temp/log.do_compile.31442
 for further information)

Some of the errors in the libgcc/config.log file are as follows:

xgcc: error: unrecognized command line option '-m32'
configure:3355: $? = 0
configure:3344:  
/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/./gcc/xgcc
 
-B/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/./gcc/
 -m32-mhard-float  
-isystem/tool/yocto/poky/build/tmp/sysroots/spartan-6-sp601-microblaze/usr/include
 
-B/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/bin/
 
-B/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/lib/
 -isystem 
/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/include
 -isystem 
/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/sys-include
 
--sysroot=/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/tmpsysroot
   -v >&5
xgcc: error: unrecognized command line option '-m32'
Reading specs from 
/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/./gcc/specs
COLLECT_GCC=/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/./gcc/xgcc
COLLECT_LTO_WRAPPER=/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/./gcc/lto-wrapper
Target: microblaze-poky-linux
Configured with: 
/tool/yocto/poky/build/tmp/work-shared/gcc-4.7.2-r19/gcc-4.7.2/configure 
--build=x86_64-linux --host=x86_64-linux --target=microblaze-poky-linux 
--prefix=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr 
--exec_prefix=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr 
--bindir=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/microblaze-poky-linux.gcc-cross-initial
 
--sbindir=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/microblaze-poky-linux.gcc-cross-initial
 
--libexecdir=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/libexec/microblaze-poky-linux.gcc-cross-initial
 --datadir=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/share 
--sysconfdir=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/etc 
--sharedstatedir=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/com 
--localstatedir=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/var 
--libdir=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/lib/microblaze-poky-linux.gcc-cross-
 initial 
--includedir=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/include 
--oldincludedir=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/include 
--infodir=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/share/info 
--mandir=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/share/man 
--disable-silent-rules --disable-dependency-tracking 
--with-libtool-sysroot=/tool/yocto/poky/build/tmp/sysroots/x86_64

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

[Bruce Ashfield]

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

[yocto] ERROR: Nothing RPROVIDES 'mdev'

[Hans Beckérus]

Hi. I get his error when trying to override udev with mdev

ERROR: Nothing RPROVIDES 'mdev' (but /poky/meta/recipes-core/packagegroups/
packagegroup-core-boot.bb RDEPENDS on or otherwise requires it)

is it not possible to replace udev with mdev?

What I have done is adding the following to the distro/mydistro.conf

*VIRTUAL-RUNTIME_dev_manager = "mdev"*

In packagegroup-core-boot.bb it looks like it should be possible, but then
how to do it?

packagegroup-core-boot.bb:
...
*# Distro can override the following VIRTUAL-RUNTIME providers:
VIRTUAL-RUNTIME_dev_manager ?= "udev"
VIRTUAL-RUNTIME_login_manager ?= "tinylogin"
VIRTUAL-RUNTIME_init_manager ?= "sysvinit"
VIRTUAL-RUNTIME_initscripts ?= "initscripts"
VIRTUAL-RUNTIME_keymaps ?= "keymaps"*
...

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

Re: [yocto] Patching gcc-4.7.2 to add support for Xilinx MicroBlaze

[Khem Raj]

On Mar 8, 2013, at 2:28 AM, Elvis Dowson  wrote:

> | configure: error: cannot compute suffix of object files: cannot compile
> | See `config.log' for more details.
> | make: *** [configure-target-libgcc] Error 1

seems some missing header or libs but doesn't say much. where is config.log ?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Bruce Ashfield]

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  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

[Insop Song]

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

Thank you,

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

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

[Hans Beckérus]

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.

Hans
___
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

[Insop Song]

Moved to master and built 3.8 with "standard/edf" branch and all working fine.

Thank you.

Insop

On Thu, Mar 7, 2013 at 5:47 PM, Bruce Ashfield
 wrote:
> 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,
>>>

Re: [yocto] Patching gcc-4.7.2 to add support for Xilinx MicroBlaze

[Elvis Dowson]

Hi Khem,
  After patching both gcc-4.7.2 and gcc-4.8.0, I get the 
following error. This looks like a common error, and I was wondering if there 
is something that needs to be additionally taken into consideration, in the 
poky gcc recipes (gcc-configure-*.inc) to get it to work for the microblaze 
processor?

The output log is from the gcc-4.8.0 build, but the same message persists with 
the gcc-4.7.2 adapted build with the microblaze patches:

| checking for microblaze-poky-linux-gcc...  
/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.8.0-r01/gcc-4.8.0/build.x86_64-linux.microblaze-poky-linux/./gcc/xgcc
 
-B/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.8.0-r01/gcc-4.8.0/build.x86_64-linux.microblaze-poky-linux/./gcc/
 -m32   
-isystem/tool/yocto/poky/build/tmp/sysroots/spartan-6-sp601-microblaze/usr/include
 
-B/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/bin/
 
-B/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/lib/
 -isystem 
/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/include
 -isystem 
/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/sys-include
 
--sysroot=/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.8.0-r01/gcc-4.8.0/build.x86_64-linux.microblaze-poky-linux/tmpsysroot
| checking for suffix of object files... configure: error: in 
`/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.8.0-r01/gcc-4.8.0/build.x86_64-linux.microblaze-poky-linux/microblaze-poky-linux/libgcc':
| configure: error: cannot compute suffix of object files: cannot compile
| See `config.log' for more details.
| make: *** [configure-target-libgcc] Error 1
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (see 
/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.8.0-r01/temp/log.do_compile.32684
 for further information)

Best regards,

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

Re: [yocto] qemu not getting dhcp question.

[Insop Song]

Hi Khem,

>
> runqemu already assigns a static IP to instance and it does not use bridging
> so dhcp from a server which is not the machine on which qemu is running will 
> not work
>
>

Right, this testing was from my own meta-dl-qemux86 (custom kernel and recipes).
https://github.com/insop/meta-dl

The image that I've created did not use static IP but attempted to get
dhcp, so that' was the issue.
I still have to look at what was the issue within my image (meta
layer), but now I've moved to latest yocto-kernel-3.8 and the image
uses the static IP.

Thank you.

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

[yocto] Licencing OpenSource fonts

[Chris Tapp]

Sorry if this is off-topic for this list, but I'm hoping that someone on here 
may be able to help with a licensing question.

I am working on a document which is to be published using the Google 'Open 
Sans' font. This is licensed under an Apache Licence.

The licence lists all the 'usual' things to do when distributing / modifying 
the font, but it doesn't say what to do if the font is used.

We plan to add something like "This document was typeset using OpenSans; this 
font is distributed under the terms of the Apache licence — see 
www.apache.org/licenses/LICENSE-2.0.html" to the acknowledgements section of 
the document. Would we need to go further than this?

Any pointers would be greatly appreciated!

Chris Tapp

opensou...@keylevel.com
www.keylevel.com



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

Re: [yocto] qemu not getting dhcp question.

[Khem Raj]

On Mar 5, 2013, at 9:10 PM, Insop Song  wrote:

> Hi all,
> 
> I've built a new meta layer image based on core-image-minimal and
> core-image-sato.
> 
> After the successful build, whey I run "runqemu" with the image, my
> qemu image won't get a dhcp IP.
> I can manually assign IP after the boot up.
> 
> Does anyone know why or which log to look at?

runqemu already assigns a static IP to instance and it does not use bridging
so dhcp from a server which is not the machine on which qemu is running will 
not work


> 
> Here is the message from qemu
> -
> Configuring network interfaces... udhcpc (v1.20.2) started
> Sending discover...
> Sending discover...
> Sending discover...
> No lease, failing
> [   20.280668] rc (824) used greatest stack depth: 5632 bytes left
> INIT: Entering runlevel: 5
> Starting syslogd/klogd: done
> Stopping Bootlog daemon: bootlogd.
> --
> 
> Here is the host side message
> --
> $ runqemu tmp/deploy/images/bzImage-3.8-dl7-dl-qemux86-20130303034712.bin
> tmp/deploy/images/core-image-minimal-dev-dl-qemux86-20130306045344.rootfs.ext3
> Set MACHINE to [qemux86] based on kernel
> [tmp/deploy/images/bzImage-3.8-dl7-dl-qemux86-20130303034712.bin]
> 
> Continuing with the following parameters:
> KERNEL: [tmp/deploy/images/bzImage-3.8-dl7-dl-qemux86-20130303034712.bin]
> ROOTFS: 
> [tmp/deploy/images/core-image-minimal-dev-dl-qemux86-20130306045344.rootfs.ext3]
> FSTYPE: [ext3]
> Setting up tap interface under sudo
> Acquiring lockfile for tap0...
> WARNING: distccd not present, no distcc support loaded.
> Running qemu-system-i386...
> /home/insop/mybuilds/dl/tmp/sysroots/x86_64-linux/usr/bin/qemu-system-i386
> -kernel tmp/deploy/images/bzImage-3.8-dl7-dl-qemux86-20130303034712.bin
> -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no
> -hda 
> tmp/deploy/images/core-image-minimal-dev-dl-qemux86-20130306045344.rootfs.ext3
> -show-cursor -usb -usbdevice wacom-tablet -vga vmware -no-reboot -m
> 128 --append "vga=0 root=/dev/hda rw mem=128M
> ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 "
> -
> 
> Thank you,
> 
> Insop
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

[yocto] Regarding Licensing of "mbsalign.c" available in util-linux-2.21.2 version (Yocto-1.3-Danny)

[Gaurang Shastri]

Hi All,

I have some concerns regarding util-linux-2.21.2 version . As per Yocto-1.3
(danny) recipe,
{{{

LICENSE_${PN}-lscpu = "GPLv3+"  <-- util-linux_2.21.2.bb

LICENSE = "GPLv2+ & LGPLv2.1+ & BSD"   <-- util-linux.inc

}}}

So as per the above description, only lscpu is GPLv3.

But while looking into the source of util-linux-2.21.2, I found out that
"util-linux-2.21.2/lib/mbsalign.c" is GPLv3 and it is used by following
binaries while building:
{{{
  -  fdisk
  -  partx
}}}

So does it mean that the above binaries should also be GPLv3 and need to
take care in util-linux.{bb,inc} ???

Regards,
Gaurang Shastri
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] how to handle a source tree with both user-space and kernel module sources

[Khem Raj]

On Mar 4, 2013, at 9:53 AM, Hans Beckérus  wrote:

> How could a package that is part of one single git repo but contains
> both user-space libraries and several kernel modules be built?
> Is there some existing "best praxis" that could be applied?
> Currently what we have done is to split this into two recipes, one
> that inherits from autotools and the other that inherit from module.
> This works fine, but... The problem now is that there will be two
> copies of the source repo, one in each package. Is there some way that
> a recipe can
> inherit from both autotools and module and thus use two different S
> targets? Or is our current approach the only way to easily do this,
> and thus having two copies
> of the repo is just a side-effect that we simply need to accept?
> Splitting the source repo is almost out of the questions since they
> are heavily dependent on shared header files etc.
> 

having two recipes is a good approach.  You can beat app and module
builds into same recipe but recipe becomes quite cluttered so its your priority
what you would prefer. 

> 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] Trying to bitbake core-image-minimal on Archlinux

[Khem Raj]

On Mar 3, 2013, at 10:02 AM, Ismael Barros²  wrote:

> Hi there,
> 
> I'm new to Yocto, and I keep finding errors that prevent me from building a 
> minimal image.
> 
> I've just installed poky-danny-8.0, sourced oe-init-build-env, and bitbaked 
> core-image-minimal. The first error is that bitbake sanity checks fail to 
> detect the network access, while my network connectivity is perfect, and 
> downloading packages seem to work if I disable this checks. Full log: 
> http://pastebin.com/6jJCC1qp. I couldn't find any log that told me which 
> piece of code was failing, so I jut disabled this check on 
> ../meta-yocto/conf/distro/poky.conf
> 
> Upon trying again, building started fine, but it started failing to build the 
> documentation for some packages, i.e. binutils-cross. First off, I want to 
> build a single mission appliance, I don't really want to build any 
> documentation, is there any way I can disable it? Anyway, this is the build 
> log: http://pastebin.com/n9U4GfjG. Looks like there are some texinfo commands 
> my machine (texinfo 5.0) doesn't recognice. According to 
> http://sourceware.org/bugzilla/show_bug.cgi?id=15183, it's a known bug on 
> binuilts-2.22 and it's fixed on binuilts-2.23.

Archlinux version you might be using may not be one of sanitized distro for 
building danny
you could have upgrades to components that are pre-requisites for building 
binutils cross

if you can try to use one of sanitized distros on your build host that way you 
can avoid some
of these issues.

> 
> Poking around, looks like "updating" to binutils-2.23 got it kind of working:

thats invasive change for danny to back port. May be you can try latest master 
and upcoming
release 1.4 if you can afford that

> 
> mv ./meta/recipes-devtools/binutils/binutils-2.22.inc 
> ./meta/recipes-devtools/binutils/binutils-2.23.1.inc
> mv ./meta/recipes-devtools/binutils/binutils-cross-canadian_2.22.bb 
> ./meta/recipes-devtools/binutils/binutils-cross-canadian_2.23.1.bb
> mv ./meta/recipes-devtools/binutils/binutils_2.22.bb 
> ./meta/recipes-devtools/binutils/binutils_2.23.1.bb
> mv ./meta/recipes-devtools/binutils/binutils-crosssdk_2.22.bb 
> ./meta/recipes-devtools/binutils/binutils-crosssdk_2.23.1.bb
> mv ./meta/recipes-devtools/binutils/binutils-cross_2.22.bb 
> ./meta/recipes-devtools/binutils/binutils-cross_2.23.1.bb
> 
> I also had to update the md5 and sha1 on 
> ./meta/recipes-devtools/binutils/binutils-2.23.1.inc. After that, some 
> patches failed to apply: libtool-2.4-update.patch, 
> binutils-2.19.1-ld-sysroot.patch, binutils-poison.patch, 
> libtool-rpath-fix.patch, clone-shadow.patch... so gave up
> What would be the appropiate way to workaround this issue, besides not using 
> Archlinux?
> 
> Btw, if the bitbake core-image-minimal fails because there's not enough disk 
> space, and the free disk in the partition is left to 0, after that even the 
> bitbake clean command fails :\
> 
> 
> Anyway, thank you guys for what seems to be an excellent BSP factory, I'm 
> really looking forward to start using it at our company :)
> 
> Kind regards,
> Ismael
> ___
> 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] SDK-only build

[Khem Raj]

On Mar 2, 2013, at 8:47 AM, Trevor Woerner  wrote:

> I've been really blown away by the breadth of the Yocto Project; not
> only will it help you create a distribution for a device but it can
> also help you create things like a -dev image or a self-extracting
> SDK.
> 
> Sometimes I like to work with a "sub-Linux" device, something that is
> too small to run Linux, or a device on which, for whatever reason,
> I've decided I don't want to run Linux.

you could add  -ffreestanding  -nostdlib and -nodefaultlibs to compiler
and it would compile bare-metal apps but you may need to provide
libgcc if needed. You may not be able to use the one shipped with
toolchain in SDK since it is for Linux env. However adding a pure bare metal
SDK generation is a whole different story and may be out of scope here


> 
> I've been wondering lately if, theoretically, it would be possible to
> use yocto to create a development environment for such projects
> (specifically an SDK). Sometimes these devices need specialized
> software tools (e.g. flash programmers), or maybe you need to use the
> vendor's special, hacked-up version of binutils/gcc.
> 
> Often these projects have instructions pages on how to setup your
> environment, and for the most part these instructions work fine and
> will produce something which with you can work. But sometimes the
> development environments they create are... strange. For example,
> they'll leave you having to provide long argument lists to gcc so they
> can find all the relevant headers and libraries. Nothing tragic, but
> just cumbersome.
> 
> It would be nice, I think, to be able to create a yocto layer and
> provide recipes that would allow a user to very easily bitbake a
> development environment for, say, an ST Discovery board. These
> recipes, then, would follow the vendor's instructions, but using yocto
> all these instructions could be performed with one simple step (which
> would then make use of bitbake's powerful fetching, sstate, and
> cross-building tools).
> 
> Is the concept of "I'm going to build a distribution/root-filesystem
> for you" too deeply engrained in the logic of the Yocto Project that
> it couldn't be used to only build -native tools and assemble an SDK?
> ___
> 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] Problem with Xserver freezing

[Burton, Ross]

On 7 March 2013 20:49, Satya Swaroop Damarla  wrote:
> I created a X11 image and I found that the init is freezing. Advice
> regarding configuring Xorg is very much appreciated. If I remove
> Xinitialization from init then its properly starting. my board is a
> specialized version of Nvidia Tegra Harmony board.

That X log doesn't contain any information that's useful, you'll have
to dig around the other logs in /var or alternatively disable X from
the startup and then start it manually with options like --verbose.

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

Re: [yocto] Trying to bitbake core-image-minimal on Archlinux

[Burton, Ross]

On 7 March 2013 15:22, Biao  wrote:
> One dummy question, how to find out the list of all "sanity tested distro",
> i just saw a long list from the output of "git tag".

Have a look in meta-yocto/conf/distro/poky.conf, specifically
SANITY_TESTED_DISTROS.

Related: if you get the warning but your system is fine, then you can
set that variable to "" in your local.conf.  I do this as I run Debian
Unstable, which for obvious reasons isn't certified.

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

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

[Khem Raj]

On Mar 3, 2013, at 4:12 AM, Satya Swaroop DAMARLA  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 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

HTH

-Khem

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

Re: [yocto] Trying to bitbake core-image-minimal on Archlinux

[Satya Swaroop Damarla]

hey Biao,

The sanity information is provided in the directory meta-yocto/conf/distro/
... Here there are several distributions and in their conf file you have
the sanity tested ditro .. :)

Greets,
Satya


On Thu, Mar 7, 2013 at 4:22 PM, Biao  wrote:

>
>
>
>
>
>
> 在 2013-03-04 06:16:55，"Jack Mitchell"  写道：
>
>  On 03/03/13 18:02, Ismael Barros² wrote:
>
> Hi there,
>
>  I'm new to Yocto, and I keep finding errors that prevent me from
> building a minimal image.
>
>  I've just installed poky-danny-8.0, sourced oe-init-build-env, and
> bitbaked core-image-minimal. The first error is that bitbake sanity checks
> fail to detect the network access, while my network connectivity is
> perfect, and downloading packages seem to work if I disable this checks.
> Full log: http://pastebin.com/6jJCC1qp. I couldn't find any log that told
> me which piece of code was failing, so I jut disabled this check
> on ../meta-yocto/conf/distro/poky.conf
>
>  Upon trying again, building started fine, but it started failing to
> build the documentation for some packages, i.e. binutils-cross. First off,
> I want to build a single mission appliance, I don't really want to build
> any documentation, is there any way I can disable it? Anyway, this is the
> build log: http://pastebin.com/n9U4GfjG. Looks like there are some
> texinfo commands my machine (texinfo 5.0) doesn't recognice. According to
> http://sourceware.org/bugzilla/show_bug.cgi?id=15183, it's a known bug
> on binuilts-2.22 and it's fixed on binuilts-2.23.
>
>  Poking around, looks like "updating" to binutils-2.23 got it kind of
> working:
>
>  mv ./meta/recipes-devtools/binutils/binutils-2.22.inc
> ./meta/recipes-devtools/binutils/binutils-2.23.1.inc
> mv 
> ./meta/recipes-devtools/binutils/binutils-cross-canadian_2.22.bb./meta/recipes-devtools/binutils/
> binutils-cross-canadian_2.23.1.bb
> mv 
> ./meta/recipes-devtools/binutils/binutils_2.22.bb./meta/recipes-devtools/binutils/
> binutils_2.23.1.bb
> mv 
> ./meta/recipes-devtools/binutils/binutils-crosssdk_2.22.bb./meta/recipes-devtools/binutils/
> binutils-crosssdk_2.23.1.bb
> mv 
> ./meta/recipes-devtools/binutils/binutils-cross_2.22.bb./meta/recipes-devtools/binutils/
> binutils-cross_2.23.1.bb
>
>  I also had to update the md5 and sha1
> on ./meta/recipes-devtools/binutils/binutils-2.23.1.inc. After that, some
> patches failed to apply:
> libtool-2.4-update.patch, binutils-2.19.1-ld-sysroot.patch, 
> binutils-poison.patch,
> libtool-rpath-fix.patch, clone-shadow.patch... so gave up
> What would be the appropiate way to workaround this issue, besides not
> using Archlinux?
>
>  Btw, if the bitbake core-image-minimal fails because there's not enough
> disk space, and the free disk in the partition is left to 0, after that
> even the bitbake clean command fails :\
>
>
>  Anyway, thank you guys for what seems to be an excellent BSP factory,
> I'm really looking forward to start using it at our company :)
>
>  Kind regards,
> Ismael
>
>
> ___
> yocto mailing 
> listyocto@yoctoproject.orghttps://lists.yoctoproject.org/listinfo/yocto
>
>
> Hi Ismael,
>
> Archlinux currently has texinfo5 in it's core repo which breaks a
> significant amount of packages. I would suggest downgrading to textinfo4.x
> (can't remember the exact version) and then things should at least start to
> get going again. I'm afraid however if you insist on using a rolling
> release distro you are going to hit these problems more often than most, if
> you want a stable build environment then I would suggest using a sanity
> tested distro. If you do with to persist with Archlinux I suggest you
> follow oe-core/yocto master and update regulary.
>
>
> One dummy question, how to find out the list of all "sanity tested
> distro", i just saw a long list from the output of "git tag".
>
> Thanks,
> Biao
>
>
> Cheers,
> Jack.
>
>
> ___
> 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] Patching gcc-4.7.2 to add support for Xilinx MicroBlaze

[Khem Raj]

Elvis

On Thu, Mar 7, 2013 at 8:20 AM, Elvis Dowson  wrote:
> Hi Khem,
>   Any plans on moving to gcc-4.7.3 or 4.8.0 anytime soon?

Neither of those has been released yet so no plans as of now.

>
> Nearly all the microblaze gcc patches are for gcc-4.8.0 on the trunk, several 
> of them in fact.
>

OK may be you should wait until fall release of yocto

> I've re-applied and ported all the existing patches that you've created for 
> gcc-4.7.2 to gcc-4.7.3 (not yet tested).

4.7.3 is probably a snapshot you are talking about. We have moved away
from snapshots for gcc since git repo for gcc is in terabytes and
using svn did not go well with gcc recipe. If 4.7.3
is release in few days I will be happy to consider but as such we are
staying with 4.7.2

>
> So, I was wondering if you'd like me to try to get gcc-4.7.3 or gcc-4.8.0 
> built against the current poky master branch?

You could try and may be even keep recipes in a layer and we can then
progress them
into OE-Core once the time comes.

>
> I can test ARM Cortex A9, ARM Cortex A8 and Microblaze at my end.
>
> Do let me know!
>
> Best regards,
>
> Elvis Dowson
___
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

[Insop Song]

>>
>> 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.
>

Thank you and I've signed up for linux-yo...@yoctoproject.org, and
will send to that list for the next mail.

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

[Juri Lelli]

Hi,

On 03/07/2013 01: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

# CONFIG_NO_HZ is not set



I actually have:

CONFIG_HIGH_RES_TIMERS = y
CONFIG_PREEMPT = y
CONFIG_HZ_1000 = y
# CONFIG_NO_HZ is not set

all the other options are not required (anymore, as the PREEMPT_RT,
since SCHED_DEADLINE is currently based on 3.8-rc7).

Thanks,

- Juri


--


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.

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 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




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