Re: [yocto] Problem with mouse and keyboard detection in yocto (core-image-sato on emenlow)
On 8 April 2013 09:42, Andreas Enbacka aenba...@gmail.com wrote: I have experienced some problems with getting the USB mouse and keyboard detected in the default core-image-sato Yocto image, built for the Intel Emenlow machine (with emgd graphics). X launches successfully to the Sato desktop, but I get no response from the mouse or keyboard. When I from terminal execute grep -i mouse /var/log/Xorg.0.log from terminal, I get the following output: Attaching the entire X log instead of grepping for phrases that you think are relevant would be more useful - in this case the module that X should be using for USB input is evdev, not mouse. Check that you've got the xorg evdev driver present and that the server is loading the module. It's possible that the permissions are wrong on the input nodes in /dev/input. Oh, and what version of Poky / oe-core were you using - 1.3 or master? Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Serial communication problem!
Hello, I have a little problem in finding out how does serial communication works within yocto-project. I've build a sato image with meta-emenlow bsp and qt4 support, i've done some qt apps and succeded in making them work on the target machine. Now i want my qt applicaion to recive some data via serial port, my target machine has a single serial DB9 father connector. I've found a class and build a program wich opens a specified port and listens it. i also have a Explorer 16 development board wich i use to send data trough serial. I tested whis with my ubuntu PC(sent data from devel. board, and opend a port with the qt program) and it worked i was able to see exactly what i've expected. Then i connected the devl board with my target machine, ran the serial listener on the target machine, with ttyS0 as the name for serial port, but nothing happend, no errors occured, but it just sitts there and dosen't do anything, i've also tried ttyS1 ttyS2 ttyS3 for the port name, but the same thing happend. Any advice? Is there some line that needs to be written before i burn my sato image in order to enable serial ports? Thank you ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with mouse and keyboard detection in yocto (core-image-sato on emenlow)
Thanks again for your assistance. I checked /usr/lib/xorg/modules/input, and evdev_drv.so is indeed present. I will try rebuild the specified modules, and see in case it solves the problem (I have indeed built some atom-pc images previously). Thanks, Andreas -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: 8. huhtikuuta 2013 13:34 To: Andreas Enbacka Cc: yocto@yoctoproject.org Subject: Re: [yocto] Problem with mouse and keyboard detection in yocto (core-image-sato on emenlow) On 8 April 2013 10:50, Andreas Enbacka aenba...@gmail.com wrote: Thanks for your reply, very much appreciated. I am currently using Poky master. I have attached the complete Xorg.0.log; it does not contain any mentions of evdev, only mouse, which would imply that evdev does not get loaded of some reason. That's interesting, it should be loading the evdev module. Can you confirm that it's present in /usr/lib/xorg/modules/input? Your log shows that it didn't load the kbd and mouse modules because the versions don't match: [3901748.190] (II) LoadModule: mouse [3901748.191] (II) Loading /usr/lib/xorg/modules/input/mouse_drv.so [3901748.208] (II) Module kbd: vendor=X.Org Foundation [3901748.208] compiled for 1.13.1, module version = 1.6.2 [3901748.203] (EE) module ABI major version (18) doesn't match the server's version (11) [3901748.204] (EE) Failed to load module mouse (module requirement mismatch, 0) This shouldn't happen in master because the server and the modules have runtime-dependences injected to stop this happening: $ dpkg -I xf86-input-mouse_1.8.1-r21.0.0_armv5te.ipk ... Depends: xorg-abi-input-19, libc6 (= 2.17) $ dpkg -I xserver-xorg_1.14.0-r8.0.0_armv5te.ipk ... Provides: xserver-xorg-extension-extmod, xserver-xorg-extension-dri, xorg-abi-video-14, xorg-abi-input-19, xserver-xorg-extension-dbe, xserver-xorg-extension-record, xserver-xorg-extension-dri2 Something went wrong and your drivers were built with a newer version of the server (1.13.1) than you're actually running (1.9.3). I suspect what's happened is that you've done a non-emenlow build (say, atom-pc) in the same build directory and your emenlow build is re-using the drivers. Rebuilding the drivers should help, so bitbake -ccleansstate xorg-input-keyboard xorg-input-mouse and then re-build your image. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] GDB problems
I'm trying to run GDB to debug code on my target. Whenever I start it up, I get this warning: warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. and indeed, no thread debug commands will work. I've found that the library /usr/lib/libthread_db.so is not being installed in the rootfs. However, just adding this library isn't enough. The file /lib/libpthread-2.60.so has been stripped on the target and this also breaks GDB. Installing a non-stripped version of this library lets GDB do thread debugging. Both of these libraries come from the eglibc package. How can I adjust that recipe to: * Install libthread_db.so * Avoid stripping libpthread-2.16.so It looks like the libthread_db.so file(s) should be installed via the 'eglibc-thread-db' package, but I can't find this package anywhere on my system. Any pointers? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with mouse and keyboard detection in yocto (core-image-sato on emenlow)
I rebuilt xf86-input-keyboard and xf86-input-mouse (as well as the core-image-sato image), and now the mouse / keyboard works ok in X. Thanks for the assistance. I checked the Xorg log file, it seems to add the mouse using the mouse_drv.so module, not evdev_drv.so. Do I need to rebuild xf86-input-evdev as well to get the mouse added using evdev? This because I have a custom application that handles the touch screen calibration running on top of X, and itexpects the mouse to be added via evdev. //Andreas -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: 8. huhtikuuta 2013 13:34 To: Andreas Enbacka Cc: yocto@yoctoproject.org Subject: Re: [yocto] Problem with mouse and keyboard detection in yocto (core-image-sato on emenlow) On 8 April 2013 10:50, Andreas Enbacka aenba...@gmail.com wrote: Thanks for your reply, very much appreciated. I am currently using Poky master. I have attached the complete Xorg.0.log; it does not contain any mentions of evdev, only mouse, which would imply that evdev does not get loaded of some reason. That's interesting, it should be loading the evdev module. Can you confirm that it's present in /usr/lib/xorg/modules/input? Your log shows that it didn't load the kbd and mouse modules because the versions don't match: [3901748.190] (II) LoadModule: mouse [3901748.191] (II) Loading /usr/lib/xorg/modules/input/mouse_drv.so [3901748.208] (II) Module kbd: vendor=X.Org Foundation [3901748.208] compiled for 1.13.1, module version = 1.6.2 [3901748.203] (EE) module ABI major version (18) doesn't match the server's version (11) [3901748.204] (EE) Failed to load module mouse (module requirement mismatch, 0) This shouldn't happen in master because the server and the modules have runtime-dependences injected to stop this happening: $ dpkg -I xf86-input-mouse_1.8.1-r21.0.0_armv5te.ipk ... Depends: xorg-abi-input-19, libc6 (= 2.17) $ dpkg -I xserver-xorg_1.14.0-r8.0.0_armv5te.ipk ... Provides: xserver-xorg-extension-extmod, xserver-xorg-extension-dri, xorg-abi-video-14, xorg-abi-input-19, xserver-xorg-extension-dbe, xserver-xorg-extension-record, xserver-xorg-extension-dri2 Something went wrong and your drivers were built with a newer version of the server (1.13.1) than you're actually running (1.9.3). I suspect what's happened is that you've done a non-emenlow build (say, atom-pc) in the same build directory and your emenlow build is re-using the drivers. Rebuilding the drivers should help, so bitbake -ccleansstate xorg-input-keyboard xorg-input-mouse and then re-build your image. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with mouse and keyboard detection in yocto (core-image-sato on emenlow)
On 8 April 2013 13:12, Andreas Enbacka aenba...@gmail.com wrote: I rebuilt xf86-input-keyboard and xf86-input-mouse (as well as the core-image-sato image), and now the mouse / keyboard works ok in X. Thanks for the assistance. I checked the Xorg log file, it seems to add the mouse using the mouse_drv.so module, not evdev_drv.so. Do I need to rebuild xf86-input-evdev as well to get the mouse added using evdev? This because I have a custom application that handles the touch screen calibration running on top of X, and itexpects the mouse to be added via evdev. Probably - you could try removing the mouse and keyboard drivers and leaving just evdev if it still prefers mouse/keyboard over evdev. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GDB problems
On 2013-04-08 05:03, Gary Thomas wrote: I'm trying to run GDB to debug code on my target. Whenever I start it up, I get this warning: warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. and indeed, no thread debug commands will work. I've found that the library /usr/lib/libthread_db.so is not being installed in the rootfs. However, just adding this library isn't enough. The file /lib/libpthread-2.60.so has been stripped on the target and this also breaks GDB. Installing a non-stripped version of this library lets GDB do thread debugging. Both of these libraries come from the eglibc package. How can I adjust that recipe to: * Install libthread_db.so * Avoid stripping libpthread-2.16.so It looks like the libthread_db.so file(s) should be installed via the 'eglibc-thread-db' package, but I can't find this package anywhere on my system. It's not clear to me why, but the files labelled as 'eglibc-thread-db' in the eglibc recipe end up in the 'libthread-db1' package, so that mystery is solved. I still don't know how to get the libpthread library to be not stripped (which it seems is what it takes to make GDB happy in this case). -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Calibrating touchscreen and the default display
Hi Guys, I have a TSC2007 touchscree for my tegra-harmony board The problem is calibration of the board Let me explain a bit better. I successfully compiled a basic X11 image. On the boot, the Linux penguins appear in the landscape mode on the display. Is it possible to rotate so that the penguins appear in the potrait mode? Apparently, I want to know if the Linux kernel identifies the display as 480x800 instead of 800x480 Now, I rotate the psplash and also the used xrandr to rotate the display. The following is the fbset output mode 800x480-60 # D: 33.260 MHz, H: 31.496 kHz, V: 59.993 Hz geometry 800 480 800 960 32 timings 30066 120 120 15 15 16 15 accel false rgba 8/0,8/8,8/16,8/24 endmode Secondly, I also want to calibrate the touchscreen. Eventhough I rotate the touchscreen in the xorg.conf.d/10-touchscreen.conf file.. When I run ts_calibrate, it still calibrates in landscape mode and not in potrait mode I am completely blocked in this stage. It would be great to receive suggestions to solve these issues Greets, Satya ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GDB problems
On Monday 08 April 2013 06:30:02 Gary Thomas wrote: On 2013-04-08 05:03, Gary Thomas wrote: I'm trying to run GDB to debug code on my target. Whenever I start it up, I get this warning: warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. and indeed, no thread debug commands will work. I've found that the library /usr/lib/libthread_db.so is not being installed in the rootfs. However, just adding this library isn't enough. The file /lib/libpthread-2.60.so has been stripped on the target and this also breaks GDB. Installing a non-stripped version of this library lets GDB do thread debugging. Both of these libraries come from the eglibc package. How can I adjust that recipe to: * Install libthread_db.so * Avoid stripping libpthread-2.16.so Does installing eglibc-dbg help with this? (Assuming you don't have this installed already.) It looks like the libthread_db.so file(s) should be installed via the 'eglibc-thread-db' package, but I can't find this package anywhere on my system. It's not clear to me why, but the files labelled as 'eglibc-thread-db' in the eglibc recipe end up in the 'libthread-db1' package, so that mystery is solved. That is debian library package renaming (debian.bbclass). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GDB problems
On 2013-04-08 06:47, Paul Eggleton wrote: On Monday 08 April 2013 06:30:02 Gary Thomas wrote: On 2013-04-08 05:03, Gary Thomas wrote: I'm trying to run GDB to debug code on my target. Whenever I start it up, I get this warning: warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. and indeed, no thread debug commands will work. I've found that the library /usr/lib/libthread_db.so is not being installed in the rootfs. However, just adding this library isn't enough. The file /lib/libpthread-2.60.so has been stripped on the target and this also breaks GDB. Installing a non-stripped version of this library lets GDB do thread debugging. Both of these libraries come from the eglibc package. How can I adjust that recipe to: * Install libthread_db.so * Avoid stripping libpthread-2.16.so Does installing eglibc-dbg help with this? (Assuming you don't have this installed already.) Yes, although it's named 'libc6-dbg' It looks like the libthread_db.so file(s) should be installed via the 'eglibc-thread-db' package, but I can't find this package anywhere on my system. It's not clear to me why, but the files labelled as 'eglibc-thread-db' in the eglibc recipe end up in the 'libthread-db1' package, so that mystery is solved. That is debian library package renaming (debian.bbclass). Ah, black magic... -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-ivi] No recipes available for: meta-ivi/recipes-graphics/xorg-xserver/xserver-xorg_1.14.0.bbappend
Hello
I am afraid I discovered a bug against the GENIVI Foton-0.1 Yocto Baseline.
I followed the instructions at
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/README.md?h=4.0
I suspect some misalignment between meta-ivi and poky SHA - however I believe I
followed what the README.me says.
Thank you in advance for any help or suggestions!
Login as gmacario@mv-linux-powerhorse
mkdir $HOME/genivi-baseline
cd $HOME/genivi-baseline
git clone git://git.yoctoproject.org/poky
cd poky; git checkout d823759b4594143d522eae0b2a2498436a6dcb1e; cd -
git clone git://git.yoctoproject.org/meta-ivi
cd meta-ivi; git checkout 4.0; cd -
Read http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/README.md?h=4.0
Initialize Build Environment
source poky/oe-init-build-env
Backup configuration files (will hand edit them later on)
cp conf/bblayers.conf conf/bblayers.conf.ORIG
cp conf/local.conf conf/local.conf.ORIG
Edit conf/bblayers.conf
gmacario@mv-linux-powerhorse:/scratch/gmacario/genivi-baseline/build$ diff -uw
conf/bblayers.conf.ORIG conf/bblayers.conf
--- conf/bblayers.conf.ORIG 2013-04-08 15:03:16.0 +0200
+++ conf/bblayers.conf 2013-04-08 15:07:59.0 +0200
@@ -6,6 +6,7 @@
BBFILES ?=
BBLAYERS ?= \
+ /scratch/gmacario/genivi-baseline/meta-ivi \
/scratch/gmacario/genivi-baseline/poky/meta \
/scratch/gmacario/genivi-baseline/poky/meta-yocto \
/scratch/gmacario/genivi-baseline/poky/meta-yocto-bsp \
gmacario@mv-linux-powerhorse:/scratch/gmacario/genivi-baseline/build$
Edit conf/local.conf
gmacario@mv-linux-powerhorse:/scratch/gmacario/genivi-baseline/build$ diff -uw
conf/local.conf.ORIG conf/local.conf
--- conf/local.conf.ORIG2013-04-08 15:04:43.0 +0200
+++ conf/local.conf 2013-04-08 15:11:26.0 +0200
@@ -17,12 +17,12 @@
# These two options control how much parallelism BitBake should use. The first
# option determines how many tasks bitbake should run in parallel:
#
-#BB_NUMBER_THREADS = 4
+BB_NUMBER_THREADS = 4
#
# The second option controls how many processes make should run in parallel
when
# running compile tasks:
#
-#PARALLEL_MAKE = -j 4
+PARALLEL_MAKE = -j 4
#
# For a quad-core machine, BB_NUMBER_THREADS = 4, PARALLEL_MAKE = -j 4
would
# be appropriate for example.
@@ -48,7 +48,8 @@
#MACHINE ?= routerstationpro
#
# This sets the default machine to be qemux86 if no other machine is selected:
-MACHINE ??= qemux86
+#MACHINE ??= qemux86
+MACHINE ??= vexpressa9
#
# Where to place downloads
@@ -63,6 +64,8 @@
#
#DL_DIR ?= ${TOPDIR}/downloads
+INCOMPATIBLE_LICENSE = GPLv3
+
#
# Where to place shared-state files
#
@@ -99,7 +102,7 @@
# Ultimately when creating custom policy, people will likely end up subclassing
# these defaults.
#
-DISTRO ?= poky
+DISTRO ?= poky-ivi-systemd
# As an example of a subclass there is a bleeding edge policy configuration
# where many versions are set to the absolute latest code from the upstream
# source control systems. This is just mentioned here as an example, its not
gmacario@mv-linux-powerhorse:/scratch/gmacario/genivi-baseline/build$
(2013-04-08 15:14 CEST)
Start the build
time bitbake foton-image
Result
gmacario@mv-linux-powerhorse:/scratch/gmacario/genivi-baseline/build$ time
bitbake -k foton-image
Pseudo is not present but is required, building this first before the main build
Parsing recipes: 100%
|#|
Time: 00:00:19
Parsing of 828 .bb files complete (0 cached, 828 parsed). 1136 targets, 82
skipped, 0 masked, 0 errors.
ERROR: No recipes available for:
/scratch/gmacario/genivi-baseline/meta-ivi/recipes-graphics/xorg-xserver/xserver-xorg_1.14.0.bbappend
ERROR: Command execution failed: Exited with 1
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
real0m27.805s
user2m37.490s
sys 0m4.904s
gmacario@mv-linux-powerhorse:/scratch/gmacario/genivi-baseline/build$
Cordiali Saluti / Best Regards
--
Gianpaolo Macario
Senior Member Technical Staff
Mentor Graphics - Linux Transportation Solutions
email: gianpaolo_maca...@mentor.com
phone: +39-02-249894.208
http://www.mentor.com/ivi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problem Installing Package Manager in FRI2
Hello, I'm trying to generate an image for the FRI2 using the official Intel BSP provided in the Yocto Project website, in this image I want to include at least one package manager. I'm Using poky 8.0 with Hob GUI, from the recipes listed that can be included in the image I can see Dpkg and Zypper package managers, but I have trouble with both packages. I'm unable to create the Image whenever Dpkg is included because of the following error message: error: Failed dependencies: /home/poky-danny-8.0/build/tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl is needed by dpkg-1.16.8-r18.0.core2 I get this message even tho the files do exist at the path specified by the error message. On the other hand whenever I select Zypper, the image is created correctly but any zypper commands ends up showing the following error: zypper: dbconfig.c:493: db3New: Assertion 'dbOpts != ((void *)0) *db0pts != '\0'' failed. Aborted I'm I missing something during the Image creation? Thank You for your time. -- Esteban Rivera ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] [eclipse-poky][master]Check build directory when location is set using Browse button
Hi Jessica,
I can reproduce this issue following these steps:
- open yocto-bsp menu
- set metadata location
- set build location directory using browse button and without interfering with
the text field at all
- set output location to new directory
- press Next
- select a Kernel from the combo
The problem is that we only check the build directory when the focus is lost in
the text field, and we do not take into account when the value of this field is
populated using Browse button.
We must check for the build directory in the first page of the wizard, because
any of the actions that can be done on the properties page(2nd) needs to have a
functional build directory and will fail otherwise.
The validatePage() method is only taken into consideration when we an finish
the wizard without any further user interaction.
Thanks,
Ioana
From: Zhang, Jessica
Sent: Saturday, April 06, 2013 2:04 AM
To: Grigoropol, IoanaX; yocto@yoctoproject.org
Subject: RE: [yocto] [PATCH] [eclipse-poky][master]Check build directory when
location is set using Browse button
Hi Ioana,
I can't reproduce the bug on my end so can't further debug the issue. But
based on the context of this patch, seems we're missing checkBuildDir for
buildLocation? By looking at the code, shouldn't the easiest fix is to add
checkBuildDir on the validatePage for the case the buildLocationText is not
empty?
Thanks,
Jessica
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Ioana Grigoropol
Sent: Friday, April 05, 2013 7:31 AM
To: yocto@yoctoproject.org
Subject: [yocto] [PATCH] [eclipse-poky][master]Check build directory when
location is set using Browse button
[Yocto #4206]
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
---
.../sdk/remotetools/wizards/bsp/MainPage.java | 57 +++-
1 file changed, 43 insertions(+), 14 deletions(-)
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
index d84cc24..156829b 100644
---
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wi
+++ zards/bsp/MainPage.java
@@ -25,6 +25,7 @@ import org.eclipse.swt.events.ModifyEvent;
import org.eclipse.swt.events.ModifyListener;
import org.eclipse.swt.events.SelectionAdapter;
import org.eclipse.swt.events.SelectionEvent;
+import org.eclipse.swt.events.SelectionListener;
import org.eclipse.swt.layout.GridData; import
org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Button;
@@ -108,7 +109,8 @@ public class MainPage extends WizardPage {
controlChanged(e.widget);
}
});
- setBtnMetadataLoc(addFileSelectButton(textContainer,
textMetadataLoc));
+ buildLocationListener = new BuildLocationListener();
+ setBtnMetadataLoc(addFileSelectButton(textContainer,
textMetadataLoc,
+null));
labelBuildLoc = new Label(composite, SWT.NONE);
labelBuildLoc.setText(Build location: ); @@ -118,10 +120,10
@@ public class MainPage extends WizardPage {
textContainer.setLayoutData(new GridData(SWT.FILL, SWT.CENTER,
true, false));
textBuildLoc = (Text)addTextControl(textContainer, );
- buildLocationListener = new BuildLocationListener();
textBuildLoc.addFocusListener(buildLocationListener);
+ textBuildLoc.addModifyListener(buildLocationListener);
- setBtnBuilddirLoc(addFileSelectButton(textContainer,
textBuildLoc));
+ setBtnBuilddirLoc(addFileSelectButton(textContainer,
textBuildLoc,
+buildLocationListener));
labelBspName = new Label(composite, SWT.NONE);
labelBspName.setText(BSP Name*: );
@@ -152,7 +154,7 @@ public class MainPage extends WizardPage {
controlChanged(e.widget);
}
});
- setBtnBspOutLoc(addFileSelectButton(textContainer,
textBspOutputLoc));
+ setBtnBspOutLoc(addFileSelectButton(textContainer,
textBspOutputLoc,
+null));
labelKArch = new Label(composite, SWT.NONE);
labelKArch.setText(Kernel Architecture*: ); @@ -206,18
+208,25 @@ public class MainPage extends WizardPage {
return text;
}
- private Button addFileSelectButton(final Composite parent, final Text
text) {
+ private Button addFileSelectButton(final Composite parent, final Text
+text, SelectionListener listener) {
Button button = new Button(parent, SWT.PUSH | SWT.LEAD);
button.setText(Browse...);
-
Re: [yocto] [meta-ivi] No recipes available for: meta-ivi/recipes-graphics/xorg-xserver/xserver-xorg_1.14.0.bbappend
Hello Gianpaolo, Hello I am afraid I discovered a bug against the GENIVI Foton-0.1 Yocto Baseline. I followed the instructions at http://git.yoctoproject.org/cgit/cgit.cgi/meta- ivi/tree/README.md?h=4.0 I suspect some misalignment between meta-ivi and poky SHA - however I believe I followed what the README.me says. Thank you in advance for any help or suggestions! You may be right, try the poky master. And in case that works for you, please sent a patch. Regards, Holger -- Holger Behrens, Principal Technologist, Wind River Wind River GmbH, Sitz: Ismaning / Registergericht: AG München, HRB-Nr 97784, Geschäftsführer: Jane Bone, Andreas Pabinger ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] working my way through the kernel hands-on labs finally
finally have the time to work my way through the ELC 2013 hands on kernel labs described here: https://www.yoctoproject.org/tools-resources/presentations/working-kernel since i'll almost certainly use some of them in my next yocto course, so the occasional question for anyone who's already been down this road. start with lab 1. the doc mentions including the meta-yocto and meta-yocto-bsp layers -- are those strictly necessary? the layer.conf definition file for the lab1 layer doesn't list those layers as dependencies. what will happen if i leave them out? what's the policy on explicitly listing dependencies on those two layers in a new layer? also, just doing a basic fetch for lab1 produces: ERROR: QA Issue: /home/rpjday/yocto/k_lab/layers/meta-lab1-qemux86/recipes-kernel/linux/linux_3.0.18.bb: Variable FILES is set as not being package specific, please fix this. is that deliberate? something that will be resolved later in the lab as part of an exercise? just curious. 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] working my way through the kernel hands-on labs finally
On 13-04-08 11:41 AM, Robert P. J. Day wrote: finally have the time to work my way through the ELC 2013 hands on kernel labs described here: https://www.yoctoproject.org/tools-resources/presentations/working-kernel since i'll almost certainly use some of them in my next yocto course, so the occasional question for anyone who's already been down this road. start with lab 1. the doc mentions including the meta-yocto and meta-yocto-bsp layers -- are those strictly necessary? the layer.conf definition file for the lab1 layer doesn't list those layers as dependencies. what will happen if i leave them out? what's the policy on explicitly listing dependencies on those two layers in a new layer? also, just doing a basic fetch for lab1 produces: ERROR: QA Issue: /home/rpjday/yocto/k_lab/layers/meta-lab1-qemux86/recipes-kernel/linux/linux_3.0.18.bb: Variable FILES is set as not being package specific, please fix this. is that deliberate? something that will be resolved later in the lab as part of an exercise? just curious. Probably not deliberate, the kernel labs aren't about packaging. Which branch are you using for your tests ? Even if it's an old release branch, there may have been some QA backports between the time the lab was done, and the time you are running it. Bruce rday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] working my way through the kernel hands-on labs finally
On Mon, 8 Apr 2013, Bruce Ashfield wrote: On 13-04-08 11:41 AM, Robert P. J. Day wrote: finally have the time to work my way through the ELC 2013 hands on kernel labs described here: https://www.yoctoproject.org/tools-resources/presentations/working-kernel since i'll almost certainly use some of them in my next yocto course, so the occasional question for anyone who's already been down this road. start with lab 1. the doc mentions including the meta-yocto and meta-yocto-bsp layers -- are those strictly necessary? the layer.conf definition file for the lab1 layer doesn't list those layers as dependencies. what will happen if i leave them out? what's the policy on explicitly listing dependencies on those two layers in a new layer? also, just doing a basic fetch for lab1 produces: ERROR: QA Issue: /home/rpjday/yocto/k_lab/layers/meta-lab1-qemux86/recipes-kernel/linux/linux_3.0.18.bb: Variable FILES is set as not being package specific, please fix this. is that deliberate? something that will be resolved later in the lab as part of an exercise? just curious. Probably not deliberate, the kernel labs aren't about packaging. Which branch are you using for your tests ? Even if it's an old release branch, there may have been some QA backports between the time the lab was done, and the time you are running it. i'm using HEAD for everything, even though the labs dictate poky-danny-8.0.1; if anything breaks because of that, i'll make a note of it. 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] working my way through the kernel hands-on labs finally
On 13-04-08 12:02 PM, Robert P. J. Day wrote: On Mon, 8 Apr 2013, Bruce Ashfield wrote: On 13-04-08 11:41 AM, Robert P. J. Day wrote: finally have the time to work my way through the ELC 2013 hands on kernel labs described here: https://www.yoctoproject.org/tools-resources/presentations/working-kernel since i'll almost certainly use some of them in my next yocto course, so the occasional question for anyone who's already been down this road. start with lab 1. the doc mentions including the meta-yocto and meta-yocto-bsp layers -- are those strictly necessary? the layer.conf definition file for the lab1 layer doesn't list those layers as dependencies. what will happen if i leave them out? what's the policy on explicitly listing dependencies on those two layers in a new layer? also, just doing a basic fetch for lab1 produces: ERROR: QA Issue: /home/rpjday/yocto/k_lab/layers/meta-lab1-qemux86/recipes-kernel/linux/linux_3.0.18.bb: Variable FILES is set as not being package specific, please fix this. is that deliberate? something that will be resolved later in the lab as part of an exercise? just curious. Probably not deliberate, the kernel labs aren't about packaging. Which branch are you using for your tests ? Even if it's an old release branch, there may have been some QA backports between the time the lab was done, and the time you are running it. i'm using HEAD for everything, even though the labs dictate poky-danny-8.0.1; if anything breaks because of that, i'll make a note of it. That's what I wondered. These were all done against 1.3, so the QA warning (and other issues you'll see) are very likely caused by this skew. For the next round of conferences, there are plans to update them to use 1.4 and get required cleanup. Bruce rday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] working my way through the kernel hands-on labs finally
On Mon, 8 Apr 2013, Bruce Ashfield wrote: On 13-04-08 12:02 PM, Robert P. J. Day wrote: On Mon, 8 Apr 2013, Bruce Ashfield wrote: On 13-04-08 11:41 AM, Robert P. J. Day wrote: finally have the time to work my way through the ELC 2013 hands on kernel labs described here: https://www.yoctoproject.org/tools-resources/presentations/working-kernel since i'll almost certainly use some of them in my next yocto course, so the occasional question for anyone who's already been down this road. start with lab 1. the doc mentions including the meta-yocto and meta-yocto-bsp layers -- are those strictly necessary? the layer.conf definition file for the lab1 layer doesn't list those layers as dependencies. what will happen if i leave them out? what's the policy on explicitly listing dependencies on those two layers in a new layer? also, just doing a basic fetch for lab1 produces: ERROR: QA Issue: /home/rpjday/yocto/k_lab/layers/meta-lab1-qemux86/recipes-kernel/linux/linux_3.0.18.bb: Variable FILES is set as not being package specific, please fix this. is that deliberate? something that will be resolved later in the lab as part of an exercise? just curious. Probably not deliberate, the kernel labs aren't about packaging. Which branch are you using for your tests ? Even if it's an old release branch, there may have been some QA backports between the time the lab was done, and the time you are running it. i'm using HEAD for everything, even though the labs dictate poky-danny-8.0.1; if anything breaks because of that, i'll make a note of it. That's what I wondered. These were all done against 1.3, so the QA warning (and other issues you'll see) are very likely caused by this skew. For the next round of conferences, there are plans to update them to use 1.4 and get required cleanup. okey dokey. 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] supplying your own defconfig in a kernel recipe
a bit of inconsistent wording between the kernel hands-on lab1 and
the kernel dev manual (unless i'm misreading).
in lab1, we read:
This is a bare-bones simple Linux kernel recipe. It inherits all of
the logic for configuring and building the kernel from the
kernel.bbclass (the 'inherit kernel' line). It specifies the Linux
kernel sources in SRC_URI as a recent tarball release from kernel.org.
It also specifies a defconfig, this file is used as the .config to
build the kernel. It is empty for now, so the Linux kernel
configuration system will use defaults.
suggesting an empty defconfig will force the config step to use
defaults. but the kernel dev manual states:
If you have a complete Linux kernel .config file you want to use,
copy it to the ${FILES} directory within your layer and name it
defconfig. Then, add the following line to your linux-yocto
.bbappend file in your layer:
SRC_URI += file://defconfig
which suggests to the reader that a user-supplied defconfig file
should represent *only* a complete .config file.
the kernel.bbclass itself seems to suggest that your defconfig file
can represent any part of the configuration you want to override the
default.
does anyone else see the apparent inconsistency that might trip up a
reader?
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] GDB problems
On Apr 8, 2013, at 5:47 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Does installing eglibc-dbg help with this? (Assuming you don't have this installed already.) libc6-dev should be enough. You do not need -dbg one. If it does not work with -dev then we have a problem. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem with mouse and keyboard detection in yocto (core-image-sato on emenlow)
I tried to rebuild the xf86-input-evdev; however the core-image-sato still insists on using the default mouse / keyboard drivers instead of evdev. Also no /dev/input/event* entries exist (only /dev/input/mice and /dev/input/mouse0). Concerning removing xf86-input-mouse / xf86-input-keyboard from the image, what is the easiest way to achieve this using yocto? I have created a custom bitbake recipe already, inheriting from core-image-sato, which adds a few packages. Can removal of packages be easily specified in the custom recipe as well? //Andreas -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: 8. huhtikuuta 2013 15:19 To: Andreas Enbacka Cc: yocto@yoctoproject.org Subject: Re: [yocto] Problem with mouse and keyboard detection in yocto (core-image-sato on emenlow) On 8 April 2013 13:12, Andreas Enbacka aenba...@gmail.com wrote: I rebuilt xf86-input-keyboard and xf86-input-mouse (as well as the core-image-sato image), and now the mouse / keyboard works ok in X. Thanks for the assistance. I checked the Xorg log file, it seems to add the mouse using the mouse_drv.so module, not evdev_drv.so. Do I need to rebuild xf86-input-evdev as well to get the mouse added using evdev? This because I have a custom application that handles the touch screen calibration running on top of X, and itexpects the mouse to be added via evdev. Probably - you could try removing the mouse and keyboard drivers and leaving just evdev if it still prefers mouse/keyboard over evdev. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, April 09, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US Canada).
Agenda: * Opens collection - 5 min (Song) * Yocto Project 1.4 M5 release readiness review - 10 min (CCB/community) * Yocto 1.4 status - 10 min (Song/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status * SWAT team rotation: Bogdan Marinescu - Laurentiu Palcu * Opens - 10 min * Team Sharing - 20 min -Original Appointment- We encourage people attending the meeting to logon the Yocto IRC chancel during the meeting (optional): Yocto IRC: http://webchat.freenode.net/?channels=#yocto IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html Conference details Conference name:Yocto Technical Team Conference date/start time: Tue Jun 26, 2012 at 10:00 AM Central Daylight Time Participants: 30 Duration: 60 minutes Participant passcode: 76994298 Dial-in number: 1.972.995. US Toll Free number:1.877.561.6828 BlackBerry users, click this link to join your conference as a participant: 1.972.995.x76994298# Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode. Local and Global Access Numbers Country Dial-in number Australia: 1800 636 843 Czech Republic: 242 430 350 China (Beijing): From office dial 8-995 or 8784277 Beijing Out of Office dial 5878 4277 China (Shanghai): From office dial 8-995 or 3073322 Shanghai Out of Office dial 2307 3322 China (Shenzen): From office dial 8-995 or 6007877 Shenzen Out of Office dial 2600 7877 China (Other Cities): From IP phone dial 8-995 Other cities - Non IP phone dial 021-23073322 Denmark: 8060 1400 Finland: 09 41333477 France: 0497 275888 Germany: 08161 803232 Holland: 030 2417490 India: BSNL subscribers use 1800 425 9996 (Toll Free) Airtel subscribers use 0008 009 861 212 (Toll Free) From TI Campus use 8995 Others use 2509 9555 (Landline within Bangalore) or 80 2509 9555 (Outside Bangalore) Israel: 09 790 6715 Italy: 039 69061234 (039 is local city code not country code) Japan: From TI Campus use 8 995 Outside TI use 03 4331 3777 Malaysia: From IP phone dial 2643799 From Kuala Lumpur dial 4264 3799 Outside Kuala Lumpur dial (03)4264 3799 Norway: 2 295 8744 Philippines: From Baguio City use 4471177 From Metro Manila area use 8702477 Singapore: From IP phone dial 3894777 Outside TI use 6389 4777 South Korea: From IP phone dial 5606998 From Seoul dial 5606998 Outside Seoul dial (02)5606998 Sweden: 08 58755577 Taiwan: From IP phone dial 1363 From Taipei dial 2241 1363 Outside Taipei dial (02)2241 1363 Turkey: Landline Only dial 0811 288 0001 then enter 877 633 1123 UK: 01604 663003 US: 972 995 or 1877 561 6828 Recurring conferences First scheduled conference: Tue Jun 26, 2012 Recurrence frequency: Weekly - Every 1 week(s) on Tuesday Recurrence ends:End on Fri Jun 21, 2013, 10:40 AM CDT ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC: Post build configuration
On Thu, Apr 4, 2013 at 6:42 PM, Sean Liming sean.lim...@annabooks.com wrote: Why post-build instead of pre-build? The idea is that you have one build, and you are manufacturing 5000 devices. So you take this one build and load it on each of your identical devices which you then sell to your customers. But if each device you sell is supposed to have a unique piece of configuration information, you don't want to have to create 5000 builds, one for each device, do you? In other words, this unique data shouldn't be part of the build, you wouldn't want to have to start a new build just because you want to change this unique data? Ideally you would create one build. Then, just before loading this build onto a given device, you do something to set this unique piece of information (i.e. post-build) for this one device, then you repeat for the remaining 4999 devices. The assumption here is that builds are expensive (i.e. slow) while post-build configuration would be cheap (i.e. quick, easy, fast). ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-ivi][PATCH] README.md: Fix poky SHA
Hi Holger, Using master (and not the SHA advertised in README.md) the build was actually successful. Attaching patch. Signed-off-by: Gianpaolo Macario gianpaolo_maca...@mentor.com --- README.md |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index b2c84f9..f17a606 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,7 @@ Layer Dependencies URI: git://git.yoctoproject.org/poky branch: master -revision: d823759b4594143d522eae0b2a2498436a6dcb1e +revision: a6502081b7c7acc49187aa7c68ad19e0751ee030 Using the above git sha's and master meta-ivi, bitbaking foton-image is known to work (the foton-image build should be GENIVI 4.0 compliant). -- 1.7.9.5 Cordiali Saluti / Best Regards -- Gianpaolo Macario Senior Member Technical Staff Mentor Graphics - Linux Transportation Solutions email: gianpaolo_maca...@mentor.com http://www.mentor.com/ivi -Original Message- From: Behrens, Holger [mailto:holger.behr...@windriver.com] Sent: Monday, April 08, 2013 5:34 PM To: Macario, Gianpaolo Cc: yocto@yoctoproject.org; Sarbu, Florin-Ionut (Florin) Subject: RE: [yocto] [meta-ivi] No recipes available for: meta-ivi/recipes- graphics/xorg-xserver/xserver-xorg_1.14.0.bbappend Hello Gianpaolo, Hello I am afraid I discovered a bug against the GENIVI Foton-0.1 Yocto Baseline. I followed the instructions at http://git.yoctoproject.org/cgit/cgit.cgi/meta- ivi/tree/README.md?h=4.0 I suspect some misalignment between meta-ivi and poky SHA - however I believe I followed what the README.me says. Thank you in advance for any help or suggestions! You may be right, try the poky master. And in case that works for you, please sent a patch. Regards, Holger ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC: Post build configuration
-Original Message- From: Trevor Woerner [mailto:twoer...@gmail.com] Sent: Monday, April 08, 2013 1:28 PM To: Sean Liming Cc: Venkata ramana gollamudi; yocto@yoctoproject.org; Sanil kumar Subject: Re: [yocto] RFC: Post build configuration On Thu, Apr 4, 2013 at 6:42 PM, Sean Liming sean.lim...@annabooks.com wrote: Why post-build instead of pre-build? The idea is that you have one build, and you are manufacturing 5000 devices. So you take this one build and load it on each of your identical devices which you then sell to your customers. But if each device you sell is supposed to have a unique piece of configuration information, you don't want to have to create 5000 builds, one for each device, do you? In other words, this unique data shouldn't be part of the build, you wouldn't want to have to start a new build just because you want to change this unique data? Ideally you would create one build. Then, just before loading this build onto a given device, you do something to set this unique piece of information (i.e. post-build) for this one device, then you repeat for the remaining 4999 devices. The assumption here is that builds are expensive (i.e. slow) while post- build configuration would be cheap (i.e. quick, easy, fast). Excellent. That makes a lot of sense. Is this post-build utility an active project for the Yocto Project or is it just getting started? Is it a menu driven item / something that we can include via a layer? Regards, Sean Liming ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC: Post build configuration
On Mon, Apr 8, 2013 at 5:49 PM, Sean Liming sean.lim...@annabooks.com wrote: Is this post-build utility an active project for the Yocto Project or is it just getting started? It's only in the discussion phase right now, hence the RFC in the subject line. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] what's the situation with MIPS support/BSPs/dev kits in yocto?
other than the canonical routerstation pro in the meta-yocto-bsp layer, is there any serious work being put into MIPS machines? a quick google didn't seem to find anything, and the rs pro itself was end-of-lifed a while back (as i recall), so is there something else if one wants to use yocto on a MIPS dev kit? 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] what's the situation with MIPS support/BSPs/dev kits in yocto?
On 13-04-08 5:59 PM, Robert P. J. Day wrote: other than the canonical routerstation pro in the meta-yocto-bsp layer, is there any serious work being put into MIPS machines? a quick google didn't seem to find anything, and the rs pro itself was end-of-lifed a while back (as i recall), so is there something else if one wants to use yocto on a MIPS dev kit? From: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2444 MIPS suggested refresh: http://www.ubnt.com/edgemax .. but I've yet to complete the due diligence on seeing if I can actually purchase one :) That's going to happen shortly after yocto 1.4 completes. Bruce rday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] what's the situation with MIPS support/BSPs/dev kits in yocto?
On Mon, 8 Apr 2013, Bruce Ashfield wrote: On 13-04-08 5:59 PM, Robert P. J. Day wrote: other than the canonical routerstation pro in the meta-yocto-bsp layer, is there any serious work being put into MIPS machines? a quick google didn't seem to find anything, and the rs pro itself was end-of-lifed a while back (as i recall), so is there something else if one wants to use yocto on a MIPS dev kit? From: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2444 MIPS suggested refresh: http://www.ubnt.com/edgemax .. but I've yet to complete the due diligence on seeing if I can actually purchase one :) That's going to happen shortly after yocto 1.4 completes. it would appear there's a canadian branch of ubiquiti: http://ubnt.ca/en/8-edgemax but based on what i remember about ubiquiti, it's *excruciating* to try to figure out how to buy anything from them. 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] what's the situation with MIPS support/BSPs/dev kits in yocto?
On Mon, 8 Apr 2013, Bruce Ashfield wrote: On 13-04-08 5:59 PM, Robert P. J. Day wrote: other than the canonical routerstation pro in the meta-yocto-bsp layer, is there any serious work being put into MIPS machines? a quick google didn't seem to find anything, and the rs pro itself was end-of-lifed a while back (as i recall), so is there something else if one wants to use yocto on a MIPS dev kit? From: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2444 MIPS suggested refresh: http://www.ubnt.com/edgemax .. but I've yet to complete the due diligence on seeing if I can actually purchase one :) That's going to happen shortly after yocto 1.4 completes. ok, based on a bit more reading, it *seems* that the phrase edgemax refers to a platform, while an actual router based on that platform might be the edgerouter lite: http://ubnt.ca/en/edgemax/61-edgemax.html does that make sense? if you look at this page: http://ubnt.ca/en/8-edgemax it seems that the edgerouter lite is the single actual product in that category, and it appears to be buyable online. 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] RFC: Post build configuration
The process that you are describing is commonly called device provisioning. I have experienced this process from different angles: working for a company making functional test equipment for electronics production lines and working for a company providing software for set-top boxes. From this experience provisioning is frequently done during production at the end of the process when the automated functional test is performed. During these tests the devices are fired up, get their device image installed, receive their individual programming and are tested. Dependent on the device there are many methods on how to do it. I have used serial ports, networked provisioning servers, direct programming of OTP or flash using the tester, etc. It may be a cool thing to have for YP but it may also somewhat out of the scope of YP. In one way or another you will always have to put your data onto the root file system. Unfortunately, creating a root file system is always somewhat expensive and time consuming. Many times when I am making changes to my YP build environment just rebuilding a single package creating the root file system is the most time consuming part of the process. My preferred way of provisioning is a networked provisioning server. In most cases, you will have to store the configuration data anyway, so I store it in a database on the provisioning server. I have not done this with YP but if had to do it I would look into using TCF. When the device boots it starts up TCF. The provisioning server connects to the TCF server on the device, pushes the files it needs, etc. It's a fun project but if you look at it from that angle it's not that much related to YP as a build system. It's like any other application package. You build it with YP and add it to the root file system. :rjs ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] working my way through the kernel hands-on labs finally
On Mon, 2013-04-08 at 11:41 -0400, Robert P. J. Day wrote: finally have the time to work my way through the ELC 2013 hands on kernel labs described here: https://www.yoctoproject.org/tools-resources/presentations/working-kernel since i'll almost certainly use some of them in my next yocto course, so the occasional question for anyone who's already been down this road. start with lab 1. the doc mentions including the meta-yocto and meta-yocto-bsp layers -- are those strictly necessary? the layer.conf definition file for the lab1 layer doesn't list those layers as dependencies. what will happen if i leave them out? what's the policy on explicitly listing dependencies on those two layers in a new layer? The bblayers.conf for the labs is just the bblayers.conf that gets generated the first time you source oe-init-build-env in poky, which is what the lab is based on. You shouldn't need those layers - the BSPs should work fine outside of poky, but since this is a yocto lab and it uses poky, there's no need to make a point of removing them - actually, I haven't tried removing those layers - meta-yocto-bsp could certainly be removed since it's all machine-specific to existing BSPs, but it's easy enough to remove them and see... also, just doing a basic fetch for lab1 produces: ERROR: QA Issue: /home/rpjday/yocto/k_lab/layers/meta-lab1-qemux86/recipes-kernel/linux/linux_3.0.18.bb: Variable FILES is set as not being package specific, please fix this. is that deliberate? something that will be resolved later in the lab as part of an exercise? just curious. The labs are and should be targeted to a specific release for exactly the reason you just discovered - in this case, the main metadata promoted various QA Issues into errors immediately following the release. In this case you were lucky and hit an example of something obvious, most of the time it's not that obvious - basically if you do anything outside of what's specified in the labs, especially working from master, all bets are off... Tom rday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
