Date   

Re: BBB doesn't boot

Denys Dmytriyenko
 

On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:
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-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/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, et al,

I've just submitted a patch to oe-core and yocto MLs that fixes this issue -
could you please test it in your setup and confirm? Thanks!

--
Denys


[PATCH] u-boot: fix beaglebone boot issue with large kernel images

Denys Dmytriyenko
 

From: Denys Dmytriyenko <denys@ti.com>

Fix beaglebone boot issue with large kernel images overwriting Device Tree.
See very detailed comments inside the patch.

The original patch is being reviewed upstream and is targeting mainline U-boot
version 2014.07. This is the adaptation of the patch for 2013.07 version we use

Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
...h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch | 74 ++++++++++++++++++++++
meta/recipes-bsp/u-boot/u-boot_2013.07.bb | 4 +-
2 files changed, 77 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch

diff --git a/meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch b/meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch
new file mode 100644
index 0000000..77e35bb
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch
@@ -0,0 +1,74 @@
+From 5701384cea4a829b772bf7a96a74825b58c22385 Mon Sep 17 00:00:00 2001
+From: Denys Dmytriyenko <denys@ti.com>
+Date: Thu, 17 Apr 2014 12:25:40 -0400
+Subject: [PATCH] am335x_evm.h: Add, use DEFAULT_LINUX_BOOT_ENV environment
+ string
+
+Modified version of the patch currently being reviewed for mainline:
+http://patchwork.ozlabs.org/patch/334861/
+
+To deal with a reoccurring problem properly we need to specify addresses
+for the Linux kernel, Flatted Device Tree and ramdisk that obey the
+constraints within the kernel's Documentation/arm/Booting file but also
+make sure that we relocate things within a valid address range.
+
+Signed-off-by: Denys Dmytriyenko <denys@ti.com>
+Signed-off-by: Tom Rini <trini@ti.com>
+
+Upstream-Status: Pending
+---
+ include/configs/am335x_evm.h | 31 ++++++++++++++++++++++++++-----
+ 1 file changed, 26 insertions(+), 5 deletions(-)
+
+diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
+index c5a6d4b..01e32b3 100644
+--- a/include/configs/am335x_evm.h
++++ b/include/configs/am335x_evm.h
+@@ -54,10 +54,7 @@
+ #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+ #ifndef CONFIG_SPL_BUILD
+ #define CONFIG_EXTRA_ENV_SETTINGS \
+- "loadaddr=0x80200000\0" \
+- "fdtaddr=0x80F80000\0" \
+- "fdt_high=0xffffffff\0" \
+- "rdaddr=0x81000000\0" \
++ DEFAULT_LINUX_BOOT_ENV \
+ "bootdir=/boot\0" \
+ "bootfile=uImage\0" \
+ "fdtfile=undefined\0" \
+@@ -197,7 +194,31 @@
+ #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START \
+ + (8 * 1024 * 1024))
+
+-#define CONFIG_SYS_LOAD_ADDR 0x81000000 /* Default load address */
++/*
++ * Our DDR memory always starts at 0x80000000 and U-Boot shall have
++ * relocated itself to higher in memory by the time this value is used.
++ * However, set this to a 32MB offset to allow for easier Linux kernel
++ * booting as the default is often used as the kernel load address.
++ */
++#define CONFIG_SYS_LOAD_ADDR 0x82000000 /* Default load address */
++
++/*
++ * We setup defaults based on constraints from the Linux kernel, which should
++ * also be safe elsewhere. We have the default load at 32MB into DDR (for
++ * the kernel), FDT above 128MB (the maximum location for the end of the
++ * kernel), and the ramdisk 512KB above that (allowing for hopefully never
++ * seen large trees). We say all of this must be within the first 256MB
++ * as that will normally be within the kernel lowmem and thus visible via
++ * bootm_size and we only run on platforms with 256MB or more of memory.
++ */
++#define DEFAULT_LINUX_BOOT_ENV \
++ "loadaddr=0x82000000\0" \
++ "kernel_addr_r=0x82000000\0" \
++ "fdtaddr=0x88000000\0" \
++ "fdt_addr_r=0x88000000\0" \
++ "rdaddr=0x88080000\0" \
++ "ramdisk_addr_r=0x88080000\0" \
++ "bootm_size=0x10000000\0"
+
+ #define CONFIG_MMC
+ #define CONFIG_GENERIC_MMC
+--
+1.9.2
+
diff --git a/meta/recipes-bsp/u-boot/u-boot_2013.07.bb b/meta/recipes-bsp/u-boot/u-boot_2013.07.bb
index 3141a2d..f8a8856 100644
--- a/meta/recipes-bsp/u-boot/u-boot_2013.07.bb
+++ b/meta/recipes-bsp/u-boot/u-boot_2013.07.bb
@@ -16,7 +16,9 @@ SRCREV = "62c175fbb8a0f9a926c88294ea9f7e88eb898f6c"

PV = "v2013.07+git${SRCPV}"

-SRC_URI = "git://git.denx.de/u-boot.git;branch=master"
+SRC_URI = "git://git.denx.de/u-boot.git;branch=master \
+ file://0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch \
+"

S = "${WORKDIR}/git"

--
1.9.2


Re: autobuilder repourl by commit

Flanagan, Elizabeth <elizabeth.flanagan@...>
 

Jate,

You can use the 'hash' property. Just make sure you have no other
branch/tag properties in the repo description.

So, something like this should work:

repos: [{'poky':
{'repourl':'git://git.yoctoproject.org/poky',
'hash':'7831ae829103ab283645'}},

On Thu, Apr 17, 2014 at 10:23 AM, Jate S <jatedev@gmail.com> wrote:
I am customizing the Yocto autobuilder for my own project. I would like to
specify a checksum for the repourl for poky. What property do I need to add?
I have tried adding the property commit, but it does not appear to work.

Thanks,

- Jate S.
--
Elizabeth Flanagan
Yocto Project
Build and Release


autobuilder repourl by commit

Jate Sujjavanich
 

I am customizing the Yocto autobuilder for my own project. I would like to specify a checksum for the repourl for poky. What property do I need to add? I have tried adding the property commit, but it does not appear to work.

Thanks,

- Jate S.


Re: Git fetch with user/pass in a recipe

Ronaldo Nunez <ronaldo.viera@...>
 

Thank you Michael! Worked as a charm! 


2014-04-16 18:48 GMT-03:00 Michael Halstead <michael@...>:

On 04/16/2014 02:15 PM, Ronaldo Nunez wrote:
Hi all!

I'm trying to create a custom recipe to a proprietary software from my company. The code should be fetched from a git server, with username and password authentication through a http connection (port 8080).

From the terminal I use the following command line to clone the project:


well in the bitbake recipe, I tried the following in SRC_URI variable, with no success:


I also tried:

SRC_URI = "git://server:8080/project.git;protocol=http;user=username"

It isn't mentioned at http://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#git-fetcher but looking at http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/git.py?h=dora it seems that including the password as part of the user parameter should work.

For example,
SRC_URI = "git://server:8080/project.git;protocol=http;user=username:password"


Michael Halstead
Yocto Project / Sys Admin


Again, with no success.

Well, any help is welcome. Thanks in advance.

--
Ronaldo Nunez




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




--
Ronaldo Nunez


Re: Integrating Golang

Khem Raj
 

On Thu, Apr 17, 2014 at 1:49 AM, Martin Donnelly <martin.donnelly@ge.com> wrote:
On 05/03/2014 21:55, Leo Schwab wrote:
Has anyone else done any work here? Is there anything that I can
steal^H^H^H^H^Htake inspiration from? Or am I in completely
unexplored territory?
I posted an RFC patch set last year but it didn't get any traction and
we subsequently ruled out use of go so I never followed up on it but it
might be a useful starting point.

http://lists.openembedded.org/pipermail/openembedded-core/2013-May/078606.html
Thats looks reasonable patch to me. Provided it can be forward ported
to gcc 4.8+
you should resubmit it for master

Cheers

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


J1900 (Bay trail) BSP

Chris Tapp
 

Is there a BSP for the J1900 anywhere?

I thought I had seen some patches go through for Bay Trail, but I've not found anything obvious in meta-intel.

I want to get accelerated GLES under X if that helps.

Chris Tapp

opensource@keylevel.com
www.keylevel.com


Re: Integrating Golang

Martin Donnelly <martin.donnelly@...>
 

On 05/03/2014 21:55, Leo Schwab wrote:
Has anyone else done any work here? Is there anything that I can
steal^H^H^H^H^Htake inspiration from? Or am I in completely
unexplored territory?
I posted an RFC patch set last year but it didn't get any traction and
we subsequently ruled out use of go so I never followed up on it but it
might be a useful starting point.

http://lists.openembedded.org/pipermail/openembedded-core/2013-May/078606.html

Cheers

- Martin


Re: non empty package group

Katu Txakur <katutxakurra@...>
 

Hi Paul,

Thanks a lot for your help. I'm sure that there is a good reason why that's not the way it works. I will continue then using individual packages for updates/installation.

Regards,
Katu


2014-04-16 17:34 GMT+01:00 Paul Eggleton <paul.eggleton@...>:

On Wednesday 16 April 2014 17:28:45 Katu Txakur wrote:
> 2014-04-16 17:17 GMT+01:00 Paul Eggleton <paul.eggleton@...>:
> > On Wednesday 16 April 2014 17:09:19 Katu Txakur wrote:
> > > yes, it does "inherit packagegroup" and all the packages are installed.
> > > What I would like to have is a mypackagegroup.ipk that I can copy to any
> > > system to install all the files, binaries.... in those recipes using
> > > "opkg install mypackage.ipk"
> > > The problem that I have is that the files, binaries... of the recipes in
> > > RDEPENDS_${PN} are not included in the mypackagegroup.ipk. Do you know
> > > how can I include them?
> >
> > opkg and similar package managers simply aren't designed to work like
> > that; it's expected that both devices would have access to the same
> > package feeds and therefore you would just install the packagegroup
> > package on each system in the same way.
>
> I see, but I don't want to feed the package from a repo, I just want to
> include all the files in the package.
> I'm now trying to set
> PREFERRED_PROVIDER_each-recipe = "mypackagegroup"
> hoping that it will change the location of the files from their individual
> recipes/packages to the packagegroup.
> I've just cleaned the entire tmp folder, I will find out tomorrow if this
> worked.

It isn't as simple as that, that just selects between providers but there is
nothing to actually make the "mypackagegroup" recipe actually provide
anything. The files would need to actually be produced as part of the
packagegroup recipe, and then it isn't really a packagegroup anymore.

I'm afraid our system just isn't designed to work this way. I'm sure it could
be made to, but it would require some additional work.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: Yocto life cycle statement

Armin Kuster
 

On 4/16/14, 1:21 PM, Stewart, David C wrote:

Thanks Stewart.

That is what I was looking for.

regards,
Armin
I found the following comments at
https://wiki.yoctoproject.org/wiki/FAQ#What_is_the_release_cycle_of_the_Yoc
to_Project.3F
(It does seem like we have been supplying maintenance releases for two
releases back, not just one. So maybe this wiki needs to be updated)



What is the release cycle of the Yocto Project?

Each release of the Yocto Project is subject to its own release schedule
according to the community-maintained Project Planning Guide
<https://wiki.yoctoproject.org/wiki/Planning#Yocto>. It is generally
expected that a new version of the Yocto Project will be released every
six months.

What is the overall support plan for the Yocto Project?

Security patches and critical bug fixes are supplied one release back. No
toolchain or kernel changes are allowed for these updates. Support for
longer periods of time can be supplied by commercial OSVs.



On 4/16/14, 12:43 PM, "Jeff Osier-Mixon" <jefro@jefro.net> wrote:

Hi Armin - let me do some research on this, just wanted to let you
know that I had seen it. I'm not sure we have a formal statement
published.

On Wed, Apr 16, 2014 at 11:49 AM, akuster@mvista <akuster@mvista.com>
wrote:
Hello,

Can someone point to a 'life cycle statement' for Yocto versions, one
that
discusses limited bug fixing peroid and ultimate EOL of a version. I am
having trouble find it.

Regards,
Armin
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


--
Jeff Osier-Mixon @Intel
Yocto Project Community Manager http://yoctoproject.org
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: Integrating Golang

Khem Raj
 

On Wed, Apr 16, 2014 at 12:10 PM, Hermanus Botha <wkj.id10t@gmail.com> wrote:
So I don't really know much about Yocto. But I would also like to see some
more Go-lang action on Yocto.
Start by generating the gcc runtime and language support in gcc
recipes. add it to RUNTIMETARGET and adjust PACKAGES
you also need to add it to LANGUAGES that should get it to some point.


This section of their manual seems promising.
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#cross-
development-toolchain-generation

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


Re: openssl and heartbleed

Michael Halstead
 

On 04/14/2014 07:41 AM, Martin Jansa wrote:
On Mon, Apr 14, 2014 at 02:37:52PM +0000, Richard Schmitt wrote:
Does the Yocto project plan to have some response to the heartbleed exploit in openssl in the near term?  Has this already been addressed?
It was already addressed for master, daisy, dora and dylan.
It's a separate issue but as far as the yoctoproject.org infrastructure is concerned our primary SSL termination server runs OpenSSL 0.9.8k and was not vulnerable to heartbleed. Other servers were not publicly accessible and were patched quickly after the announcement. On the build hosts the only running service linked linked against OpenSSL was NTP. We discussed this on the https://www.yoctoproject.org/tools-resources/community/weekly-technical-call the day after heartbleed was announced.

Michael Halstead
Yocto Project / Sys Admin

      



Re: Git fetch with user/pass in a recipe

Michael Halstead
 

On 04/16/2014 02:15 PM, Ronaldo Nunez wrote:
Hi all!

I'm trying to create a custom recipe to a proprietary software from my company. The code should be fetched from a git server, with username and password authentication through a http connection (port 8080).

From the terminal I use the following command line to clone the project:


well in the bitbake recipe, I tried the following in SRC_URI variable, with no success:


I also tried:

SRC_URI = "git://server:8080/project.git;protocol=http;user=username"

It isn't mentioned at http://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#git-fetcher but looking at http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/git.py?h=dora it seems that including the password as part of the user parameter should work.

For example,
SRC_URI = "git://server:8080/project.git;protocol=http;user=username:password"


Michael Halstead
Yocto Project / Sys Admin


Again, with no success.

Well, any help is welcome. Thanks in advance.

--
Ronaldo Nunez




Git fetch with user/pass in a recipe

Ronaldo Nunez <ronaldo.viera@...>
 

Hi all!

I'm trying to create a custom recipe to a proprietary software from my company. The code should be fetched from a git server, with username and password authentication through a http connection (port 8080).

From the terminal I use the following command line to clone the project:

$ git clone http://username:pass@server:8080/project.git

well in the bitbake recipe, I tried the following in SRC_URI variable, with no success:

SRC_URI = "git://username:pass@server:8080/project.git;protocol=http"

I also tried:

SRC_URI = "git://server:8080/project.git;protocol=http;user=username"

Again, with no success.

Well, any help is welcome. Thanks in advance.

--
Ronaldo Nunez


Re: Yocto life cycle statement

David Stewart
 

I found the following comments at
https://wiki.yoctoproject.org/wiki/FAQ#What_is_the_release_cycle_of_the_Yoc
to_Project.3F
(It does seem like we have been supplying maintenance releases for two
releases back, not just one. So maybe this wiki needs to be updated)



What is the release cycle of the Yocto Project?

Each release of the Yocto Project is subject to its own release schedule
according to the community-maintained Project Planning Guide
<https://wiki.yoctoproject.org/wiki/Planning#Yocto>. It is generally
expected that a new version of the Yocto Project will be released every
six months.

What is the overall support plan for the Yocto Project?

Security patches and critical bug fixes are supplied one release back. No
toolchain or kernel changes are allowed for these updates. Support for
longer periods of time can be supplied by commercial OSVs.

On 4/16/14, 12:43 PM, "Jeff Osier-Mixon" <jefro@jefro.net> wrote:

Hi Armin - let me do some research on this, just wanted to let you
know that I had seen it. I'm not sure we have a formal statement
published.

On Wed, Apr 16, 2014 at 11:49 AM, akuster@mvista <akuster@mvista.com>
wrote:
Hello,

Can someone point to a 'life cycle statement' for Yocto versions, one
that
discusses limited bug fixing peroid and ultimate EOL of a version. I am
having trouble find it.

Regards,
Armin
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


--
Jeff Osier-Mixon @Intel
Yocto Project Community Manager http://yoctoproject.org
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: Yocto life cycle statement

Jeff Osier-Mixon <jefro@...>
 

Hi Armin - let me do some research on this, just wanted to let you
know that I had seen it. I'm not sure we have a formal statement
published.

On Wed, Apr 16, 2014 at 11:49 AM, akuster@mvista <akuster@mvista.com> wrote:
Hello,

Can someone point to a 'life cycle statement' for Yocto versions, one that
discusses limited bug fixing peroid and ultimate EOL of a version. I am
having trouble find it.

Regards,
Armin
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Jeff Osier-Mixon @Intel
Yocto Project Community Manager http://yoctoproject.org


Re: BBB doesn't boot

William Mills <wmills@...>
 

On 04/16/2014 03:04 PM, Stefan Stanacar wrote:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6165

Link to the two kernels at the end of the first comment.
Yes, I found that i bit ago. Very helpful, thanks.

I have not run them yet (my only BBB is at home)
but I am comparing the objdumps.


Re: Integrating Golang

Hermanus Botha <wkj.id10t@...>
 

Hermanus Botha <wkj.id10t@...> writes:


So I don't really know much about Yocto. But I would also like to see some
more Go-lang action on Yocto.

This section of their manual seems promising.
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#cross-
development-toolchain-generation

I guess this link is broken. In that manual, it's section:
"4.2. Cross-Development Toolchain Generation"

Manual:
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html


Re: Question about remote debugging via gdbserver

Rudolf Streif <rstreif@...>
 

Hi Federico,

I knew that I can add source paths to the debugger.

Ok, if that's not the issue what exactly is not working for you?
 

I see in your debug profiles that you have some binaries eg "ls". Did you import that binary from sysrootfs on your build machine? Can you please tell me the steps before adding the path?

No, that's actually sample code of a simple ls application that I use for teaching a class on Linux APIs.

Cheers,
Rudi


Re: Integrating Golang

Hermanus Botha <wkj.id10t@...>
 

So I don't really know much about Yocto. But I would also like to see some
more Go-lang action on Yocto.

This section of their manual seems promising.
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#cross-
development-toolchain-generation