[yocto] adding package management
Hullo I'm new to yocto, so I'm probably not going about this in the optimum way. I'm trying to add package management to a yocto build. My preference would be yum/rpm on a rh/centos/fedora distro (as that's the distro used elsewhere), but I don't think that's feasible. I've added: [code] IMAGE_FEATURES += package-management IMAGE_INSTALL_append += apt perl [/code] to the bottom of …conf/local.conf (I started without the perl, which I added to fix this specific issue). However, when I run [code] bitbake core-image-minimal [/code] I get the following error [code] [tim@mercury mybuilds]$ less /opt/poky/mybuilds/tmp/work/qemuarm-poky-linux-gnueabi/core-image-minimal-1.0-r0/temp/log.do_rootfs.18707 DEBUG: Executing shell function do_rootfs Generating solve db for /opt/poky/mybuilds/tmp/deploy/rpm/qemuarm... Generating solve db for /opt/poky/mybuilds/tmp/deploy/rpm/armv5te... Generating solve db for /opt/poky/mybuilds/tmp/deploy/rpm/all... Generating solve db for /opt/poky/mybuilds/tmp/deploy/rpm/all... Processing rpm... Processing zypper... Processing packagegroup-core-boot... Processing apt... Processing perl... error: Failed dependencies: /opt/poky/mybuilds/tmp/sysroots/i686-linux/usr/bin/perl-native/perl is needed by dpkg-1.16.8-r18.0.armv5te ERROR: Function failed: do_rootfs (see /opt/poky/mybuilds/tmp/work/qemuarm-poky-linux-gnueabi/core-image-minimal-1.0-r0/temp/log.do_rootfs.18707 for further information) [/code] the rpm for dpkg-1.16.8-r18.0.armv5te does indeed include that dependency. However, the file *is* present: [code] [tim@mercury mybuilds]$ ll /opt/poky/mybuilds/tmp/sysroots/i686-linux/usr/bin/perl-native/perl -rwxr-xr-x 1 tim tim 244 Dec 10 11:04 /opt/poky/mybuilds/tmp/sysroots/i686-linux/usr/bin/perl-native/perl [/code] … and since it's a couple of days old, I can see that adding perl after apt to IMAGE_INSTALL_append is pointless. Have I missed something obvious? Is this a real issue? Should I add a package manager some other way in any case? thanks Tim ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] adding package management
On 12 December 2012 11:13, Tim Coote tim+yoctoproject@coote.org wrote: I'm trying to add package management to a yocto build. My preference would be yum/rpm on a rh/centos/fedora distro (as that's the distro used elsewhere), but I don't think that's feasible. I've added: [code] IMAGE_FEATURES += package-management IMAGE_INSTALL_append += apt perl [/code] Why are you adding apt when you said you wanted rpm? Just ensure IMAGE_FEATURES has package-mangement and set PACKAGE_CLASSES to package_rpm. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] adding package management
Thanks, Ross. That fixed that. Either I had finger trouble before when invoking rpm or I needed to remove the ? from the ?= in PACKAGE_CLASSES ?= package_rpm Am I right in thinking that yum isn't in the standard recipes? Tim On 12 Dec 2012, at 11:18, Burton, Ross ross.bur...@intel.com wrote: On 12 December 2012 11:13, Tim Coote tim+yoctoproject@coote.org wrote: I'm trying to add package management to a yocto build. My preference would be yum/rpm on a rh/centos/fedora distro (as that's the distro used elsewhere), but I don't think that's feasible. I've added: [code] IMAGE_FEATURES += package-management IMAGE_INSTALL_append += apt perl [/code] Why are you adding apt when you said you wanted rpm? Just ensure IMAGE_FEATURES has package-mangement and set PACKAGE_CLASSES to package_rpm. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] adding package management
On 12 December 2012 11:31, Tim Coote tim+yoctoproject@coote.org wrote: Am I right in thinking that yum isn't in the standard recipes? Yum, no. Zypper is in oe-core and is used when you construct a RPM-based image. (note that Zypper is being replaced by Smart in oe-core master) Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH runqemu] runqemu: add support for FSTYPE=vmdk
Allow vmdk images to be run through the 'runqemu' facility.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
scripts/runqemu | 39 +--
scripts/runqemu-internal | 20
2 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index fb7ac56..190e3b4 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -27,6 +27,7 @@ usage() {
echo ROOTFS - the rootfs image file or nfsroot directory to use
echo MACHINE - the machine name (optional, autodetected from KERNEL
filename if unspecified)
echo RAMFS - boot a ramfs-based image
+echo VM - boot a vmdk image
echo Simplified QEMU command-line options can be passed with:
echo nographic - disables video console
echo serial - enables a serial console on /dev/ttyS0
@@ -41,6 +42,7 @@ usage() {
echo $MYNAME qemux86 ramfs
echo $MYNAME qemux86 qemuparams=\-m 256\
echo $MYNAME qemux86 bootparams=\psplash=false\
+echo $MYNAME path/to/image-machine.vmdk
exit 1
}
@@ -56,6 +58,7 @@ error() {
MACHINE=${MACHINE:=}
KERNEL=${KERNEL:=}
ROOTFS=${ROOTFS:=}
+VM=${VM:=}
FSTYPE=
LAZY_ROOTFS=
SCRIPT_QEMU_OPT=
@@ -84,6 +87,10 @@ process_filename() {
error conflicting FSTYPE types [$FSTYPE] and [$EXT]
fi
;;
+ /vmdk/)
+ FSTYPE=$EXT
+ VM=$filename
+ ;;
*)
error unknown file arg [$filename]
;;
@@ -192,19 +199,27 @@ elif [ ! -w /dev/net/tun ] ; then
fi
# Report errors for missing combinations of options
-if [ -z $MACHINE -a -z $KERNEL ]; then
-error you must specify at least a MACHINE or KERNEL argument
+if [ -z $MACHINE -a -z $KERNEL -a -z $VM ]; then
+error you must specify at least a MACHINE, VM, or KERNEL argument
fi
if [ $FSTYPE = nfs -a -z $ROOTFS ]; then
error NFS booting without an explicit ROOTFS path is not yet supported
fi
if [ -z $MACHINE ]; then
-MACHINE=`basename $KERNEL | sed
's/.*\(qemux86-64\|qemux86\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/'`
-if [ -z $MACHINE ]; then
-error Unable to set MACHINE from kernel filename [$KERNEL]
+if [ x$FSTYPE = xvmdk ]; then
+MACHINE=`basename $VM | sed
's/.*\(qemux86-64\|qemux86\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/'`
+if [ -z $MACHINE ]; then
+error Unable to set MACHINE from vmdk filename [$VM]
+fi
+echo Set MACHINE to [$MACHINE] based on vmdk [$VM]
+else
+MACHINE=`basename $KERNEL | sed
's/.*\(qemux86-64\|qemux86\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/'`
+if [ -z $MACHINE ]; then
+error Unable to set MACHINE from kernel filename [$KERNEL]
+fi
+echo Set MACHINE to [$MACHINE] based on kernel [$KERNEL]
fi
-echo Set MACHINE to [$MACHINE] based on kernel [$KERNEL]
fi
YOCTO_KVM_WIKI=https://wiki.yoctoproject.org/wiki/How_to_enable_KVM_for_Poky_qemu;
@@ -366,7 +381,7 @@ if [ -e $ROOTFS -a -z $FSTYPE ]; then
fi
fi
-if [ -z $KERNEL ]; then
+if [ -z $KERNEL -a x$FSTYPE != xvmdk ]; then
setup_tmpdir
eval kernel_file=\$${machine2}_DEFAULT_KERNEL
KERNEL=$OE_TMPDIR/deploy/images/$kernel_file
@@ -395,7 +410,7 @@ if [ $LAZY_ROOTFS = true ]; then
ROOTFS=$OE_TMPDIR/deploy/images/$ROOTFS-$MACHINE.$FSTYPE
fi
-if [ -z $ROOTFS ]; then
+if [ -z $ROOTFS -a x$FSTYPE != xvmdk ]; then
setup_tmpdir
T=$OE_TMPDIR/deploy/images
eval rootfs_list=\$${machine2}_DEFAULT_ROOTFS
@@ -409,8 +424,12 @@ fi
echo
echo Continuing with the following parameters:
-echo KERNEL: [$KERNEL]
-echo ROOTFS: [$ROOTFS]
+if [ x$FSTYPE != xvmdk ]; then
+echo KERNEL: [$KERNEL]
+echo ROOTFS: [$ROOTFS]
+else
+echo VMDK: [$VM]
+fi
echo FSTYPE: [$FSTYPE]
setup_sysroot
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index 7ca00f8..fd1304e 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -260,13 +260,13 @@ case $MACHINE in
;;
esac
-if [ ! -f $KERNEL ]; then
+if [ ! -f $KERNEL -a x$FSTYPE != xvmdk ]; then
echo Error: Kernel image file $KERNEL doesn't exist
cleanup
return
fi
-if [ $FSTYPE != nfs -a ! -f $ROOTFS ]; then
+if [ $FSTYPE != nfs -a $FSTYPE != vmdk -a ! -f $ROOTFS ]; then
echo Error: Image file $ROOTFS doesn't exist
cleanup
return
@@ -341,6 +341,9 @@ if [ $MACHINE = qemux86 ]; then
KERNCMDLINE=root=/dev/nfs nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw
$KERNEL_NETWORK_CMD mem=$QEMU_MEMORY
QEMUOPTIONS=$QEMU_NETWORK_CMD $QEMU_UI_OPTIONS
fi
+if [ $FSTYPE = vmdk ]; then
+QEMUOPTIONS=$QEMU_NETWORK_CMD $QEMU_UI_OPTIONS
+fi
# Currently oprofile's event based interrupt mode doesn't work(Bug #828) in
# qemux86 and qemux86-64. We can use timer interrupt mode for now.
Re: [yocto] [PATCH runqemu] runqemu: add support for FSTYPE=vmdk
Hi Scott, Thank you for reviewing my patch. On Wed, Dec 12, 2012 at 12:55 AM, Scott Garman scott.a.gar...@intel.com wrote: This looks ok without having tested it personally. Could you just add a signed-off-by line to the commit? D'oh! Sorry about that. It has obviously been too long since I last contributed to a project :-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] [eclipse-poky][branch: windows-build] Performance fix for New Bitbake project
- after creating the project, the wizard should not block waiting for the
environment to be populated and instead should be ran in the background
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
---
.../src/org/yocto/bc/bitbake/BBSession.java| 81
.../src/org/yocto/bc/bitbake/ShellSession.java |7 +-
.../org/yocto/bc/remote/utils/RemoteHelper.java|3 +-
.../remote/utils/YoctoHostShellProcessAdapter.java | 16 +++-
.../yocto/bc/ui/wizards/FiniteStateWizardPage.java | 54 +++--
.../bc/ui/wizards/NewBitBakeFileRecipeWizard.java | 58 +++---
.../yocto/bc/ui/wizards/install/InstallWizard.java | 63 +--
.../yocto/bc/ui/wizards/install/OptionsPage.java |9 ++-
8 files changed, 173 insertions(+), 118 deletions(-)
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 3aa4efe..a5bf1ca 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
@@ -13,8 +13,8 @@ package org.yocto.bc.bitbake;
import java.io.BufferedReader;
import java.io.File;
import java.io.FileFilter;
+import java.io.FileReader;
import java.io.IOException;
-import java.io.StringReader;
import java.net.URI;
import java.util.ArrayList;
import java.util.Arrays;
@@ -48,7 +48,7 @@ import org.yocto.bc.ui.model.ProjectInfo;
/**
* BBSession encapsulates a global bitbake configuration and is the primary
interface
* for actions against a BitBake installation.
- *
+ *
* @author kgilmer
*
*/
@@ -57,7 +57,9 @@ public class BBSession implements IBBSessionListener,
IModelElement, Map {
public static final int TYPE_UNKNOWN = 2;
public static final int TYPE_STATEMENT = 3;
public static final int TYPE_FLAG = 4;
-
+
+ public static final String BB_ENV_FILE = bitbake.env;
+
public static final String BUILDDIR_INDICATORS [] = {
/conf/local.conf,
/conf/bblayers.conf,
@@ -74,20 +76,20 @@ public class BBSession implements IBBSessionListener,
IModelElement, Map {
private final Lock wlock = rwlock.writeLock();
protected String parsingCmd;
private boolean silent = false;
-
+
public BBSession(ShellSession ssession, URI projectRoot) throws
IOException {
shell = ssession;
this.pinfo = new ProjectInfo();
pinfo.setLocation(projectRoot);
pinfo.setInitScriptPath(ProjectInfoHelper.getInitScriptPath(projectRoot));
- this.parsingCmd = DISABLE_SANITY_CHECKS=\1\ bitbake -e;
+ this.parsingCmd = sh -c 'DISABLE_SANITY_CHECKS=\1\ bitbake
-e + BB_ENV_FILE + ' ;
}
public BBSession(ShellSession ssession, URI projectRoot, boolean
silent) throws IOException {
this(ssession, projectRoot);
this.silent = silent;
}
-
+
private Collection adapttoIPath(ListFile asList, IProject project) {
List pathList = new ArrayList();
@@ -102,7 +104,7 @@ public class BBSession implements IBBSessionListener,
IModelElement, Map {
return pathList;
}
-
+
private String appendAll(String[] elems, int st) {
StringBuffer sb = new StringBuffer();
@@ -112,7 +114,7 @@ public class BBSession implements IBBSessionListener,
IModelElement, Map {
return sb.toString();
}
-
+
private int charCount(String trimmed, char c) {
int i = 0;
int p = 0;
@@ -124,11 +126,13 @@ public class BBSession implements IBBSessionListener,
IModelElement, Map {
return i;
}
-
+
+ @Override
public void clear() {
throw new RuntimeException(BB configuration is read-only.);
}
+ @Override
public boolean containsKey(Object arg0) {
try {
checkValidAndLock(true);
@@ -141,6 +145,7 @@ public class BBSession implements IBBSessionListener,
IModelElement, Map {
}
}
+ @Override
public boolean containsValue(Object arg0) {
try {
checkValidAndLock(true);
@@ -153,6 +158,7 @@ public class BBSession implements IBBSessionListener,
IModelElement, Map {
}
}
+ @Override
public Set entrySet() {
try {
checkValidAndLock(true);
@@ -188,7 +194,7 @@ public class BBSession implements IBBSessionListener,
IModelElement, Map {
/**
* Recursively generate list of Recipe files from a root directory.
-*
+*
* @param rootDir
* @param recipes
* @param fileExtension
@@ -197,6 +203,7 @@ public class BBSession
Re: [yocto] [PATCH v3] [eclipse-poky-windows][branch:windows-build]Remove validate existing repository radio button
Hi Jessica,
I have sent a new patch that targets the downtime issue that you reported,
against windows-build current branch.
The downtime that you noticed it is due to the fact that with the current
implementation, the commands are ran synchronously, meaning that each command
must wait for the previous one to finish.
In the past, this was done by creating a process for each command, and waiting
for its output. At the moment, we have a shell per remote connection, and we
need to know when a command has finished running.
In the case of the New Bitbake project, the downtime is caused by sourcing the
environment, and retrieving the values outputted by bitbake -e.
With the current patch, the output of this command, is silenced and the process
is not blocking the new project wizard, but running in the background.
There is one scenario in which this implementation is not safe, which is that
where the user creates a new project from an existing directory, and soon after
does some operation that uses the presumably already populated environment from
bitbake, which may or may not be available, since it is sent in the background.
One possible solution for this, is to show to the user that this operation is
in progress, and he still needs to wait a bit for this to be done before
performing any operations that might need this information.
What is your opinion on this matter?
Thanks,
Ioana
-Original Message-
From: Zhang, Jessica
Sent: Wednesday, December 12, 2012 12:44 AM
To: Grigoropol, IoanaX; yocto@yoctoproject.org
Subject: RE: [yocto] [PATCH v3]
[eclipse-poky-windows][branch:windows-build]Remove validate existing repository
radio button
Hi Ioana,
I merged your patches up to this one to jzhang/windows-build branch of
eclipse-poky. Please send out the final patches for Linux performance
improvements that we've discussed. Also, many java files there's a comment
section at the beginning, can you add some comments about your changes to those
files? For example,
plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizardPage.java
Thanks,
Jessica
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Ioana Grigoropol
Sent: Tuesday, December 11, 2012 6:04 AM
To: yocto@yoctoproject.org
Subject: [yocto] [PATCH v3] [eclipse-poky-windows][branch:windows-build]Remove
validate existing repository radio button
- remove radio button for validating existing repository but keep performing
the validation in the back
- make 'clone' button a check button
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
---
.../yocto/bc/ui/wizards/install/OptionsPage.java | 30
1 file changed, 6 insertions(+), 24 deletions(-)
diff --git
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
index 9e94aea..72aeec2 100644
---
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/Option
+++ sPage.java
@@ -54,7 +54,6 @@ public class OptionsPage extends FiniteStateWizardPage {
private ValidationListener validationListener;
private Text txtProjectName;
private Button btnGit;
- private Button btnValidate;
private RemoteProjectContentsLocationArea locationArea;
@@ -67,7 +66,7 @@ public class OptionsPage extends FiniteStateWizardPage {
public void createControl(Composite parent) {
top = new Composite(parent, SWT.None);
top.setLayout(new GridLayout());
- top.setLayoutData(new GridData(GridData.FILL_BOTH));
+ top.setLayoutData(new GridData(GridData.FILL_HORIZONTAL));
GridData gdFillH = new GridData(GridData.FILL_HORIZONTAL);
@@ -97,25 +96,13 @@ public class OptionsPage extends FiniteStateWizardPage {
locationArea = new
RemoteProjectContentsLocationArea(errorReporter, top, null);
- Group locationValidationGroup = new Group(top, SWT.NONE);
- locationValidationGroup.setText(Git repository);
- GridData gd = new GridData(GridData.VERTICAL_ALIGN_END |
GridData.FILL_HORIZONTAL);
- locationValidationGroup.setLayoutData(gd);
- GridLayout gl = new GridLayout(1, false);
- locationValidationGroup.setLayout(gl);
-
- btnGit = new Button(locationValidationGroup, SWT.RADIO);
+ btnGit = new Button(top, SWT.CHECK);
btnGit.setText(Clone from Yocto Project Git Repository into
new location);
btnGit.setEnabled(true);
btnGit.setSelection(true);
btnGit.addSelectionListener(validationListener);
-
-
- btnValidate = new Button(locationValidationGroup, SWT.RADIO);
-
Re: [yocto] adding package management
ok. Thanks. just spotted the split between rpm / rpm5 and yum. I suppose that the knock on is managing multiple repos for different update managers. don't suppose you know if there are material differences from a packaging/dependency point of view between rpm4 and rpm5? is there an eta for smart in the mainstream core? On 12 Dec 2012, at 11:43, Burton, Ross ross.bur...@intel.com wrote: On 12 December 2012 11:31, Tim Coote tim+yoctoproject@coote.org wrote: Am I right in thinking that yum isn't in the standard recipes? Yum, no. Zypper is in oe-core and is used when you construct a RPM-based image. (note that Zypper is being replaced by Smart in oe-core master) Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] adding package management
On 12 December 2012 12:07, Tim Coote tim+yoctoproject@coote.org wrote: don't suppose you know if there are material differences from a packaging/dependency point of view between rpm4 and rpm5? Not sure, I prefer opkg for Yocto and am a Debian user for my desktop.s is there an eta for smart in the mainstream core? The patches are being finalised right now. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Disabling PREMIRRORS and upstream sources
Hi Jon, Thanks for the clarification on which manual release you were looking at. I am the technical writer for the project so hopefully someone from the team will address the technical aspect of you issue. If there is a way to disable these within a specific recipe then I can get that information into the documentation. Does anyone know if this is possible and how to do it? Scott -Original Message- From: Jon Szymaniak [mailto:jon.szyman...@gmail.com] Sent: Tuesday, December 11, 2012 8:26 PM To: Rifenbark, Scott M Cc: yocto@yoctoproject.org Subject: Re: [yocto] Disabling PREMIRRORS and upstream sources From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Jon Szymaniak Sent: Monday, December 03, 2012 7:19 AM To: yocto@yoctoproject.org Subject: [yocto] Disabling PREMIRRORS and upstream sources Is there a simple way to disable the use of PREMIRRORS and MIRRORS within a recipe? (Perhaps the answer here might be worth mentioning in Section 12.23 of the Poky Reference Manual?) My use case for this is the situation where the code hasn't been released yet, so there's no point in checking mirrors. Thank you, Jon Isn't this set up in the local.conf file for global use? In the manual I see that there are indeed global options, configured via local.conf. However, I'm wondering if there's a way to denote that PREMIRRORS and MIRRORS should not be used for a *specific recipe* (i.e., only attempt to fetch via what's provided in SRC_URI, and still use the mirrors for other recipes). Perhaps this is a wacky thing to want to do. I just figured there's no sense in hitting all those 404's if I know the code associated with a specific recipe isn't on any of the standard mirrors. Also, Jon, what documentation are you referring to here? Are you looking at the latest Yocto Project documentation (e.g. http://www.yoctoproject.org/docs/1.4/poky-ref- manual/poky-ref-manual.html for the Yocto Project Reference Manual?). I think I may have actually been looking at an old manual version, but yes, that'd the documentation I was referring to. It seemed that 12.23, How does the OpenEmbedded build system obtain source code... seemed the most relevant to my question. Thanks! Jon ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Disabling PREMIRRORS and upstream sources
On Monday 03 December 2012 10:19:00 Jon Szymaniak wrote: Is there a simple way to disable the use of PREMIRRORS and MIRRORS within a recipe? (Perhaps the answer here might be worth mentioning in Section 12.23 of the Poky Reference Manual?) My use case for this is the situation where the code hasn't been released yet, so there's no point in checking mirrors. I guess the easiest thing would be just to set PREMIRRORS and MIRRORS to in the recipe. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFCv3 0/7][eclipse-poky] Integrate yocto documentation into eclipse
Hi, m...@timomueller.eu wrote, On 06.12.2012 16:48: From: Timo Mueller timo.muel...@bmw-carit.de Hi, since the last proposal some things have changed: 1. Eclipse help generation is now part of the yocto-docs project (currently available in the origin/timo branch) 2. We agreed that the plugin should be licensed under the EPL v1.0 instead of having a separate documentation plugin licensed under the CCA-SA 2.0 UK. The last patch set was adding generated eclipse help files (html) to the repository. One major change in this patch series is that I extended the plugin build system to integrate the generation into the build process. Thus keeping the eclipse help and the official documentation in sync is now automated. Also the eclipse help is now part of the user.doc plugin and no longer contained in a separate plugin/feature. Rational from the original patch: snip the documentation of the yocto project can currently be viewed online or as a separate pdf. When using the eclipse ide to develop software on base of a yocto sysroot and toolchain it would be convenient to access the relevant parts of the documentation from within the ide. /snip snip I have intergrated this documentation in the ide and it can now be accessed through the eclipse help center (Help - Help Contents). /snip Best regards Timo Timo Mueller (7): plugins/sdk.ide.doc.user: Add empty eclipse help plugins/sdk.ide.doc.user: Add about.html to prepare addition of yocto documentation scripts/generate_doc.sh: Add script to handle eclipse help generation plugins/sdk.ide.doc.user: Add yocto documentation to the table of contents scripts/generat-doc.sh: Copy generated eclipse help into the user.doc plugin scripts/build.sh: Add documentation generation to the default build (TEMPORARY): Use origin/timo branch of yocto docs project .../META-INF/MANIFEST.MF |3 +- plugins/org.yocto.sdk.ide.doc.user/about.html.in | 166 .../org.yocto.sdk.ide.doc.user/build.properties|9 +- plugins/org.yocto.sdk.ide.doc.user/html/book.css |1 + plugins/org.yocto.sdk.ide.doc.user/plugin.xml | 31 plugins/org.yocto.sdk.ide.doc.user/toc.xml | 21 +++ scripts/build.sh |7 + scripts/generate_doc.sh| 91 +++ 8 files changed, 326 insertions(+), 3 deletions(-) create mode 100644 plugins/org.yocto.sdk.ide.doc.user/about.html.in create mode 100644 plugins/org.yocto.sdk.ide.doc.user/html/book.css create mode 100644 plugins/org.yocto.sdk.ide.doc.user/toc.xml create mode 100755 scripts/generate_doc.sh The name of the poky-ref-manual will be changed to ref-manual. This change has an impact on this patch series, since the name is used in the generate-doc shell script. But with the temporary fix in patch 7, the timo branch is used, which will for the time being remain unaffected by the name changes. This way you can test the documentation integration proposed in this patch set. I would like to get your opinion on the general approach to integrate the documentation into eclipse. If it fits into the eclipse-poky project in general, I will rewrite this patch series to reflect the changes. The rewrite will also remove the the from the different help chapters (as Scott pointed out to me). I also agreed with Scott that once this approach is agreed on I will provide the necessary patches to the timo branch of the yocto-docs project and he will merge the eclipse generation into the master of the project. Best regards, Timo PS: I also apologize for not signing off the patch series. I will make up for that in the reworked patches. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Building pseudo fails
I just downloaded the Danny release to an Ubuntu 12.10 computer, and
pseudo failed to build. Before opening a bug, I just wanted to make sure
it's not something silly I am doing. The log file is attached and below
I've pasted the terminal output.
Thanks!
Belen
Pseudo is not present but is required, building this first before the main
build
Loading cache: 100% |###| ETA:
00:00:00
Loaded 1132 entries from dependency cache.
Build Configuration:
BB_VERSION= 1.16.0
TARGET_ARCH = i586
TARGET_OS = linux
MACHINE = qemux86
DISTRO= poky
DISTRO_VERSION= 1.3
TUNE_FEATURES = m32 i586
TARGET_FPU=
meta
meta-yocto
meta-yocto-bsp= unknown:unknown
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Error executing a python function in
/home/yocto/poky-danny-8.0/meta/recipes-devtools/quilt/quilt-native_0.60.bb
http://quilt-native_0.60.bb/:
OSError: [Errno 2] No such file or directory
ERROR: The stack trace of python calls that resulted in this
exception/failure was:
ERROR: File relocatable_binaries_preprocess, line 6, in module
ERROR:
ERROR: File relocatable_binaries_preprocess, line 3, in
relocatable_binaries_preprocess
ERROR:
ERROR: File chrpath.bbclass, line 7, in rpath_replace
ERROR:
ERROR: File chrpath.bbclass, line 36, in process_dir
ERROR:
ERROR: File /usr/lib/python2.7/subprocess.py, line 679, in __init__
ERROR: errread, errwrite)
ERROR:
ERROR: File /usr/lib/python2.7/subprocess.py, line 1259, in
_execute_child
ERROR: raise child_exception
ERROR:
ERROR: The code that was being executed was:
ERROR: 0002:def relocatable_binaries_preprocess(d):
ERROR: 0003:
rpath_replace(d.expand('/home/yocto/poky-danny-8.0/build/tmp/work/i686-linu
x/quilt-native-0.60-r0/sysroot-destdir/'), d)
ERROR: 0004:
ERROR: 0005:
ERROR: *** 0006:relocatable_binaries_preprocess(d)
ERROR: 0007:
ERROR: [From file: 'relocatable_binaries_preprocess', lineno: 6, function:
module]
ERROR: 0001:
ERROR: 0002:def relocatable_binaries_preprocess(d):
ERROR: *** 0003:
rpath_replace(d.expand('/home/yocto/poky-danny-8.0/build/tmp/work/i686-linu
x/quilt-native-0.60-r0/sysroot-destdir/'), d)
ERROR: 0004:
ERROR: 0005:
ERROR: 0006:relocatable_binaries_preprocess(d)
ERROR: 0007:
ERROR: [From file: 'relocatable_binaries_preprocess', lineno: 3, function:
relocatable_binaries_preprocess]
ERROR: 0003:
ERROR: 0004:for bindir in bindirs:
ERROR: 0005:#bb.note (Processing directory + bindir)
ERROR: 0006:directory = path + / + bindir
ERROR: *** 0007:process_dir (directory, d)
ERROR: 0008:
ERROR: [From file: 'chrpath.bbclass', lineno: 7, function: rpath_replace]
ERROR: 0032:else:
ERROR: 0033:# Temporarily make the file writeable so
we can chrpath it
ERROR: 0034:os.chmod(fpath, perms|stat.S_IRWXU)
ERROR: 0035:
ERROR: *** 0036:p = sub.Popen([cmd, '-l',
fpath],stdout=sub.PIPE,stderr=sub.PIPE)
ERROR: 0037:err, out = p.communicate()
ERROR: 0038:# If returned succesfully, process stderr for
results
ERROR: 0039:if p.returncode != 0:
ERROR: 0040:continue
ERROR: [From file: 'chrpath.bbclass', lineno: 36, function: process_dir]
ERROR: Function failed: relocatable_binaries_preprocess
ERROR: Logfile of failure stored in:
/home/yocto/poky-danny-8.0/build/tmp/work/i686-linux/quilt-native-0.60-r0/t
emp/log.do_populate_sysroot.7795
ERROR: Task 10
(/home/yocto/poky-danny-8.0/meta/recipes-devtools/quilt/quilt-native_0.60.b
b http://quilt-native_0.60.bb/, do_populate_sysroot) failed with exit
code '1'
NOTE: Tasks Summary: Attempted 7 tasks of which 6 didn't need to be rerun
and 1 failed.
No currently running tasks (7 of 63)
Summary: 1 task failed:
/home/yocto/poky-danny-8.0/meta/recipes-devtools/quilt/quilt-native_0.60.bb
http://quilt-native_0.60.bb/, do_populate_sysroot
Summary: There were 50 ERROR messages shown, returning a non-zero exit
code.
-
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.
log.do_populate_sysroot.7795
Description: log.do_populate_sysroot.7795
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building pseudo fails
On 12 December 2012 14:09, Barros Pena, Belen belen.barros.p...@intel.com wrote: I just downloaded the Danny release to an Ubuntu 12.10 computer, and pseudo failed to build. Before opening a bug, I just wanted to make sure it's not something silly I am doing. The log file is attached and below I've pasted the terminal output. It appears you need to install the chrpath package. If that fixes it then we've clearly got a mismatch between the assumed to exist list and the verified to exist list. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building pseudo fails
On Wednesday 12 December 2012 14:15:50 Burton, Ross wrote: On 12 December 2012 14:09, Barros Pena, Belen belen.barros.p...@intel.com wrote: I just downloaded the Danny release to an Ubuntu 12.10 computer, and pseudo failed to build. Before opening a bug, I just wanted to make sure it's not something silly I am doing. The log file is attached and below I've pasted the terminal output. It appears you need to install the chrpath package. If that fixes it then we've clearly got a mismatch between the assumed to exist list and the verified to exist list. Whoops, missed this earlier when I talked to Belen about this issue off-list. chrpath is in the list of verified to exist utilities (SANITY_REQUIRED_UTILITIES), however the catch is that when running hob the sanity checks are deferred until the UI actually starts (which is after pseudo gets built), so you won't get the error on startup. Obviously this is not an ideal situation; I suspect we're going to need to re- engineer how the sanity checks are run within hob so that the critical ones can run before pseudo gets built and only the ones that may require configuration (e.g. network connectivity checks) are deferred. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building pseudo fails
That totally worked. Silly me, just realised I forgot to check the quick start guide to install the required packages. Thanks, Ross. Belen On 12/12/2012 14:15, Burton, Ross ross.bur...@intel.com wrote: On 12 December 2012 14:09, Barros Pena, Belen belen.barros.p...@intel.com wrote: I just downloaded the Danny release to an Ubuntu 12.10 computer, and pseudo failed to build. Before opening a bug, I just wanted to make sure it's not something silly I am doing. The log file is attached and below I've pasted the terminal output. It appears you need to install the chrpath package. If that fixes it then we've clearly got a mismatch between the assumed to exist list and the verified to exist list. Ross - 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
[yocto] building for ZYNQ ZC702 SoC
Hi all, I am new to Yocto. I am trying to build an environment with arm-gcc integrated since the ZYNQ board has ARM Cortex A9 ducal core on it. Let me know if any one has tried something similar or some pointers on how i can proceed. -- *Anup Kini *Systems Engineer * -- * *Synapticon** * | Cyber-Physical System Solutions Direct: +49 7335 / 186 999 17 Fax: +49 7335 / 186 999 19 synapticon.com http://www.synapticon.com/ | @synapticon_cohttps://twitter.com/#!/synapticon_co Synapticon GmbH | Hohlbachweg 2 | 73344 Gruibingen, DE Secretary +49 7335 / 186 999 0 | General Manager: Nikolai Ensslen Registry Court Ulm HRB 725114 | USt-ID DE271647127 This message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Please notify the sender immediately if you have received this e-mail by mistake and delete it from your system. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] building for ZYNQ ZC702 SoC
Hi Anup,
Atleast two people on the yocto mailing list have successfully
built the toolchain and rootfile system for the ZC702, Philip Balister and
myself, using the latest yocto master.
Here are a few steps:
01. Look up the Yocto Quick Start Guide to setup your Ubuntu 12.10 x86 64-bit
host development environment.
02. Use Philip Balister's meta-zynq layer located here, and add it to your
bblayer.conf file
https://github.com/balister/meta-zynq
$ gedit conf/bblayers.conf
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = 5
BBPATH = ${TOPDIR}
BBFILES ?=
BBLAYERS ?= \
/tool/yocto/poky/meta \
/tool/yocto/poky/meta-yocto \
/tool/yocto/meta-openembedded/toolchain-layer \
/tool/yocto/meta-zynq \
03. Updated your yocto local.conf file as follows:
#
# Xilinx target board configuration.
#
# Set the target machine details
MACHINE ?= zynq-zc702
# Set Xilinx Platform Studio hardware project path
XILINX_BSP_PATH ?= /project/xilinx-zc702
# Set target board
XILINX_BOARD ?= zc702
04. Download the souces
$ cd /tool/yocto/poky
$ source oe-init-build-env build
### Shell environment set up for builds. ###
You can now run 'bitbake target'
Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
meta-toolchain-sdk
adt-installer
meta-ide-support
You can also run generated qemu images with a command like 'runqemu qemux86'
$ bitbake -c fetchall core-image-minimal
Build Configuration:
BB_VERSION= 1.16.0
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = zynq-zc702
DISTRO= poky
DISTRO_VERSION= 1.3+snapshot-20121025
TUNE_FEATURES = armv7a vfp neon cortexa9
TARGET_FPU= vfp-neon
meta
meta-yocto= master:33440ee70623394d06a4b214c2be10788cba6d08
toolchain-layer = master:55855cd569fbff7182974ca08b1de8435bf0f597
meta-zynq-balister =
master-xilinx-zc702-gcc-4.7:d168cea411034d1f1530e4eacf6eb3ce4affd1c8
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
05. Build the toolchain
$ cd /tool/yocto/poky
$ source oe-init-build-env build
$ bitbake meta-toolchain
06. Build the image
$ bitbake core-image-minimal
07. Use Xilinx PlanAhead 14.3 software design too to create your hardware
design.
The only additional step you need to perform is to use the Xilinx PlanAhead
software, to export you hardware to the Xilinx SDK, and use the SDK to generate
and build the Zynq First Stage Bootloader (zynq_fsbl). After that, create a
boot image by using the Xilinx tool menu option, and include the u-boot.elf,
system.bit and zynq_fsbl.elf.
Use the scripts in XAPP792 to download the kernel and bootable image to the
target using XMD. Or rename the u-boot.bin file to BOOT.bin, copy the uImage
generated from the yocto build, and it should all work.
Best regards,
Elvis Dowson
On Dec 12, 2012, at 6:56 PM, Anup Kini ak...@synapticon.com wrote:
Hi all,
I am new to Yocto.
I am trying to build an environment with arm-gcc integrated since the ZYNQ
board has ARM Cortex A9 ducal core on it.
Let me know if any one has tried something similar or some pointers on how i
can proceed.
--
Anup Kini
Systems Engineer
Synapticon | Cyber-Physical System Solutions
Direct:
+49 7335 / 186 999 17
Fax:
+49 7335 / 186 999 19
synapticon.com | @synapticon_co
Synapticon GmbH | Hohlbachweg 2 | 73344 Gruibingen, DE
Secretary +49 7335 / 186 999 0 | General Manager: Nikolai Ensslen
Registry Court Ulm HRB 725114 | USt-ID DE271647127
This message and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
Please notify the sender immediately if you have received this e-mail by
mistake and delete it from your system.
___
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] CyaSSL Yocto Recipe
On Tue, 2012-10-09 at 14:26 -0600, Chris Conlon wrote: On Sep 6, 2012, at 4:53 PM, Richard Purdie wrote: This looks like an interesting piece of software and a quick read through your webpages suggests there may be some interesting applications of this within OE which I'd love to explore. We are however quite careful about what goes into OE-Core and you've picked about the worst possible point of the cycle to have this discussion (just after feature freeze which was six days ago). So I certainly think this could make OE-Core but probably not in the 1.3 release timeframe. I would also want to see some kind of demo that we could replace some of our openssl/gnutls usage with this too which so far I've not seen. There is discussion in the OE-Core archives about making the SSL/TLS provider selectable though so there is certainly interest. So I think this is a good idea, a layer is a great place to start experimenting and if its shown to be successful it would make the core. We've got to be realistic about the development process and this isn't going to happen overnight though (a layer is much easier/faster to start with). As suggested, we have created a yaSSL layer (meta-yassl) which includes a recipe for the CyaSSL embedded SSL library. The layer can be found on GitHub, here: https://github.com/cconlon/meta-yassl Any comments or suggestions on improving the layer would be greatly appreciated. Going forward from here, what would make the most sense as a next step? I did finally get around to looking at this, sorry about the delay. The release and some travel commitments all combined against me time wise. I must admit I thought the layer was going to do a little more than it does. The layer in itself is fine and I was able to build it successfully. I did notice the library is a little larger than your 30-100kb quoted on the website. I also noticed it builds with the default configuration with lot of pieces disabled. I think as this stands its interesting but you might not get many people using it. What would get people much more interested is if you could build a system where openssl/gnutls was replaced with cyassl. Initially, I think a proof of concept using .bbappend files to reconfigure recipes to use cyassl would be a good place to start. Once proved to work, we could then incorporate generic ssl providers code into the project core, allowing people to select the ssl provider at will. Is this a direction you'd be willing/able to take the layer? Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] building for ZYNQ ZC702 SoC
Hi Elvis,
I could not find where the arm gcc was included in this build.
I was checking the build process and took the gcc.4.4.6 while building the
core-image-minimal.
Hence i wanted to confirm if the arm-gcc can be integrated and steps to do
it.
On 12 December 2012 16:18, Elvis Dowson elvis.dow...@gmail.com wrote:
Hi Anup,
Atleast two people on the yocto mailing list have
successfully built the toolchain and rootfile system for the ZC702, Philip
Balister and myself, using the latest yocto master.
Here are a few steps:
01. Look up the Yocto Quick Start Guide to setup your Ubuntu 12.10 x86
64-bit host development environment.
02. Use Philip Balister's meta-zynq layer located here, and add it to your
bblayer.conf file
https://github.com/balister/meta-zynq
$ gedit conf/bblayers.conf
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = 5
BBPATH = ${TOPDIR}
BBFILES ?=
BBLAYERS ?= \
/tool/yocto/poky/meta \
/tool/yocto/poky/meta-yocto \
/tool/yocto/meta-openembedded/toolchain-layer \
/tool/yocto/meta-zynq \
03. Updated your yocto local.conf file as follows:
#
# Xilinx target board configuration.
#
# Set the target machine details
MACHINE ?= zynq-zc702
# Set Xilinx Platform Studio hardware project path
XILINX_BSP_PATH ?= /project/xilinx-zc702
# Set target board
XILINX_BOARD ?= zc702
04. Download the souces
$ cd /tool/yocto/poky
$ source oe-init-build-env build
### Shell environment set up for builds. ###
You can now run 'bitbake target'
Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
meta-toolchain-sdk
adt-installer
meta-ide-support
You can also run generated qemu images with a command like 'runqemu
qemux86'
$ bitbake -c fetchall core-image-minimal
Build Configuration:
BB_VERSION= 1.16.0
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = zynq-zc702
DISTRO= poky
DISTRO_VERSION= 1.3+snapshot-20121025
TUNE_FEATURES = armv7a vfp neon cortexa9
TARGET_FPU= vfp-neon
meta
meta-yocto= master:33440ee70623394d06a4b214c2be10788cba6d08
toolchain-layer = master:55855cd569fbff7182974ca08b1de8435bf0f597
meta-zynq-balister =
master-xilinx-zc702-gcc-4.7:d168cea411034d1f1530e4eacf6eb3ce4affd1c8
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
05. Build the toolchain
$ cd /tool/yocto/poky
$ source oe-init-build-env build
$ bitbake meta-toolchain
06. Build the image
$ bitbake core-image-minimal
07. Use Xilinx PlanAhead 14.3 software design too to create your hardware
design.
The only additional step you need to perform is to use the Xilinx
PlanAhead software, to export you hardware to the Xilinx SDK, and use the
SDK to generate and build the Zynq First Stage Bootloader (zynq_fsbl).
After that, create a boot image by using the Xilinx tool menu option, and
include the u-boot.elf, system.bit and zynq_fsbl.elf.
Use the scripts in XAPP792 to download the kernel and bootable image to
the target using XMD. Or rename the u-boot.bin file to BOOT.bin, copy the
uImage generated from the yocto build, and it should all work.
Best regards,
Elvis Dowson
On Dec 12, 2012, at 6:56 PM, Anup Kini ak...@synapticon.com wrote:
Hi all,
I am new to Yocto.
I am trying to build an environment with arm-gcc integrated since the ZYNQ
board has ARM Cortex A9 ducal core on it.
Let me know if any one has tried something similar or some pointers on how
i can proceed.
--
*Anup Kini
*Systems Engineer
*
--
*
*Synapticon** * | Cyber-Physical System Solutions
Direct:
+49 7335 / 186 999 17
Fax:
+49 7335 / 186 999 19
synapticon.com http://www.synapticon.com/ |
@synapticon_cohttps://twitter.com/#!/synapticon_co
Synapticon GmbH | Hohlbachweg 2 | 73344 Gruibingen, DE
Secretary +49 7335 / 186 999 0 | General Manager: Nikolai Ensslen
Registry Court Ulm HRB 725114 | USt-ID DE271647127
This message and any files transmitted with it are confidential and
intended
solely for the use of the individual or entity to whom they are addressed.
Please notify the sender immediately if you have received this e-mail by
mistake and delete it from your system.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
*Anup Kini
*Systems Engineer
*
--
*
*Synapticon** * | Cyber-Physical System Solutions
Direct:
+49 7335 / 186 999 17
Fax:
+49 7335 / 186 999 19
synapticon.com http://www.synapticon.com/ |
@synapticon_cohttps://twitter.com/#!/synapticon_co
Synapticon GmbH | Hohlbachweg 2 | 73344
Re: [yocto] building for ZYNQ ZC702 SoC
Hi Anup, On Dec 12, 2012, at 7:32 PM, Anup Kini ak...@synapticon.com wrote: I could not find where the arm gcc was included in this build. I was checking the build process and took the gcc.4.4.6 while building the core-image-minimal. Hence i wanted to confirm if the arm-gcc can be integrated and steps to do it. Two things to keep in mind here: a. Yocto will generate a cross compiler for you. It will be called arm-poky-linux-gcc , and will be located in the poky/build/tmp/sysroots/x86_64-linux/usr/bin folder This won't appear in your path, unless you explicitly specify it. You can use this to build u-boot, the linux kernel and the root filesystem for the ZC702. b. The cross compiler generated from yocto has some issues building the Xilinx SDK sources, for compiling the bsp and fsbl sources. Hence, you can use the default xilinx supplied compiler, which is already setup with Xilinx SDK, to build the bsp and fsbl binaries. You only need the Xilinx supplied gcc toolchain for these tasks, as well as for bare-metal applications using StandAlone OS or XilKernel. For the rest, yocto gives you an easy way to build a fully working image for the ZC702. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Disabling PREMIRRORS and upstream sources
Hi Jon,
Thanks for the clarification on which manual release you were looking
at. I am the technical writer for the project so hopefully someone from
the team will address the technical aspect of you issue. If there is a
way to disable these within a specific recipe then I can get that
information into the documentation.
Does anyone know if this is possible and how to do it?
Scott
I guess the easiest thing would be just to set PREMIRRORS and MIRRORS to
in the recipe.
Cheers,
Paul
Scott
Scott and Paul,
Thank you both very much for your time and help!
I confirmed this does indeed work.
Just to make sure I'm understanding this... so when I place PREMIRRORS =
in a recipe, I see that it doesn't affect the associated variables in other
recipes.
Is this because I'm inherently setting up PREMIRRORS_${PN}, which is
initialized with the PREMIRROR defaults (and what was appended and
prepended in the local.conf)?
I'm also guessing that touching PREMIRRORS and MIRRORS within recipes
is generally a bad practice. I'd be curious to hear if my use case
sounds totally
wacky, as I'm still very much getting up to speed on Yocto/OE and best
practices.
Many thanks,
Jon
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Disabling PREMIRRORS and upstream sources
On Wednesday 12 December 2012 11:32:39 Jon Szymaniak wrote:
Just to make sure I'm understanding this... so when I place PREMIRRORS =
in a recipe, I see that it doesn't affect the associated variables in other
recipes.
Is this because I'm inherently setting up PREMIRRORS_${PN}, which is
initialized with the PREMIRROR defaults (and what was appended and
prepended in the local.conf)?
When you set a variable within a recipe it's setting it just within the
context of that recipe, so there's no way for it to affect other recipes.
I'm also guessing that touching PREMIRRORS and MIRRORS within recipes
is generally a bad practice. I'd be curious to hear if my use case
sounds totally
wacky, as I'm still very much getting up to speed on Yocto/OE and best
practices.
I guess it's not unreasonable to want to avoid touching anything external when
building something internal; but you're right as a general practice this is
something we would not do in published recipes.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Difference of toolchain recipes
On 12/11/12 3:20 PM, Rifenbark, Scott M wrote: I think what I am going to do is document these in general as part of the Terms section in the YP Development Manual where the term Cross-Development Toolchain is defined. Would putting such a high-level list in the YP documentation be unnecessary or helpful? I think it would. The set of compiler/toolchain elements we have is definitely confusing to someone new. --Mark Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Mark Hatle Sent: Thursday, December 06, 2012 10:05 AM To: yocto@yoctoproject.org Subject: Re: [yocto] Difference of toolchain recipes On 12/6/12 4:00 AM, Luo Zhenhua-B19537 wrote: Can anybody shed some light, please? Best Regards, Zhenhua -Original Message- From: Luo Zhenhua-B19537 Sent: Tuesday, December 04, 2012 11:53 AM To: openembedded-c...@lists.openembedded.org; 'yocto@yoctoproject.org' Subject: Difference of toolchain recipes It is a bit confused for the different recipes of toolchian, can somebody help to explain what's the difference for those recipes? E.g. gcc- cross, gcc-cross-canadian, gcc-cross-initial, gcc-cross-intermediate, gcc- crosssdk, gcc-crosssdk-initial, gcc-crosssdk-intermediate, gcc- runtime, etc. gcc-cross-initial - This is the initial compiler needed to bootstrap the toolchain to build software on the host for the target. (This is a 'native' package.) gcc-cross-intermediate - This is the second stage of the bootstrap process to build software on the host for the target. (This is a 'native' package.) gcc-cross - this is the the final stage of the bootstrap process, and results in the cross compiler to build software on the host for the target. (This is a 'native' package.) If you are replacing the cross compiler toolchain with a custom version, this is what you must replace. gcc-runtime - these are the runtime libraries, but from the toolchain bootstrapping process. This results in a 'target' binary. gcc-crosssdk-initial/intermediate - stage 1 and 2 of the a cross compiler to build from the 'host' to the 'sdk'. Often the SDK is not the same target as the host. (This is a 'native' binary.) gcc-crosssdk - this the final stage of the SDK compiler. Again, this is to build on the host, for the sdk. This is a 'native' binary. gcc-cross-canadian - This is the compiler included with the SDK to build on the SDK machine creating software for the target. This is an 'nativesdk' package. Is there any document for those description? Not that I know of.. It's one of those things that you kind of need to know in order to work with it. It likely should be documented somewhere officially. --Mark Best Regards, Zhenhua ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] adding package management
On 12/12/12 5:43 AM, Burton, Ross wrote: On 12 December 2012 11:31, Tim Coote tim+yoctoproject@coote.org wrote: Am I right in thinking that yum isn't in the standard recipes? Yum, no. Zypper is in oe-core and is used when you construct a RPM-based image. (note that Zypper is being replaced by Smart in oe-core master) See the following for more information on the change: http://permalink.gmane.org/gmane.comp.handhelds.openembedded.core/29105 The one feature that Smart does not have that Zypper does (that I know people want) is delta-rpm support. Otherwise it seems to be better for our uses in Embedded Systems. --Mark Ross ___ 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 package management
On 12/12/12 6:07 AM, Tim Coote wrote: ok. Thanks. just spotted the split between rpm / rpm5 and yum. I suppose that the knock on is managing multiple repos for different update managers. don't suppose you know if there are material differences from a packaging/dependency point of view between rpm4 and rpm5? Generated packages are more or less compatible. The only big difference is that all RPM5 packages are 'self-signed' to integrity purposes. Self-signing is better then simply md5sums. (They of course can also be signed with a specific key to indicate trust as well.) But the primary difference is in cross compiling and support for the activities that we need when cross-constructing root filesystems and such. There is also an aspect of 'control' behind this. We have input into the RPM5 development, in RPM4 we have absolutely no influence and they have removed everything that helped in a cross-compiled environment after the split. is there an eta for smart in the mainstream core? Hopefully the next version of the integration patches should be sent up today. We're really trying to get the code in by next week. --Mark On 12 Dec 2012, at 11:43, Burton, Ross ross.bur...@intel.com wrote: On 12 December 2012 11:31, Tim Coote tim+yoctoproject@coote.org wrote: Am I right in thinking that yum isn't in the standard recipes? Yum, no. Zypper is in oe-core and is used when you construct a RPM-based image. (note that Zypper is being replaced by Smart in oe-core master) Ross ___ 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] Disabling PREMIRRORS and upstream sources
If this is something we would not encourage in a published recipe, then it is
questionable as to documenting this simple way. Or, perhaps, document it with
the caveat that it is not something you would normally do?
Scott
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Wednesday, December 12, 2012 8:49 AM
To: Jon Szymaniak
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Disabling PREMIRRORS and upstream sources
On Wednesday 12 December 2012 11:32:39 Jon Szymaniak wrote:
Just to make sure I'm understanding this... so when I place PREMIRRORS
=
in a recipe, I see that it doesn't affect the associated variables in
other
recipes.
Is this because I'm inherently setting up PREMIRRORS_${PN}, which is
initialized with the PREMIRROR defaults (and what was appended and
prepended in the local.conf)?
When you set a variable within a recipe it's setting it just within the
context of that recipe, so there's no way for it to affect other
recipes.
I'm also guessing that touching PREMIRRORS and MIRRORS within recipes
is generally a bad practice. I'd be curious to hear if my use case
sounds totally
wacky, as I'm still very much getting up to speed on Yocto/OE and best
practices.
I guess it's not unreasonable to want to avoid touching anything
external when
building something internal; but you're right as a general practice this
is
something we would not do in published recipes.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] New Documentation: Linux Kernel Development with the Yocto Project
A good read, thanks! Dave On 12/12/12 12:44 AM, Darren Hart dvh...@linux.intel.com wrote: In response to much feedback on the linux-yocto recipes and the associated kernel tools, we have made a number of improvements in an attempt to make them more accessible. In particular, the tools now allow for using your own sources and configurations in a fairly simple manner, while providing a path to more complex meta-data management. The following document is intended to demystify the Yocto Project Linux Kernel Tools now that some of this work has been done. Ultimately, the goal of this document is to provide a task-based approach to developing Linux kernel recipes and meta-data with the Yocto Project. It should present information more or less in the order a developer is likely to need it. Start off by changing a config and adding a patch, then using your own sources, incorporating out of tree drivers, then diving into more complex configuration and source management. This document has seen some review prior to this announcement. I wanted to thank everyone for the feedback provided. I have done my best to incorporate it. In a couple cases I felt the additions were better left to How Do I wiki pages or a separate manual (such as the Development Manual or the BSP Guide). The following is what I am submitting to Scott R, our tech writer, for a full review and docbookification for release with the 1.4 Yocto Project release. Eventually I would like to see the following sections added to the document. 1) Workflow * Group environements * Local sources 2) Advanced Source Management * working outside of bitbake * generating the git tree from the meta-data 3) Examples For now, I feel this document should go a long way towards clarifying the use of the kernel tools and the linux-yocto recipes. I would still greatly appreciate any additional feedback and there is still plenty of time to incorporate that feedback prior to release. So if you haven't already and have the inclination, I'd welcome your review! Linux Kernel Development with the Yocto Project Table of Contents = INTRODUCTION Yocto Project Linux Kernel Recipes COMMON TASKS Preparing a Layer Modifying an Existing Recipe (Mostly covered by the Dev Manual) Applying Patches Changing the Config Iterative Development Generating Configuration Files Modifying Source Code Working with Your Own Sources Incorporating Out-of-tree Modules ADVANCED META-DATA Using Meta-Data in a Recipe Meta-Data Location Recipe-Space Meta-Data In-Tree Meta-Data Meta-Data Syntax Configuration Patches Features Kernel Types BSPs Machine Branches Feature Branches SCC Reference EXAMPLES FAQ (Maybe put this online as a wiki?) How do I use my own Linux kernel .config? How do I create configuration fragments? How do I use my own Linux kernel sources? How do I install/not-install the kernel image on the rootfs? How do install a specific kernel module? How do I changed the Linux kernel command line? 1 Introduction == Regardless of how you intend to make use of the Yocto Project, chances are you are going to need to work with the Linux kernel. The Yocto Project provides a powerful set of tools for managing Linux kernel sources and configuration data. If you want to make a single configuration change, apply a couple of patches, or work with your own sources, the Yocto Project has tooling in place to help you do it. 1.1 Yocto Project Linux Kernel Recipes -- Each Yocto Project release introduces a new set of linux-yocto kernel recipes, tracking the latest upstream developments and introducing newly supported platforms. In addition to the new kernel recipes, the previous recipes are refreshed and supported for at least one additional release. As they align, these previous releases are updated to include the latest from the LTSI project. Besides these recipes, a linux-yocto-dev recipe is available for working with the very latest in upstream Linux kernel development as well as meta-data development. If you do not maintain your own kernel sources and need to make only minimal changes to the sources, these recipes provide a vetted base upon which to layer your changes. Doing so allows you to benefit from the continual kernel integration and testing performed during development of the Yocto Project. If, instead, you have a very specific Linux kernel source tree and are unable to align with one of the many official linux-yocto releases, an alternative exists by which you can use the Yocto Project Linux kernel tools with your own sources. The sections that follow provide instructions for completing specific Linux kernel development tasks. They assume familiarity with working with bitbake recipes and basic open-source development tools. Understanding these concepts will facilitate the process of working with the kernel recipes. If you find you
[yocto] might it be worth explaining BBMASK more comprehensively?
a bit more pedantry, but is there a more complete example of the use of BBMASK than the trivial example in the ref and dev manuals? the ref manual provides this example by way of explanation: BBMASK = .*/meta-ti/recipes-misc/ well, ok, except you occasinally find slight variations like: BBMASK = meta-ti/recipes-misc/ or BBMASK = meta-ti/recipes-misc given that there are places where a trailing slash is significant, are all of the above exactly equivalent? if so, that's worth noting. also, what about an example showing masking out a couple directories, or perhaps a single recipe from a layer, and so on? at the moment, the manuals suggest you can mask multiple recipes but nowhere do i see the reader being given an actual example of how to do that. 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] might it be worth explaining BBMASK more comprehensively?
Please feel free (anyone) to provide some useful examples and a bit of explanation for each and I will be happy to get them in the manual(s). Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Wednesday, December 12, 2012 11:27 AM To: Yocto discussion list Subject: [yocto] might it be worth explaining BBMASK more comprehensively? a bit more pedantry, but is there a more complete example of the use of BBMASK than the trivial example in the ref and dev manuals? the ref manual provides this example by way of explanation: BBMASK = .*/meta-ti/recipes-misc/ well, ok, except you occasinally find slight variations like: BBMASK = meta-ti/recipes-misc/ or BBMASK = meta-ti/recipes-misc given that there are places where a trailing slash is significant, are all of the above exactly equivalent? if so, that's worth noting. also, what about an example showing masking out a couple directories, or perhaps a single recipe from a layer, and so on? at the moment, the manuals suggest you can mask multiple recipes but nowhere do i see the reader being given an actual example of how to do that. 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] should users be able to run yocto's pre-built images standalone?
On Tue, 11 Dec 2012, Rudolf Streif wrote: Hi Robert, a basic question -- is it supported that users be able to download and run yocto's pre-built QEMU images without having to download an entire build system, and set up bitbake, etc? theoretically, of course, it can be done, but it's not set up to do it conveniently (if it even should be). IMHO that is exactly what the ADT installer does. OK, it could use some enhancements but it lets you specify what pre-built images you would like to use and sets it up, including QEMU and the related scripts. ok, i haven't poked around there yet, i'll look at that later. first, one can't get yocto's qemu-related utilities without downloading either oe-core or a toolchain. is that really necessary? how hard would it be to break out the QEMU stuff into a much smaller tarball if that's all people want? I think you want at least QEMU, the scripts, the user-space NFS server and the cross-toolchain. Quite frankly, what do you really do with just QEMU, scripts and images? Either you want to build your own images then you need Poky (the build system) or you want to do user-space development then you need images and a cross-toolchain. Just booting an image into QEMU seems quite boring to me. good point ... i originally envisioned someone perhaps wanting to do nothing more than just downloading and running the pre-built images to see what all the fuss was about. if that's really not considered a useful example, i'll forget about it. and if that's done, certainly, the help messages from runqemu can be updated, since those utilities clearly assume they're running as part of a build infrastructure when that's not necessary. Fair enough, but if you could provide more details outlining what the error message said, what the root cause of the problem was, and what you think the error message should say, it would really help the developers to make the improvements. Unless you are inclined to rummage through the code, fix it and submit patches. ah, that i can provide. in the runqemu usage message, you see the suggestion: $MYNAME qemux86-64 core-image-sato ext3 but that assumes you're in a build directory. of course, using the adt-installer as you suggested might make all this moot. 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] Difference of toolchain recipes
Thanks for the feedback Mark. I will go ahead with it. Scott -Original Message- From: Mark Hatle [mailto:mark.ha...@windriver.com] Sent: Wednesday, December 12, 2012 9:08 AM To: Rifenbark, Scott M Cc: yocto@yoctoproject.org Subject: Re: [yocto] Difference of toolchain recipes On 12/11/12 3:20 PM, Rifenbark, Scott M wrote: I think what I am going to do is document these in general as part of the Terms section in the YP Development Manual where the term Cross- Development Toolchain is defined. Would putting such a high-level list in the YP documentation be unnecessary or helpful? I think it would. The set of compiler/toolchain elements we have is definitely confusing to someone new. --Mark Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Mark Hatle Sent: Thursday, December 06, 2012 10:05 AM To: yocto@yoctoproject.org Subject: Re: [yocto] Difference of toolchain recipes On 12/6/12 4:00 AM, Luo Zhenhua-B19537 wrote: Can anybody shed some light, please? Best Regards, Zhenhua -Original Message- From: Luo Zhenhua-B19537 Sent: Tuesday, December 04, 2012 11:53 AM To: openembedded-c...@lists.openembedded.org; 'yocto@yoctoproject.org' Subject: Difference of toolchain recipes It is a bit confused for the different recipes of toolchian, can somebody help to explain what's the difference for those recipes? E.g. gcc- cross, gcc-cross-canadian, gcc-cross-initial, gcc-cross-intermediate, gcc- crosssdk, gcc-crosssdk-initial, gcc-crosssdk-intermediate, gcc- runtime, etc. gcc-cross-initial - This is the initial compiler needed to bootstrap the toolchain to build software on the host for the target. (This is a 'native' package.) gcc-cross-intermediate - This is the second stage of the bootstrap process to build software on the host for the target. (This is a 'native' package.) gcc-cross - this is the the final stage of the bootstrap process, and results in the cross compiler to build software on the host for the target. (This is a 'native' package.) If you are replacing the cross compiler toolchain with a custom version, this is what you must replace. gcc-runtime - these are the runtime libraries, but from the toolchain bootstrapping process. This results in a 'target' binary. gcc-crosssdk-initial/intermediate - stage 1 and 2 of the a cross compiler to build from the 'host' to the 'sdk'. Often the SDK is not the same target as the host. (This is a 'native' binary.) gcc-crosssdk - this the final stage of the SDK compiler. Again, this is to build on the host, for the sdk. This is a 'native' binary. gcc-cross-canadian - This is the compiler included with the SDK to build on the SDK machine creating software for the target. This is an 'nativesdk' package. Is there any document for those description? Not that I know of.. It's one of those things that you kind of need to know in order to work with it. It likely should be documented somewhere officially. --Mark Best Regards, Zhenhua ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Difference of toolchain recipes
I can likely help with this, Scott. On Wed, Dec 12, 2012 at 2:33 PM, Rifenbark, Scott M scott.m.rifenb...@intel.com wrote: Thanks for the feedback Mark. I will go ahead with it. Scott -Original Message- From: Mark Hatle [mailto:mark.ha...@windriver.com] Sent: Wednesday, December 12, 2012 9:08 AM To: Rifenbark, Scott M Cc: yocto@yoctoproject.org Subject: Re: [yocto] Difference of toolchain recipes On 12/11/12 3:20 PM, Rifenbark, Scott M wrote: I think what I am going to do is document these in general as part of the Terms section in the YP Development Manual where the term Cross- Development Toolchain is defined. Would putting such a high-level list in the YP documentation be unnecessary or helpful? I think it would. The set of compiler/toolchain elements we have is definitely confusing to someone new. --Mark Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Mark Hatle Sent: Thursday, December 06, 2012 10:05 AM To: yocto@yoctoproject.org Subject: Re: [yocto] Difference of toolchain recipes On 12/6/12 4:00 AM, Luo Zhenhua-B19537 wrote: Can anybody shed some light, please? Best Regards, Zhenhua -Original Message- From: Luo Zhenhua-B19537 Sent: Tuesday, December 04, 2012 11:53 AM To: openembedded-c...@lists.openembedded.org; 'yocto@yoctoproject.org' Subject: Difference of toolchain recipes It is a bit confused for the different recipes of toolchian, can somebody help to explain what's the difference for those recipes? E.g. gcc- cross, gcc-cross-canadian, gcc-cross-initial, gcc-cross-intermediate, gcc- crosssdk, gcc-crosssdk-initial, gcc-crosssdk-intermediate, gcc- runtime, etc. gcc-cross-initial - This is the initial compiler needed to bootstrap the toolchain to build software on the host for the target. (This is a 'native' package.) gcc-cross-intermediate - This is the second stage of the bootstrap process to build software on the host for the target. (This is a 'native' package.) gcc-cross - this is the the final stage of the bootstrap process, and results in the cross compiler to build software on the host for the target. (This is a 'native' package.) If you are replacing the cross compiler toolchain with a custom version, this is what you must replace. gcc-runtime - these are the runtime libraries, but from the toolchain bootstrapping process. This results in a 'target' binary. gcc-crosssdk-initial/intermediate - stage 1 and 2 of the a cross compiler to build from the 'host' to the 'sdk'. Often the SDK is not the same target as the host. (This is a 'native' binary.) gcc-crosssdk - this the final stage of the SDK compiler. Again, this is to build on the host, for the sdk. This is a 'native' binary. gcc-cross-canadian - This is the compiler included with the SDK to build on the SDK machine creating software for the target. This is an 'nativesdk' package. Is there any document for those description? Not that I know of.. It's one of those things that you kind of need to know in order to work with it. It likely should be documented somewhere officially. --Mark Best Regards, Zhenhua ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] might it be worth explaining BBMASK more comprehensively?
On Wed, 12 Dec 2012, Rifenbark, Scott M wrote: Please feel free (anyone) to provide some useful examples and a bit of explanation for each and I will be happy to get them in the manual(s). i forgot to mention this snippet i ran across in the meta-angstrom layer's contrib/local.conf: BBFILES := /OE/org.openembedded.dev/recipes/*/*.bb BBMASK = that combination isn't something that appears to be explained anywhere and some readers might wonder what it means to explicitly set BBFILES and clear BBMASK. 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] Strange error with missing meta-yocto in bblayers
When trying to build a machine I had not built in a while, I got the following error: $ bitbake core-image-minimal Pseudo is not present but is required, building this first before the main build NOTE: Your conf/bblayers.conf has been automatically updated. Please re-run bitbake . mkdir: cannot create directory `/../../var/pseudo': Permission denied /home/dvhart/source/poky/scripts/bitbake: line 178: /pseudo: No such file or direct ory It turns out I had meta and meta-yocto-bsp in bblayers, but not meta-yocto. The error wasn't at all helpful, but I figured it had to be something in my configuration. Would there be someway to better articulate to the user what the failure actually was? -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] might it be worth explaining BBMASK more comprehensively?
On Wed, Dec 12, 2012 at 11:42:41AM -0800, Tim Bird wrote: On 12/12/2012 11:27 AM, Robert P. J. Day wrote: a bit more pedantry, but is there a more complete example of the use of BBMASK than the trivial example in the ref and dev manuals? the ref manual provides this example by way of explanation: BBMASK = .*/meta-ti/recipes-misc/ well, ok, except you occasinally find slight variations like: BBMASK = meta-ti/recipes-misc/ or BBMASK = meta-ti/recipes-misc given that there are places where a trailing slash is significant, are all of the above exactly equivalent? if so, that's worth noting. also, what about an example showing masking out a couple directories, or perhaps a single recipe from a layer, and so on? at the moment, the manuals suggest you can mask multiple recipes but nowhere do i see the reader being given an actual example of how to do that. Indeed. These would be good clarifications. The manual says that this is a single python regular expression. Hence, when masking multiple directories or recipes, you use a vertical bar to separate the regex fragments. Here's a particularly complex case I used once: BBMASK = meta-ti/recipes-misc|meta-ti/recipes-ti/packagegroup BBMASK .= |.*meta-oe/recipes-support #BBMASK .= |.*openldap #BBMASK .= |.*opencv #BBMASK .= |.*lzma BBMASK .= |meta-oe/recipes-core/packagegroups BBMASK .= |meta-oe/recipes-devtools BBMASK .= |meta-oe/recipes-extended BBMASK .= |meta-oe/recipes-multimedia BBMASK .= |meta-oe/recipes-navigation BBMASK .= |meta-oe/recipes-connectivity BBMASK .= |meta-oe/recipes-graphics BBMASK .= |meta-oe/recipes-qt I don't know if the .= with leading bar is the optimal way to append on to BBMASK, but it seems fairly straightforward Yes because += would add extra space and break regexp (_append should probably work too). Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] per-image ROOTFS sizes
On 12/11/2012 01:05 PM, Trevor Woerner wrote: Hi, Are per-image ROOTFS sizes (i.e. IMAGE_ROOTFS_SIZE_image) still supported? From this: http://patches.openembedded.org/patch/4671/ it would appear not. However poky-extras/meta-kernel-dev/conf/machine/example.conf contains IMAGE_ROOTFS_SIZE_ext3 (which would make it appear as though they are). Interesting, I haven't tried myself. Have you tried and run into an issue? -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] SRC_URI and appending and a style guide?
it's a pedantry-laden day today so i'm going to continue to whine about aesthetics. what about a yocto style guide for coding style recommendations? for example, consider the variations: poky/meta/recipes-support/libcroco/libcroco_0.6.3.bb:SRC_URI_append = file://croco.patch;apply=yes \ poky/meta/recipes-support/attr/ea-acl.inc:SRC_URI += file://relative-libdir.patch;striplevel=0 \ poky/meta/recipes-support/db/db_5.3.15.bb:SRC_URI += file://arm-thumb-mutex_db5.patch;patchdir=.. poky/meta/recipes-sato/leafpad/leafpad_0.8.18.1.bb:SRC_URI_append_poky = file://owl-menu.patch;apply=yes poky/meta/recipes-sato/puzzles/oh-puzzles_git.bb:SRC_URI_append_poky = file://oh-puzzles-owl-menu.patch;striplevel=0 in the above, you have three different variations for appending to SRC_URI. i don't think it would be clear to a reader if there was any difference between += and _append, other than that _append forces you to add the space yourself while += doesn't. of course, _append_poky is self-explanatory. so is there a *preferred* form for things like that? is it written down somewhere? should it be? just because it works for perl doesn't always mean that there's more than one way to do it is a good idea. :-) 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] per-image ROOTFS sizes
Hi Darren, On Wed, Dec 12, 2012 at 2:59 PM, Darren Hart dvh...@linux.intel.com wrote: On 12/11/2012 01:05 PM, Trevor Woerner wrote: Are per-image ROOTFS sizes (i.e. IMAGE_ROOTFS_SIZE_image) still supported? Interesting, I haven't tried myself. Have you tried and run into an issue? Yes. I had been trying to figure out why my: IMAGE_ROOTFS_SIZE_vmdk = 50 line in my config file wasn't working when I found the link I provided earlier. Right now all I can say is that it doesn't work for _vmdk specifically. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] might it be worth explaining BBMASK more comprehensively?
On 12/12/2012 11:53 AM, Robert P. J. Day wrote: On Wed, 12 Dec 2012, Tim Bird wrote: On 12/12/2012 11:27 AM, Robert P. J. Day wrote: a bit more pedantry, but is there a more complete example of the use of BBMASK than the trivial example in the ref and dev manuals? the ref manual provides this example by way of explanation: BBMASK = .*/meta-ti/recipes-misc/ well, ok, except you occasinally find slight variations like: BBMASK = meta-ti/recipes-misc/ or BBMASK = meta-ti/recipes-misc given that there are places where a trailing slash is significant, are all of the above exactly equivalent? if so, that's worth noting. also, what about an example showing masking out a couple directories, or perhaps a single recipe from a layer, and so on? at the moment, the manuals suggest you can mask multiple recipes but nowhere do i see the reader being given an actual example of how to do that. Indeed. These would be good clarifications. The manual says that this is a single python regular expression. Hence, when masking multiple directories or recipes, you use a vertical bar to separate the regex fragments. Here's a particularly complex case I used once: BBMASK = meta-ti/recipes-misc|meta-ti/recipes-ti/packagegroup BBMASK .= |.*meta-oe/recipes-support #BBMASK .= |.*openldap #BBMASK .= |.*opencv #BBMASK .= |.*lzma BBMASK .= |meta-oe/recipes-core/packagegroups BBMASK .= |meta-oe/recipes-devtools BBMASK .= |meta-oe/recipes-extended BBMASK .= |meta-oe/recipes-multimedia BBMASK .= |meta-oe/recipes-navigation BBMASK .= |meta-oe/recipes-connectivity BBMASK .= |meta-oe/recipes-graphics BBMASK .= |meta-oe/recipes-qt I don't know if the .= with leading bar is the optimal way to append on to BBMASK, but it seems fairly straightforward to me. I sometimes use the leading .* and sometimes not. it doesn't seem like the leading .* makes any difference but that's the sort of detail that might confuse a reader and should be explained. In my setup it seems to not be required, but maybe for flexibility it should be used. I'm not sure -- it would depend on wheter python re.match or re.search is used for the regex. -- Tim from your examples above, is this how you mask individual software recipes? BBMASK .= |.*openldap that's kind of useful to know. That's how I do it. I'm not sure if there's some other preferred method or not. This should catch that name in all layers. -- Tim = Tim Bird Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment = ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] per-image ROOTFS sizes
On 12/12/2012 12:14 PM, Trevor Woerner wrote: Hi Darren, On Wed, Dec 12, 2012 at 2:59 PM, Darren Hart dvh...@linux.intel.com wrote: On 12/11/2012 01:05 PM, Trevor Woerner wrote: Are per-image ROOTFS sizes (i.e. IMAGE_ROOTFS_SIZE_image) still supported? Interesting, I haven't tried myself. Have you tried and run into an issue? Yes. I had been trying to figure out why my: IMAGE_ROOTFS_SIZE_vmdk = 50 line in my config file wasn't working when I found the link I provided earlier. Right now all I can say is that it doesn't work for _vmdk specifically. That was: http://patches.openembedded.org/patch/4671/ What is the reason you would like to do this just for vmdk? Is it to avoid increasing the size of all the images when it is only vmdk you care about? That would makes sense. Perhaps, for now, you could limit the image types you build to just vmdk and increate the size without the override? Saul on CC for comment as that was his RFC Patch. -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] might it be worth explaining BBMASK more comprehensively?
On 12/12/2012 11:53 AM, Robert P. J. Day wrote: On Wed, 12 Dec 2012, Tim Bird wrote: I don't know if the .= with leading bar is the optimal way to append on to BBMASK, but it seems fairly straightforward to me. I sometimes use the leading .* and sometimes not. it doesn't seem like the leading .* makes any difference but that's the sort of detail that might confuse a reader and should be explained. In my setup it seems to not be required, but maybe for flexibility it should be used. I'm not sure -- it would depend on whether python re.match or re.search is used for the regex. Just to answer my own question... In bitbake in poky-danny-8.0, (poky-danny-8.0/bitbake/lib/bb/cooker.py) bbmask_compiled.search() is used, which means that the leading .* is unnecessary. A python re.search() can match anywhere in the string, while a python re.match() must match at the beginning of a string. Maybe previous versions of bitbake used re.match()?? In any event, I would think that it should be considered best practice to NOT include the leading .* in BBMASK regex fragments. -- Tim = Tim Bird Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment = ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Difference of toolchain recipes
Thanks Bill, I will put together my draft for the section and send it your way. You can give it a good technical review. Scott From: Bill Traynor [mailto:w...@alphatroop.com] Sent: Wednesday, December 12, 2012 11:37 AM To: Rifenbark, Scott M Cc: Mark Hatle; yocto@yoctoproject.org Subject: Re: [yocto] Difference of toolchain recipes I can likely help with this, Scott. On Wed, Dec 12, 2012 at 2:33 PM, Rifenbark, Scott M scott.m.rifenb...@intel.commailto:scott.m.rifenb...@intel.com wrote: Thanks for the feedback Mark. I will go ahead with it. Scott -Original Message- From: Mark Hatle [mailto:mark.ha...@windriver.commailto:mark.ha...@windriver.com] Sent: Wednesday, December 12, 2012 9:08 AM To: Rifenbark, Scott M Cc: yocto@yoctoproject.orgmailto:yocto@yoctoproject.org Subject: Re: [yocto] Difference of toolchain recipes On 12/11/12 3:20 PM, Rifenbark, Scott M wrote: I think what I am going to do is document these in general as part of the Terms section in the YP Development Manual where the term Cross- Development Toolchain is defined. Would putting such a high-level list in the YP documentation be unnecessary or helpful? I think it would. The set of compiler/toolchain elements we have is definitely confusing to someone new. --Mark Scott -Original Message- From: yocto-boun...@yoctoproject.orgmailto:yocto-boun...@yoctoproject.org [mailto:yocto-mailto:yocto- boun...@yoctoproject.orgmailto:boun...@yoctoproject.org] On Behalf Of Mark Hatle Sent: Thursday, December 06, 2012 10:05 AM To: yocto@yoctoproject.orgmailto:yocto@yoctoproject.org Subject: Re: [yocto] Difference of toolchain recipes On 12/6/12 4:00 AM, Luo Zhenhua-B19537 wrote: Can anybody shed some light, please? Best Regards, Zhenhua -Original Message- From: Luo Zhenhua-B19537 Sent: Tuesday, December 04, 2012 11:53 AM To: openembedded-c...@lists.openembedded.orgmailto:openembedded-c...@lists.openembedded.org; 'yocto@yoctoproject.orgmailto:yocto@yoctoproject.org' Subject: Difference of toolchain recipes It is a bit confused for the different recipes of toolchian, can somebody help to explain what's the difference for those recipes? E.g. gcc- cross, gcc-cross-canadian, gcc-cross-initial, gcc-cross-intermediate, gcc- crosssdk, gcc-crosssdk-initial, gcc-crosssdk-intermediate, gcc- runtime, etc. gcc-cross-initial - This is the initial compiler needed to bootstrap the toolchain to build software on the host for the target. (This is a 'native' package.) gcc-cross-intermediate - This is the second stage of the bootstrap process to build software on the host for the target. (This is a 'native' package.) gcc-cross - this is the the final stage of the bootstrap process, and results in the cross compiler to build software on the host for the target. (This is a 'native' package.) If you are replacing the cross compiler toolchain with a custom version, this is what you must replace. gcc-runtime - these are the runtime libraries, but from the toolchain bootstrapping process. This results in a 'target' binary. gcc-crosssdk-initial/intermediate - stage 1 and 2 of the a cross compiler to build from the 'host' to the 'sdk'. Often the SDK is not the same target as the host. (This is a 'native' binary.) gcc-crosssdk - this the final stage of the SDK compiler. Again, this is to build on the host, for the sdk. This is a 'native' binary. gcc-cross-canadian - This is the compiler included with the SDK to build on the SDK machine creating software for the target. This is an 'nativesdk' package. Is there any document for those description? Not that I know of.. It's one of those things that you kind of need to know in order to work with it. It likely should be documented somewhere officially. --Mark Best Regards, Zhenhua ___ yocto mailing list yocto@yoctoproject.orgmailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.orgmailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.orgmailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] per-image ROOTFS sizes
On Wed, 12 Dec 2012, Trevor Woerner wrote:
Hi Darren,
On Wed, Dec 12, 2012 at 2:59 PM, Darren Hart dvh...@linux.intel.com wrote:
On 12/11/2012 01:05 PM, Trevor Woerner wrote:
Are per-image ROOTFS sizes (i.e. IMAGE_ROOTFS_SIZE_image) still
supported?
Interesting, I haven't tried myself. Have you tried and run into an issue?
Yes. I had been trying to figure out why my:
IMAGE_ROOTFS_SIZE_vmdk = 50
line in my config file wasn't working when I found the link I provided
earlier. Right now all I can say is that it doesn't work for _vmdk
specifically.
since i was going to play with vmdk soon, i took a look at this and
from a position of extreme ignorance, i can see image-vmdk.bbclass
(which i'm going to assume is the class being used) which contains:
#inherit image-live
inherit boot-directdisk
create_vmdk_image () {
qemu-img convert -O vmdk ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hdddirect
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.vmdk
ln -s ${IMAGE_NAME}.vmdk ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.vmdk
}
so my *guess* is that any sort of rootfs size calculation has to come
from boot-directdisk.bbclass, but if you look there, there's no
apparent reference to IMAGE_ROOTFS_SIZE. what you see are numerous
references to BLOCKS and ROOTFSBLOCKS and BOOTDD_EXTRA_SPACE and so
on, with:
ROOTFSBLOCKS=`du -Lbks ${ROOTFS} | cut -f 1`
TOTALSIZE=`expr $BLOCKS + $ROOTFSBLOCKS`
END1=`expr $BLOCKS \* 1024`
END2=`expr $END1 + 512`
END3=`expr \( $ROOTFSBLOCKS \* 1024 \) + $END1`
echo $ROOTFSBLOCKS $TOTALSIZE $END1 $END2 $END3
rm -rf $IMAGE
dd if=/dev/zero of=$IMAGE bs=1024 seek=$TOTALSIZE count=1
parted $IMAGE mklabel msdos
parted $IMAGE mkpart primary fat16 0 ${END1}B
parted $IMAGE unit B mkpart primary ext2 ${END2}B ${END3}B
so what happens if you try to set the appropriate variables above?
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] per-image ROOTFS sizes
On Wed, Dec 12, 2012 at 3:19 PM, Darren Hart dvh...@linux.intel.com wrote:
What is the reason you would like to do this just for vmdk? Is it to
avoid increasing the size of all the images when it is only vmdk you
care about? That would makes sense.
Yes, that's it exactly. I have an existing build system in place
(which is all based on custom scripts) that I would like to upgrade to
Yocto. Our target device uses a 2GB CF card. My build system generates
an image which I use in conjunction with a script to create CF cards
based on any given build. There's no reason the image needs to be
2GB in size; the script formats and mounts the CF card, mounts the
image, then copies the files from the image to the CF card. The
script also takes care of running LILO against the CF so it can boot.
The build system also generates a VDI (which is very much like a VMDK)
of the device which can be used for testing or development of
non-hardware-related features (e.g. web interface, snmp, etc). What I
like about the VDI is that it will start at, roughly, 200MB (which
makes it easier to copy around, download, etc) but when run will act
like the real 2GB system.
Perhaps, for now, you could limit
the image types you build to just vmdk and increate the size without the
override?
Yes, that'll do for now. But I'd like to keep investigating so that
the ext3 image can be only as big as it needs to be while the
V{DI,MDK} can be dynamically sized to whatever is specified in
IMAGE_ROOTFS_SIZE_vmdk.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] per-image ROOTFS sizes
On Wed, Dec 12, 2012 at 3:46 PM, Robert P. J. Day rpj...@crashcourse.ca wrote:
so what happens if you try to set the appropriate variables above?
When Yocto creates a VMDK, it creates 2 partitions:
- an MSDOS partition for the syslinux stuff
- the ext{3,4} partition of your root image
When it then shmushes these two together into 1 file, it has to make
sure all the sizes are set correctly as per the information in the
disk's partition table. That's what all these calculations are doing
(I recognize it from similar work in my own scripts).
Personally I have my own approach that can use either LILO or syslinux
for booting x86 (it can also create bootable ARM images with the
appropriate uboot/mlo); neither of the x86 solutions require a
separate MSDOS partition. Hopefully I'll find some time to examine how
Yocto is doing things and perhaps integrate my own findings into the
broader project(?).
(please see https://github.com/twoerner/qemu-image-builder)
I believe Yocto calculates the sizes (using IMAGE_ROOTFS_SIZE) from
code in poky/meta/classes/image_types.bbclass, which is also run for
the VMDK's calculations too.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] per-image ROOTFS sizes
On Wed, 12 Dec 2012, Trevor Woerner wrote:
On Wed, Dec 12, 2012 at 3:46 PM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
so what happens if you try to set the appropriate variables above?
When Yocto creates a VMDK, it creates 2 partitions:
- an MSDOS partition for the syslinux stuff
- the ext{3,4} partition of your root image
When it then shmushes these two together into 1 file, it has to make
sure all the sizes are set correctly as per the information in the
disk's partition table. That's what all these calculations are doing
(I recognize it from similar work in my own scripts).
Personally I have my own approach that can use either LILO or syslinux
for booting x86 (it can also create bootable ARM images with the
appropriate uboot/mlo); neither of the x86 solutions require a
separate MSDOS partition. Hopefully I'll find some time to examine how
Yocto is doing things and perhaps integrate my own findings into the
broader project(?).
(please see https://github.com/twoerner/qemu-image-builder)
I believe Yocto calculates the sizes (using IMAGE_ROOTFS_SIZE) from
code in poky/meta/classes/image_types.bbclass, which is also run for
the VMDK's calculations too.
now i'm interested, so ... what are your config steps? i wouldn't
mind trying to reproduce this on my system.
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] per-image ROOTFS sizes
Hi Robert,
(we met at OLS last summer, I came and chatted with you briefly after
your presentation)
On Wed, Dec 12, 2012 at 5:03 PM, Robert P. J. Day rpj...@crashcourse.ca wrote:
now i'm interested, so ... what are your config steps? i wouldn't
mind trying to reproduce this on my system.
My doodle layer can be found here:
https://github.com/twoerner/meta-trevor
My conf/bblayers.conf adds this and meta-openembedded/meta-oe.
My conf/local.conf currently looks like:
BB_NUMBER_THREADS = 4
PARALLEL_MAKE = -j 4
MACHINE = qemux86
DL_DIR = /home/trevor/devel/Downloads
DISTRO = poky
PACKAGE_CLASSES = package_ipk
EXTRA_IMAGE_FEATURES = debug-tweaks ssh-server-openssh
USER_CLASSES = buildstats image-mklibs image-prelink
PATCHRESOLVE = noop
#
# Disk Space Monitoring during the build
#
# Monitor the disk space during the build. If there is less that
1GB of space or less
# than 100K inodes in any key build location (TMPDIR, DL_DIR,
SSTATE_DIR), gracefully
# shutdown the build. If there is less that 100MB or 1K inodes,
perform a hard abort
# of the build. The reason for this is that running completely out
of space can corrupt
# files and damages the build in ways which may not be easily recoverable.
BB_DISKMON_DIRS = \
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K
CONF_VERSION = 1
BB_DANGLINGAPPENDS_WARNONLY = yes
IMAGE_FSTYPES = vmdk
IMAGE_ROOTFS_SIZE = 50
You can then either bitbake bboverride or bitbake core-image-minimal.
To easily boot the resulting VMDK with qemu, you'll have to patch your
poky/scripts/runqemu and poky/scripts/runqemu-internal with my patch
here (unless by the time you read this, it has already been included):
https://lists.yoctoproject.org/pipermail/yocto/2012-December/013279.html
and then run:
$ runqemu tmp/deploy/images/image.vmdk
Currently I can't think of any nice/easy way to _flexibly_ specify the
eth0 IP address of the vmdk image, but the runqemu script does setup
your local tap interface for 192.168.7.1/24 as expected. You can then
manually configure eth0 once the VM boots and/or setup
'/etc/network/interfaces'.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] per-image ROOTFS sizes
On Wed, 12 Dec 2012, Trevor Woerner wrote:
Hi Robert,
(we met at OLS last summer, I came and chatted with you briefly after
your presentation)
On Wed, Dec 12, 2012 at 5:03 PM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
now i'm interested, so ... what are your config steps? i wouldn't
mind trying to reproduce this on my system.
My doodle layer can be found here:
https://github.com/twoerner/meta-trevor
My conf/bblayers.conf adds this and meta-openembedded/meta-oe.
My conf/local.conf currently looks like:
BB_NUMBER_THREADS = 4
PARALLEL_MAKE = -j 4
MACHINE = qemux86
DL_DIR = /home/trevor/devel/Downloads
DISTRO = poky
PACKAGE_CLASSES = package_ipk
EXTRA_IMAGE_FEATURES = debug-tweaks ssh-server-openssh
USER_CLASSES = buildstats image-mklibs image-prelink
PATCHRESOLVE = noop
#
# Disk Space Monitoring during the build
#
# Monitor the disk space during the build. If there is less that
1GB of space or less
# than 100K inodes in any key build location (TMPDIR, DL_DIR,
SSTATE_DIR), gracefully
# shutdown the build. If there is less that 100MB or 1K inodes,
perform a hard abort
# of the build. The reason for this is that running completely out
of space can corrupt
# files and damages the build in ways which may not be easily recoverable.
BB_DISKMON_DIRS = \
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K
CONF_VERSION = 1
BB_DANGLINGAPPENDS_WARNONLY = yes
IMAGE_FSTYPES = vmdk
IMAGE_ROOTFS_SIZE = 50
You can then either bitbake bboverride or bitbake core-image-minimal.
To easily boot the resulting VMDK with qemu, you'll have to patch your
poky/scripts/runqemu and poky/scripts/runqemu-internal with my patch
here (unless by the time you read this, it has already been included):
https://lists.yoctoproject.org/pipermail/yocto/2012-December/013279.html
and then run:
$ runqemu tmp/deploy/images/image.vmdk
Currently I can't think of any nice/easy way to _flexibly_ specify the
eth0 IP address of the vmdk image, but the runqemu script does setup
your local tap interface for 192.168.7.1/24 as expected. You can then
manually configure eth0 once the VM boots and/or setup
'/etc/network/interfaces'.
i'll check all this out, either this eve or tomorrow. probably
tomorrow since i'm well into a bottle of 10-YO single malt ardbeg at
the moment. you're jealous. i know you are.
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] per-image ROOTFS sizes
On 12/12/2012 03:16 PM, Robert P. J. Day wrote:
On Wed, 12 Dec 2012, Trevor Woerner wrote:
On Wed, Dec 12, 2012 at 3:46 PM, Robert P. J. Day rpj...@crashcourse.ca wrote:
so what happens if you try to set the appropriate variables above?
When Yocto creates a VMDK, it creates 2 partitions:
- an MSDOS partition for the syslinux stuff
- the ext{3,4} partition of your root image
When it then shmushes these two together into 1 file, it has to make
sure all the sizes are set correctly as per the information in the
disk's partition table. That's what all these calculations are doing
(I recognize it from similar work in my own scripts).
Personally I have my own approach that can use either LILO or syslinux
for booting x86 (it can also create bootable ARM images with the
appropriate uboot/mlo); neither of the x86 solutions require a
separate MSDOS partition. Hopefully I'll find some time to examine how
Yocto is doing things and perhaps integrate my own findings into the
broader project(?).
(please see https://github.com/twoerner/qemu-image-builder)
I believe Yocto calculates the sizes (using IMAGE_ROOTFS_SIZE) from
code in poky/meta/classes/image_types.bbclass, which is also run for
the VMDK's calculations too.
and here's where i'm confused. i'm *assuming* that the
image-vmdk.bbclass file defines the creation of vmdk images, yes? but
that class file inherits directly only boot-directdisk.bbclass, and if
i look in that class file, i don't see any further inherits that might
process IMAGE_ROOTFS_SIZE. i just see hardcoded calculations that
build an image based on actual rootfs directory size.
so what am i missing?
Some serious magic! It took me a while to reload my cache on this one.
All strapped in because here we go!
So you have selected the types of images you want to build by add it's
type to IMAGE_FSTYPES, of which you can have multiple types.
When the do_rootfs() is run for an image, there is a call into
image_types.bbclass via the ${@get_imagecmds(d)}, which returns a list
of cmds to execute to create the various images selected via the above
IMAGE_FSTYPES. Of note here is that if vmdk or live is select, but not
ext3 (soon to be ext4 we hope), then ext3 will be added to the types
list, and vmdk and/or live will be removed.
in the get_imagecmds code, you can see that the OVERRIDES are updated
locally to include the filesystem type, so that correct IMAGE_CMD can be
selected via overrides and set into $cmd while the compressed version is
set to $ccmd, then the runimagecmd is added to the cmds list (different
than cmd, yes a little confusing).
runimagecmd is here the size computation occurs and the IMAGE_CMD is run
via $cmd. Since we are not out side the get_imagecmds() context and do
not have the localdata that set filesystem type overrides we won't seem
them and beside runimagecmd will never get called for a vmdk or live
image type! The underlying filesystem for those is the ext3 fs type.
Now that the rootfs has been created in the correct fs type (ext3) it
mething to the TOTALSIZE and END3 computations in this code
fragment:needs to be converted to vmdk, this is done via the
image-vmdk.bbclass which is optionally inherited in image.bbclass. This
class slips the do_vmdkimg() function after do_bootdirectdisk, which is
needed to get the right disk leve partitioning. The image-vmdk.bbclass
inherits boot-directdisk.bbclass to get it incorporated correctly. This
is where Trevor correctly noted that that we are doing the multiple
partition approach.
SO we cycle back to the initial question which is how to have 2
different sizes for ext3 vanilla images vs a fixed size for the vmdk,
right now that's really hard! Since we create an ext3 (4) for including
mething to the TOTALSIZE and END3 computations in this code
fragment:into the vmdk, that's where the sizing occurs.
What I think you are asking for is create a default sized ext3 and then
allow the partition to be resized in the boot-directdisk partitioning
code, since that's where the extra space would get accounted for.
Possibly we could add something to the TOTALSIZE and END3 computations
in this code fragment:
ROOTFSBLOCKS=`du -Lbks ${ROOTFS} | cut -f 1`
TOTALSIZE=`expr $BLOCKS + $ROOTFSBLOCKS`
END1=`expr $BLOCKS \* 1024`
END2=`expr $END1 + 512`
END3=`expr \( $ROOTFSBLOCKS \* 1024 \) + $END1`
That code feeds into the parted command, the dd that happens after that
would have to change since we are dd'ing a ext3 and it does not know it
has more space, this is the tricky part! More thought is required,
maybe a single malt (yes I was jealous).
Anyway, I hope have I not thoroughly confused everyone at this point.
Sau!
rday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
