Re: [yocto] Cedartrail / GLES / Framebuffer
Hi Ross, (Resend, as I forgot to include the list last time). On 15 Nov 2012, at 14:44, Burton, Ross wrote: Hi, On 20 October 2012 19:31, Chris Tapp opensou...@keylevel.com wrote: I'm still trying to get my 'perfect' platform configuration for a project. 1) I need to use the 'nopvr' machine as I need unionfs. This means I need the kernel 3.2, which doesn't currently support pvr; 2) I'm running using the framebuffer and would rather not have to include libx11; 3) I was using SDL, but I now need to support GLESv2 / EGL as well. Is it possible to build a system that runs like this? i.e. GLES on the framerbuffer without X11. I think the only issue is getting a build of MESA that runs without x11, but is there anything else, or another way? I had this marked to Follow Up but managed to ignore it until now, sorry. My turn - I had to go to Japan for a week and I've only just caught up with e-mails ;-) GLES without X11 should work using EGL, but that will be using the closed cdv-pvr-drivers package. If you can't use those for other reasons, then you're stuck. That should be ok for this project. Thanks for the confirmation. (yay closed drivers) I understand that Ubuntu contains a re-packaging and re-build of the CedarView binary drivers - it may be worth seeing what kernel they are built against as I believe that the stack is slightly new than the MeeGo-derived binaries that we're using. I'll have a look, but this is well outside my comfort-zone :-) James Abernathy reported similar: It may not solve the 3.0 problem for CDV and Yocto, but I noticed that Ubuntu 12.04.1 with the 3.2 kernel supports the PVR driver on it's 3.2.0 kernel. I've only tested it successfully on an All-In-One with LVDS off of an eDP to LVDS converter used on the DN2800MT motherboard. Ross Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Best way to support multiple versions of Poky?
I'm just getting round to moving from 'denzil' to 'danny'. I've got a layer that makes some changes to a few recipes through bbappend files. However, 'danny' has bumped a few of these to a new version (which is good) which means I now have bbappend files that get a 'there is no matching bb file' errors when I try to build. This is easy to fix (generally just rename the bbappend to match the new version), but I would like the layer to be able to work with older versions of Poky - mainly in case I need to make changes to an existing project that hasn't be verified under 'danny'. What's the best way to do this? All I can think of is to have another set of layers to use when building against a specific poky version: meta-mystuff | +--poky-versions | +--denzil-specific +--danny-specific +--etc Is there a more elegant solution? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Best way to support multiple versions of Poky?
On Thu, Nov 22, 2012 at 9:35 AM, Chris Tapp opensou...@keylevel.com wrote: I'm just getting round to moving from 'denzil' to 'danny'. I've got a layer that makes some changes to a few recipes through bbappend files. However, 'danny' has bumped a few of these to a new version (which is good) which means I now have bbappend files that get a 'there is no matching bb file' errors when I try to build. This is easy to fix (generally just rename the bbappend to match the new version), but I would like the layer to be able to work with older versions of Poky - mainly in case I need to make changes to an existing project that hasn't be verified under 'danny'. What's the best way to do this? All I can think of is to have another set of layers to use when building against a specific poky version: meta-mystuff | +--poky-versions | +--denzil-specific +--danny-specific +--etc Is there a more elegant solution? i suspect you might have thought about that already... and might have discarded the idea... but for meta-ti layer, we use a branching scheme. each version is maintained in its separate branch. you will find 'denzil', 'danny', and master branch here http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/, for each OE version. one drawback with that is that you need multiple copy of the layer 'tree' to work on multiple versions... but that can be managed. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] inconsistent pages out there for setting up your yocto dev host
On Wednesday 21 November 2012 20:19:05 Robert P. J. Day wrote: On Wed, 21 Nov 2012, Paul Eggleton wrote: On Wednesday 21 November 2012 17:23:56 Robert P. J. Day wrote: as i read it, the sanity.bbclass and ASSUME_PROVIDED will dictate what needs to be there and what will be used if it's installed natively, no? it certainly seems that that wiki page is insructing the developer to install a lot of software that OE will handle automatically, no? Er, no. Well, if by handle automatically you mean error out when they are not present then that's not very helpful - it's much easier if people just get a list of what they need to install up front. at the risk of asking a dumb question, let me make sure i understand the different categories of software. first, there's what is absolutely *required* to be installed on the development system already before doing any oe/yocto work. those would the packages/utilities that are listed on the wiki page as you must install this, and that's what's represented in the sanity.bbclass. is that about right? on the other hand, there's what's listed in ASSUME_PROVIDED, which represents software that, if it *is* natively installed, will be used; otherwise, oe/yocto will download and build it as part of the build process. correct? or have i misunderstood the distinction here? I think you may have. All ASSUME_PROVIDED does is tell bitbake that dependencies on the things within it should be considered to be satisfied - i.e. assume these things are provided. If you add something to ASSUME_PROVIDED that is genuinely needed by the build process and it isn't actually provided by the host system, then you will get build failures or at the very least undesirable changes in build behaviour. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] inconsistent pages out there for setting up your yocto dev host
On Thu, 22 Nov 2012, Paul Eggleton wrote: On Wednesday 21 November 2012 20:19:05 Robert P. J. Day wrote: On Wed, 21 Nov 2012, Paul Eggleton wrote: On Wednesday 21 November 2012 17:23:56 Robert P. J. Day wrote: as i read it, the sanity.bbclass and ASSUME_PROVIDED will dictate what needs to be there and what will be used if it's installed natively, no? it certainly seems that that wiki page is insructing the developer to install a lot of software that OE will handle automatically, no? Er, no. Well, if by handle automatically you mean error out when they are not present then that's not very helpful - it's much easier if people just get a list of what they need to install up front. at the risk of asking a dumb question, let me make sure i understand the different categories of software. first, there's what is absolutely *required* to be installed on the development system already before doing any oe/yocto work. those would the packages/utilities that are listed on the wiki page as you must install this, and that's what's represented in the sanity.bbclass. is that about right? on the other hand, there's what's listed in ASSUME_PROVIDED, which represents software that, if it *is* natively installed, will be used; otherwise, oe/yocto will download and build it as part of the build process. correct? or have i misunderstood the distinction here? I think you may have. All ASSUME_PROVIDED does is tell bitbake that dependencies on the things within it should be considered to be satisfied - i.e. assume these things are provided. If you add something to ASSUME_PROVIDED that is genuinely needed by the build process and it isn't actually provided by the host system, then you will get build failures or at the very least undesirable changes in build behaviour. ok, after a good night's sleep, i re-read what i wrote above and i sound like an idiot so let me try again. first, there's sanity.bbclass, which contains: SANITY_REQUIRED_UTILITIES ?= patch diffstat makeinfo git bzip2 tar gzip gawk chrpath wget cpio which represents the utilities that *must* already exist before bitbake will offer to do anything. yes, it's obvious, but i just confirmed that by removing diffstat, whereupon i got: ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Please install the following missing utilities: diffstat so that's good, it's what i expected. it also suggests that, in terms of minimal software, it's valid to just point people at that variable in sanity.bbclass -- technically, those utilities are the ones developers should be ordered to install beforehand. so far, so good. now, regarding ASSUME_PROVIDED in bitbake.conf, as you say, that represents any dependencies assumed to be satisfied for further processing, and it's not surprising that those two lists are closely related -- if, for example, the sanity checker requires bzip2 (as it does), it's only natural that ASSUME_PROVIDED would contain bzip2-native. and so on, and so on. and now, a few questions that probably have obvious answers but i'll ask them, anyway. first, is ASSUME_PROVIDED technically completely superfluous? it's clearly meant to speed up processing, but could one (if one wanted) unset it and have the processing still work (albeit more slowly, of course)? next, what about this in bitbake.conf, right after the setting of ASSUME_PROVIDED? # gzip-native should be listed above? should it? seems to make sense -- why did someone feel the need to leave a comment asking that question? next, while ASSUME_PROVIDED contains grep-native, the sanity check doesn't list grep. should it? it just seems natural that anything you assume to be provided should be listed as an installation requirement first. finally (and because i don't read python all that well, i can't check the code as quickly as i would like), how would one add subversion to one or both of the above? after all, the utility name is svn but the package name (used by recipes) is subversion. (sure seems like subversion would be a good requirement to avoid building it.) ok, i'm done. 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] Ada layer for Yocto
Hi, I managed to get my Ada layer going for the official gumstix repo. I had the code in the wrong bbappend file, should be the gcc-cross, not the gcc one. The repo is here: https://github.com/Lucretia/meta-ada This is currently very basic support and I will be adding more. Please see the README for problems. Please test and help me refine it. Luke. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] inconsistent pages out there for setting up your yocto dev host
On Thursday 22 November 2012 06:54:33 Robert P. J. Day wrote: On Thu, 22 Nov 2012, Paul Eggleton wrote: On Wednesday 21 November 2012 20:19:05 Robert P. J. Day wrote: On Wed, 21 Nov 2012, Paul Eggleton wrote: On Wednesday 21 November 2012 17:23:56 Robert P. J. Day wrote: as i read it, the sanity.bbclass and ASSUME_PROVIDED will dictate what needs to be there and what will be used if it's installed natively, no? it certainly seems that that wiki page is insructing the developer to install a lot of software that OE will handle automatically, no? Er, no. Well, if by handle automatically you mean error out when they are not present then that's not very helpful - it's much easier if people just get a list of what they need to install up front. at the risk of asking a dumb question, let me make sure i understand the different categories of software. first, there's what is absolutely *required* to be installed on the development system already before doing any oe/yocto work. those would the packages/utilities that are listed on the wiki page as you must install this, and that's what's represented in the sanity.bbclass. is that about right? on the other hand, there's what's listed in ASSUME_PROVIDED, which represents software that, if it *is* natively installed, will be used; otherwise, oe/yocto will download and build it as part of the build process. correct? or have i misunderstood the distinction here? I think you may have. All ASSUME_PROVIDED does is tell bitbake that dependencies on the things within it should be considered to be satisfied - i.e. assume these things are provided. If you add something to ASSUME_PROVIDED that is genuinely needed by the build process and it isn't actually provided by the host system, then you will get build failures or at the very least undesirable changes in build behaviour. ok, after a good night's sleep, i re-read what i wrote above and i sound like an idiot so let me try again. first, there's sanity.bbclass, which contains: SANITY_REQUIRED_UTILITIES ?= patch diffstat makeinfo git bzip2 tar gzip gawk chrpath wget cpio which represents the utilities that *must* already exist before bitbake will offer to do anything. yes, it's obvious, but i just confirmed that by removing diffstat, whereupon i got: ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Please install the following missing utilities: diffstat so that's good, it's what i expected. it also suggests that, in terms of minimal software, it's valid to just point people at that variable in sanity.bbclass -- technically, those utilities are the ones developers should be ordered to install beforehand. so far, so good. now, regarding ASSUME_PROVIDED in bitbake.conf, as you say, that represents any dependencies assumed to be satisfied for further processing, and it's not surprising that those two lists are closely related -- if, for example, the sanity checker requires bzip2 (as it does), it's only natural that ASSUME_PROVIDED would contain bzip2-native. and so on, and so on. and now, a few questions that probably have obvious answers but i'll ask them, anyway. first, is ASSUME_PROVIDED technically completely superfluous? it's clearly meant to speed up processing, but could one (if one wanted) unset it and have the processing still work (albeit more slowly, of course)? If you like building things that you don't have to, sure, but I wouldn't equate that to it being superfluous. Note that if you do change this variable you are deviating from what has been tested, so you do so at your own risk. next, what about this in bitbake.conf, right after the setting of ASSUME_PROVIDED? # gzip-native should be listed above? should it? seems to make sense -- why did someone feel the need to leave a comment asking that question? Not sure. We do now build pigz-native instead of using the system gzip though, that might have something to do with it not being in the list. next, while ASSUME_PROVIDED contains grep-native, the sanity check doesn't list grep. should it? it just seems natural that anything you assume to be provided should be listed as an installation requirement first. Probably yes. finally (and because i don't read python all that well, i can't check the code as quickly as i would like), how would one add subversion to one or both of the above? after all, the utility name is svn but the package name (used by recipes) is subversion. (sure seems like subversion would be a good requirement to avoid building it.) The important thing to remember is SANITY_REQUIRED_UTILITIES is a list of commands, and
[yocto] [PATCH] Add console fixes run commands in a synchronous way
- when creating a new Yocto Project, the window does not wait for the process
to complete, and closes beforehand
- the long time running task will be created without forking and monitor will
be updated when receiving events from the YoctoHostShellProcessAdapter
- use AbstractHostShellReader.isFinished to wait for command outputs
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
---
.../src/org/yocto/bc/bitbake/ShellSession.java | 13 +-
.../org/yocto/bc/remote/utils/ConsoleHelper.java | 18 +--
.../bc/remote/utils/ConsoleHelperRunnable.java | 31 +
.../org/yocto/bc/remote/utils/ConsoleRunnable.java | 37 ++
.../org/yocto/bc/remote/utils/RemoteHelper.java| 34 +++--
.../org/yocto/bc/remote/utils/RemoteMachine.java |6 +-
.../remote/utils/YoctoHostShellProcessAdapter.java | 140 +---
.../bc/ui/wizards/NewBitBakeFileRecipeWizard.java |2 +-
.../ui/wizards/NewBitBakeFileRecipeWizardPage.java | 10 +-
.../yocto/bc/ui/wizards/install/InstallWizard.java | 86 +++-
10 files changed, 217 insertions(+), 160 deletions(-)
create mode 100644
plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ConsoleHelperRunnable.java
create mode 100644
plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ConsoleRunnable.java
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java
index 06978fb..a7ed3d6 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java
@@ -18,7 +18,6 @@ import java.io.InputStreamReader;
import java.io.OutputStream;
import java.io.Writer;
-import org.eclipse.core.runtime.CoreException;
import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.core.runtime.NullProgressMonitor;
import org.eclipse.rse.services.files.IHostFile;
@@ -119,12 +118,12 @@ public class ShellSession {
synchronized
public String execute(String command, int[] retCode) throws IOException
{
//FIXME : parse output
- try {
-
RemoteHelper.runCommandRemote(RemoteHelper.getRemoteConnectionByName(projectInfo.getConnection().getName()),
new YoctoCommand(command, root.getAbsolutePath(), ), new
NullProgressMonitor(), true);
- } catch (Exception e) {
- e.printStackTrace();
- }
-
+// try {
+//
RemoteHelper.runCommandRemote(RemoteHelper.getRemoteConnectionByName(projectInfo.getConnection().getName()),
new YoctoCommand(command, root.getAbsolutePath(), ), new
NullProgressMonitor());
+// } catch (Exception e) {
+// e.printStackTrace();
+// }
+//
// String errorMessage = null;
// interrupt = false;
// out.write(command);
diff --git
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ConsoleHelper.java
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ConsoleHelper.java
index 4655fe0..25bd9f9 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ConsoleHelper.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ConsoleHelper.java
@@ -1,14 +1,9 @@
package org.yocto.bc.remote.utils;
-import org.eclipse.ui.IWorkbench;
-import org.eclipse.ui.IWorkbenchPage;
-import org.eclipse.ui.IWorkbenchWindow;
-import org.eclipse.ui.PlatformUI;
+import org.eclipse.swt.widgets.Display;
import org.eclipse.ui.console.ConsolePlugin;
import org.eclipse.ui.console.IConsole;
-import org.eclipse.ui.console.IConsoleConstants;
import org.eclipse.ui.console.IConsoleManager;
-import org.eclipse.ui.console.IConsoleView;
import org.eclipse.ui.console.MessageConsole;
public class ConsoleHelper {
@@ -28,15 +23,6 @@ public class ConsoleHelper {
}
public static void showConsole(MessageConsole console){
- IWorkbench wb = PlatformUI.getWorkbench();
- IWorkbenchWindow win = wb.getActiveWorkbenchWindow();
- IWorkbenchPage page = win.getActivePage();
- String id = IConsoleConstants.ID_CONSOLE_VIEW;
- try {
- IConsoleView view = (IConsoleView) page.showView(id);
- view.display(console);
- } catch (Exception e) {
- e.printStackTrace();
- }
+ Display.getDefault().syncExec(new ConsoleRunnable(console));
}
}
diff --git
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ConsoleHelperRunnable.java
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ConsoleHelperRunnable.java
new file mode 100644
index 000..36f6b70
--- /dev/null
+++
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ConsoleHelperRunnable.java
@@ -0,0 +1,31 @@
+package org.yocto.bc.remote.utils;
+
+import
Re: [yocto] Ada layer for Yocto
On Thursday 22 November 2012 14:00:33 Luke A. Guest wrote: I managed to get my Ada layer going for the official gumstix repo. I had the code in the wrong bbappend file, should be the gcc-cross, not the gcc one. The repo is here: https://github.com/Lucretia/meta-ada Thanks, I've added the layer to the layerindex [1]. Cheers, Paul [1] http://www.openembedded.org/wiki/LayerIndex -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-xilinx] Update maintainers contact informaton
Hi all, Please welcome Elvis Dowson as new maintainer for meta-xilinx bsp layer. Elvis had provide fixes over the last months for this layer and I'm pretty sure that he can improve and move forward this layer. This BSP layer allows to create a custom Linux distro that can be deployed in Xilinx FPGA's which can either have a soft-cpu model or a traditional CPU like PowerPC or ARM Cortex A9. @Richard, Jeffrey please help Elvis to get write access in this repo. -- Regards Adrian Alonso http://aalonso.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
