[yocto] Installation of i686 SDK on a x86_64 machine?
Hi, in previous releases it ha always been possible to install a SDK configured for a i686 machine on both x86 and x86_64 systems. Since commit c04f5435 populate_sdk_base.bbclass: use SDK_ARCH instead of SDKMACHINE this does not work any more; instead, installation will abort with Error: Installation machine not supported! ++ uname -m ++ sed -e 's/i[3-6]86/ix86/' -e 's/x86[-_]64/x86_64/' + INST_ARCH=x86_64 ++ echo i686 ++ sed -e 's/i[5-6]86/ix86/' + SDK_ARCH=ix86 + '[' x86_64 '!=' ix86 ']' + echo 'Error: Installation machine not supported!' Error: Installation machine not supported! + exit -1 Is this intended behaviour (and if so, why?) or rather a bug that should be reported and fixed? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If there was anything that depressed him more than his own cynicism, it was that quite often it still wasn't as cynical as real life. - Terry Pratchett, _Guards! Guards!_ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Installation of i686 SDK on a x86_64 machine?
Hi Wolfgang, On 01/22/2013 09:16 AM, Wolfgang Denk wrote: Hi, in previous releases it ha always been possible to install a SDK configured for a i686 machine on both x86 and x86_64 systems. Since commit c04f5435 populate_sdk_base.bbclass: use SDK_ARCH instead of SDKMACHINE this does not work any more; instead, installation will abort with Error: Installation machine not supported! ++ uname -m ++ sed -e 's/i[3-6]86/ix86/' -e 's/x86[-_]64/x86_64/' + INST_ARCH=x86_64 ++ echo i686 ++ sed -e 's/i[5-6]86/ix86/' + SDK_ARCH=ix86 + '[' x86_64 '!=' ix86 ']' + echo 'Error: Installation machine not supported!' Error: Installation machine not supported! + exit -1 Is this intended behaviour (and if so, why?) or rather a bug that should be reported and fixed? This is the intended behavior. Please check: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3269 Also, this thread: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-November/031519.html If people really need to install SDK tarballs intended for other hosts than the SDK was built for (i686 on x86_64 or vice-versa), we could add a -f flag to force installation and show an error message like this: Error: Installation machine not supported! Use -f to force installation. Thanks, Laurentiu Thanks in advance. Best regards, Wolfgang Denk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Installation of i686 SDK on a x86_64 machine?
Dear Laurentiu, In message 50fe4900.7020...@intel.com you wrote: in previous releases it ha always been possible to install a SDK configured for a i686 machine on both x86 and x86_64 systems. Since commit c04f5435 populate_sdk_base.bbclass: use SDK_ARCH instead of SDKMACHINE this does not work any more; instead, installation will abort with Error: Installation machine not supported! ... Is this intended behaviour (and if so, why?) or rather a bug that should be reported and fixed? This is the intended behavior. Please check: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3269 Sorry, but this bug is about a different problem - the fix overshoots the mark. The following combinations of SDK_ARCH and INST_ARCH are possible and relevant here: Id SDK_ARCHINST_ARCH Status == 1 ix86ix86works 2 ix86x86_64 works 3 x86_64 ix86cannot work 4 x86_64 x86_64 works The bug report is about case 3 - attempting to install a 64 bit SDK on a 32 bit machine. This indeed cannot work and shuld be prevented byy the installer. But the current code also prevents case 2, installing 32 bit images on a 64 bit machine, which works perfectly fine (assuming you have the needed 32 bit libraries installed). For any distribution it is very convenient to provide only one set of images (configured for ix86), as these images will work both on 32 and 64 bit systems. I consider it a major drawback if you intentionally prevent such use. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'm not a god, I was misquoted. - Lister, Red Dwarf ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH v2] [eclipse-poky][branch:windows-build]Performance fix for Windows implementation
Hi Jessica,
This patch applies on top of the last patch I sent on Thursday,
[PATCH] [eclipse-poky][branch:windows-build]Performance fix for Linux
implementation.
Attached is my local git log.
Please let me know it there are any problems.
Thanks,
Ioana
-Original Message-
From: Zhang, Jessica
Sent: Tuesday, January 22, 2013 12:30 AM
To: Grigoropol, IoanaX; yocto@yoctoproject.org
Subject: RE: [yocto] [PATCH v2] [eclipse-poky][branch:windows-build]Performance
fix for Windows implementation
Hi Ioana,
This patch seems not apply to the code of the latest windows-build, can you do
a rebase?
Thanks,
Jessica
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Ioana Grigoropol
Sent: Monday, January 21, 2013 6:37 AM
To: yocto@yoctoproject.org
Subject: [yocto] [PATCH v2] [eclipse-poky][branch:windows-build]Performance fix
for Windows implementation
- run each command in a separate shell - needs explicit sourcing of
environment and closing for each command
- add distinction between OEFS URI and actual URI of the remote project and
files - YoctoLocation of the project contains both URIs
- use OEFS URI only for initialization of
OEFSFileSystem,OEIgnoredPaths, OEFile (oefs://...)
- use actual URI (file:// or rse://) for all other operations (new
file, copy, save, delete)
- tested only against Windows machine RSE connection to BuildAppliance
machine
IMPORTANT: please make sure that sshd configurations on the remote machine has
variable MaxSessions set to a reasonable number (more than the default 10
sessions), otherwise an Error creating terminal will be thrown when more
channels are opened for running remote commands (ChannelSftp)
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
---
.../src/org/yocto/bc/bitbake/BBRecipe.java |2 +-
.../src/org/yocto/bc/bitbake/BBSession.java| 30 +++--
.../src/org/yocto/bc/bitbake/ShellSession.java | 10 +-
.../org/yocto/bc/remote/utils/CommandRunnable.java |3 +-
.../org/yocto/bc/remote/utils/RemoteHelper.java| 19
.../org/yocto/bc/remote/utils/RemoteMachine.java | 31 +++---
.../src/org/yocto/bc/ui/Activator.java | 12 +-
.../editors/bitbake/BitBakeDocumentProvider.java | 27 +++--
.../bc/ui/editors/bitbake/BitBakeFileEditor.java |2 +-
.../bitbake/BitBakeSourceViewerConfiguration.java | 20 +++-
.../src/org/yocto/bc/ui/filesystem/OEFile.java | 115
.../org/yocto/bc/ui/filesystem/YoctoLocation.java | 36 ++
.../src/org/yocto/bc/ui/model/ProjectInfo.java | 38 ---
.../src/org/yocto/bc/ui/model/YoctoHostFile.java | 20 ++--
.../ui/wizards/NewBitBakeFileRecipeWizardPage.java | 19 +++-
.../importProject/ImportYoctoProjectWizard.java|4 +-
.../yocto/bc/ui/wizards/install/InstallWizard.java |4 +-
.../yocto/bc/ui/wizards/install/OptionsPage.java |8 +-
.../BBConfigurationInitializeOperation.java|2 +-
.../newproject/CreateBBCProjectOperation.java |7 +-
20 files changed, 233 insertions(+), 176 deletions(-) create mode 100755
plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/filesystem/YoctoLocation.java
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBRecipe.java
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBRecipe.java
index 6d003ce..e8e8d30 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBRecipe.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBRecipe.java
@@ -23,7 +23,7 @@ public class BBRecipe extends BBSession {
private final URI fileURI;
public BBRecipe(BBSession session, URI filePath) throws IOException {
- super(session.shell, session.pinfo.getURI());
+ super(session.shell, session.pinfo.getOriginalURI());
this.session = session;
this.fileURI = filePath;
this.parsingCmd = DISABLE_SANITY_CHECKS=\1\ bitbake -e -b
+ filePath.getPath() ++ BB_ENV_FILE; diff --git
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
index 9adeb3f..8a8de22 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
@@ -15,6 +15,8 @@ import java.io.File;
import java.io.FileFilter;
import java.io.FileReader;
import java.io.IOException;
+import java.io.InputStream;
+import java.io.InputStreamReader;
import java.net.URI;
import java.util.ArrayList;
import java.util.Arrays;
@@ -33,15 +35,18 @@ import org.eclipse.core.resources.IProject;
import org.eclipse.core.resources.IResource;
import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.core.runtime.IStatus;
+import org.eclipse.core.runtime.NullProgressMonitor;
import org.eclipse.core.runtime.Status; import
Re: [yocto] Installation of i686 SDK on a x86_64 machine?
On 01/22/2013 11:03 AM, Wolfgang Denk wrote: IdSDK_ARCHINST_ARCH Status == 1 ix86ix86works 2 ix86x86_64 works 3 x86_64 ix86cannot work 4 x86_64 x86_64 works The bug report is about case 3 - attempting to install a 64 bit SDK on a 32 bit machine. This indeed cannot work and shuld be prevented byy the installer. But the current code also prevents case 2, installing 32 bit images on a 64 bit machine, which works perfectly fine (assuming you have the needed 32 bit libraries installed). I see your point. Would you please file a bug on this? Thanks, Laurentiu ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] M2, M3, M4 milestones available?
Hello Wolfgang, From a QA point of view, we are approaching the 1.4 M3 milestone. Here is what Saul wrote for the latest Full Pass request: QA Teams: Please do FULL Pass testing on this as a PRE-M3 Full Pass so we have some idea of what's going on. Git Rev: 9eb88ceb39b7d0b8ddc6487e61ce8edadef10ec4 1.4 M2 was kind of blurry because it landed during charismas and new year thus many of us were on vacation. I hope this helped. Have a nice day, Stoicescu Cornel Romania Yocto QA -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Wolfgang Denk Sent: Tuesday, January 22, 2013 9:04 AM To: yocto@yoctoproject.org Subject: [yocto] M2, M3, M4 milestones available? Hello, I wonder if the M2, M3 and M4 milestones have been reached already? The release schedule [1] says they were due on Nov 26 2012, Dec 24 2012 and Jan 11 2013 respectively, and even lists bugs against these. [1] https://wiki.yoctoproject.org/wiki/Yocto_1.4_Schedule However, I cannot find any other git tags but 1.4_M1.rc1 and 1.4_M1.final So are these later milestones available somewhere? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Neckties strangle clear thinking. -- Lin Yutang ___ 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] Installation of i686 SDK on a x86_64 machine?
Dear Laurentiu, In message 50fe5f87.4060...@intel.com you wrote: Id SDK_ARCHINST_ARCH Status == 1 ix86ix86works 2 ix86x86_64 works 3 x86_64 ix86cannot work 4 x86_64 x86_64 works The bug report is about case 3 - attempting to install a 64 bit SDK on a 32 bit machine. This indeed cannot work and shuld be prevented byy the installer. But the current code also prevents case 2, installing 32 bit images on a 64 bit machine, which works perfectly fine (assuming you have the needed 32 bit libraries installed). I see your point. Would you please file a bug on this? Done, with a patch included. Please see https://bugzilla.yoctoproject.org/show_bug.cgi?id=3770 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Worlds are conquered, galaxies destroyed -- but a woman is always a woman. -- Kirk, Conscience of the King, stardate unknown ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] M2, M3, M4 milestones available?
Dear Cornel, In message 33115abc4887814e8a92a08fbc93416b08dc5...@irsmsx103.ger.corp.intel.com you wrote: From a QA point of view, we are approaching the 1.4 M3 milestone. Here is what Saul wrote for the latest Full Pass request: QA Teams: Please do FULL Pass testing on this as a PRE-M3 Full Pass so we have some idea of what's going on. Git Rev: 9eb88ceb39b7d0b8ddc6487e61ce8edadef10ec4 OK, so we have not reached M3 yet. Thanks. Would it not make sense to regularly update the release schedule web page [1] so that it also reports the current state? or is there any other web page where such information is present? [1] https://wiki.yoctoproject.org/wiki/Yocto_1.4_Schedule 1.4 M2 was kind of blurry because it landed during charismas and new year thus many of us were on vacation. So what exactly is the git commit ID of the 1.4 M2 milestone release? I cannot see any matching tag in the git repository? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you use modules, you pay the price. Sane embedded solutions running in tight environments don't use modules :-) -- Benjamin Herrenschmidt in 1258234866.2140.451.camel@pasglop ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] scripts/build.sh: Fixed local build to use the correct repository path
From: Timo Mueller timo.muel...@bmw-carit.de
Signed-off-by: Timo Mueller timo.muel...@bmw-carit.de
---
scripts/build.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/build.sh b/scripts/build.sh
index 54081d5..8d8b4c3 100755
--- a/scripts/build.sh
+++ b/scripts/build.sh
@@ -115,7 +115,7 @@ mkdir ${BUILD_DIR} || fail $? Create temporary build
directory ${BUILD_DIR}
GIT_URL=git://git.pokylinux.org/eclipse-poky.git
if [ $USE_LOCAL_GIT_REPO -eq 1 ]; then
SCRIPT_DIR=`dirname $0`
- GIT_DIR=`readlink -f ${SCRIPTDIR}\..`
+ GIT_DIR=`readlink -f ${SCRIPT_DIR}\..`
GIT_URL=file://${GIT_DIR}
fi
--
1.7.11.7
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
Hi, I am not sure if this is the problem you are struggling with. I am wondering why class module.bbclass behaves completely different than kernel.bbclacc copy the hello-mod_0.1.bb and files folder into my taget layer meta-intel/meta-jasperforest/recipe-kernel, then add MACHINE_EXTRA_ RDEPENDS += kernel-module-hello in the conf/local.conf after build and boot, there's no hello.ko found in the binary image also there's no hello.ko in the tmp/work/... folder If you hello-mod_0.1.bb inherits module class there is no mechanism to create the kernel-module package. This only applies to the kernel.bbclass http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module.bbclass http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module-base.bbclass Have a look at kernel.bbclass instead shows some pathon code which handles the module package creation: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n301 I've fixed this in my layer by stealing the code from kernel.bbclass https://github.com/project-magpie/meta-stlinux/blob/master/recipes-bsp/tdt-driver/tdt-driver.inc With this you can also use the following extends with your module: module_autoload_aotom = aotom and module_conf_stmfb = options stmfb display0=1280x720-32@50:8m:pal:yuv:yuv If you are only inherting from module this have not worked for me. The next part I had to fight against was the fact that in core-image-minimal the package managment information are stripped and thus no pre hooks are executet. So the module is installed in the image but not loaded on boot-up unless you call update-modules by hand. ROOTFS_POSTPROCESS_COMMAND += remove_packaging_data_files ; To prevent this I've defined an image without the stripping: https://github.com/project-magpie/meta-stlinux/blob/master/recipes-core/images/core-image-base.bb I hope this clarify things a little bit regards, Christian Eddy All, There is a new YP manual under development. It is a development manual for Linux kernels in the YP. Darren Hart is the original author of the manual as you probably know. It is still being worked on but it is in HTML form and now part of the yocto-docs/master branch. It is published at http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html [1]. Feel free to access it and comment. Thanks, Scott Scott Rifenbark Intel Corporation Yocto Project Documentation 503.712.2702 503.341.0418 (cell) ___ yocto mailing list yocto@yoctoproject.org [2] https://lists.yoctoproject.org/listinfo/yocto [3] Links: -- [1] http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html [2] mailto:yocto@yoctoproject.org [3] https://lists.yoctoproject.org/listinfo/yocto Hi, I am reposting this to the discussion list and copying Darren Hart. Scott FROM: Eddy Lai GMail [mailto:eddy.lai...@gmail.com] SENT: Monday, January 21, 2013 3:36 PM TO: Rifenbark, Scott M SUBJECT: Re: [yocto] YP Linux Kernel Development Manual hi hi, I follow the kernel development manual 2.5. Incorporating Out-of-Tree Modules, copy the hello-mod_0.1.bb and files folder into my taget layer meta-intel/meta-jasperforest/recipe-kernel, then add MACHINE_EXTRA_ RDEPENDS += kernel-module-hello in the conf/local.conf after build and boot, there's no hello.ko found in the binary image also there's no hello.ko in the tmp/work/... folder Eddy All, There is a new YP manual under development. It is a development manual for Linux kernels in the YP. Darren Hart is the original author of the manual as you probably know. It is still being worked on but it is in HTML form and now part of the yocto-docs/master branch. It is published at http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html [1]. Feel free to access it and comment. Thanks, Scott Scott Rifenbark Intel Corporation Yocto Project Documentation 503.712.2702 503.341.0418 (cell) ___ yocto mailing list yocto@yoctoproject.org [2] https://lists.yoctoproject.org/listinfo/yocto [3] Links: -- [1] http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html [2] mailto:yocto@yoctoproject.org [3] https://lists.yoctoproject.org/listinfo/yocto On Jan 16, 2013, at 11:11 AM, Darren Hart dvh...@linux.intel.com wrote: On 01/15/2013 10:38 AM, Bruce Ashfield wrote: I finally found the entries that I was recalling earlier. They are: https://bugzilla.yoctoproject.org/show_bug.cgi?id=241 https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614 https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968 1614 and 2968 are the most interesting for what you are asking. As you can see the net result of those bugs is that you can get the right parts of the kernel tree in SDK packages, since they include dev packages, and with what is currently in kernel-dev .. it should be enough to build against in the SDK (perhaps with just the LDFLAGS tweaks
[yocto] Web Hob first designs: tell us what you think
Hi all, Over the past couple of weeks we have been working on some ideas for the design of Web Hob. We are know searching for volunteers to give us their opinion about them. It works like this: - We arrange a 30-minute phone call at any time that suits you and a screen-sharing session (using Skype or a tool called Team Viewer - http://www.teamviewer.com) - We give you the URL where our web-based prototype is hosted - You try the prototype and tell us what you think about it If at all possible, we would like to record our conversations so that we can come back to them, but please don't let this stop you from volunteering: if recording makes you uncomfortable, we can live without it. We are trying to gather feedback this week, but if you can't do this week we'll find another time. I wish I could convey how incredibly valuable your feedback is for our design work. If you would like to help, please get in touch with me at belen.barros.p...@intel.com Thanks!! Belen - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-baryon][PATCH 0/4] baryon updates
On Monday 07 January 2013 13:05:37 Kevin Strasser wrote: This patch set contains a change which will not work with versions of poky prior to commit 51cbb5ae76a22d465e2f6c5ef923ec2682624e3b, and therefor should not be applied until after cutting a danny branch. The following changes since commit 9a80f62b1874bbb0819068cf394e9fd920bb84b7: proftpd: conditionally remove /usr/libexec (2012-12-05 16:27:36 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib strassek/baryon-updates http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=strassek/baryon-up dates Kevin Strasser (4): webmin: remove perl-module-warnings-register RDEPENDS ffmpeg: build position independent code where possible baryon-image: use parted instead of util-linux schroedinger: specify the version of MPL in use recipes-extended/images/baryon-image.bb |2 +- recipes-extended/webmin/webmin_1.590.bb |4 ++-- recipes-multimedia/ffmpeg/ffmpeg_0.6.1.bb|3 ++- recipes-multimedia/schroedinger/schroedinger.inc |2 +- 4 files changed, 6 insertions(+), 5 deletions(-) I've merged these, and created a danny branch which excludes the perl-module- warnings-register patch. Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] M2, M3, M4 milestones available?
Dear Elizabeth, In message CAPhnLPCk8byBnRSEB2aMOBPEmZQRfWpNSJ+xj+uX4BVvHKMf=q...@mail.gmail.com you wrote: 1.4 M2 was kind of blurry because it landed during charismas and new year thus many of us were on vacation. So what exactly is the git commit ID of the 1.4 M2 milestone release? I cannot see any matching tag in the git repository? That is because we have merged M2 and M3. See: http://article.gmane.org/gmane.linux.embedded.yocto.general/11075/match=merging+m2 I see - thanks for the information. All this is pretty much frustrating. I mean, you cannot really expect people who are looking for release information to scan the mailing list archives for such bits of scattered information? Especially since what appears to the the Yocto Project's official web site claims that there _has_ been a M2-RC1, M2-RC2 and M2, see [1]: M2 Stabilize schedule Release Candidate and Milestone Release schedule (Full Pass QA test follows every RC build) RC1: 12/26/12 RC2: 1/2/13 M2 release: 1/11/13 [1] https://wiki.yoctoproject.org/wiki/Yocto_1.4_Schedule#M2_Stabilize_schedule It would so nice if we had somewhere, publicly visible at a well known location (like the above page), some correct and useful information. Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you are afraid of loneliness, don't marry. - Chekhov ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] M2, M3, M4 milestones available?
On Tue, Jan 22, 2013 at 3:26 AM, Wolfgang Denk w...@denx.de wrote: Dear Cornel, In message 33115abc4887814e8a92a08fbc93416b08dc5...@irsmsx103.ger.corp.intel.com you wrote: From a QA point of view, we are approaching the 1.4 M3 milestone. Here is what Saul wrote for the latest Full Pass request: QA Teams: Please do FULL Pass testing on this as a PRE-M3 Full Pass so we have some idea of what's going on. Git Rev: 9eb88ceb39b7d0b8ddc6487e61ce8edadef10ec4 OK, so we have not reached M3 yet. Thanks. Would it not make sense to regularly update the release schedule web page [1] so that it also reports the current state? or is there any other web page where such information is present? [1] https://wiki.yoctoproject.org/wiki/Yocto_1.4_Schedule 1.4 M2 was kind of blurry because it landed during charismas and new year thus many of us were on vacation. So what exactly is the git commit ID of the 1.4 M2 milestone release? I cannot see any matching tag in the git repository? Hi Wolfgang, The M2 and M3 milestones were merged. Please see Liu Song's email on Dec 27, in part: Yocto Project CCB has approved our request to merge M2 and M3 together. So there won’t be a M2 release and we will be working toward a M3 release for M2 and M3 features by Feb. 7th, 2013 -mehaf Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you use modules, you pay the price. Sane embedded solutions running in tight environments don't use modules :-) -- Benjamin Herrenschmidt in 1258234866.2140.451.camel@pasglop ___ 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] Adding ALSA to the Yocto SDK
On Jan 21, 2013, at 5:16 PM, Patrick Turley patricktur...@gamestop.com wrote: On Jan 21, 2013, at 4:35 PM, Zhang, Jessica jessica.zh...@intel.com wrote: Hi Patrick, Since you're able to add the dev packages to images, just do bitbake yourimagewithALSA -c populate_sdk, that should generate a SDK contains ALSA. By default, meta-toolchain-sdk is predefined unless you use -c populate_sdk to enforce the SDK sysroot to match your rootfs. All the clues rolling in are starting to knit together. At first, I regarded the populate_sdk task as a hack, since it seemed to be expressing something that was naturally a target -- not a task. Now I see that it is a way to connect an image to a corresponding SDK. That makes a *lot* more sense. One of my colleagues did some research on this and I believe we've found the best way for *us* to do this. We tried using a single image recipe. We tried both bitbake'ing this recipe directly *and* using the populate_sdk task with it. This gave us the SDK we needed, but it resulted in development header files appearing in the target root file system. Like core-image-sato and core-image-sato-sdk, we'll have have two images: 1) A target image recipe. We will bitbake this recipe directly to produce the target image. We will *never* use the populate_sdk task with this recipe. 2) An SDK image recipe. This recipe require's the target image recipe and adds various development packages to it. We will *never* bitbake this recipe directly because we have no interest in the root file system it would produce. We will *only* use the populate_sdk task with this recipe. This gives us the clean target root file system we need *and* the SDK we need. The disadvantage is that we have to keep two recipe files in sync with each other. Fortunately, these are low-frequency and low-volume changes, so we think this is a reasonable trade-off. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] M2, M3, M4 milestones available?
Dear John, In message cagoht_fp04irbj2pqnjszjjiow5qzjyqctz0rxudg_gjvha...@mail.gmail.com you wrote: The M2 and M3 milestones were merged. Please see Liu Song's email on Dec 27, in part: Yocto Project CCB has approved our request to merge M2 and M3 together. So there won't be a M2 release and we will be working toward a M3 release for M2 and M3 features by Feb. 7th, 2013 Thanks, understood now. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You don't have to worry about me. I might have been born yesterday... but I stayed up all night. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Remove unwanted package from Qt
On Fri, Jan 18, 2013 at 10:59 AM, Eric Bénard e...@eukrea.com wrote: Le Fri, 18 Jan 2013 10:25:22 -0500, Jon Szymaniak jon.szyman...@gmail.com a écrit : I checked the package list on a running system (opkg list | grep -i qt). Here's all the installed Qt packages...no qt4-embedded-examples as far as I see. libqtcoree4 - 4.8.3-r50.0 libqtdeclarativee4 - 4.8.3-r50.0 libqtguie4 - 4.8.3-r50.0 libqtnetworke4 - 4.8.3-r50.0 libqtscripte4 - 4.8.3-r50.0 libqtsqle4 - 4.8.3-r50.0 Seems strange to me...any thoughts? strange, in a fresh build of danny /usr/share/qtopia is only present in the following packages : ./qt4-embedded-translation-linguist/usr/share/qtopia ./qt4-embedded-translation-qt/usr/share/qtopia ./qt4-embedded-translation-qvfb/usr/share/qtopia ./qt4-embedded-qt3to4/usr/share/qtopia ./qt4-embedded-translation-qtconfig/usr/share/qtopia ./qt4-embedded-mkspecs/usr/share/qtopia ./qt4-embedded-phrasebook-dutch/usr/share/qtopia ./qt4-embedded-phrasebook-french/usr/share/qtopia ./qt4-embedded-phrasebook-spanish/usr/share/qtopia ./qt4-embedded-phrasebook-russian/usr/share/qtopia ./qt4-embedded-phrasebook-italian/usr/share/qtopia ./qt4-embedded-phrasebook-polish/usr/share/qtopia ./qt4-embedded-translation-assistant/usr/sh ./qt4-embedded-phrasebook-swedish/usr/share/qtopia ./qt4-embedded-doc/usr/share/doc/qtopia ./qt4-embedded-translation-designer/usr/share/qtopia ./qt4-embedded-phrasebook-danish/usr/share/qtopia ./qt4-embedded-phrasebook-finnish/usr/share/qtopia ./qt4-embedded-phrasebook-german/usr/share/qtopia ./qt4-embedded-demos-doc/usr/share/doc/qtopia ./qt4-embedded-phrasebook-japanese/usr/share/qtopia ./qt4-embedded-phrasebook-norwegian/usr/share/qtopia ./qt4-embedded-phrasebook-hungarian/usr/share/qtopia can you check in your workdir in packages-split which package includes this directory ? Eric Eric, Sorry for the delay. I did check my packages-split and it was the same as what you listed. Since your email, I had removed my do_install_append() from my qt4-embedded bbappend, blown away build/$MY_DIR/tmp and done a full rebuild. I no longer see the qtopia directory in my images. Perhaps this was a vestige of me experimenting with Qt early on? I guess I'll call it a mystery solved for the time being, but will touch back on the mailing list if I figure out what exactly caused this to be populated in my filesystem. (Unless of course, there were other items you'd like me to check.) Thanks again, Jon ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] High-level roadmap
Hi all, I was recently asked for a high-level roadmap for future releases, and I couldn't find anything to point to on our website. We have this wiki page, but it's somewhat out of date: https://wiki.yoctoproject.org/wiki/Yocto_Project_Roadmap Do we have anything else at the moment? If not could something be written up and kept up-to-date? Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FW: YP Linux Kernel Development Manual
On 01/21/2013 06:05 PM, Rifenbark, Scott M wrote: Hi, I am reposting this to the discussion list and copying Darren Hart. Scott From: Eddy Lai GMail [mailto:eddy.lai...@gmail.com] Sent: Monday, January 21, 2013 3:36 PM To: Rifenbark, Scott M Subject: Re: [yocto] YP Linux Kernel Development Manual hi hi, I follow the kernel development manual 2.5. Incorporating Out-of-Tree Modules, copy the hello-mod_0.1.bb and files folder into my taget layer meta-intel/meta-jasperforest/recipe-kernel, then add MACHINE_EXTRA_ RDEPENDS += kernel-module-hello in the conf/local.conf after build and boot, there's no hello.ko found in the binary image also there's no hello.ko in the tmp/work/... folder From the description below that would be because you have to place the entire hello-mod directory into meta-intel/meta-jasperforest/recipes-kernel in order for the stock layer.conf BBFILES variables to include in the bitbake search path. If you do indeed have have a space in MACHINE_EXTRA_ RDEPENDS as in your message below, that will also lead to failure. Thanks, -- Darren Eddy All, There is a new YP manual under development. It is a development manual for Linux kernels in the YP. Darren Hart is the original author of the manual as you probably know. It is still being worked on but it is in HTML form and now part of the yocto-docs/master branch. It is published at http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html. Feel free to access it and comment. Thanks, Scott Scott Rifenbark Intel Corporation Yocto Project Documentation 503.712.2702 503.341.0418 (cell) ___ yocto mailing list yocto@yoctoproject.orgmailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FW: YP Linux Kernel Development Manual
On 01/22/2013 12:59 AM, Christian Ege wrote: Hi, I am not sure if this is the problem you are struggling with. I am wondering why class module.bbclass behaves completely different than kernel.bbclacc hi, I follow the kernel development manual 2.5. Incorporating Out-of-Tree Modules, copy the hello-mod_0.1.bb and files folder into my taget layer meta-intel/meta-jasperforest/recipe-kernel, then add MACHINE_EXTRA_ RDEPENDS += kernel-module-hello in the conf/local.conf after build and boot, there's no hello.ko found in the binary image also there's no hello.ko in the tmp/work/... folder If you hello-mod_0.1.bb inherits module class there is no mechanism to create the kernel-module package. This only applies to the kernel.bbclass http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module.bbclass http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module-base.bbclass Have a look at kernel.bbclass instead shows some pathon code which handles the module package creation: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n301 I've fixed this in my layer by stealing the code from kernel.bbclass https://github.com/project-magpie/meta-stlinux/blob/master/recipes-bsp/tdt-driver/tdt-driver.inc With this you can also use the following extends with your module: module_autoload_aotom = aotom and module_conf_stmfb = options stmfb display0=1280x720-32@50:8m:pal:yuv:yuv Christian, this is a really good point I hadn't considered. Would you care to take a stab at adding this to module.bbclass and sending the patch to the oe-core list for review? CC'ing myself? Thanks, -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
On Jan 15, 2013, at 1:16 PM, Zhang, Jessica jessica.zh...@intel.com wrote: For your LDFLAGS question in another email thread, the yocto SDK is mainly produced for application developer, but seems we are hearing more usage request for it to support kernel module build as well. As Eric pointed, can you just set LDFLAGS= and we'll add that instruction to developer's manual? I *can* clear the LDFLAGS variable just before building modules against the kernel. That works. I understand history makes this difficult, and this is a problem OE/Yocto wasn't originally *intended* to solve. My use case in an outlier, and I don't presume to know what should be done. On the other hand, I wouldn't want anyone to feel that putting those instructions in the documentation is a tidy solution. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
On Jan 16, 2013, at 11:11 AM, Darren Hart dvh...@linux.intel.com wrote: On 01/15/2013 10:38 AM, Bruce Ashfield wrote: I finally found the entries that I was recalling earlier. They are: https://bugzilla.yoctoproject.org/show_bug.cgi?id=241 https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614 https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968 1614 and 2968 are the most interesting for what you are asking. As you can see the net result of those bugs is that you can get the right parts of the kernel tree in SDK packages, since they include dev packages, and with what is currently in kernel-dev .. it should be enough to build against in the SDK (perhaps with just the LDFLAGS tweaks mentioned in the other thread). The sources should be part of the sysroot, and hence available when that is packaged for use outside of bitbake/yocto. If you aren't seeing kernel-dev in the SDK image, it might be that TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something else is different in the SDK that is being generated in your testing. I'm only speculating about what might be missing, since I'm not 100% familiar with the SDK, but perhaps Jessica or others can chime in if I've led you astray :) You have *not* led me astray. A fundamental problem was that I didn't comprehend the distinction/correspondence between target image recipes and SDK image recipes. I believe I get that now. We've created a target image recipe, and an SDK image recipe that require's the former (this is conventional, I believe). The SDK image recipe adds all the development packages and, yes, it includes kernel-dev. So, when I install my SDK now, I certainly *do* get all the kernel header files. As you know, I do *not* get the hostprogs. As I described in an earlier post, I am currently reaching into the tmp directory, pulling out the kernel work directory, and making it directly available to my external build process. This solves my problem because the work directory contains all the header files I need *and* the hostprogs. Of course, it's bad because it's not an intended way to use the build artifacts, and it's awkward to distribute. With the recent improvement, I can now get the kernel header files packaged in the SDK. That's good because it's an intended mechanism and it's easy to distribute. With regard to: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614 This seems a reasonable solution to the problem of building modules on the target, given the difficulties of dealing with executables. I'm not building modules on the target (I'm cross-compiling them), but this seems to apply anyway. It adds an extra step to SDK installation, but that's the least of our problems. One problem I ran into … When I tried to execute make scripts, I got a whole bunch of config questions that I *think* should have been answered with a .config file or something. Should I have copied out the .config file from the kernel work directory into the SDK installation before I ran that? Is that the best way to get around all the questions? Patrick, please keep us posted if this continues to not work for you. I will open a bug to include a section about this in the kernel development manual. It's very *nearly* working for me now. See my question above. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
On 13-01-22 03:28 PM, Patrick Turley wrote: On Jan 16, 2013, at 11:11 AM, Darren Hart dvh...@linux.intel.com wrote: On 01/15/2013 10:38 AM, Bruce Ashfield wrote: I finally found the entries that I was recalling earlier. They are: https://bugzilla.yoctoproject.org/show_bug.cgi?id=241 https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614 https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968 1614 and 2968 are the most interesting for what you are asking. As you can see the net result of those bugs is that you can get the right parts of the kernel tree in SDK packages, since they include dev packages, and with what is currently in kernel-dev .. it should be enough to build against in the SDK (perhaps with just the LDFLAGS tweaks mentioned in the other thread). The sources should be part of the sysroot, and hence available when that is packaged for use outside of bitbake/yocto. If you aren't seeing kernel-dev in the SDK image, it might be that TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something else is different in the SDK that is being generated in your testing. I'm only speculating about what might be missing, since I'm not 100% familiar with the SDK, but perhaps Jessica or others can chime in if I've led you astray :) You have *not* led me astray. A fundamental problem was that I didn't comprehend the distinction/correspondence between target image recipes and SDK image recipes. I believe I get that now. We've created a target image recipe, and an SDK image recipe that require's the former (this is conventional, I believe). The SDK image recipe adds all the development packages and, yes, it includes kernel-dev. So, when I install my SDK now, I certainly *do* get all the kernel header files. As you know, I do *not* get the hostprogs. As I described in an earlier post, I am currently reaching into the tmp directory, pulling out the kernel work directory, and making it directly available to my external build process. This solves my problem because the work directory contains all the header files I need *and* the hostprogs. Of course, it's bad because it's not an intended way to use the build artifacts, and it's awkward to distribute. With the recent improvement, I can now get the kernel header files packaged in the SDK. That's good because it's an intended mechanism and it's easy to distribute. With regard to: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614 This seems a reasonable solution to the problem of building modules on the target, given the difficulties of dealing with executables. I'm not building modules on the target (I'm cross-compiling them), but this seems to apply anyway. It adds an extra step to SDK installation, but that's the least of our problems. One problem I ran into … When I tried to execute make scripts, I got a whole bunch of config questions that I *think* should have been answered with a .config file or something. Should I have copied out the .config file from the kernel work directory into the SDK installation before I ran that? Is that the best way to get around all the questions? Interesting. I haven't seen this myself, so just a couple of quick questions: - without the .config, did you still get a working set of hostprogs, and only had to suffer the warnings ? - If the answer is yes, then the .config really doesn't matter for this and the approach of grabbing a .config should work fine or even having a dummy defconfig available with enough to keep the build happy. Definitely sounds like something we can address and it's worth putting into bugzilla so it doesn't get lost. Bruce Patrick, please keep us posted if this continues to not work for you. I will open a bug to include a section about this in the kernel development manual. It's very *nearly* working for me now. See my question above. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PATCH 0/1] meta: add emgd-1.16 driver support
From: Nitin A Kamble nitin.a.kam...@intel.com Here is a commit which adds an scc file for emgd-1.16 feature. It depends on the emgd-1.16 branch in the kernel repo, for which a pull request is already sent. This commit keeps the emgd-1.14 driver support in the repo intact. Thanks, Nitin The following changes since commit c0b3904d60830e24b3930b0fa606a48b2758d979: meta: add config fragment for gma600 graphics driver (2013-01-18 23:07:15 -0500) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib nitin/meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=nitin/meta Nitin A Kamble (1): meta: add a kernel feature for drm-emgd-1.16 driver .../features/drm-emgd/drm-emgd-1.16.scc|2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/drm-emgd/drm-emgd-1.16.scc -- 1.7.3.4 ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 1/1] meta: add a kernel feature for drm-emgd-1.16 driver
From: Nitin A Kamble nitin.a.kam...@intel.com Use the newly created emgd-1.16 branch to get the emgd-1.16 kernel driver sources. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- .../features/drm-emgd/drm-emgd-1.16.scc|2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/drm-emgd/drm-emgd-1.16.scc diff --git a/meta/cfg/kernel-cache/features/drm-emgd/drm-emgd-1.16.scc b/meta/cfg/kernel-cache/features/drm-emgd/drm-emgd-1.16.scc new file mode 100644 index 000..8f2a167 --- /dev/null +++ b/meta/cfg/kernel-cache/features/drm-emgd/drm-emgd-1.16.scc @@ -0,0 +1,2 @@ +kconf hardware drm-emgd.cfg +git merge emgd-1.16 -- 1.7.3.4 ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/1] meta: add emgd-1.16 driver support
On 13-01-22 03:38 PM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Here is a commit which adds an scc file for emgd-1.16 feature. It depends on the emgd-1.16 branch in the kernel repo, for which a pull request is already sent. This commit keeps the emgd-1.14 driver support in the repo intact. merged. and pushed. SRCREV updates to follow, but you can test it locally before I do the updates. Bruce Thanks, Nitin The following changes since commit c0b3904d60830e24b3930b0fa606a48b2758d979: meta: add config fragment for gma600 graphics driver (2013-01-18 23:07:15 -0500) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib nitin/meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=nitin/meta Nitin A Kamble (1): meta: add a kernel feature for drm-emgd-1.16 driver .../features/drm-emgd/drm-emgd-1.16.scc|2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/drm-emgd/drm-emgd-1.16.scc ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] a new kernel repo branch for emgd 1.16 driver
On 13-01-21 06:19 PM, Kamble, Nitin A wrote: Hi Bruce, I have created a branch for emgd-1.16 kernel driver for the v3.4 kernel repo over here. http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=nitin/emgd-1.16 It consists of mainly following 2 commits on top of the standard/base branch. merged and pushed. the emgd-1.16 branch is now available. Bruce Can you pull this branch in the v3.4 YP kernel repository so that BSPs can start using emgd 1.16 driver for graphics? Thanks, Nitin commit 39fa5392e05b98a1bd107a5c77f06679adc917e6 Author: Nitin A Kamble nitin.a.kam...@intel.com Date: Fri Jan 18 21:02:20 2013 -0800 emgd: enable building within the kernel sources Modify the build mechanism so that emgd can be configured and built as a feature of the kernel. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com commit 99ae3010eeb048bd6fd63b554e2e3c6fddd80afa Author: Nitin A Kamble nitin.a.kam...@intel.com Date: Fri Jan 18 19:51:03 2013 -0800 emgd: add emgd 1.16 driver sources This is starting-point code that subsequent patches will modify. This is a virgin copy of the code from the emgd 1.16 driver. This code is coming from IEMGD_HEAD_Linux/common/drm/emgd_drm.tgz which is a piece from the 'Linux Tar Ball' release of EMGD 1.16 downloaded from here: https://edc.intel.com/App_Shared/Downloads/LIN_IEMGD_1_16_GOLD_3228.tgz Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/1] meta: add emgd-1.16 driver support
-Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, January 22, 2013 1:04 PM To: Kamble, Nitin A Cc: linux-yo...@yoctoproject.org Subject: Re: [PATCH 0/1] meta: add emgd-1.16 driver support On 13-01-22 03:38 PM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Here is a commit which adds an scc file for emgd-1.16 feature. It depends on the emgd-1.16 branch in the kernel repo, for which a pull request is already sent. This commit keeps the emgd-1.14 driver support in the repo intact. merged. and pushed. SRCREV updates to follow, but you can test it locally before I do the updates. Bruce With current autorev it's ok. I am checking it here locally. Thanks for pushing, Nitin Thanks, Nitin The following changes since commit c0b3904d60830e24b3930b0fa606a48b2758d979: meta: add config fragment for gma600 graphics driver (2013-01-18 23:07:15 -0500) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib nitin/meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h =nitin/meta Nitin A Kamble (1): meta: add a kernel feature for drm-emgd-1.16 driver .../features/drm-emgd/drm-emgd-1.16.scc|2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/drm-emgd/drm-emgd-1.16.scc ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/1] meta: add emgd-1.16 driver support
On 13-01-22 03:38 PM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Here is a commit which adds an scc file for emgd-1.16 feature. It depends on the emgd-1.16 branch in the kernel repo, for which a pull request is already sent. This commit keeps the emgd-1.14 driver support in the repo intact. Ack'd. I'll merge this shortly, once I get emgd pulled in .. which I'm doing now, but being throttled by the servers. Bruce Thanks, Nitin The following changes since commit c0b3904d60830e24b3930b0fa606a48b2758d979: meta: add config fragment for gma600 graphics driver (2013-01-18 23:07:15 -0500) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib nitin/meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=nitin/meta Nitin A Kamble (1): meta: add a kernel feature for drm-emgd-1.16 driver .../features/drm-emgd/drm-emgd-1.16.scc|2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/drm-emgd/drm-emgd-1.16.scc ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] FW: YP Linux Kernel Development Manual
Am Dienstag, den 22.01.2013, 11:14 +0100 schrieb Darren Hart darren.h...@intel.com: On 01/22/2013 12:59 AM, Christian Ege wrote: Hi, I am not sure if this is the problem you are struggling with. I am wondering why class module.bbclass behaves completely different than kernel.bbclacc hi, I follow the kernel development manual 2.5. Incorporating Out-of-Tree Modules, copy the hello-mod_0.1.bb and files folder into my taget layer meta-intel/meta-jasperforest/recipe-kernel, then add MACHINE_EXTRA_ RDEPENDS += kernel-module-hello in the conf/local.conf after build and boot, there's no hello.ko found in the binary image also there's no hello.ko in the tmp/work/... folder If you hello-mod_0.1.bb inherits module class there is no mechanism to create the kernel-module package. This only applies to the kernel.bbclass http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module.bbclass http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module-base.bbclass Have a look at kernel.bbclass instead shows some pathon code which handles the module package creation: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n301 I've fixed this in my layer by stealing the code from kernel.bbclass https://github.com/project-magpie/meta-stlinux/blob/master/recipes-bsp/tdt-driver/tdt-driver.inc With this you can also use the following extends with your module: module_autoload_aotom = aotom and module_conf_stmfb = options stmfb display0=1280x720-32@50:8m:pal:yuv:yuv Christian, this is a really good point I hadn't considered. Would you care to take a stab at adding this to module.bbclass and sending the patch to the oe-core list for review? CC'ing myself? I'll try to write a patch. Maybe tomorrow or by end of the week. I'll send it to oe-core and to you in CC. regrads, Christian Thanks, ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] scripts/build.sh: Fixed local build to use the correct repository path
Merged to eclipse-poky master.
Thanks,
Jessica
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Timo Mueller
Sent: Tuesday, January 22, 2013 4:03 AM
To: yocto@yoctoproject.org
Cc: Timo Mueller
Subject: [yocto] [PATCH] scripts/build.sh: Fixed local build to use the correct
repository path
From: Timo Mueller timo.muel...@bmw-carit.de
Signed-off-by: Timo Mueller timo.muel...@bmw-carit.de
---
scripts/build.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/build.sh b/scripts/build.sh index 54081d5..8d8b4c3 100755
--- a/scripts/build.sh
+++ b/scripts/build.sh
@@ -115,7 +115,7 @@ mkdir ${BUILD_DIR} || fail $? Create temporary build
directory ${BUILD_DIR}
GIT_URL=git://git.pokylinux.org/eclipse-poky.git
if [ $USE_LOCAL_GIT_REPO -eq 1 ]; then
SCRIPT_DIR=`dirname $0`
- GIT_DIR=`readlink -f ${SCRIPTDIR}\..`
+ GIT_DIR=`readlink -f ${SCRIPT_DIR}\..`
GIT_URL=file://${GIT_DIR}
fi
--
1.7.11.7
___
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] High-level roadmap
On 01/22/2013 01:59 PM, Paul Eggleton wrote: Hi all, I was recently asked for a high-level roadmap for future releases, and I couldn't find anything to point to on our website. We have this wiki page, but it's somewhat out of date: https://wiki.yoctoproject.org/wiki/Yocto_Project_Roadmap Do we have anything else at the moment? If not could something be written up and kept up-to-date? I think that page updated with the major features added in the releases to date, combined with features for the next release would be a good start showing what the Project has done, so people can think about other ways to make Embedded Development easier. Philip ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] M2/M3.rc1 availability
The weekly build is available at: http://autobuilder.yoctoproject.org/pub/nightly/20130122-2 This build is built from master HEAD. Please begin testing against this rc. Please note that tag and branch names for this milestone will be named as if it was M3. I will be tagging tonight and branching in the morning once given the all clear by RP. -b -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
On Jan 22, 2013, at 2:34 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-01-22 03:28 PM, Patrick Turley wrote: One problem I ran into … When I tried to execute make scripts, I got a whole bunch of config questions that I *think* should have been answered with a .config file or something. Should I have copied out the .config file from the kernel work directory into the SDK installation before I ran that? Is that the best way to get around all the questions? Interesting. I haven't seen this myself, so just a couple of quick questions: - without the .config, did you still get a working set of hostprogs, and only had to suffer the warnings ? - If the answer is yes, then the .config really doesn't matter for this and the approach of grabbing a .config should work fine or even having a dummy defconfig available with enough to keep the build happy. Definitely sounds like something we can address and it's worth putting into bugzilla so it doesn't get lost. Below, please find a transcript of the commands I executed. You'll see that I installed the SDK, tried to make scripts, and then got attacked with a storm of config questions. I cut off the transcript at the second question, but there are dozens that follow. There *is* a .config file in the SDK directory, and it is identical to the one in our kernel build directory: /home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git Unfortunately, I'm still something of a n00b when it comes to building the kernel. I suspect *most* of these questions are irrelevant to hostprogs, but I can't say that *all* of them are. If I just hold down the Enter key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.) $ pwd /home/pturley/yocto-mpu-build/tmp/deploy/sdk $ ls poky-eglibc-x86_64-arm-toolchain-1.3.sh $ sudo ./poky-eglibc-x86_64-arm-toolchain-1.3.sh Enter target directory for SDK (default: /opt/poky/1.3): You are about to install the SDK to /opt/poky/1.3. Proceed[Y/n]? Extracting SDK...done Setting it up...done SDK has been successfully set up and is ready to be used. $ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel $ ls -a . firmware lib scripts .. fs MAINTAINERS security arch includeMakefilesound block init mm System.map-2.6.37 .configipcModule.symvers tools COPYINGKbuild net uImage CREDITSKconfigpatches usr crypto kernel README virt Documentation kernel-abiversion REPORTING-BUGS driverskernel-image-name samples $ sudo make scripts HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --silentoldconfig Kconfig * * Restart config... * * * General setup * Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y Cross-compiler tool prefix (CROSS_COMPILE) [] Local version - append to kernel release (LOCALVERSION) [] Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n Kernel compression mode 1. Gzip (KERNEL_GZIP) 2. Bzip2 (KERNEL_BZIP2) (NEW) 3. LZMA (KERNEL_LZMA) 4. LZO (KERNEL_LZO) choice[1-4?]: Support for paging of anonymous memory (swap) (SWAP) [N/y/?] n System V IPC (SYSVIPC) [Y/n/?] y POSIX Message Queues (POSIX_MQUEUE) [Y/n/?] y BSD Process Accounting (BSD_PROCESS_ACCT) [Y/n/?] y BSD Process Accounting version 3 file format (BSD_PROCESS_ACCT_V3) [Y/n/?] y Export task/process statistics through netlink (EXPERIMENTAL) (TASKSTATS) [Y/n/?] y Enable per-task delay accounting (EXPERIMENTAL) (TASK_DELAY_ACCT) [Y/n/?] y Enable extended accounting over taskstats (EXPERIMENTAL) (TASK_XACCT) [Y/n/?] y Enable per-task storage I/O accounting (EXPERIMENTAL) (TASK_IO_ACCOUNTING) [Y/n/?] y Auditing support (AUDIT) [N/y/?] n Kernel .config support (IKCONFIG) [Y/n/m/?] y Enable access to .config through /proc/config.gz (IKCONFIG_PROC) [Y/n/?] y Kernel log buffer size (16 = 64KB, 17 = 128KB) (LOG_BUF_SHIFT) [17] 17 enable deprecated sysfs features to support old userspace tools (SYSFS_DEPRECATED) [N/y/?] n Kernel-user space relay support (formerly relayfs) (RELAY) [N/y/?] n Initial RAM filesystem and RAM disk (initramfs/initrd) support (BLK_DEV_INITRD) [Y/n/?] y Initramfs source file(s) (INITRAMFS_SOURCE) [] Optimize for size
Re: [yocto] Build external module against Yocto kernel
On 13-01-22 9:26 PM, Patrick Turley wrote: On Jan 22, 2013, at 2:34 PM, Bruce Ashfieldbruce.ashfi...@windriver.com wrote: On 13-01-22 03:28 PM, Patrick Turley wrote: One problem I ran into … When I tried to execute make scripts, I got a whole bunch of config questions that I *think* should have been answered with a .config file or something. Should I have copied out the .config file from the kernel work directory into the SDK installation before I ran that? Is that the best way to get around all the questions? Interesting. I haven't seen this myself, so just a couple of quick questions: - without the .config, did you still get a working set of hostprogs, and only had to suffer the warnings ? - If the answer is yes, then the .config really doesn't matter for this and the approach of grabbing a .config should work fine or even having a dummy defconfig available with enough to keep the build happy. Definitely sounds like something we can address and it's worth putting into bugzilla so it doesn't get lost. Below, please find a transcript of the commands I executed. You'll see that I installed the SDK, tried to make scripts, and then got attacked with a storm of config questions. I cut off the transcript at the second question, but there are dozens that follow. There *is* a .config file in the SDK directory, and it is identical to the one in our kernel build directory: /home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git Unfortunately, I'm still something of a n00b when it comes to building the kernel. I suspect *most* of these questions are irrelevant to hostprogs, but I can't say that *all* of them are. If I just hold down the Enter key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.) This will be fine, the defaults will work. The kernel build infrastructure is picking up what it thinks is a change source - to config and trying to reconcile the differences. If you throw in a 'make oldconfig' before you do the 'make scripts', does that quiet things down a bit ? Cheers, Bruce $ pwd /home/pturley/yocto-mpu-build/tmp/deploy/sdk $ ls poky-eglibc-x86_64-arm-toolchain-1.3.sh $ sudo ./poky-eglibc-x86_64-arm-toolchain-1.3.sh Enter target directory for SDK (default: /opt/poky/1.3): You are about to install the SDK to /opt/poky/1.3. Proceed[Y/n]? Extracting SDK...done Setting it up...done SDK has been successfully set up and is ready to be used. $ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel $ ls -a . firmware lib scripts .. fs MAINTAINERS security arch includeMakefilesound block init mm System.map-2.6.37 .configipcModule.symvers tools COPYINGKbuild net uImage CREDITSKconfigpatches usr crypto kernel README virt Documentation kernel-abiversion REPORTING-BUGS driverskernel-image-name samples $ sudo make scripts HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --silentoldconfig Kconfig * * Restart config... * * * General setup * Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y Cross-compiler tool prefix (CROSS_COMPILE) [] Local version - append to kernel release (LOCALVERSION) [] Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n Kernel compression mode 1. Gzip (KERNEL_GZIP) 2. Bzip2 (KERNEL_BZIP2) (NEW) 3. LZMA (KERNEL_LZMA) 4. LZO (KERNEL_LZO) choice[1-4?]: Support for paging of anonymous memory (swap) (SWAP) [N/y/?] n System V IPC (SYSVIPC) [Y/n/?] y POSIX Message Queues (POSIX_MQUEUE) [Y/n/?] y BSD Process Accounting (BSD_PROCESS_ACCT) [Y/n/?] y BSD Process Accounting version 3 file format (BSD_PROCESS_ACCT_V3) [Y/n/?] y Export task/process statistics through netlink (EXPERIMENTAL) (TASKSTATS) [Y/n/?] y Enable per-task delay accounting (EXPERIMENTAL) (TASK_DELAY_ACCT) [Y/n/?] y Enable extended accounting over taskstats (EXPERIMENTAL) (TASK_XACCT) [Y/n/?] y Enable per-task storage I/O accounting (EXPERIMENTAL) (TASK_IO_ACCOUNTING) [Y/n/?] y Auditing support (AUDIT) [N/y/?] n Kernel .config support (IKCONFIG) [Y/n/m/?] y Enable access to .config through /proc/config.gz (IKCONFIG_PROC) [Y/n/?] y Kernel log buffer size (16 = 64KB, 17 = 128KB)
Re: [yocto] Build external module against Yocto kernel
On Jan 22, 2013, at 10:43 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-01-22 9:26 PM, Patrick Turley wrote: If I just hold down the Enter key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.) This will be fine, the defaults will work. The kernel build infrastructure is picking up what it thinks is a change source - to config and trying to reconcile the differences. If you throw in a 'make oldconfig' before you do the 'make scripts', does that quiet things down a bit ? No -- make oldconfig caused the very same questions (see below). --- $ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel $ ls arch drivers Kbuild MAINTAINERS README System.map-2.6.37 block firmware KconfigMakefileREPORTING-BUGS tools COPYINGfskernel mm samples uImage CREDITSinclude kernel-abiversion Module.symvers scripts usr crypto init kernel-image-name net securityvirt Documentation ipc libpatches sound $ sudo make oldconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --oldconfig Kconfig * * Restart config... * * * General setup * Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y Cross-compiler tool prefix (CROSS_COMPILE) [] Local version - append to kernel release (LOCALVERSION) [] Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n Kernel compression mode 1. Gzip (KERNEL_GZIP) 2. Bzip2 (KERNEL_BZIP2) (NEW) 3. LZMA (KERNEL_LZMA) 4. LZO (KERNEL_LZO) choice[1-4?]: ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
On 13-01-23 12:14 AM, Patrick Turley wrote: On Jan 22, 2013, at 10:43 PM, Bruce Ashfieldbruce.ashfi...@windriver.com wrote: On 13-01-22 9:26 PM, Patrick Turley wrote: If I just hold down the Enter key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.) This will be fine, the defaults will work. The kernel build infrastructure is picking up what it thinks is a change source - to config and trying to reconcile the differences. If you throw in a 'make oldconfig' before you do the 'make scripts', does that quiet things down a bit ? No -- make oldconfig caused the very same questions (see below). Aha. of course (now that I think about it), the build was simply triggering old config automatically. silentoldconfig is what I really should have typed :) Bruce --- $ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel $ ls arch drivers Kbuild MAINTAINERS README System.map-2.6.37 block firmware KconfigMakefileREPORTING-BUGS tools COPYINGfskernel mm samples uImage CREDITSinclude kernel-abiversion Module.symvers scripts usr crypto init kernel-image-name net securityvirt Documentation ipc libpatches sound $ sudo make oldconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --oldconfig Kconfig * * Restart config... * * * General setup * Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y Cross-compiler tool prefix (CROSS_COMPILE) [] Local version - append to kernel release (LOCALVERSION) [] Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n Kernel compression mode 1. Gzip (KERNEL_GZIP) 2. Bzip2 (KERNEL_BZIP2) (NEW) 3. LZMA (KERNEL_LZMA) 4. LZO (KERNEL_LZO) choice[1-4?]: ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
