[yocto] Creating a volatile image
When an .hddimg image is used on a hard disk or flash drive, the target root directory is implemented as a loop device referring to the rootfs.img file contained in that drive. This means it is a true non-volatile file system. Is there a way to make the entire file system volatile? I'm trying to ensure that my flash drive is written to as rarely as possible. To this end, I'm putting my app's volatile data on a separate partition, and I'd like to run the OS out of a big ramdisk, loading it on startup and then discarding it on shutdown. In other words, I want a Groundhog Day system, which always boots up as though it is a brand new clean install. I've spent a couple hours trying to decipher various .bbclass files, Googling about the various file systems, and so on, and I haven't seen anything that looks like this capability is already provided somehow in the Yocto system. Is there an easy way to do this? Or is there only a hard way to do it, involving way more expertise in the build system than I've got? Alternatively, is it practical to make the existing file system readonly? My system is based on core-image-base, with no graphics. What will break if it can't write to anything outside of /tmp or /run or /media/ram or /var/volatile? And is there a built-in way to do that? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Creating a volatile image
On 07/03/2013 03:48 PM, Paul D. DeRocco wrote: When an .hddimg image is used on a hard disk or flash drive, the target root directory is implemented as a loop device referring to the rootfs.img file contained in that drive. This means it is a true non-volatile file system. Is there a way to make the entire file system volatile? Three ways to achieve this goal. 1. If you're using yocto 3.8 kernel, you can enable aufs by add the following line to local.conf. KERNEL_FEATURES_append = features/aufs/aufs-enable.scc This will enable the aufs support and your live image (iso or hddimg) will appear to be writable. This aufs support in live image is added recently. commit: 29e55997caeb9c6367f9a340e153f829228f36ed subject: init-live.sh: try to make a union mount when possible 2. If you're using other kernel versions, an option is to use device-mapping. But you might need to write your own recipe to include the dmsetup command into the image. In addition, you need to modify the init-live.sh script a little. dmsetup is not used in OE/Yocto for now. ArchLinux uses this method to make its liveCD version work. 3. As a temporary workaround, you can bind mount the directory you need to write to with a tmpfs. e.g. mkdir -p /var/volatile/lib mount --bind /var/lib /var/volatile/lib Best Regards, Chen Qi I'm trying to ensure that my flash drive is written to as rarely as possible. To this end, I'm putting my app's volatile data on a separate partition, and I'd like to run the OS out of a big ramdisk, loading it on startup and then discarding it on shutdown. In other words, I want a Groundhog Day system, which always boots up as though it is a brand new clean install. I've spent a couple hours trying to decipher various .bbclass files, Googling about the various file systems, and so on, and I haven't seen anything that looks like this capability is already provided somehow in the Yocto system. Is there an easy way to do this? Or is there only a hard way to do it, involving way more expertise in the build system than I've got? Alternatively, is it practical to make the existing file system readonly? My system is based on core-image-base, with no graphics. What will break if it can't write to anything outside of /tmp or /run or /media/ram or /var/volatile? And is there a built-in way to do that? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Creating a volatile image
On 3 July 2013 08:48, Paul D. DeRocco pdero...@ix.netcom.com wrote: Alternatively, is it practical to make the existing file system readonly? My system is based on core-image-base, with no graphics. What will break if it can't write to anything outside of /tmp or /run or /media/ram or /var/volatile? And is there a built-in way to do that? You can set the read-only-rootfs image feature (never tried it myself, so YMMV), but if you turn off atime writes to / you won't be making that many writes to / anyway. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Creating a volatile image
From: Burton, Ross You can set the read-only-rootfs image feature (never tried it myself, so YMMV), That would certainly be the simplest thing to try. but if you turn off atime writes to / you won't be making that many writes to / anyway. How does one turn off atime? By modifying /etc/fstab? How is that done? By supplying a different source file to get copied into the image, or by overwriting the built-in one in my own recipe? I need to do that anyway, since I have a second partition to mount. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] systemd configuration
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
That's entirely up to what you put into your image. busybox
should provide a very basic version of vi out of the box.
Ah, vi. I guess it's time to learn vi.
Sure, you can find in the rootfs subdirectory of the
image's WORKDIR (which you can find out using:
bitbake -e imagename | grep ^WORKDIR=
One way to look at this is to launch a devshell for the image:
bitbake -c devshell imagename
In 1.4+ using a devshell has the advantage of showing you the correct
permission/ownership of files within the root filesystem.
For my purpose, the first choice turned out to be sufficient.
Or perhaps someone can just tell me what target gets
activated on bootup,
where its .wants directory is, and what directory I should
put my daemon's unit file into.
I'm sure someone more knowledgeable about systemd will pipe
up with further
information, but I would suggest looking at other recipes for
examples. AFAICT
systemd units for daemons should be installed into
${systemd_unitdir}/system.
Turns out I was confused by the fact that there is no multi-user.target
file, since it's just an empty unit. But there is a multi-user.target.wants
directory, so I'm all set.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project 1.5_M2.rc1 build underway, again
Hi Michael, There are some errors like below: mkdir: cannot create directory `/toolchain': Permission denied cp: cannot create regular file `/toolchain/i686': No such file or directory mkdir: cannot create directory `/toolchain': Permission denied cp: cannot create regular file `/toolchain/x86_64': No such file or directory program finished with exit code 1 Please see: http://autobuilder.yoctoproject.org:8011/builders/nightly-arm/builds/191/steps/Publishing%20Artifacts/logs/stdio http://autobuilder.yoctoproject.org:8011/builders/nightly-mips/builds/193/steps/Publishing%20Artifacts/logs/stdio Thanks, Yi ? 2013?07?03? 11:55, Michael Halstead ??: After correcting some configuration errors the Yocto Project 1.5_M2.rc1 build is underway again. As tasks complete artifacts will start appearing at their new location: http://autobuilder.yoctoproject.org/pub/nightly/20130703-2 pokyeaa5df34af42b6a37f6506847d0f3ef6ba0d298a https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=eaa5df34af42b6a37f6506847d0f3ef6ba0d298a meta-fsl-armdaf582c93a7283fb0af3b25fe2ada48f4c9985c4 https://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=daf582c93a7283fb0af3b25fe2ada48f4c9985c4 meta-fsl-ppcb889029dca03fcb7e55c671aa5006fe8be1eefb0 https://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/commit/?id=b889029dca03fcb7e55c671aa5006fe8be1eefb0 meta-intel e0d6134ed2e2687ff9f2ee77701666447842bf33 https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/?id=e0d6134ed2e2687ff9f2ee77701666447842bf33 meta-minnow 286a72ba3f5e29432be1dd77127de5bdc2d988c3 https://git.yoctoproject.org/cgit/cgit.cgi/meta-minnow/commit/?id=286a72ba3f5e29432be1dd77127de5bdc2d988c3 meta-qt3 b73552fb998fd30a01dbee5a172e432a16078222 https://git.yoctoproject.org/cgit/cgit.cgi/meta-qt3/commit/?id=b73552fb998fd30a01dbee5a172e432a16078222 eclipse-poky e35dfd79e3970f88a8273125890a54f75f108b97 https://git.yoctoproject.org/cgit/cgit.cgi/eclipse-poky/commit/?id=e35dfd79e3970f88a8273125890a54f75f108b97 Please begin QA as soon as possible. Thank you. -- Michael Halstead Yocto Project / Sys Admin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-ivi] [PATCH] connman: delete init scripts if 'sysvinit' feature is enabled
connman bbappend: delete init scripts if 'sysvinit' feature is enabled
Connman init scripts are installed only if 'sysvinit' feature is enabled
in DISTRO_FEATURES: see commit 7c8160ccbe17d6e10bd7a09b91843182a89b9055 in
poky.
Signed-off-by: Sergey Matyukevich sergey_matyukev...@mentor.com
---
recipes-connectivity/connman/connman_1.15.bbappend |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/recipes-connectivity/connman/connman_1.15.bbappend
b/recipes-connectivity/connman/connman_1.15.bbappend
index cda612b..236f244 100644
--- a/recipes-connectivity/connman/connman_1.15.bbappend
+++ b/recipes-connectivity/connman/connman_1.15.bbappend
@@ -4,6 +4,8 @@ INITSCRIPT_NAME =
INITSCRIPT_PARAMS =
do_install_append() {
- # Remove init scripts
- rm -r ${D}${sysconfdir}/init.d
+if ${@base_contains('DISTRO_FEATURES','sysvinit','true','false',d)}; then
+# Remove init scripts
+rm -r ${D}${sysconfdir}/init.d
+fi
}
--
1.7.2.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ivi] [PATCH] connman: delete init scripts if 'sysvinit' feature is enabled
On 3 July 2013 12:28, Sergey Matyukevich sergey_matyukev...@mentor.com wrote: connman bbappend: delete init scripts if 'sysvinit' feature is enabled Connman init scripts are installed only if 'sysvinit' feature is enabled in DISTRO_FEATURES: see commit 7c8160ccbe17d6e10bd7a09b91843182a89b9055 in poky. Signed-off-by: Sergey Matyukevich sergey_matyukev...@mentor.com I'm curious as to why you're deleting the connman init scripts in meta-ivi... Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-ivi] [PATCHv2] connman: do not delete init scripts in bbappend
Connman init scripts are installed only if 'sysvinit' feature is enabled
in DISTRO_FEATURES: see commit 7c8160ccbe17d6e10bd7a09b91843182a89b9055 in
poky.
Signed-off-by: Sergey Matyukevichsergey_matyukev...@mentor.com
I'm curious as to why you're deleting the connman init scripts in meta-ivi...
Ross
Hmm... Thanks for comment. It is good idea to take a break and to see
the forest for the trees. Here is the second patch revision.
Connman init scripts are now installed only when 'sysvinit' feature is
enabled in DISTRO_FEATURES: commit
7c8160ccbe17d6e10bd7a09b91843182a89b9055 in
poky. No need to remove them in bbappend: they are not installed for
'systemd'-enabled
systems and they are needed for 'sysvinit'-enabled systems.
Signed-off-by: Sergey Matyukevich sergey_matyukev...@mentor.com
---
recipes-connectivity/connman/connman_1.15.bbappend |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/recipes-connectivity/connman/connman_1.15.bbappend
b/recipes-connectivity/connman/connman_1.15.bbappend
index cda612b..83e4b51 100644
--- a/recipes-connectivity/connman/connman_1.15.bbappend
+++ b/recipes-connectivity/connman/connman_1.15.bbappend
@@ -2,8 +2,3 @@ PRINC := ${@int(PRINC) + 2}
INITSCRIPT_NAME =
INITSCRIPT_PARAMS =
-
-do_install_append() {
- # Remove init scripts
- rm -r ${D}${sysconfdir}/init.d
-}
--
1.7.2.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ivi] [PATCHv2] connman: do not delete init scripts in bbappend
On 3 July 2013 12:59, Sergey Matyukevich sergey_matyukev...@mentor.com wrote:
Hmm... Thanks for comment. It is good idea to take a break and to see the
forest for the trees. Here is the second patch revision.
Connman init scripts are now installed only when 'sysvinit' feature is
enabled in DISTRO_FEATURES: commit 7c8160ccbe17d6e10bd7a09b91843182a89b9055
in
poky. No need to remove them in bbappend: they are not installed for
'systemd'-enabled
systems and they are needed for 'sysvinit'-enabled systems.
Signed-off-by: Sergey Matyukevich sergey_matyukev...@mentor.com
---
recipes-connectivity/connman/connman_1.15.bbappend |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/recipes-connectivity/connman/connman_1.15.bbappend
b/recipes-connectivity/connman/connman_1.15.bbappend
index cda612b..83e4b51 100644
--- a/recipes-connectivity/connman/connman_1.15.bbappend
+++ b/recipes-connectivity/connman/connman_1.15.bbappend
@@ -2,8 +2,3 @@ PRINC := ${@int(PRINC) + 2}
INITSCRIPT_NAME =
INITSCRIPT_PARAMS =
-
-do_install_append() {
- # Remove init scripts
- rm -r ${D}${sysconfdir}/init.d
-}
--
1.7.2.5
In that case, you can delete INITSCRIPT_NAME and INITSCRIPT_PARAMS too
surely. Then all you're left is the PRINC, so you can delete that if
you don't care/are using the PR service, or delete that bbappend when
connman 1.16 is integrated.
Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ivi] [PATCHv2] connman: do not delete init scripts in bbappend
On Wed, Jul 03, 2013 at 01:09:47PM +0100, Burton, Ross wrote:
In that case, you can delete INITSCRIPT_NAME and INITSCRIPT_PARAMS too
surely. Then all you're left is the PRINC, so you can delete that if
you don't care/are using the PR service, or delete that bbappend when
connman 1.16 is integrated.
Using PR service isn't enough to keep binary feed sane after removing
PRINC.
PR service bumps least significant number in PKGR value. PRINC bumps
most significant (even from INC_PR when used).
INC_PR = r1
PR = ${INC_PR}.1
PRINC := ${@int(PRINC) + 1}
EXTENDPRAUTO = .1
PKGR = r2.1.1
After removing PRINC, EXTENDPRAUTO is bumped, but still PKGR is lower:
PKGR = r1.1.2
--
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] [meta-ivi] [PATCHv2] connman: do not delete init scripts in bbappend
Hi,
On 3 July 2013 12:59, Sergey Matyukevich
sergey_matyukev...@mentor.com wrote:
Hmm... Thanks for comment. It is good idea to take a break and to see the
forest for the trees. Here is the second patch revision.
Connman init scripts are now installed only when 'sysvinit' feature is
enabled in DISTRO_FEATURES: commit
7c8160ccbe17d6e10bd7a09b91843182a89b9055
in
poky. No need to remove them in bbappend: they are not installed for
'systemd'-enabled
systems and they are needed for 'sysvinit'-enabled systems.
Signed-off-by: Sergey Matyukevich sergey_matyukev...@mentor.com
---
recipes-connectivity/connman/connman_1.15.bbappend |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/recipes-connectivity/connman/connman_1.15.bbappend
b/recipes-connectivity/connman/connman_1.15.bbappend
index cda612b..83e4b51 100644
--- a/recipes-connectivity/connman/connman_1.15.bbappend
+++ b/recipes-connectivity/connman/connman_1.15.bbappend
@@ -2,8 +2,3 @@ PRINC := ${@int(PRINC) + 2}
INITSCRIPT_NAME =
INITSCRIPT_PARAMS =
-
-do_install_append() {
- # Remove init scripts
- rm -r ${D}${sysconfdir}/init.d
-}
--
1.7.2.5
In that case, you can delete INITSCRIPT_NAME and INITSCRIPT_PARAMS too
surely. Then all you're left is the PRINC, so you can delete that if
you don't care/are using the PR service, or delete that bbappend when
connman 1.16 is integrated.
I agree that we could now start with the clean-up of the meta-ivi layer, given
the fact that systemd is now supported by oe-core. Which makes this .bbappend
obsolete. And so agree with Ross to delete that bbappend when connman 1.16 is
integrated. I created a card [1] and added it to the Next Up stack in
Trello, so that we don't forget.
Regards,
Holger
[1] https://trello.com/c/bmWpT6lU
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ivi] [PATCHv2] connman: do not delete init scripts in bbappend
Hi,
On 07/03/2013 04:38 PM, Behrens, Holger wrote:
Hi,
On 3 July 2013 12:59, Sergey Matyukevich
sergey_matyukev...@mentor.com wrote:
Hmm... Thanks for comment. It is good idea to take a break and to see the
forest for the trees. Here is the second patch revision.
Connman init scripts are now installed only when 'sysvinit' feature is
enabled in DISTRO_FEATURES: commit
7c8160ccbe17d6e10bd7a09b91843182a89b9055
in
poky. No need to remove them in bbappend: they are not installed for
'systemd'-enabled
systems and they are needed for 'sysvinit'-enabled systems.
Signed-off-by: Sergey Matyukevichsergey_matyukev...@mentor.com
---
recipes-connectivity/connman/connman_1.15.bbappend |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/recipes-connectivity/connman/connman_1.15.bbappend
b/recipes-connectivity/connman/connman_1.15.bbappend
index cda612b..83e4b51 100644
--- a/recipes-connectivity/connman/connman_1.15.bbappend
+++ b/recipes-connectivity/connman/connman_1.15.bbappend
@@ -2,8 +2,3 @@ PRINC := ${@int(PRINC) + 2}
INITSCRIPT_NAME =
INITSCRIPT_PARAMS =
-
-do_install_append() {
- # Remove init scripts
- rm -r ${D}${sysconfdir}/init.d
-}
--
1.7.2.5
In that case, you can delete INITSCRIPT_NAME and INITSCRIPT_PARAMS too
surely. Then all you're left is the PRINC, so you can delete that if
you don't care/are using the PR service, or delete that bbappend when
connman 1.16 is integrated.
I agree that we could now start with the clean-up of the meta-ivi layer, given the fact that
systemd is now supported by oe-core. Which makes this .bbappend obsolete. And so agree with Ross
to delete that bbappend when connman 1.16 is integrated. I created a card [1] and
added it to the Next Up stack in Trello, so that we don't forget.
Regards,
Holger
[1] https://trello.com/c/bmWpT6lU
Does it make sense to fix the current connman bbappend which is going to
be in use for a while ? In its current state it affects distros which
enable 'systemd' feature and disable 'sysvinit'. One of the following
two options can be chosen. The first one was finalized in this thread:
diff --git a/recipes-connectivity/connman/connman_1.15.bbappend
b/recipes-connectivity/connman/connman_1.15.bbappend
index cda612b..f1deaf2 100644
--- a/recipes-connectivity/connman/connman_1.15.bbappend
+++ b/recipes-connectivity/connman/connman_1.15.bbappend
@@ -1,9 +1 @@
PRINC := ${@int(PRINC) + 2}
-
-INITSCRIPT_NAME =
-INITSCRIPT_PARAMS =
-
-do_install_append() {
- # Remove init scripts
- rm -r ${D}${sysconfdir}/init.d
-}
There is also another [minimalistic and failsafe] option:
diff --git a/recipes-connectivity/connman/connman_1.15.bbappend
b/recipes-connectivity/connman/connman_1.15.bbappend
index cda612b..2e5f355 100644
--- a/recipes-connectivity/connman/connman_1.15.bbappend
+++ b/recipes-connectivity/connman/connman_1.15.bbappend
@@ -5,5 +5,5 @@ INITSCRIPT_PARAMS =
do_install_append() {
# Remove init scripts
- rm -r ${D}${sysconfdir}/init.d
+ rm -rf ${D}${sysconfdir}/init.d
}
Thanks,
Sergey
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fedora 18 CentOS 6.4 yocto difference zc702
Hello, I recently built core-image-minimal for zc702. This generated a file with a dtb extension that I have not seen before uImage--3.8-xilinx+git0+6a0bedad60-r1-zynq-zc702-20130703173428.dtb. Can anyone tell me more about the this extension. Where do you find the boot.scr or uEnv.txt for the zc702? I built this on both a CentOS 6.4 and a Fedora18 x86_64 system. meta-yocto= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e meta-xilinx meta-kc705 meta-zc702 meta-zedboard = (nobranch):b065f091f10060f2bb68b58f1d618e26a966fee2 meta-yocto-bsp= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e The latest version of poky that I downloaded commit 8a186a6b3853fc1a7dcf342d421c8926c38949c9 Author: Cristiana Voicu cristiana.vo...@intel.com Date: Mon Jul 1 08:09:52 2013 + bitbake: hob: save button from settings called a nonexisting method The method was removed when the process for saving configuration in Hob was changed. Replace the call with the right function. [YOCTO #4793] (Bitbake rev: b6aa2b63d71cbe82850a375381b2dbc750cf1905) Signed-off-by: Cristiana Voicu cristiana.vo...@intel.com Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org causes the following error on both CentOS 6.4 and Fedora 18 . oe-init-build-env BitBake requires Python 2.7.3 or later CentOS 6.4 has a non standard location of python. Does anyone know how to tell bitbake of the non standard location of python. This latest version of poky that I downloaded on fedora18 causes the following error. MACHINE=zc702 bitbake core-image-minimal -vDD ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version. ERROR: Execution of event handler 'check_sanity_eventhandler' failed This version of poky and meta-xilinx worked okay. meta meta-yocto= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e meta-xilinx meta-kc705 meta-zc702 meta-zedboard = (nobranch):b065f091f10060f2bb68b58f1d618e26a966fee2 meta-yocto-bsp= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e MACHINE=zc702 bitbake core-image-minimal -vDD NOTE: Tasks Summary: Attempted 1530 tasks of which 306 didn't need to be rerun and all succeeded. We are trying to determine which board to purchase the Xilinx Zynq-7000 SoC ZC702 Evaluation Kit EK-Z7-ZC702-G $895.00 or AES-Z7EV-7Z020-G ZEDBOARD ZYNQ BOARD AES-Z7EV-7Z020-G ECCN Avnet Design Services - Custom $395.00 Does anyone have any experience with either of these boards? Any and all will be appreciated. Thanks vidal.devel...@gmail.com or devel...@sbcglobal.net ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fedora 18 CentOS 6.4 yocto difference zc702
Hi Edward, On Jul 3, 2013, at 11:05 PM, Edward Vidal vidal.devel...@gmail.com wrote: Hello, I recently built core-image-minimal for zc702. This generated a file with a dtb extension that I have not seen before uImage--3.8-xilinx+git0+6a0bedad60-r1-zynq-zc702-20130703173428.dtb. Can anyone tell me more about the this extension. The *.dts and *.dtb files are related to the device tree source and binary formats. When you work with a hardware project using the Xilinx ISE 14.6/Vivado 2013.2 tools, a dts file will be create. This contains the base address and other parameters for each device peripheral, e.g. serial ports, video controller, etc. The yocto build system takes these files and generates the required *.dtb file. Please refer the Zynq Base TRD 14.6 document, (you can quickly scan through the document and fast forward to section 8.2, for building a dtb file from a dts file) http://www.wiki.xilinx.com/Zynq+Base+TRD+14.6-beta Where do you find the boot.scr or uEnv.txt for the zc702? I built this on both a CentOS 6.4 and a Fedora18 x86_64 system. meta-yocto= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e meta-xilinx meta-kc705 meta-zc702 meta-zedboard = (nobranch):b065f091f10060f2bb68b58f1d618e26a966fee2 meta-yocto-bsp= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e The latest version of poky that I downloaded commit 8a186a6b3853fc1a7dcf342d421c8926c38949c9 Author: Cristiana Voicu cristiana.vo...@intel.com Date: Mon Jul 1 08:09:52 2013 + bitbake: hob: save button from settings called a nonexisting method The method was removed when the process for saving configuration in Hob was changed. Replace the call with the right function. [YOCTO #4793] (Bitbake rev: b6aa2b63d71cbe82850a375381b2dbc750cf1905) Signed-off-by: Cristiana Voicu cristiana.vo...@intel.com Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org causes the following error on both CentOS 6.4 and Fedora 18 . oe-init-build-env BitBake requires Python 2.7.3 or later CentOS 6.4 has a non standard location of python. Does anyone know how to tell bitbake of the non standard location of python. This latest version of poky that I downloaded on fedora18 causes the following error. MACHINE=zc702 bitbake core-image-minimal -vDD ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version. ERROR: Execution of event handler 'check_sanity_eventhandler' failed This version of poky and meta-xilinx worked okay. meta meta-yocto= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e meta-xilinx meta-kc705 meta-zc702 meta-zedboard = (nobranch):b065f091f10060f2bb68b58f1d618e26a966fee2 meta-yocto-bsp= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e MACHINE=zc702 bitbake core-image-minimal -vDD NOTE: Tasks Summary: Attempted 1530 tasks of which 306 didn't need to be rerun and all succeeded. We are trying to determine which board to purchase the Xilinx Zynq-7000 SoC ZC702 Evaluation Kit EK-Z7-ZC702-G $895.00 or AES-Z7EV-7Z020-G ZEDBOARD ZYNQ BOARD AES-Z7EV-7Z020-G ECCN Avnet Design Services - Custom $395.00 Does anyone have any experience with either of these boards? From a support standpoint, both the ZC702 and Zedboard are supported really well. You will find that most of the Xilinx reference design and application notes usually always target the ZC702. If you get a Zedboard you'll need to take the extra effort to adapt the pin constraints file. Also the ZC702 has two FMC LPC connectors rather than 1 FMC LPC connector, if that's more important for you. My recommendation would be to go in for the ZC702 or the ZC706 if you need more logic density. Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Build Auditing
Hi all, I was curious if anyone has created any sort of build auditing software for Yocto builds. Our company has an extensive software quality assurance program and we are trying to figure out the best methods to audit our builds. In the past we have used clearaudit type software. The current home-grown version of our build system on Linux uses inotify to track files touched in our build repositories. We generally try to have file-based audit records that record the file path/version that can be traced to individual releases. We are currently using Mercurial as our revision control system. Right now it seems like the best solution to this issue would be to create a wrapper that would fetch our software from Mercurial, create a tar file out of it, hand those tar files to Yocto, start an inotify process to watch the build directories Yocto uses, bitbake our image, collect the list of files touched by yocto, join those files with the files that went into the tar files, and then join those records against the Mercurial checkout records to obtain changeset information/approval metadata. It would certainly be easier to resolve the revision of the Mercurial repository without individual files-touched information, but knowing which files are actually compiled has been highly useful information in the past. For example, when a CVE is released against package foo for a vulnerability in bar.c, it is reassuring to know that our releases didn't even compile bar.c. We do peer code reviews/UT along with static code analysis on many version of each file in our repositories. When we release a product build we have to show to management that each file that went into our released image underwent our QA process. It is definitely a lot of work, but it is necessary for audit/compliance. Anyone else out there challenged with these type of requirements? How are other companies handling this? Any better methods/solutions people can recommend? Thanks for your help! Barry ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fedora 18 CentOS 6.4 yocto difference zc702
Hello, *Where do you find the boot.scr or uEnv.txt for the zc702? * On Wed, Jul 3, 2013 at 1:35 PM, Elvis Dowson elvis.dow...@gmail.com wrote: Hi Edward, On Jul 3, 2013, at 11:05 PM, Edward Vidal vidal.devel...@gmail.com wrote: Hello, I recently built core-image-minimal for zc702. This generated a file with a dtb extension that I have not seen before uImage--3.8-xilinx+git0+6a0bedad60-r1-zynq-zc702-20130703173428.dtb. Can anyone tell me more about the this extension. The *.dts and *.dtb files are related to the device tree source and binary formats. When you work with a hardware project using the Xilinx ISE 14.6/Vivado 2013.2 tools, a dts file will be create. This contains the base address and other parameters for each device peripheral, e.g. serial ports, video controller, etc. The yocto build system takes these files and generates the required *.dtb file. Please refer the Zynq Base TRD 14.6 document, (you can quickly scan through the document and fast forward to section 8.2, for building a dtb file from a dts file) http://www.wiki.xilinx.com/Zynq+Base+TRD+14.6-beta Where do you find the boot.scr or uEnv.txt for the zc702? I built this on both a CentOS 6.4 and a Fedora18 x86_64 system. meta-yocto= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e meta-xilinx meta-kc705 meta-zc702 meta-zedboard = (nobranch):b065f091f10060f2bb68b58f1d618e26a966fee2 meta-yocto-bsp= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e The latest version of poky that I downloaded commit 8a186a6b3853fc1a7dcf342d421c8926c38949c9 Author: Cristiana Voicu cristiana.vo...@intel.com Date: Mon Jul 1 08:09:52 2013 + bitbake: hob: save button from settings called a nonexisting method The method was removed when the process for saving configuration in Hob was changed. Replace the call with the right function. [YOCTO #4793] (Bitbake rev: b6aa2b63d71cbe82850a375381b2dbc750cf1905) Signed-off-by: Cristiana Voicu cristiana.vo...@intel.com Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org causes the following error on both CentOS 6.4 and Fedora 18 . oe-init-build-env BitBake requires Python 2.7.3 or later CentOS 6.4 has a non standard location of python. Does anyone know how to tell bitbake of the non standard location of python. This latest version of poky that I downloaded on fedora18 causes the following error. MACHINE=zc702 bitbake core-image-minimal -vDD ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version. ERROR: Execution of event handler 'check_sanity_eventhandler' failed This version of poky and meta-xilinx worked okay. meta meta-yocto= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e meta-xilinx meta-kc705 meta-zc702 meta-zedboard = (nobranch):b065f091f10060f2bb68b58f1d618e26a966fee2 meta-yocto-bsp= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e MACHINE=zc702 bitbake core-image-minimal -vDD NOTE: Tasks Summary: Attempted 1530 tasks of which 306 didn't need to be rerun and all succeeded. We are trying to determine which board to purchase the Xilinx Zynq-7000 SoC ZC702 Evaluation Kit EK-Z7-ZC702-G $895.00 or AES-Z7EV-7Z020-G ZEDBOARD ZYNQ BOARD AES-Z7EV-7Z020-G ECCN Avnet Design Services - Custom $395.00 Does anyone have any experience with either of these boards? From a support standpoint, both the ZC702 and Zedboard are supported really well. You will find that most of the Xilinx reference design and application notes usually always target the ZC702. If you get a Zedboard you'll need to take the extra effort to adapt the pin constraints file. Also the ZC702 has two FMC LPC connectors rather than 1 FMC LPC connector, if that's more important for you. My recommendation would be to go in for the ZC702 or the ZC706 if you need more logic density. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to add WiFi support
I have searched and spotted different discussion on adding wireless support
but have not found a solution. I have a Intel Centrino Wireless-N 1000 card
plugged into a Intel Atom N2800 (Cedar Trail) platform. I am using Yocto
Project 1.3.1, Cedar Trail BSP, core-image-x11
BB_VERSION= 1.16.0
TARGET_ARCH = i586
TARGET_OS = linux
MACHINE = cedartrail-nopvr
DISTRO= poky
DISTRO_VERSION= 1.3.1
TUNE_FEATURES = m32 core2
Core-image-x11
Following the instructions to use menuconfig and create configuration
fragment, I have enabled the various kernel options to include the iwlagn
driver. The configuration fragment called mydiff.cfg (attached) was placed
in the meta-intel/meta-cedartrail/recipes-kernel/Linux/files folder. The
Linux-yocto_3.0.bbappend was modified with the following:
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
SRC_URI += file://mydiff.cfg
After building the image, ifconfig didn't show wireless and neither does
iwconfig. The adapter is found when I do a lspci. The kernel wireless
website - http://wireless.kernel.org/en/users/Drivers/iwlwifi lists a
firmware package needed for installation. I tried to create a recipe to
place the firmware file in the /lib/firmware folder, but it doesn't get put
in. The lack of what to do for the LICENSE might be a problem. Here is the
recipe:
DESCRIPTION = Intel WiFi 1000 Adapter
LICENSE = GPL-?
LIC_FILES_CHKSUM =
file://${WORKDIR}/LICENSE.iwlwifi-1000-ucode;md5=aa2bfb02c7e0712680334b9f47
f8dc61
SRC_URI = file://LICENSE.iwlwifi-1000-ucode \
file://iwlwifi-1000-3.ucode \
FWPATH = lib/firmware
do_install_apped() {
install -m 0644 LICENSE.iwlwifi-1000-ucode ${D}${FWPATH}
install -m 0644 iwlwifi-1000-3.ucode ${D}${FWPATH}
}
I manually created the /lib/firmware folder and copied the firmware file
(iwlwifi-1000-3.ucode) to the folder. Nothing changed after a reboot. I also
tried a Intel Centrino Ultimate-N 6300 same result.
1. Was a kernel modification the right direction to enable support for this
driver?
2. Did I miss anything with regards to the configuration fragment setup?
3. Is the firmware really needed? If so why is there no /lib/firmware folder
and what should be used for the LICENSE ?
Regards,
Sean Liming
mydiff.cfg
Description: Binary data
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project 1.5_M2.rc1 build status
Adidtional autobuilder configuration errors were corrected and a third spin of 1.5_M2.rc1 started. Please find the build at the new location: http://autobuilder.yoctoproject.org/pub/nightly/20130703-3 pokyeaa5df34af42b6a37f6506847d0f3ef6ba0d298a https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=eaa5df34af42b6a37f6506847d0f3ef6ba0d298a meta-fsl-armdaf582c93a7283fb0af3b25fe2ada48f4c9985c4 https://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=daf582c93a7283fb0af3b25fe2ada48f4c9985c4 meta-fsl-ppca2bcb25c53f935ae9a423c57ca5e2f7a2f7b1a69 (Changed since last build) meta-intel e0d6134ed2e2687ff9f2ee77701666447842bf33 https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/?id=e0d6134ed2e2687ff9f2ee77701666447842bf33 meta-minnow 286a72ba3f5e29432be1dd77127de5bdc2d988c3 https://git.yoctoproject.org/cgit/cgit.cgi/meta-minnow/commit/?id=286a72ba3f5e29432be1dd77127de5bdc2d988c3 meta-qt3b73552fb998fd30a01dbee5a172e432a16078222 https://git.yoctoproject.org/cgit/cgit.cgi/meta-qt3/commit/?id=b73552fb998fd30a01dbee5a172e432a16078222 eclipse-pokye35dfd79e3970f88a8273125890a54f75f108b97 https://git.yoctoproject.org/cgit/cgit.cgi/eclipse-poky/commit/?id=e35dfd79e3970f88a8273125890a54f75f108b97 Please begin QA as soon as possible. Thank you. smime.p7s Description: S/MIME Cryptographic Signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bitbake requires Python 2.7.3
On 28 June 2013 06:53, Burton, Ross ross.bur...@intel.com wrote: On 28 June 2013 11:16, Paul Barker p...@paulbarker.me.uk wrote: Just chiming in to say that sounds excellent. Will this contain a known-working make as well for those with a broken make 3.82? What systems have a broken 3.82? I'm aware that Debian Experimental has it, but stable/testing/unstable have a working 3.81. Certain older versions of Suse also had a broken 3.82, but they've been fixed recently after I filed some bugs. Is it just Fedora 16? I'm using the latest released version of openSuSE (12.3), 64-bit, and recent pulls from master have started complaining that my make-3.82 is broken, so I had to manually downgrade to make-3.81. As it turns out, this make downgrade also fixed a problem I was having with my gumstix build (but I hadn't been seeing any other build failures that are now fixed by this downgrade). ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fedora 18 CentOS 6.4 yocto difference zc702
Hi, On Jul 4, 2013, at 3:25 AM, Edward Vidal vidal.devel...@gmail.com wrote: Where do you find the boot.scr or uEnv.txt for the zc702? I haven't seen one for the ZC702. You could use one of the prebuilt boot images (e.g. the Base TRD 14.5 or 14.6 beta packages), put it into the SD card slot, interrupt the boot process and type printenv, and list out all the u-boot environment variables and copy it out to create your own boot.scr file. The boot args are stored in the *.dts file, so look up the dts file for the zynq board in the TRD or the Xilinx linux kernel distro. Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] sstate-cache hit/miss
Is there a simple way to determine how well (or not) the sstate-cache is being hit during a build? At the end of a build there is always that line saying (something along the lines of): NOTE: Tasks Summary: Attempted X tasks of which Y didn't need to be rerun and all succeeded. How good of an indication of sstate-cache use is this information? If I perform a successful build, delete sstate-cache, and then perform the same build again Y is always some value greater-than zero. If this NOTE at the end of a build was 100% a report of the sstate-cache hit/miss rate, I would assume Y to be zero after a fresh build with no sstate-cache, no? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] sstate-cache clobbering
Let's say I have two build machines (A and B), both running the exact same version of a given distribution. Also assume both machines have a fully populated downloads directory but otherwise have not performed any OE/Yocto builds. On machine A I perform a fresh bitbake core-image-minimal and end up with a sstate-cache of 733MB and I receive a message saying 324/1621 tasks didn't need to be (re)run. I then take this sstate-cache directory, copy it to machine B and perform a bitbake core-image-minimal. This build takes under 5 minutes, and didn't need to run 1374/1621 tasks. So far this makes good sense. The sstate-cache is getting hit quite a lot and the performance of the second build shows considerable improvement (relative to the first build on machine A) to reflect this fact. Now I wipe machine B then get it ready for a fresh build (i.e. put the downloads directory in place, make sure it has all the necessary host packages, etc). Then on machine A I perform a bitbake core-image-minimal -c populate_sdk. Now, on machine A, I end up with a sstate-cache that is 1.6GB in size. I take machine A's 1.6GB sstate-cache and copy it to machine B. Then on machine B I perform a bitbake core-image-minimal. I would have expected this build on machine B to take the same under 5 minutes, and didn't need to run 1374/1621 tasks. But instead I find this build takes 27 minutes and only 781/1621 tasks didn't need to be run. Doesn't it seem strange that a larger sstate-cache involving the same base image has such a lower sstate-cache hit rate? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache clobbering
On Jul 3, 2013, at 10:06 PM, Trevor Woerner trevor.woer...@linaro.org wrote: Let's say I have two build machines (A and B), both running the exact same version of a given distribution. Also assume both machines have a fully populated downloads directory but otherwise have not performed any OE/Yocto builds. On machine A I perform a fresh bitbake core-image-minimal and end up with a sstate-cache of 733MB and I receive a message saying 324/1621 tasks didn't need to be (re)run. I then take this sstate-cache directory, copy it to machine B and perform a bitbake core-image-minimal. This build takes under 5 minutes, and didn't need to run 1374/1621 tasks. So far this makes good sense. The sstate-cache is getting hit quite a lot and the performance of the second build shows considerable improvement (relative to the first build on machine A) to reflect this fact. Now I wipe machine B then get it ready for a fresh build (i.e. put the downloads directory in place, make sure it has all the necessary host packages, etc). Then on machine A I perform a bitbake core-image-minimal -c populate_sdk. Now, on machine A, I end up with a sstate-cache that is 1.6GB in size. I take machine A's 1.6GB sstate-cache and copy it to machine B. Then on machine B I perform a bitbake core-image-minimal. I would have expected this build on machine B to take the same under 5 minutes, and didn't need to run 1374/1621 tasks. But instead I find this build takes 27 minutes and only 781/1621 tasks didn't need to be run. hmm you need to compare signatures( bitbake-diffsigs is your friend), may be there is a variable that should be added to ignore list which is causing unnecessary rebuilds. secondly, why are you copying sstate, set up a nfssever/http on machine A and let it server sstate to machine B via NFS or http Doesn't it seem strange that a larger sstate-cache involving the same base image has such a lower sstate-cache hit rate? ___ 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] sstate-cache hit/miss
On Wed, Jul 3, 2013 at 8:54 PM, Trevor Woerner trevor.woer...@linaro.orgwrote: Is there a simple way to determine how well (or not) the sstate-cache is being hit during a build? It's not ideal, but we're using http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/buildstats-summary.bbclass at the moment, which displays, at the end of a build, the number of do_populate_sysroot tasks run vs do_populate_sysroot_setscene, as an indicator of what % of recipes were built from scratch. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
