date:20120801

Re: [yocto] [meta-ti] [HOB] issue

2012-08-01 Thread Iorga, Cristian

Hello Tim,

Please fill in a bug report at bugzilla.yoctoproject.org
It will be investigated later on.

Regards,
Cristian Iorga

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Tim Verstraete
Sent: Wednesday, August 01, 2012 9:29 AM
To: Denys Dmytriyenko
Cc: meta...@yoctoproject.org; yocto@yoctoproject.org
Subject: Re: [yocto] [meta-ti] [HOB] issue

 Hi,

 When i use the HOB functionality in yocto with the meta-ti, I get an  error 
message after about 5% with no error message in it. I can only press close.

 I use the default layers but I do see that HOB re-arranges them into:
 Poky/meta
 Poky/meta-hob
 Poky/meta-ti
 Poky/meta-yocto

 I see that I can build using the command line so it has to be  something with 
HOB and not necessary something in yocto.

Thanks in advance,

Kind regards,

Tim

-Original Message-
From: Denys Dmytriyenko [mailto:de...@ti.com]
Sent: dinsdag 31 juli 2012 22:11
To: Tim Verstraete
Cc: meta...@yoctoproject.org
Subject: Re: [meta-ti] [HOB] issue

On Tue, Jul 31, 2012 at 12:04:37PM +, Tim Verstraete wrote:
> Hi,
> 
> When i use the HOB functionality in yocto with the meta-ti, I get an 
> error message after about 5% with no error message in it. I can only press 
> close.
> 
> I use the default layers but I do see that HOB re-arranges them into:
> Poky/meta
> Poky/meta-hob
> Poky/meta-ti
> Poky/meta-yocto
> 
> I see that I can build using the command line so it has to be 
> something with HOB and not necessary something in yocto.

Well, HOB _is_ part of Yocto anyway. While meta-ti may be triggering the issue 
in HOB, you better off reporting it to the main yocto mailing list - feel free 
to copy meta-ti as well.

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

Re: [yocto] [for denzil] kernel.bbclass: Copy bounds.h only if it exists, needed for 2.6.x.

2012-08-01 Thread Leon Woestenberg

Hello Koen,

On 08/01/2012 08:55 AM, Koen Kooi wrote:

Shouldn't this be sent to the oe-core list?!?!?

It was intended for the denzil branch ([for denzil]) of Yocto, that's why I
sent it to yocto@yoctoproject.org.

If that was wrong reasoning, let me know, I would be glad to change
workflow if I know why.

Cheers,

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

Re: [yocto] [SPAM] - RE: [meta-ti] [HOB] issue - Email found in subject

2012-08-01 Thread Tim Verstraete

OK. Where can I find the log file to add to the bugzilla ...

Kind regards,

Tim


-Original Message-
From: Iorga, Cristian [mailto:cristian.io...@intel.com] 
Sent: woensdag 1 augustus 2012 10:08
To: Tim Verstraete; Denys Dmytriyenko
Cc: meta...@yoctoproject.org; yocto@yoctoproject.org
Subject: [SPAM] - RE: [meta-ti] [HOB] issue - Email found in subject

Hello Tim,

Please fill in a bug report at bugzilla.yoctoproject.org It will be 
investigated later on.

Regards,
Cristian Iorga

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Tim Verstraete
Sent: Wednesday, August 01, 2012 9:29 AM
To: Denys Dmytriyenko
Cc: meta...@yoctoproject.org; yocto@yoctoproject.org
Subject: Re: [yocto] [meta-ti] [HOB] issue

 Hi,
 
 When i use the HOB functionality in yocto with the meta-ti, I get an  error 
message after about 5% with no error message in it. I can only press close.
 
 I use the default layers but I do see that HOB re-arranges them into:
 Poky/meta
 Poky/meta-hob
 Poky/meta-ti
 Poky/meta-yocto
 
 I see that I can build using the command line so it has to be  something with 
HOB and not necessary something in yocto.

Thanks in advance,

Kind regards,

Tim

-Original Message-
From: Denys Dmytriyenko [mailto:de...@ti.com]
Sent: dinsdag 31 juli 2012 22:11
To: Tim Verstraete
Cc: meta...@yoctoproject.org
Subject: Re: [meta-ti] [HOB] issue

On Tue, Jul 31, 2012 at 12:04:37PM +, Tim Verstraete wrote:
> Hi,
> 
> When i use the HOB functionality in yocto with the meta-ti, I get an 
> error message after about 5% with no error message in it. I can only press 
> close.
> 
> I use the default layers but I do see that HOB re-arranges them into:
> Poky/meta
> Poky/meta-hob
> Poky/meta-ti
> Poky/meta-yocto
> 
> I see that I can build using the command line so it has to be 
> something with HOB and not necessary something in yocto.

Well, HOB _is_ part of Yocto anyway. While meta-ti may be triggering the issue 
in HOB, you better off reporting it to the main yocto mailing list - feel free 
to copy meta-ti as well.

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

Re: [yocto] [PATCH] kernel.bbclass: Iff exists, copy bounds.h for external module building.

2012-08-01 Thread Leon Woestenberg

On Mon, Jul 30, 2012 at 5:17 PM, Leon Woestenberg <
sidebranch.openembed...@gmail.com> wrote:

> On 12-07-30 11:07 AM, Bruce Ashfield wrote:
>>
>>> On 12-07-28 09:45 AM, Leon Woestenberg wrote:
>>>
 From: Leon Woestenberg


>> Aha. And now I see that Scott G was copied. If this was for 1.2.x of
>> yocto,
>> that needs to be clearly in the subject .. otherwise it is just
>> confusing.
>>
>>
> On Mon, Jul 30, 2012 at 5:09 PM, Bruce Ashfield <
> bruce.ashfi...@windriver.com> wrote:
> Correct, my intention was for Denzil. Agreed, the full fix should be first
> proposed for HEAD, and I should first fix my GIT script foo setup. This
> went wrong in several ways.
>
> Fixed in separate attempt. This thread is closed.

Thanks,

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

[yocto] mechanism to disable package management on target

2012-08-01 Thread Venkata ramana gollamudi

Hi,



Is there any mechanism to disable package management, so that my rootfs 
should not have any package management related packages like opkg etc.

 I found that one of the methods ipk/rpm/deb need to be mandatorily selected. 
Please suggest if any such method exists.



Regards,

Ramana


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

Re: [yocto] mechanism to disable package management on target

2012-08-01 Thread Paul Eggleton

On Wednesday 01 August 2012 11:44:53 Venkata ramana gollamudi wrote:
> Is there any mechanism to disable package management, so that my rootfs
> should not have any package management related packages like opkg etc.
> 
>  I found that one of the methods ipk/rpm/deb need to be mandatorily
> selected. Please suggest if any such method exists.

Definitely - if IMAGE_FEATURES does not contain "package-management" then the 
package manager database and package management tools will not be part of the 
final image. The package manager will still be used to construct the root 
filesystem so you'll still see it being built.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RFC 0/3] Cheat sheet for hello world project

2012-08-01 Thread Atanas Gegov

Hi Jessica,
Thank you for the feedack and the comments!
1. I did the cheat sheet for the "Hello World C++ Autotools Project". I did
not consider the "Hello World ANSI C Autotools Project". Now I will have a
look how to improve this - write an additional cheat sheet for the second
project or adapt my cheat sheet to be genereic enough for both projects.
2. By now the patches apply and work both for "master" and for
"master-indigo". I will follow
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2383 and adapt the cheat
sheet's content when the bug is resloved.

Cheers,
Atanas

On Tue, Jul 31, 2012 at 7:08 PM, Zhang, Jessica wrote:

> Hi Atanas,
>
> This patch set looks nice, couple comments:
>
> 1. Is it just meant for C++ project since it's applicable to C project as
> well
> 2. I'd think this should be targeted for the upcoming 1.3 release that's
> targeted for Oct.. For 1.3 release we are based on the latest Juno release
> and also, there's a new feature added for SDK which makes it rellocatable
> which is under patch review atm.  I'd suggest you  follow bug 2383 once
> it's marked resolved, which means the patch is merged into master.  Then
> pull down the latest master and the latest Eclipse plug-in to capture the
> latest behavior and update the cheatsheet contents accordingly.
>
> Thanks,
> Jessica
>
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:
> yocto-boun...@yoctoproject.org] On Behalf Of Atanas Gegov
> Sent: Tuesday, July 24, 2012 8:54 AM
> To: yocto@yoctoproject.org
> Subject: [yocto] [RFC 0/3] Cheat sheet for hello world project
>
> From: Atanas Gegov 
>
> Hi,
>
> currently the adt manual contains a description of how to create a new
> project (chapter 4.2). Also some videos are explaining how to achieve this.
> Eclipse provides a nice way of interactive tutorials with the cheat sheets
> and I thought it would be nice to have this kind of user help. So I have
> created a cheat sheet for the 'Hello World C++ Autotools Project' project
> delivered with the yocto ide. It guides the user through the process of
> creating and building the hello world project. Some operations such as
> changing to the C/C++ perspective can even be automated helping the user to
> get started with the project.
>
> Cheers, Atanas
>
> Atanas Gegov (3):
>   plugins/sdk.ide.doc.user: Added plugin for ide specific user help
>   feature/sdk: Added user doc plugin
>   plugins/sdk.ide.doc.user: Added cheat sheet for hello world project
>
>  features/org.yocto.sdk/feature.xml |8 +
>  plugins/org.yocto.sdk.ide.doc.user/.classpath  |6 +
>  plugins/org.yocto.sdk.ide.doc.user/.project|   28 +++
>  .../.settings/org.eclipse.jdt.core.prefs   |8 +
>  .../META-INF/MANIFEST.MF   |8 +
>  .../OSGI-INF/l10n/bundle.properties|7 +
>  .../org.yocto.sdk.ide.doc.user/build.properties|6 +
>  .../cheatsheets/createNewHelloWorldProject.xml |  187
> 
>  plugins/org.yocto.sdk.ide.doc.user/plugin.xml  |   13 ++
>  9 files changed, 271 insertions(+), 0 deletions(-)  create mode 100644
> plugins/org.yocto.sdk.ide.doc.user/.classpath
>  create mode 100644 plugins/org.yocto.sdk.ide.doc.user/.project
>  create mode 100644
> plugins/org.yocto.sdk.ide.doc.user/.settings/org.eclipse.jdt.core.prefs
>  create mode 100644 plugins/org.yocto.sdk.ide.doc.user/META-INF/MANIFEST.MF
>  create mode 100644
> plugins/org.yocto.sdk.ide.doc.user/OSGI-INF/l10n/bundle.properties
>  create mode 100644 plugins/org.yocto.sdk.ide.doc.user/build.properties
>  create mode 100644
> plugins/org.yocto.sdk.ide.doc.user/cheatsheets/createNewHelloWorldProject.xml
>  create mode 100644 plugins/org.yocto.sdk.ide.doc.user/plugin.xml
>
> --
> 1.7.5.4
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [denzil-next BREAKAGE] Silent breakage in denzil-next --- uImage*.dts no longer generated

2012-08-01 Thread Leon Woestenberg

Hello Scott,

I tested your denzil-next branch but found breakage that will not fail the
(auto) build.

poky-contrib.git$ git branch
  master
* sgarman/denzil-next
poky-contrib.git$ git log -n1
commit 6a7d4c7dfc574669ea2eeacede1b74e2f55c4675

I'm hitting the "Warning: ${DTS_FILE} is not available!" case.

I'll follow-up later. This was just a heads up that even if the autobuilds
succeed, I would consider this failing.


This is the probable related diff between denzil and denzil-next, I think
fully from commit a40d795e (Zhenhua Luo).
meta/recipes-kernel/linux/linux-dtb.inc:


+++ poky-contrib.git/meta/recipes-kernel/linux/linux-dtb.inc2012-08-01
12:03:42.502612844 +0200
@@ -15,13 +15,35 @@

 do_install_append() {
 if test -n "${KERNEL_DEVICETREE}"; then
-dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o devicetree
${KERNEL_DEVICETREE}
-install -m 0644 devicetree ${D}/boot/devicetree-${KERNEL_VERSION}
-install -d ${DEPLOYDIR}
-install -m 0644 devicetree ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.dtb
-cd ${DEPLOYDIR}
-rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.dtb
-ln -sf ${KERNEL_IMAGE_BASE_NAME}.dtb ${KERNEL_IMAGE_SYMLINK_NAME}.dtb
+for DTS_FILE in ${KERNEL_DEVICETREE}; do
+if [ ! -f ${DTS_FILE} ]; then
+echo "Warning: ${DTS_FILE} is not available!"
+continue
+fi
+DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F "." '{print $1}'`
+DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
"s/${MACHINE}/${DTS_BASE_NAME}/g"`
+DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} | sed
"s/${MACHINE}/${DTS_BASE_NAME}/g"`
+dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o
${DTS_BASE_NAME} ${DTS_FILE}
+install -m 0644 ${DTS_BASE_NAME}
${D}/boot/devicetree-${DTB_SYMLINK_NAME}.dtb
+done
 fi
 }

+do_deploy_append() {
+if test -n "${KERNEL_DEVICETREE}"; then
+for DTS_FILE in ${KERNEL_DEVICETREE}; do
+if [ ! -f ${DTS_FILE} ]; then
+echo "Warning: ${DTS_FILE} is not available!"
+continue
+fi
+DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F "." '{print $1}'`
+DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
"s/${MACHINE}/${DTS_BASE_NAME}/g"`
+DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} | sed
"s/${MACHINE}/${DTS_BASE_NAME}/g"`
+install -d ${DEPLOYDIR}
+install -m 0644 ${B}/${DTS_BASE_NAME}
${DEPLOYDIR}/${DTB_NAME}.dtb
+cd ${DEPLOYDIR}
+ln -sf ${DTB_NAME}.dtb ${DTB_SYMLINK_NAME}.dtb
+cd -
+done
+fi
+}


Regards,

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

Re: [yocto] [denzil-next BREAKAGE] Silent breakage in denzil-next --- uImage*.dts no longer generated

2012-08-01 Thread Leon Woestenberg

Hello Scott, all,

On Wed, Aug 1, 2012 at 4:31 PM, Leon Woestenberg <
sidebranch.openembed...@gmail.com> wrote:

> Hello Scott,
>
> I tested your denzil-next branch but found breakage that will not fail the
> (auto) build.
>
> I'm hitting the "Warning: ${DTS_FILE} is not available!" case.
>
> Disregard the breakage.  Local user error; my KERNEL_DEVICETREE missed the
"${S}" prefix.

However, that being said, should we silently fail with a warning of the
specified device tree (DTS) is missing?  This is clearly a change of
behaviour that makes the build prone to user errors, as I just demonstrated.

I rather have the build fail.

Regards,

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

[yocto] GLIBCTARGETOS ?= "linux-gnueabi" for PowerPC 440 targets

2012-08-01 Thread Elvis Dowson

Hi,
   Perhaps the reason none of my root file system binaries are not working 
or running is because there is no

GLIBCTARGETOS ?= "linux-gnueabi"

in my machine/virtex5.conf or local.conf file? 

I couldn't find any documentation on this, and if this is indeed the correct 
variable name for the current release. 

Could someone please tell me what variables I should set, in order to generate 
a linux-gnueabi binary and cross compiler toolchain, for powerpc?

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

Re: [yocto] Debug with gdbserver

2012-08-01 Thread Darren Hart

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 07/31/2012 11:15 PM, Martin Jansa wrote:
> On Tue, Jul 31, 2012 at 08:47:47PM -0700, Darren Hart wrote:
>> 
>> 
>> On 07/31/2012 08:13 PM, Khem Raj wrote:
>>> 
>>> On Jul 31, 2012, at 7:46 PM, Darren Hart
>>>  wrote:
>>> 
 I am trying to debug a userpsace application that misbehaves
 under poky-tiny. My current approach is use gdbserver on the
 target and attach to the offending process, then connect to
 it on the client using the yocto-built native gdb for the
 target.
 
 I can easily add gdbserver to the target image, and can
 successfully connect it to the process:
 
 # From the target (qemux86) root shell: # dropbearkey -t rsa
 -f ./rsa # dropbear -r ./rsa # DBPID=$(ps | grep dropbear |
 head -n1 | cut -f4 -d ' ') # gdbserver 127.0.0.1:1234
 --attach $DBPID
 
 Now on the host machine (amd64) I want to: $ gdb (gdb)
 target extended-remote 127.0.0.1:1234
 
 Which package do I need to build to get the appropriate gdb
 for the host to remote debug processes on the target?
>>> 
>>> bake cross-gdb for your arch and use it same way as above
>> 
>> ERROR: Nothing PROVIDES 'cross-gdb'
>> 
>> gdb-cross maybe?
>> 
>> Ah that gets a lot farther... and then do_compile fails.
>> 
>> | libgdb.a(python.o): In function `gdbpy_target_wide_charset': |
>> python.c:(.text+0x1c7): undefined reference to
>> `PyUnicodeUCS4_Decode'
>> 
>> And a lot more similar to that. I'm doing this on poky-tiny (so
>> a minimal target libc... shouldn't impact native bits though
>> right?
> 
> http://patchwork.openembedded.org/patch/33345/

Excellent, that gets things building.

Now I'm trying to use it and getting a timeout. I'm investigating, but
if anyone has run into this already and can save me the time, I'd
appreciate it.

I start qemu with:

$ qemu -kernel
/build/poky/master/qemux86_SZ60LW/tmp/deploy/images/bzImage-qemux86.bin
- -initrd
/build/poky/master/qemux86_SZ60LW/tmp/deploy/images/core-image-minimal-qemux86.cpio.gz
- -nographic -append "console=ttyS0 root=/dev/ram0" -redir tcp:1234::1234

Then run the following on the target:

# dropbearkey -t rsa -f ./rsa
# dropbear -r ./rsa
# DBPID=$(ps | grep dropbear | head -n1 | cut -f4 -d ' ')
# gdbserver 127.0.0.1:1234 --attach $DBPID
...
Attached; pid = 41
Listening on port 1234


Then from the host:

$ nmap localhost
...
1234/tcp open  hotline


$ i586-poky-linux-gdb
GNU gdb (GDB) 7.4.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux --target=i586-poky-linux".
For bug reporting instructions, please see:
.
(gdb) target extended-remote 127.0.0.1:1234
Remote debugging using 127.0.0.1:1234
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Remote communication error.  Target disconnected.: Connection reset by
peer.



- -- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQGVfEAAoJEKbMaAwKp364Ug8H/0yXaF/jqZdrl3XEnM0mT4Ef
gvTIEQ4yAr015Ra2TV9kTUEqb0tnKR1chfZDveEmlBf84ZUsnArFvUseaCMQ1sz6
0lG5iAdeY6Cpo4UKPmpxgLCCMo3nEUIULvA4XrsTakvEgUH4DhssmgEOTOi/aaQ3
Fc9YtpUvXjC63eyRNqYk5sEMWzEVMSxbRHUegllGrsK+eeacEYoA1/TFFiK0c6lH
cLL/mZsnbzPFh9a1SteR1D9YC7tmrooGyaWBz/zZ8UYNfTlP5JfsQA/GZHc6wmWn
h6Ml9l9DdnNQxXX8Ff6nyEYgc1714u8OEl/Wno6wwJdCh9U9OvxfRC5KxMKkMWg=
=yC5/
-END PGP SIGNATURE-
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [for denzil] kernel.bbclass: Copy bounds.h only if it exists, needed for 2.6.x.

2012-08-01 Thread Scott Garman


On 08/01/2012 02:08 AM, Leon Woestenberg wrote:

Hello Koen,

On 08/01/2012 08:55 AM, Koen Kooi wrote:

Shouldn't this be sent to the oe-core list?!?!?


It was intended for the denzil branch ([for denzil]) of Yocto, that's
why I sent it to yocto@yoctoproject.org.

If that was wrong reasoning, let me know, I would be glad to change
workflow if I know why.


Hi Leon,

Since Yocto is built upon oe-core, changes to files that live in oe-core 
should really be sent to the oe-core ML. Our workflow is then to pick 
things up from oe-core and move them into the poky git repository.


Both oe-core and poky have denzil branches this patch applies to, so 
you'd still make mention in your subject line that the patch is intended 
for denzil.


The main reason to submit patches to the Yocto ML is if it's specific to 
the meta-yocto layer you find in the Poky git repository, or to discuss 
overall Yocto issues.


Just some things to keep in mind for the future.

Thanks,

Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [denzil-next BREAKAGE] Silent breakage in denzil-next --- uImage*.dts no longer generated

2012-08-01 Thread Scott Garman


On 08/01/2012 07:50 AM, Leon Woestenberg wrote:

Hello Scott, all,

On Wed, Aug 1, 2012 at 4:31 PM, Leon Woestenberg
mailto:sidebranch.openembed...@gmail.com>> wrote:

Hello Scott,

I tested your denzil-next branch but found breakage that will not
fail the (auto) build.

I'm hitting the "Warning: ${DTS_FILE} is not available!" case.

Disregard the breakage.  Local user error; my KERNEL_DEVICETREE missed
the "${S}" prefix.

However, that being said, should we silently fail with a warning of the
specified device tree (DTS) is missing?  This is clearly a change of
behaviour that makes the build prone to user errors, as I just demonstrated.

I rather have the build fail.


Hi Leon,

Thanks for bringing this up. I believe Matthew made the original request 
for this commit (linux-dtb: add multi-dtb build support, 
a40d795ee97d8ada6a0b76c9741a8653fd646893). I'm cc:'ing him on this email 
as well as Richard Purdie, who has yet to review the new commits in my 
denzil-next branch and may also have some input on this issue.


The question in my mind right now is whether this change is too 
risky/change-inducing for a point-release.


Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Debug with gdbserver

2012-08-01 Thread Khem Raj

On Wed, Aug 1, 2012 at 9:22 AM, Darren Hart  wrote:
> (gdb) target extended-remote 127.0.0.1:1234

this should be ip of target which in your case is qemu prolly
something like 192.168.7.2 or somesuch
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Debug with gdbserver

2012-08-01 Thread Darren Hart

On 08/01/2012 10:09 AM, Khem Raj wrote:
> On Wed, Aug 1, 2012 at 9:22 AM, Darren Hart  wrote:
>> (gdb) target extended-remote 127.0.0.1:1234
> 
> this should be ip of target which in your case is qemu prolly
> something like 192.168.7.2 or somesuch
> 

I was trying to use the "redir" feature of qemu which supposedly allows
you to connect to 1234 on the host instead. After looking at this for a
bit and not making any progress, I setup tun/tap networking with qemu
and easily connected using the target IP as you mention above. I'd like
to understand why redir didn't work - as debugging without a full
network on the client would be nice - but for now, I'm moving along.

Thanks,

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

Re: [yocto] [denzil-next BREAKAGE] Silent breakage in denzil-next --- uImage*.dts no longer generated

2012-08-01 Thread McClintock Matthew-B29882

On Wed, Aug 1, 2012 at 11:56 AM, Scott Garman  wrote:
> On 08/01/2012 07:50 AM, Leon Woestenberg wrote:
>>
>> Hello Scott, all,
>>
>> On Wed, Aug 1, 2012 at 4:31 PM, Leon Woestenberg
>> > > wrote:
>>
>> Hello Scott,
>>
>> I tested your denzil-next branch but found breakage that will not
>> fail the (auto) build.
>>
>> I'm hitting the "Warning: ${DTS_FILE} is not available!" case.
>>
>> Disregard the breakage.  Local user error; my KERNEL_DEVICETREE missed
>> the "${S}" prefix.
>>
>> However, that being said, should we silently fail with a warning of the
>> specified device tree (DTS) is missing?  This is clearly a change of
>> behaviour that makes the build prone to user errors, as I just
>> demonstrated.
>>
>> I rather have the build fail.
>
>
> Hi Leon,
>
> Thanks for bringing this up. I believe Matthew made the original request for
> this commit (linux-dtb: add multi-dtb build support,
> a40d795ee97d8ada6a0b76c9741a8653fd646893). I'm cc:'ing him on this email as
> well as Richard Purdie, who has yet to review the new commits in my
> denzil-next branch and may also have some input on this issue.
>
> The question in my mind right now is whether this change is too
> risky/change-inducing for a point-release.

I think the was made this way for people using different Linux tree's
(and Linux versions) specifically which lacked specific device trees
so switching between them causing problems for specific device tree
definitions so with this we could just list them all. For example
p1022ds -> (p1022ds_32b and p1022ds_36b). I could be convinced the
make this an error or at the very least a bb.warn instead of just an
echo since it does seem problematic.

Any change should go through master -> denzil

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

Re: [yocto] build error pandaboard on master

2012-08-01 Thread maniacbug

Yup, I can verify that denzil builds and runs on Pandaboard with meta-ti 
30fb40ebc13614a74c2e237927c60ac43e01d1bc.  Haven't tried master, but don't see 
a need if denzil is going to work.  BTW, I did not find it necessary to use 
meta-oe.


Both core-image-base and core-image-sato are working swell, except for sound.  
Though the latest omap4 kernel has lots of improvements in that area, so I'm in 
the midst of upgrading it to see if thatfind helps.


> Yes, this is a rather touch ball of twine with all these layers - they 
> have to
> be properly aligned to get something that builds.

Wow, try it WITHOUT Yocto/Poky.  Yocto project seems to add stabilization and 
documentation to OE, which is about the only thing that makes it possible to 
get started at all :)

> Work arounds:
>   * You could checkout meta-ti to something that matches denzil
>     Revision 30fb40ebc13614a74c2e237927c60ac43e01d1bc works for me.


I would actually call this the CORRECT solution, not just a workaround.  
meta-ti should create a denzil-tracking branch from this commit.
> How in the world you knew how to find that commit number is the part that 
> amazes me

This commit was identified and discussed on the meta-ti list as the point of 
departure from denzil, that's how I found it, myself.

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

[yocto] [PATCH 0/1] [KERNEL] meta: New Crystal Forest Machine Branch

2012-08-01 Thread kishore . k . bodke

From: Kishore Bodke 

Hi,

This patch set is for creating initial checkin for the
new machine Crystal Forest.

This machine is based on standard/default/common-pc-64.

Please create a new branch called standard/default/common-pc-64/crystalforest
for linux-yocto-3.4 kernel and push this new meta branch.

Thanks
Kishore.

The following changes since commit 459165c1dd61c4e843c36e6a1abeb30949a20ba7:

  kconf: add 8250 Kconfig to hardware listing audit (2012-07-26 16:23:26 -0400)

are available in the git repository at:

  git://git.pokylinux.org/linux-yocto-2.6.37-contrib meta-crystalforest
  
http://git.pokylinux.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=meta-crystalforest

Kishore Bodke (1):
  meta: Crystal Forest Machine Created.

 .../bsp/crystalforest/crystalforest-preempt-rt.scc |   15 +
 .../bsp/crystalforest/crystalforest-standard.scc   |   10 
 .../bsp/crystalforest/crystalforest.cfg|   63 
 .../bsp/crystalforest/crystalforest.scc|   14 +
 4 files changed, 102 insertions(+)
 create mode 100644 
meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-preempt-rt.scc
 create mode 100644 
meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-standard.scc
 create mode 100644 meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.cfg
 create mode 100644 meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.scc

-- 
1.7.9.5

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

[yocto] [PATCH 1/1] [KERNEL] meta: Crystal Forest Machine Created.

2012-08-01 Thread kishore . k . bodke

From: Kishore Bodke 

Initial checkin for the new Crystal Forest Machine Branch.

Signed-off-by: Kishore Bodke 
---
 .../bsp/crystalforest/crystalforest-preempt-rt.scc |   15 +
 .../bsp/crystalforest/crystalforest-standard.scc   |   10 
 .../bsp/crystalforest/crystalforest.cfg|   63 
 .../bsp/crystalforest/crystalforest.scc|   14 +
 4 files changed, 102 insertions(+)
 create mode 100644 
meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-preempt-rt.scc
 create mode 100644 
meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-standard.scc
 create mode 100644 meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.cfg
 create mode 100644 meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.scc

diff --git 
a/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-preempt-rt.scc 
b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-preempt-rt.scc
new file mode 100644
index 000..6c250af
--- /dev/null
+++ b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-preempt-rt.scc
@@ -0,0 +1,15 @@
+define KMACHINE crystalforest
+define KTYPE preempt-rt
+define KARCH x86_64
+
+# no new branch required, re-use the ktypes/preempt-rt branch
+include ktypes/preempt-rt
+include bsp/common-pc-64/common-pc-64.scc
+
+include crystalforest.scc
+
+# default policy for preempt-rt kernels
+include cfg/usb-mass-storage.scc
+include cfg/boot-live.scc
+include features/latencytop/latencytop.scc
+include features/profiling/profiling.scc
diff --git a/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-standard.scc 
b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-standard.scc
new file mode 100644
index 000..9d24c76
--- /dev/null
+++ b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-standard.scc
@@ -0,0 +1,10 @@
+define KMACHINE crystalforest
+define KTYPE standard
+define KARCH x86_64
+
+include bsp/common-pc-64/common-pc-64-standard
+branch crystalforest
+
+include crystalforest.scc
+
+# default policy for standard kernels
diff --git a/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.cfg 
b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.cfg
new file mode 100644
index 000..341cc20
--- /dev/null
+++ b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.cfg
@@ -0,0 +1,63 @@
+CONFIG_PRINTK=y
+
+# Basic hardware support for the box - network, USB, PCI, sound
+CONFIG_NETDEVICES=y
+CONFIG_ATA=y
+CONFIG_ATA_GENERIC=y
+CONFIG_ATA_SFF=y
+CONFIG_PCI=y
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_USB_SUPPORT=y
+CONFIG_USB=y
+CONFIG_USB_ARCH_HAS_EHCI=y
+CONFIG_R8169=y
+CONFIG_PATA_SCH=y
+CONFIG_MMC_SDHCI_PCI=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_PCIEPORTBUS=y
+CONFIG_NET=y
+CONFIG_USB_UHCI_HCD=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_HDA_INTEL=y
+
+# Make sure these are on, otherwise the bootup won't be fun
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_MODULES=y
+CONFIG_SHMEM=y
+CONFIG_TMPFS=y
+CONFIG_PACKET=y
+
+# These are needed for the Poulsbo kernel modules
+CONFIG_I2C=y
+CONFIG_AGP=y
+CONFIG_VFAT_FS=y
+CONFIG_PM=y
+CONFIG_FB=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_INPUT=y
+CONFIG_VIDEO_V4L2=y
+CONFIG_VIDEO_IVTV=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_VIDEO_CAPTURE_DRIVERS=y
+CONFIG_VIDEO_DEV=y
+CONFIG_VIDEO_V4L2_COMMON=y
+CONFIG_I2C_ALGOBIT=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_VIDEO_FB_IVTV=y
+
+# Needed for booting (and using) USB memory sticks
+CONFIG_USB_STORAGE=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_RD_GZIP=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
diff --git a/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.scc 
b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.scc
new file mode 100644
index 000..ff45107
--- /dev/null
+++ b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.scc
@@ -0,0 +1,14 @@
+kconf hardware crystalforest.cfg
+
+include features/i915/i915.scc
+include cfg/8250.scc
+include cfg/x86_64.scc
+include features/uio/uio.scc
+include features/hugetlb/hugetlb.scc
+include features/ixgbe/ixgbe.scc
+include features/igb/igb.scc
+include features/power/intel.scc
+
+include features/latencytop/latencytop.scc
+include features/profiling/profiling.scc
+
-- 
1.7.9.5

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

[yocto] denzil-next (1.2.2) staging branch change

2012-08-01 Thread Scott Garman


Hello,

I just wanted to make a short announcement that I've just renamed my 
sgarman/denzil-next-1.2.2 staging branches to simply sgarman/denzil-next.


oe-core based:
http://git.openembedded.org/openembedded-core-contrib/log/?h=sgarman/denzil-next

poky based:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next

I created the -1.2.2 branches because at the time the Yocto Project 
1.2.1 release was still being finalized and I needed to start tracking 
patches for the next denzil point release. Now that 1.2.1 is out, the 
meaning of denzil-next is no longer ambiguous.


Again, the workflow I'm using is I pull in community requests for denzil 
commits into my sgarman/denzil-next branches, run some tests on them, 
and then submit a pull request to the appropriate mailing lists so 
Richard can then approve and merge them into the official denzil branches.


Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-baryon][PATCH 1/2] webmin: include webmin-module-acl

2012-08-01 Thread Kevin Strasser

Webmin's logging module depends on webmin-module-acl.

Signed-off-by: Kevin Strasser 
---
 recipes-extended/images/baryon-image.bb |1 +
 recipes-extended/webmin/webmin_1.570.bb |2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-extended/images/baryon-image.bb 
b/recipes-extended/images/baryon-image.bb
index dc6b197..56b160c 100644
--- a/recipes-extended/images/baryon-image.bb
+++ b/recipes-extended/images/baryon-image.bb
@@ -22,6 +22,7 @@ IMAGE_INSTALL += "samba procps mdadm e2fsprogs-mke2fs 
util-linux \
  webmin-module-webmincron \
  webmin-module-mediatomb \
  webmin-notice \
+ webmin-module-acl \
  mediatomb \
  proftpd"
 
diff --git a/recipes-extended/webmin/webmin_1.570.bb 
b/recipes-extended/webmin/webmin_1.570.bb
index c30b050..b6c4965 100644
--- a/recipes-extended/webmin/webmin_1.570.bb
+++ b/recipes-extended/webmin/webmin_1.570.bb
@@ -9,7 +9,7 @@ RDEPENDS_${PN} += "perl-module-warnings 
perl-module-warnings-register perl-modul
 RDEPENDS_${PN} += "perl-module-fcntl perl-module-tie-hash perl-module-vars 
perl-module-time-local perl-module-config perl-module-constant"
 RDEPENDS_${PN} += "perl-module-file perl-module-file-glob 
perl-module-file-copy perl-module-sdbm perl-module-sdbm-file 
perl-module-timelocal perl-module-feature"
 
-PR = "r10"
+PR = "r11"
 
 SRC_URI = "${SOURCEFORGE_MIRROR}/webadmin/webmin-${PV}.tar.gz \
   file://setup.sh \
-- 
1.7.9.5

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

[yocto] [meta-baryon][PATCH 2/2] webmin: remove nfsd check from exports-lib.pl

2012-08-01 Thread Kevin Strasser

YOCTO #1719: Webmin expects the userspace version of nsfd and
attempts to find its pid when applying a new set of nfs exports.
This check fails because baryon is configured to install the
kernelspace version. In result the command that is assigned to
apply_cmd will never be executed, and the contents of /exports
are not successfully exported.

Signed-off-by: Kevin Strasser 
---
 recipes-extended/webmin/files/exports-lib.pl.patch |   32 
 recipes-extended/webmin/webmin_1.570.bb|3 +-
 2 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 recipes-extended/webmin/files/exports-lib.pl.patch

diff --git a/recipes-extended/webmin/files/exports-lib.pl.patch 
b/recipes-extended/webmin/files/exports-lib.pl.patch
new file mode 100644
index 000..cdee355
--- /dev/null
+++ b/recipes-extended/webmin/files/exports-lib.pl.patch
@@ -0,0 +1,32 @@
+From 7eba4c98c6953fa6ea76c1620d19524bcfa3a576 Mon Sep 17 00:00:00 2001
+From: Kevin Strasser 
+Date: Wed, 1 Aug 2012 11:51:26 -0700
+Subject: [PATCH] nfs export: remove nfsd check
+
+nfsd runs as a kernel process and does not have a pid. This means
+that the command assigned to apply_cmd will never be executed when
+the user tries to apply changes to nfs exports.
+
+Upstream-Status: Not appropriate [config]
+
+Signed-off-by: Kevin Strasser 
+---
+ exports/exports-lib.pl |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/exports/exports-lib.pl b/exports/exports-lib.pl
+index 22891c0..1c67494 100755
+--- a/exports/exports-lib.pl
 b/exports/exports-lib.pl
+@@ -273,7 +273,7 @@ return !&has_command("rpc.nfsd") && !&has_command("nfsd") 
&&
+ sub restart_mountd
+ {
+ # Try exportfs -r first
+-if ($config{'apply_cmd'} && &find_byname("nfsd") && &find_byname("mountd")) {
++if ($config{'apply_cmd'} && &find_byname("mountd")) {
+   local $out = &backquote_logged("$config{'apply_cmd'} 2>&1 https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Debug with gdbserver

2012-08-01 Thread Khem Raj


On Aug 1, 2012, at 10:16 AM, Darren Hart  wrote:

> 
> 
> On 08/01/2012 10:09 AM, Khem Raj wrote:
>> On Wed, Aug 1, 2012 at 9:22 AM, Darren Hart  wrote:
>>> (gdb) target extended-remote 127.0.0.1:1234
>> 
>> this should be ip of target which in your case is qemu prolly
>> something like 192.168.7.2 or somesuch
>> 
> 
> I was trying to use the "redir" feature of qemu which supposedly allows
> you to connect to 1234 on the host instead. After looking at this for a
> bit and not making any progress, I setup tun/tap networking with qemu
> and easily connected using the target IP as you mention above. I'd like
> to understand why redir didn't work - as debugging without a full
> network on the client would be nice - but for now, I'm moving along.
> 

well redir is visible to qemu gdb stub not to the software stack that qemu is 
running
in your case. although you can use that to debug kernel using qemu. Pass -s 
option 
and qemu will boot kernel using gdb stub and you can debug the kernel from 
address 0
kind of JTAG debugger for poor :)

> Thanks,
> 
> 
> -- 
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Technical Lead - Linux Kernel

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

Re: [yocto] GLIBCTARGETOS ?= "linux-gnueabi" for PowerPC 440 targets

2012-08-01 Thread Khem Raj


On Aug 1, 2012, at 9:18 AM, Elvis Dowson  wrote:

> Hi,
>   Perhaps the reason none of my root file system binaries are not working 
> or running is because there is no
> 
> GLIBCTARGETOS ?= "linux-gnueabi"
> 
> in my machine/virtex5.conf or local.conf file? 

you don't need to set it. it should be automatically computed based on libc and 
arch
your problem seems more like console related. Probably you don't have console 
params
set correctly or securetty does not know about your console device.



> 
> I couldn't find any documentation on this, and if this is indeed the correct 
> variable name for the current release. 
> 
> Could someone please tell me what variables I should set, in order to 
> generate a linux-gnueabi binary and cross compiler toolchain, for powerpc?
> 
> Elvis Dowson
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] Debug with gdbserver

2012-08-01 Thread Darren Hart



On 08/01/2012 03:34 PM, Khem Raj wrote:
> 
> On Aug 1, 2012, at 10:16 AM, Darren Hart  wrote:
> 
>>
>>
>> On 08/01/2012 10:09 AM, Khem Raj wrote:
>>> On Wed, Aug 1, 2012 at 9:22 AM, Darren Hart  wrote:
 (gdb) target extended-remote 127.0.0.1:1234
>>>
>>> this should be ip of target which in your case is qemu prolly
>>> something like 192.168.7.2 or somesuch
>>>
>>
>> I was trying to use the "redir" feature of qemu which supposedly allows
>> you to connect to 1234 on the host instead. After looking at this for a
>> bit and not making any progress, I setup tun/tap networking with qemu
>> and easily connected using the target IP as you mention above. I'd like
>> to understand why redir didn't work - as debugging without a full
>> network on the client would be nice - but for now, I'm moving along.
>>
> 
> well redir is visible to qemu gdb stub not to the software stack that qemu is 
> running
> in your case. although you can use that to debug kernel using qemu. Pass -s 
> option 
> and qemu will boot kernel using gdb stub and you can debug the kernel from 
> address 0
> kind of JTAG debugger for poor :)


Oh. Duh. :-)

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

Re: [yocto] [PATCH 1/1] [KERNEL] meta: Crystal Forest Machine Created.

2012-08-01 Thread Darren Hart

Hi Kishore,

On 08/01/2012 12:15 PM, kishore.k.bo...@intel.com wrote:
> From: Kishore Bodke 
> 
> Initial checkin for the new Crystal Forest Machine Branch.
> 
> Signed-off-by: Kishore Bodke 
> ---
>  .../bsp/crystalforest/crystalforest-preempt-rt.scc |   15 +
>  .../bsp/crystalforest/crystalforest-standard.scc   |   10 
>  .../bsp/crystalforest/crystalforest.cfg|   63 
> 
>  .../bsp/crystalforest/crystalforest.scc|   14 +
>  4 files changed, 102 insertions(+)
>  create mode 100644 
> meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-preempt-rt.scc
>  create mode 100644 
> meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-standard.scc
>  create mode 100644 meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.cfg
>  create mode 100644 meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.scc
> 
> diff --git 
> a/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-preempt-rt.scc 
> b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-preempt-rt.scc
> new file mode 100644
> index 000..6c250af
> --- /dev/null
> +++ b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-preempt-rt.scc
> @@ -0,0 +1,15 @@
> +define KMACHINE crystalforest
> +define KTYPE preempt-rt
> +define KARCH x86_64
> +
> +# no new branch required, re-use the ktypes/preempt-rt branch
> +include ktypes/preempt-rt
> +include bsp/common-pc-64/common-pc-64.scc
> +
> +include crystalforest.scc
> +
> +# default policy for preempt-rt kernels
> +include cfg/usb-mass-storage.scc
> +include cfg/boot-live.scc
> +include features/latencytop/latencytop.scc
> +include features/profiling/profiling.scc
> diff --git 
> a/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-standard.scc 
> b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-standard.scc
> new file mode 100644
> index 000..9d24c76
> --- /dev/null
> +++ b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest-standard.scc
> @@ -0,0 +1,10 @@
> +define KMACHINE crystalforest
> +define KTYPE standard
> +define KARCH x86_64
> +
> +include bsp/common-pc-64/common-pc-64-standard
> +branch crystalforest
> +
> +include crystalforest.scc
> +
> +# default policy for standard kernels
> diff --git a/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.cfg 
> b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.cfg
> new file mode 100644
> index 000..341cc20
> --- /dev/null
> +++ b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.cfg
> @@ -0,0 +1,63 @@
> +CONFIG_PRINTK=y
> +
> +# Basic hardware support for the box - network, USB, PCI, sound
> +CONFIG_NETDEVICES=y
> +CONFIG_ATA=y
> +CONFIG_ATA_GENERIC=y
> +CONFIG_ATA_SFF=y
> +CONFIG_PCI=y
> +CONFIG_MMC=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_USB_SUPPORT=y
> +CONFIG_USB=y

USB support should be pulled in using the various usb scc files Tom
created relatively recently.

> +CONFIG_USB_ARCH_HAS_EHCI=y
> +CONFIG_R8169=y
> +CONFIG_PATA_SCH=y
> +CONFIG_MMC_SDHCI_PCI=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_PCIEPORTBUS=y
> +CONFIG_NET=y
> +CONFIG_USB_UHCI_HCD=y
> +CONFIG_BLK_DEV_SD=y
> +CONFIG_CHR_DEV_SG=y
> +CONFIG_SOUND=y
> +CONFIG_SND=y
> +CONFIG_SND_HDA_INTEL=y
> +
> +# Make sure these are on, otherwise the bootup won't be fun
> +CONFIG_UNIX=y
> +CONFIG_INET=y
> +CONFIG_MODULES=y
> +CONFIG_SHMEM=y
> +CONFIG_TMPFS=y
> +CONFIG_PACKET=y
> +
> +# These are needed for the Poulsbo kernel modules
> +CONFIG_I2C=y
> +CONFIG_AGP=y
> +CONFIG_VFAT_FS=y

VFAT_FS is required for Poulsbo kernel modules?

This would make more sense as a poulsbo.scc and .cfg file.

> +CONFIG_PM=y
> +CONFIG_FB=y
> +CONFIG_BACKLIGHT_LCD_SUPPORT=y
> +CONFIG_BACKLIGHT_CLASS_DEVICE=y
> +CONFIG_INPUT=y
> +CONFIG_VIDEO_V4L2=y
> +CONFIG_VIDEO_IVTV=y
> +CONFIG_MEDIA_SUPPORT=y
> +CONFIG_VIDEO_CAPTURE_DRIVERS=y
> +CONFIG_VIDEO_DEV=y
> +CONFIG_VIDEO_V4L2_COMMON=y
> +CONFIG_I2C_ALGOBIT=y
> +CONFIG_FB_CFB_COPYAREA=y
> +CONFIG_FB_CFB_IMAGEBLIT=y
> +CONFIG_FB_CFB_FILLRECT=y
> +CONFIG_VIDEO_FB_IVTV=y
> +
> +# Needed for booting (and using) USB memory sticks
> +CONFIG_USB_STORAGE=y
> +CONFIG_BLK_DEV_RAM=y
> +CONFIG_BLK_DEV_LOOP=y
> +CONFIG_BLK_DEV_INITRD=y
> +CONFIG_RD_GZIP=y
> +CONFIG_NLS_CODEPAGE_437=y
> +CONFIG_NLS_ISO8859_1=y

All this is taken care of with the:

> +include cfg/usb-mass-storage.scc
> +include cfg/boot-live.scc

lines which are missing from your non-preempt-rt bsp file.

> diff --git a/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.scc 
> b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.scc
> new file mode 100644
> index 000..ff45107
> --- /dev/null
> +++ b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.scc
> @@ -0,0 +1,14 @@
> +kconf hardware crystalforest.cfg
> +
> +include features/i915/i915.scc

Sorry, are Poulsbo and i915 the same thing?

> +include cfg/8250.scc
> +include cfg/x86_64.scc
> +include features/uio/uio.scc
> +include features/hugetlb/hugetlb.scc
> +include features/ixgbe/ixgbe.scc
> +include features/igb/igb.scc
> +include features/power/intel.scc
> +

Insert usb-mass

Re: [yocto] GLIBCTARGETOS ?= "linux-gnueabi" for PowerPC 440 targets

2012-08-01 Thread Elvis Dowson

Hi Khem,

On Aug 2, 2012, at 2:37 AM, Khem Raj wrote:

> On Aug 1, 2012, at 9:18 AM, Elvis Dowson  wrote:
> 
>> Hi,
>>  Perhaps the reason none of my root file system binaries are not working 
>> or running is because there is no
>> 
>> GLIBCTARGETOS ?= "linux-gnueabi"
>> 
>> in my machine/virtex5.conf or local.conf file? 
> 
> you don't need to set it. it should be automatically computed based on libc 
> and arch
> your problem seems more like console related. Probably you don't have console 
> params
> set correctly or securetty does not know about your console device.

You're right. After rebuilding it, with that variable set, it made no 
difference in the generated
binaries, (e.g. generate a tool chain powerpc-poky-linux-gnueabi-gcc) nor did 
it 
change the situation with my having no console login or bash prompt.

The serial port that I am using is ttyS0. There is an entry for ttyS0 under 
/dev in my ramdisk
, and my /etc/device_table also has an entry for ttyS. 

I have also checked that my securetty has an entry for ttyS0.

I have tried all possible option, e.g. try to get inittab running first with 

S:2345:respawn:/sbin/getty 9600 ttyS0

then with

S:2345:respawn:/bin/sh 9600 ttyS0

and then after that didn't work, tried kernel bootargs with init=/bin/sh or 
init=/sbin/getty

I have even enabled verbose kernel driver debug messages and it appears to be 
correctly registering the driver, and doing everything correct at the kernel 
level, but the moment it hits init, it doesn't display anything on the console. 
This appear to work fine, displaying output on the ttyS0 console, as specified 
in the device tree upto the point just before it attempts to run init. As soon 
as init runs, I get no output on the console, in terms of a login prompt or a 
bash prompt.

You can see detailed kernel bootlogs output from gdb here:

http://forums.xilinx.com/t5/Embedded-Linux/PowerPC-kernel-fails-to-boot-with-linux-3-3-0-using-xps/td-p/251194/page/2

Best regards,

Elvis Dowson

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

Re: [yocto] GLIBCTARGETOS ?= "linux-gnueabi" for PowerPC 440 targets

2012-08-01 Thread McClintock Matthew-B29882

Are you running with prelinking? You might try disabling that. It's in
local.conf under IMAGE_CLASSES I believe.

-M

On Wed, Aug 1, 2012 at 9:44 PM, Elvis Dowson  wrote:
> Hi Khem,
>
> On Aug 2, 2012, at 2:37 AM, Khem Raj wrote:
>
>> On Aug 1, 2012, at 9:18 AM, Elvis Dowson  wrote:
>>
>>> Hi,
>>>  Perhaps the reason none of my root file system binaries are not 
>>> working or running is because there is no
>>>
>>> GLIBCTARGETOS ?= "linux-gnueabi"
>>>
>>> in my machine/virtex5.conf or local.conf file?
>>
>> you don't need to set it. it should be automatically computed based on libc 
>> and arch
>> your problem seems more like console related. Probably you don't have 
>> console params
>> set correctly or securetty does not know about your console device.
>
> You're right. After rebuilding it, with that variable set, it made no 
> difference in the generated
> binaries, (e.g. generate a tool chain powerpc-poky-linux-gnueabi-gcc) nor did 
> it
> change the situation with my having no console login or bash prompt.
>
> The serial port that I am using is ttyS0. There is an entry for ttyS0 under 
> /dev in my ramdisk
> , and my /etc/device_table also has an entry for ttyS.
>
> I have also checked that my securetty has an entry for ttyS0.
>
> I have tried all possible option, e.g. try to get inittab running first with
>
> S:2345:respawn:/sbin/getty 9600 ttyS0
>
> then with
>
> S:2345:respawn:/bin/sh 9600 ttyS0
>
> and then after that didn't work, tried kernel bootargs with init=/bin/sh or 
> init=/sbin/getty
>
> I have even enabled verbose kernel driver debug messages and it appears to be 
> correctly registering the driver, and doing everything correct at the kernel 
> level, but the moment it hits init, it doesn't display anything on the 
> console. This appear to work fine, displaying output on the ttyS0 console, as 
> specified in the device tree upto the point just before it attempts to run 
> init. As soon as init runs, I get no output on the console, in terms of a 
> login prompt or a bash prompt.
>
> You can see detailed kernel bootlogs output from gdb here:
>
> http://forums.xilinx.com/t5/Embedded-Linux/PowerPC-kernel-fails-to-boot-with-linux-3-3-0-using-xps/td-p/251194/page/2
>
> Best regards,
>
> Elvis Dowson
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] GLIBCTARGETOS ?= "linux-gnueabi" for PowerPC 440 targets

2012-08-01 Thread Khem Raj


On Aug 1, 2012, at 7:44 PM, Elvis Dowson  wrote:

> Hi Khem,
> 
> On Aug 2, 2012, at 2:37 AM, Khem Raj wrote:
> 
>> On Aug 1, 2012, at 9:18 AM, Elvis Dowson  wrote:
>> 
>>> Hi,
>>> Perhaps the reason none of my root file system binaries are not working 
>>> or running is because there is no
>>> 
>>> GLIBCTARGETOS ?= "linux-gnueabi"
>>> 
>>> in my machine/virtex5.conf or local.conf file? 
>> 
>> you don't need to set it. it should be automatically computed based on libc 
>> and arch
>> your problem seems more like console related. Probably you don't have 
>> console params
>> set correctly or securetty does not know about your console device.
> 
> You're right. After rebuilding it, with that variable set, it made no 
> difference in the generated
> binaries, (e.g. generate a tool chain powerpc-poky-linux-gnueabi-gcc) nor did 
> it 
> change the situation with my having no console login or bash prompt.
> 
> The serial port that I am using is ttyS0. There is an entry for ttyS0 under 
> /dev in my ramdisk
> , and my /etc/device_table also has an entry for ttyS. 
> 
> I have also checked that my securetty has an entry for ttyS0.
> 
> I have tried all possible option, e.g. try to get inittab running first with 
> 
> S:2345:respawn:/sbin/getty 9600 ttyS0
> 
> then with
> 
> S:2345:respawn:/bin/sh 9600 ttyS0

well. When I look into virtext configuration then I see

SERIAL_CONSOLE ?= "115200 ttyUL0"

I wonder if you have tried that configuration for serial console.


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

Re: [yocto] GLIBCTARGETOS ?= "linux-gnueabi" for PowerPC 440 targets

2012-08-01 Thread Khem Raj


On Aug 1, 2012, at 8:50 PM, McClintock Matthew-B29882  
wrote:

> Are you running with prelinking? You might try disabling that. It's in
> local.conf under IMAGE_CLASSES I believe.
> 

FWIW I have seen issues with prelink + ppc64 that said ppc32 + prelink has 
worked well for me

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

Re: [yocto] [SPAM] - RE: [meta-ti] [HOB] issue - Email found in subject

2012-08-01 Thread Tim Verstraete

I filed a bug report: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2875 

-Original Message-
From: Iorga, Cristian [mailto:cristian.io...@intel.com] 
Sent: woensdag 1 augustus 2012 10:08
To: Tim Verstraete; Denys Dmytriyenko
Cc: meta...@yoctoproject.org; yocto@yoctoproject.org
Subject: [SPAM] - RE: [meta-ti] [HOB] issue - Email found in subject

Hello Tim,

Please fill in a bug report at bugzilla.yoctoproject.org It will be 
investigated later on.

Regards,
Cristian Iorga

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Tim Verstraete
Sent: Wednesday, August 01, 2012 9:29 AM
To: Denys Dmytriyenko
Cc: meta...@yoctoproject.org; yocto@yoctoproject.org
Subject: Re: [yocto] [meta-ti] [HOB] issue

 Hi,
 
 When i use the HOB functionality in yocto with the meta-ti, I get an  error 
message after about 5% with no error message in it. I can only press close.
 
 I use the default layers but I do see that HOB re-arranges them into:
 Poky/meta
 Poky/meta-hob
 Poky/meta-ti
 Poky/meta-yocto
 
 I see that I can build using the command line so it has to be  something with 
HOB and not necessary something in yocto.

Thanks in advance,

Kind regards,

Tim

-Original Message-
From: Denys Dmytriyenko [mailto:de...@ti.com]
Sent: dinsdag 31 juli 2012 22:11
To: Tim Verstraete
Cc: meta...@yoctoproject.org
Subject: Re: [meta-ti] [HOB] issue

On Tue, Jul 31, 2012 at 12:04:37PM +, Tim Verstraete wrote:
> Hi,
> 
> When i use the HOB functionality in yocto with the meta-ti, I get an 
> error message after about 5% with no error message in it. I can only press 
> close.
> 
> I use the default layers but I do see that HOB re-arranges them into:
> Poky/meta
> Poky/meta-hob
> Poky/meta-ti
> Poky/meta-yocto
> 
> I see that I can build using the command line so it has to be 
> something with HOB and not necessary something in yocto.

Well, HOB _is_ part of Yocto anyway. While meta-ti may be triggering the issue 
in HOB, you better off reporting it to the main yocto mailing list - feel free 
to copy meta-ti as well.

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

Re: [yocto] [meta-ti] [HOB] issue

Re: [yocto] [for denzil] kernel.bbclass: Copy bounds.h only if it exists, needed for 2.6.x.

Re: [yocto] [SPAM] - RE: [meta-ti] [HOB] issue - Email found in subject

Re: [yocto] [PATCH] kernel.bbclass: Iff exists, copy bounds.h for external module building.

[yocto] mechanism to disable package management on target

Re: [yocto] mechanism to disable package management on target

Re: [yocto] [RFC 0/3] Cheat sheet for hello world project

[yocto] [denzil-next BREAKAGE] Silent breakage in denzil-next --- uImage*.dts no longer generated

Re: [yocto] [denzil-next BREAKAGE] Silent breakage in denzil-next --- uImage*.dts no longer generated

[yocto] GLIBCTARGETOS ?= "linux-gnueabi" for PowerPC 440 targets

Re: [yocto] Debug with gdbserver

Re: [yocto] [for denzil] kernel.bbclass: Copy bounds.h only if it exists, needed for 2.6.x.

Re: [yocto] [denzil-next BREAKAGE] Silent breakage in denzil-next --- uImage*.dts no longer generated

Re: [yocto] Debug with gdbserver

Re: [yocto] Debug with gdbserver

Re: [yocto] [denzil-next BREAKAGE] Silent breakage in denzil-next --- uImage*.dts no longer generated

Re: [yocto] build error pandaboard on master

[yocto] [PATCH 0/1] [KERNEL] meta: New Crystal Forest Machine Branch

[yocto] [PATCH 1/1] [KERNEL] meta: Crystal Forest Machine Created.

[yocto] denzil-next (1.2.2) staging branch change

[yocto] [meta-baryon][PATCH 1/2] webmin: include webmin-module-acl

[yocto] [meta-baryon][PATCH 2/2] webmin: remove nfsd check from exports-lib.pl

Re: [yocto] Debug with gdbserver

Re: [yocto] GLIBCTARGETOS ?= "linux-gnueabi" for PowerPC 440 targets

Re: [yocto] Debug with gdbserver

Re: [yocto] [PATCH 1/1] [KERNEL] meta: Crystal Forest Machine Created.

Re: [yocto] GLIBCTARGETOS ?= "linux-gnueabi" for PowerPC 440 targets

Re: [yocto] GLIBCTARGETOS ?= "linux-gnueabi" for PowerPC 440 targets

Re: [yocto] GLIBCTARGETOS ?= "linux-gnueabi" for PowerPC 440 targets

Re: [yocto] GLIBCTARGETOS ?= "linux-gnueabi" for PowerPC 440 targets

Re: [yocto] [SPAM] - RE: [meta-ti] [HOB] issue - Email found in subject

31 matches

Site Navigation

Mail list logo

Footer information