Date   

beagleboard not booting to SATO interface

Edward Vidal <vidal.develone@...>
 

Hello
This is the first time that I have created and MMC for the beagleboard on a RHELx86_64 6.3.  The beagleboard boots and the YOCTO display comes up but never goes to the SATO display.


WARNING: Host distribution "Red Hat Enterprise Linux Workstation release 6.3 (Santiago)" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.

Build Configuration:
BB_VERSION        = "1.17.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "RedHatEnterpriseWorkstation-6.3"
TARGET_SYS        = "arm-poky-linux-gnueabi"
MACHINE           = "beagleboard"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20121208"
TUNE_FEATURES     = "armv7a vfp neon"
TARGET_FPU        = "vfp-neon"
meta             
meta-yocto       
meta-yocto-bsp    = "master:c607095894cab60493ddfc4b967b0325e1c313b4"

NOTE: recipe core-image-sato-sdk-1.0-r0: task do_rootfs: Succeeded
NOTE: Running noexec task 6235 of 6235 (ID: 11, /home/vidal/poky/meta/recipes-sato/images/core-image-sato-sdk.bb, do_build)
NOTE: Tasks Summary: Attempted 6235 tasks of which 5220 didn't need to be rerun and all succeeded.

The Xorg.log is okay up to the end where the following shows the error.
[2058343.877]     ABI class: X.Org XInput driver, version 18.0
[2058343.877] (EE) No drivers available.
[2058343.877]
Fatal server error:
[2058343.878] no screens found
[2058343.878] (EE)
Please consult the The X.Org Foundation support
     at http://wiki.x.org
 for help.
[2058343.879] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[2058343.879] (EE)
[2058343.890] Server terminated with error (1). Closing log file.

Networking is working Okay.
Any help will be welcomed.
Thanks


Re: QA issue with custom recipe

Sean Liming <sean.liming@...>
 

-----Original Message-----
From: Jon Szymaniak [mailto:jon.szymaniak@gmail.com]
Sent: Friday, December 07, 2012 1:36 PM
To: sean.liming@annabooks.com
Cc: yocto@yoctoproject.org
Subject: Re: QA issue with custom recipe

I am trying to create a simple hello world recipe for a helloworld.c
file. The recipe almost works except it hits a QA issue: WARNING: QA
Issue: hello: Files/directories were installed but not shipped

The warning leads to a failure in the do_rootfs.

WARNING: QA Issue: hello: Files/directories were installed but not
shipped
/usr
/usr/bin
ERROR: Function failed: do_rootfs
--------------------------


What am I missing in the recipe?

--
Regards,

Sean D. Liming
Owner
Annabooks
Cell: 858-774-3176


-------------- next part -------------- DESCRIPTION = "Hello World
Application"
LICENSE = "GPL-2"
LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58"

SECTION = "apps"

SRC_URI = "file:///home/sean/workspace/Hello/HelloYocto.c"
SRC_URI[md5sum] = "4f5c57b446cc08a7299d4dca58c49cda"
SRC_URI[sha256sum] =
"f357d9214f9c585d8b3997c6a3038eb28b218de264a8bb39ae8474949ad2b98d"

S = "${WORKDIR}"

do_compile() {
${CC} ${CFLAGS} ${LDFLAGS} /home/sean/workspace/Hello/HelloYocto.c -
o
helloyocto }

do_install() {
install -d ${D}${bindir}
install -m 0755 helloyocto ${D}{bindir} }

Sean,

I think you need to note which files are installed by the packages
associated with this recipe, via:

FILES_${PN} = "${bindir}"

For more info on these, Check out the FILES and CONFFILES
variables in the Poky Reference Manual. I also found it helpful
to grep around some of the bigger recipes to see how they use
these. (I got a bit tripped up with some libraries with the sonames set!)


Regards,
Jon


John,

Thank you. The Q/A Warning is gone. That is one step closer, but the package
is still not resolved.

-------------------------------------
Processing HelloYocto...

Unable to resolve package HelloYocto

ERROR: some packages were missing

ERROR: Function failed: do_rootfs (see
/home/sean/Yocto1.3/n2800/tmp/work/cedartrail-poky-linux/core-image-minimal-
1.0-r0/temp/log.do_rootfs.24265 for further information)

----------------------



Regards,

Sean Liming
Owner
Annabooks
Tel: 714-970-7523 / Cell: 858-774-3176


Re: [PATCH 0/3][eclipse-poky] Add option to allow building from local repo

Zhang, Jessica
 

Hi Timo,

There're some changes made to eclipse build scripts, so your patch won't be able to apply. Can you rebase against latest master and resend?

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of mail@timomueller.eu
Sent: Friday, November 30, 2012 2:33 AM
To: yocto@yoctoproject.org
Cc: Timo Mueller
Subject: [yocto] [PATCH 0/3][eclipse-poky] Add option to allow building from local repo

From: Timo Mueller <timo.mueller@bmw-carit.de>

Hi,

if you build eclipse-poky with the provided build script it will always use the upstream version of the IDE.
During development I wanted to use my local repository to make sure that my changes don't break the build system. Therefor I added an option to the build script to allow building from the local eclipse-poky git repository.

Best regards,
Timo

Timo Mueller (3):
scripts/build.sh: Added function to use the local repository for
building
scripts/build.sh: Added help option to the cmdline
script/build.sh: Added option to enable building from local
repository.

scripts/build.sh | 30 ++++++++++++++++++++++++++----
1 files changed, 26 insertions(+), 4 deletions(-)

--
1.7.7.6

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


Re: [PATCH 0/8][eclipse-poky] Enable setting yocto settings in the project properties dialog

Zhang, Jessica
 

Hi Timo,

Great patch set and merged to eclipse-poky master.

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of mail@timomueller.eu
Sent: Tuesday, December 04, 2012 1:22 AM
To: yocto@yoctoproject.org
Cc: Timo Mueller
Subject: [yocto] [PATCH 0/8][eclipse-poky] Enable setting yocto settings in the project properties dialog

From: Timo Mueller <timo.mueller@bmw-carit.de>

Hi,

changing the yocto settings of a project is currently achieved through a separate dialog. This dialog can be opened via the eclipse menu bar (project -> change yocto project settings). Typically all project related settings in eclipse are located in the project properties dialog.

This patch series adds yocto settings to the project properties dialog. It also removes the separate dialog. Instead the yocto section in the project properties is opened if "change yocto project settings"
is selected from the menu bar.

Best regards,
Atanas and Timo

Atanas Gegov (4):
plugins/sdk.ide: Allow using a YoctoUIElement to set the input of a
yocto settings widget
plugins/sdk.ide: Create a default YoctoUIElement from the preference
store
plugins/sdk.ide: Use new setCurrentInput method to set defaults
plugins/sdk.ide: Remove fControl array that is no longer needed

Timo Mueller (4):
plugins/sdk.ide: Added empty yocto preference page to project
properties
plugins/sdk.ide: Move modification of yocto project settings to utils
class
plugins/sdk.ide: Show yocto ui setting widget in project property
page
plugins/sdk.ide: Open project properties instead of standalone yocto
settings dialog

.../OSGI-INF/l10n/bundle.properties | 1 +
plugins/org.yocto.sdk.ide/plugin.xml | 14 +++
.../src/org/yocto/sdk/ide/YoctoSDKUtils.java | 67 ++++++++++++
.../src/org/yocto/sdk/ide/YoctoUISetting.java | 54 +++++++---
.../yocto/sdk/ide/actions/ReconfigYoctoAction.java | 64 ++---------
.../yocto/sdk/ide/actions/SDKLocationDialog.java | 89 ----------------
.../ide/preferences/YoctoSDKPreferencePage.java | 51 +---------
.../preferences/YoctoSDKProjectPropertyPage.java | 111 ++++++++++++++++++++
8 files changed, 247 insertions(+), 204 deletions(-) delete mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/actions/SDKLocationDialog.java
create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java

--
1.7.7.6

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


Re: [PATCH] Yocto Project Dev Manual - bad reference in dev-manual-newbie.xml

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

This patch has been applied to the master branch of yocto-docs repo. I have republished the dev-manual in the "In Progress" documents on the YP website.

Thanks for the patch Bob.

Scott

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] On Behalf Of Bob Cochran
Sent: Saturday, December 01, 2012 7:15 AM
To: Yocto discussion list
Subject: [yocto] [PATCH] Yocto Project Dev Manual - bad reference in
dev-manual-newbie.xml

I updated a note that points the reader to the maintainers list. The
note in the master branch pointed the reader to a nonexistent (old)
file.

Signed-off-by: Robert Cochran<yocto@mindchasers.com>

---
documentation/dev-manual/dev-manual-newbie.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/documentation/dev-manual/dev-manual-newbie.xml
b/documentation/dev-manual/dev-manual-newbie.xml
index bb01131..8b078e1 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -742,8 +742,8 @@
The maintainer is responsible for allowing changes in from
other developers and for
organizing the underlying branch structure to reflect release
strategies and so forth.
<note>You can see who is the maintainer for Yocto Project
files by examining the
- <filename>distro_tracking_fields.inc</filename> file in the
Yocto Project
- <filename>meta/conf/distro/include</filename> directory.</note>
+ <filename>maintainers.inc</filename> file in the Yocto Project
+ <filename>meta-yocto/conf/distro/include</filename>
directory.</note>
</para>

<para>
--
1.7.9.5
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [PATCH] Fix incompatibility with jre1.6 support for typed HashMap

Zhang, Jessica
 

Hi Ioana,

Seems the patch won't apply even with the --keep-cr flag. This is against jzhang/windows-build branch.

Can you double check?

Thanks,
Jessica

git am --keep-cr ~/mbox/\[yocto\]_\[PATCH_7_8\]_convert_CRLF_line_terminators_to_CR_only.mbox
Applying: convert CRLF line terminators to CR only
/home/jzhang/eclipse-poky-windows/.git/rebase-apply/patch:79: trailing whitespace.
public FiniteStateWizard() {
/home/jzhang/eclipse-poky-windows/.git/rebase-apply/patch:81: trailing whitespace.

/home/jzhang/eclipse-poky-windows/.git/rebase-apply/patch:96: trailing whitespace.

/home/jzhang/eclipse-poky-windows/.git/rebase-apply/patch:101: trailing whitespace.
super.createPageControls(pageContainer);
/home/jzhang/eclipse-poky-windows/.git/rebase-apply/patch:112: trailing whitespace.

error: patch failed: plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/FiniteStateWizard.java:1
error: plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/FiniteStateWizard.java: patch does not apply
error: patch failed: plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/FiniteStateWizardPage.java:1
error: plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/FiniteStateWizardPage.java: patch does not apply
Patch failed at 0001 convert CRLF line terminators to CR only
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".

-----Original Message-----
From: Grigoropol, IoanaX
Sent: Thursday, December 06, 2012 6:02 AM
To: Zhang, Jessica; yocto@yoctoproject.org
Subject: RE: [yocto] [PATCH] Fix incompatibility with jre1.6 support for typed HashMap

Hi Jessica,

There seems to be a bit of a mix-up on the new branch in the order of the patches were applied. Also, some files modified under Linux have CRLF ending instead of CR.
Can you please rebase the branch (the new one or the old one) to commit ec4fcf7b478f59e190d9b9fe9b56e44971c4f66c, and then apply the set of 8 patches I resent to the mailing list ?
Bare in mind that the patch before last (that converts from CRLF to CR) will not apply unless applied with option --keep-cr.

Thanks,
Ioana

-----Original Message-----
From: Zhang, Jessica
Sent: Thursday, December 06, 2012 1:12 AM
To: Grigoropol, IoanaX; yocto@yoctoproject.org
Subject: RE: [yocto] [PATCH] Fix incompatibility with jre1.6 support for typed HashMap

Hi Ioana,

None of your patches of today apply so there seems to be some rebase issue. Also, I've added headless build support changes for windows BC plugin, so can you rebase against jzhang/windows-build and resubmit the patch series?

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Ioana Grigoropol
Sent: Wednesday, December 05, 2012 2:41 AM
To: yocto@yoctoproject.org
Subject: [yocto] [PATCH] Fix incompatibility with jre1.6 support for typed HashMap

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@intel.com>
---
.../remote/utils/YoctoHostShellProcessAdapter.java | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java
index 9ab43cf..2dba0a6 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShe
+++ llProcessAdapter.java
@@ -34,6 +34,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {

private Semaphore sem;

+
public YoctoHostShellProcessAdapter(IHostShell hostShell, ProcessStreamBuffer processStreamBuffer, CommandResponseHandler commandResponseHandler) throws IOException {
super(hostShell);
this.processStreamBuffer = processStreamBuffer; @@ -41,7 +42,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
this.calculator = new GitCalculatePercentage();
this.sem = new Semaphore(1);
this.command = "";
- this.commandMonitors = new HashMap<>();
+ this.commandMonitors = new HashMap<String, IProgressMonitor>();
}

public String getLastCommand() {
@@ -50,7 +51,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {

public synchronized void setLastCommand(String lastCommand) {
try {
- // there are still some processes that might take a long time and if we do not wait for them,
+ // there are still some processes that might take a long time and if
+we do not wait for them,
// then the semaphore will not be released, because an interrupted exception will occur
Thread.sleep(2000);
isFinished = false;
@@ -70,6 +71,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {

private class GitCalculatePercentage implements ICalculatePercentage {
final Pattern pattern = Pattern.compile("^Receiving objects:\\s*(\\d+)%.*");
+ @Override
public float calWorkloadDone(String info) throws IllegalArgumentException {
Matcher m = pattern.matcher(info.trim());
if(m.matches()) {
@@ -88,13 +90,16 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
}

private void updateMonitor(final int work){
+
Display.getDefault().asyncExec(new Runnable() {
+
@Override
public void run() {
if (getMonitor() != null) {
getMonitor().worked(work);
}
}
+
});
}

@@ -124,7 +129,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
updateMonitor(delta);
reportedWorkload += delta;
}
-
+
if (reportedWorkload == RemoteHelper.TOTALWORKLOAD)
doneMonitor();
}
@@ -152,8 +157,9 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
continue;
}
setCommandPrompt(value);
+
if (commandPrompt != null && endChar != null && command != null && processStreamBuffer != null &&
- value.startsWith(commandPrompt) && value.endsWith(endChar) &&
+ value.startsWith(commandPrompt) && value.endsWith(endChar) &&
!value.endsWith(command) && processStreamBuffer.getLastOutputLineContaining(command) != null /*&& waitForOutput*/) {
sem.release();
isFinished = true;
@@ -165,7 +171,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
this.commandResponseHandler.response(value, false);
}
}
-
+
}
private void setCommandPrompt(String value) {
if (commandPrompt == null) {
@@ -178,7 +184,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
commandPrompt = value.substring(0, end);
endChar = PROMPT_USER_CH;
}
-
+
}
}
public boolean isFinished() {
--
1.7.9.5

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


Re: QA issue with custom recipe

Jon Szymaniak <jon.szymaniak@...>
 

I am trying to create a simple hello world recipe for a helloworld.c
file. The recipe almost works except it hits a QA issue: WARNING: QA
Issue: hello: Files/directories were installed but not shipped

The warning leads to a failure in the do_rootfs.

WARNING: QA Issue: hello: Files/directories were installed but not shipped
/usr
/usr/bin
ERROR: Function failed: do_rootfs
--------------------------


What am I missing in the recipe?

--
Regards,

Sean D. Liming
Owner
Annabooks
Cell: 858-774-3176


-------------- next part --------------
DESCRIPTION = "Hello World Application"
LICENSE = "GPL-2"
LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58"

SECTION = "apps"

SRC_URI = "file:///home/sean/workspace/Hello/HelloYocto.c"
SRC_URI[md5sum] = "4f5c57b446cc08a7299d4dca58c49cda"
SRC_URI[sha256sum] =
"f357d9214f9c585d8b3997c6a3038eb28b218de264a8bb39ae8474949ad2b98d"

S = "${WORKDIR}"

do_compile() {
${CC} ${CFLAGS} ${LDFLAGS} /home/sean/workspace/Hello/HelloYocto.c -o
helloyocto
}

do_install() {
install -d ${D}${bindir}
install -m 0755 helloyocto ${D}{bindir}
}

Sean,

I think you need to note which files are installed by the packages
associated with this recipe, via:

FILES_${PN} = "${bindir}"

For more info on these, Check out the FILES and CONFFILES
variables in the Poky Reference Manual. I also found it helpful
to grep around some of the bigger recipes to see how they use
these. (I got a bit tripped up with some libraries with the sonames set!)


Regards,
Jon


QA issue with custom recipe

Sean Liming <sean.liming@...>
 

I am trying to create a simple hello world recipe for a helloworld.c file. The recipe almost works except it hits a QA issue: WARNING: QA Issue: hello: Files/directories were installed but not shipped

The warning leads to a failure in the do_rootfs.

Base image: core-image-minimal, and here is the build output:
-----------------------
Build Configuration:
BB_VERSION = "1.16.0"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "cedartrail"
DISTRO = "poky"
DISTRO_VERSION = "1.3"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp
meta-intel
meta-cedartrail
meta-apps = "<unknown>:<unknown>"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: QA Issue: hello: Files/directories were installed but not shipped
/usr
/usr/bin
ERROR: Function failed: do_rootfs
--------------------------


What am I missing in the recipe?

--
Regards,

Sean D. Liming
Owner
Annabooks
Cell: 858-774-3176


Re: FILESEXTRAPATHS needs to be explained *way* better

Robert P. J. Day
 

On Fri, 7 Dec 2012, Paul Eggleton wrote:

On Friday 07 December 2012 08:04:58 Robert P. J. Day wrote:

i find the current, widespread usage of this form (with the colon):

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

potentially misleading since people reading the .bbappend file will
(quite naturally) assume that, hey, that must represent a literal
prepend since it includes the colon.
It *is* a literal prepend - to FILESEXTRAPATHS. In your discussion
above you are conflating FILESPATH with FILESEXTRAPATHS. The former
is constructed based on the latter in conjuction with OVERRIDES;
they are not the same variable.
ok, i think i finally clued in here, thanks. i was fixated on the
processing when only *one* bbappend file was involved, i didn't think
to back up another level.

my bad. apologies.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: FILESEXTRAPATHS needs to be explained *way* better

Paul Eggleton
 

On Friday 07 December 2012 08:04:58 Robert P. J. Day wrote:
On Thu, 6 Dec 2012, Chris Larson wrote:
On Thu, Dec 6, 2012 at 4:16 PM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:
ok, that's just silly (but that could be the 9% quebec beer
talking). if i'm working with just one layer, then this:

FILESEXTRAPATHS_prepend := "rday"

works fine:

FILESPATH="rday/linux-gnueabi:rday/arm:rday/build-linux:rday/pn-netb
ase:...

if that fails with more than one layer, then that is, quite simply,
asinine.

I really don't see why you're failing to grasp such a basic concept
as a colon separated variable. Do you think you can add something to
PATH without adding a colon?
arrrrrrrgggghhhh ... i'll try this again. as i read it (and i'm
willing to be corrected), the value of FILESEXTRAPATHS_prepend is not
used for a simple, textual prepend. period. end of discussion.

rather, it is used as the basis for extending FILESPATH based on
*processing* that involves taking the value of OVERRIDES into
consideration. using the example i was talking about yesterday (the
meta-ti layer and the netbase recipe), if my netbase .bbappend
contains *only* this:

FILESEXTRAPATHS_prepend := "/rday"

then if i use bitbake-env to see what happens with FILESPATH wrt to
that recipe, i see (replacing ":" with newlines for prettiness):

$ bitbake-env -r netbase FILESPATH | tr : '\n'
Parsing recipes..done.
# FILESPATH="${@base_set_filespath(["${FILE_DIRNAME}/${BP}",
"${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
FILESPATH="/rday/linux-gnueabi
/rday/arm
/rday/build-linux
/rday/pn-netbase
/rday/dm814x-evm
/rday/ti814x
/rday/armv7a
/rday/
/rday/class-target
/rday/forcevariable
/rday/libc-glibc
/rday/
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/li
nux-gnueabi
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/a
rm
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/b
uild-linux
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/p
n-netbase ... snip ...

see? how much clearer can i make this? if you prefer adding the
silly colon to that line, as in:

FILESEXTRAPATHS_prepend := "/rday:"

it ends up making exactly *no* difference. none. zip. squat.
you're quite welcome to add as many as you like:

FILESEXTRAPATHS_prepend := "/rday:::::::::::::::::"

and it will make no difference since, as i read it, you are not
specifying a value to be literally prepended to FILESPATH, you are
identifying a *directory* to be processed (by, i believe, def
base_set_filespath(path, d) in utils.bbclass). if for some bizarre
reason you like to add that superfluous ":", knock yourself out, but
don't claim that it is somehow *necessary* because of a
colon-separated list of directories.

on the other hand, it *is* useful if you want to add, say, *two*
dirtectories, as in:

FILESEXTRAPATHS_prepend := "/rday1:/rday2"
Right, and this is what you'll get if two layers bbappend the same recipe and
both prepend to FILESEXTRAPATHS, which is not an unlikely situation. If you
want that to work correctly then you *must* include the trailing colon. The
easiest thing is to just include it every time you prepend to FILESEXTRAPATHS.

which will produce (predictably):

FILESPATH="/rday1/linux-gnueabi
/rday1/arm
/rday1/build-linux
/rday1/pn-netbase
/rday1/dm814x-evm
/rday1/ti814x
/rday1/armv7a
/rday1/
/rday1/class-target
/rday1/forcevariable
/rday1/libc-glibc
/rday1/
/rday2/linux-gnueabi
/rday2/arm
/rday2/build-linux
/rday2/pn-netbase
/rday2/dm814x-evm
/rday2/ti814x
/rday2/armv7a
/rday2/
/rday2/class-target
/rday2/forcevariable
/rday2/libc-glibc
/rday2/
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/li
nux-gnueabi
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/a
rm
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/b
uild-linux
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/p
n-netbase ... snip ...

so why am i so fixated on this? thanks for asking.

i find the current, widespread usage of this form (with the colon):

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

potentially misleading since people reading the .bbappend file will
(quite naturally) assume that, hey, that must represent a literal
prepend since it includes the colon.
It *is* a literal prepend - to FILESEXTRAPATHS. In your discussion above you
are conflating FILESPATH with FILESEXTRAPATHS. The former is constructed based
on the latter in conjuction with OVERRIDES; they are not the same variable.

i'm willing to bet that, in many cases, those people just added what
they thought was a simple overriding directory name, having no clue
that that was being expanded into multiple directories, one of which
just *happened* to match the directory name they supplied. so things
worked out, but not for the reason they thought.
By saying "just happened" you're implying that it is somehow accidental or
incidental that the directory that the user has specified is added - it is
nothing of the sort. It is completely deliberate and if it did not do so in
fact almost no recipe that used this construct would work.

We know this isn't a particularly self-evident structure; if it makes it
easier, consider it as just a single line of boilerplate when you want to add
or override any file in SRC_URI within a bbappend.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: FILESEXTRAPATHS needs to be explained *way* better

Robert P. J. Day
 

On Thu, 6 Dec 2012, Chris Larson wrote:

On Thu, Dec 6, 2012 at 4:16 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
  ok, that's just silly (but that could be the 9% quebec beer
talking).  if i'm working with just one layer, then this:

FILESEXTRAPATHS_prepend := "rday"

works fine:

FILESPATH="rday/linux-gnueabi:rday/arm:rday/build-linux:rday/pn-netbase:...

if that fails with more than one layer, then that is, quite simply,
asinine.


I really don't see why you're failing to grasp such a basic concept
as a colon separated variable. Do you think you can add something to
PATH without adding a colon?
arrrrrrrgggghhhh ... i'll try this again. as i read it (and i'm
willing to be corrected), the value of FILESEXTRAPATHS_prepend is not
used for a simple, textual prepend. period. end of discussion.

rather, it is used as the basis for extending FILESPATH based on
*processing* that involves taking the value of OVERRIDES into
consideration. using the example i was talking about yesterday (the
meta-ti layer and the netbase recipe), if my netbase .bbappend
contains *only* this:

FILESEXTRAPATHS_prepend := "/rday"

then if i use bitbake-env to see what happens with FILESPATH wrt to
that recipe, i see (replacing ":" with newlines for prettiness):

$ bitbake-env -r netbase FILESPATH | tr : '\n'
Parsing recipes..done.
# FILESPATH="${@base_set_filespath(["${FILE_DIRNAME}/${BP}",
"${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
FILESPATH="/rday/linux-gnueabi
/rday/arm
/rday/build-linux
/rday/pn-netbase
/rday/dm814x-evm
/rday/ti814x
/rday/armv7a
/rday/
/rday/class-target
/rday/forcevariable
/rday/libc-glibc
/rday/
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/linux-gnueabi
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/arm
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/build-linux
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/pn-netbase
... snip ...

see? how much clearer can i make this? if you prefer adding the
silly colon to that line, as in:

FILESEXTRAPATHS_prepend := "/rday:"

it ends up making exactly *no* difference. none. zip. squat.
you're quite welcome to add as many as you like:

FILESEXTRAPATHS_prepend := "/rday:::::::::::::::::"

and it will make no difference since, as i read it, you are not
specifying a value to be literally prepended to FILESPATH, you are
identifying a *directory* to be processed (by, i believe, def
base_set_filespath(path, d) in utils.bbclass). if for some bizarre
reason you like to add that superfluous ":", knock yourself out, but
don't claim that it is somehow *necessary* because of a
colon-separated list of directories.

on the other hand, it *is* useful if you want to add, say, *two*
dirtectories, as in:

FILESEXTRAPATHS_prepend := "/rday1:/rday2"

which will produce (predictably):

FILESPATH="/rday1/linux-gnueabi
/rday1/arm
/rday1/build-linux
/rday1/pn-netbase
/rday1/dm814x-evm
/rday1/ti814x
/rday1/armv7a
/rday1/
/rday1/class-target
/rday1/forcevariable
/rday1/libc-glibc
/rday1/
/rday2/linux-gnueabi
/rday2/arm
/rday2/build-linux
/rday2/pn-netbase
/rday2/dm814x-evm
/rday2/ti814x
/rday2/armv7a
/rday2/
/rday2/class-target
/rday2/forcevariable
/rday2/libc-glibc
/rday2/
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/linux-gnueabi
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/arm
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/build-linux
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/pn-netbase
... snip ...

so why am i so fixated on this? thanks for asking.

i find the current, widespread usage of this form (with the colon):

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

potentially misleading since people reading the .bbappend file will
(quite naturally) assume that, hey, that must represent a literal
prepend since it includes the colon. and they will be wrong. in
fact, i'm willing to bet that, based on that ubiquitous usage, many
people who wrote .bbappend files had no idea that that's what was
happening.

i'm willing to bet that, in many cases, those people just added what
they thought was a simple overriding directory name, having no clue
that that was being expanded into multiple directories, one of which
just *happened* to match the directory name they supplied. so things
worked out, but not for the reason they thought.

as it stands, the way things are done now will work just fine, of
course. but i think it's visually misleading, and not very well
explained.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: Difference of toolchain recipes

Luo Zhenhua-B19537 <B19537@...>
 

Hello Mark,

Thanks a lot, this is very helpful for understanding the different recipes of toolchain.


Best Regards,

Zhenhua

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] On Behalf Of Mark Hatle
Sent: Friday, December 07, 2012 2:05 AM
To: yocto@yoctoproject.org
Subject: Re: [yocto] Difference of toolchain recipes

On 12/6/12 4:00 AM, Luo Zhenhua-B19537 wrote:
Can anybody shed some light, please?


Best Regards,

Zhenhua


-----Original Message-----
From: Luo Zhenhua-B19537
Sent: Tuesday, December 04, 2012 11:53 AM
To: openembedded-core@lists.openembedded.org; 'yocto@yoctoproject.org'
Subject: Difference of toolchain recipes

It is a bit confused for the different recipes of toolchian, can
somebody help to explain what's the difference for those recipes?
E.g. gcc-cross, gcc-cross-canadian, gcc-cross-initial,
gcc-cross-intermediate, gcc- crosssdk, gcc-crosssdk-initial,
gcc-crosssdk-intermediate, gcc-runtime, etc.
gcc-cross-initial - This is the initial compiler needed to bootstrap the
toolchain to build software on the host for the target. (This is a
'native'
package.)

gcc-cross-intermediate - This is the second stage of the bootstrap
process to build software on the host for the target. (This is a 'native'
package.)

gcc-cross - this is the the final stage of the bootstrap process, and
results in the cross compiler to build software on the host for the
target. (This is a 'native' package.) If you are replacing the cross
compiler toolchain with a custom version, this is what you must replace.

gcc-runtime - these are the runtime libraries, but from the toolchain
bootstrapping process. This results in a 'target' binary.

gcc-crosssdk-initial/intermediate - stage 1 and 2 of the a cross compiler
to build from the 'host' to the 'sdk'. Often the SDK is not the same
target as the host. (This is a 'native' binary.)

gcc-crosssdk - this the final stage of the SDK compiler. Again, this is
to build on the host, for the sdk. This is a 'native' binary.

gcc-cross-canadian - This is the compiler included with the SDK to build
on the SDK machine creating software for the target. This is an
'nativesdk' package.

Is there any document for those description?
Not that I know of.. It's one of those things that you kind of need to
know in order to work with it. It likely should be documented somewhere
officially.

--Mark



Best Regards,

Zhenhua
_______________________________________________
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: FILESEXTRAPATHS needs to be explained *way* better

Chris Larson <clarson@...>
 

On Thu, Dec 6, 2012 at 4:16 PM, Robert P. J. Day <rpjday@...> wrote:
  ok, that's just silly (but that could be the 9% quebec beer
talking).  if i'm working with just one layer, then this:

FILESEXTRAPATHS_prepend := "rday"

works fine:

FILESPATH="rday/linux-gnueabi:rday/arm:rday/build-linux:rday/pn-netbase:...

if that fails with more than one layer, then that is, quite simply,
asinine.

I really don't see why you're failing to grasp such a basic concept as a colon separated variable. Do you think you can add something to PATH without adding a colon?
--
Christopher Larson


Re: FILESEXTRAPATHS needs to be explained *way* better

Robert P. J. Day
 

On Thu, 6 Dec 2012, Chris Larson wrote:



On Thu, Dec 6, 2012 at 3:32 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
On Thu, 6 Dec 2012, Chris Larson wrote:

>
>
> On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:
>         in addition, there is absolutely no need to add a ":" to the value
>       as the processing adds that for you, so the many, many examples of
>
>       FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
>       is potentially confusing to folks reading the code.  (that trailing
>       ":" doesn't hurt, but it has no value.)
>
>
> This is wrong. You only don't need the leading : if FILESEXTRAPATHS
> was empty to begin with, which is only the case if that is the first
> and only bbappend adding to it. As soon as you get more than one,
> you'll end up with concatenated values and no separator.

  i'm confused, not sure what this means.  what is the *proper* usage
of that variable?


As I'm pretty sure you've already been told in one of the other 2
threads about this, it's a colon separated list of paths. If you go
appending to it without a separator, you're going to end up with
something useless.

layer1/.../foo.bbappend
FILESEXTRAPATHS_prepend = "${THISDIR}/foo"

layer2/.../foo.bbappend
FILESEXTRAPATHS_prepend = "${THISDIR}/bar"

resulting FILESEXTRAPATHS: layer1/.../foo/layer2/.../bar
ok, that's just silly (but that could be the 9% quebec beer
talking). if i'm working with just one layer, then this:

FILESEXTRAPATHS_prepend := "rday"

works fine:

FILESPATH="rday/linux-gnueabi:rday/arm:rday/build-linux:rday/pn-netbase:...

if that fails with more than one layer, then that is, quite simply,
asinine.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: FILESEXTRAPATHS needs to be explained *way* better

Chris Larson <clarson@...>
 



On Thu, Dec 6, 2012 at 3:49 PM, Gary Thomas <gary@...> wrote:
On 2012-12-06 15:32, Robert P. J. Day wrote:
On Thu, 6 Dec 2012, Chris Larson wrote:



On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day <rpjday@...> wrote:
         in addition, there is absolutely no need to add a ":" to the value
       as the processing adds that for you, so the many, many examples of

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

       is potentially confusing to folks reading the code.  (that trailing
       ":" doesn't hurt, but it has no value.)


This is wrong. You only don't need the leading : if FILESEXTRAPATHS
was empty to begin with, which is only the case if that is the first
and only bbappend adding to it. As soon as you get more than one,
you'll end up with concatenated values and no separator.

   i'm confused, not sure what this means.  what is the *proper* usage
of that variable?

I think Chris means you don't need ":=", you should just use "="

No, := is required whenever you use THISDIR in a bbappend, unless you *really* mean the path to the recipe itself, which is unlikely. THISDIR evaluates based on FILE, which resolves to the current file being parsed, at the time it's expanded. 

Bottom line, what you are trying to create is something that looks like this:
  FILESEXTRAPATHS = "some_path:some_other_path:even_another_path:"
so the ":" at the end of the expression should always be there.

Right :)
--
Christopher Larson


Re: FILESEXTRAPATHS needs to be explained *way* better

Gary Thomas
 

On 2012-12-06 15:32, Robert P. J. Day wrote:
On Thu, 6 Dec 2012, Chris Larson wrote:



On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
in addition, there is absolutely no need to add a ":" to the value
as the processing adds that for you, so the many, many examples of

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

is potentially confusing to folks reading the code. (that trailing
":" doesn't hurt, but it has no value.)


This is wrong. You only don't need the leading : if FILESEXTRAPATHS
was empty to begin with, which is only the case if that is the first
and only bbappend adding to it. As soon as you get more than one,
you'll end up with concatenated values and no separator.
i'm confused, not sure what this means. what is the *proper* usage
of that variable?
I think Chris means you don't need ":=", you should just use "="

Bottom line, what you are trying to create is something that looks like this:
FILESEXTRAPATHS = "some_path:some_other_path:even_another_path:"
so the ":" at the end of the expression should always be there.

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Re: FILESEXTRAPATHS needs to be explained *way* better

Chris Larson <clarson@...>
 



On Thu, Dec 6, 2012 at 3:32 PM, Robert P. J. Day <rpjday@...> wrote:
On Thu, 6 Dec 2012, Chris Larson wrote:

>
>
> On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day <rpjday@...> wrote:
>         in addition, there is absolutely no need to add a ":" to the value
>       as the processing adds that for you, so the many, many examples of
>
>       FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
>       is potentially confusing to folks reading the code.  (that trailing
>       ":" doesn't hurt, but it has no value.)
>
>
> This is wrong. You only don't need the leading : if FILESEXTRAPATHS
> was empty to begin with, which is only the case if that is the first
> and only bbappend adding to it. As soon as you get more than one,
> you'll end up with concatenated values and no separator.

  i'm confused, not sure what this means.  what is the *proper* usage
of that variable?

As I'm pretty sure you've already been told in one of the other 2 threads about this, it's a colon separated list of paths. If you go appending to it without a separator, you're going to end up with something useless.

layer1/.../foo.bbappend
FILESEXTRAPATHS_prepend = "${THISDIR}/foo"

layer2/.../foo.bbappend
FILESEXTRAPATHS_prepend = "${THISDIR}/bar"

resulting FILESEXTRAPATHS: layer1/.../foo/layer2/.../bar
--
Christopher Larson


Re: FILESEXTRAPATHS needs to be explained *way* better

Robert P. J. Day
 

On Thu, 6 Dec 2012, Chris Larson wrote:



On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
  in addition, there is absolutely no need to add a ":" to the value
as the processing adds that for you, so the many, many examples of

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

is potentially confusing to folks reading the code.  (that trailing
":" doesn't hurt, but it has no value.)


This is wrong. You only don't need the leading : if FILESEXTRAPATHS
was empty to begin with, which is only the case if that is the first
and only bbappend adding to it. As soon as you get more than one,
you'll end up with concatenated values and no separator.
i'm confused, not sure what this means. what is the *proper* usage
of that variable?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: FILESEXTRAPATHS needs to be explained *way* better

Chris Larson <clarson@...>
 



On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day <rpjday@...> wrote:
  in addition, there is absolutely no need to add a ":" to the value
as the processing adds that for you, so the many, many examples of

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

is potentially confusing to folks reading the code.  (that trailing
":" doesn't hurt, but it has no value.)

This is wrong. You only don't need the leading : if FILESEXTRAPATHS was empty to begin with, which is only the case if that is the first and only bbappend adding to it. As soon as you get more than one, you'll end up with concatenated values and no separator.
--
Christopher Larson


FILESEXTRAPATHS needs to be explained *way* better

Robert P. J. Day
 

first time digging into FILESPATH and .bbappend files, and i tested
the effect of setting something trivial to see what would happen:

FILESEXTRAPATHS_prepend := "rday"

did this for "netbase" in meta-ti layer, and checked the resulting
value of FILESPATH and (nicely formatted so you can read it), i got:

FILESPATH="rday/linux-gnueabi
rday/arm
rday/build-linux
rday/pn-netbase
rday/beagleboard
rday/omap3
rday/armv7a
rday/
rday/class-target
rday/forcevariable
rday/libc-glibc
rday/
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/linux-gnueabi
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/arm
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/build-linux
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/pn-netbase
... snip ...

that is totally *not* what i expected given the explanation of that
variable in the current docs (unless i've missed it). obviously,
FILESEXTRAPATHS doesn't just add individual directories to FILESPATH
-- it processes and adds based on OVERRIDES, which is fine but that's
not at all obvious.

in addition, there is absolutely no need to add a ":" to the value
as the processing adds that for you, so the many, many examples of

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

is potentially confusing to folks reading the code. (that trailing
":" doesn't hurt, but it has no value.)

at what point is this variable explained in detail?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================