Date   

Re: ntpclient compile fail

niqingliang
 

thanks.

If we want to use the original Makefile, we must get rid of the "-e" and
"-Wl,as-needed" in original arguments, for latter, we can add
"-Wl,--no-as-needed", but what about the "-e"?

On Wed, 2011-09-28 at 10:12 +0800, McClintock Matthew-B29882 wrote:
On Tue, Sep 27, 2011 at 9:04 PM, Ni Qingliang
<niqingliang@...> wrote:
1. sorry, I will.
2. Yes, I made a new Makefile (based on the original) as the patch of
ntpclient (which will override the original Makefile).
There are lots of ways to do this and avoid making a patch. You can
use EXTRA_OECONF, EXTRA_OEMAKE, EXTRA_CFLAGS, etc in the recipe itself
to fix up the build process. You can even go and modify the variables
in the do_configure, do_compile, etc build steps as well.

-M
--
Yi Qingliang
niqingliang@...
http://niqingliang2003.wordpress.com


Re: ntpclient compile fail

McClintock Matthew-B29882 <B29882@...>
 

On Tue, Sep 27, 2011 at 9:04 PM, Ni Qingliang
<niqingliang@...> wrote:
1. sorry, I will.
2. Yes, I made a new Makefile (based on the original) as the patch of
ntpclient (which will override the original Makefile).
There are lots of ways to do this and avoid making a patch. You can
use EXTRA_OECONF, EXTRA_OEMAKE, EXTRA_CFLAGS, etc in the recipe itself
to fix up the build process. You can even go and modify the variables
in the do_configure, do_compile, etc build steps as well.

-M


Re: ntpclient compile fail

niqingliang
 

1. sorry, I will.
2. Yes, I made a new Makefile (based on the original) as the patch of
ntpclient (which will override the original Makefile).

On Wed, 2011-09-28 at 09:50 +0800, McClintock Matthew-B29882 wrote:
On Tue, Sep 27, 2011 at 8:00 PM, Ni Qingliang
<niqingliang@...> wrote:
the attachement is the bb file and Makefile(modified),
It usually best to include these attachments inline when possible.

after 'override' CFLAGS/LDFLAGS in Makefile, I have added
override LDFLAGS += -Wl,--no-as-needed
in the Makefile to neutralize the '-Wl,--as-needed' in the original
LDFLAGS.

and then the world clear.
Are you editing the source files in this package or the recipe itself?

-M
--
Yi Qingliang
niqingliang@...
http://niqingliang2003.wordpress.com


Re: ntpclient compile fail

McClintock Matthew-B29882 <B29882@...>
 

On Tue, Sep 27, 2011 at 8:00 PM, Ni Qingliang
<niqingliang@...> wrote:
the attachement is the bb file and Makefile(modified),
It usually best to include these attachments inline when possible.

after 'override' CFLAGS/LDFLAGS in Makefile, I have added
override LDFLAGS += -Wl,--no-as-needed
in the Makefile to neutralize the '-Wl,--as-needed' in the original
LDFLAGS.

and then the world clear.
Are you editing the source files in this package or the recipe itself?

-M


Re: rootfs-ramdisk error

niqingliang
 

On Tue, 2011-09-27 at 23:06 +0800, McClintock Matthew-B29882 wrote:
On Mon, Sep 26, 2011 at 8:14 PM, Ni Qingliang
<niqingliang@...> wrote:
maybe not only similar, but same:)

curious, the issue disappeared, what I can remeber is reconfigured the
busybox.
maybe another thing is rebuilded all.

before that, I have added debug code in udhcpc's script, and found that:
mkdir /etc/AAAAA will fail
but
cd /etc
mkdir ./AAAAA will success.
maybe that is a clue, but I can't reproduce the problem.:(

the IMAGE_ROOTFS_SIZE is 16M, only used about 11M.
I have looked the source code of the poky, it will use the bigger one in
(ROOTFS_SIZE and 1.3 * real_size) by default.
Can you add a bug to bugzilla.yoctoproject.org to track this so we can
try to fix this for the 1.1 release?

-M
--
Yi Qingliang
niqingliang@...
http://niqingliang2003.wordpress.com


Re: ntpclient compile fail

niqingliang
 

Thanks!

the attachement is the bb file and Makefile(modified),

after 'override' CFLAGS/LDFLAGS in Makefile, I have added
override LDFLAGS += -Wl,--no-as-needed
in the Makefile to neutralize the '-Wl,--as-needed' in the original
LDFLAGS.

and then the world clear.

On Tue, 2011-09-27 at 23:46 +0800, McClintock Matthew-B29882 wrote:
On Mon, Sep 26, 2011 at 10:18 PM, Ni Qingliang
<niqingliang@...> wrote:
Hello:
I'm adding ntpclient into my distro.

but build fail, reason is the CFLAGS/LDFLAGS in it's Makefile didn't
take effect.
If the CFLAGS are not taking effect from the Makefile are you over
ridding the value in the recipe? Can you point us at a copy of the
recipe you are using?

-M
--
Yi Qingliang
niqingliang@...
http://niqingliang2003.wordpress.com


multilib issue when setting DEFAULTTUNE

McClintock Matthew-B29882 <B29882@...>
 

All,

I'm having a problem building multilib for ppc64e5500. My local.conf
looks like this following:

require conf/multilib.conf
MULTILIBS = "multilib:lib64"
DEFAULTTUNE_virtclass-multilib-lib64 = "ppc64e5500"

If I change the last time to:

DEFAULTTUNE_virtclass-multilib-lib64 = "powerpc64"

Everything works just fine. We get images built, sysroot created, etc

Obviously we want the first one to work as it has additional compiler
flags for that target. I've tried tweaking tune-ppce5500-64b.inc to
look like arch-powerpc64.inc almost exactly but I'm really just
guessing here...

What happens is bitbake essentially locks up if I enable -DDD the
output will usually look something like this:

DEBUG: LOAD /local/home/mattsm/git/poky/meta-yocto/recipes-core/netbase/netbase_4.45.bbappend
DEBUG: BB :0: inheriting classes/multilib.bbclass

And freeze, the last class it freezes on could be one of several but
the multilib.bbclass is always close to being the last one loaded.

Does anyone have any pointers about where to start looking?

-Matthew


Re: Minutes: Yocto Technical Team Meeting - (Tuesday, September 20, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))

Liu, Song <song.liu@...>
 

Thank you, Matthew!

Song

-----Original Message-----
From: McClintock Matthew-B29882 [mailto:B29882@...]
Sent: Tuesday, September 27, 2011 2:58 PM
To: Liu, Song
Cc: McClintock Matthew-B29882; Wold, Saul; yocto@...
Subject: Re: [yocto] Minutes: Yocto Technical Team Meeting - (Tuesday, September 20, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))

On Mon, Sep 26, 2011 at 3:01 PM, Liu, Song <song.liu@...> wrote:
Hi Saul/Mark, would you guys please help clarifying this? We also need to document this in the release note.
The conclusion here was that prelink is working in other 64bit
machines, so the powerpc64 issue is specific to that arch. Bug has
been filed to track the issue!

http://bugzilla.pokylinux.org/show_bug.cgi?id=1531

-M


Re: Minutes: Yocto Technical Team Meeting - (Tuesday, September 20, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))

McClintock Matthew-B29882 <B29882@...>
 

On Mon, Sep 26, 2011 at 3:01 PM, Liu, Song <song.liu@...> wrote:
Hi Saul/Mark, would you guys please help clarifying this? We also need to document this in the release note.
The conclusion here was that prelink is working in other 64bit
machines, so the powerpc64 issue is specific to that arch. Bug has
been filed to track the issue!

http://bugzilla.pokylinux.org/show_bug.cgi?id=1531

-M


Minutes: Yocto Technical Team Meeting - (Tuesday, September 27, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))

Liu, Song <song.liu@...>
 

Attendees:
Beth, Paul, Jessica, ScottR, Jeff, Matthew, Josh, Richard, Tom, Saul, Darren, Song, Bruce
 
Agenda
 
* Opens collection - 5 min (Song)
* Yocto 1.1 M4 status review and issues - 15 min (team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria#Milestone_
- Bug fixing summary and issues (Song):
. We started M4 with about 100 bugs targeted for 1.1 and we planned to fix most of those. By today, the number of bugs for 1.1 have doubled to about 200. and we have fixed about 170 of those bugs. So for fixing Medium+ bugs, we are doing pretty well.
. For the rest of M4 bug fixing, we will be selective on which fixes go into RC4. We should find the problem, identify the solution and then evaluate the benefit and risk before we decide if the bug fix can go into RC4.
. 1523, 1532: Saul, will be fixed in a couple of days.
. 1496/1497/1498/1527: Richard, working on the fix, some of them already have patches to be reviewed. Some of these are resulted from testcases for non main path usage model and corner cases.
. 1443: special usage case problem for prelink. Should consider downgrade.
. 1489: Jessica, not a showstopper. Should consider to downgrade.
- Build status and QA (Beth/Song)
. Everything in Edison branch is building fine. All green but Crowbay
ADT toolchain and installer is done.
- Release schedule (Song) RC4 starts on Oct. 5th.
. Have all docs into Edison branch by Oct. 6th.
* Opens - 10 min
. Prelink on 64 bit: Matthew will open a new bug for the problem he found. Mark will likely be the owner
. Remind 1.2 planning: process is in full swing. We are waiting on two things to happen before we do team planning: 1. Dave and Richard sync on 1.2 theme and feature set. 2. Sync with stakeholders on process improvement moving forward.
. Darren: Machine_essential: None of the 4 options cause the package to be included in the image. Is this a problem or user error? Shall we fix it for 1.1. Richard will respond in the email about this issue and work with Darren offline.
 
* Weekly team sharing (30 min)
Bruce: doing bug triage, consulting on kernel bugs, looking at 3.1 kernels. Planning for next Yocto release. Linux libc header package upgrade. Getting a decent mirror for 3.04. (Master is ok to upgrade kernel version, but not the Edison branch).
Darren: debugging on some serial port issues on upcoming BSP, working on minimal boot. Some patches sent to kernel mailing list. Main blockers are mostly internal things such as hardware availability. A few things I could farm out. Anyone can help? (some packaging issues) Paul volunteered to help.
Saul: working to get the release done, blockers: my own getting through these bugs. Consolidate pulls again for master, not Edison. Do a basic build first before send out batch pull request.
Tom: Get Emanlow moved to 3.0. always one BSP gets in trouble when we move the kernel. BSP reviews. Seems to be a good time clean up some of the config issues. Going through emanlow, crownbay configures. But this is not for 1.1. Working on bugs at the same time. Continue all that staff this week
Richard: In china last week, working with the team there, doing training, brainstorming, discussing 1.2 features. Did some stability work on autobuider. Some work on openembedded, did some work on QA warnings. Next week focus on the release, go through some release bugs, work with Dongxiao on multi-lib fixes.
Josh: Worked bug fixing last week, worked on video together, continue bug fixing video this week.
Matthew: Doing some ppc64 staff, state cache. Not affecting release. Would not make a demand to fix the ppc64 prelink problem for Yocto 1.1. Freescale's work will be based on 1.1 though.
Jeff: Not much on yocto side, working on wrs linux.
Scott: last week worked with Jessica to create the ADT video. Completed the ADT manual. Done work on user feedback, especially from Paul. This week to complete the HOB video. Wrap up all bugs and changes before next week starts. Lots of things to do. But will make the Oct. 6th date for doc freeze.
Jessica: Debugging with lianghao on 1489, screen cast, initial video for ADT video. Worked with Beth on ADT repo. Planning working on intel tools. Post 1.1 features, etc.
Paul: Doing bug fixes for the release. Helping Scott for the documentation. Working on distro list, not much feedback on that from the community. A short list. Next to help Darren. Look at some QT patches and respond.
Beth: last week spent time getting RC3 out, fixing autobuilder issues. Next week, get release together for RC4 for 1.1. For Oct./Nov. taking every Friday off.
 
Shanghai Team: Shane is on vacation. Pretty much everyone was having meetings with Dave and Richard on training, brainstorming, and other things.


Re: MACHINE_EXTRA_* and MACHINE_ESSENTIAL_* documentation

Rifenbark, Scott M <scott.m.rifenbark@...>
 

I am currently crafting descriptions of these four variables plus the RDEPENDS and RRECOMMENDS variables. When I get them done I will distribute for discussion.

Thanks,
Scott

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Darren Hart
Sent: Tuesday, September 27, 2011 1:03 PM
To: Richard Purdie
Cc: Yocto Project; Eggleton, Paul; Wold, Saul
Subject: Re: [yocto] MACHINE_EXTRA_* and MACHINE_ESSENTIAL_* documentation

On 09/27/2011 11:04 AM, Richard Purdie wrote:
On Tue, 2011-09-27 at 08:51 -0700, Darren Hart wrote:
On 09/21/2011 02:29 PM, Darren Hart wrote:
This is something I've run into frequently and have been putting off
trying to resolve. Hopefully the following will help illustrate the path
a BSP developer might go down trying to use the MACHINE_ESSENTIAL* and
MACHINE_EXTRA* variables. If someone with more knowledge on the subject
could fill in the gaps noted below, I'll be happy to test and work with
Scott to improve the documentation.

I am unable to discern from the following text in the reference manual,
which variable I should be using to include a firmware package in the
images for a given BSP.

From
http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html:

"
MACHINE_ESSENTIAL_RDEPENDS

List of packages required to boot device
MACHINE_ESSENTIAL_RRECOMMENDS

List of packages required to boot device (usually additional kernel
modules)
As Saul points out, these should be:

MACHINE_ESSENTIAL_EXTRA_*


MACHINE_EXTRA_RDEPENDS

List of packages required to use device
MACHINE_EXTRA_RRECOMMNEDS (<-- typo still present)

List of packages useful to use device (for example additional kernel
modules)
"

From the above, I don't learn anything about what the impact of using
each of these variables is. Which ones add the packages to the rootfs,
which only build them, do they impact the initrd (one might assume a
package required for boot should be in the initrd). The difference
between RDEPENDS and RRECOMMENDS is unclear. Three of the four use the
term "required" while the other uses "useful" in the description.
Neither semantic split (RDEPENDS vs. RRECOMMENDS, ESSENTIAL vs. EXTRA)
can be understood from the available descriptions.

The firmware I want to add is needed for wireless functionality. This is
likely not required for boot, so I added it to MACHINE_EXTRA_RRECOMMENDS
as it is only needed if the wireless driver is used. This resulted in
the package being built, but not installed. In practice this would mean
that people building the BSP would need to manually add the firmware
package to IMAGE_INSTALL or install it manually later. This strikes me
as unnecessarily complex.

This was also unexpected given the definition of RRECOMMENDS in the
manual, which would have led me to believe the package should have been
installed:

"
RRECOMMENDS

List of packages which extend usability of the package. Those
packages will be automatically installed but can be removed by user.
"

Paul E. explained that RRECOMMENDS differs from RDEPENDS in that if a
RRECOMMENDS package is not available (because the providing recipe
doesn't build it - like a custom linux kernel not building a particular
module) the image build will continue and not error out.
Right. Its really there so people can flag modules to include (if
they're built as modules) so that is that difference.

Let me explain what should happen:

ESSENTIAL are ones which are required to get the system to boot and be
of any use. These would be flash/mtd drivers, screen drivers,
keyboard/mouse/touchscreen.

The EXTRA things are things that are nice to have but are not needed to
boot. Wifi drivers would be an example if we known a given machine
contains some kind of wifi card, the driver would need to be present to
make the system 100% functional.

There is a line in task-base.bb which hints at this:

#
# those ones can be set in machine config to supply packages needed to get machine booting
#
MACHINE_ESSENTIAL_EXTRA_RDEPENDS ?= ""
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?= ""


I wasn't able to find a general meaning for the term "EXTRA" by
searching through the manual.

I then tried the remaining 3 variables, doing the following after
setting each:

$ bitbake -c cleanall task-machine-base task-core-boot
linux-firmware-core-image-sato
$ bitbake -u depexp -g core-image-sato
$ bitbake core-image-sato

I then determined if the linux-firmware package appeared in the list
presented by the depexp UI and whether or not the linux-firmware package
was built and installed. The results follow:

MACHINE_EXTRA_RDEPENDS = "linux-firmware-iwlwifi-6000g2a-5"
# appears in depexp with no rdepends, builds, does not install

#MACHINE_EXTRA_RECOMMENDS += "linux-firmware-iwlwifi-6000g2a-5"
# does not appear in depexp, does not build

#MACHINE_ESSENTIAL_RDEPENDS = "linux-firmware-iwlwifi-6000g2a-5"
# does not appear in depexp, does not build

If I use the appropriate MACHINE_ESSENTIAL_EXTRA_RDEPENDS here, the
package is built, but it is not included in the final image.
We have two different types of image, minimal/basic and the others. The
former is derived from task-core-boot, the others derive from task-base.
The former is a minimal setup of things just needed to boot, task-base
has more dependencies but is more suited to real world use.

I've tried searching the sources for these variables, and quickly lose
their scent. Here is what I did find:

task-base.bb:
#
# packages added by machine config
#
RDEPENDS_task-machine-base = "${MACHINE_EXTRA_RDEPENDS}"
RRECOMMENDS_task-machine-base = "${MACHINE_EXTRA_RRECOMMENDS}"

task-core-boot.bb:
RDEPENDS_task-core-boot = "\
...
${MACHINE_ESSENTIAL_EXTRA_RDEPENDS}"

RRECOMMENDS_task-core-boot = "\
${MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS}"


How these should impact the final image is not clear to me.
So if you change MACHINE_EXTRA* you need to rebuild task-base, if you
change MACHINE_ESSENTIAL_EXTRA* you need to rebuild task-core-boot.
Confusing and the checksum code we'll enable soon should make this
automatic.

The task-core-boot is included into task-base by task-distro-base
through DISTRO_EXTRA_RDEPENDS which in meta-yocto is set to
task-core-boot. Both sets of variables should therefore appear in most
images except minimal and basic which should only get the essential
ones.

I hope that at least clarifies what should happen...
I pulled master and rebuilt using all 4 options. All 4 resulted in the
firmware packages being built and installed in the rootfs. Either
something changed in master since I tried this last, or my machine was
the victim of a gamma ray event.... sigh.

Nevermind, there is nothing to see here.

Still, I think the discussion of documentation was worth the trouble,
I'll work with Scott to update what we have in the reference manual with
the feedback from Saul, Paul, and RP.

Thanks everyone.


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


Re: MACHINE_EXTRA_* and MACHINE_ESSENTIAL_* documentation

Darren Hart <darren.hart@...>
 

On 09/27/2011 11:04 AM, Richard Purdie wrote:
On Tue, 2011-09-27 at 08:51 -0700, Darren Hart wrote:
On 09/21/2011 02:29 PM, Darren Hart wrote:
This is something I've run into frequently and have been putting off
trying to resolve. Hopefully the following will help illustrate the path
a BSP developer might go down trying to use the MACHINE_ESSENTIAL* and
MACHINE_EXTRA* variables. If someone with more knowledge on the subject
could fill in the gaps noted below, I'll be happy to test and work with
Scott to improve the documentation.

I am unable to discern from the following text in the reference manual,
which variable I should be using to include a firmware package in the
images for a given BSP.

From
http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html:

"
MACHINE_ESSENTIAL_RDEPENDS

List of packages required to boot device
MACHINE_ESSENTIAL_RRECOMMENDS

List of packages required to boot device (usually additional kernel
modules)
As Saul points out, these should be:

MACHINE_ESSENTIAL_EXTRA_*


MACHINE_EXTRA_RDEPENDS

List of packages required to use device
MACHINE_EXTRA_RRECOMMNEDS (<-- typo still present)

List of packages useful to use device (for example additional kernel
modules)
"

From the above, I don't learn anything about what the impact of using
each of these variables is. Which ones add the packages to the rootfs,
which only build them, do they impact the initrd (one might assume a
package required for boot should be in the initrd). The difference
between RDEPENDS and RRECOMMENDS is unclear. Three of the four use the
term "required" while the other uses "useful" in the description.
Neither semantic split (RDEPENDS vs. RRECOMMENDS, ESSENTIAL vs. EXTRA)
can be understood from the available descriptions.

The firmware I want to add is needed for wireless functionality. This is
likely not required for boot, so I added it to MACHINE_EXTRA_RRECOMMENDS
as it is only needed if the wireless driver is used. This resulted in
the package being built, but not installed. In practice this would mean
that people building the BSP would need to manually add the firmware
package to IMAGE_INSTALL or install it manually later. This strikes me
as unnecessarily complex.

This was also unexpected given the definition of RRECOMMENDS in the
manual, which would have led me to believe the package should have been
installed:

"
RRECOMMENDS

List of packages which extend usability of the package. Those
packages will be automatically installed but can be removed by user.
"

Paul E. explained that RRECOMMENDS differs from RDEPENDS in that if a
RRECOMMENDS package is not available (because the providing recipe
doesn't build it - like a custom linux kernel not building a particular
module) the image build will continue and not error out.
Right. Its really there so people can flag modules to include (if
they're built as modules) so that is that difference.

Let me explain what should happen:

ESSENTIAL are ones which are required to get the system to boot and be
of any use. These would be flash/mtd drivers, screen drivers,
keyboard/mouse/touchscreen.

The EXTRA things are things that are nice to have but are not needed to
boot. Wifi drivers would be an example if we known a given machine
contains some kind of wifi card, the driver would need to be present to
make the system 100% functional.

There is a line in task-base.bb which hints at this:

#
# those ones can be set in machine config to supply packages needed to get machine booting
#
MACHINE_ESSENTIAL_EXTRA_RDEPENDS ?= ""
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?= ""


I wasn't able to find a general meaning for the term "EXTRA" by
searching through the manual.

I then tried the remaining 3 variables, doing the following after
setting each:

$ bitbake -c cleanall task-machine-base task-core-boot
linux-firmware-core-image-sato
$ bitbake -u depexp -g core-image-sato
$ bitbake core-image-sato

I then determined if the linux-firmware package appeared in the list
presented by the depexp UI and whether or not the linux-firmware package
was built and installed. The results follow:

MACHINE_EXTRA_RDEPENDS = "linux-firmware-iwlwifi-6000g2a-5"
# appears in depexp with no rdepends, builds, does not install

#MACHINE_EXTRA_RECOMMENDS += "linux-firmware-iwlwifi-6000g2a-5"
# does not appear in depexp, does not build

#MACHINE_ESSENTIAL_RDEPENDS = "linux-firmware-iwlwifi-6000g2a-5"
# does not appear in depexp, does not build

If I use the appropriate MACHINE_ESSENTIAL_EXTRA_RDEPENDS here, the
package is built, but it is not included in the final image.
We have two different types of image, minimal/basic and the others. The
former is derived from task-core-boot, the others derive from task-base.
The former is a minimal setup of things just needed to boot, task-base
has more dependencies but is more suited to real world use.

I've tried searching the sources for these variables, and quickly lose
their scent. Here is what I did find:

task-base.bb:
#
# packages added by machine config
#
RDEPENDS_task-machine-base = "${MACHINE_EXTRA_RDEPENDS}"
RRECOMMENDS_task-machine-base = "${MACHINE_EXTRA_RRECOMMENDS}"

task-core-boot.bb:
RDEPENDS_task-core-boot = "\
...
${MACHINE_ESSENTIAL_EXTRA_RDEPENDS}"

RRECOMMENDS_task-core-boot = "\
${MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS}"


How these should impact the final image is not clear to me.
So if you change MACHINE_EXTRA* you need to rebuild task-base, if you
change MACHINE_ESSENTIAL_EXTRA* you need to rebuild task-core-boot.
Confusing and the checksum code we'll enable soon should make this
automatic.

The task-core-boot is included into task-base by task-distro-base
through DISTRO_EXTRA_RDEPENDS which in meta-yocto is set to
task-core-boot. Both sets of variables should therefore appear in most
images except minimal and basic which should only get the essential
ones.

I hope that at least clarifies what should happen...
I pulled master and rebuilt using all 4 options. All 4 resulted in the
firmware packages being built and installed in the rootfs. Either
something changed in master since I tried this last, or my machine was
the victim of a gamma ray event.... sigh.

Nevermind, there is nothing to see here.

Still, I think the discussion of documentation was worth the trouble,
I'll work with Scott to update what we have in the reference manual with
the feedback from Saul, Paul, and RP.

Thanks everyone.


--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: MACHINE_EXTRA_* and MACHINE_ESSENTIAL_* documentation

Richard Purdie
 

On Tue, 2011-09-27 at 08:51 -0700, Darren Hart wrote:
On 09/21/2011 02:29 PM, Darren Hart wrote:
This is something I've run into frequently and have been putting off
trying to resolve. Hopefully the following will help illustrate the path
a BSP developer might go down trying to use the MACHINE_ESSENTIAL* and
MACHINE_EXTRA* variables. If someone with more knowledge on the subject
could fill in the gaps noted below, I'll be happy to test and work with
Scott to improve the documentation.

I am unable to discern from the following text in the reference manual,
which variable I should be using to include a firmware package in the
images for a given BSP.

From
http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html:

"
MACHINE_ESSENTIAL_RDEPENDS

List of packages required to boot device
MACHINE_ESSENTIAL_RRECOMMENDS

List of packages required to boot device (usually additional kernel
modules)
As Saul points out, these should be:

MACHINE_ESSENTIAL_EXTRA_*


MACHINE_EXTRA_RDEPENDS

List of packages required to use device
MACHINE_EXTRA_RRECOMMNEDS (<-- typo still present)

List of packages useful to use device (for example additional kernel
modules)
"

From the above, I don't learn anything about what the impact of using
each of these variables is. Which ones add the packages to the rootfs,
which only build them, do they impact the initrd (one might assume a
package required for boot should be in the initrd). The difference
between RDEPENDS and RRECOMMENDS is unclear. Three of the four use the
term "required" while the other uses "useful" in the description.
Neither semantic split (RDEPENDS vs. RRECOMMENDS, ESSENTIAL vs. EXTRA)
can be understood from the available descriptions.

The firmware I want to add is needed for wireless functionality. This is
likely not required for boot, so I added it to MACHINE_EXTRA_RRECOMMENDS
as it is only needed if the wireless driver is used. This resulted in
the package being built, but not installed. In practice this would mean
that people building the BSP would need to manually add the firmware
package to IMAGE_INSTALL or install it manually later. This strikes me
as unnecessarily complex.

This was also unexpected given the definition of RRECOMMENDS in the
manual, which would have led me to believe the package should have been
installed:

"
RRECOMMENDS

List of packages which extend usability of the package. Those
packages will be automatically installed but can be removed by user.
"

Paul E. explained that RRECOMMENDS differs from RDEPENDS in that if a
RRECOMMENDS package is not available (because the providing recipe
doesn't build it - like a custom linux kernel not building a particular
module) the image build will continue and not error out.
Right. Its really there so people can flag modules to include (if
they're built as modules) so that is that difference.

Let me explain what should happen:

ESSENTIAL are ones which are required to get the system to boot and be
of any use. These would be flash/mtd drivers, screen drivers,
keyboard/mouse/touchscreen.

The EXTRA things are things that are nice to have but are not needed to
boot. Wifi drivers would be an example if we known a given machine
contains some kind of wifi card, the driver would need to be present to
make the system 100% functional.

There is a line in task-base.bb which hints at this:

#
# those ones can be set in machine config to supply packages needed to get machine booting
#
MACHINE_ESSENTIAL_EXTRA_RDEPENDS ?= ""
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?= ""


I wasn't able to find a general meaning for the term "EXTRA" by
searching through the manual.

I then tried the remaining 3 variables, doing the following after
setting each:

$ bitbake -c cleanall task-machine-base task-core-boot
linux-firmware-core-image-sato
$ bitbake -u depexp -g core-image-sato
$ bitbake core-image-sato

I then determined if the linux-firmware package appeared in the list
presented by the depexp UI and whether or not the linux-firmware package
was built and installed. The results follow:

MACHINE_EXTRA_RDEPENDS = "linux-firmware-iwlwifi-6000g2a-5"
# appears in depexp with no rdepends, builds, does not install

#MACHINE_EXTRA_RECOMMENDS += "linux-firmware-iwlwifi-6000g2a-5"
# does not appear in depexp, does not build

#MACHINE_ESSENTIAL_RDEPENDS = "linux-firmware-iwlwifi-6000g2a-5"
# does not appear in depexp, does not build

If I use the appropriate MACHINE_ESSENTIAL_EXTRA_RDEPENDS here, the
package is built, but it is not included in the final image.
We have two different types of image, minimal/basic and the others. The
former is derived from task-core-boot, the others derive from task-base.
The former is a minimal setup of things just needed to boot, task-base
has more dependencies but is more suited to real world use.

I've tried searching the sources for these variables, and quickly lose
their scent. Here is what I did find:

task-base.bb:
#
# packages added by machine config
#
RDEPENDS_task-machine-base = "${MACHINE_EXTRA_RDEPENDS}"
RRECOMMENDS_task-machine-base = "${MACHINE_EXTRA_RRECOMMENDS}"

task-core-boot.bb:
RDEPENDS_task-core-boot = "\
...
${MACHINE_ESSENTIAL_EXTRA_RDEPENDS}"

RRECOMMENDS_task-core-boot = "\
${MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS}"


How these should impact the final image is not clear to me.
So if you change MACHINE_EXTRA* you need to rebuild task-base, if you
change MACHINE_ESSENTIAL_EXTRA* you need to rebuild task-core-boot.
Confusing and the checksum code we'll enable soon should make this
automatic.

The task-core-boot is included into task-base by task-distro-base
through DISTRO_EXTRA_RDEPENDS which in meta-yocto is set to
task-core-boot. Both sets of variables should therefore appear in most
images except minimal and basic which should only get the essential
ones.

I hope that at least clarifies what should happen...

Cheers,

Richard


Re: MACHINE_EXTRA_* and MACHINE_ESSENTIAL_* documentation

Darren Hart <darren.hart@...>
 

On 09/21/2011 02:29 PM, Darren Hart wrote:
This is something I've run into frequently and have been putting off
trying to resolve. Hopefully the following will help illustrate the path
a BSP developer might go down trying to use the MACHINE_ESSENTIAL* and
MACHINE_EXTRA* variables. If someone with more knowledge on the subject
could fill in the gaps noted below, I'll be happy to test and work with
Scott to improve the documentation.

I am unable to discern from the following text in the reference manual,
which variable I should be using to include a firmware package in the
images for a given BSP.

From
http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html:

"
MACHINE_ESSENTIAL_RDEPENDS

List of packages required to boot device
MACHINE_ESSENTIAL_RRECOMMENDS

List of packages required to boot device (usually additional kernel
modules)
As Saul points out, these should be:

MACHINE_ESSENTIAL_EXTRA_*


MACHINE_EXTRA_RDEPENDS

List of packages required to use device
MACHINE_EXTRA_RRECOMMNEDS (<-- typo still present)

List of packages useful to use device (for example additional kernel
modules)
"

From the above, I don't learn anything about what the impact of using
each of these variables is. Which ones add the packages to the rootfs,
which only build them, do they impact the initrd (one might assume a
package required for boot should be in the initrd). The difference
between RDEPENDS and RRECOMMENDS is unclear. Three of the four use the
term "required" while the other uses "useful" in the description.
Neither semantic split (RDEPENDS vs. RRECOMMENDS, ESSENTIAL vs. EXTRA)
can be understood from the available descriptions.

The firmware I want to add is needed for wireless functionality. This is
likely not required for boot, so I added it to MACHINE_EXTRA_RRECOMMENDS
as it is only needed if the wireless driver is used. This resulted in
the package being built, but not installed. In practice this would mean
that people building the BSP would need to manually add the firmware
package to IMAGE_INSTALL or install it manually later. This strikes me
as unnecessarily complex.

This was also unexpected given the definition of RRECOMMENDS in the
manual, which would have led me to believe the package should have been
installed:

"
RRECOMMENDS

List of packages which extend usability of the package. Those
packages will be automatically installed but can be removed by user.
"

Paul E. explained that RRECOMMENDS differs from RDEPENDS in that if a
RRECOMMENDS package is not available (because the providing recipe
doesn't build it - like a custom linux kernel not building a particular
module) the image build will continue and not error out.


I wasn't able to find a general meaning for the term "EXTRA" by
searching through the manual.

I then tried the remaining 3 variables, doing the following after
setting each:

$ bitbake -c cleanall task-machine-base task-core-boot
linux-firmware-core-image-sato
$ bitbake -u depexp -g core-image-sato
$ bitbake core-image-sato

I then determined if the linux-firmware package appeared in the list
presented by the depexp UI and whether or not the linux-firmware package
was built and installed. The results follow:

MACHINE_EXTRA_RDEPENDS = "linux-firmware-iwlwifi-6000g2a-5"
# appears in depexp with no rdepends, builds, does not install

#MACHINE_EXTRA_RECOMMENDS += "linux-firmware-iwlwifi-6000g2a-5"
# does not appear in depexp, does not build

#MACHINE_ESSENTIAL_RDEPENDS = "linux-firmware-iwlwifi-6000g2a-5"
# does not appear in depexp, does not build

If I use the appropriate MACHINE_ESSENTIAL_EXTRA_RDEPENDS here, the
package is built, but it is not included in the final image.


I've tried searching the sources for these variables, and quickly lose
their scent. Here is what I did find:

task-base.bb:
#
# packages added by machine config
#
RDEPENDS_task-machine-base = "${MACHINE_EXTRA_RDEPENDS}"
RRECOMMENDS_task-machine-base = "${MACHINE_EXTRA_RRECOMMENDS}"

task-core-boot.bb:
RDEPENDS_task-core-boot = "\
...
${MACHINE_ESSENTIAL_EXTRA_RDEPENDS}"

RRECOMMENDS_task-core-boot = "\
${MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS}"


How these should impact the final image is not clear to me.


Thanks,

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: ntpclient compile fail

McClintock Matthew-B29882 <B29882@...>
 

On Mon, Sep 26, 2011 at 10:18 PM, Ni Qingliang
<niqingliang@...> wrote:
Hello:
I'm adding ntpclient into my distro.

but build fail, reason is the CFLAGS/LDFLAGS in it's Makefile didn't
take effect.
If the CFLAGS are not taking effect from the Makefile are you over
ridding the value in the recipe? Can you point us at a copy of the
recipe you are using?

-M


Re: QEMU nfs kernel panic

Zhang, Jessica
 

Hi Jack,

The minimal-dev image doesn't contain tcf-agent which is needed for any remote interaction. So can you build core-image-sato-sdk image and use it to boot up qemu, then your problem will be solved.

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Jack Mitchell
Sent: Tuesday, September 27, 2011 5:05 AM
To: yocto@...
Subject: Re: [yocto] QEMU nfs kernel panic

On 27/09/2011 10:05, Jack Mitchell wrote:
I am using the stock sysroot and arm kernel zImage downloaded from the
yocto site. When I try to boot QEMU all is well until it tries to
mount the nfs root filesystem. It can't find it and the kernel panics,
I have set --debug all on in the runqemu-export-rootfs script but it
throws no further errors. Does anyone have any idea why it would do
this, is it possible that there is something wrong with the nfs
implementation in the kernel and the module is not loaded correctly,
or is it more likely that the nfs share isn't mounted on my machine
and the kernel cannot find it.

Screenshot of kernel panic: http://imgur.com/UbPTT

The only thing that jumps out at me is in the kernel boot up the
rootfs doesn't have a value as can be seen in the screenshot, but I
don't know if this is normal or not?

Cheers,
Jack.
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
Ok, I managed to fix it. I needed to load the tun module to get it
working. Maybe this should be added as a check in runqemu?

I am now having issues with connecting to the live image, I recieve a
connection refused message when I try to upload the file to the virtual
machine, I have just the stick minimal-dev image so no additional
passwords set.
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: rootfs-ramdisk error

McClintock Matthew-B29882 <B29882@...>
 

On Mon, Sep 26, 2011 at 8:14 PM, Ni Qingliang
<niqingliang@...> wrote:
maybe not only similar, but same:)

curious, the issue disappeared, what I can remeber is reconfigured the
busybox.
maybe another thing is rebuilded all.

before that, I have added debug code in udhcpc's script, and found that:
mkdir /etc/AAAAA will fail
but
cd /etc
mkdir ./AAAAA will success.
maybe that is a clue, but I can't reproduce the problem.:(

the IMAGE_ROOTFS_SIZE is 16M, only used about 11M.
I have looked the source code of the poky, it will use the bigger one in
(ROOTFS_SIZE and 1.3 * real_size) by default.
Can you add a bug to bugzilla.yoctoproject.org to track this so we can
try to fix this for the 1.1 release?

-M


Re: QEMU nfs kernel panic

Jack Mitchell <ml@...>
 

On 27/09/2011 10:05, Jack Mitchell wrote:
I am using the stock sysroot and arm kernel zImage downloaded from the yocto site. When I try to boot QEMU all is well until it tries to mount the nfs root filesystem. It can't find it and the kernel panics, I have set --debug all on in the runqemu-export-rootfs script but it throws no further errors. Does anyone have any idea why it would do this, is it possible that there is something wrong with the nfs implementation in the kernel and the module is not loaded correctly, or is it more likely that the nfs share isn't mounted on my machine and the kernel cannot find it.

Screenshot of kernel panic: http://imgur.com/UbPTT

The only thing that jumps out at me is in the kernel boot up the rootfs doesn't have a value as can be seen in the screenshot, but I don't know if this is normal or not?

Cheers,
Jack.
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
Ok, I managed to fix it. I needed to load the tun module to get it working. Maybe this should be added as a check in runqemu?

I am now having issues with connecting to the live image, I recieve a connection refused message when I try to upload the file to the virtual machine, I have just the stick minimal-dev image so no additional passwords set.


QEMU nfs kernel panic

Jack Mitchell <ml@...>
 

I am using the stock sysroot and arm kernel zImage downloaded from the yocto site. When I try to boot QEMU all is well until it tries to mount the nfs root filesystem. It can't find it and the kernel panics, I have set --debug all on in the runqemu-export-rootfs script but it throws no further errors. Does anyone have any idea why it would do this, is it possible that there is something wrong with the nfs implementation in the kernel and the module is not loaded correctly, or is it more likely that the nfs share isn't mounted on my machine and the kernel cannot find it.

Screenshot of kernel panic: http://imgur.com/UbPTT

The only thing that jumps out at me is in the kernel boot up the rootfs doesn't have a value as can be seen in the screenshot, but I don't know if this is normal or not?

Cheers,
Jack.


[PATCH 2/2] meta-crownbay: remove emgd-1.6

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

emgd-1.6 is now obsoleted by emgd-1.8, so remove support for it.

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
.../xorg-xserver/emgd-driver-bin_1.8.bb | 2 +-
.../xorg-xserver/emgd-driver-bin_1.6.bb | 25 --------------------
2 files changed, 1 insertions(+), 26 deletions(-)
delete mode 100644 meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin-1.6/.gitignore
delete mode 100644 meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.6.bb

diff --git a/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb b/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
index 88e8a55..8dc43ea 100644
--- a/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
+++ b/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
@@ -6,7 +6,7 @@ see the README in meta-crownbay/ for instructions on the (simple) manual \
steps necessary to make the necessary binaries available to this recipe. \
Please do that before building an image."
LICENSE = "Intel-binary-only"
-PR = "r1"
+PR = "r7"

LIC_FILES_CHKSUM = "file://${WORKDIR}/License.txt;md5=b54f01caaf8483b3cb60c0c40f2bf22d"

diff --git a/meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin-1.6/.gitignore b/meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin-1.6/.gitignore
deleted file mode 100644
index e69de29..0000000
diff --git a/meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.6.bb b/meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.6.bb
deleted file mode 100644
index 4d5d1e2..0000000
--- a/meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.6.bb
+++ /dev/null
@@ -1,25 +0,0 @@
-SUMMARY = "EMGD 1.6 xserver binaries"
-DESCRIPTION = "EMGD 1.6 includes some userspace binaries that use non-free licensing. Intel Open Source Technology Center unfortunately has no power to change that, but tries to make their use as painless as possible. Please see the README in meta-crownbay/ for instructions on the (simple) manual steps necessary to make the necessary binaries available to this recipe. Please do that before building an image."
-
-LICENSE = "Intel-binary-only"
-LIC_FILES_CHKSUM = "file://${WORKDIR}/License.txt;md5=b54f01caaf8483b3cb60c0c40f2bf22d"
-PR = "r0"
-
-FILESPATH = "${FILE_DIRNAME}/emgd-driver-bin-1.6"
-
-FILES_${PN} = "${libdir}/*.so.* ${libdir}/dri ${libdir}/xorg/modules/drivers"
-
-SRC_URI = "file://lib \
- file://License.txt"
-
-S = "${WORKDIR}"
-
-do_install () {
- install -d -m 0755 ${D}/${libdir}/dri ${D}/${libdir}/xorg/modules/drivers
-
- cp -PR ${S}/lib/lib* ${D}${libdir}
- install -m 0755 ${S}/lib/xorg/modules/drivers/* ${D}${libdir}/xorg/modules/drivers/
- install -m 0755 ${S}/lib/dri/* ${D}${libdir}/dri/
-}
-
-LEAD_SONAME = "libEGL.so"
--
1.7.0.4