On Jul 15, 2011, at 2:28 PM, Khem Raj wrote:

On Thu, Jul 14, 2011 at 7:36 PM, Kumar Gala <galak@...> wrote:

Where is the best place to ask questions and try and get support for adding some toolchain variations in?

I'm wanting to add support in for a few different flavors of PPC that are not currently supported:

* e500v2 (gcc needs --enable-e500_double, eglibc

this means ABI change especially due to double formats. This should be
doable in machine.conf
files or tune files.

how so? What can I set in there that would actually get passed into gcc's configure (not really seeing anything). Also what exactly do you mean by a machine.conf

* e5500 (64-bit embedded ppc)

this is new I guess. Its like adding a new arch to OE. See around
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/024661.html
is roughly what can be helpful in getting ppc64 going

Thanks, will take a look at that.

- k

In my attempts to get an e500v2/gnuspe toolchain working I was able to get core-image-minimal working. However when I try the 'meta-toolchain' I run into the following below. I believe this is because of TARGET_OS being 'linux-gnuspe'.

Any ideas ?

- k

[kumar@right build-p2020]$ bitbake meta-toolchain

OE Build Configuration:
BB_VERSION = "1.13.2"
TARGET_ARCH = "powerpc"
TARGET_OS = "linux-gnuspe"
MACHINE = "p2020-ds"
DISTRO = "poky"
DISTRO_VERSION = "1.0+snapshot-20110715"
TARGET_FPU = "spe"
meta
meta-yocto = "master:068839698fe192d8846c0ed4db65861448e8e524"

NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'virtual/powerpc-poky-linux-libc-for-gcc'
NOTE: Runtime target 'gcc-cross-canadian-powerpc' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['gcc-cross-canadian-powerpc', 'virtual/powerpc-poky-linux-libc-for-gcc']
NOTE: Runtime target 'task-cross-canadian-powerpc' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['task-cross-canadian-powerpc', 'gcc-cross-canadian-powerpc', 'virtual/powerpc-poky-linux-libc-for-gcc']
ERROR: Required build target 'meta-toolchain' has no buildable providers.
Missing or unbuildable dependency chain was: ['meta-toolchain', 'task-cross-canadian-powerpc', 'gcc-cross-canadian-powerpc', 'virtual/powerpc-poky-linux-libc-for-gcc']
ERROR: Command execution failed: Traceback (most recent call last):
File "/local/home/kumar/git/poky/bitbake/lib/bb/command.py", line 102, in runAsyncCommand
commandmethod(self.cmds_async, self, options)
File "/local/home/kumar/git/poky/bitbake/lib/bb/command.py", line 200, in buildTargets
command.cooker.buildTargets(pkgs_to_build, task)
File "/local/home/kumar/git/poky/bitbake/lib/bb/cooker.py", line 996, in buildTargets
taskdata.add_unresolved(localdata, self.status)
File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 534, in add_unresolved
self.remove_buildtarget(targetid)
File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 491, in remove_buildtarget
self.fail_fnid(fnid, missing_list)
File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 476, in fail_fnid
self.remove_runtarget(target, missing_list)
File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 517, in remove_runtarget
self.fail_fnid(fnid, missing_list)
File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 476, in fail_fnid
self.remove_runtarget(target, missing_list)
File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 517, in remove_runtarget
self.fail_fnid(fnid, missing_list)
File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 471, in fail_fnid
self.remove_buildtarget(target, missing_list)
File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 501, in remove_buildtarget
raise bb.providers.NoProvider(target)
NoProvider: meta-toolchain

A couple commands are missing the version number directory level under
the /opt/poky toolchain installation directory.

Signed-off-by: Robert P. J. Day <rpjday@...>

---

i'll let scott take this as well, and decide whether it's worth
fixing this or just waiting for 1.1. either way works for me.

diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml
index 52f7391..a09cb66 100644
--- a/documentation/yocto-project-qs/yocto-project-qs.xml
+++ b/documentation/yocto-project-qs/yocto-project-qs.xml
@@ -513,7 +513,7 @@
</para>

<literallayout class='monospaced'>
- $ source /opt/poky/environment-setup-&lt;<emphasis>arch</emphasis>&gt;-poky-linux-&lt;<emphasis>if</emphasis>&gt;
+ $ source /opt/poky/1.0/environment-setup-&lt;<emphasis>arch</emphasis>&gt;-poky-linux-&lt;<emphasis>if</emphasis>&gt;

Where:
&lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture:
@@ -547,7 +547,7 @@
</para>

<literallayout class='monospaced'>
- $ source /opt/poky/environment-setup-i686-poky-linux
+ $ source /opt/poky/1.0/environment-setup-i686-poky-linux
$ poky-qemu qemux86 zImage-2.6.34-qemux86-1.0.bin yocto-image-sdk-qemux86-1.0.rootfs.ext3
</literallayout>


--

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

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

On 07/15/2011 03:12 PM, Koen Kooi wrote:

Op 15 jul 2011, om 20:33 heeft Darren Hart het volgende geschreven:

Jason, Koen,

Does anything spring to mind as an obvious fix for this? Perhaps
some kernel parameter initialization string for the graphics
hardware?

I've never seen it in angstrom, so you'd have to see what meta-yocto
is doing different. In other news, for beagleboard please use the
meta-ti layer for that, it's the offcial upstream for beagle and is
known to work.

I'm not using meta-ti because I'm working with Darren to test out support for the rev C board in meta-yocto. We just don't know what difference is causing this :-)

--Jeff

On Thu, Jul 14, 2011 at 7:36 PM, Kumar Gala <galak@...> wrote:

Where is the best place to ask questions and try and get support for adding some toolchain variations in?

I'm wanting to add support in for a few different flavors of PPC that are not currently supported:

* e500v2 (gcc needs --enable-e500_double, eglibc

this means ABI change especially due to double formats. This should be
doable in machine.conf
files or tune files.

* e5500 (64-bit embedded ppc)

this is new I guess. Its like adding a new arch to OE. See around
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/024661.html
is roughly what can be helpful in getting ppc64 going

* e5500 - multilib support for 32/64-bit

there is some thought and work RP has been doing on multilib.

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

Op 15 jul 2011, om 20:33 heeft Darren Hart het volgende geschreven:

Jason, Koen,

Does anything spring to mind as an obvious fix for this? Perhaps some
kernel parameter initialization string for the graphics hardware?

I've never seen it in angstrom, so you'd have to see what meta-yocto is doing different. In other news, for beagleboard please use the meta-ti layer for that, it's the offcial upstream for beagle and is known to work.

--
Darren

On 07/15/2011 08:30 AM, Jeff Mitchell wrote:

Darren Hart suggested I send this to the list...

Attached is a picture of my screen running Terminal. This is on a
BeagleBoard xM rev C connected via its HDMI out to a DVI adapter and
then into a Dell UltraSharp monitor. Angstrom doesn't display these
problems, so the setup should be fine.

I'm not quite sure what is causing this. The resolution is also fairly
low, and I haven't had any success using boot parameters (either the
older video=omapfb:mode variant or the newer DSS2 omapfb.mode variant).

Thanks,
Jeff



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

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

On Fri, 15 Jul 2011, Darren Hart wrote:

On 07/14/2011 05:01 PM, Robert P. J. Day wrote:

just so i'm doing this the right way, what is the appropriate way to
report bitbake fetch errors? with a fully-updated git repo, i just
ran:

$ bitbake -c fetchall -k core-image-sato

and got fetch errors for both of:

* sat-solver
* linux-libc-headers

should i post the more detailed output of the command? the contents
of the log files? etc, etc.

I would check the log files and verify it isn't a local network issue.
After that, sharing the relevant bits of the log.do_fetch logs for the
failed recipes is a good way to report them.

ok, i'm still getting a fetch error for "sat-solver" when trying to
do a fetchall for core-image-sato, and here's the log file:

fatal: Not a git repository (or any of the parent directories): .git
fatal: Not a git repository (or any of the parent directories): .git
ERROR: Function 'Fetcher failure for URL:
'git://gitorious.org/opensuse/sat-solver.git;protocol=git'. Unable to
fetch URL git://gitorious.org/opensuse/sat-solver.git;protocol=git
from any source.' failed

except that git repo looks fine, no?

http://gitorious.org/opensuse/sat-solver

rday

--

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

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

On 07/15/2011 09:55 AM, Scott Garman wrote:

On 07/15/2011 07:15 AM, Robert P. J. Day wrote:

(look on the bright side -- eventually, after many, many patches, i
will have nothing left to whine about.)

:)

I know I can speak for the team in saying we're incredibly grateful for
your help in combing through our documentation. This is a great
contribution to the project.

Agreed - thanks Robert!


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

Jason, Koen,

Does anything spring to mind as an obvious fix for this? Perhaps some
kernel parameter initialization string for the graphics hardware?

--
Darren

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

On 07/14/2011 05:55 PM, tom.zanussi@... wrote:

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

The meta-intel BSPs currently have a number of machine settings common
to all - factor these out into a couple common include files.

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
common/common-bsp-mach.inc | 13 +++++++++++++
common/common-bsp-x.inc | 4 ++++
2 files changed, 17 insertions(+), 0 deletions(-)
create mode 100644 common/common-bsp-mach.inc
create mode 100644 common/common-bsp-x.inc

diff --git a/common/common-bsp-mach.inc b/common/common-bsp-mach.inc
new file mode 100644
index 0000000..b020a84
--- /dev/null
+++ b/common/common-bsp-mach.inc
@@ -0,0 +1,13 @@
+MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 \
+ acpi serial usbgadget"
+
+KERNEL_IMAGETYPE = "bzImage"
+
+SERIAL_CONSOLE = "115200 ttyS0"
+
+MACHINE_EXTRA_RRECOMMENDS = "kernel-modules eee-acpi-scripts"
+

If these are going in common .inc files we need them to be easily
overridden, shouldn't all the above be using the ?= operator?

--
Darren

+IMAGE_FSTYPES ?= "ext3 cpio.gz"
+
+GLIBC_ADDONS = "nptl"
+GLIBC_EXTRA_OECONF = "--with-tls"
diff --git a/common/common-bsp-x.inc b/common/common-bsp-x.inc
new file mode 100644
index 0000000..c012efd
--- /dev/null
+++ b/common/common-bsp-x.inc
@@ -0,0 +1,4 @@
+PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
+PREFERRED_PROVIDER_virtual/libgl ?= "mesa-dri"
+PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xf86-dri-lite"
+PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xf86-dri-lite"

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

On 07/14/2011 05:01 PM, Robert P. J. Day wrote:

just so i'm doing this the right way, what is the appropriate way to
report bitbake fetch errors? with a fully-updated git repo, i just
ran:

$ bitbake -c fetchall -k core-image-sato

and got fetch errors for both of:

* sat-solver
* linux-libc-headers

should i post the more detailed output of the command? the contents
of the log files? etc, etc.

I would check the log files and verify it isn't a local network issue.
After that, sharing the relevant bits of the log.do_fetch logs for the
failed recipes is a good way to report them.

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

Thanks Robert... I will deal with each of these.

ScottR

1) "This optional GNOME mobile-based UI, which is intended for
devices with resolution but restricted size screens ..."

pretty sure there's a word missing before "resolution," no?

2) "OpenSUSE" vs "OpenSuse" ... actually, both of those are wrong,
it should be "openSUSE". :-P

3) near bottom, sample command:

poky-qemu qemux86 zImage-2.6.34-qemux86-1.0.bin \
yocto-image-sdk-qemux86-1.0.rootfs.ext3

neither that kernel image nor rootfs are in downloads, should
pick args that exist if that matters

i'll let scott do with that what he will, and move on to manhandle
the poky handbook. :-)

rday

--

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

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

On 07/15/2011 07:15 AM, Robert P. J. Day wrote:

(look on the bright side -- eventually, after many, many patches, i
will have nothing left to whine about.)

:)

I know I can speak for the team in saying we're incredibly grateful for your help in combing through our documentation. This is a great contribution to the project.

Thanks!

Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

On Jul 15, 2011, at 8:37 AM, Richard Purdie wrote:

On Fri, 2011-07-15 at 08:33 -0500, Kumar Gala wrote:

On Jul 14, 2011, at 9:36 PM, Kumar Gala wrote:

Where is the best place to ask questions and try and get support for adding some toolchain variations in?

I'm wanting to add support in for a few different flavors of PPC that are not currently supported:

* e500v2 (gcc needs --enable-e500_double, eglibc
* e5500 (64-bit embedded ppc)
* e5500 - multilib support for 32/64-bit

The other reason I ask is the recipes today don't seem to use (or allow for use of) --with-cpu.

Wondering who is the expect on these recipes to discuss such issues with.

The tune files (conf/machine/include/tune*) usually set the march and
mcpu options which are added to CFLAGS. Does that provide the
functionality you're looking for?

No, I'm dealing with different configure issues for gcc, eglibc for these targets:

PPC e500v2
PPC e5500 (64-bit, multilib)

- k

Darren Hart suggested I send this to the list...

Attached is a picture of my screen running Terminal. This is on a BeagleBoard xM rev C connected via its HDMI out to a DVI adapter and then into a Dell UltraSharp monitor. Angstrom doesn't display these problems, so the setup should be fine.

I'm not quite sure what is causing this. The resolution is also fairly low, and I haven't had any success using boot parameters (either the older video=omapfb:mode variant or the newer DSS2 omapfb.mode variant).

Thanks,
Jeff

Robert,

You can cross this off your list.

Scott

On Fri, 15 Jul 2011, Rifenbark, Scott M wrote:

Wording change taken care of.

Scott

ok, i can cross that off my list, thanks.

rday

Signed-off-by: Robert P. J. Day <rpjday@...>

---

i think i got them all, i didn't see any other references anywhere
in the docs directory. does this look right?


diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml
index 52f7391..62c95ae 100644
--- a/documentation/yocto-project-qs/yocto-project-qs.xml
+++ b/documentation/yocto-project-qs/yocto-project-qs.xml
@@ -425,7 +425,7 @@
</para>

<literallayout class='monospaced'>
- yocto-eglibc&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-sdk-&lt;<emphasis>release</emphasis>&gt;.tar.bz2
+ yocto-eglibc&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-gmae-&lt;<emphasis>release</emphasis>&gt;.tar.bz2

Where:
&lt;<emphasis>host_system</emphasis>&gt; is a string representing your development system:
@@ -443,7 +443,7 @@
</para>

<literallayout class='monospaced'>
- yocto-eglibc-x86_64-i686-toolchain-sdk-1.0.tar.bz2
+ yocto-eglibc-x86_64-i686-toolchain-gmae-1.0.tar.bz2
</literallayout>

<para>
@@ -455,7 +455,7 @@
<para>
<literallayout class='monospaced'>
$ cd /
- $ sudo tar -xvjf yocto-eglibc-x86_64-i686-toolchain-sdk-1.0.tar.bz2
+ $ sudo tar -xvjf yocto-eglibc-x86_64-i686-toolchain-gmae-1.0.tar.bz2
</literallayout>
</para>
</section>

rday

--

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

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

Wording change taken care of.

Scott