date:20140415

[yocto] bitbake co from SVN with Authentication

2014-04-15 Thread Laurent Joli

Hello,

I am try to checkout some file from a SVN with authentification. But
bitbake say that :


ERROR: Function failed: Fetcher failure: Fetch command failed with exit
code 1, output:
svn: E170001: Unable to connect to a repository at URL 'http://XXX'
svn: E170001: OPTIONS of 'http://XXX': authorization failed: Could not
authenticate to server: ignored Negotiate challenge, rejected Basic
challenge

ERROR: Logfile of failure stored in:
/home/g179256/yocto/XX/armv7a-vfp-neon-poky-linux-gnueabi/ti-dcg3-app/loadNG-r0/temp/log.do_fetch.6211
Log data follows:
| DEBUG: Executing python function do_fetch
| DEBUG: Executing python function base_do_fetch
| DEBUG: Fetcher accessed the network with the command /usr/bin/env svn
--non-interactive --trust-server-cert info --no-auth-cache http://XXX
| DEBUG: Running export SSH_AGENT_PID="3606"; export
SSH_AUTH_SOCK="/tmp/ssh-zEFWxgcc3553/agent.3553"; export http_proxy=""; 
export HOME="/home/g179256"; LANG=C LC_ALL=C /usr/bin/env svn
--non-interactive --trust-server-cert info --no-auth-cache http://XXX
| DEBUG: Python function base_do_fetch finished
| DEBUG: Python function do_fetch finished
| ERROR: Function failed: Fetcher failure: Fetch command failed with
exit code 1, output:
| svn: E170001: Unable to connect to a repository at URL 'http://XXX'
| svn: E170001: OPTIONS of 'http://XXX': authorization failed: Could not
authenticate to server: ignored Negotiate challenge, rejected Basic
challenge
|
ERROR: Task 0
(/home/g179256/yocto/../meta-layer-third-party/meta-custom/recipes-plc/ti-dcg3-app/ti-dcg3-app_loadNG.bb,
do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 236 tasks of which 2 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:
 
/home/g179256/yocto_urd3/../meta-layer-third-party/meta-custom/recipes-plc/ti-dcg3-app/ti-dcg3-app_loadNG.bb,
do_fetch
Summary: There were 32 WARNING messages shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Why bitbake does not ask me my username and my password ?


Best regards,
---
Laurent J


#
" Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caractÃ¨ privÃ©S'ils ne vous sont
pas destinÃ© nous vous signalons qu'il est strictement interdit de les
divulguer, de les reproduire ou d'en utiliser de quelque maniÃ¨ que ce
soit le contenu. Si ce message vous a Ã© transmis par erreur, merci d'en
informer l'expÃ©teur et de supprimer immÃ©atement de votre systÃ¨
informatique ce courriel ainsi que tous les documents qui y sont attachÃ©"


   **

" This e-mail and any attached documents may contain confidential or
proprietary information. If you are not the intended recipient, you are
notified that any dissemination, copying of this e-mail and any attachments
thereto or use of their contents by any means whatsoever is strictly
prohibited. If you have received this e-mail in error, please advise the
sender immediately and delete this e-mail and all attached documents
from your computer system."
#

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

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Stanacar, StefanX




On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > > Very interesting results!  These are the results from the build 
> > > > > > > hosts I have:
> > > > > > >   Fedora 13 (i686) - fails
> > > > > > >   Fedora 17 (i686) - fails
> > > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > > 
> > > > > > Interesting indeed. I have no idea what's so special about Fedora 
> > > > > > host - this 
> > > > > > is the first time I hear about issues with it. I may try 
> > > > > > experimenting with 
> > > > > > different VMs once I have more time...
> > > > > 
> > > > > I've been having a look at this. The biggest differences I can find
> > > > > between working and non working builds is the path length to the build
> > > > > directory for the kernel. This is from comparing vmlinux files from
> > > > > working and non working builds.
> > > > > 
> > > > > Works:
> > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > 
> > > > > Doesn't Work:
> > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > 
> > > > > I also have been wondering if the version strings may be making a
> > > > > difference.
> > > > > 
> > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where 
> > > > > I
> > > > > truncated the path length to a "working" build path length and patched
> > > > > in the same version strings:
> > > > > 
> > > > > const char linux_banner[] = 
> > > > >"Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
> > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
> > > > > 
> > > > > const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
> > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > 
> > > > > to init/version.c.
> > > > > 
> > > > > I don't have hardware and would be interested to know if the kernel
> > > > > linked to above works or not. If it doesn't, it rules out these path 
> > > > > and
> > > > > string lengths, if it does work, it points to a problem there.
> > > > 
> > > > Richard,
> > > > 
> > > > Good catch! It boots:
> > > 
> > > Thanks Denys, this helps narrow down the issue. I've shared
> > > http://dan.rpsys.net/uImage-rp3 which is the same as the last one but
> > > with my changes to version.c reverted. The one should tell us if its the
> > > paths or the strings.
> > 
> > This one also boots for me:
> > 
> > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 (GCC) 
> > ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014
> > 
> > 
> > > I'm guessing the path problem is more likely but anything is possible.
> > > This is starting to look like some kind of compiler or linker issue. If
> > > it is that, it would help to have more data points about what works and
> > > what doesn't. With that in mind could people who have good or bad builds
> > > please share the paths they built the kernels in so we can see if we can
> > > spot some kind of pattern.
> 
> BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it 
> works.
> 

I can confirm:
 build dir in /home/stefans/b1  works,
but /home/stefans/yocto/poky/build doesn't.

Cheers,
Stefan

> -- 
> Denys

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

Re: [yocto] bitbake co from SVN with Authentication

2014-04-15 Thread Sathish Kumar Balasubramaniam -ERS, HCL Tech

Hi Laurent,

For SVN, for ex, if the SVN path is http://svn.server.com/svn/project/ti

the "SRC_URI, SRCREV" should be in the following format

SRCREV = ""
SRC_URI = 
"svn://svn.server.com/svn/project;module=ti;protocol=http;user="

But before this execution, login to the above , at least one time you 
need to do svn checkout using the regular command line and when asks to save 
password, give yes to save.


Regards,
B.Sathish Kumar

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Laurent Joli
Sent: Tuesday, April 15, 2014 2:32 PM
To: yocto@yoctoproject.org
Subject: [yocto] bitbake co from SVN with Authentication


Hello,



I am try to checkout some file from a SVN with authentification. But

bitbake say that :





ERROR: Function failed: Fetcher failure: Fetch command failed with exit

code 1, output:

svn: E170001: Unable to connect to a repository at URL 'http://XXX'

svn: E170001: OPTIONS of 'http://XXX': authorization failed: Could not

authenticate to server: ignored Negotiate challenge, rejected Basic

challenge



ERROR: Logfile of failure stored in:

/home/g179256/yocto/XX/armv7a-vfp-neon-poky-linux-gnueabi/ti-dcg3-app/loadNG-r0/temp/log.do_fetch.6211

Log data follows:

| DEBUG: Executing python function do_fetch

| DEBUG: Executing python function base_do_fetch

| DEBUG: Fetcher accessed the network with the command /usr/bin/env svn

--non-interactive --trust-server-cert info --no-auth-cache http://XXX

| DEBUG: Running export SSH_AGENT_PID="3606"; export

SSH_AUTH_SOCK="/tmp/ssh-zEFWxgcc3553/agent.3553"; export http_proxy="";

export HOME="/home/g179256"; LANG=C LC_ALL=C /usr/bin/env svn

--non-interactive --trust-server-cert info --no-auth-cache http://XXX

| DEBUG: Python function base_do_fetch finished

| DEBUG: Python function do_fetch finished

| ERROR: Function failed: Fetcher failure: Fetch command failed with

exit code 1, output:

| svn: E170001: Unable to connect to a repository at URL 'http://XXX'

| svn: E170001: OPTIONS of 'http://XXX': authorization failed: Could not

authenticate to server: ignored Negotiate challenge, rejected Basic

challenge

|

ERROR: Task 0

(/home/g179256/yocto/../meta-layer-third-party/meta-custom/recipes-plc/ti-dcg3-app/ti-dcg3-app_loadNG.bb,

do_fetch) failed with exit code '1'

NOTE: Tasks Summary: Attempted 236 tasks of which 2 didn't need to be

rerun and 1 failed.



Summary: 1 task failed:



/home/g179256/yocto_urd3/../meta-layer-third-party/meta-custom/recipes-plc/ti-dcg3-app/ti-dcg3-app_loadNG.bb,

do_fetch

Summary: There were 32 WARNING messages shown.

Summary: There was 1 ERROR message shown, returning a non-zero exit code.



Why bitbake does not ask me my username and my password ?





Best regards,

---

Laurent J



#

" Ce courriel et les documents qui lui sont joints peuvent contenir des

informations confidentielles ou ayant un caractÃ¨ privÃ©S'ils ne vous sont

pas destinÃ© nous vous signalons qu'il est strictement interdit de les

divulguer, de les reproduire ou d'en utiliser de quelque maniÃ¨ que ce

soit le contenu. Si ce message vous a Ã© transmis par erreur, merci d'en

informer l'expÃ©teur et de supprimer immÃ©atement de votre systÃ¨

informatique ce courriel ainsi que tous les documents qui y sont attachÃ©"





   **



" This e-mail and any attached documents may contain confidential or

proprietary information. If you are not the intended recipient, you are

notified that any dissemination, copying of this e-mail and any attachments

thereto or use of their contents by any means whatsoever is strictly

prohibited. If you have received this e-mail in error, please advise the

sender immediately and delete this e-mail and all attached documents

from your computer system."

#


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
ot

Re: [yocto] bitbake co from SVN with Authentication

2014-04-15 Thread Erik Botö

Another solution might be to set both username and password in the
SRC_URI line, but use variables that can then be provided in e.g.
local.conf

SRC_URI = 
"svn://svn.server.com/svn/project;module=ti;protocol=http;user=${PROJ_SVN_USER};pswd=${PROJ_SVN_PASSWORD}"

and then in local.conf each user set:
PROJ_SVN_USER = "foo"
PROJ_SV_PASSWORD = "topsecret"

The downside is that you'd have the password saved in clear text,
which in some cases is a bad idea. You can of course go the middle way
and just let the username be in local.conf to avoid having to edit the
recipe when using other usernames.

Cheers,
Erik

On Tue, Apr 15, 2014 at 11:24 AM, Sathish Kumar Balasubramaniam -ERS,
HCL Tech  wrote:
> Hi Laurent,
>
>
>
> For SVN, for ex, if the SVN path is http://svn.server.com/svn/project/ti
>
>
>
> the "SRC_URI, SRCREV" should be in the following format
>
>
>
> SRCREV = ""
>
> SRC_URI =
> "svn://svn.server.com/svn/project;module=ti;protocol=http;user="
>
>
>
> But before this execution, login to the above , at least one time
> you need to do svn checkout using the regular command line and when asks to
> save password, give yes to save.
>
>
>
>
>
> Regards,
>
> B.Sathish Kumar
>
>
>
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> On Behalf Of Laurent Joli
> Sent: Tuesday, April 15, 2014 2:32 PM
> To: yocto@yoctoproject.org
> Subject: [yocto] bitbake co from SVN with Authentication
>
>
>
> Hello,
>
>
>
> I am try to checkout some file from a SVN with authentification. But
>
> bitbake say that :
>
>
>
>
>
> ERROR: Function failed: Fetcher failure: Fetch command failed with exit
>
> code 1, output:
>
> svn: E170001: Unable to connect to a repository at URL 'http://XXX'
>
> svn: E170001: OPTIONS of 'http://XXX': authorization failed: Could not
>
> authenticate to server: ignored Negotiate challenge, rejected Basic
>
> challenge
>
>
>
> ERROR: Logfile of failure stored in:
>
> /home/g179256/yocto/XX/armv7a-vfp-neon-poky-linux-gnueabi/ti-dcg3-app/loadNG-r0/temp/log.do_fetch.6211
>
> Log data follows:
>
> | DEBUG: Executing python function do_fetch
>
> | DEBUG: Executing python function base_do_fetch
>
> | DEBUG: Fetcher accessed the network with the command /usr/bin/env svn
>
> --non-interactive --trust-server-cert info --no-auth-cache http://XXX
>
> | DEBUG: Running export SSH_AGENT_PID="3606"; export
>
> SSH_AUTH_SOCK="/tmp/ssh-zEFWxgcc3553/agent.3553"; export http_proxy="";
>
> export HOME="/home/g179256"; LANG=C LC_ALL=C /usr/bin/env svn
>
> --non-interactive --trust-server-cert info --no-auth-cache http://XXX
>
> | DEBUG: Python function base_do_fetch finished
>
> | DEBUG: Python function do_fetch finished
>
> | ERROR: Function failed: Fetcher failure: Fetch command failed with
>
> exit code 1, output:
>
> | svn: E170001: Unable to connect to a repository at URL 'http://XXX'
>
> | svn: E170001: OPTIONS of 'http://XXX': authorization failed: Could not
>
> authenticate to server: ignored Negotiate challenge, rejected Basic
>
> challenge
>
> |
>
> ERROR: Task 0
>
> (/home/g179256/yocto/../meta-layer-third-party/meta-custom/recipes-plc/ti-dcg3-app/ti-dcg3-app_loadNG.bb,
>
> do_fetch) failed with exit code '1'
>
> NOTE: Tasks Summary: Attempted 236 tasks of which 2 didn't need to be
>
> rerun and 1 failed.
>
>
>
> Summary: 1 task failed:
>
>
>
> /home/g179256/yocto_urd3/../meta-layer-third-party/meta-custom/recipes-plc/ti-dcg3-app/ti-dcg3-app_loadNG.bb,
>
> do_fetch
>
> Summary: There were 32 WARNING messages shown.
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
>
>
> Why bitbake does not ask me my username and my password ?
>
>
>
>
>
> Best regards,
>
> ---
>
> Laurent J
>
>
>
> #
>
> " Ce courriel et les documents qui lui sont joints peuvent contenir des
>
> informations confidentielles ou ayant un caractÃ¨ privÃ(c)S'ils ne vous sont
>
> pas destinÃ(c) nous vous signalons qu'il est strictement interdit de les
>
> divulguer, de les reproduire ou d'en utiliser de quelque maniÃ¨ que ce
>
> soit le contenu. Si ce message vous a Ã(c) transmis par erreur, merci d'en
>
> informer l'expÃ(c)teur et de supprimer immÃ(c)atement de votre systÃ¨
>
> informatique ce courriel ainsi que tous les documents qui y sont attachÃ(c)"
>
>
>
>
>
>**
>
>
>
> " This e-mail and any attached documents may contain confidential or
>
> proprietary information. If you are not the intended recipient, you are
>
> notified that any dissemination, copying of this e-mail and any attachments
>
> thereto or use of their contents by any means whatsoever is strictly
>
> prohibited. If you have received this e-mail in error, please advise the
>
> sender immediately and delete this e-mail and all attached documents
>
> from your computer system."
>
> #
>
>
>
> ::DISCLAIMER::
> 
>
> The contents of this e-m

Re: [yocto] bitbake co from SVN with Authentication

2014-04-15 Thread Laurent Joli

OK thanks for all your reply.

@B.Sathish Kumar

I just tested an svn co like that :

svn co 'http://XXX'


 Password for 'user' Authentication realm: 


---
ATTENTION!  Your password for authentication realm:

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/home/user/.subversion/servers'.
---
yes
Store password unencrypted (yes/no)?
---
ATTENTION!  Your password for authentication realm:



can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/home/user/.subversion/servers'.
---
yes
Store password unencrypted (yes/no)? Checked out revision 104.

And after, I do the bitbake command and all is DONE.

Thanks you,

Laurent JOLI

On 04/15/2014 11:39 AM, Erik Botö wrote:
> Another solution might be to set both username and password in the
> SRC_URI line, but use variables that can then be provided in e.g.
> local.conf
>
> SRC_URI = 
> "svn://svn.server.com/svn/project;module=ti;protocol=http;user=${PROJ_SVN_USER};pswd=${PROJ_SVN_PASSWORD}"
>
> and then in local.conf each user set:
> PROJ_SVN_USER = "foo"
> PROJ_SV_PASSWORD = "topsecret"
>
> The downside is that you'd have the password saved in clear text,
> which in some cases is a bad idea. You can of course go the middle way
> and just let the username be in local.conf to avoid having to edit the
> recipe when using other usernames.
>
> Cheers,
> Erik
>
> On Tue, Apr 15, 2014 at 11:24 AM, Sathish Kumar Balasubramaniam -ERS,
> HCL Tech  wrote:
>> Hi Laurent,
>>
>>
>>
>> For SVN, for ex, if the SVN path is http://svn.server.com/svn/project/ti
>>
>>
>>
>> the "SRC_URI, SRCREV" should be in the following format
>>
>>
>>
>> SRCREV = ""
>>
>> SRC_URI =
>> "svn://svn.server.com/svn/project;module=ti;protocol=http;user="
>>
>>
>>
>> But before this execution, login to the above , at least one time
>> you need to do svn checkout using the regular command line and when asks to
>> save password, give yes to save.
>>
>>
>>
>>
>>
>> Regards,
>>
>> B.Sathish Kumar
>>
>>
>>
>> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
>> On Behalf Of Laurent Joli
>> Sent: Tuesday, April 15, 2014 2:32 PM
>> To: yocto@yoctoproject.org
>> Subject: [yocto] bitbake co from SVN with Authentication
>>
>>
>>
>> Hello,
>>
>>
>>
>> I am try to checkout some file from a SVN with authentification. But
>>
>> bitbake say that :
>>
>>
>>
>>
>>
>> ERROR: Function failed: Fetcher failure: Fetch command failed with exit
>>
>> code 1, output:
>>
>> svn: E170001: Unable to connect to a repository at URL 'http://XXX'
>>
>> svn: E170001: OPTIONS of 'http://XXX': authorization failed: Could not
>>
>> authenticate to server: ignored Negotiate challenge, rejected Basic
>>
>> challenge
>>
>>
>>
>> ERROR: Logfile of failure stored in:
>>
>> /home/g179256/yocto/XX/armv7a-vfp-neon-poky-linux-gnueabi/ti-dcg3-app/loadNG-r0/temp/log.do_fetch.6211
>>
>> Log data follows:
>>
>> | DEBUG: Executing python function do_fetch
>>
>> | DEBUG: Executing python function base_do_fetch
>>
>> | DEBUG: Fetcher accessed the network with the command /usr/bin/env svn
>>
>> --non-interactive --trust-server-cert info --no-auth-cache http://XXX
>>
>> | DEBUG: Running export SSH_AGENT_PID="3606"; export
>>
>> SSH_AUTH_SOCK="/tmp/ssh-zEFWxgcc3553/agent.3553"; export http_proxy="";
>>
>> export HOME="/home/g179256"; LANG=C LC_ALL=C /usr/bin/env svn
>>
>> --non-interactive --trust-server-cert info --no-auth-cache http://XXX
>>
>> | DEBUG: Python function base_do_fetch finished
>>
>> | DEBUG: Python function do_fetch finished
>>
>> | ERROR: Function failed: Fetcher failure: Fetch command failed with
>>
>> exit code 1, output:
>>
>> | svn: E170001: Unable to connect to a repository at URL 'http://XXX'
>>
>> | svn: E170001: OPTIONS of 'http://XXX': authorization failed: Could not
>>
>> authenticate to server: ignored Negotiate challenge, rejected Basic
>>
>> challenge
>>
>> |
>>
>> ERROR: Task 0
>>
>> (/home/g179256/yocto/../meta-layer-third-party/meta-custom/recipes-plc/ti-dcg3-app/ti-dcg3-app_loadNG.bb,
>>
>> do_fetch) failed with exit code '1'
>>
>> NOTE: Tasks Summary: Attempted 236 tasks of which 2 didn't need to be
>>
>> rerun and 1 failed.
>>
>>
>>
>> Summary: 1 task failed:
>>
>>
>>
>

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Stanacar, StefanX




On Tue, 2014-04-15 at 09:03 +, Stanacar, StefanX wrote:
> 
> 
> On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > > > Very interesting results!  These are the results from the build 
> > > > > > > > hosts I have:
> > > > > > > >   Fedora 13 (i686) - fails
> > > > > > > >   Fedora 17 (i686) - fails
> > > > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > > > 
> > > > > > > Interesting indeed. I have no idea what's so special about Fedora 
> > > > > > > host - this 
> > > > > > > is the first time I hear about issues with it. I may try 
> > > > > > > experimenting with 
> > > > > > > different VMs once I have more time...
> > > > > > 
> > > > > > I've been having a look at this. The biggest differences I can find
> > > > > > between working and non working builds is the path length to the 
> > > > > > build
> > > > > > directory for the kernel. This is from comparing vmlinux files from
> > > > > > working and non working builds.
> > > > > > 
> > > > > > Works:
> > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > 
> > > > > > Doesn't Work:
> > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > 
> > > > > > I also have been wondering if the version strings may be making a
> > > > > > difference.
> > > > > > 
> > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build 
> > > > > > where I
> > > > > > truncated the path length to a "working" build path length and 
> > > > > > patched
> > > > > > in the same version strings:
> > > > > > 
> > > > > > const char linux_banner[] = 
> > > > > >"Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) 
> > > > > > (gcc
> > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
> > > > > > 
> > > > > > const char linux_proc_banner[] = "%s version %s 
> > > > > > (paul@ubuntu-build01)
> > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > 
> > > > > > to init/version.c.
> > > > > > 
> > > > > > I don't have hardware and would be interested to know if the kernel
> > > > > > linked to above works or not. If it doesn't, it rules out these 
> > > > > > path and
> > > > > > string lengths, if it does work, it points to a problem there.
> > > > > 
> > > > > Richard,
> > > > > 
> > > > > Good catch! It boots:
> > > > 
> > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last one but
> > > > with my changes to version.c reverted. The one should tell us if its the
> > > > paths or the strings.
> > > 
> > > This one also boots for me:
> > > 
> > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 
> > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014
> > > 
> > > 
> > > > I'm guessing the path problem is more likely but anything is possible.
> > > > This is starting to look like some kind of compiler or linker issue. If
> > > > it is that, it would help to have more data points about what works and
> > > > what doesn't. With that in mind could people who have good or bad builds
> > > > please share the paths they built the kernels in so we can see if we can
> > > > spot some kind of pattern.
> > 
> > BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it 
> > works.
> > 
> 
> I can confirm:
>  build dir in /home/stefans/b1  works,
> but /home/stefans/yocto/poky/build doesn't.
> 

But this works 
[stefans@firebird bu]$ pwd
/home/stefans/yocto/poky/bu
[stefans@firebird bu]$ echo `pwd`| wc -c
28


But 29 doesn't.
So, what now?

Cheers,
Stefan

> Cheers,
> Stefan
> 
> > -- 
> > Denys
> 

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

[yocto] [PATCH] weston: Add weston.ini

2014-04-15 Thread Sujith H

From: Sujith H 

Adding weston.ini to $HOME/.config. With this change
user can login to $HOME and launch weston with ivi-shell.

Signed-off-by: Sujith H 
---
 recipes-graphics/wayland/weston_1.4.0.bbappend | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/recipes-graphics/wayland/weston_1.4.0.bbappend 
b/recipes-graphics/wayland/weston_1.4.0.bbappend
index 7a8ba6f..fb48de1 100644
--- a/recipes-graphics/wayland/weston_1.4.0.bbappend
+++ b/recipes-graphics/wayland/weston_1.4.0.bbappend
@@ -12,3 +12,14 @@ PR = "r1"
 
 FILES_${PN} += "${libdir}/weston/*"
 FILES_${PN}-dbg += "${libdir}/weston/.debug/*"
+
+do_install_append() {
+   install -d ${D}/home/root/.config
+   install -m 0644 ${S}/ivi-shell/weston.ini.in 
${D}/home/root/.config/weston.ini
+   sed -i -e  's/hmi-controller.so/hmi-controller.so,ivi-controller.so/' 
${D}/home/root/.config/weston.ini
+   sed -i -e 's|\@libexecdir\@|${libexecdir}|' 
${D}/home/root/.config/weston.ini
+   sed -i -e 's|\@abs_top_builddir\@\/data|${datadir}\/weston|' 
${D}/home/root/.config/weston.ini
+   sed -i -e 's|\@abs_top_builddir\@\/clients|${bindir}|' 
${D}/home/root/.config/weston.ini
+}
+
+FILES_${PN} += "/home/root/.config"
-- 
1.8.4

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

[yocto] [PATCH] weston: Add weston.ini

2014-04-15 Thread Sujith H

Adding weston.ini to $HOME/.config. With this change
user can login to $HOME and launch weston with ivi-shell.

Signed-off-by: Sujith H 
---
 recipes-graphics/wayland/weston_1.4.0.bbappend | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/recipes-graphics/wayland/weston_1.4.0.bbappend 
b/recipes-graphics/wayland/weston_1.4.0.bbappend
index 7a8ba6f..fb48de1 100644
--- a/recipes-graphics/wayland/weston_1.4.0.bbappend
+++ b/recipes-graphics/wayland/weston_1.4.0.bbappend
@@ -12,3 +12,14 @@ PR = "r1"
 
 FILES_${PN} += "${libdir}/weston/*"
 FILES_${PN}-dbg += "${libdir}/weston/.debug/*"
+
+do_install_append() {
+   install -d ${D}/home/root/.config
+   install -m 0644 ${S}/ivi-shell/weston.ini.in 
${D}/home/root/.config/weston.ini
+   sed -i -e  's/hmi-controller.so/hmi-controller.so,ivi-controller.so/' 
${D}/home/root/.config/weston.ini
+   sed -i -e 's|\@libexecdir\@|${libexecdir}|' 
${D}/home/root/.config/weston.ini
+   sed -i -e 's|\@abs_top_builddir\@\/data|${datadir}\/weston|' 
${D}/home/root/.config/weston.ini
+   sed -i -e 's|\@abs_top_builddir\@\/clients|${bindir}|' 
${D}/home/root/.config/weston.ini
+}
+
+FILES_${PN} += "/home/root/.config"
-- 
1.8.4

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

[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, April 15, 2014 8:00 AM US Pacific Time

2014-04-15 Thread Jolley, Stephen K

Agenda:



* Opens collection - 5 min (Stephen)

* Yocto 1.6 status - 5 min (Stephen/team)

  https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.6_Status

  https://wiki.yoctoproject.org/wiki/Yocto_1.6_Features

* SWAT team rotation: Laurentiu -> Nitin

  https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

* Opens - 10 min

* Team Sharing - 10 min

-Original Appointment-

We encourage people attending the meeting to logon the Yocto Project IRC 
chancel during the meeting (optional):



Yocto IRC: http://webchat.freenode.net/?channels=#yocto

IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html

Conference details

Conference name:

Yocto Project Technical Team

Conference date/start time:

Tue Jun 25, 2013 at 11:00 AM Eastern Daylight Time (GMT-0400)

Participants:

30

Duration:

30 minutes

Participant passcode:

42001078

Dial-in number:

1.972.995.

US Toll Free number:

1.877.561.6828

BlackBerry users, click this link to join your conference as a participant:

1.972.995.x42001078#



Depending on where you are dialing from, either your BlackBerry will pause and 
enter the passcode automatically or you will be prompted to click again to dial 
the passcode.


Local and Global Access Numbers



Country

Dial-in number

Australia:

1800 636 843

Czech Republic:

242 430 350

China (Beijing):

>From office dial 8-995 or 8784277
Beijing Out of Office dial 5878 4277

China (Shanghai):

>From office dial 8-995 or 3073322
Shanghai Out of Office dial 2307 3322

China (Shenzen):

>From office dial 8-995 or 6007877
Shenzen Out of Office dial 2600 7877

China (Other Cities):

>From IP phone dial 8-995
Other cities - Non IP phone dial 021-23073322

Denmark:

8060 1400

Finland:

09 41333477

France:

0497 275888

Germany:

08161 803232

Holland:

030 2417490

India:

BSNL subscribers use 1800 425 9996 (Toll Free)
Airtel subscribers use 0008 009 861 212 (Toll Free)
>From TI Campus use 8995
Others use 2509 9555 (Landline within Bangalore) or
80 2509 9555 (Outside Bangalore)

Israel:

09 790 6715

Italy:

039 69061234 (039 is local city code not country code)

Japan:

>From TI Campus use 8 995 
Outside TI use 03 4331 3777

Malaysia:

>From IP phone dial 2643799
>From Kuala Lumpur dial 4264 3799
Outside Kuala Lumpur dial (03)4264 3799

Norway:

2 295 8744

Philippines:

>From Baguio City use 4471177
>From Metro Manila area use 8702477

Singapore:

>From IP phone dial 3894777
Outside TI use 6389 4777

South Korea:

>From IP phone dial 5606998
>From Seoul dial 5606998
Outside Seoul dial (02)5606998

Sweden:

08 58755577

Taiwan:

>From IP phone dial 1363
>From Taipei dial 2241 1363
Outside Taipei dial (02)2241 1363

Turkey:

Landline Only dial 0811 288 0001
then enter 877 633 1123

UK:

01908 355599

US:

972 995  or 1877 561 6828


Recurring conferences

First scheduled conference:

Tue Jun 25, 2013

Recurrence frequency:

Weekly - Every 1 week(s) on Tuesday

Recurrence ends:

End after 52 occurrences


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:  (503) 712-0534
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

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

[yocto] [meta-ivi][PATCH] weston: Add weston.ini

2014-04-15 Thread Sujith H

Adding weston.ini to $HOME/.config. With this change
user can login to $HOME and launch weston with ivi-shell.

Signed-off-by: Sujith H 
---
 recipes-graphics/wayland/weston_1.4.0.bbappend | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/recipes-graphics/wayland/weston_1.4.0.bbappend 
b/recipes-graphics/wayland/weston_1.4.0.bbappend
index 7a8ba6f..fb48de1 100644
--- a/recipes-graphics/wayland/weston_1.4.0.bbappend
+++ b/recipes-graphics/wayland/weston_1.4.0.bbappend
@@ -12,3 +12,14 @@ PR = "r1"
 
 FILES_${PN} += "${libdir}/weston/*"
 FILES_${PN}-dbg += "${libdir}/weston/.debug/*"
+
+do_install_append() {
+   install -d ${D}/home/root/.config
+   install -m 0644 ${S}/ivi-shell/weston.ini.in 
${D}/home/root/.config/weston.ini
+   sed -i -e  's/hmi-controller.so/hmi-controller.so,ivi-controller.so/' 
${D}/home/root/.config/weston.ini
+   sed -i -e 's|\@libexecdir\@|${libexecdir}|' 
${D}/home/root/.config/weston.ini
+   sed -i -e 's|\@abs_top_builddir\@\/data|${datadir}\/weston|' 
${D}/home/root/.config/weston.ini
+   sed -i -e 's|\@abs_top_builddir\@\/clients|${bindir}|' 
${D}/home/root/.config/weston.ini
+}
+
+FILES_${PN} += "/home/root/.config"
-- 
1.8.4

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

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Gary Thomas

On 2014-04-15 03:03, Stanacar, StefanX wrote:
> 
> 
> 
> On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
>> On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
>>> On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
 On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
>> On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
>>> On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
 Very interesting results!  These are the results from the build hosts 
 I have:
   Fedora 13 (i686) - fails
   Fedora 17 (i686) - fails
   Ubuntu 12.04 (x86_64) - boots
>>>
>>> Interesting indeed. I have no idea what's so special about Fedora host 
>>> - this 
>>> is the first time I hear about issues with it. I may try experimenting 
>>> with 
>>> different VMs once I have more time...
>>
>> I've been having a look at this. The biggest differences I can find
>> between working and non working builds is the path length to the build
>> directory for the kernel. This is from comparing vmlinux files from
>> working and non working builds.
>>
>> Works:
>> /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
>>
>> Doesn't Work:
>> /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
>>
>> I also have been wondering if the version strings may be making a
>> difference.
>>
>> http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
>> truncated the path length to a "working" build path length and patched
>> in the same version strings:
>>
>> const char linux_banner[] = 
>>"Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
>> version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
>>
>> const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
>> (gcc version 4.8.2 (GCC) ) %s\n";
>>
>> to init/version.c.
>>
>> I don't have hardware and would be interested to know if the kernel
>> linked to above works or not. If it doesn't, it rules out these path and
>> string lengths, if it does work, it points to a problem there.
>
> Richard,
>
> Good catch! It boots:

 Thanks Denys, this helps narrow down the issue. I've shared
 http://dan.rpsys.net/uImage-rp3 which is the same as the last one but
 with my changes to version.c reverted. The one should tell us if its the
 paths or the strings.
>>>
>>> This one also boots for me:
>>>
>>> Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 (GCC) 
>>> ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014
>>>
>>>
 I'm guessing the path problem is more likely but anything is possible.
 This is starting to look like some kind of compiler or linker issue. If
 it is that, it would help to have more data points about what works and
 what doesn't. With that in mind could people who have good or bad builds
 please share the paths they built the kernels in so we can see if we can
 spot some kind of pattern.
>>
>> BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it 
>> works.
>>
> 
> I can confirm:
>  build dir in /home/stefans/b1  works,
> but /home/stefans/yocto/poky/build doesn't.

My paths:
  /local/bbb_yocto_2014-04-14 - works
  /home/local/bbb_yocto_2014-04-14 - fails
  /raid/work/tmp/bbb_yocto_2014-04-14 - fails
  /tmp/bbb_yocto_2014-04-15 - works
  /tmp/work/bbb_yocto_2014-04-15 - fails
  /tmp/w2/bbb_yocto_2014-04-15 - fails
  /tmp/w/bbb_yocto_2014-04-15 - works
Note: the last 5 were all built on the same host

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[linux-yocto] Regarding clarifications for adding support of I2C, SPI slave devices on x86 through ACPI

2014-04-15 Thread Sathish Kumar Balasubramaniam -ERS, HCL Tech

Hi,

For Intel, I can understand that the community is advising to implement the 
I2C, SPI slave devices info like base address, IRQs, etc through ACPI mechanism 
rather than using Board files and FDT

I read the following
https://www.kernel.org/doc/Documentation/acpi/enumeration.txt
https://events.linuxfoundation.org/images/stories/slides/lfcs2013_wysocki.pdf

In Linux Kernel 3.8 we are trying to add support for (I2C, SPI) slave devices 
like video output decoder, video input decoder, etc which are behind the bus 
controllers

For ex, for adding support of ADV7180 through I2C

I have the following clarifications

1. Do we need any modification in the BIOS for adding support of I2C, SPI slave 
devices to Linux using ACPI ?
2. Do we need to add the CONFIG_ACPI code (described in "I2C serial bus 
support" section of acpi/enumeration.txt) to the drivers/media/i2c/adv7180.c 
file ?
3. Where we need to add the device info like I2C bus number, I2C slave address, 
IRQ ?
4. Do we need to add any additional code in the chip driver specifically for 
this ACPI support ?
5. We have an Intel reference board. The source code provided by Intel itself 
used certain board files to add support for SPI slave devices, Clock setup, 
Init, etc. Why it has been done without using ACPI ? Is it due to any 
restriction ?


Thanks,
B.Sathish Kumar


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.


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

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Gary Thomas

On 2014-04-15 05:52, Stanacar, StefanX wrote:
> 
> 
> 
> On Tue, 2014-04-15 at 09:03 +, Stanacar, StefanX wrote:
>>
>>
>> On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
>>> On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
 On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
>> On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
>>> On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
 On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> Very interesting results!  These are the results from the build hosts 
> I have:
>   Fedora 13 (i686) - fails
>   Fedora 17 (i686) - fails
>   Ubuntu 12.04 (x86_64) - boots

 Interesting indeed. I have no idea what's so special about Fedora host 
 - this 
 is the first time I hear about issues with it. I may try experimenting 
 with 
 different VMs once I have more time...
>>>
>>> I've been having a look at this. The biggest differences I can find
>>> between working and non working builds is the path length to the build
>>> directory for the kernel. This is from comparing vmlinux files from
>>> working and non working builds.
>>>
>>> Works:
>>> /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
>>>
>>> Doesn't Work:
>>> /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
>>>
>>> I also have been wondering if the version strings may be making a
>>> difference.
>>>
>>> http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
>>> truncated the path length to a "working" build path length and patched
>>> in the same version strings:
>>>
>>> const char linux_banner[] = 
>>>"Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
>>> version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
>>>
>>> const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
>>> (gcc version 4.8.2 (GCC) ) %s\n";
>>>
>>> to init/version.c.
>>>
>>> I don't have hardware and would be interested to know if the kernel
>>> linked to above works or not. If it doesn't, it rules out these path and
>>> string lengths, if it does work, it points to a problem there.
>>
>> Richard,
>>
>> Good catch! It boots:
>
> Thanks Denys, this helps narrow down the issue. I've shared
> http://dan.rpsys.net/uImage-rp3 which is the same as the last one but
> with my changes to version.c reverted. The one should tell us if its the
> paths or the strings.

 This one also boots for me:

 Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 (GCC) 
 ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014


> I'm guessing the path problem is more likely but anything is possible.
> This is starting to look like some kind of compiler or linker issue. If
> it is that, it would help to have more data points about what works and
> what doesn't. With that in mind could people who have good or bad builds
> please share the paths they built the kernels in so we can see if we can
> spot some kind of pattern.
>>>
>>> BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it 
>>> works.
>>>
>>
>> I can confirm:
>>  build dir in /home/stefans/b1  works,
>> but /home/stefans/yocto/poky/build doesn't.
>>
> 
> But this works 
> [stefans@firebird bu]$ pwd
> /home/stefans/yocto/poky/bu
> [stefans@firebird bu]$ echo `pwd`| wc -c
> 28
> 
> 
> But 29 doesn't.
> So, what now?

Hard to know, it might take debugging via JTAG to find out what's
happening since when it fails, it's so dead that nothing makes it
to the [dmesg] log buffer :-(

Sadly, I can't help much with this as I don't have a JTAG debug
setup for the BBB.

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Paul Eggleton

On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> On Tue, 2014-04-15 at 09:03 +, Stanacar, StefanX wrote:
> > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > > > > Very interesting results!  These are the results from the 
build hosts I have:
> > > > > > > > >   Fedora 13 (i686) - fails
> > > > > > > > >   Fedora 17 (i686) - fails
> > > > > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > > > > 
> > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > Fedora host - this is the first time I hear about issues with
> > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > more time...
> > > > > > > 
> > > > > > > I've been having a look at this. The biggest differences I can
> > > > > > > find
> > > > > > > between working and non working builds is the path length to the
> > > > > > > build
> > > > > > > directory for the kernel. This is from comparing vmlinux files
> > > > > > > from
> > > > > > > working and non working builds.
> > > > > > > 
> > > > > > > Works:
> > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > 
> > > > > > > Doesn't Work:
> > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gn
> > > > > > > ueabi
> > > > > > > 
> > > > > > > I also have been wondering if the version strings may be making
> > > > > > > a
> > > > > > > difference.
> > > > > > > 
> > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build
> > > > > > > where I
> > > > > > > truncated the path length to a "working" build path length and
> > > > > > > patched
> > > > > > > in the same version strings:
> > > > > > > 
> > > > > > > const char linux_banner[] =
> > > > > > > 
> > > > > > >"Linux version 3.14.0-yocto-standard
> > > > > > >(paul@ubuntu-build01) (gcc
> > > > > > > 
> > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > 2014\n";
> > > > > > > 
> > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > (paul@ubuntu-build01)
> > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > 
> > > > > > > to init/version.c.
> > > > > > > 
> > > > > > > I don't have hardware and would be interested to know if the
> > > > > > > kernel
> > > > > > > linked to above works or not. If it doesn't, it rules out these
> > > > > > > path and
> > > > > > > string lengths, if it does work, it points to a problem there.
> > > > > > 
> > > > > > Richard,
> > > > > 
> > > > > > Good catch! It boots:
> > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last one
> > > > > but
> > > > > with my changes to version.c reverted. The one should tell us if its
> > > > > the
> > > > > paths or the strings.
> > > > 
> > > > This one also boots for me:
> > > > 
> > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2
> > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > > 
> > > > > I'm guessing the path problem is more likely but anything is
> > > > > possible.
> > > > > This is starting to look like some kind of compiler or linker issue.
> > > > > If
> > > > > it is that, it would help to have more data points about what works
> > > > > and
> > > > > what doesn't. With that in mind could people who have good or bad
> > > > > builds
> > > > > please share the paths they built the kernels in so we can see if we
> > > > > can
> > > > > spot some kind of pattern.
> > > 
> > > BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and
> > > it works.
> > 
> > I can confirm:
> >  build dir in /home/stefans/b1  works,
> > 
> > but /home/stefans/yocto/poky/build doesn't.
> 
> But this works
> [stefans@firebird bu]$ pwd
> /home/stefans/yocto/poky/bu
> [stefans@firebird bu]$ echo `pwd`| wc -c
> 28
> 
> 
> But 29 doesn't.
> So, what now?

Some other things I tried with a "long" TMPDIR path (note that it's the TMPDIR 
path that makes the difference - in my tests I've been using 
/home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:

* kernel built with gcc 4.7.2 and binutils 2.23.2
* u-boot built with gcc 4.7.2 and binutils 2.23.2
* u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
* earlyprintk and CONFIG_DEBUG_LL - no additional output printed

I think we're now at the point where we'd benefit from someone with better 
knowledge debugging the issue.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
_

Re: [yocto] [PATCH] weston: Add weston.ini

2014-04-15 Thread Chris Larson

On Tue, Apr 15, 2014 at 5:45 AM, Sujith H  wrote:

> From: Sujith H 
>
> Adding weston.ini to $HOME/.config. With this change
> user can login to $HOME and launch weston with ivi-shell.
>
> Signed-off-by: Sujith H 
>

1) the package manager shouldn't install user files, unless absolutely
necessary, and if you're going to do something like that, you should at
least split it out into a separate package, IMO
2) you hardcode /home/root rather than using the variable for root's home
directory (see bitbake.conf)
3) you don't actually mention what layer this patch is destined for. I'm
guessing meta-yocto?
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] Regarding clarifications for adding support of I2C, SPI slave devices on x86 through ACPI

2014-04-15 Thread Ong, Boon Leong

CC'ed Rebecca & Chia Ee for their response/attention. 

Short answer, we have both ACPI and PCI enumeration support for those low power 
IO like I2C, SPI, HS-UART. 
You can refer to 
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/tree/meta/cfg/kernel-cache/features/valleyisland-io?h=meta
 for v3.8.

For your knowledge, we are in the midst of making support for v3.10 too and we 
prefer that your long term goal is to converge into Linux LTS/LTSI. But, it is 
fine to try out v3.8 and eventually move to v3.10.   


From: linux-yocto-boun...@yoctoproject.org 
[mailto:linux-yocto-boun...@yoctoproject.org] On Behalf Of Sathish Kumar 
Balasubramaniam -ERS, HCL Tech
Sent: Tuesday, April 15, 2014 10:41 PM
To: linux-yo...@yoctoproject.org; Darren Hart (dvh...@linux.intel.com)
Subject: [linux-yocto] Regarding clarifications for adding support of I2C, SPI 
slave devices on x86 through ACPI
Importance: High

Hi,

For Intel, I can understand that the community is advising to implement the 
I2C, SPI slave devices info like base address, IRQs, etc through ACPI mechanism 
rather than using Board files and FDT

I read the following 
https://www.kernel.org/doc/Documentation/acpi/enumeration.txt
https://events.linuxfoundation.org/images/stories/slides/lfcs2013_wysocki.pdf

In Linux Kernel 3.8 we are trying to add support for (I2C, SPI) slave devices 
like video output decoder, video input decoder, etc which are behind the bus 
controllers

For ex, for adding support of ADV7180 through I2C

I have the following clarifications

1. Do we need any modification in the BIOS for adding support of I2C, SPI slave 
devices to Linux using ACPI ?
2. Do we need to add the CONFIG_ACPI code (described in "I2C serial bus 
support" section of acpi/enumeration.txt) to the drivers/media/i2c/adv7180.c 
file ?
3. Where we need to add the device info like I2C bus number, I2C slave address, 
IRQ ?
4. Do we need to add any additional code in the chip driver specifically for 
this ACPI support ?
5. We have an Intel reference board. The source code provided by Intel itself 
used certain board files to add support for SPI slave devices, Clock setup, 
Init, etc. Why it has been done without using ACPI ? Is it due to any 
restriction ?


Thanks,
B.Sathish Kumar


::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted, 
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents 
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates. 
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the 
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of 
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately. 
Before opening any email and/or attachments, please check them for viruses and 
other defects.

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

[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, April 15, 2014 8:00 AM US Pacific Time

2014-04-15 Thread Jolley, Stephen K

Attendees:  Stephen, Armin, Scott R., Paul, Belen, Christiana, Vali, Jeff, 
Michael H, Matthew, Michael B, Sean,



* Opens collection - 5 min (Stephen)



* Yocto 1.6 status - 5 min (Stephen/team)

  https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.6_Status

  https://wiki.yoctoproject.org/wiki/Yocto_1.6_Features



* SWAT team rotation: Laurentiu -> Nitin

  https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team



* Opens - 10 min



* Team Sharing - 10 min

Scott - 4/22 will be the last day for documentation changes for 1.6 and not 
more changes will be made until we start work on 1.7.  If you have changes you 
would like see included they should get them to Scott ASAP!

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:  (503) 712-0534
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

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

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Stoicescu, CorneliuX

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Paul Eggleton
> Sent: Tuesday, April 15, 2014 5:50 PM
> To: yocto@yoctoproject.org
> Subject: Re: [yocto] BBB doesn't boot
> 
> On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > On Tue, 2014-04-15 at 09:03 +, Stanacar, StefanX wrote:
> > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas
> wrote:
> > > > > > > > > > Very interesting results!  These are the results from
> > > > > > > > > > the
> build hosts I have:
> > > > > > > > > >   Fedora 13 (i686) - fails
> > > > > > > > > >   Fedora 17 (i686) - fails
> > > > > > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > > > > >
> > > > > > > > > Interesting indeed. I have no idea what's so special
> > > > > > > > > about Fedora host - this is the first time I hear about
> > > > > > > > > issues with it. I may try experimenting with different
> > > > > > > > > VMs once I have more time...
> > > > > > > >
> > > > > > > > I've been having a look at this. The biggest differences I
> > > > > > > > can find between working and non working builds is the
> > > > > > > > path length to the build directory for the kernel. This is
> > > > > > > > from comparing vmlinux files from working and non working
> > > > > > > > builds.
> > > > > > > >
> > > > > > > > Works:
> > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-
> gnuea
> > > > > > > > bi
> > > > > > > >
> > > > > > > > Doesn't Work:
> > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-li
> > > > > > > > nux-gn
> > > > > > > > ueabi
> > > > > > > >
> > > > > > > > I also have been wondering if the version strings may be
> > > > > > > > making a difference.
> > > > > > > >
> > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken
> > > > > > > > build where I truncated the path length to a "working"
> > > > > > > > build path length and patched in the same version strings:
> > > > > > > >
> > > > > > > > const char linux_banner[] =
> > > > > > > >
> > > > > > > >"Linux version 3.14.0-yocto-standard
> > > > > > > >(paul@ubuntu-build01) (gcc
> > > > > > > >
> > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > 2014\n";
> > > > > > > >
> > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > (paul@ubuntu-build01)
> > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > >
> > > > > > > > to init/version.c.
> > > > > > > >
> > > > > > > > I don't have hardware and would be interested to know if
> > > > > > > > the kernel linked to above works or not. If it doesn't, it
> > > > > > > > rules out these path and string lengths, if it does work,
> > > > > > > > it points to a problem there.
> > > > > > >
> > > > > > > Richard,
> > > > > >
> > > > > > > Good catch! It boots:
> > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last
> > > > > > one but with my changes to version.c reverted. The one should
> > > > > > tell us if its the paths or the strings.
> > > > >
> > > > > This one also boots for me:
> > > > >
> > > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version
> > > > > 4.8.2
> > > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > >
> > > > > > I'm guessing the path problem is more likely but anything is
> > > > > > possible.
> > > > > > This is starting to look like some kind of compiler or linker issue.
> > > > > > If
> > > > > > it is that, it would help to have more data points about what
> > > > > > works and what doesn't. With that in mind could people who
> > > > > > have good or bad builds please share the paths they built the
> > > > > > kernels in so we can see if we can spot some kind of pattern.
> > > >
> > > > BTW, my path is
> > > > /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it
> works.
> > >
> > > I can confirm:
> > >  build dir in /home/stefans/b1  works,
> > >
> > > but /home/stefans/yocto/poky/build doesn't.
> >
> > But this works
> > [stefans@firebird bu]$ pwd
> > /home/stefans/yocto/poky/bu
> > [stefans@firebird bu]$ echo `pwd`| wc -c
> > 28
> >
> >
> > But 29 doesn't.
> > So, what now?
> 
> Some other things I tried with a "long" TMPDIR path (note that it's the
> TMPDIR path that makes the difference - in my tests I've been using
> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> 
> * kernel built with gcc 4.7.2 and binutils 2.23.2
> * u

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Gary Thomas

On 2014-04-15 09:15, Stoicescu, CorneliuX wrote:
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org [mailto:yocto-
>> boun...@yoctoproject.org] On Behalf Of Paul Eggleton
>> Sent: Tuesday, April 15, 2014 5:50 PM
>> To: yocto@yoctoproject.org
>> Subject: Re: [yocto] BBB doesn't boot
>>
>> On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
>>> On Tue, 2014-04-15 at 09:03 +, Stanacar, StefanX wrote:
 On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
>> On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
>>> On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
 On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
>> On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas
>> wrote:
>>> Very interesting results!  These are the results from
>>> the
>> build hosts I have:
>>>   Fedora 13 (i686) - fails
>>>   Fedora 17 (i686) - fails
>>>   Ubuntu 12.04 (x86_64) - boots
>>
>> Interesting indeed. I have no idea what's so special
>> about Fedora host - this is the first time I hear about
>> issues with it. I may try experimenting with different
>> VMs once I have more time...
>
> I've been having a look at this. The biggest differences I
> can find between working and non working builds is the
> path length to the build directory for the kernel. This is
> from comparing vmlinux files from working and non working
> builds.
>
> Works:
> /home/paul/poky/build/tmp/work/beaglebone-poky-linux-
>> gnuea
> bi
>
> Doesn't Work:
> /media/data1/build1/poky/build/tmp/work/beaglebone-poky-li
> nux-gn
> ueabi
>
> I also have been wondering if the version strings may be
> making a difference.
>
> http://dan.rpsys.net/uImage-rp2 is a uImage from a broken
> build where I truncated the path length to a "working"
> build path length and patched in the same version strings:
>
> const char linux_banner[] =
>
>"Linux version 3.14.0-yocto-standard
>(paul@ubuntu-build01) (gcc
>
> version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> 2014\n";
>
> const char linux_proc_banner[] = "%s version %s
> (paul@ubuntu-build01)
> (gcc version 4.8.2 (GCC) ) %s\n";
>
> to init/version.c.
>
> I don't have hardware and would be interested to know if
> the kernel linked to above works or not. If it doesn't, it
> rules out these path and string lengths, if it does work,
> it points to a problem there.

 Richard,
>>>
 Good catch! It boots:
>>> Thanks Denys, this helps narrow down the issue. I've shared
>>> http://dan.rpsys.net/uImage-rp3 which is the same as the last
>>> one but with my changes to version.c reverted. The one should
>>> tell us if its the paths or the strings.
>>
>> This one also boots for me:
>>
>> Linux version 3.14.0-yocto-standard (richard@ted) (gcc version
>> 4.8.2
>> (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > >
>>> I'm guessing the path problem is more likely but anything is
>>> possible.
>>> This is starting to look like some kind of compiler or linker issue.
>>> If
>>> it is that, it would help to have more data points about what
>>> works and what doesn't. With that in mind could people who
>>> have good or bad builds please share the paths they built the
>>> kernels in so we can see if we can spot some kind of pattern.
>
> BTW, my path is
> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it
>> works.

 I can confirm:
  build dir in /home/stefans/b1  works,

 but /home/stefans/yocto/poky/build doesn't.
>>>
>>> But this works
>>> [stefans@firebird bu]$ pwd
>>> /home/stefans/yocto/poky/bu
>>> [stefans@firebird bu]$ echo `pwd`| wc -c
>>> 28
>>>
>>>
>>> But 29 doesn't.
>>> So, what now?
>>
>> Some other things I tried with a "long" TMPDIR path (note that it's the
>> TMPDIR path that makes the difference - in my tests I've been using
>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
>>
>> * kernel built with gcc 4.7.2 and binutils 2.23.2
>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
>> * u-boot from http://downloads.angstrom-
>> distribution.org/demo/beaglebone/
>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
>>
>> I think we're now at the point where we'd benefit from someone with better
>> knowledge debugging the issue.
>>
>> Cheers,
>> Paul
>>
> 
> I don't know if this is helpful but thi

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Denys Dmytriyenko

On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > On Tue, 2014-04-15 at 09:03 +, Stanacar, StefanX wrote:
> > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > > > > > Very interesting results!  These are the results from the 
> build hosts I have:
> > > > > > > > > >   Fedora 13 (i686) - fails
> > > > > > > > > >   Fedora 17 (i686) - fails
> > > > > > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > > > > > 
> > > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > > Fedora host - this is the first time I hear about issues with
> > > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > > more time...
> > > > > > > > 
> > > > > > > > I've been having a look at this. The biggest differences I can
> > > > > > > > find
> > > > > > > > between working and non working builds is the path length to the
> > > > > > > > build
> > > > > > > > directory for the kernel. This is from comparing vmlinux files
> > > > > > > > from
> > > > > > > > working and non working builds.
> > > > > > > > 
> > > > > > > > Works:
> > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > > 
> > > > > > > > Doesn't Work:
> > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gn
> > > > > > > > ueabi
> > > > > > > > 
> > > > > > > > I also have been wondering if the version strings may be making
> > > > > > > > a
> > > > > > > > difference.
> > > > > > > > 
> > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build
> > > > > > > > where I
> > > > > > > > truncated the path length to a "working" build path length and
> > > > > > > > patched
> > > > > > > > in the same version strings:
> > > > > > > > 
> > > > > > > > const char linux_banner[] =
> > > > > > > > 
> > > > > > > >"Linux version 3.14.0-yocto-standard
> > > > > > > >(paul@ubuntu-build01) (gcc
> > > > > > > > 
> > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > 2014\n";
> > > > > > > > 
> > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > (paul@ubuntu-build01)
> > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > > 
> > > > > > > > to init/version.c.
> > > > > > > > 
> > > > > > > > I don't have hardware and would be interested to know if the
> > > > > > > > kernel
> > > > > > > > linked to above works or not. If it doesn't, it rules out these
> > > > > > > > path and
> > > > > > > > string lengths, if it does work, it points to a problem there.
> > > > > > > 
> > > > > > > Richard,
> > > > > > 
> > > > > > > Good catch! It boots:
> > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last one
> > > > > > but
> > > > > > with my changes to version.c reverted. The one should tell us if its
> > > > > > the
> > > > > > paths or the strings.
> > > > > 
> > > > > This one also boots for me:
> > > > > 
> > > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2
> > > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > > 
> > > > > > I'm guessing the path problem is more likely but anything is
> > > > > > possible.
> > > > > > This is starting to look like some kind of compiler or linker issue.
> > > > > > If
> > > > > > it is that, it would help to have more data points about what works
> > > > > > and
> > > > > > what doesn't. With that in mind could people who have good or bad
> > > > > > builds
> > > > > > please share the paths they built the kernels in so we can see if we
> > > > > > can
> > > > > > spot some kind of pattern.
> > > > 
> > > > BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and
> > > > it works.
> > > 
> > > I can confirm:
> > >  build dir in /home/stefans/b1  works,
> > > 
> > > but /home/stefans/yocto/poky/build doesn't.
> > 
> > But this works
> > [stefans@firebird bu]$ pwd
> > /home/stefans/yocto/poky/bu
> > [stefans@firebird bu]$ echo `pwd`| wc -c
> > 28
> > 
> > 
> > But 29 doesn't.
> > So, what now?
> 
> Some other things I tried with a "long" TMPDIR path (note that it's the 
> TMPDIR 
> path that makes the difference - in my tests I've been using 
> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> 
> * kernel built with gcc 4.7.2 and binutils 2.23.2
> * u-boot built with gcc 4.7.2 and binutils 2.23.2
> * u-boot from http://dow

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Paul Eggleton

On Tuesday 15 April 2014 12:26:39 Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> > On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > > On Tue, 2014-04-15 at 09:03 +, Stanacar, StefanX wrote:
> > > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie 
wrote:
> > > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas 
wrote:
> > > > > > > > > > > Very interesting results!  These are the results from
> > > > > > > > > > > the
> > 
> > build hosts I have:
> > > > > > > > > > >   Fedora 13 (i686) - fails
> > > > > > > > > > >   Fedora 17 (i686) - fails
> > > > > > > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > > > > > > 
> > > > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > > > Fedora host - this is the first time I hear about issues
> > > > > > > > > > with
> > > > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > > > more time...
> > > > > > > > > 
> > > > > > > > > I've been having a look at this. The biggest differences I
> > > > > > > > > can
> > > > > > > > > find
> > > > > > > > > between working and non working builds is the path length to
> > > > > > > > > the
> > > > > > > > > build
> > > > > > > > > directory for the kernel. This is from comparing vmlinux
> > > > > > > > > files
> > > > > > > > > from
> > > > > > > > > working and non working builds.
> > > > > > > > > 
> > > > > > > > > Works:
> > > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > > > 
> > > > > > > > > Doesn't Work:
> > > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linu
> > > > > > > > > x-gn
> > > > > > > > > ueabi
> > > > > > > > > 
> > > > > > > > > I also have been wondering if the version strings may be
> > > > > > > > > making
> > > > > > > > > a
> > > > > > > > > difference.
> > > > > > > > > 
> > > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken
> > > > > > > > > build
> > > > > > > > > where I
> > > > > > > > > truncated the path length to a "working" build path length
> > > > > > > > > and
> > > > > > > > > patched
> > > > > > > > > in the same version strings:
> > > > > > > > > 
> > > > > > > > > const char linux_banner[] =
> > > > > > > > > 
> > > > > > > > >"Linux version 3.14.0-yocto-standard
> > > > > > > > >(paul@ubuntu-build01) (gcc
> > > > > > > > > 
> > > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > > 2014\n";
> > > > > > > > > 
> > > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > > (paul@ubuntu-build01)
> > > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > > > 
> > > > > > > > > to init/version.c.
> > > > > > > > > 
> > > > > > > > > I don't have hardware and would be interested to know if the
> > > > > > > > > kernel
> > > > > > > > > linked to above works or not. If it doesn't, it rules out
> > > > > > > > > these
> > > > > > > > > path and
> > > > > > > > > string lengths, if it does work, it points to a problem
> > > > > > > > > there.
> > > > > > > > 
> > > > > > > > Richard,
> > > > > > > 
> > > > > > > > Good catch! It boots:
> > > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last
> > > > > > > one
> > > > > > > but
> > > > > > > with my changes to version.c reverted. The one should tell us if
> > > > > > > its
> > > > > > > the
> > > > > > > paths or the strings.
> > > > > > 
> > > > > > This one also boots for me:
> > > > > > 
> > > > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version
> > > > > > 4.8.2
> > > > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > >
> > > > > > 
> > > > > > > I'm guessing the path problem is more likely but anything is
> > > > > > > possible.
> > > > > > > This is starting to look like some kind of compiler or linker
> > > > > > > issue.
> > > > > > > If
> > > > > > > it is that, it would help to have more data points about what
> > > > > > > works
> > > > > > > and
> > > > > > > what doesn't. With that in mind could people who have good or
> > > > > > > bad
> > > > > > > builds
> > > > > > > please share the paths they built the kernels in so we can see
> > > > > > > if we
> > > > > > > can
> > > > > > > spot some kind of pattern.
> > > > > 
> > > > > BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > and
> > > > > it works.
> > > > 
> > > > I can confirm:
> > > >  build dir in /home/stefans/b1  works,
> > > > 
> > > > bu

[yocto] [not-for-merge][PATCH 2/2] beaglebone: switch default kernel format to zImage

2014-04-15 Thread Denys Dmytriyenko

From: Denys Dmytriyenko 

Requires U-boot 2013.10+

Signed-off-by: Denys Dmytriyenko 
---
 meta-yocto-bsp/conf/machine/beaglebone.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
b/meta-yocto-bsp/conf/machine/beaglebone.conf
index 4263715..7ce2563 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
@@ -24,7 +24,7 @@ SERIAL_CONSOLE = "115200 ttyO0"
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 PREFERRED_VERSION_linux-yocto ?= "3.14%"
 
-KERNEL_IMAGETYPE = "uImage"
+KERNEL_IMAGETYPE = "zImage"
 KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
 KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
 
-- 
1.9.2

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

[yocto] [not-for-merge][PATCH 1/2] u-boot: update to 2014.01

2014-04-15 Thread Denys Dmytriyenko

From: Denys Dmytriyenko 

Signed-off-by: Denys Dmytriyenko 
---
 meta/recipes-bsp/u-boot/u-boot_2014.01.bb | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/recipes-bsp/u-boot/u-boot_2014.01.bb

diff --git a/meta/recipes-bsp/u-boot/u-boot_2014.01.bb 
b/meta/recipes-bsp/u-boot/u-boot_2014.01.bb
new file mode 100644
index 000..5c522ec
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/u-boot_2014.01.bb
@@ -0,0 +1,22 @@
+require u-boot.inc
+
+# To build u-boot for your machine, provide the following lines in your machine
+# config, replacing the assignments as appropriate for your machine.
+# UBOOT_MACHINE = "omap3_beagle_config"
+# UBOOT_ENTRYPOINT = "0x80008000"
+# UBOOT_LOADADDRESS = "0x80008000"
+
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = 
"file://Licenses/README;md5=025bf9f768cbcb1a165dbe1a110babfb"
+
+# This revision corresponds to the tag "v2014.01"
+# We use the revision in order to avoid having to fetch it from the repo 
during parse
+SRCREV = "b44bd2c73c4cfb6e3b9e7f8cf987e8e39aa74a0b"
+
+PV = "v2014.01+git${SRCPV}"
+
+SRC_URI = "git://git.denx.de/u-boot.git;branch=master"
+
+S = "${WORKDIR}/git"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
-- 
1.9.2

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

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Denys Dmytriyenko

On Tue, Apr 15, 2014 at 05:36:10PM +0100, Paul Eggleton wrote:
> On Tuesday 15 April 2014 12:26:39 Denys Dmytriyenko wrote:
> > On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> > > On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > > > On Tue, 2014-04-15 at 09:03 +, Stanacar, StefanX wrote:
> > > > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie 
> wrote:
> > > > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas 
> wrote:
> > > > > > > > > > > > Very interesting results!  These are the results from
> > > > > > > > > > > > the
> > > 
> > > build hosts I have:
> > > > > > > > > > > >   Fedora 13 (i686) - fails
> > > > > > > > > > > >   Fedora 17 (i686) - fails
> > > > > > > > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > > > > > > > 
> > > > > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > > > > Fedora host - this is the first time I hear about issues
> > > > > > > > > > > with
> > > > > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > > > > more time...
> > > > > > > > > > 
> > > > > > > > > > I've been having a look at this. The biggest differences I
> > > > > > > > > > can
> > > > > > > > > > find
> > > > > > > > > > between working and non working builds is the path length to
> > > > > > > > > > the
> > > > > > > > > > build
> > > > > > > > > > directory for the kernel. This is from comparing vmlinux
> > > > > > > > > > files
> > > > > > > > > > from
> > > > > > > > > > working and non working builds.
> > > > > > > > > > 
> > > > > > > > > > Works:
> > > > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > > > > 
> > > > > > > > > > Doesn't Work:
> > > > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linu
> > > > > > > > > > x-gn
> > > > > > > > > > ueabi
> > > > > > > > > > 
> > > > > > > > > > I also have been wondering if the version strings may be
> > > > > > > > > > making
> > > > > > > > > > a
> > > > > > > > > > difference.
> > > > > > > > > > 
> > > > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken
> > > > > > > > > > build
> > > > > > > > > > where I
> > > > > > > > > > truncated the path length to a "working" build path length
> > > > > > > > > > and
> > > > > > > > > > patched
> > > > > > > > > > in the same version strings:
> > > > > > > > > > 
> > > > > > > > > > const char linux_banner[] =
> > > > > > > > > > 
> > > > > > > > > >"Linux version 3.14.0-yocto-standard
> > > > > > > > > >(paul@ubuntu-build01) (gcc
> > > > > > > > > > 
> > > > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > > > 2014\n";
> > > > > > > > > > 
> > > > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > > > (paul@ubuntu-build01)
> > > > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > > > > 
> > > > > > > > > > to init/version.c.
> > > > > > > > > > 
> > > > > > > > > > I don't have hardware and would be interested to know if the
> > > > > > > > > > kernel
> > > > > > > > > > linked to above works or not. If it doesn't, it rules out
> > > > > > > > > > these
> > > > > > > > > > path and
> > > > > > > > > > string lengths, if it does work, it points to a problem
> > > > > > > > > > there.
> > > > > > > > > 
> > > > > > > > > Richard,
> > > > > > > > 
> > > > > > > > > Good catch! It boots:
> > > > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last
> > > > > > > > one
> > > > > > > > but
> > > > > > > > with my changes to version.c reverted. The one should tell us if
> > > > > > > > its
> > > > > > > > the
> > > > > > > > paths or the strings.
> > > > > > > 
> > > > > > > This one also boots for me:
> > > > > > > 
> > > > > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version
> > > > > > > 4.8.2
> > > > > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > >
> > > > > > > 
> > > > > > > > I'm guessing the path problem is more likely but anything is
> > > > > > > > possible.
> > > > > > > > This is starting to look like some kind of compiler or linker
> > > > > > > > issue.
> > > > > > > > If
> > > > > > > > it is that, it would help to have more data points about what
> > > > > > > > works
> > > > > > > > and
> > > > > > > > what doesn't. With that in mind could people who have good or
> > > > > > > > bad
> > > > > > > > builds
> > > > > > > > please share the paths they built the kernels in so we can see
> > > > > > > >

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Stanacar, StefanX




On Tue, 2014-04-15 at 12:26 -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> > On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > > On Tue, 2014-04-15 at 09:03 +, Stanacar, StefanX wrote:
> > > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > > > > > > Very interesting results!  These are the results from the 
> > build hosts I have:
> > > > > > > > > > >   Fedora 13 (i686) - fails
> > > > > > > > > > >   Fedora 17 (i686) - fails
> > > > > > > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > > > > > > 
> > > > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > > > Fedora host - this is the first time I hear about issues 
> > > > > > > > > > with
> > > > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > > > more time...
> > > > > > > > > 
> > > > > > > > > I've been having a look at this. The biggest differences I can
> > > > > > > > > find
> > > > > > > > > between working and non working builds is the path length to 
> > > > > > > > > the
> > > > > > > > > build
> > > > > > > > > directory for the kernel. This is from comparing vmlinux files
> > > > > > > > > from
> > > > > > > > > working and non working builds.
> > > > > > > > > 
> > > > > > > > > Works:
> > > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > > > 
> > > > > > > > > Doesn't Work:
> > > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gn
> > > > > > > > > ueabi
> > > > > > > > > 
> > > > > > > > > I also have been wondering if the version strings may be 
> > > > > > > > > making
> > > > > > > > > a
> > > > > > > > > difference.
> > > > > > > > > 
> > > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken 
> > > > > > > > > build
> > > > > > > > > where I
> > > > > > > > > truncated the path length to a "working" build path length and
> > > > > > > > > patched
> > > > > > > > > in the same version strings:
> > > > > > > > > 
> > > > > > > > > const char linux_banner[] =
> > > > > > > > > 
> > > > > > > > >"Linux version 3.14.0-yocto-standard
> > > > > > > > >(paul@ubuntu-build01) (gcc
> > > > > > > > > 
> > > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > > 2014\n";
> > > > > > > > > 
> > > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > > (paul@ubuntu-build01)
> > > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > > > 
> > > > > > > > > to init/version.c.
> > > > > > > > > 
> > > > > > > > > I don't have hardware and would be interested to know if the
> > > > > > > > > kernel
> > > > > > > > > linked to above works or not. If it doesn't, it rules out 
> > > > > > > > > these
> > > > > > > > > path and
> > > > > > > > > string lengths, if it does work, it points to a problem there.
> > > > > > > > 
> > > > > > > > Richard,
> > > > > > > 
> > > > > > > > Good catch! It boots:
> > > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last one
> > > > > > > but
> > > > > > > with my changes to version.c reverted. The one should tell us if 
> > > > > > > its
> > > > > > > the
> > > > > > > paths or the strings.
> > > > > > 
> > > > > > This one also boots for me:
> > > > > > 
> > > > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2
> > > > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > > 
> > > > > > > I'm guessing the path problem is more likely but anything is
> > > > > > > possible.
> > > > > > > This is starting to look like some kind of compiler or linker 
> > > > > > > issue.
> > > > > > > If
> > > > > > > it is that, it would help to have more data points about what 
> > > > > > > works
> > > > > > > and
> > > > > > > what doesn't. With that in mind could people who have good or bad
> > > > > > > builds
> > > > > > > please share the paths they built the kernels in so we can see if 
> > > > > > > we
> > > > > > > can
> > > > > > > spot some kind of pattern.
> > > > > 
> > > > > BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi 
> > > > > and
> > > > > it works.
> > > > 
> > > > I can confirm:
> > > >  build dir in /home/stefans/b1  works,
> > > > 
> > > > but /home/stefans/yocto/poky/build doesn't.
> > > 
> > > But this works
> > > [stefans@firebird bu]$ pwd
> > > /home/stefans/yocto/poky/bu
> > > [stefans@fireb

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Denys Dmytriyenko

On Tue, Apr 15, 2014 at 01:16:01PM -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 05:36:10PM +0100, Paul Eggleton wrote:
> > On Tuesday 15 April 2014 12:26:39 Denys Dmytriyenko wrote:
> > > On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> > > > On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > > > > On Tue, 2014-04-15 at 09:03 +, Stanacar, StefanX wrote:
> > > > > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie 
> > wrote:
> > > > > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas 
> > wrote:
> > > > > > > > > > > > > Very interesting results!  These are the results from
> > > > > > > > > > > > > the
> > > > 
> > > > build hosts I have:
> > > > > > > > > > > > >   Fedora 13 (i686) - fails
> > > > > > > > > > > > >   Fedora 17 (i686) - fails
> > > > > > > > > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > > > > > > > > 
> > > > > > > > > > > > Interesting indeed. I have no idea what's so special 
> > > > > > > > > > > > about
> > > > > > > > > > > > Fedora host - this is the first time I hear about issues
> > > > > > > > > > > > with
> > > > > > > > > > > > it. I may try experimenting with different VMs once I 
> > > > > > > > > > > > have
> > > > > > > > > > > > more time...
> > > > > > > > > > > 
> > > > > > > > > > > I've been having a look at this. The biggest differences I
> > > > > > > > > > > can
> > > > > > > > > > > find
> > > > > > > > > > > between working and non working builds is the path length 
> > > > > > > > > > > to
> > > > > > > > > > > the
> > > > > > > > > > > build
> > > > > > > > > > > directory for the kernel. This is from comparing vmlinux
> > > > > > > > > > > files
> > > > > > > > > > > from
> > > > > > > > > > > working and non working builds.
> > > > > > > > > > > 
> > > > > > > > > > > Works:
> > > > > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > > > > > 
> > > > > > > > > > > Doesn't Work:
> > > > > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linu
> > > > > > > > > > > x-gn
> > > > > > > > > > > ueabi
> > > > > > > > > > > 
> > > > > > > > > > > I also have been wondering if the version strings may be
> > > > > > > > > > > making
> > > > > > > > > > > a
> > > > > > > > > > > difference.
> > > > > > > > > > > 
> > > > > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken
> > > > > > > > > > > build
> > > > > > > > > > > where I
> > > > > > > > > > > truncated the path length to a "working" build path length
> > > > > > > > > > > and
> > > > > > > > > > > patched
> > > > > > > > > > > in the same version strings:
> > > > > > > > > > > 
> > > > > > > > > > > const char linux_banner[] =
> > > > > > > > > > > 
> > > > > > > > > > >"Linux version 3.14.0-yocto-standard
> > > > > > > > > > >(paul@ubuntu-build01) (gcc
> > > > > > > > > > > 
> > > > > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > > > > 2014\n";
> > > > > > > > > > > 
> > > > > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > > > > (paul@ubuntu-build01)
> > > > > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > > > > > 
> > > > > > > > > > > to init/version.c.
> > > > > > > > > > > 
> > > > > > > > > > > I don't have hardware and would be interested to know if 
> > > > > > > > > > > the
> > > > > > > > > > > kernel
> > > > > > > > > > > linked to above works or not. If it doesn't, it rules out
> > > > > > > > > > > these
> > > > > > > > > > > path and
> > > > > > > > > > > string lengths, if it does work, it points to a problem
> > > > > > > > > > > there.
> > > > > > > > > > 
> > > > > > > > > > Richard,
> > > > > > > > > 
> > > > > > > > > > Good catch! It boots:
> > > > > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last
> > > > > > > > > one
> > > > > > > > > but
> > > > > > > > > with my changes to version.c reverted. The one should tell us 
> > > > > > > > > if
> > > > > > > > > its
> > > > > > > > > the
> > > > > > > > > paths or the strings.
> > > > > > > > 
> > > > > > > > This one also boots for me:
> > > > > > > > 
> > > > > > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version
> > > > > > > > 4.8.2
> > > > > > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > >
> > > > > > > > 
> > > > > > > > > I'm guessing the path problem is more likely but anything is
> > > > > > > > > possible.
> > > > > > > > > This is starting to look lik

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Denys Dmytriyenko

On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
> > > > > Some other things I tried with a "long" TMPDIR path (note that it's 
> > > > > the
> > > > > TMPDIR path that makes the difference - in my tests I've been using
> > > > > /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> > > > > 
> > > > > * kernel built with gcc 4.7.2 and binutils 2.23.2
> > > > > * u-boot built with gcc 4.7.2 and binutils 2.23.2
> > > > > * u-boot from 
> > > > > http://downloads.angstrom-distribution.org/demo/beaglebone/
> > > > > * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
> > > > > 
> > > > > I think we're now at the point where we'd benefit from someone with 
> > > > > better
> > > > > knowledge debugging the issue.
> > > > 
> > > > Ok, should we expand the search area? Since this is supposed to be 
> > > > vanilla
> > > > 3.14 kernel, can we try other platforms and see if they are similarly
> > > > affected? I'll try pinging our kernel guys for any ideas...
> > > 
> > > As far as I know it has only been observed with beaglebone (both white 
> > > and 
> > > black, if it makes a difference). FWIW, qemuarm images from the 
> > > autobuilder 
> > > boot just fine, and apparently the same is true of edgerouter (different 
> > > architecture but also uses u-boot).
> > 
> > But do those other platforms use uImage or zImage?

I don't yet know what is going on, but building in the same directory with 
sources (B = S) makes it work regarless of the path length:

/OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux

So, I just commented out setting kernel-specific B in linux-yocto.inc and any 
kernel now boots with long path:

#B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"

I'm copying Richard and Bruce directly to see if they may have a quick insight 
and/or accept it as a workaround for the release. I'll keep digging further, 
but if anyone cares to verify the above workaround works for them, I would 
appreciate. Thanks!

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

[yocto] Getting USB devices to work on BeagleBoard xM

2014-04-15 Thread Jeremy Cole-Baker


Hi,

I've managed to build a couple of different recipes for my BeagleBoard 
(BeagleBoard xM Rev C), and also had a go at customising it.  I think 
I've tried core-image-minimal and core-image-basic.


The build works OK, and I can set up my micro SD card and get it to 
boot. I see lots of messages about loading drivers during boot, and I 
can log in to linux.


However, the USB devices don't seem to be working. The built in 
USB-Ethernet isn't there, and when I plug in a USB stick nothing happens 
- nothing in /dev/ and no messages in the system log.


I don't know whether this is something I missed in the build, or some 
configuration I need to do. I also don't know whether it is specific to 
the Beagle or a general problem. Unfortunately I am new to Kernel builds 
and device drivers.


Here's what I've looked into:

The boot-up messages indicate that the USB drivers are loaded, e.g.:


usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
...
usbcore: registered new interface driver smsc75xx
usbcore: registered new interface driver smsc95xx
...etc

(I think smsc95xx is the USB-Ethernet chip on the beagle board xM).

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-omap: OMAP-EHCI Host Controller driver
ehci-omap 48064800.ehci: EHCI Host Controller
ehci-omap 48064800.ehci: new USB bus registered, assigned bus number 1
ehci-omap 48064800.ehci: irq 93, io mem 0x48064800
ehci-omap 48064800.ehci: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
usbcore: registered new interface driver usb-storage
musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -6
mousedev: PS/2 mouse device common for all mice
...Etc

There's a modprobe error which occurs a couple of times:

udevd[71]: starting version 175
modprobe: chdir(3.10.11-yocto-standard): No such file or directory

I also saw errors from the ethernet subsystem (?), along the lines of 
"eth0: device not found" and "usb0: device not found". This occurred 
during boot and also when I used "ifup eth0". I'm actually seeing a 
different error now: "ifconfig: SIOCGIFFLAGS: No such device". In either 
case, I think it's because something to do with the actual USB hardware 
is missing or not configured.


"lsmod" shows no modules loaded, i.e.:

root@beagleboard:~#lsmod
Module Size Used by
root@beagleboard:~#

Does this mean that the various device drivers, etc, above are built in 
to the kernel?


Any suggestions for how to diagnose / fix this problem? Anybody else 
have experience with the BeagleBoard xM? I'm a bit lost.


Thanks!


--
Riverhead Technology
Jeremy Cole-Baker
Ph. (+64) 27 673 0129
www.rhtech.co.nz

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

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Gary Thomas

On 2014-04-15 13:43, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
>> Some other things I tried with a "long" TMPDIR path (note that it's the
>> TMPDIR path that makes the difference - in my tests I've been using
>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
>>
>> * kernel built with gcc 4.7.2 and binutils 2.23.2
>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
>> * u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
>>
>> I think we're now at the point where we'd benefit from someone with 
>> better
>> knowledge debugging the issue.
>
> Ok, should we expand the search area? Since this is supposed to be vanilla
> 3.14 kernel, can we try other platforms and see if they are similarly
> affected? I'll try pinging our kernel guys for any ideas...

 As far as I know it has only been observed with beaglebone (both white and 
 black, if it makes a difference). FWIW, qemuarm images from the 
 autobuilder 
 boot just fine, and apparently the same is true of edgerouter (different 
 architecture but also uses u-boot).
>>>
>>> But do those other platforms use uImage or zImage?
> 
> I don't yet know what is going on, but building in the same directory with 
> sources (B = S) makes it work regarless of the path length:
> 
> /OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> 
> So, I just commented out setting kernel-specific B in linux-yocto.inc and any 
> kernel now boots with long path:
> 
> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> 
> I'm copying Richard and Bruce directly to see if they may have a quick 
> insight 
> and/or accept it as a workaround for the release. I'll keep digging further, 
> but if anyone cares to verify the above workaround works for them, I would 
> appreciate. Thanks!
> 

Verified - I rebuilt the kernel in a working tree with a longer
path (one in fact that had failed before) and it boots fine.

Wonder what ${B} != ${S} is doing wacky...?

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Bruce Ashfield


On 14-04-15 03:43 PM, Denys Dmytriyenko wrote:

On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:

Some other things I tried with a "long" TMPDIR path (note that it's the
TMPDIR path that makes the difference - in my tests I've been using
/home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:

* kernel built with gcc 4.7.2 and binutils 2.23.2
* u-boot built with gcc 4.7.2 and binutils 2.23.2
* u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
* earlyprintk and CONFIG_DEBUG_LL - no additional output printed

I think we're now at the point where we'd benefit from someone with better
knowledge debugging the issue.


Ok, should we expand the search area? Since this is supposed to be vanilla
3.14 kernel, can we try other platforms and see if they are similarly
affected? I'll try pinging our kernel guys for any ideas...


As far as I know it has only been observed with beaglebone (both white and
black, if it makes a difference). FWIW, qemuarm images from the autobuilder
boot just fine, and apparently the same is true of edgerouter (different
architecture but also uses u-boot).


But do those other platforms use uImage or zImage?


I don't yet know what is going on, but building in the same directory with
sources (B = S) makes it work regarless of the path length:

/OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux

So, I just commented out setting kernel-specific B in linux-yocto.inc and any
kernel now boots with long path:

#B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"

I'm copying Richard and Bruce directly to see if they may have a quick insight
and/or accept it as a workaround for the release. I'll keep digging further,


I've never seen this before, and when I'm back in the office Wed/Thursday
I can have a closer look.

As for the BBB using this in the release, I really don't want to have
one board that breaks the build and source separation, since it has
always been in place to keep things clean (and I know of a few random
scripts, etc, that expect it) .. but more importantly, I want to root
cause this, since it is a lurking problem.

Bruce


but if anyone cares to verify the above workaround works for them, I would
appreciate. Thanks!



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

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Richard Purdie

On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
> I don't yet know what is going on, but building in the same directory with 
> sources (B = S) makes it work regarless of the path length:
> 
> /OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> 
> So, I just commented out setting kernel-specific B in linux-yocto.inc and any 
> kernel now boots with long path:
> 
> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> 
> I'm copying Richard and Bruce directly to see if they may have a quick 
> insight 
> and/or accept it as a workaround for the release. I'll keep digging further, 
> but if anyone cares to verify the above workaround works for them, I would 
> appreciate. Thanks!

I'm travelling and don't have hardware so I'm limited in what I can look
at right now. I suspect this workaround "works" because it makes the
"beaglebone-standard-build" extra characters on the path. I have a
feeling your -111 test above may have reused sstate or something
like that and given misleading results. I'd be interested in the vmlinux
file from the build above to see if the poky-11 pathnames are in
there (they get stripped out when you create the zImage).

Cheers,

Richard

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

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Denys Dmytriyenko

On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
> On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
> > I don't yet know what is going on, but building in the same directory with 
> > sources (B = S) makes it work regarless of the path length:
> > 
> > /OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> > 
> > So, I just commented out setting kernel-specific B in linux-yocto.inc and 
> > any 
> > kernel now boots with long path:
> > 
> > #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> > 
> > I'm copying Richard and Bruce directly to see if they may have a quick 
> > insight 
> > and/or accept it as a workaround for the release. I'll keep digging 
> > further, 
> > but if anyone cares to verify the above workaround works for them, I would 
> > appreciate. Thanks!
> 
> I'm travelling and don't have hardware so I'm limited in what I can look
> at right now. I suspect this workaround "works" because it makes the
> "beaglebone-standard-build" extra characters on the path. I have a
> feeling your -111 test above may have reused sstate or something
> like that and given misleading results. I'd be interested in the vmlinux
> file from the build above to see if the poky-11 pathnames are in
> there (they get stripped out when you create the zImage).

Nope, I was fooled by sstate once, so this time I tested with cleansstate and 
compared timestamps of the kernel when it boots - it is definitely the new 
one. And to make sure 'beaglebone-standard-build' extra suffix doesn't affect 
it, I increased the path length even further - that extra level with 333 is 
there to over-compensate, as it was failing before even with just 111 and 222 
levels only... Looks like Gary was also able to verify it.

But, you are right about vmlinux - it doesn't have those paths in there any 
more! I've seen them there when building with B != S, but they are gone when 
building with B = S. Wondering why. You can check it for yourself:

http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard

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

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Denys Dmytriyenko

On Tue, Apr 15, 2014 at 09:12:30PM -0400, Denys Dmytriyenko wrote:
> On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
> > On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
> > > I don't yet know what is going on, but building in the same directory 
> > > with 
> > > sources (B = S) makes it work regarless of the path length:
> > > 
> > > /OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> > > 
> > > So, I just commented out setting kernel-specific B in linux-yocto.inc and 
> > > any 
> > > kernel now boots with long path:
> > > 
> > > #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> > > 
> > > I'm copying Richard and Bruce directly to see if they may have a quick 
> > > insight 
> > > and/or accept it as a workaround for the release. I'll keep digging 
> > > further, 
> > > but if anyone cares to verify the above workaround works for them, I 
> > > would 
> > > appreciate. Thanks!
> > 
> > I'm travelling and don't have hardware so I'm limited in what I can look
> > at right now. I suspect this workaround "works" because it makes the
> > "beaglebone-standard-build" extra characters on the path. I have a
> > feeling your -111 test above may have reused sstate or something
> > like that and given misleading results. I'd be interested in the vmlinux
> > file from the build above to see if the poky-11 pathnames are in
> > there (they get stripped out when you create the zImage).
> 
> Nope, I was fooled by sstate once, so this time I tested with cleansstate and 
> compared timestamps of the kernel when it boots - it is definitely the new 
> one. And to make sure 'beaglebone-standard-build' extra suffix doesn't affect 
> it, I increased the path length even further - that extra level with 333 is 
> there to over-compensate, as it was failing before even with just 111 and 222 
> levels only... Looks like Gary was also able to verify it.
> 
> But, you are right about vmlinux - it doesn't have those paths in there any 
> more! I've seen them there when building with B != S, but they are gone when 
> building with B = S. Wondering why. You can check it for yourself:
> 
> http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard

And, as a follow up, all those long paths in vmlinux when built with B != S 
point to sources. Here are few examples:

B != S strings:

/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/main.c
earlycon
4Malformed early option '%s'
3Starting init: %s exists but couldn't execute it (error %d)
...
6Trying to unpack rootfs image as initramfs...
/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/initramfs.c
6rootfs image is not initramfs (%s); looks like an initrd
TRAILER!!!
...
%lu.%02lu BogoMIPS (lpj=%lu)
/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/arch/arm/vfp/vfpmodule.c
6VFP support v0.3: 

B = S same strings:

init/main.c
earlycon
4Malformed early option '%s'
3Starting init: %s exists but couldn't execute it (error %d)
...
6Trying to unpack rootfs image as initramfs...
init/initramfs.c
6rootfs image is not initramfs (%s); looks like an initrd
TRAILER!!!
...
%lu.%02lu BogoMIPS (lpj=%lu)
arch/arm/vfp/vfpmodule.c
6VFP support v0.3: 

So, that explains why B = S works regardless of the location, as it doesn't 
embed full path to source files...

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

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Khem Raj

On Tue, Apr 15, 2014 at 6:20 PM, Denys Dmytriyenko  wrote:
> On Tue, Apr 15, 2014 at 09:12:30PM -0400, Denys Dmytriyenko wrote:
>> On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
>> > On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
>> > > I don't yet know what is going on, but building in the same directory 
>> > > with
>> > > sources (B = S) makes it work regarless of the path length:
>> > >
>> > > /OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
>> > >
>> > > So, I just commented out setting kernel-specific B in linux-yocto.inc 
>> > > and any
>> > > kernel now boots with long path:
>> > >
>> > > #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
>> > >
>> > > I'm copying Richard and Bruce directly to see if they may have a quick 
>> > > insight
>> > > and/or accept it as a workaround for the release. I'll keep digging 
>> > > further,
>> > > but if anyone cares to verify the above workaround works for them, I 
>> > > would
>> > > appreciate. Thanks!
>> >
>> > I'm travelling and don't have hardware so I'm limited in what I can look
>> > at right now. I suspect this workaround "works" because it makes the
>> > "beaglebone-standard-build" extra characters on the path. I have a
>> > feeling your -111 test above may have reused sstate or something
>> > like that and given misleading results. I'd be interested in the vmlinux
>> > file from the build above to see if the poky-11 pathnames are in
>> > there (they get stripped out when you create the zImage).
>>
>> Nope, I was fooled by sstate once, so this time I tested with cleansstate and
>> compared timestamps of the kernel when it boots - it is definitely the new
>> one. And to make sure 'beaglebone-standard-build' extra suffix doesn't affect
>> it, I increased the path length even further - that extra level with 333 is
>> there to over-compensate, as it was failing before even with just 111 and 222
>> levels only... Looks like Gary was also able to verify it.
>>
>> But, you are right about vmlinux - it doesn't have those paths in there any
>> more! I've seen them there when building with B != S, but they are gone when
>> building with B = S. Wondering why. You can check it for yourself:
>>
>> http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard
>
> And, as a follow up, all those long paths in vmlinux when built with B != S
> point to sources. Here are few examples:
>
> B != S strings:
>
> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/main.c
> earlycon
> 4Malformed early option '%s'
> 3Starting init: %s exists but couldn't execute it (error %d)
> ...
> 6Trying to unpack rootfs image as initramfs...
> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/initramfs.c
> 6rootfs image is not initramfs (%s); looks like an initrd
> TRAILER!!!
> ...
> %lu.%02lu BogoMIPS (lpj=%lu)
> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/arch/arm/vfp/vfpmodule.c
> 6VFP support v0.3:
>
>
> B = S same strings:
>
> init/main.c
> earlycon
> 4Malformed early option '%s'
> 3Starting init: %s exists but couldn't execute it (error %d)
> ...
> 6Trying to unpack rootfs image as initramfs...
> init/initramfs.c
> 6rootfs image is not initramfs (%s); looks like an initrd
> TRAILER!!!
> ...
> %lu.%02lu BogoMIPS (lpj=%lu)
> arch/arm/vfp/vfpmodule.c
> 6VFP support v0.3:
>
>
> So, that explains why B = S works regardless of the location, as it doesn't
> embed full path to source files...
>

seemingly there could be rodata segment overflow issue. Can you do the
kernel build with say linker from dora build
and see if it still fails.

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

[yocto] bitbake co from SVN with Authentication

Re: [yocto] BBB doesn't boot

Re: [yocto] bitbake co from SVN with Authentication

Re: [yocto] bitbake co from SVN with Authentication

Re: [yocto] bitbake co from SVN with Authentication

Re: [yocto] BBB doesn't boot

[yocto] [PATCH] weston: Add weston.ini

[yocto] [PATCH] weston: Add weston.ini

[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, April 15, 2014 8:00 AM US Pacific Time

[yocto] [meta-ivi][PATCH] weston: Add weston.ini

Re: [yocto] BBB doesn't boot

[linux-yocto] Regarding clarifications for adding support of I2C, SPI slave devices on x86 through ACPI

Re: [yocto] BBB doesn't boot

Re: [yocto] BBB doesn't boot

Re: [yocto] [PATCH] weston: Add weston.ini

Re: [linux-yocto] Regarding clarifications for adding support of I2C, SPI slave devices on x86 through ACPI

[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, April 15, 2014 8:00 AM US Pacific Time

Re: [yocto] BBB doesn't boot

Re: [yocto] BBB doesn't boot

Re: [yocto] BBB doesn't boot

Re: [yocto] BBB doesn't boot

[yocto] [not-for-merge][PATCH 2/2] beaglebone: switch default kernel format to zImage

[yocto] [not-for-merge][PATCH 1/2] u-boot: update to 2014.01

Re: [yocto] BBB doesn't boot

Re: [yocto] BBB doesn't boot

Re: [yocto] BBB doesn't boot

Re: [yocto] BBB doesn't boot

[yocto] Getting USB devices to work on BeagleBoard xM

Re: [yocto] BBB doesn't boot

Re: [yocto] BBB doesn't boot

Re: [yocto] BBB doesn't boot

Re: [yocto] BBB doesn't boot

Re: [yocto] BBB doesn't boot

Re: [yocto] BBB doesn't boot

34 matches

Site Navigation

Mail list logo

Footer information