[oe] [PATCH] ti-dmai: Fixes for Display and Capture.
These patches fix issues with display and capture in ti-dmai that cause it to
break with recent kernels.
Signed-off-by: Joel A Fernandes
---
recipes/ti/ti-dmai.inc |4 +
...display-Set-the-default-Display-Output-to.patch | 26 +
...o-detect-V4L2-display-device-node-to-open.patch | 109
...e-display-rotation-to-avoid-problems-due-.patch | 29 +
...-DMAI-Use-the-correct-capture-device-node.patch | 26 +
5 files changed, 194 insertions(+), 0 deletions(-)
create mode 100644
recipes/ti/ti-dmai/beagle/0001-DMAI-video_display-Set-the-default-Display-Output-to.patch
create mode 100644
recipes/ti/ti-dmai/beagle/0002-DMAI-Auto-detect-V4L2-display-device-node-to-open.patch
create mode 100644
recipes/ti/ti-dmai/beagle/0003-DMAI-Disable-display-rotation-to-avoid-problems-due-.patch
create mode 100644
recipes/ti/ti-dmai/beagle/0004-DMAI-Use-the-correct-capture-device-node.patch
diff --git a/recipes/ti/ti-dmai.inc b/recipes/ti/ti-dmai.inc
index c3a0f71..a5a11a1 100644
--- a/recipes/ti/ti-dmai.inc
+++ b/recipes/ti/ti-dmai.inc
@@ -27,6 +27,10 @@ SRC_URI =
"svn://gforge.ti.com/svn/dmai/;module=${DMAIBRANCH};proto=https;user=a
file://loadmodules-ti-dmai-ol138_al.sh \
file://doxygen_templates.tar.gz \
file://arago-tdox \
+
file://beagle/0001-DMAI-video_display-Set-the-default-Display-Output-to.patch \
+
file://beagle/0002-DMAI-Auto-detect-V4L2-display-device-node-to-open.patch \
+
file://beagle/0003-DMAI-Disable-display-rotation-to-avoid-problems-due-.patch \
+
file://beagle/0004-DMAI-Use-the-correct-capture-device-node.patch \
"
DEPENDS = "virtual/kernel alsa-lib ti-framework-components ti-codec-engine
ti-xdctools"
diff --git
a/recipes/ti/ti-dmai/beagle/0001-DMAI-video_display-Set-the-default-Display-Output-to.patch
b/recipes/ti/ti-dmai/beagle/0001-DMAI-video_display-Set-the-default-Display-Output-to.patch
new file mode 100644
index 000..fce8272
--- /dev/null
+++
b/recipes/ti/ti-dmai/beagle/0001-DMAI-video_display-Set-the-default-Display-Output-to.patch
@@ -0,0 +1,26 @@
+From c584fc4593fc95c24facc8521a8a1180a0bc7b13 Mon Sep 17 00:00:00 2001
+From: Joel
+Date: Mon, 20 Jun 2011 16:59:54 -0500
+Subject: [PATCH 1/4] DMAI video_display: Set the default Display Output to DVI.
+
+Signed-off-by: Joel A Fernandes
+---
+ apps/video_display/linux/main.c |2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+packages/ti/sdo/dmai
+diff --git a/packages/ti/sdo/dmai/apps/video_display/linux/main.c
b/packages/ti/sdo/dmai/apps/video_display/linux/main.c
+index 15182b7..496d19c 100644
+--- a/packages/ti/sdo/dmai/apps/video_display/linux/main.c
b/packages/ti/sdo/dmai/apps/video_display/linux/main.c
+@@ -45,7 +45,7 @@
+ #include "../appMain.h"
+
+ /* Default arguments for app */
+-#define DEFAULT_ARGS { 1000, FALSE, FALSE, VideoStd_D1_NTSC,
Display_Output_COMPOSITE }
++#define DEFAULT_ARGS { 1000, FALSE, FALSE, VideoStd_D1_NTSC,
Display_Output_DVI }
+
+ /*
+ * Argument IDs for long options. They must not conflict with ASCII values,
+--
+1.7.0.4
+
diff --git
a/recipes/ti/ti-dmai/beagle/0002-DMAI-Auto-detect-V4L2-display-device-node-to-open.patch
b/recipes/ti/ti-dmai/beagle/0002-DMAI-Auto-detect-V4L2-display-device-node-to-open.patch
new file mode 100644
index 000..77882f4
--- /dev/null
+++
b/recipes/ti/ti-dmai/beagle/0002-DMAI-Auto-detect-V4L2-display-device-node-to-open.patch
@@ -0,0 +1,109 @@
+From 39d909ea1040b86968adf0d62475955bd07f96a8 Mon Sep 17 00:00:00 2001
+From: Joel A Fernandes
+Date: Tue, 21 Jun 2011 15:33:14 -0500
+Subject: [PATCH 2/4] DMAI: Auto-detect V4L2 display device node to open.
+
+Changes in display device node names in the kernel break DMAI.
+This autodetects the device node name to avoid such breakages in the future.
+
+Signed-off-by: Joel A Fernandes
+---
+ linux/Display.c |2 +-
+ linux/omap3530/Display_v4l2.c | 40
+ 2 files changed, 41 insertions(+), 1 deletions(-)
+
+diff --git a/packages/ti/sdo/dmai/linux/Display.c
b/packages/ti/sdo/dmai/linux/Display.c
+index bf0db2e..578ab8a 100644
+--- a/packages/ti/sdo/dmai/linux/Display.c
b/packages/ti/sdo/dmai/linux/Display.c
+@@ -197,7 +197,7 @@ const Display_Attrs Display_Attrs_O3530_VID_DEFAULT = {
+ Display_Std_V4L2,
+ VideoStd_VGA,
+ Display_Output_LCD,
+-"/dev/video1",
++"", // V4L2 device nodes are auto detected
+ 0,
+ ColorSpace_UYVY,
+ -1,
+diff --git a/packages/ti/sdo/dmai/linux/omap3530/Display_v4l2.c
b/packages/ti/sdo/dmai/linux/omap3530/Display_v4l2.c
+index 8cd891c..61f15bb 100644
+--- a/packages/ti/sdo/dmai/linux/omap3530/Display_v4l2.c
b/packages/ti/sdo/dmai/linux/omap3530/Display_v4l2.c
+@@ -35,6 +35,7 @@
+ #include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -55,6 +56,7
Re: [oe] libgisi: task compile fails with `posix-ext.vapi:7.5-7.30: error: `Posix' already contains a definition for `INET_ADDRSTRLEN'`
On 06/24/2011 02:41 PM, Paul Menzel wrote: Dear OE folks, task compile of libgisi c993ee694ea98597d619a1ffae397d3416233354 fails with the following error using `minimal` for `MACHINE = "beagleboard"`. /oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/bin/valac -C --basedir .. --vapidir ../data --vapidir ../vapi --pkg glib-2.0 --pkg gio-2.0 --pkg libgisi --pkg posix --pkg posix-ext --header gisicomm.h --library gisicomm-0.0 gisicomm.vala posix-ext.vapi:7.5-7.30: error: `Posix' already contains a definition for `INET_ADDRSTRLEN' const int INET_ADDRSTRLEN; ^^ posix.vapi:476.2-476.34: note: previous definition of `INET_ADDRSTRLEN' was here public const int INET_ADDRSTRLEN; ^ posix-ext.vapi:8.5-8.31: error: `Posix' already contains a definition for `INET6_ADDRSTRLEN' const int INET6_ADDRSTRLEN; ^^^ posix.vapi:478.2-478.35: note: previous definition of `INET6_ADDRSTRLEN' was here public const int INET6_ADDRSTRLEN; ^^ posix-ext.vapi:4.2-4.25: error: `Posix' already contains a definition for `inet_ntop' unowned string inet_ntop (int af, void* src, uint8[] dst); posix.vapi:485.2-485.25: note: previous definition of `inet_ntop' was here unowned string inet_ntop (int af, void* src, uint8[] dst); Compilation failed: 3 error(s), 0 warning(s) Please forward that to the appropriate people. may be it should not be including posix-ext and posix pkgs simulteneously Thanks, Paul ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Bitbake master vs. openembedded classic
Hi, I'm still working with oe-dev on the KKK (klibc, kexec, kexecboot) which will be hopefully soon ready for oe-core. Trying a build from scratch after fresh pull breaks on gettext-native. Fresh oe.dev doesn't cope with bitbake master. I sent bitbake back to "HEAD is now at ea0ca90 cooker.py: Drop duplicate parseCommandLine call" and things works as before. Maybe next time I'll try to bisect pulling bitbake 1.13.1 Just FYI Andrea ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Packaging from devshell
On Fri, Jun 24, 2011 at 2:40 PM, Joel A Fernandes wrote:
> I use devshell for compiling by running a bitbake generated do_compile shell
> script in work/ for my package, this helps me develop faster as I can skip
> over parsing and other repetitive stages.
>
> However I'm not able to do the same with do_package_write, as the shell
> script for the same appears to have an empty function:
>
> do_package_write() {
> :
> }
>
> Could anyone suggest which script should I execute to package from
> devshell?
Nearly all of the packaging process is done from python code, not shell.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] libgisi: task compile fails with `posix-ext.vapi:7.5-7.30: error: `Posix' already contains a definition for `INET_ADDRSTRLEN'`
Dear OE folks, task compile of libgisi c993ee694ea98597d619a1ffae397d3416233354 fails with the following error using `minimal` for `MACHINE = "beagleboard"`. /oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/bin/valac -C --basedir .. --vapidir ../data --vapidir ../vapi --pkg glib-2.0 --pkg gio-2.0 --pkg libgisi --pkg posix --pkg posix-ext --header gisicomm.h --library gisicomm-0.0 gisicomm.vala posix-ext.vapi:7.5-7.30: error: `Posix' already contains a definition for `INET_ADDRSTRLEN' const int INET_ADDRSTRLEN; ^^ posix.vapi:476.2-476.34: note: previous definition of `INET_ADDRSTRLEN' was here public const int INET_ADDRSTRLEN; ^ posix-ext.vapi:8.5-8.31: error: `Posix' already contains a definition for `INET6_ADDRSTRLEN' const int INET6_ADDRSTRLEN; ^^^ posix.vapi:478.2-478.35: note: previous definition of `INET6_ADDRSTRLEN' was here public const int INET6_ADDRSTRLEN; ^^ posix-ext.vapi:4.2-4.25: error: `Posix' already contains a definition for `inet_ntop' unowned string inet_ntop (int af, void* src, uint8[] dst); posix.vapi:485.2-485.25: note: previous definition of `inet_ntop' was here unowned string inet_ntop (int af, void* src, uint8[] dst); Compilation failed: 3 error(s), 0 warning(s) Please forward that to the appropriate people. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Packaging from devshell
Hi,
I use devshell for compiling by running a bitbake generated do_compile shell
script in work/ for my package, this helps me develop faster as I can skip
over parsing and other repetitive stages.
However I'm not able to do the same with do_package_write, as the shell
script for the same appears to have an empty function:
do_package_write() {
:
}
Could anyone suggest which script should I execute to package from
devshell?
Thanks,
Joel.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] initscripts: don't background volatile creation
From: Chris Larson
This fix is courtesy Chris Hallinan. There is/can be assumptions made in
the volatiles file that they're processed in order (e.g. directory
created, then files within that directory), yet the script processes
them in parallel, backgrounding the operations. This is racy, and means
it's possible to end up with dependent files/dirs not created before the
bits that need them.
It's likely that this will have a performance impact, but I haven't
benchmarked it. Better that we behave correctly than quickly. We can
look back into improving the speed of this, without breaking
dependencies, in the future.
Signed-off-by: Chris Larson
---
.../initscripts-1.0/populate-volatile.sh | 12 ++--
recipes/initscripts/initscripts_1.0.bb |2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/recipes/initscripts/initscripts-1.0/populate-volatile.sh
b/recipes/initscripts/initscripts-1.0/populate-volatile.sh
index f0a45ea..d9ec1b7 100755
--- a/recipes/initscripts/initscripts-1.0/populate-volatile.sh
+++ b/recipes/initscripts/initscripts-1.0/populate-volatile.sh
@@ -19,7 +19,7 @@ create_file() {
[ -e "$1" ] && {
[ "${VERBOSE}" != "no" ] && echo "Target already exists. Skipping."
} || {
- eval $EXEC &
+ eval $EXEC
}
}
@@ -34,7 +34,7 @@ mk_dir() {
[ -e "$1" ] && {
[ "${VERBOSE}" != "no" ] && echo "Target already exists. Skipping."
} || {
- eval $EXEC &
+ eval $EXEC
}
}
@@ -46,7 +46,7 @@ link_file() {
[ -e "$2" ] && {
echo "Cannot create link over existing -${TNAME}-." >&2
} || {
- eval $EXEC &
+ eval $EXEC
}
}
@@ -123,7 +123,7 @@ apply_cfgfile() {
TSOURCE="$TLTARGET"
[ -L "${TNAME}" ] || {
[ "${VERBOSE}" != "no" ] && echo "Creating link -${TNAME}- pointing to
-${TSOURCE}-."
-link_file "${TSOURCE}" "${TNAME}" &
+link_file "${TSOURCE}" "${TNAME}"
}
continue
}
@@ -142,10 +142,10 @@ apply_cfgfile() {
case "${TTYPE}" in
"f") [ "${VERBOSE}" != "no" ] && echo "Creating file -${TNAME}-."
-create_file "${TNAME}" &
+create_file "${TNAME}"
;;
"d") [ "${VERBOSE}" != "no" ] && echo "Creating directory -${TNAME}-."
-mk_dir "${TNAME}" &
+mk_dir "${TNAME}"
# Add check to see if there's an entry in fstab to mount.
;;
*)[ "${VERBOSE}" != "no" ] && echo "Invalid type -${TTYPE}-."
diff --git a/recipes/initscripts/initscripts_1.0.bb
b/recipes/initscripts/initscripts_1.0.bb
index 87a0e99..adf8594 100644
--- a/recipes/initscripts/initscripts_1.0.bb
+++ b/recipes/initscripts/initscripts_1.0.bb
@@ -4,7 +4,7 @@ PRIORITY = "required"
DEPENDS = "makedevs"
RDEPENDS_${PN} = "makedevs"
LICENSE = "GPL"
-PR = "r128"
+PR = "r129"
SRC_URI = "file://functions \
file://halt \
--
1.7.5.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] udev 171 caching working propely?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24-06-11 16:49, Andreas Mueller wrote: > On Friday, June 24, 2011 08:49:00 AM Koen Kooi wrote: >> On 24-06-11 00:52, Andreas Mueller wrote: >>> On Thursday, June 23, 2011 11:58:53 PM Koen Kooi wrote: On 23-06-11 22:58, Andreas Mueller wrote: > On Tuesday, June 21, 2011 11:31:45 PM Tom Rini wrote: >> On 06/20/2011 03:47 PM, Tom Rini wrote: >>> On 06/20/2011 02:16 PM, Andreas Mueller wrote: Dear OE-folks, Working with lastest classic oe master and angstrom it seems udev caching is not working as expected. On *every* boot I get: > Remounting root file system... > Caching udev devnodes > Populating dev cachemv: can't rename '/dev/shm/uname': No such file > or directory I don't know why this change came in but there was a change of storage location in Tom's commit few days ago [1]. To me it seems that 1. The files created by udev (init) get lost at remount so udev-cache (cache) is unable to find 2. Since this error occures not only at first boot the recipe's pkg_postinst_udev_append() seems never being executed. To check I added a simple echo 'foo text' in this function but 'foo text' is not found in log of first boot. Suggestions welcome >>> >>> Did udev change behaviors at some point then? I've been using an >>> older udev and didn't run into that problem. I changed from /tmp to >>> /dev/shm since we don't know that /tmp is writable at that point so >>> we were instead getting errors there. I wonder if we should just >>> switch to re-creating the contents for that step? >> >> I've gone with this change and some quick testing on a board. > > Hi Tom, > > thanks for taking care and sorry for late response - yesterday I had > one of these nightmares at the job... > > Now I tested the patch for two machines and sorry I am afraid to waste > your time again: > > First machine is overo with linux-omap-psp-2.6.32 and a hub connected > to the OTG connector. The kernel detects USB devices at a very early > boot state long before udev starts (see end of file 'overo' attached). > udev caching seems to work without errors. > > Second machine is tx28 with linux-2.6.38.5 (freescale imx28 based - I > will send patches when stable). This shows different behaviours on > first and all further boots (see udev-*boot attached). Problem is that > after second boot nothing connected to USB is detected / working. By > deleting /etc/udev/saved.* and rebooting all USB devices work fine and > log looks similar as first boot. > > Before I merged your patch I know the USB devices were working properly > on tx28. Don't misunderstand me: I think before your patch cache was > never read. Now you fixed this and it seems reading the cache does not > work (on my half cooked machine only?). > > I will have further investigations on this... With 171 you shouldn't need caching anymore, triggering has been sped up considerably, could you try disable caching and see how much it impacts your boot time? >>> >>> Uncached feels slower. Populating all devices takes 5-10s. Is there a >>> simple way to create time stamps for boot messages? >> >> Another test would be to unload the kernel modules and do: >> >> killall udevd ; time ( udevadm trigger ; udevadm settle ) >> >> That takes about 1s on my beagleboard and 3.5s on my hawkboard. >> >> Systemd keeps a track of it, have a look at the bright red portions of >> the graphs: >> >> http://dominion.thruhere.net/koen/angstrom/systemd/beagleboardC5-ubi-201106 >> 171148.svg http://dominion.thruhere.net/koen/angstrom/systemd/hawkboard.svg >> >> I my case the caching wasn't needed, but if it starts taking >4s on >> 'slow' systems and >2s on 'fast' systems it is worth considering. >> > News from udev-journey: > > I did modify the udev-init script so that I could see that > > | udevadm trigger ; udevadm settle > > lasted for ~10s! > > That made me think (usually that is not my domain..); Why is my board so slow > and why refuses udev to work proper for it? Checking all written I fell over > udev msg in one of my previous mails > > | insmod /lib/modules/2.6.38.5/kernel/drivers/usb/host/ehci-hcd.ko > > So I decided to change in kernel-config > -CONFIG_USB_HID=m > +CONFIG_USB_HID=y > > -CONFIG_USB_EHCI_HCD=m > +CONFIG_USB_EHCI_HCD=y > > This make the tx28 board now working very similar to my overo board: USB > devices > are detected at a very early state of boot and udev is much faster now and > USB > is working as expected. Also hotplugging seems to work. It does make the kernel boot ±1.5s slower, but that will still give you a big win in userspace. > I would say it's > pa
Re: [oe] udev 171 caching working propely?
On Friday, June 24, 2011 08:49:00 AM Koen Kooi wrote: > On 24-06-11 00:52, Andreas Mueller wrote: > > On Thursday, June 23, 2011 11:58:53 PM Koen Kooi wrote: > >> On 23-06-11 22:58, Andreas Mueller wrote: > >>> On Tuesday, June 21, 2011 11:31:45 PM Tom Rini wrote: > On 06/20/2011 03:47 PM, Tom Rini wrote: > > On 06/20/2011 02:16 PM, Andreas Mueller wrote: > >> Dear OE-folks, > >> > >> Working with lastest classic oe master and angstrom it seems udev > >> caching is not > >> > >> working as expected. On *every* boot I get: > >>> Remounting root file system... > >>> Caching udev devnodes > >>> Populating dev cachemv: can't rename '/dev/shm/uname': No such file > >>> or directory > >> > >> I don't know why this change came in but there was a change of > >> storage location in Tom's commit few days ago [1]. To me it seems > >> that > >> > >> 1. The files created by udev (init) get lost at remount so > >> udev-cache (cache) is unable to find > >> 2. Since this error occures not only at first boot the recipe's > >> pkg_postinst_udev_append() seems never being executed. To check I > >> added a simple echo 'foo text' > >> in this function but 'foo text' is not found in log of first boot. > >> > >> Suggestions welcome > > > > Did udev change behaviors at some point then? I've been using an > > older udev and didn't run into that problem. I changed from /tmp to > > /dev/shm since we don't know that /tmp is writable at that point so > > we were instead getting errors there. I wonder if we should just > > switch to re-creating the contents for that step? > > I've gone with this change and some quick testing on a board. > >>> > >>> Hi Tom, > >>> > >>> thanks for taking care and sorry for late response - yesterday I had > >>> one of these nightmares at the job... > >>> > >>> Now I tested the patch for two machines and sorry I am afraid to waste > >>> your time again: > >>> > >>> First machine is overo with linux-omap-psp-2.6.32 and a hub connected > >>> to the OTG connector. The kernel detects USB devices at a very early > >>> boot state long before udev starts (see end of file 'overo' attached). > >>> udev caching seems to work without errors. > >>> > >>> Second machine is tx28 with linux-2.6.38.5 (freescale imx28 based - I > >>> will send patches when stable). This shows different behaviours on > >>> first and all further boots (see udev-*boot attached). Problem is that > >>> after second boot nothing connected to USB is detected / working. By > >>> deleting /etc/udev/saved.* and rebooting all USB devices work fine and > >>> log looks similar as first boot. > >>> > >>> Before I merged your patch I know the USB devices were working properly > >>> on tx28. Don't misunderstand me: I think before your patch cache was > >>> never read. Now you fixed this and it seems reading the cache does not > >>> work (on my half cooked machine only?). > >>> > >>> I will have further investigations on this... > >> > >> With 171 you shouldn't need caching anymore, triggering has been sped up > >> considerably, could you try disable caching and see how much it impacts > >> your boot time? > > > > Uncached feels slower. Populating all devices takes 5-10s. Is there a > > simple way to create time stamps for boot messages? > > Another test would be to unload the kernel modules and do: > > killall udevd ; time ( udevadm trigger ; udevadm settle ) > > That takes about 1s on my beagleboard and 3.5s on my hawkboard. > > Systemd keeps a track of it, have a look at the bright red portions of > the graphs: > > http://dominion.thruhere.net/koen/angstrom/systemd/beagleboardC5-ubi-201106 > 171148.svg http://dominion.thruhere.net/koen/angstrom/systemd/hawkboard.svg > > I my case the caching wasn't needed, but if it starts taking >4s on > 'slow' systems and >2s on 'fast' systems it is worth considering. > News from udev-journey: I did modify the udev-init script so that I could see that | udevadm trigger ; udevadm settle lasted for ~10s! That made me think (usually that is not my domain..); Why is my board so slow and why refuses udev to work proper for it? Checking all written I fell over udev msg in one of my previous mails | insmod /lib/modules/2.6.38.5/kernel/drivers/usb/host/ehci-hcd.ko So I decided to change in kernel-config -CONFIG_USB_HID=m +CONFIG_USB_HID=y -CONFIG_USB_EHCI_HCD=m +CONFIG_USB_EHCI_HCD=y This make the tx28 board now working very similar to my overo board: USB devices are detected at a very early state of boot and udev is much faster now and USB is working as expected. Also hotplugging seems to work. I would say it's partytime but still there is | udevd[588]: error: runtime directory '/run/udev' not writable, for now falling back to '/dev/.udev' | <30>udevd[589]: starting version 171 For now no need to follow this... Thanks Koen & Tom for support An
Re: [oe] Minutes: OpenEmbedded eV Board meeting, 20-Jun-2011
On 06/24/2011 09:37 AM, Dirk Hohndel wrote: On Thu, 23 Jun 2011 23:53:11 -0400, Denys Dmytriyenko wrote: Minutes: OpenEmbedded eV Board meeting, 20-Jun-2011 Agenda: 06) call for donation * OE needs an income stream - another call for donations in the mailing lists * denix to check if TI can make another donation ** may be difficult, as TI and other companies are LF/Yocto members and pay dues ** thus, latest LF donations to OE as a "feedback" channel make sense We (or more likely, the Board) should establish clearly how this OE income stream should work. Do we (the OE members) WANT to have the LF provide a well defined reasonable income stream to OE? Then RP or I can trigger that conversation with Jim Zemlin, Exec Director of the LF. Or do we PREFER to solicit independent donations to avoid the perception of being dependent on LF? In that case please talk to DaveS or me about an Intel donation to OE. This is a very good question. I would like to see the eV have a steady income from a diverse group of people. At the same time, any income is helpful. A reliable income stream allows the board to make long term plans. We need to provide the nas-admin group at OSUOSL with better financial support to cover our infrastructure needs as the project grows. Basically, we have two sources of income, corporate sponsorship and individual donations. As a board member, I would like to hear from the membership what people think, both about how we should spend money and how we should raise money. Philip ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
