[yocto] [linux-yocto-3.2][PATCH] arm: Fix linking errors with binutils 2.23
We end up with linking errors on arm using latest binutils
because we are linking asm generated objects which use -march=all
generating different attributes into object and use some c objects
e.g. misc.o which use different march therefore generating a
different set of attributes into object. When linking is done
the ld complains since it finds incompatible attributes and ends
up with errors like
error: DIV usage mismatch between arch/arm/boot/compressed/head.o and
output
error: DIV usage mismatch between arch/arm/boot/compressed/misc.o and
output
error: DIV usage mismatch between arch/arm/boot/compressed/decompress.o
and output
error: DIV usage mismatch between arch/arm/boot/compressed/lib1funcs.o
and output
This patch fixes it by providing correct march to assembly routines
which than matches with output of ld.
Signed-off-by: Khem Raj raj.k...@gmail.com
---
arch/arm/boot/compressed/Makefile |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/compressed/Makefile
b/arch/arm/boot/compressed/Makefile
index 21f56ff..05d9cb3 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -5,7 +5,7 @@
#
OBJS =
-
+plus_sec :=$(call as-instr,.arch_extension sec,+sec)
# Ensure that MMCIF loader code appears early in the image
# to minimise that number of bocks that have to be read in
# order to load it.
@@ -123,7 +123,7 @@ KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS))
endif
ccflags-y := -fpic -fno-builtin -I$(obj)
-asflags-y := -Wa,-march=all
+asflags-y := -Wa,-march=armv7-a$(plus_sec)
# Supply kernel BSS size to the decompressor via a linker symbol.
KBSS_SZ = $(shell size $(obj)/../../../../vmlinux | awk 'END{print $$3}')
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2] [Fixed]Yocto-BSP Main Page - time consuming processes block the UI
- problems on the main page of yocto-bsp wizard :
- getting the available kernel architectures is invoked from the UI
- similar to the properties page, when loading the
architectures a new thread is created in the background and a
progress monitor dialog is shown.
- getting qemu kernel architectures is invoked from the UI
- as above.
- creation of properties file is done with each change in any of
the controls
- this action should only be done once, and the most
convenient place would be when flipping to next page. Unfortunately, the
method that checks if we can flip to the next page is called at each
change on the controls, in so re-creating the file with each keystroke.
The creation of this file was moved on the YoctoBSP Wizard, when
clicking on finish.[v1](update : flipping to properties page fails
while trying to retrieve properties file)
The creation of this file will only be done once at the first
validation of the main page [v2].
In order to reuse the code that sends a process in the background
and shows the progress from the properties page, we use a
generic class BSPThread that runs a command from the shell in the
background and collects the output error, and a BSPProgressDialog to
show. Each command will customize the processing of its output by
subclassing BSPThread. the progress of the background thread.
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
---
.../sdk/remotetools/wizards/bsp/BSPAction.java | 32 ++
.../remotetools/wizards/bsp/BSPProgressDialog.java | 44 +++
.../sdk/remotetools/wizards/bsp/BSPThread.java | 92 ++
.../wizards/bsp/ErrorCollectorThread.java | 19 ++
.../remotetools/wizards/bsp/KernelArchGetter.java | 23 ++
.../wizards/bsp/KernelBranchesGetter.java | 28 ++
.../sdk/remotetools/wizards/bsp/MainPage.java | 300 --
.../wizards/bsp/OutputCollectorThread.java | 19 ++
.../remotetools/wizards/bsp/PropertiesPage.java| 327 +++-
.../remotetools/wizards/bsp/QemuArchGetter.java| 27 ++
.../remotetools/wizards/bsp/YoctoBSPWizard.java| 86 +++--
11 files changed, 571 insertions(+), 426 deletions(-)
create mode 100644
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPAction.java
create mode 100644
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPProgressDialog.java
create mode 100644
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPThread.java
create mode 100644
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/ErrorCollectorThread.java
create mode 100644
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/KernelArchGetter.java
create mode 100644
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/KernelBranchesGetter.java
create mode 100644
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/OutputCollectorThread.java
create mode 100644
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/QemuArchGetter.java
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPAction.java
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPAction.java
new file mode 100644
index 000..171f181
--- /dev/null
+++
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPAction.java
@@ -0,0 +1,32 @@
+package org.yocto.sdk.remotetools.wizards.bsp;
+
+/**
+ * Stores a list of items from the output of a background thread and the error
message if something went wrong
+ * @author ioana.grigoropol
+ *
+ */
+public class BSPAction {
+ private String[] items;
+ private String message;
+
+ BSPAction(String[] items, String message){
+ this.setItems(items);
+ this.setMessage(message);
+ }
+
+ public String[] getItems() {
+ return items;
+ }
+
+ public void setItems(String[] items) {
+ this.items = items;
+ }
+
+ public String getMessage() {
+ return message;
+ }
+
+ public void setMessage(String message) {
+ this.message = message;
+ }
+}
\ No newline at end of file
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPProgressDialog.java
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPProgressDialog.java
new file mode 100644
index 000..5cf713d
--- /dev/null
+++
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPProgressDialog.java
@@ -0,0 +1,44 @@
+package org.yocto.sdk.remotetools.wizards.bsp;
+
+import org.eclipse.core.runtime.IProgressMonitor;
+import org.eclipse.jface.dialogs.ProgressMonitorDialog;
+import
Re: [yocto] [poky] [PATCH v2] routerstationpro: move board off 3.0 and onto the 3.4 kernel
On Fri, 2012-08-17 at 11:24 -0400, Paul Gortmaker wrote: The updated patch series to support this target is in place on the BSP specific branch in the 3.4 kernel tree now[1], so we can move it ahead off of the old 3.0 kernel. [1] https://lists.yoctoproject.org/pipermail/linux-yocto/2012-July/23.html Cc: Bruce Ashfield bruce.ashfi...@windriver.com Cc: Saul Wold s...@linux.intel.com Acked-by: Darren Hart dvh...@linux.intel.com Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- [v2: update to the SRCREV-of-the-day. Note that if anyone sees build failures with this, you are also missing the meta SRCREV update in linux-yocto_3.4.bb from Bruce. Yay SRCREV. ] meta-yocto/conf/machine/routerstationpro.conf| 2 +- meta-yocto/recipes-kernel/linux/linux-yocto_3.4.bbappend | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) Merged to master, thanks. I had to manually apply the patch. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] libgcc_s.so libstdc++.so on the target
Hi, I notice that core-image-minimal doesn't ship libgcc_s.so and libstdc++.so shared libraries on the target. Some of the executables that I manually cross compile on the host, and copy over to the target, require these libraries at a minimum. Which package or task should I append, to core-image-minimal, to get these two shared libraries file to get copied over to the rootfilesystem image tarball? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] of recipes and packages
Okay, if the confusion over yocto versus yocto project versus poky and trying to decide whether poky or yocto is a distribution or a build system or sometimes both or neither of either wasn't bad enough... there now comes a new confusion: recipes versus packages an image is composed of packages a recipe for a given piece of software generates a set of packages to discover the list of packages generated by a recipe one can use: $ bitbake -e recipe | grep ^PACKAGES= to discover the list of available recipes (for a given set of layers) one can use: $ bitbake -s However: $ bitbake --help | grep -- -s ... -s, --show-versions show current and preferred versions of all packages ... ...versions of all _packages_!? Shouldn't that be recipes? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] mpc8315e: switch to Xorg instead of kdrive
All of the other BSPs are using Xorg and kdrive is only maintained for Xephyr. Signed-off-by: Ross Burton ross.bur...@intel.com --- meta-yocto/conf/machine/mpc8315e-rdb.conf |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/meta-yocto/conf/machine/mpc8315e-rdb.conf b/meta-yocto/conf/machine/mpc8315e-rdb.conf index aa1e5c3..390882c 100644 --- a/meta-yocto/conf/machine/mpc8315e-rdb.conf +++ b/meta-yocto/conf/machine/mpc8315e-rdb.conf @@ -17,8 +17,13 @@ MACHINE_FEATURES = keyboard pci ext2 ext3 serial PREFERRED_VERSION_linux-yocto ?= 3.4% PREFERRED_PROVIDER_virtual/kernel = linux-yocto -PREFERRED_PROVIDER_virtual/xserver = xserver-kdrive -XSERVER = xserver-kdrive-fbdev +PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg +XSERVER ?= xserver-xorg \ + xserver-xorg-extension-extmod \ + xf86-input-mouse \ + xf86-input-keyboard \ + xf86-input-evdev \ + xf86-video-fbdev PREFERRED_VERSION_u-boot ?= v2012.04% UBOOT_ENTRYPOINT = 0x -- 1.7.10 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] of recipes and packages
I tend to think of packages as ingredients, in keeping with the cooking metaphor. They have version numbers, just as ingredients in the refrigerator have expiration dates. The recipes, however, have their own version numbers, but they are less critical to the success of the build - maybe my Aunt Agnes has a version of Betty Crocker's yellow cake recipe, but improved slightly. If I make that recipe with old eggs, though, it will fail. In this case, bitbake is looking for the expiration dates on your ingredients - the version of the package that each recipe builds. With the list that comes from bitbake -s you can determine whether any of your packages is the right one. As for the versions of the recipes themselves, the Yocto Project's QA and testing process makes sure that each of the included recipes works, in the sense that it builds the package reliably. You can spice them up if you like. Chris Hallinan wrote up a good description of many of the terms used in the project: http://blogs.mentor.com/chrishallinan/blog/2012/04/13/yocto-versus-poky-versus-angstrom-etc/ Hope that helps On Wed, Aug 22, 2012 at 10:05 AM, Trevor Woerner twoer...@gmail.com wrote: Okay, if the confusion over yocto versus yocto project versus poky and trying to decide whether poky or yocto is a distribution or a build system or sometimes both or neither of either wasn't bad enough... there now comes a new confusion: recipes versus packages an image is composed of packages a recipe for a given piece of software generates a set of packages to discover the list of packages generated by a recipe one can use: $ bitbake -e recipe | grep ^PACKAGES= to discover the list of available recipes (for a given set of layers) one can use: $ bitbake -s However: $ bitbake --help | grep -- -s ... -s, --show-versions show current and preferred versions of all packages ... ...versions of all _packages_!? Shouldn't that be recipes? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] routerstationpro: switch to Xorg instead of kdrive
All of the other BSPs are using Xorg and kdrive is only maintained for Xephyr. Signed-off-by: Ross Burton ross.bur...@intel.com --- meta-yocto/conf/machine/routerstationpro.conf |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/meta-yocto/conf/machine/routerstationpro.conf b/meta-yocto/conf/machine/routerstationpro.conf index 3c2f56f..645a94a 100644 --- a/meta-yocto/conf/machine/routerstationpro.conf +++ b/meta-yocto/conf/machine/routerstationpro.conf @@ -11,9 +11,14 @@ KERNEL_ALT_IMAGETYPE = vmlinux.bin PREFERRED_PROVIDER_virtual/kernel ?= linux-yocto PREFERRED_VERSION_linux-yocto ?= 3.0% -PREFERRED_PROVIDER_virtual/xserver = xserver-kdrive -XSERVER = xserver-kdrive-fbdev +PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg +XSERVER ?= xserver-xorg \ + xserver-xorg-extension-extmod \ + xf86-input-mouse \ + xf86-input-keyboard \ + xf86-input-evdev \ + xf86-video-fbdev SERIAL_CONSOLE = 115200 ttyS0 -- 1.7.10 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] PyCon India 2012
Hi All, I would like to do a talk in Python Conference, PyCon India 2012 about Yocto Project. The PyCon India is purely a volunteer effort from python community in India. Here is the details: http://in.pycon.org/2012/funnel/pyconindia2012/6-yoctoproject-and-bitbake and http://in.pycon.org/2012/. Firstly, I request the community and project leaders to give me the permission to do presentation and Secondly, request you all to guide me to make the presentation a grand successful. I believe, about 80% of the audience would be python programmer and about 5% - 10% can be from embedded stream. So, what I planning is to give a short intro about yocto project and showing a demo with Qemu (10 - 15 min), and then explaining bitbake's operation with a recipe in the yocto (20 mins). That is about bitbake's COW, scheduler, runqueue and shared state cache. Based on this idea, I have been preparing the slides. I was little away due to current assignment but I found http://www.aosabook.org/en/yocto.html and http://vimeo.com/36450321 very useful. Once draft slides are made, I will sent to the mailing list. I request you all to give some more comments on this. -- Thanks and Regards, Sathishkumar D ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [infrastructure] Power interruption at OSL
There was an unintended power interruption during UPS electrical work at the OSU Open Source Lab today. Power to the Yocto Project racks was not impacted but the core router was briefly offline. This event doesn't appear to have impacted us but please report any network trouble that may be related. Michael Halstead Yocto Project / Sys Admin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How does bitbake work
Hi Tim - this sounds quite correct to me, and a good way to represent the process. Further, the elinux.org wiki page is coming along very well, and I would encourage you to add this to the page. I'd be glad to help with it if I can. On Tue, Aug 21, 2012 at 11:23 AM, Tim Bird tim.b...@am.sony.com wrote: On 08/21/2012 01:11 AM, Liu wrote: Hi all, In order to learn to use poky,I am wondering how bitbake works with so many recipes. When I bitbake target, I want to know how bitbake collect the providers of target . Then bitbake will prepare the runqueue tasks to build the target.So I need to know which tasks to assign to build the target.And bitbake run these tasks in what order.In other words according to the characteristics of what to decided to implement which task first and then next. I am very eager to know the answers. I'm not an expert, but here's some information that I believe is correct. (If someone else knows better, please correct this...) bitbake reads the entire set of recipe files that are specified by the local configuration, and parses them all into a global task namespace. This includes all the class files and include files as well. These are specified by the BBFILES and BBLAYERS variables in the conf/bblayers.conf file. Within the layers directories, the layer-dir/conf/layer.conf file is used to indicate the set of .bb files to parse for that layer. Note that this global parse of the entire set of recipe files is quite different from 'make', which usually operated on a single Makefile. (This is also why bitbake startup is a little slow). Information in the meta-data (the DEPENDS and PROVIDES lines) determine package ordering. Where packages are independent of each other, the build order is dependent (I believe) on file parse order. In this case, processing is not required to be in any particular order (and, in fact, can be parallelized). You can have bitbake produce the dependency graph of the packages for your build by using the -g option. This produces output in 'dot' syntax (suitable for processing using some graphviz visualizer). The list of tasks to perform within a package appears to come from the common class meta-data (see meta/classes/utility-tasks.bbclass, for example) and the meta-data for the individual package These are added by the 'addtask' keyword. You can see a list of tasks for an individual package with: bitbake pkg -c listtasks I have started to put together an overview introduction of Yocto at: http://elinux.org/Yocto_Project_Introduction I haven't gotten much completed yet, but I do discuss bitbake there a bit. Hopefully what I've got so far will be helpful. -- Tim P.S. someone correct me if I'm wrong. Thanks , -- Yu Liu Following is the some output of bitbake busybox and in this example I want to know why first do the task of (quilt-native_0.51.bb, do_fetch) : Parsing recipes...done. Parsing of 830 .bb files complete (0 cached, 830 parsed). 1106 targets, 34 skipped, 0 masked, 0 errors. OE Build Configuration: BB_VERSION= 1.15.2 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = qemuarm DISTRO= poky DISTRO_VERSION= 1.2.1 TUNE_FEATURES = armv5 dsp thumb arm926ejs TARGET_FPU= soft meta meta-yocto= unknown:unknown NOTE: Resolving any missing task queue dependencies NOTE: multiple providers are available for virtual/arm-none-linux-gnueabi-g++ (external-csl-toolchain, gcc-cross) NOTE: consider defining a PREFERRED_PROVIDER entry to match virtual/arm-none-linux-gnueabi-g++ NOTE: multiple providers are available for runtime linux-libc-headers-dev (linux-libc-headers, linux-libc-headers-yocto, linux-libc-headers-yocto-nativesdk) NOTE: consider defining a PREFERRED_PROVIDER entry to match linux-libc-headers-dev NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Running task 1 of 706 (ID: 18, /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/quilt/quilt-native_0.51.bb, do_fetch) NOTE: Running task 2 of 706 (ID: 228, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/gnu-config/gnu-config_2011.bb, do_fetch) NOTE: Running task 3 of 706 (ID: 189, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/autoconf/autoconf_2.68.bb, do_fetch) NOTE: Running task 4 of 706 (ID: 515, /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/m4/m4-native_1.4.16.bb, do_fetch) NOTE: package gnu-config-native-2011-r1: task do_fetch: Started NOTE: package m4-native-1.4.16-r2: task do_fetch: Started NOTE: package quilt-native-0.51-r1: task do_fetch: Started NOTE: package autoconf-native-2.68-r7: task do_fetch: Started NOTE: package gnu-config-native-2011-r1: task do_fetch: Succeeded NOTE: Running task 5 of 706 (ID: 224,
Re: [yocto] of recipes and packages
Hi Jeff, Thanks for your tasty metaphors! On Wed, Aug 22, 2012 at 1:15 PM, Jeff Osier-Mixon je...@jefro.net wrote: In this case, bitbake is looking for the expiration dates on your ingredients - the version of the package that each recipe builds. But your wording would seem to imply _a_ recipe builds _a_ package. But a recipe doesn't build a package, a recipe potentially builds lots of packages. For example the net-snmp recipe builds the following packages: net-snmp-dbg net-snmp-doc net-snmp-dev net-snmp-staticdev net-snmp-static net-snmp-libs net-snmp-mibs net-snmp-server net-snmp-client bitbake -s doesn't list net-snmp-dbg net-snmp-doc net-snmp-dev... it lists net-snmp. Therefore couldn't the wording of the bitbake help be improved to say: -s, --show-versions show current and preferred versions of all __recipes__ instead of: -s, --show-versions show current and preferred versions of all __packages__ ? Chris Hallinan wrote up a good description of many of the terms used Actually I wrote this email after reading his very next blog post: http://blogs.mentor.com/chrishallinan/blog/2012/04/27/more-on-yocto-terminology-recipes-and-packages/ :-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [linux-yocto-3.2][PATCH] arm: Fix linking errors with binutils 2.23
On 12-08-22 05:28 AM, Khem Raj wrote:
We end up with linking errors on arm using latest binutils
because we are linking asm generated objects which use -march=all
generating different attributes into object and use some c objects
e.g. misc.o which use different march therefore generating a
different set of attributes into object. When linking is done
the ld complains since it finds incompatible attributes and ends
up with errors like
error: DIV usage mismatch between arch/arm/boot/compressed/head.o and
output
error: DIV usage mismatch between arch/arm/boot/compressed/misc.o and
output
error: DIV usage mismatch between arch/arm/boot/compressed/decompress.o
and output
error: DIV usage mismatch between arch/arm/boot/compressed/lib1funcs.o
and output
This patch fixes it by providing correct march to assembly routines
which than matches with output of ld.
Looks good to me. I'll queue it here with a few other fixes and do
a test build against my existing binutils.
I haven't looked yet, will 3.4+ need the same fix ?
Cheers,
Bruce
Signed-off-by: Khem Rajraj.k...@gmail.com
---
arch/arm/boot/compressed/Makefile |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/compressed/Makefile
b/arch/arm/boot/compressed/Makefile
index 21f56ff..05d9cb3 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -5,7 +5,7 @@
#
OBJS =
-
+plus_sec :=$(call as-instr,.arch_extension sec,+sec)
# Ensure that MMCIF loader code appears early in the image
# to minimise that number of bocks that have to be read in
# order to load it.
@@ -123,7 +123,7 @@ KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS))
endif
ccflags-y := -fpic -fno-builtin -I$(obj)
-asflags-y := -Wa,-march=all
+asflags-y := -Wa,-march=armv7-a$(plus_sec)
# Supply kernel BSS size to the decompressor via a linker symbol.
KBSS_SZ = $(shell size $(obj)/../../../../vmlinux | awk 'END{print $$3}')
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] of recipes and packages
On Wed, Aug 22, 2012 at 12:23 PM, Trevor Woerner twoer...@gmail.com wrote: On Wed, Aug 22, 2012 at 1:15 PM, Jeff Osier-Mixon je...@jefro.net wrote: In this case, bitbake is looking for the expiration dates on your ingredients - the version of the package that each recipe builds. But your wording would seem to imply _a_ recipe builds _a_ package. But a recipe doesn't build a package, a recipe potentially builds lots of packages. For example the net-snmp recipe builds the following packages: net-snmp-dbg net-snmp-doc net-snmp-dev net-snmp-staticdev net-snmp-static net-snmp-libs net-snmp-mibs net-snmp-server net-snmp-client bitbake -s doesn't list net-snmp-dbg net-snmp-doc net-snmp-dev... it lists net-snmp. Therefore couldn't the wording of the bitbake help be improved to say: -s, --show-versions show current and preferred versions of all __recipes__ instead of: It could, and should, be changed in that way, yes. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] of recipes and packages
On Wed, Aug 22, 2012 at 3:24 PM, Chris Larson clar...@kergoth.com wrote: On Wed, Aug 22, 2012 at 12:23 PM, Trevor Woerner twoer...@gmail.com wrote: bitbake -s doesn't list net-snmp-dbg net-snmp-doc net-snmp-dev... it lists net-snmp. Therefore couldn't the wording of the bitbake help be improved to say: -s, --show-versions show current and preferred versions of all __recipes__ instead of: It could, and should, be changed in that way, yes. Do the OE people accept this wording too, or is this a yocto-project-only thing? In other words, should a potential patch be sent to OE or here? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] of recipes and packages
On Wed, Aug 22, 2012 at 1:15 PM, Trevor Woerner twoer...@gmail.com wrote: On Wed, Aug 22, 2012 at 3:24 PM, Chris Larson clar...@kergoth.com wrote: On Wed, Aug 22, 2012 at 12:23 PM, Trevor Woerner twoer...@gmail.com wrote: bitbake -s doesn't list net-snmp-dbg net-snmp-doc net-snmp-dev... it lists net-snmp. Therefore couldn't the wording of the bitbake help be improved to say: -s, --show-versions show current and preferred versions of all __recipes__ instead of: It could, and should, be changed in that way, yes. Do the OE people accept this wording too, or is this a yocto-project-only thing? In other words, should a potential patch be sent to OE or here? The change would be to a core component, which is part of OE and which yocto pulls in — bitbake. So it would make no sense to send the patch here. No changes to bitbake are going into poky without going into the main bitbake repository. The bitbake-devel mailing list is the correct place for it. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [linux-yocto-3.2][PATCH] arm: Fix linking errors with binutils 2.23
On Wed, Aug 22, 2012 at 12:24 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: I haven't looked yet, will 3.4+ need the same fix ? yes looking at 3.4 code. But havent tried that yet ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] of recipes and packages
On Wed, 22 Aug 2012, Chris Larson wrote: On Wed, Aug 22, 2012 at 1:15 PM, Trevor Woerner twoer...@gmail.com wrote: On Wed, Aug 22, 2012 at 3:24 PM, Chris Larson clar...@kergoth.com wrote: On Wed, Aug 22, 2012 at 12:23 PM, Trevor Woerner twoer...@gmail.com wrote: bitbake -s doesn't list net-snmp-dbg net-snmp-doc net-snmp-dev... it lists net-snmp. Therefore couldn't the wording of the bitbake help be improved to say: -s, --show-versions show current and preferred versions of all __recipes__ instead of: It could, and should, be changed in that way, yes. Do the OE people accept this wording too, or is this a yocto-project-only thing? In other words, should a potential patch be sent to OE or here? The change would be to a core component, which is part of OE and which yocto pulls in — bitbake. So it would make no sense to send the patch here. No changes to bitbake are going into poky without going into the main bitbake repository. The bitbake-devel mailing list is the correct place for it. there really should be an official glossary somewhere, and it should be backed up with *actual* *examples* from the source as much as possible. that is, don't use foo if there's an existing recipe or package whose use would be more informative. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Classes
Hi, How about these classes by the Linux Foundation? https://training.linuxfoundation.org/courses/linux-developer/building-embedded-linux-with-yocto-crash-course https://training.linuxfoundation.org/courses/linux-developer/building-embedded-linux-with-yocto ... and of course there is also customized stuff ... Regards, Robert ...It is easier to change the specification to fit the program than vice versa. - Anonymous My public pgp key is available at: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x90320BF1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] dev manual section on customizing images needs serious adjustment
from here:
http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#usingpoky-extend-customimage-custombb
a couple gripes.
end of 4.2.1 suggests
IMAGE_INSTALL += strace
when creating a new image .bb file. as i read it, the docs currently
suggest
IMAGE_INSTALL_append = strace
when adding to your local.conf, and i don't think it's sufficiently
clear to the reader the distinction between += and _append, and
when to use one or the other. and reading the source doesn't help
since it bounces back and forth constantly. is this clarified
anywhere?
a bigger gripe for me is this:
One way to get additional software into an image is to create a
custom image. The following example shows the form for the two lines
you need:
IMAGE_INSTALL = task-core-x11-base package1 package2
inherit core-image
no. that is not a way to get additional software into an image, it
is a way to *override* core-image.bbclass's conditional setting of:
IMAGE_INSTALL ?= ${CORE_IMAGE_BASE_INSTALL}
which i think is overly confusing. in general, i'm really unhappy
with the number of image definitions that explicitly set
IMAGE_INSTALL, *then* inherit core-image. the potential to mislead
the reader as to what's happening is really overwhelming.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Eclipse ADT] Eclipse plugin download site is not a valid Eclipse site
The download site http://downloads.yoctoproject.org/releases/eclipse-plugin/1.2.1/indigo/ for the Eclipse plugin is not a correctly setup Eclipse download site. The site root does not have the correct layout for Eclipse to be able to recognize it: site root/ content.jar artifacts.jar features/ feature archives plugins/ plug-in archives binary/ binary artifact archives However, the file org.yocto.sdk-rc1-201206291755-archive.zip looks as if it contains the correct site layout. The file org.yocto.sdk-rc1-201206291755.zip does contain the features and plugins only however time stamps in the file names and file sizes differ from the ones contained in org.yocto.sdk-rc1-201206291755-archive.zip. Could anybody please shed some light on this? Thanks, Rudi ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] of recipes and packages
On 08/22/2012 01:27 PM, Robert P. J. Day wrote: On Wed, 22 Aug 2012, Chris Larson wrote: On Wed, Aug 22, 2012 at 1:15 PM, Trevor Woerner twoer...@gmail.com wrote: On Wed, Aug 22, 2012 at 3:24 PM, Chris Larson clar...@kergoth.com wrote: On Wed, Aug 22, 2012 at 12:23 PM, Trevor Woerner twoer...@gmail.com wrote: bitbake -s doesn't list net-snmp-dbg net-snmp-doc net-snmp-dev... it lists net-snmp. Therefore couldn't the wording of the bitbake help be improved to say: -s, --show-versions show current and preferred versions of all __recipes__ instead of: It could, and should, be changed in that way, yes. Do the OE people accept this wording too, or is this a yocto-project-only thing? In other words, should a potential patch be sent to OE or here? The change would be to a core component, which is part of OE and which yocto pulls in — bitbake. So it would make no sense to send the patch here. No changes to bitbake are going into poky without going into the main bitbake repository. The bitbake-devel mailing list is the correct place for it. there really should be an official glossary somewhere, and it should be backed up with *actual* *examples* from the source as much as possible. that is, don't use foo if there's an existing recipe or package whose use would be more informative. From Jeff's description, it sounded like the package (especially 'package version') comes from the stuff that is the recipe's *input*, and not the recipe's output -- if you've selected to build packages and not just a straight image. Is 'package' also used in that sense, to describe, say, the tarball for busybox before it's processed by bitbake and made into an busybox binary ipkg or rpm? Or am I just muddying the waters further? BTW, on denzil, I get the following: $ bitbake -s | grep busybox busybox :1.19.4-r2 Note that this includes the version of busybox (the input source version), as well as (I think) the recipe revision number. And yes - a definitive glossary would be great. -- Tim = Tim Bird Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment = ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] of recipes and packages
On Wed, Aug 22, 2012 at 4:24 PM, Tim Bird tim.b...@am.sony.com wrote: On 08/22/2012 01:27 PM, Robert P. J. Day wrote: On Wed, 22 Aug 2012, Chris Larson wrote: On Wed, Aug 22, 2012 at 1:15 PM, Trevor Woerner twoer...@gmail.com wrote: On Wed, Aug 22, 2012 at 3:24 PM, Chris Larson clar...@kergoth.com wrote: On Wed, Aug 22, 2012 at 12:23 PM, Trevor Woerner twoer...@gmail.com wrote: bitbake -s doesn't list net-snmp-dbg net-snmp-doc net-snmp-dev... it lists net-snmp. Therefore couldn't the wording of the bitbake help be improved to say: -s, --show-versions show current and preferred versions of all __recipes__ instead of: It could, and should, be changed in that way, yes. Do the OE people accept this wording too, or is this a yocto-project-only thing? In other words, should a potential patch be sent to OE or here? The change would be to a core component, which is part of OE and which yocto pulls in — bitbake. So it would make no sense to send the patch here. No changes to bitbake are going into poky without going into the main bitbake repository. The bitbake-devel mailing list is the correct place for it. there really should be an official glossary somewhere, and it should be backed up with *actual* *examples* from the source as much as possible. that is, don't use foo if there's an existing recipe or package whose use would be more informative. From Jeff's description, it sounded like the package (especially 'package version') comes from the stuff that is the recipe's *input*, and not the recipe's output -- if you've selected to build packages and not just a straight image. Is 'package' also used in that sense, to describe, say, the tarball for busybox before it's processed by bitbake and made into an busybox binary ipkg or rpm? Or am I just muddying the waters further? BTW, on denzil, I get the following: $ bitbake -s | grep busybox busybox :1.19.4-r2 anything you bake using bitbake is a recipe (input rules) which then generates packages (output) and there can be many packages generated from single recipes and one of the name of output package can be same as recipe name. Note that this includes the version of busybox (the input source version), as well as (I think) the recipe revision number. And yes - a definitive glossary would be great. -- Tim = Tim Bird Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment = ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [ADT] Autotools: configure using --with-libtool-sysroot
On Wed, Aug 22, 2012 at 4:22 PM, Rudolf Streif rudolf.str...@linux.com wrote:
I tried, according to the documentation at
http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html#extracting-the-root-filesystem),
to configure and compile the autotooled GNU Hello World Applcation for x86
and ARM with
./configure --host=i586-poky-linux
--with-libtool-sysroot=${YOCTODIR}/adt-sysroots/x86
and
./configure --host=armv5te-poky-linux-gnueabi
--with-libtool-sysroot=${YOCTODIR}/adt-sysroots/arm
As expected configure does not recognize --with-libtool-sysroot: configure:
WARNING: unrecognized options: --with-libtool-sysroot.
Running the suggested commands:
$ libtoolize --automake
$ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \
[-I dir_containing_your_project-specific_m4_macros]
$ autoconf
$ autoheader
$ automake -a
did not make a difference (same error message). However, compiling the
application worked just fine.
Questions:
What exactly is --with-libtool-sysroot supposed to do?
its an option for libtool sysroot support actually it was called --with-sysroot
but it conflicts with gcc and binutils which already had that option
before lib tool added it.
What could be the reason that the steps to update the configure script to
recognize the option do not work?
so I guess if you have new enough libtool this option should be effective
but will be ignored for old libtools (pre 2.4)
Suggestion:
Add --prefix to ./configure --host=armv5te-poky-linux-gnueabi
--with-libtool-sysroot=sysrootdir --prefix=sysrootdir/prefix so that
make install actually installs into the system root.
:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [ADT] Sysroot setup issue
Hi Rudi,
I'm currently on vacation so have very limited access to my YP setup. We've
been using the sysroot and nfs like below to start qemu after adt-installation,
can you give it a try to see whether there's problem or not?
Runqemu youradtinstallerdir/download_image/bzImage-qemux86.bin
${HOME}/test-yocto/x86
Scott,
Can you help answer or look into the boot dir missing kernel file issue that
Rudi's reporting to see whether it's a bug on our end?
Thanks,
Jessica
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Rudolf Streif
Sent: Tuesday, August 21, 2012 1:17 PM
To: yocto@yoctoproject.org
Subject: [yocto] [ADT] Sysroot setup issue
Hi,
I am trying to setup the ADT using an ADT installer. I have downloaded the
installer from
http://downloads.yoctoproject.org/releases/yocto/yocto-1.2.1/adt_installer/ as
well as created my own installer using a build environment with Denzil 7.0.1.
The adt_installer.conf contains these settings:
YOCTOADT_REPO=http://adtrepo.yoctoproject.org/1.2.1;
YOCTOADT_TARGETS=arm x86
YOCTOADT_QEMU=Y
YOCTOADT_NFS_UTIL=Y
YOCTOADT_ROOTFS_arm=minimal
YOCTOADT_TARGET_SYSROOT_IMAGE_arm=minimal
YOCTOADT_TARGET_SYSROOT_LOC_arm=$HOME/test-yocto/arm
YOCTOADT_ROOTFS_x86=minimal
YOCTOADT_TARGET_SYSROOT_IMAGE_x86=minimal
YOCTOADT_TARGET_SYSROOT_LOC_x86=$HOME/test-yocto/x86
The installer downloads kernel and root fs images. After the installation has
finished
${HOME}/test-yocto/arm/boot does not contain any kernel images and
${HOME}/test-yocto/x86/boot only contains a empty link bzImage -
bzImage-3.2.18-yocto-standard
I manually copied the x86 kernel image bzImage-qemux86.bin from the
download_image directory of the extracted installer tarball into the directory,
initialized the ADT environment and then ran
runqemu ${HOME}/test-yocto/x86/boot/bzImage-qemux86.bin ${HOME}/test-yocto/x86
The NFS user-space server initializes on the tap0 interface and the kernel
boots. However, it panics because it cannot locate the root fs. rpcbind is
started with the -i option on my system.
I also ran QEMU directly using:
/opt/poky/1.2.1/sysroots/x86_64-pokysdk-linux/usr/bin/qemu -kernel
/home/rudi/test-yocto/x86/boot/bzImage-qemux86.bin -show-cursor -usb -usbdevice
wacom-tablet -vga vmware -enable-gl -no-reboot -m 128 --append root=/dev/nfs
nfsroot=192.168.100.199http://192.168.100.199://home/rudi/test-yocto/x86 rw
ip=192.168.100.38::192.168.100.199:255.255.255.0 mem=128M oprofile.timer=1
with my dev system's NFS server running and exporting the file system (I
verified that I can mount the exported file system via NFS).
Questions:
1. Why do the sysroot boot directory not contain any kernel images? I
don't think that is what it is supposed to be.
2. Is there anything broken with the sysroot causing the boot process to
fail when the kernel tries to access the root fs?
3. Any hints on how to fix it?
Thanks,
Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Eclipse ADT] Eclipse plugin download site is not a valid Eclipse site
On Wed, Aug 22, 2012 at 4:00 PM, Rudolf Streif rudolf.str...@linux.comwrote: The download site http://downloads.yoctoproject.org/releases/eclipse-plugin/1.2.1/indigo/ for the Eclipse plugin is not a correctly setup Eclipse download site. The site root does not have the correct layout for Eclipse to be able to recognize it: site root/ content.jar artifacts.jar features/ feature archives plugins/ plug-in archives binary/ binary artifact archives However, the file org.yocto.sdk-rc1-201206291755-archive.zip looks as if it contains the correct site layout. The file org.yocto.sdk-rc1-201206291755.zip does contain the features and plugins only however time stamps in the file names and file sizes differ from the ones contained in org.yocto.sdk-rc1-201206291755-archive.zip. Could anybody please shed some light on this? Thanks for catching this, Rudolf. I've corrected this and have added a bug entry against the release scripts. -b Thanks, Rudi ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [ADT] Sysroot setup issue
Hi Jessica,
Thanks while responding while on vacation.
No worries. I have resolved the NFS boot issue. I entirely missed that my
dev system had a firewall running blocking ports 3048 and 3049 used by the
user-space rpc.mountd and rpc.nfsd daemons that runquemu-export-rootfs sets
up. My fault. Sorry about that.
The kernel images may be an incorrect expectation from my side. I checked
the ADT installer scripts and they do not seem to do anything with the
kernel images they download. From my point of view it would make sense to
copy them into sysroot/boot.
The adt_installer.conf file suggests that minimal, minimal-dev, sato,
sato-dev, sato-sdk,lsb, lsb-dev, lsb-sdk are valid images
for YOCTOADT_ROOTFS_arch, but really only the *-dev and *-sdk images make
sense for an ADT as the others are missing the dev headers and libs.
While the ADT installer downloads all the image files specified in
YOCTOADT_ROOTFS_arch it really only extracts the one specified
by YOCTOADT_TARGET_SYSROOT_IMAGE_arch into the location specified
by YOCTOADT_TARGET_SYSROOT_LOC_arch. If you keep the installer files
around you can of course later install them with runqemu-extract-sdk but
that's not necessarily intuitive.
I eventually extracted all the sysroot images into separate directories and
created a link to the one I wanted to use with the name specified
by YOCTOADT_TARGET_SYSROOT_LOC_arch. That works well.
I don't know what the overall direction of development for the ADT
installer is but I could make some patches to address these items if that
makes sense to the community.
:rjs
On Wed, Aug 22, 2012 at 5:16 PM, Zhang, Jessica jessica.zh...@intel.comwrote:
Hi Rudi,
** **
I’m currently on vacation so have very limited access to my YP setup.
We’ve been using the sysroot and nfs like below to start qemu after
adt-installation, can you give it a try to see whether there’s problem or
not?
** **
Runqemu youradtinstallerdir/download_image/bzImage-qemux86.bin
${HOME}/test-yocto/x86
** **
** **
Scott,
** **
Can you help answer or look into the boot dir missing kernel file issue
that Rudi’s reporting to see whether it’s a bug on our end?
** **
Thanks,
Jessica
** **
*From:* yocto-boun...@yoctoproject.org [mailto:
yocto-boun...@yoctoproject.org] *On Behalf Of *Rudolf Streif
*Sent:* Tuesday, August 21, 2012 1:17 PM
*To:* yocto@yoctoproject.org
*Subject:* [yocto] [ADT] Sysroot setup issue
** **
Hi,
** **
I am trying to setup the ADT using an ADT installer. I have downloaded the
installer from
http://downloads.yoctoproject.org/releases/yocto/yocto-1.2.1/adt_installer/ as
well as created my own installer using a build environment with Denzil
7.0.1.
** **
The adt_installer.conf contains these settings:
** **
YOCTOADT_REPO=http://adtrepo.yoctoproject.org/1.2.1
YOCTOADT_TARGETS=arm x86
YOCTOADT_QEMU=Y
YOCTOADT_NFS_UTIL=Y
** **
YOCTOADT_ROOTFS_arm=minimal
YOCTOADT_TARGET_SYSROOT_IMAGE_arm=minimal
YOCTOADT_TARGET_SYSROOT_LOC_arm=$HOME/test-yocto/arm
** **
YOCTOADT_ROOTFS_x86=minimal
YOCTOADT_TARGET_SYSROOT_IMAGE_x86=minimal
YOCTOADT_TARGET_SYSROOT_LOC_x86=$HOME/test-yocto/x86
** **
The installer downloads kernel and root fs images. After the installation
has finished
** **
${HOME}/test-yocto/arm/boot does not contain any kernel images and
** **
${HOME}/test-yocto/x86/boot only contains a empty link bzImage -
bzImage-3.2.18-yocto-standard
** **
I manually copied the x86 kernel image bzImage-qemux86.bin from the
download_image directory of the extracted installer tarball into the
directory, initialized the ADT environment and then ran
** **
runqemu ${HOME}/test-yocto/x86/boot/bzImage-qemux86.bin ${HOME}/test-yocto/x86
** **
The NFS user-space server initializes on the tap0 interface and the kernel
boots. However, it panics because it cannot locate the root fs. rpcbind is
started with the -i option on my system.
** **
I also ran QEMU directly using:
** **
/opt/poky/1.2.1/sysroots/x86_64-pokysdk-linux/usr/bin/qemu -kernel
/home/rudi/test-yocto/x86/boot/bzImage-qemux86.bin -show-cursor -usb
-usbdevice wacom-tablet -vga vmware -enable-gl -no-reboot -m 128 --append
root=/dev/nfs nfsroot=192.168.100.199://home/rudi/test-yocto/x86 rw
ip=192.168.100.38::192.168.100.199:255.255.255.0 mem=128M
oprofile.timer=1
** **
with my dev system's NFS server running and exporting the file system (I
verified that I can mount the exported file system via NFS).
** **
Questions:
1. Why do the sysroot boot directory not contain any kernel images? I
don't think that is what it is supposed to be.
2. Is there anything broken with the sysroot causing the boot process
to fail when the kernel tries to access the root fs?
3. Any hints on how to fix it?
Thanks,
Rudi
** **
Re: [yocto] [ADT] Sysroot setup issue
Hi Rudi,
Good to hear that you've resolved your issue. For the kernel issue, would you
mind to file a bug (enhancement) in our bugzilla for us to track? As to
adt-installer, it is meant to be an alternative way for people to setup their
cross development environment, so patches are always welcome, esp. from
community. The few things you've pointed out are all good and valid that worth
to improve.
Thanks,
Jessica
From: rstr...@linuxfoundation.org [mailto:rstr...@linuxfoundation.org] On
Behalf Of Rudolf Streif
Sent: Wednesday, August 22, 2012 5:37 PM
To: Zhang, Jessica
Cc: yocto@yoctoproject.org; Garman, Scott A
Subject: Re: [yocto] [ADT] Sysroot setup issue
Hi Jessica,
Thanks while responding while on vacation.
No worries. I have resolved the NFS boot issue. I entirely missed that my dev
system had a firewall running blocking ports 3048 and 3049 used by the
user-space rpc.mountd and rpc.nfsd daemons that runquemu-export-rootfs sets up.
My fault. Sorry about that.
The kernel images may be an incorrect expectation from my side. I checked the
ADT installer scripts and they do not seem to do anything with the kernel
images they download. From my point of view it would make sense to copy them
into sysroot/boot.
The adt_installer.conf file suggests that minimal, minimal-dev, sato, sato-dev,
sato-sdk,lsb, lsb-dev, lsb-sdk are valid images for YOCTOADT_ROOTFS_arch, but
really only the *-dev and *-sdk images make sense for an ADT as the others are
missing the dev headers and libs.
While the ADT installer downloads all the image files specified in
YOCTOADT_ROOTFS_arch it really only extracts the one specified by
YOCTOADT_TARGET_SYSROOT_IMAGE_arch into the location specified by
YOCTOADT_TARGET_SYSROOT_LOC_arch. If you keep the installer files around you
can of course later install them with runqemu-extract-sdk but that's not
necessarily intuitive.
I eventually extracted all the sysroot images into separate directories and
created a link to the one I wanted to use with the name specified by
YOCTOADT_TARGET_SYSROOT_LOC_arch. That works well.
I don't know what the overall direction of development for the ADT installer is
but I could make some patches to address these items if that makes sense to the
community.
:rjs
On Wed, Aug 22, 2012 at 5:16 PM, Zhang, Jessica
jessica.zh...@intel.commailto:jessica.zh...@intel.com wrote:
Hi Rudi,
I'm currently on vacation so have very limited access to my YP setup. We've
been using the sysroot and nfs like below to start qemu after adt-installation,
can you give it a try to see whether there's problem or not?
Runqemu youradtinstallerdir/download_image/bzImage-qemux86.bin
${HOME}/test-yocto/x86
Scott,
Can you help answer or look into the boot dir missing kernel file issue that
Rudi's reporting to see whether it's a bug on our end?
Thanks,
Jessica
From: yocto-boun...@yoctoproject.orgmailto:yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.orgmailto:yocto-boun...@yoctoproject.org]
On Behalf Of Rudolf Streif
Sent: Tuesday, August 21, 2012 1:17 PM
To: yocto@yoctoproject.orgmailto:yocto@yoctoproject.org
Subject: [yocto] [ADT] Sysroot setup issue
Hi,
I am trying to setup the ADT using an ADT installer. I have downloaded the
installer from
http://downloads.yoctoproject.org/releases/yocto/yocto-1.2.1/adt_installer/ as
well as created my own installer using a build environment with Denzil 7.0.1.
The adt_installer.conf contains these settings:
YOCTOADT_REPO=http://adtrepo.yoctoproject.org/1.2.1;
YOCTOADT_TARGETS=arm x86
YOCTOADT_QEMU=Y
YOCTOADT_NFS_UTIL=Y
YOCTOADT_ROOTFS_arm=minimal
YOCTOADT_TARGET_SYSROOT_IMAGE_arm=minimal
YOCTOADT_TARGET_SYSROOT_LOC_arm=$HOME/test-yocto/arm
YOCTOADT_ROOTFS_x86=minimal
YOCTOADT_TARGET_SYSROOT_IMAGE_x86=minimal
YOCTOADT_TARGET_SYSROOT_LOC_x86=$HOME/test-yocto/x86
The installer downloads kernel and root fs images. After the installation has
finished
${HOME}/test-yocto/arm/boot does not contain any kernel images and
${HOME}/test-yocto/x86/boot only contains a empty link bzImage -
bzImage-3.2.18-yocto-standard
I manually copied the x86 kernel image bzImage-qemux86.bin from the
download_image directory of the extracted installer tarball into the directory,
initialized the ADT environment and then ran
runqemu ${HOME}/test-yocto/x86/boot/bzImage-qemux86.bin ${HOME}/test-yocto/x86
The NFS user-space server initializes on the tap0 interface and the kernel
boots. However, it panics because it cannot locate the root fs. rpcbind is
started with the -i option on my system.
I also ran QEMU directly using:
/opt/poky/1.2.1/sysroots/x86_64-pokysdk-linux/usr/bin/qemu -kernel
/home/rudi/test-yocto/x86/boot/bzImage-qemux86.bin -show-cursor -usb -usbdevice
wacom-tablet -vga vmware -enable-gl -no-reboot -m 128 --append root=/dev/nfs
nfsroot=192.168.100.199http://192.168.100.199://home/rudi/test-yocto/x86 rw
Re: [yocto] adding packages in my Yocto
Thanks to you all for helping me out there. On Tue, Aug 21, 2012 at 9:51 PM, Stewart, David C david.c.stew...@intel.com wrote: Good advice. A quick check of openembedded-core shows that gst-ffmpeg appears to be one of the packages available. Yes, definitely check the hob. -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Jeff Osier-Mixon Sent: Tuesday, August 21, 2012 9:01 AM To: aaryak gautam Cc: Yocto Project Subject: Re: [yocto] adding packages in my Yocto Hi - please take a look at the FAQ here: https://wiki.yoctoproject.org/wiki/FAQ Near the bottom there are some technical answers, one of which is how to add a single package: Q: How can I add a package to my project? A: As with any complex system, the real answer is it depends, but of course that is not very helpful. The simplest method for adding a single package to your build is to add a line like this to conf/local.conf: IMAGE_INSTALL_append += package Use your own package name in place of package. Note the leading space before the package name. For more information, read this chapter in the Yocto Project Development Manual (http://www.yoctoproject.org/docs/current/dev-manual/dev- manual.html#usingpoky-extend-addpkg). I also highly recommend trying out the Hob interface, as it makes the whole system easier to understand. I like to make changes in the Hob and then examine those changes in the resulting configuration files to better understand the system at work. Hope this helps! On Tue, Aug 21, 2012 at 1:26 AM, aaryak gautam aaryak.gau...@gmail.com wrote: Hello I am a hobbyist and quite new to both Linux and Yocto. I had already compiled my Yocto kernel for I.MX23 successfully. But I want to add few packages. Like if i want to have ffmpeg in my yocto,how should I add it? I have gone through the documentation,but could not understand. can you help me out? I am using Bitbake core-image-minimal , not sato. Thank You. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
