[yocto] [CONSOLIDATED PULL (meta-yocto) 0/4]
Richard, This is the meta-yocto patches that coordiate with the oe-core changes you have already pulled. Sau! The following changes since commit f3a1a8897c78e116d7d28947a85687d0ce9d7df7: pseudo: ensure libs are included in package (2012-01-03 12:14:41 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib sgw/stage http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgw/stage Bruce Ashfield (2): linux-yocto/meta-yocto: routerstationpro/beagleboard: add 3.0.x support linux-yocto-rt/meta-yocto: add routerstationpro support Darren Hart (2): distro: Add POKY_DEFAULT_EXTRA_R* variables distro: Add poky-tiny distro definition meta-yocto/conf/distro/poky-tiny.conf | 103 meta-yocto/conf/distro/poky.conf |8 +- meta-yocto/conf/machine/beagleboard.conf |1 + meta-yocto/conf/machine/routerstationpro.conf |1 + .../linux/linux-yocto-rt_3.0.bbappend |8 +- .../recipes-kernel/linux/linux-yocto_3.0.bbappend |8 +- 6 files changed, 119 insertions(+), 10 deletions(-) create mode 100644 meta-yocto/conf/distro/poky-tiny.conf -- 1.7.6.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [CONSOLIDATED PULL (meta-yocto) 1/4] linux-yocto/meta-yocto: routerstationpro/beagleboard: add 3.0.x support
From: Bruce Ashfield Updating the routerstationpro and beagleboard compatibility and SRCREV to pickup v3.0.12 support. Signed-off-by: Bruce Ashfield --- meta-yocto/conf/machine/beagleboard.conf |1 + meta-yocto/conf/machine/routerstationpro.conf |1 + .../recipes-kernel/linux/linux-yocto_3.0.bbappend |8 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/meta-yocto/conf/machine/beagleboard.conf b/meta-yocto/conf/machine/beagleboard.conf index 4d21388..dd549d0 100644 --- a/meta-yocto/conf/machine/beagleboard.conf +++ b/meta-yocto/conf/machine/beagleboard.conf @@ -32,6 +32,7 @@ EXTRA_IMAGECMD_jffs2 = "-lnp " SERIAL_CONSOLE = "115200 ttyO2" PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" +PREFERRED_VERSION_linux-yocto ?= "3.0%" KERNEL_IMAGETYPE = "uImage" diff --git a/meta-yocto/conf/machine/routerstationpro.conf b/meta-yocto/conf/machine/routerstationpro.conf index 9338ca1..83c2f8a 100644 --- a/meta-yocto/conf/machine/routerstationpro.conf +++ b/meta-yocto/conf/machine/routerstationpro.conf @@ -11,6 +11,7 @@ KERNEL_IMAGETYPE = "vmlinux" 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" diff --git a/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend b/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend index 4f68bc1..e510880 100644 --- a/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend +++ b/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend @@ -5,11 +5,11 @@ KMACHINE_beagleboard = "yocto/standard/beagleboard" SRCREV_machine_atom-pc ?= "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0" -SRCREV_machine_routerstationpro ?= "ed0e03a8b04388a982141919da805392b7ca1c91" +SRCREV_machine_routerstationpro ?= "8f38705810634a84326d3a3ebe9653951aa4bf61" SRCREV_machine_mpc8315e-rdb ?= "58ffdb8000e34d2ba7c3ef278b26680b0886e8b5" -SRCREV_machine_beagleboard ?= "2bba211297d10047637b8f49abd2c5415480ce4d" +SRCREV_machine_beagleboard ?= "6b4bf6173b0bd2d1619a8218bac66ebc4681dd35" COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb" -# COMPATIBLE_MACHINE_routerstationpro = "routerstationpro" -# COMPATIBLE_MACHINE_beagleboard = "beagleboard" +COMPATIBLE_MACHINE_routerstationpro = "routerstationpro" +COMPATIBLE_MACHINE_beagleboard = "beagleboard" COMPATIBLE_MACHINE_atom-pc = "atom-pc" -- 1.7.6.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [CONSOLIDATED PULL (meta-yocto) 2/4] linux-yocto-rt/meta-yocto: add routerstationpro support
From: Bruce Ashfield Fixes [YOCTO #1390] Updated the meta-yocto support for the routerstationpro on the preempt-rt kernel support. Signed-off-by: Bruce Ashfield --- .../linux/linux-yocto-rt_3.0.bbappend |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/meta-yocto/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend b/meta-yocto/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend index ab0f24c..831df8d 100644 --- a/meta-yocto/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend +++ b/meta-yocto/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend @@ -19,7 +19,7 @@ SRCREV_machine_pn-linux-yocto-rt_mpc8315e-rdb = "0b805cce57f61a244eb3b8fce460b14 #SRCREV_machine_pn-linux-yocto-rt_beagleboard = # routerstationpro support - preempt-rt kernel build failure -#COMPATIBLE_MACHINE_routerstationpro = "routerstationpro" -#KMACHINE_routerstationpro = "routerstationpro" -#KBRANCH_routerstationpro = "yocto/standard/preempt-rt/base" -#SRCREV_machine_pn-linux-yocto-rt_routerstationpro = "7e1e5b6c8a13c615feb0d7b6d37988a094aae98f" +COMPATIBLE_MACHINE_routerstationpro = "routerstationpro" +KMACHINE_routerstationpro = "routerstationpro" +KBRANCH_routerstationpro = "yocto/standard/preempt-rt/routerstationpro" +SRCREV_machine_pn-linux-yocto-rt_routerstationpro = "43dcdffebb64d9ce2f5cdcb18bb74bd9c301133f" -- 1.7.6.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [CONSOLIDATED PULL (meta-yocto) 3/4] distro: Add POKY_DEFAULT_EXTRA_R* variables
From: Darren Hart
Allow the reuse of poky.conf by distro definitions wanting to remove
content by introducting POKY_DEFAULT_EXTRA_R*. These are appended
to the corresponding DISTRO_EXTRA_R* variables and can be overriden
by distro configs that "require poky.conf".
Signed-off-by: Darren Hart
---
meta-yocto/conf/distro/poky.conf |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta-yocto/conf/distro/poky.conf b/meta-yocto/conf/distro/poky.conf
index 80d4e47..86f9bf6 100644
--- a/meta-yocto/conf/distro/poky.conf
+++ b/meta-yocto/conf/distro/poky.conf
@@ -24,8 +24,12 @@ SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
EXTRAOPKGCONFIG = "poky-feed-config-opkg"
-DISTRO_EXTRA_RDEPENDS += "task-core-boot"
-DISTRO_EXTRA_RRECOMMENDS += "kernel-module-af-packet"
+# Override these in poky based distros to modify DISTRO_EXTRA_R*
+POKY_DEFAULT_EXTRA_RDEPENDS = "task-core-boot"
+POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
+
+DISTRO_EXTRA_RDEPENDS += " ${POKY_DEFAULT_EXTRA_RDEPENDS}"
+DISTRO_EXTRA_RRECOMMENDS += " ${POKY_DEFAULT_EXTRA_RRECOMMENDS}"
POKYQEMUDEPS = "${@base_contains("INCOMPATIBLE_LICENSE", "GPLv3", "",
"qemu-config",d)}"
DISTRO_EXTRA_RDEPENDS_append_qemuarm = " ${POKYQEMUDEPS}"
--
1.7.6.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [CONSOLIDATED PULL (meta-yocto) 4/4] distro: Add poky-tiny distro definition
From: Darren Hart
Poky-tiny is intended for building very small OS images. The distro
definition sets the providers for the kernel and the runtime services.
It also reduces the eglibc component list and other DISTRO_FEATURE
elements.
Signed-off-by: Darren Hart
---
meta-yocto/conf/distro/poky-tiny.conf | 103 +
1 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 meta-yocto/conf/distro/poky-tiny.conf
diff --git a/meta-yocto/conf/distro/poky-tiny.conf
b/meta-yocto/conf/distro/poky-tiny.conf
new file mode 100644
index 000..49c4397
--- /dev/null
+++ b/meta-yocto/conf/distro/poky-tiny.conf
@@ -0,0 +1,103 @@
+# Distribution definition for: poky-tiny
+#
+# Copyright (c) 2011, Intel Corporation.
+# All rights reserved.
+#
+# Poky-tiny is intended to define a tiny Linux system comprised of a
+# Linux kernel tailored to support each specific MACHINE and busybox.
+# Poky-tiny sets some basic policy to ensure a usable system while still
+# keeping the rootfs and kernel image as small as possible.
+#
+# The policies defined are intended to meet the following goals:
+# o Serial consoles only (no framebuffer or VGA console)
+# o Basic support for IPV4 networking
+# o Single user ash shell
+# o Static images (no support for adding packages or libraries later)
+# o Read-only or RAMFS root filesystem
+# o Combined Linux kernel + rootfs in under 4MB
+# o Allow the user to select between eglibc or uclibc with the TCLIBC variable
+#
+# This is currently a partial definition, the following tasks remain:
+# [ ] Integrate linux-yocto-tiny ktype into linux-yocto
+# [ ] Define linux-yocto-tiny configs for all supported BSPs
+# [ ] Drop ldconfig from the installation
+# [ ] Modify the runqemu scripts to work with ext2 parameter:
+# runqemu qemux86 qemuparams="-nographic" bootparams="console=ttyS0,115200
root=0800"
+# [ ] Modify busybox to allow for DISTRO_FEATURES-like confiruration
+
+require conf/distro/poky.conf
+DISTRO = "poky-tiny"
+
+# FIXME: consider adding a new "tiny" feature
+#DISTRO_FEATURES_append = " tiny"
+
+# Distro config is evaluated after the machine config, so we have to explicitly
+# set the kernel provider to override a machine config.
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
+PREFERRED_VERSION_linux-yocto-tiny = "3.0%"
+
+# We can use task-core-boot, but in the future we may need a new task-core-tiny
+#POKY_DEFAULT_EXTRA_RDEPENDS += "task-core-boot"
+# Drop kernel-module-af-packet from RRECOMMENDS
+POKY_DEFAULT_EXTRA_RRECOMMENDS = ""
+
+# FIXME: what should we do with this?
+TCLIBCAPPEND = ""
+
+# Disable wide char support for ncurses as we don't include it in
+# in the LIBC features below.
+ENABLE_WIDEC="false"
+
+# Reconfigure eglibc for a smaller installation
+# Comment out any of the lines below to disable them in the build
+DISTRO_FEATURES_LIBC_TINY = "libc-libm libc-crypt"
+# Required for "who"
+DISTRO_FEATURES_LIBC_MINIMAL = "libc-utmp libc-getlogin"
+DISTRO_FEATURES_LIBC_REGEX = "libc-posix-regexp"
+DISTRO_FEATURES_LIBC_NET = "libc-inet libc-nis"
+
+DISTRO_FEATURES_LIBC = "${DISTRO_FEATURES_LIBC_TINY} \
+${DISTRO_FEATURES_LIBC_MINIMAL} \
+${DISTRO_FEATURES_LIBC_REGEX} \
+${DISTRO_FEATURES_LIBC_NET} \
+ "
+
+# Comment out any of the lines below to disable them in the build
+# DISTRO_FEATURES options:
+# alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs zeroconf pci
+DISTRO_FEATURES_TINY = "pci"
+DISTRO_FEATURES_NET = "ipv4"
+DISTRO_FEATURES_USB = "usbhost"
+#DISTRO_FEATURES_USBGADGET = "usbgadget"
+#DISTRO_FEATURES_WIFI = "wifi"
+
+DISTRO_FEATURES = "${DISTRO_FEATURES_TINY} \
+ ${DISTRO_FEATURES_NET} \
+ ${DISTRO_FEATURES_USB} \
+ ${DISTRO_FEATURES_USBGADGET} \
+ ${DISTRO_FEATURES_WIFI} \
+ ${DISTRO_FEATURES_LIBC} \
+ "
+
+# Use tmpdevfs and the busybox runtime services
+VIRTUAL-RUNTIME_dev_manager = ""
+VIRTUAL-RUNTIME_login_manager = ""
+VIRTUAL-RUNTIME_init_manager = ""
+VIRTUAL-RUNTIME_keymaps = ""
+
+# FIXME: Consider adding "modules" to MACHINE_FEATURES and using that in
+# task-core-base to select modutils-initscripts or not. Similar with "net" and
+# netbase.
+
+# By default we only support ext2 and initramfs. We don't build live as that
+# pulls in a lot of dependencies for the live image and the installer, like
+# udev, grub, etc. These pull in gettext, which fails to build with wide
+# character support.
+IMAGE_FSTYPES = "ext2 cpio.gz"
+
+# Drop v86d from qemu dependency list (we support serial)
+# Drop grub from meta-intel BSPs
+# FIXME: A different mechanism is needed here. We could define -tiny
+#variants of all compatible machines, but that leads to a lot
+#more machine configs to maintain long term.
+MACHINE_ESSENTIAL_EXTRA_RDEPENDS = ""
--
1.7.6.4
_
Re: [yocto] build error on meta-cedarview
On 12/29/2011 11:37 AM, Saul Wold wrote: On 12/28/2011 09:26 PM, Andrew Schweitzer wrote: Jim Abernathy writes: While running a build of the core-image-sato using the edison latest commits and the meta-cedartrail bsp, I notices some errors fly by and thought I'd see if anyone knows the reason. The build is just to test the bsp with no changes. Basically, doing the Appendix A of the Development manual substituting cedartrail for crownbay. snippet of the console log below: NOTE: package icon-naming-utils-native-0.8.7-r3: task do_unpack: Started ERROR: Function 'Unpack failure for URL: 'http://tango.freedesktop.org/releases/icon-naming-utils-0.8.7.tar.gz'. I don't know the reason, but I did get the same error when trying to build yocto per the getting started page, changing local.conf to create qemuarm I would be interested in knowing the reason too. There has been a bug filed against this issue, it seems that the tarballs have moved or are unavailable from that location for some reason. You are getting a download page, and I believe that the failure should occur earlier with a checksum mismatch, but is not. You can fetch this file from our mirror at: http://downloads.yoctoproject.org/mirror/sources/icon-naming-utils-0.8.7.tar.gz Saul, Sorry for the dumb question, but how do I download the file and fool bitbake into not trying to download it from the invalid site? Or do I need to change a file somewhere to specific our mirror URL instead?? Jim A Sau! Andy ___ 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Technical Team Meeting - Tuesday, January 03, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada)
Attendees: Paul, Beth, Josh, Richard, Scott, Mark, Jessica, Saul, Bruce, Matthew, Song New Action Item: - Mark will review unsorted features from Wind River team and try to have them scheduled (WIP, Reviewed, but not scheduled yet.) - Song and Saul to follow on Scott Garman's M2 schedule conflict. (WIP, need to talk with Dave) - Paul to work with Jeremy and others to move 1598 forward. (WIP) - Paul to split feature 1566. Agenda: * Opens collection - 5 min (Song) * Yocto 1.1.1 point release update - 10 min (Josh) - Got the build out before Christmas, QA test passed. One outstanding issue. Have a promising solution now. Pulling together some other minor fixes. Need to talk with Beth - Scott: do we need to update manual? - Beth will setup a meeting with Josh and Scott to determine the next build for QA and possible doc changes. * Yocto 1.2 M2 status and major kernel/toolchain version lock - 10 min (Song/Bruce/Team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.2_Status - 4th week of M2, next week we will have RC1. more than half of the features are in progress, some in patch review, some is lacking QA effort, about 40% still has no progress. Paul and ScottG's P1's are at risk. - Paul will split P1 feature 1655 into deliverables for both M2 and M3. - Master build is green by the new year's day. Integrating patches now. - bugs are in control with about 15 new bugs opened and about the same amount fixed after Christmas. - Major kernel version lock: Kernel - 3.2.x with RT release. Tool Chain - set with the versions now, gcc 4.6, minor patches possible, but no more major version change. - M2 release criteria review (Reviewed and updated on the wiki page) * Opens - 10 min - RP: email status: had a disaster over holiday, lost all emails, recovered most of them. Reponses were delayed. * Action item Review - 5 min - Mark will review unsorted features from Wind River team and try to have them scheduled (WIP, Reviewed, but not scheduled yet.) - Song and Saul to follow on Scott Garman's M2 schedule conflict. (WIP, need to talk with Dave) - Paul to work with Jeremy and others to move 1598 forward. (WIP) * Team Sharing (shared some holiday stories, skip due to holidays) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [CONSOLIDATED PULL (meta-yocto) 0/4]
On Tue, 2012-01-03 at 08:18 -0800, Saul Wold wrote: > Richard, > > This is the meta-yocto patches that coordiate with the oe-core changes > you have already pulled. > > Sau! > > The following changes since commit f3a1a8897c78e116d7d28947a85687d0ce9d7df7: > > pseudo: ensure libs are included in package (2012-01-03 12:14:41 +) > > are available in the git repository at: > git://git.yoctoproject.org/poky-contrib sgw/stage > http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgw/stage > > Bruce Ashfield (2): > linux-yocto/meta-yocto: routerstationpro/beagleboard: add 3.0.x > support > linux-yocto-rt/meta-yocto: add routerstationpro support > > Darren Hart (2): > distro: Add POKY_DEFAULT_EXTRA_R* variables > distro: Add poky-tiny distro definition Merged to master, thanks. Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] clutter-1.6: make build for armv4t
On 28/12/11 11:46, Wolfgang Denk wrote: Dear Matthew, In message you wrote: On Thu, Dec 22, 2011 at 3:21 AM, Wolfgang Denk wrote: GCC will define __ARM_ARCH_4T__ when building with "-march=3Darmv4t" so we can check this to turn off the use of 'clz' instructions, which otherwise would cause compile errors like "selected processor does not support ARM mode `clz r3,r0'". ... This version was dropped recently... Is this possibly for the 1.1.1 edison release? If so, I would CC: Joshua Lock. yes, this patch was for the edison series (mainline has updated to clutter-1.8 in the meantime). Wolfgang, I've pulled this patch into my edison branch. Unless you object I'll also apply the patch for cogl in master and send it upstream. Thanks, Joshua -- Joshua Lock Yocto Project "Johannes factotum" Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/3] distro: Add poky-tiny distro definition
On Wed, Dec 28, 2011 at 3:45 PM, Darren Hart wrote:
> Poky-tiny is intended for building very small OS images. The distro
> definition sets the providers for the kernel and the runtime services.
> It also reduces the eglibc component list and other DISTRO_FEATURE
> elements.
>
> Signed-off-by: Darren Hart
> ---
> meta-yocto/conf/distro/poky-tiny.conf | 103
> +
> 1 files changed, 103 insertions(+), 0 deletions(-)
> create mode 100644 meta-yocto/conf/distro/poky-tiny.conf
>
> diff --git a/meta-yocto/conf/distro/poky-tiny.conf
> b/meta-yocto/conf/distro/poky-tiny.conf
> new file mode 100644
> index 000..49c4397
> --- /dev/null
> +++ b/meta-yocto/conf/distro/poky-tiny.conf
> @@ -0,0 +1,103 @@
> +# Distribution definition for: poky-tiny
> +#
> +# Copyright (c) 2011, Intel Corporation.
> +# All rights reserved.
> +#
should this be MIT licensed ?
or do u plan to keep it closed.
> +# Poky-tiny is intended to define a tiny Linux system comprised of a
> +# Linux kernel tailored to support each specific MACHINE and busybox.
> +# Poky-tiny sets some basic policy to ensure a usable system while still
> +# keeping the rootfs and kernel image as small as possible.
> +#
> +# The policies defined are intended to meet the following goals:
> +# o Serial consoles only (no framebuffer or VGA console)
> +# o Basic support for IPV4 networking
> +# o Single user ash shell
> +# o Static images (no support for adding packages or libraries later)
> +# o Read-only or RAMFS root filesystem
> +# o Combined Linux kernel + rootfs in under 4MB
> +# o Allow the user to select between eglibc or uclibc with the TCLIBC
> variable
> +#
> +# This is currently a partial definition, the following tasks remain:
> +# [ ] Integrate linux-yocto-tiny ktype into linux-yocto
> +# [ ] Define linux-yocto-tiny configs for all supported BSPs
> +# [ ] Drop ldconfig from the installation
> +# [ ] Modify the runqemu scripts to work with ext2 parameter:
> +# runqemu qemux86 qemuparams="-nographic"
> bootparams="console=ttyS0,115200 root=0800"
> +# [ ] Modify busybox to allow for DISTRO_FEATURES-like confiruration
> +
> +require conf/distro/poky.conf
> +DISTRO = "poky-tiny"
> +
> +# FIXME: consider adding a new "tiny" feature
> +#DISTRO_FEATURES_append = " tiny"
> +
> +# Distro config is evaluated after the machine config, so we have to
> explicitly
> +# set the kernel provider to override a machine config.
> +PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
> +PREFERRED_VERSION_linux-yocto-tiny = "3.0%"
> +
> +# We can use task-core-boot, but in the future we may need a new
> task-core-tiny
> +#POKY_DEFAULT_EXTRA_RDEPENDS += "task-core-boot"
> +# Drop kernel-module-af-packet from RRECOMMENDS
> +POKY_DEFAULT_EXTRA_RRECOMMENDS = ""
> +
> +# FIXME: what should we do with this?
> +TCLIBCAPPEND = ""
> +
> +# Disable wide char support for ncurses as we don't include it in
> +# in the LIBC features below.
> +ENABLE_WIDEC="false"
> +
> +# Reconfigure eglibc for a smaller installation
> +# Comment out any of the lines below to disable them in the build
> +DISTRO_FEATURES_LIBC_TINY = "libc-libm libc-crypt"
> +# Required for "who"
> +DISTRO_FEATURES_LIBC_MINIMAL = "libc-utmp libc-getlogin"
> +DISTRO_FEATURES_LIBC_REGEX = "libc-posix-regexp"
> +DISTRO_FEATURES_LIBC_NET = "libc-inet libc-nis"
> +
> +DISTRO_FEATURES_LIBC = "${DISTRO_FEATURES_LIBC_TINY} \
> + ${DISTRO_FEATURES_LIBC_MINIMAL} \
> + ${DISTRO_FEATURES_LIBC_REGEX} \
> + ${DISTRO_FEATURES_LIBC_NET} \
> + "
> +
> +# Comment out any of the lines below to disable them in the build
> +# DISTRO_FEATURES options:
> +# alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs zeroconf pci
> +DISTRO_FEATURES_TINY = "pci"
> +DISTRO_FEATURES_NET = "ipv4"
> +DISTRO_FEATURES_USB = "usbhost"
> +#DISTRO_FEATURES_USBGADGET = "usbgadget"
> +#DISTRO_FEATURES_WIFI = "wifi"
> +
> +DISTRO_FEATURES = "${DISTRO_FEATURES_TINY} \
> + ${DISTRO_FEATURES_NET} \
> + ${DISTRO_FEATURES_USB} \
> + ${DISTRO_FEATURES_USBGADGET} \
> + ${DISTRO_FEATURES_WIFI} \
> + ${DISTRO_FEATURES_LIBC} \
> + "
> +
> +# Use tmpdevfs and the busybox runtime services
> +VIRTUAL-RUNTIME_dev_manager = ""
> +VIRTUAL-RUNTIME_login_manager = ""
> +VIRTUAL-RUNTIME_init_manager = ""
> +VIRTUAL-RUNTIME_keymaps = ""
> +
> +# FIXME: Consider adding "modules" to MACHINE_FEATURES and using that in
> +# task-core-base to select modutils-initscripts or not. Similar with "net"
> and
> +# netbase.
> +
> +# By default we only support ext2 and initramfs. We don't build live as that
> +# pulls in a lot of dependencies for the live image and the installer, like
> +# udev, grub, etc. These pull in gettext, which fails to build with wide
> +# character support.
> +IMAGE_FSTYPES = "ext2 cpio.gz"
> +
> +# Drop v86d from qemu depende
Re: [yocto] [V2 PATCH 1/1] mm: msync: fix issues of sys_msync on tmpfs
On (22/12/11 09:24), Bruce Ashfield wrote:
> On 11-12-21 10:07 PM, Zumeng Chen wrote:
> >There are two problems as follows shown:
> >1 ) for TMPFS, nothing need to be done in sys_msync,
> > sys_msync just return 0 for all arches.
> >
> >2 ) But for MIPS CPUs with cache alias(dmesg|grep alias),
> > it maybe has the issue, which reported by msync test
> > suites in ltp-full, when the memory of memset used by
> > msycn01 has cache alias.
> > So, in this situation, we have to flush the related
> > vma to make sure correct read.
>
> Looks good. I'll queue this for the next kernel update.
>
has this been proposed to lkml ?
> Cheers,
>
> Bruce
>
> >
> >Signed-off-by: Zumeng Chen
> >---
> > include/linux/shmem_fs.h | 10 ++
> > mm/msync.c | 22 +-
> > mm/shmem.c |5 +
> > 3 files changed, 36 insertions(+), 1 deletions(-)
> >
> >diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
> >index aa08fa8..62a2d57 100644
> >--- a/include/linux/shmem_fs.h
> >+++ b/include/linux/shmem_fs.h
> >@@ -12,6 +12,15 @@
> >
> > #define SHMEM_SYMLINK_INLINE_LEN (SHMEM_NR_DIRECT * sizeof(swp_entry_t))
> >
> >+/*
> >+
> >+*/
> >+#ifndef cpu_has_dc_aliases
> >+#define CPU_HAS_CACHE_ALIAS 0
> >+#else
> >+#define CPU_HAS_CACHE_ALIAS cpu_has_dc_aliases
> >+#endif
> >+
> > struct shmem_inode_info {
> > spinlock_t lock;
> > unsigned long flags;
> >@@ -49,6 +58,7 @@ static inline struct shmem_inode_info *SHMEM_I(struct
> >inode *inode)
> > /*
> > * Functions in mm/shmem.c called directly from elsewhere:
> > */
> >+extern int is_shmem_file(struct file *file);
> > extern int init_tmpfs(void);
> > extern int shmem_fill_super(struct super_block *sb, void *data, int
> > silent);
> > extern struct file *shmem_file_setup(const char *name,
> >diff --git a/mm/msync.c b/mm/msync.c
> >index 632df45..84cb068 100644
> >--- a/mm/msync.c
> >+++ b/mm/msync.c
> >@@ -13,6 +13,8 @@
> > #include
> > #include
> > #include
> >+#include
> >+#include
> >
> > /*
> > * MS_SYNC syncs the entire file - including mappings.
> >@@ -33,6 +35,7 @@ SYSCALL_DEFINE3(msync, unsigned long, start, size_t, len,
> >int, flags)
> > unsigned long end;
> > struct mm_struct *mm = current->mm;
> > struct vm_area_struct *vma;
> >+struct file *file;
> > int unmapped_error = 0;
> > int error = -EINVAL;
> >
> >@@ -56,8 +59,25 @@ SYSCALL_DEFINE3(msync, unsigned long, start, size_t, len,
> >int, flags)
> > */
> > down_read(&mm->mmap_sem);
> > vma = find_vma(mm, start);
> >+
> >+#ifdef CONFIG_TMPFS
> >+/*
> >+ * For tmpfs, no matter which flag(ASYNC or SYNC) gets from msync,
> >+ * there is not so much thing to do for CPUs without cache alias,
> >+ * But for some CPUs with cache alias, msync has to flush cache
> >+ * explicitly, which makes sure the data coherency between memory
> >+ * file and cache.
> >+ */
> >+file = vma->vm_file;
> >+if (is_shmem_file(file)) {
> >+if(CPU_HAS_CACHE_ALIAS)
> >+flush_cache_range(vma, start, start+len);
> >+error = 0;
> >+goto out_unlock;
> >+}
> >+#endif
> >+
> > for (;;) {
> >-struct file *file;
> >
> > /* Still start< end. */
> > error = -ENOMEM;
> >diff --git a/mm/shmem.c b/mm/shmem.c
> >index 92e5c15..4fabfac 100644
> >--- a/mm/shmem.c
> >+++ b/mm/shmem.c
> >@@ -2793,6 +2793,11 @@ static struct file_system_type tmpfs_fs_type = {
> > .kill_sb= kill_litter_super,
> > };
> >
> >+int is_shmem_file(struct file *file)
> >+{
> >+return (file->f_op ==&shmem_file_operations)? 1 : 0;
> >+}
> >+
> > int __init init_tmpfs(void)
> > {
> > int error;
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
-Khem
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [V2 PATCH 1/1] mm: msync: fix issues of sys_msync on tmpfs
On 12-01-03 11:53 PM, Khem Raj wrote:
On (22/12/11 09:24), Bruce Ashfield wrote:
On 11-12-21 10:07 PM, Zumeng Chen wrote:
There are two problems as follows shown:
1 ) for TMPFS, nothing need to be done in sys_msync,
sys_msync just return 0 for all arches.
2 ) But for MIPS CPUs with cache alias(dmesg|grep alias),
it maybe has the issue, which reported by msync test
suites in ltp-full, when the memory of memset used by
msycn01 has cache alias.
So, in this situation, we have to flush the related
vma to make sure correct read.
Looks good. I'll queue this for the next kernel update.
has this been proposed to lkml ?
Not yet. We are still reviewing it @ Wind River via our process, and
since we picked it up on MIPS, we are running it past Ralf as well.
Still time to get it in place for 3.3, if it is legit.
Cheers,
Bruce
Cheers,
Bruce
Signed-off-by: Zumeng Chen
---
include/linux/shmem_fs.h | 10 ++
mm/msync.c | 22 +-
mm/shmem.c |5 +
3 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
index aa08fa8..62a2d57 100644
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -12,6 +12,15 @@
#define SHMEM_SYMLINK_INLINE_LEN (SHMEM_NR_DIRECT * sizeof(swp_entry_t))
+/*
+
+*/
+#ifndef cpu_has_dc_aliases
+#define CPU_HAS_CACHE_ALIAS 0
+#else
+#define CPU_HAS_CACHE_ALIAS cpu_has_dc_aliases
+#endif
+
struct shmem_inode_info {
spinlock_t lock;
unsigned long flags;
@@ -49,6 +58,7 @@ static inline struct shmem_inode_info *SHMEM_I(struct inode
*inode)
/*
* Functions in mm/shmem.c called directly from elsewhere:
*/
+extern int is_shmem_file(struct file *file);
extern int init_tmpfs(void);
extern int shmem_fill_super(struct super_block *sb, void *data, int silent);
extern struct file *shmem_file_setup(const char *name,
diff --git a/mm/msync.c b/mm/msync.c
index 632df45..84cb068 100644
--- a/mm/msync.c
+++ b/mm/msync.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
/*
* MS_SYNC syncs the entire file - including mappings.
@@ -33,6 +35,7 @@ SYSCALL_DEFINE3(msync, unsigned long, start, size_t, len,
int, flags)
unsigned long end;
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
+ struct file *file;
int unmapped_error = 0;
int error = -EINVAL;
@@ -56,8 +59,25 @@ SYSCALL_DEFINE3(msync, unsigned long, start, size_t, len,
int, flags)
*/
down_read(&mm->mmap_sem);
vma = find_vma(mm, start);
+
+#ifdef CONFIG_TMPFS
+ /*
+* For tmpfs, no matter which flag(ASYNC or SYNC) gets from msync,
+* there is not so much thing to do for CPUs without cache alias,
+* But for some CPUs with cache alias, msync has to flush cache
+* explicitly, which makes sure the data coherency between memory
+* file and cache.
+*/
+ file = vma->vm_file;
+ if (is_shmem_file(file)) {
+ if(CPU_HAS_CACHE_ALIAS)
+ flush_cache_range(vma, start, start+len);
+ error = 0;
+ goto out_unlock;
+ }
+#endif
+
for (;;) {
- struct file *file;
/* Still start< end. */
error = -ENOMEM;
diff --git a/mm/shmem.c b/mm/shmem.c
index 92e5c15..4fabfac 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2793,6 +2793,11 @@ static struct file_system_type tmpfs_fs_type = {
.kill_sb= kill_litter_super,
};
+int is_shmem_file(struct file *file)
+{
+ return (file->f_op ==&shmem_file_operations)? 1 : 0;
+}
+
int __init init_tmpfs(void)
{
int error;
___
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] build error on meta-cedarview
On (03/01/12 12:26), Jim Abernathy wrote: > On 12/29/2011 11:37 AM, Saul Wold wrote: > >On 12/28/2011 09:26 PM, Andrew Schweitzer wrote: > >>Jim Abernathy writes: > >> > >>> > >>> > >>> While running a build of the core-image-sato using the > >>>edison latest > >>> commits and the meta-cedartrail bsp, I notices some errors fly by > >>> and thought I'd see if anyone knows the reason. The build is just > >>> to test the bsp with no changes. Basically, doing the > >>>Appendix A of > >>> the Development manual substituting cedartrail for crownbay. > >>> snippet of the console log below: > >>> NOTE: package icon-naming-utils-native-0.8.7-r3: task do_unpack: > >>> Started > >>> ERROR: Function 'Unpack failure for URL: > >>'http://tango.freedesktop.org/releases/icon-naming-utils-0.8.7.tar.gz'. > >> > >>I don't know the reason, but I did get the same error when > >>trying to build yocto > >>per the getting started page, changing local.conf to create qemuarm > >> > >>I would be interested in knowing the reason too. > >> > >There has been a bug filed against this issue, it seems that the > >tarballs have moved or are unavailable from that location for some > >reason. You are getting a download page, and I believe that the > >failure should occur earlier with a checksum mismatch, but is not. > > > >You can fetch this file from our mirror at: > >http://downloads.yoctoproject.org/mirror/sources/icon-naming-utils-0.8.7.tar.gz > > > > > Saul, > > Sorry for the dumb question, but how do I download the file and fool > bitbake into not trying to download it from the invalid site? Or do > I need to change a file somewhere to specific our mirror URL > instead?? cd into DL_DIR wget the then touch .done You can add http://downloads.yoctoproject.org/mirror/sources/ to MIRRORS something like MIRRORS =+ "http://downloads.yoctoproject.org/mirror/sources/"; to the concerned recipe. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Related to eglibc
On (22/12/11 09:01), Navani Kamal Srivastava wrote: > Hello, > > We are having problem in running Qt applications. What I figured out is when > we are putting eglibc-2.12 generated libraries (like libdl-2.12.1.so, > libm-2.12.1.so), Qt applications are flickering or can say refreshing at > every touch. On putting same libraries of version 2.11 taken from freescale > rootfs ( libdl-2.11.1.so, libm-2.11.1.so) Qt applications are running fine. > We tried compiling eglibc-2.11.1 through yocto but we didn't even succeeded > to configure it. Can you please suggest some patch that we can apply to get > the same libraries. > can you try it with eglibc-2.13 or eglibc-2.14 ? you can backport those recipes from oe-core master ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
On (23/12/11 12:59), Bruce Ashfield wrote: > On 11-12-23 12:52 PM, Koen Kooi wrote: > > > >Op 23 dec. 2011, om 18:45 heeft Bruce Ashfield het volgende geschreven: > > > >>On 11-12-23 12:38 PM, Philip Balister wrote: > >>>On 12/23/2011 12:10 PM, Bruce Ashfield wrote: > On 11-12-23 08:10 AM, James Abernathy wrote: > > > >On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote: > > > >> > >>Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: > >> > >>>On Friday 23 December 2011 09:28:31 Koen Kooi wrote: > Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: > >I know the examples in the documentation of Yocto use meta-intel a > >lot > >to get the board specific BSPs like meta-crownbay or meta-n450. > > > >Is there a meta-ti or similar that gets you the meta-beagleboard and > >meta-pandaboard? If not how do you clone and checkout the pandaboard > >BPS? > http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ > > > It has a README in there on how to set it up, read it and follow it > precisely. > >>> > >>>Just out of interest, why does meta-texasinstruments depend on > >>>meta-angstrom? > >> > >>It needs extra things in overrides and reuses tasks from there. > > > >Sorry for the follow-up, but if I clone the meta-texasinstruments bsp > >repository and checkout the pandaboard-rework branch, > >how does that relate to the Yocto branch/bsp yocto/standard/pandaboard > >on the Yocto site? > > I'll jump into the middle of the thread, and answer a couple of specific > questions and leave the larger what depends on what, and where > things evolve and why .. for another day. > > The yocto/standard/pandaboard in the 3.0 kernel tree is the refresh/update > of a reference BSP for the 3.0 (and newer) kernel(s). > >>> > >>>Who is the intended audience of this BSP? The Angstrom/meta-to layer is > >>>obviously intended for people using TI hardware and all the associated > >>>peripherals. Without defining your audience better, this jsut adds to > >>>the confusion end users are experiencing with all the words and layers > >>>being used in emails. This is becoming a real problem as new users enter > >>>the project. > >> > >>Quite simply, the audience that needs a particular kernel version > >>and feature set, with the tooling to transition to a supported (i.e > >>not the yocto one) BSP. > > > >You do realize that by doing this without informing anyone involved with the > >official pandaboard BSP the net effect is negative? And by 'negative' I mean > >"severe annoyance" among other things. > > .. and why would you assume that precisely that hadn't been done ? > It has been, via management channels at multiple companies and > organizations and is exactly why I said "a layer you can't get" > and "work in progress". > > So please, no need to jump to anything resembling 'annoyance'. > There's plenty of that to go around, and it isn't constructive. I think it would be nice if we had a wiki document which listed various BSPs for a given platform that are available using the given layers and some words differentiating them. That can help end users in understanding and deciding which to use. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
On 12-01-04 12:15 AM, Khem Raj wrote: On (23/12/11 12:59), Bruce Ashfield wrote: On 11-12-23 12:52 PM, Koen Kooi wrote: Op 23 dec. 2011, om 18:45 heeft Bruce Ashfield het volgende geschreven: On 11-12-23 12:38 PM, Philip Balister wrote: On 12/23/2011 12:10 PM, Bruce Ashfield wrote: On 11-12-23 08:10 AM, James Abernathy wrote: On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote: Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: On Friday 23 December 2011 09:28:31 Koen Kooi wrote: Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: I know the examples in the documentation of Yocto use meta-intel a lot to get the board specific BSPs like meta-crownbay or meta-n450. Is there a meta-ti or similar that gets you the meta-beagleboard and meta-pandaboard? If not how do you clone and checkout the pandaboard BPS? http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ It has a README in there on how to set it up, read it and follow it precisely. Just out of interest, why does meta-texasinstruments depend on meta-angstrom? It needs extra things in overrides and reuses tasks from there. Sorry for the follow-up, but if I clone the meta-texasinstruments bsp repository and checkout the pandaboard-rework branch, how does that relate to the Yocto branch/bsp yocto/standard/pandaboard on the Yocto site? I'll jump into the middle of the thread, and answer a couple of specific questions and leave the larger what depends on what, and where things evolve and why .. for another day. The yocto/standard/pandaboard in the 3.0 kernel tree is the refresh/update of a reference BSP for the 3.0 (and newer) kernel(s). Who is the intended audience of this BSP? The Angstrom/meta-to layer is obviously intended for people using TI hardware and all the associated peripherals. Without defining your audience better, this jsut adds to the confusion end users are experiencing with all the words and layers being used in emails. This is becoming a real problem as new users enter the project. Quite simply, the audience that needs a particular kernel version and feature set, with the tooling to transition to a supported (i.e not the yocto one) BSP. You do realize that by doing this without informing anyone involved with the official pandaboard BSP the net effect is negative? And by 'negative' I mean "severe annoyance" among other things. .. and why would you assume that precisely that hadn't been done ? It has been, via management channels at multiple companies and organizations and is exactly why I said "a layer you can't get" and "work in progress". So please, no need to jump to anything resembling 'annoyance'. There's plenty of that to go around, and it isn't constructive. I think it would be nice if we had a wiki document which listed various BSPs for a given platform that are available using the given layers and some words differentiating them. That can help end users in understanding and deciding which to use. AFAIK there are plans in this area for the 1.2 timeframe, perhaps via the BSP portal that TomZ was creating. Something linked from the wiki pages that list all the available layers would be the logical place to locate something like this as well. Richard may have more insight as to whether or not something is planned like this. Cheers, Bruce ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/2] Fix Makefiles
On (28/12/11 14:54), Wang, Shane wrote: > This patch is to remove DESTDIR in docdir. > Otherwise, when users install by running `make install > DESTDIR=/alternate/directory' specified in the file INSTALL, the doc will go > into /alternate/directory/alternate/directory, which is not expected. DESTDIR is supposed to relocate the install dir why is this wrong ? > > Signed-off-by: Shane Wang > > diff -r 30b597e4e70d Makefile.am > --- a/Makefile.am Wed Dec 28 15:38:35 2011 +0800 > +++ b/Makefile.am Wed Dec 28 15:39:25 2011 +0800 > @@ -7,7 +7,7 @@ > pkgconfigdir = $(libdir)/pkgconfig > pkgconfig_DATA = libomxil-bellagio.pc > > -docdir = $(DESTDIR)$(prefix)/share/doc/@PACKAGE@ > +docdir = $(prefix)/share/doc/@PACKAGE@ > doc_DATA = README \ > ChangeLog \ > TODO > > -- > Shane > > http://www.yoctoproject.org/ > It's not an embedded Linux distribution - > It creates a custom one for you. > [0;0mThis patch is to remove DESTDIR in docdir.[0;0m > [0;0mOtherwise, when users install by running `make install > DESTDIR=/alternate/directory' specified in the file INSTALL, the doc will go > into /alternate/directory/alternate/directory, which is not expected.[0;0m > [0;0m[0;0m > [0;0mSigned-off-by: Shane Wang [0;0m > [0;0m[0;0m > [1;32mdiff -r 30b597e4e70d Makefile.am[0;0m > [1;31m--- a/Makefile.am Wed Dec 28 15:38:35 2011 +0800[0;0m > [1;34m+++ b/Makefile.am Wed Dec 28 15:39:25 2011 +0800[0;0m > [1;35m@@ -7,7 +7,7 @@[0;0m > [0;0m pkgconfigdir = $(libdir)/pkgconfig[0;0m > [0;0m pkgconfig_DATA = libomxil-bellagio.pc[0;0m > [0;0m [0;0m > [1;31m-docdir = $(DESTDIR)$(prefix)/share/doc/@PACKAGE@[0;0m > [1;34m+docdir = $(prefix)/share/doc/@PACKAGE@[0;0m > [0;0m doc_DATA = README \[0;0m > [0;0m ChangeLog \[0;0m > [0;0m TODO[0;0m > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- -Khem ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python Math Module
On (02/01/12 19:07), Pedro Algarvio wrote:
> I've started to port the Mini2440 openembedded layer found at
> http://code.google.com/p/mini2440/ and also PySide from Angstrom or
> the old OpenEmbedded layers I think(can't remember now).
>
> My layers can be found at http://dev.ufsoft.org/projects/yocto
>
> I found out while porting PySide's examples that python does not ship
> with it's math module, is there a specific reason why?
add RDEPENDS_${PN} += "python-math" to your pyside recipe
>
> I need to add that I'm pretty new to all this, so I might be doin'
> things the wrong way...
>
> Anyway, any pointers on how to add the python's math module to an
> image is more than welcome, I'd like to include it as a dependency for
> the pyside examples bb script.
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
-Khem
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
