Re: [yocto] linux/limits.h: No such file or directory

2016-07-06 Thread Khem Raj 
On Wed, Jul 6, 2016 at 7:05 PM, Takashi Matsuzawa
 wrote:
> Hello Yocto.
>
> I am seeing this error recently, and wonder if it is a known issue that has
> a workaround.
>
> It does not go even if I delete DL_DIR or SSTATE_CACHE, etc.  It started to
> happen, though previously the build ran well.
>

which version of release are you using ? secondly can you see if its
reproducible in a fresh setup

>>configure: error: C preprocessor "x86_64-pokysdk-linux-gcc -E
>> --sysroot=/mnt/ssd2/>yocto/dev/tmp/x86-wk3/sysroots/x86_64-nativesdk-pokysdk-linux
>> " fails sanity check
>>| See `config.log' for more details.
>
> If I look into config.log
> (gcc-4.9.2/build.x86_64-pokysdk-linux.x86_64-pokysdk-linux/libgcc/config.log)
> as suggested, I can see the following.
> It says linux/limits.h is not found.
>
> (in config.log)
>>usr/include/bits/local_lim.h:38:26: fatal error: linux/limits.h: No such
>> file or directory
>
> I googled some, and found a few similar reports (e.g. install kernel headers
> first, could be a race condition, etc.) but I am not sure practically how to
> avoid this build break.
>
> Error log (on bitable console):
>
> 
> | checking for x86_64-pokysdk-linux-gcc
> --sysroot=/mnt/ssd2/yocto/dev/tmp/x86-wk3/sysroots/x86_64-nativesdk-pokysdk-linux
> option to accept ISO C89... none needed
> | checking how to run the C preprocessor... x86_64-pokysdk-linux-gcc -E
> --sysroot=/mnt/ssd2/yocto/dev/tmp/x86-wk3/sysroots/x86_64-nativesdk-pokysdk-linux
> | configure: error: in
> `/mnt/ssd2/yocto/dev/tmp/x86-wk3/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/4.9.2-r0/gcc-4.9.2/build.x86_64-pokysdk-linux.x86_64-pokysdk-linux/libgcc':
> | configure: error: C preprocessor "x86_64-pokysdk-linux-gcc -E
> --sysroot=/mnt/ssd2/yocto/dev/tmp/x86-wk3/sysroots/x86_64-nativesdk-pokysdk-linux
> " fails sanity check
> | See `config.log' for more details.
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_configure (log file is located at
> /mnt/ssd2/yocto/dev/tmp/x86-wk3/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/4.9.2-r0/temp/log.do_configure.888)
> ERROR: Task 3580
> (virtual:nativesdk:/mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/recipes-devtools/gcc/libgcc-initial_4.9.bb,
> do_configure) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 4247 tasks of which 2301 didn't need to be
> rerun and 1 failed.
> Waiting for 0 running tasks to finish:
> 
>
>
>
> --
> ___
> 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] customizing system configuration files in my image

2016-07-06 Thread Paul Eggleton 
On Fri, 01 Jul 2016 09:55:38 Zhenhua Luo wrote:
> On Fri, 01 Jul 2016 09:11:47 Ottavio Campana wrote:
> > I would like to customize an image I am developing based on core image
> > minimal.
> > 
> > Particularly, I'd like to customize the files /etc/network/interfaces and
> > /etc/inittab .
>
> Usually I do it by adding bbappend of corresponding packages to override
> original files, the interfaces is provided by init-ifupdown, the inittab is
> provided by sysvinit-inittab.
> 
> An example:
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/recipes-core/in
> it-ifupdown

FYI there is a shortcut to creating these - the "recipetool appendfile" 
command. For example, say you have your desired custom inittab file locally as 
"myinittab" and you want the bbappend to be created in meta-mylayer then you 
would run:

recipetool appendfile meta-mylayer /etc/inittab myinittab

This will automatically determine which recipe is providing the file and how 
to overwrite it with your version. You do need to have built that recipe for 
this to work, but then that will already be the case if you have built the 
image beforehand.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] baremetal cross-compiler

2016-07-06 Thread Paul Eggleton 
Hi Robert,

On Tue, 05 Jul 2016 12:02:11 Robert Berger wrote:
> According to the release notes it should be possible to build a
> baremetal (no glibc/Linux) cross compiler with the YP. I just can't find
> any information how this could be done.
> 
> I would like to build a native compiler e.g. for a Cortex-A3 and compile
> FreeRTOS with it.

It looks like all you should need to do would be to set TCLIBC = "baremetal" 
and build the toolchain. Juro, is there any more to it than that?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] linux/limits.h: No such file or directory

2016-07-06 Thread Takashi Matsuzawa 
Hello Yocto.

I am seeing this error recently, and wonder if it is a known issue that has a 
workaround.

It does not go even if I delete DL_DIR or SSTATE_CACHE, etc.  It started to 
happen, though previously the build ran well.

>configure: error: C preprocessor "x86_64-pokysdk-linux-gcc -E 
>--sysroot=/mnt/ssd2/>yocto/dev/tmp/x86-wk3/sysroots/x86_64-nativesdk-pokysdk-linux
> " fails sanity check
>| See `config.log' for more details.

If I look into config.log 
(gcc-4.9.2/build.x86_64-pokysdk-linux.x86_64-pokysdk-linux/libgcc/config.log) 
as suggested, I can see the following.
It says linux/limits.h is not found.

(in config.log)
>usr/include/bits/local_lim.h:38:26: fatal error: linux/limits.h: No such file 
>or directory

I googled some, and found a few similar reports (e.g. install kernel headers 
first, could be a race condition, etc.) but I am not sure practically how to 
avoid this build break.

Error log (on bitable console):


| checking for x86_64-pokysdk-linux-gcc  
--sysroot=/mnt/ssd2/yocto/dev/tmp/x86-wk3/sysroots/x86_64-nativesdk-pokysdk-linux
 option to accept ISO C89... none needed
| checking how to run the C preprocessor... x86_64-pokysdk-linux-gcc -E 
--sysroot=/mnt/ssd2/yocto/dev/tmp/x86-wk3/sysroots/x86_64-nativesdk-pokysdk-linux
| configure: error: in 
`/mnt/ssd2/yocto/dev/tmp/x86-wk3/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/4.9.2-r0/gcc-4.9.2/build.x86_64-pokysdk-linux.x86_64-pokysdk-linux/libgcc':
| configure: error: C preprocessor "x86_64-pokysdk-linux-gcc -E 
--sysroot=/mnt/ssd2/yocto/dev/tmp/x86-wk3/sysroots/x86_64-nativesdk-pokysdk-linux
 " fails sanity check
| See `config.log' for more details.
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at 
/mnt/ssd2/yocto/dev/tmp/x86-wk3/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/4.9.2-r0/temp/log.do_configure.888)
ERROR: Task 3580 
(virtual:nativesdk:/mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/recipes-devtools/gcc/libgcc-initial_4.9.bb,
 do_configure) failed with exit code '1'
NOTE: Tasks Summary: Attempted 4247 tasks of which 2301 didn't need to be rerun 
and 1 failed.
Waiting for 0 running tasks to finish:



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to install a service generated by update-rc.d?

2016-07-06 Thread Stephan Roslen 
This should deploy the file correctly.

do_install_append() {
install -d ${D}${sysconfdir}/init.d
install -m 0755 ${WORKDIR}/can_if
${D}${sysconfdir}/init.d/can_if
}

On Mi, 2016-07-06 at 11:20 +0200, s.jar...@esa-grimma.de wrote:
> Hej, 
> 
> I want to start a service that generates Sockets for the CAN Modules.
> Manually configuring the system is no problem, but I like to have it
> done by yocto. Below I give the code of my recipe (socketcan.bb): 
> # 
> SUMMARY = "the config for the can socket interface" 
> SECTION = "CAN" 
> LICENSE = "CLOSED" 
> 
> inherit update-rc.d 
> 
> RDEPENDS_${PN} = "initscripts" 
> 
> DEPENDS = "iproute2" 
> 
> SRC_URI = "file://can_if" 
> 
> INITSCRIPT_PARAMS = "start 02 2 3 4 5 . stop 01 0 1 6 ." 
> INITSCRIPT_NAME = "can_if" 
> 
> CONFFILES_${PN} += "${sysconfdir}/init.d/can_if" 
> # 
> It has one file bash script "can_if". This contains the up and down
> commands. I want to generate at the /etc/rc*** Dirs the
> S02can_if/K01can_if links. 
> Building the recipe via "bitbake socketcan" works fine. 
> When generating the rootfs via "bitbake core-image-minimal" I got the
> following error: 
> # 
> ERROR: core-image-minimal-1.0-r0 do_rootfs: Unable to install
> packages. Command '/home/user/myTC/poky/build/tmp/sysroots/x86_64-
> linux/usr/bin/apt-get  install --force-yes --allow-unauthenticated
> python-modules meteocontrol webmaint libg3logger0 packagegroup-core-
> ssh-openssh apt vim curl pmdb redis libcsv3 myuser boost
> packagegroup-core-boot libredox0 libemd2 python-django python libev4
> can-utils run-postinsts util-linux dpkg mymodules grep libhiredis0.13
> libmydbus0 libconfig iproute2 p7zip socketcan' returned 100: 
> Reading package lists... 
> Building dependency tree... 
> Reading state information... 
> Package socketcan is not available, but is referred to by another
> package. 
> This may mean that the package is missing, has been obsoleted, or 
> is only available from another source 
> 
> E: Package 'socketcan' has no installation candidate 
> 
> ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed:
> do_rootfs 
> ERROR: Logfile of failure stored in:
> /home/user/myTC/poky/build/tmp/work/sama5d3xek-poky-linux-
> gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.14597 
> ERROR: Task 9 (/home/user/myTC/poky/meta/recipes-core/images/core-
> image-minimal.bb, do_rootfs) failed with exit code '1' 
> # 
> 
> Any idea how to fix that? 
> 
> Regards!
> 
> Stefan Jaritz
> 
> 
> ESA Elektroschaltanlagen Grimma GmbH
> Broner Ring 30
> 04668 Grimma
> Telefon: +49 3437 9211 176
> Telefax: +49 3437 9211 26
> E-Mail: s.jar...@esa-grimma.de
> Internet: www.esa-grimma.de
> 
> 
> Geschäftsführer:
> Dipl.-Ing. Jörg Gaitzsch
> Jörg Reinker
> 
> Sitz der Gesellschaft: Grimma
> Ust.-ID: DE 141784437
> Amtsgericht: Leipzig, HRB 5159
> Steuernummer: 238/108/00755
> 
> 
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. 
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten 
> haben, informieren Sie bitte sofort den Absender und löschen Sie
> diese 
> Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe
> dieser Mail 
> ist nicht gestattet.
> 
> This e-mail may contain confidential and/or privileged information.
> If you are 
> not the intended recipient (or have received this e-mail in error)
> please 
> notify the sender immediately and destroy this e-mail. Any
> unauthorized 
> copying, disclosure or distribution of the material in this e-mail is
> strictly 
> forbidden.
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
Stephan Roslen
Dipl.-Ing.
 
hibento
Jülicher Strasse 306
52070 Aachen
 
Tel: +49 241 53809119-1
Fax: +49 241 53809119-9
 
E-Mail: stephan.ros...@hibento.de
Web: http://www.hibento.de
 
Geschäftsführer: Christian Steffens
Bankverbindung: Aachener Bank, BIC: GENODED1AAC
IBAN: DE76390601800628606021
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH V3 0/4] Drop rpi-mkimage and use upstream u-boot

2016-07-06 Thread Paul Barker 
On Sat, 18 Jun 2016 12:07:02 +0100
Paul Barker  wrote:

> Following discussion on the Raspberry Pi tools bug tracker it was
> found that rpi-mkimage is no longer needed with recent firmware. It
> can therefore be dropped from the layer completely.
> 
> Whilst looking into this I also found that the u-boot-rpi recipe in
> meta-raspberrypi can now be replaced by direct use of the mainline
> u-boot recipe from oe-core. The 2016.03 release of u-boot supports
> the original Raspberry Pi and the Raspberry Pi 2. Configuration of
> the u-boot environment to directly boot the uImage file on the SD
> card must still be done manually - I'm going to look into making this
> work by default in the near future.
> 
> Changes for V2:
> * Don't remove linux-raspberrypi 3.18 just yet
> * Drop move of PV setting out of linux-raspberrypi.inc
> 
> Changes for V3:
> * Rebase onto latest master
> 
> Paul Barker (4):
>   linux-raspberrypi: rpi-mkimage is no longer needed
>   u-boot: Use mainline u-boot recipe from oe-core
>   rpi-mkimage: Remove unused recipe
>   sdcard_image-rpi: Always install dtb files
> 
>  classes/sdcard_image-rpi.bbclass   | 42
> +++---
> conf/machine/include/rpi-default-providers.inc |  1 -
> conf/machine/raspberrypi.conf  |  2 ++
> conf/machine/raspberrypi2.conf |  2 ++
> recipes-bsp/rpi-mkimage/rpi-mkimage/License| 25
> - .../open-files-relative-to-script.patch| 17
> - recipes-bsp/rpi-mkimage/rpi-mkimage_git.bb | 22
>  recipes-bsp/u-boot/u-boot-rpi_git.bb   | 29
> --- recipes-kernel/linux/linux-raspberrypi.inc |
> 20 --- 9 files changed, 25 insertions(+), 135 deletions(-)
> delete mode 100644 recipes-bsp/rpi-mkimage/rpi-mkimage/License delete
> mode 100644
> recipes-bsp/rpi-mkimage/rpi-mkimage/open-files-relative-to-script.patch
> delete mode 100644 recipes-bsp/rpi-mkimage/rpi-mkimage_git.bb delete
> mode 100644 recipes-bsp/u-boot/u-boot-rpi_git.bb
> 

Ping on this.

Thanks,
Paul Barker
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH] features/thermal: Enable Intel PMIC thermal feature

2016-07-06 Thread Nilesh Bacchewar 
Enable this for Intel PMIC with ADC channels monitoring system
temperature measurements and alerts.

Signed-off-by: Nilesh Bacchewar 
---
 features/power/intel_pmic.cfg | 6 ++
 features/thermal/coretemp.cfg | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/features/power/intel_pmic.cfg b/features/power/intel_pmic.cfg
index 1b15a2c..4b2472b 100644
--- a/features/power/intel_pmic.cfg
+++ b/features/power/intel_pmic.cfg
@@ -1,2 +1,8 @@
+# Intel Atom SoC PMIC
 CONFIG_INTEL_SOC_PMIC=y
+
+# Intel PMIC operation region support
 CONFIG_PMIC_OPREGION=y
+
+# Intel PMIC GPIO driver
+CONFIG_GPIO_WHISKEY_COVE=m
diff --git a/features/thermal/coretemp.cfg b/features/thermal/coretemp.cfg
index 9be6e74..bdaf6d0 100644
--- a/features/thermal/coretemp.cfg
+++ b/features/thermal/coretemp.cfg
@@ -12,3 +12,6 @@ CONFIG_INT340X_THERMAL=m
 
 # Intel PowerClamp idle injection driver
 CONFIG_INTEL_POWERCLAMP=y
+
+# Intel PMIC thermal driver
+CONFIG_INTEL_PMIC_THERMAL=m
-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [yocto-kernel-cache] [PATCH] Thermal: Enable PMIC thermal configs

2016-07-06 Thread Nilesh Bacchewar 
Hello Bruce,

This change enables PMIC thermal feature on broxton platform. Changes are added 
in 
coretemp.cfg and intel pmic. This change is targeted for yocto-4.4 branch.

Nilesh Bacchewar (1):
  features/thermal: Enable Intel PMIC thermal feature

 features/power/intel_pmic.cfg | 6 ++
 features/thermal/coretemp.cfg | 3 +++
 2 files changed, 9 insertions(+)

-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [yocto-kernel-cache] [PATCH] Enable USB Type C for broxton

2016-07-06 Thread Pranav Tipnis 
Hello Bruce,

This is to enable USB type C feature on broxton platform. I have
created new config fragments for usb type c and intel pmic. This
should go in yocto-4.4 branch.

Pranav Tipnis (1):
  broxton: Enable USB Type C feature for broxton

 features/power/intel_pmic.cfg| 5 +
 features/power/intel_pmic.scc| 4 
 features/soc/broxton/broxton.cfg | 3 +++
 features/soc/broxton/broxton.scc | 2 ++
 features/usb/usb-typec.cfg   | 2 ++
 features/usb/usb-typec.scc   | 4 
 6 files changed, 20 insertions(+)
 create mode 100644 features/power/intel_pmic.cfg
 create mode 100644 features/power/intel_pmic.scc
 create mode 100644 features/usb/usb-typec.cfg
 create mode 100644 features/usb/usb-typec.scc

-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH] gpio: update Intel WhiskeyCove GPIO driver

2016-07-06 Thread Nilesh Bacchewar 
Incremental patch for Intel WhiskeyCove GPIO driver based on
updated patch version

Changes:
 - Typo fix (Whsikey --> Whiskey).
 - Removed the device id table and added MODULE_ALIAS()

Signed-off-by: Nilesh Bacchewar 
---
 drivers/gpio/Kconfig  |  2 +-
 drivers/gpio/gpio-wcove.c | 12 
 2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ceea085..f343a8c 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -733,7 +733,7 @@ config GPIO_WHISKEY_COVE
help
  Support for GPIO pins on Whiskey Cove PMIC.
 
- Say Yes if you have a Intel SoC based tablet with Whsikey Cove PMIC
+ Say Yes if you have a Intel SoC based tablet with Whiskey Cove PMIC
  inside.
 
  This driver can also be built as a module. If so, the module will be
diff --git a/drivers/gpio/gpio-wcove.c b/drivers/gpio/gpio-wcove.c
index ed3ac88..5983207 100644
--- a/drivers/gpio/gpio-wcove.c
+++ b/drivers/gpio/gpio-wcove.c
@@ -382,17 +382,12 @@ static int wcove_gpio_remove(struct platform_device *pdev)
return 0;
 }
 
-static const struct platform_device_id pmic_gpio_id_table[] = {
-   { "bxt_wcove_gpio", },
-};
-
 static struct platform_driver wcove_gpio_driver = {
-   .probe = wcove_gpio_probe,
-   .remove = wcove_gpio_remove,
.driver = {
-   .name = "wcove_gpio",
+   .name = "bxt_wcove_gpio",
},
-   .id_table = pmic_gpio_id_table,
+   .probe = wcove_gpio_probe,
+   .remove = wcove_gpio_remove,
 };
 
 module_platform_driver(wcove_gpio_driver);
@@ -400,3 +395,4 @@ module_platform_driver(wcove_gpio_driver);
 MODULE_AUTHOR("Ajay Thomas ");
 MODULE_DESCRIPTION("Intel Whiskey Cove GPIO Driver");
 MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:bxt_wcove_gpio");
-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] What keeps sstate from being used?

2016-07-06 Thread Chris Z. 
Hi,

Gary what poky version you are using ?
It seems that you probably updated somehow local workspace recipe for
binutils from poky master upstream. 5 days ago binutils recipe was updated
with new patch.

http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/recipes-devtools/binutils/binutils-2.26.inc?id=1b29aff0e0ca00c9125e29f8d229ec22ef0350d8

Do you have some scripts or cron to update recipes and check that they are
building with newer poky ?

On Wed, Jul 6, 2016 at 4:39 PM, Gary Thomas  wrote:

> On 2016-07-06 16:27, Burton, Ross wrote:
>
>>
>> On 6 July 2016 at 15:23, Gary Thomas  g...@mlbassoc.com>> wrote:
>>
>> Dependency on checksum of file
>> MIPS-GAS-Fix-an-ISA-override-not-lifting-ABI-restrictions.patch was removed
>>
>>
>> As this show binutils changing its SRC_URI this suggests that you did
>> something in between the two runs, or those hashes
>> are not the relevant pair.
>>
>
> I could send the whole trace of how I got there, but basically
> I noticed that 'patch' was being rebuilt for the target, so I
> tracked that back to gcc-cross-arm which led me to binutils-cross-arm
>
> Maybe I've done something wrong or don't totally understand the output
> of the tools, but it's clear that something is a little off here as
> my original build was 99% complete (only a dozen or so tasks remaining)
> and when I reran it from sstate, it more or less started over.
>
> If you have pointers on how I can diagnose this, or at least retrace it,
> I'm all ears as I really want to see this work the way it's advertised
> "on the tin"
>
> Ideas/suggestions more than welcome
>
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder][PATCH 2/2] publish build artifacts for wic images

2016-07-06 Thread Bill Randle 
Publish the wic images created by the nightly-wic build so they are
available for QA testing.

[YOCTO #9397]

Signed-off-by: Bill Randle 
---
 buildset-config.controller/nightly-wic.conf|  8 ++---
 .../autobuilder/buildsteps/PublishArtifacts.py | 35 --
 2 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/buildset-config.controller/nightly-wic.conf 
b/buildset-config.controller/nightly-wic.conf
index 7d2ae88..27584cb 100644
--- a/buildset-config.controller/nightly-wic.conf
+++ b/buildset-config.controller/nightly-wic.conf
@@ -19,10 +19,6 @@ steps: [{'SetDest':{}},
 {'BuildImages':{'images':'core-image-sato'}},
 {'CreateWicImages':{'wic_img_type':'directdisk', 
'target_img':'core-image-sato'}},
 {'CreateWicImages':{'wic_img_type':'directdisk-gpt', 
'target_img':'core-image-sato'}},
-{'CreateWicImages':{'wic_img_type':'mkefidisk', 
'target_img':'core-image-sato'}}]
-
-
-
-
-
+{'CreateWicImages':{'wic_img_type':'mkefidisk', 
'target_img':'core-image-sato'}},
+{'PublishArtifacts': {'artifacts': ['qemux86-64', 'genericx86-64']}}]
 
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
index 952a458..f9df16c 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
@@ -174,7 +174,14 @@ class PublishArtifacts(ShellCommand):
 artifact_name, deploy_image_dir = 
self.getDeployNames(artifact, buildername)
 command += self.generateMD5cmd(artifact, deploy_image_dir)
 command=command+"mkdir -p " + DEST + "/" + 
QEMU_PUBLISH_DIR + "/" + artifact_name + ";"
-command=command+"cp -R --no-dereference --preserve=links " 
+ \
+if "-wic" in buildername:
+deploy_image_dir += "/*/*/build";
+command=command+"cp --no-dereference --preserve=links 
" + \
+deploy_image_dir + "/*\.direct " + \
+deploy_image_dir + "/*\.direct.md5sum " + \
+DEST + "/" + QEMU_PUBLISH_DIR + "/" + 
artifact_name + ";"
+else:
+command=command+"cp -R --no-dereference 
--preserve=links " + \
 deploy_image_dir + \
 "/*" + artifact + "* " + DEST + "/" + 
QEMU_PUBLISH_DIR + "/" + artifact_name + ";"
 elif "mpc8315e" in artifact:
@@ -213,18 +220,26 @@ class PublishArtifacts(ShellCommand):
"genericx86-64" in artifact:
 command = command+"echo 'Skipping copy of 
genericx86-64.'; "
 else:
-command=command+"mkdir -p " + DEST + "/"+ 
MACHINE_PUBLISH_DIR +"/" + artifact_name + ";"
-if "beagle" in artifact:
-command=command+"cp -R --no-dereference 
--preserve=links " + \
+command += self.generateMD5cmd(artifact, 
deploy_image_dir)
+if "-wic" in buildername:
+deploy_image_dir += "/*/*/build";
+command=command+"mkdir -p " + DEST + "/" + 
MACHINE_PUBLISH_DIR + "/" + artifact_name + ";"
+command=command+"cp --no-dereference 
--preserve=links " + \
+deploy_image_dir + "/*\.direct " + \
+deploy_image_dir + "/*\.direct.md5sum " + \
+DEST + "/" + MACHINE_PUBLISH_DIR + "/" + 
artifact_name + ";"
+else:
+command=command+"mkdir -p " + DEST + "/"+ 
MACHINE_PUBLISH_DIR +"/" + artifact_name + ";"
+if "beagle" in artifact:
+command=command+"cp -R --no-dereference 
--preserve=links " + \
  deploy_image_dir + \
  "/*Image* " + DEST + "/" + 
MACHINE_PUBLISH_DIR +"/" + artifact_name + ";"
-command=command+"cp -R --no-dereference 
--preserve=links " + \
+command=command+"cp -R --no-dereference 
--preserve=links " + \
  deploy_image_dir + \
  "/u-boot* " + DEST + "/" + 
MACHINE_PUBLISH_DIR +"/" + artifact_name + ";"
-command=command+"cp -R --no-dereference 
--preserve=links " + \
+command=command+"cp -R --no-dereference 
--preserve=links " + \
  deploy_image_dir + \

[yocto] [yocto-autobuilder][PATCH 1/2] PublishArtifacts.py: create md5sum files in same dir as artifacts

2016-07-06 Thread Bill Randle 
Previously all the md5sum files got put into the top level deploy directory.
This patch keeps the md5sum file in the same directory as the file it is
hashing. It also limits the traversal depth to five, to avoid hashing the
wic components that go into making the wic images.

Signed-off-by: Bill Randle 
---
 .../site-packages/autobuilder/buildsteps/PublishArtifacts.py | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
index 111dad7..952a458 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
@@ -233,9 +233,8 @@ class PublishArtifacts(ShellCommand):
 def generateMD5cmd(self, artifact, deploy_dir):
 cmd = ""
 if os.environ.get('GEN_IMG_MD5') == "True":
-cmd += "for x in `find " + deploy_dir + " -type f`;"
-cmd += "do fname=`basename $x`;"
-cmd += "md5sum $x >> " + deploy_dir + "/$fname.md5sum; done;"
+cmd += "for x in `find " + deploy_dir + " -type f -maxdepth 5`;"
+cmd += "do md5sum $x >> " + "$x.md5sum; done;"
 return cmd
 
 def getDeployNames(self, artifact, buildername):
-- 
2.5.5

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder][PATCH 0/2] publish wic images

2016-07-06 Thread Bill Randle 
QA started testing wic images in Yocto 2.1, but was building them
themselves. Have the autobuilder publish the wic images so they are
available for testing.

[YOCTO #9397]

Bill Randle (2):
  PublishArtifacts.py: create md5sum files in same dir as artifacts
  publish build artifacts for wic images

 buildset-config.controller/nightly-wic.conf|  8 ++---
 .../autobuilder/buildsteps/PublishArtifacts.py | 40 +++---
 2 files changed, 30 insertions(+), 18 deletions(-)

-- 
2.5.5

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to create a directory for an SD-Card mount?

2016-07-06 Thread Khem Raj 
You also need to package it with FILES

On Jul 6, 2016 11:09 AM, "Daniel."  wrote:
>
> install -d ${D}/media/sd1
> ???
>
> 2016-07-06 11:44 GMT-03:00  :
> > Hej
> >
> > I managed to create and install a rule that should mount a sd card to
> > "/media/sd1".  To finish it, I need to create the directory "sd1" in
media.
> > My recipe for the rule looks like:
> > ###
> > SUMMARY = "the udev rules for the board"
> > SECTION = "rules"
> > LICENSE = "CLOSED"
> >
> > SRC_URI = "file://50-mmc.rules \
> > "
> > S = "${WORKDIR}"
> >
> > do_install () {
> > install -d ${D}${sysconfdir}/udev/rules.d
> > install -m 0644 ${WORKDIR}/50-mmc.rules
> > ${D}${sysconfdir}/udev/rules.d/
> > }
> > ###
> > How to create a dir in do_install which goes to the package?
> >
> > By the way:
> > I was also appending fstab after this article
> >
> > https://communities.intel.com/thread/49251
> >
> > Is there an better way to uncomment/modify that one line in fstab?
> >
> > Regards!
> >
> > Stefan Jaritz
> >
> > 
> > ESA Elektroschaltanlagen Grimma GmbH
> > Broner Ring 30
> > 04668 Grimma
> > Telefon: +49 3437 9211 176
> > Telefax: +49 3437 9211 26
> > E-Mail: s.jar...@esa-grimma.de
> > Internet: www.esa-grimma.de
> >
> >
> > Geschäftsführer:
> > Dipl.-Ing. Jörg Gaitzsch
> > Jörg Reinker
> >
> > Sitz der Gesellschaft: Grimma
> > Ust.-ID: DE 141784437
> > Amtsgericht: Leipzig, HRB 5159
> > Steuernummer: 238/108/00755
> >
> >
> > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> > Informationen.
> > Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
> > erhalten
> > haben, informieren Sie bitte sofort den Absender und löschen Sie diese
> > Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
> > Mail
> > ist nicht gestattet.
> >
> > This e-mail may contain confidential and/or privileged information. If
you
> > are
> > not the intended recipient (or have received this e-mail in error)
please
> > notify the sender immediately and destroy this e-mail. Any unauthorized
> > copying, disclosure or distribution of the material in this e-mail is
> > strictly
> > forbidden.
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
>
>
> --
> "Do or do not. There is no try"
>   Yoda Master
> --
> ___
> 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] how to tftp download a newer u-boot into RAM and simply execute it?

2016-07-06 Thread Bruce Ashfield 

On 2016-07-06 03:14 PM, Robert P. J. Day wrote:

On Wed, 6 Jul 2016, Chris Hallinan wrote:


Hi Robert,
That's not old, that's ancient in dog^HU-Boot years - LOL!

It's been quite a while since I looked at a PPC U-Boot, but at a
minimum, you will need to link U-Boot to a RAM'able address.  By
default, I'm sure the recipe links it for the NOR addresses.  When
it boots from NOR it immediately relocates itself to a RAM address
from NOR, if memory serves.  Notice it's crashing right away, on the
second instruction.


   i came to that conclusion ... i looked at the u-boot.srec file that
was generated and, sure enough:

S00E752D626F6F742E73726563C0
S315FE0042424242424242420606060606060606AC
S315FE10DC
S315FE20A0A0A0A0A0A0A0A06060606060606060CC
... snip ...

so definitely linked for flashing to beginning of NOR flash at
0xFE00. so i suspect i could just flash it and reset and it would
work just fine. and never mind, i found the answer i was after:

http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM

i was hoodwinked into thinking it would be easy because i found this
page:

https://blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:tftp_loading_files

of course, that page is for the blackfin, precisely one of the
platforms the denx page says it *can* work for. gr.

   so, before i commit myself to this, who's the PPC/MPC8315E-RDB
expert on this list who can confirm a stock u-boot should flash to NOR
and just plain run?


Kevin Hao @ Wind has been looking after the reference build for us, so
he is the best bet to know.

Bruce



rday



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] hang on ... can u-boot binary extend beyond CONFIG_ENV_ADDR?

2016-07-06 Thread Robert P. J. Day 

  ok, one last dumb question before i throw caution to the winds. i'm
looking at the u-boot board defn file for this board,
include/configs/MPC8315ERDB.h, and i see the following in there:

  #if !defined(CONFIG_SYS_RAMBOOT)
#define CONFIG_ENV_IS_IN_FLASH  1
#define CONFIG_ENV_ADDR \
(CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN)

i followed all that through, and CONFIG_ENV_ADDR ends up being defined
by:

#define CONFIG_SYS_MONITOR_LEN  (384 * 1024) /* Reserve 384 kB for Mon */

but the u-boot.bin file created via meta-yocto-bsp is larger than
that:

-rwxr-xr-x. 2 rpjday rpjday   423964 Jul  5 06:46
u-boot-mpc8315e-rdb-v2016.03+gitAUTOINC+df61a74e68-r0.bin

  does that make sense? how can the u-boot binary overlap where the
persistent environment is supposed to live?

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] how to tftp download a newer u-boot into RAM and simply execute it?

2016-07-06 Thread Robert P. J. Day 
On Wed, 6 Jul 2016, Chris Hallinan wrote:

> Hi Robert,
> That's not old, that's ancient in dog^HU-Boot years - LOL!
>
> It's been quite a while since I looked at a PPC U-Boot, but at a
> minimum, you will need to link U-Boot to a RAM'able address.  By
> default, I'm sure the recipe links it for the NOR addresses.  When
> it boots from NOR it immediately relocates itself to a RAM address
> from NOR, if memory serves.  Notice it's crashing right away, on the
> second instruction.

  i came to that conclusion ... i looked at the u-boot.srec file that
was generated and, sure enough:

S00E752D626F6F742E73726563C0
S315FE0042424242424242420606060606060606AC
S315FE10DC
S315FE20A0A0A0A0A0A0A0A06060606060606060CC
... snip ...

so definitely linked for flashing to beginning of NOR flash at
0xFE00. so i suspect i could just flash it and reset and it would
work just fine. and never mind, i found the answer i was after:

http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM

i was hoodwinked into thinking it would be easy because i found this
page:

https://blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:tftp_loading_files

of course, that page is for the blackfin, precisely one of the
platforms the denx page says it *can* work for. gr.

  so, before i commit myself to this, who's the PPC/MPC8315E-RDB
expert on this list who can confirm a stock u-boot should flash to NOR
and just plain run?

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] how to tftp download a newer u-boot into RAM and simply execute it?

2016-07-06 Thread Chris Hallinan 
Hi Robert,

That's not old, that's ancient in dog^HU-Boot years - LOL!

It's been quite a while since I looked at a PPC U-Boot, but at a minimum,
you will need to link U-Boot to a RAM'able address.  By default, I'm sure
the recipe links it for the NOR addresses.  When it boots from NOR it
immediately relocates itself to a RAM address from NOR, if memory serves.
Notice it's crashing right away, on the second instruction.

In past history, many U-Boot ports would require more work than simply
linking it to a proper RAM address.  I can't comment on the 8313, 'cuz I
haven't worked on it in ages.  Older ports had configuration options for
exactly that use case, but I haven't seen that used in a long time.
Perhaps if you can find one of those ports, it will lead you in the right
direction.  I can't recall: CFG_RUN_IN_RAM or some such magic???

Hopefully someone on this list smarter (and more current on U-Boot) than me
can help.

Regards,

Chris



On Wed, Jul 6, 2016 at 2:18 PM, Robert P. J. Day 
wrote:

>
>   ok, i'm trying to do something on my MPC8315E-RDB that *should* be
> really simple, and i'm getting nowhere.
>
>   currently on this machine, i have u-boot in NOR flash, and it's old
> but it will still boot the other images also stored in NOR flash:
>
>   U-Boot 1.3.0-rc2 (Mar 21 2008 - 16:00:02) MPC83XX
>
> i just built a new image from the current poky repo for precisely
> this target, and my generated artifacts include the newer u-boot
> binary image:
>
>   -rwxr-xr-x. 2 rpjday rpjday   423964 Jul  5 06:46
> u-boot-mpc8315e-rdb-v2016.03+gitAUTOINC+df61a74e68-r0.bin
>
> rather than immediately write it to flash, i'd like to download and
> test it first, and everything i've seen suggests i should be able to:
>
> => tftp 0x10 u-boot-mpc8315e-rdb-v2016.03+gitAUTOINC+df61a74e68-r0.bin
> => go 0x10
>
>   well, the downloading seems to work fine:
>
> => tftp 0x10 u-boot-mpc8315e-rdb-v2016.03+gitAUTOINC+df61a74e68-r0.bin
> Speed: 1000, full duplex
> Using eTSEC0 device
> TFTP from server 192.168.1.13; our IP address is 192.168.1.127
> Filename 'u-boot-mpc8315e-rdb-v2016.03+gitAUTOINC+df61a74e68-r0.bin'.
> Load address: 0x10
> Loading: #
> done
> Bytes transferred = 423964 (6781c hex)
> =>
>
> so the number of bytes transferred is correct. and then bad things
> happen:
>
> => go 0x10
> ## Starting application at 0x0010 ...
> NIP: 0018 XER: 2000 LR: 07FC6614 REGS: 07f2fcd0 TRAP: 0700 DAR:
> 
> MSR: 0008b002 EE: 1 PR: 0 FP: 1 ME: 1 IR/DR: 00
>
> GPR00: 07FC6604 07F2FDC0 0080 0001 07F329E4 0010 0001
> 0030
> GPR08: 0041 0020 0006   0200 07FF9000
> 09FB2000
> GPR16:       
> 
> GPR24: 07F32930   0002 0010 07F2FF4C 07FF98F8
> 07F329E4
> Call backtrace:
> 07FC6604 07FD767C 07FD6D10 07FD6E98 07FC6110 07FB6BF8 07FB568C
> Program Check Exception
> Resetting the board.
>
>
>   am i missing something? downloading to the wrong address in RAM?
> jumping to the wrong entry point? i'mopen to suggestions, i know i've
> done this sort of thing before.
>
>   i'm willing to start a new configure and build from scratch if
> someone wants to supply a recipe. since this is the current YP powerpc
> reference board, it really should work out of the box, no?
>
> 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
>



-- 
Life is like Linux - it never stands still.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] how to tftp download a newer u-boot into RAM and simply execute it?

2016-07-06 Thread Robert P. J. Day 

  ok, i'm trying to do something on my MPC8315E-RDB that *should* be
really simple, and i'm getting nowhere.

  currently on this machine, i have u-boot in NOR flash, and it's old
but it will still boot the other images also stored in NOR flash:

  U-Boot 1.3.0-rc2 (Mar 21 2008 - 16:00:02) MPC83XX

i just built a new image from the current poky repo for precisely
this target, and my generated artifacts include the newer u-boot
binary image:

  -rwxr-xr-x. 2 rpjday rpjday   423964 Jul  5 06:46
u-boot-mpc8315e-rdb-v2016.03+gitAUTOINC+df61a74e68-r0.bin

rather than immediately write it to flash, i'd like to download and
test it first, and everything i've seen suggests i should be able to:

=> tftp 0x10 u-boot-mpc8315e-rdb-v2016.03+gitAUTOINC+df61a74e68-r0.bin
=> go 0x10

  well, the downloading seems to work fine:

=> tftp 0x10 u-boot-mpc8315e-rdb-v2016.03+gitAUTOINC+df61a74e68-r0.bin
Speed: 1000, full duplex
Using eTSEC0 device
TFTP from server 192.168.1.13; our IP address is 192.168.1.127
Filename 'u-boot-mpc8315e-rdb-v2016.03+gitAUTOINC+df61a74e68-r0.bin'.
Load address: 0x10
Loading: #
done
Bytes transferred = 423964 (6781c hex)
=>

so the number of bytes transferred is correct. and then bad things
happen:

=> go 0x10
## Starting application at 0x0010 ...
NIP: 0018 XER: 2000 LR: 07FC6614 REGS: 07f2fcd0 TRAP: 0700 DAR: 
MSR: 0008b002 EE: 1 PR: 0 FP: 1 ME: 1 IR/DR: 00

GPR00: 07FC6604 07F2FDC0 0080 0001 07F329E4 0010 0001 0030
GPR08: 0041 0020 0006   0200 07FF9000 09FB2000
GPR16:        
GPR24: 07F32930   0002 0010 07F2FF4C 07FF98F8 07F329E4
Call backtrace:
07FC6604 07FD767C 07FD6D10 07FD6E98 07FC6110 07FB6BF8 07FB568C
Program Check Exception
Resetting the board.


  am i missing something? downloading to the wrong address in RAM?
jumping to the wrong entry point? i'mopen to suggestions, i know i've
done this sort of thing before.

  i'm willing to start a new configure and build from scratch if
someone wants to supply a recipe. since this is the current YP powerpc
reference board, it really should work out of the box, no?

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] How to create a directory for an SD-Card mount?

2016-07-06 Thread Daniel. 
install -d ${D}/media/sd1
???

2016-07-06 11:44 GMT-03:00  :
> Hej
>
> I managed to create and install a rule that should mount a sd card to
> "/media/sd1".  To finish it, I need to create the directory "sd1" in media.
> My recipe for the rule looks like:
> ###
> SUMMARY = "the udev rules for the board"
> SECTION = "rules"
> LICENSE = "CLOSED"
>
> SRC_URI = "file://50-mmc.rules \
> "
> S = "${WORKDIR}"
>
> do_install () {
> install -d ${D}${sysconfdir}/udev/rules.d
> install -m 0644 ${WORKDIR}/50-mmc.rules
> ${D}${sysconfdir}/udev/rules.d/
> }
> ###
> How to create a dir in do_install which goes to the package?
>
> By the way:
> I was also appending fstab after this article
>
> https://communities.intel.com/thread/49251
>
> Is there an better way to uncomment/modify that one line in fstab?
>
> Regards!
>
> Stefan Jaritz
>
> 
> ESA Elektroschaltanlagen Grimma GmbH
> Broner Ring 30
> 04668 Grimma
> Telefon: +49 3437 9211 176
> Telefax: +49 3437 9211 26
> E-Mail: s.jar...@esa-grimma.de
> Internet: www.esa-grimma.de
>
>
> Geschäftsführer:
> Dipl.-Ing. Jörg Gaitzsch
> Jörg Reinker
>
> Sitz der Gesellschaft: Grimma
> Ust.-ID: DE 141784437
> Amtsgericht: Leipzig, HRB 5159
> Steuernummer: 238/108/00755
>
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
> erhalten
> haben, informieren Sie bitte sofort den Absender und löschen Sie diese
> Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
> Mail
> ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If you
> are
> not the intended recipient (or have received this e-mail in error) please
> notify the sender immediately and destroy this e-mail. Any unauthorized
> copying, disclosure or distribution of the material in this e-mail is
> strictly
> forbidden.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Do or do not. There is no try"
  Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How do I select the kernel version in Dizzy ? ( 3.10 | 3.14 | 3.17 )

2016-07-06 Thread Khem Raj 
On Wed, Jul 6, 2016 at 10:40 AM, Mark T  wrote:
> Hi,
>
> The Dizzy revision looks to support 3 kernel versions ( 3.10 | 3.14 | 3.17
> ).
>
> If I chose Dizzy 1.7.3 - how do I ensure  the 3.10 kernel is used for the
> build ?

usually you would set that in your machine conf file.

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.10%"

>
> Thanks,
>
> Mark
>
> --
> ___
> 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] How do I select the kernel version in Dizzy ? ( 3.10 | 3.14 | 3.17 )

2016-07-06 Thread Mark T 
Hi,

The Dizzy revision looks to support 3 kernel versions ( 3.10 | 3.14 | 3.17
).

If I chose Dizzy 1.7.3 - how do I ensure  the 3.10 kernel is used for the
build ?

Thanks,

Mark
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] Review request: [linux-yocto-4.1] Add the fsl-ls10xx bsp kernel meta

2016-07-06 Thread Bruce Ashfield 

On 2016-07-05 11:26 PM, guojian.z...@windriver.com wrote:

From: Guojian Zhou 

These patches will supply the fsl-ls10xx bsp scc/cfg kernel meta support
for the linux-yocto-4.1 kernel.

The FSL LS1021A-IOT platform will work well with this kernel.


merged

Bruce




The following changes since commit 0845ec79bc2fbc45efcf4c44138fd698039960c5:

   mei.cfg: Add CONFIG_INTEL_MEI_TXE=m (2016-07-03 23:58:02 -0400)

are available in the git repository at:

   https://github.com/GuojianZhou/yocto-kernel-cache yocto-4.1

for you to fetch changes up to 48a3d45777ec90a69da4aa77a28551ebec8b28a8:

   fsl-ls10xx: add kernel meta scc/cfg data (2016-07-05 03:11:23 -0700)


Guojian Zhou (1):
   fsl-ls10xx: add kernel meta scc/cfg data

  bsp/fsl-ls10xx/fsl-ls10xx-standard.scc |   8 +
  bsp/fsl-ls10xx/fsl-ls10xx.cfg  | 196 
++
  bsp/fsl-ls10xx/fsl-ls10xx.scc  |  10 ++
  3 files changed, 214 insertions(+)
  create mode 100644 bsp/fsl-ls10xx/fsl-ls10xx-standard.scc
  create mode 100644 bsp/fsl-ls10xx/fsl-ls10xx.cfg
  create mode 100644 bsp/fsl-ls10xx/fsl-ls10xx.scc



--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[yocto] How to create a directory for an SD-Card mount?

2016-07-06 Thread S . Jaritz 
Hej

I managed to create and install a rule that should mount a sd card to 
"/media/sd1".  To finish it, I need to create the directory "sd1" in 
media.
My recipe for the rule looks like:
###
SUMMARY = "the udev rules for the board"
SECTION = "rules"
LICENSE = "CLOSED"

SRC_URI = "file://50-mmc.rules \
"
S = "${WORKDIR}"

do_install () {
install -d ${D}${sysconfdir}/udev/rules.d
install -m 0644 ${WORKDIR}/50-mmc.rules 
${D}${sysconfdir}/udev/rules.d/
}
###
How to create a dir in do_install which goes to the package?

By the way:
I was also appending fstab after this article

https://communities.intel.com/thread/49251

Is there an better way to uncomment/modify that one line in fstab?

Regards!

Stefan Jaritz


ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 176
Telefax: +49 3437 9211 26
E-Mail: s.jar...@esa-grimma.de
Internet: www.esa-grimma.de


Geschäftsführer:
Dipl.-Ing. Jörg Gaitzsch
Jörg Reinker

Sitz der Gesellschaft: Grimma
Ust.-ID: DE 141784437
Amtsgericht: Leipzig, HRB 5159
Steuernummer: 238/108/00755


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
erhalten 
haben, informieren Sie bitte sofort den Absender und löschen Sie diese 
Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser 
Mail 
ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you 
are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is 
strictly 
forbidden.-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What keeps sstate from being used?

2016-07-06 Thread Gary Thomas 

On 2016-07-06 16:27, Burton, Ross wrote:


On 6 July 2016 at 15:23, Gary Thomas > wrote:

Dependency on checksum of file 
MIPS-GAS-Fix-an-ISA-override-not-lifting-ABI-restrictions.patch was removed


As this show binutils changing its SRC_URI this suggests that you did something 
in between the two runs, or those hashes
are not the relevant pair.


I could send the whole trace of how I got there, but basically
I noticed that 'patch' was being rebuilt for the target, so I
tracked that back to gcc-cross-arm which led me to binutils-cross-arm

Maybe I've done something wrong or don't totally understand the output
of the tools, but it's clear that something is a little off here as
my original build was 99% complete (only a dozen or so tasks remaining)
and when I reran it from sstate, it more or less started over.

If you have pointers on how I can diagnose this, or at least retrace it,
I'm all ears as I really want to see this work the way it's advertised
"on the tin"

Ideas/suggestions more than welcome

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] Review request: [linux-yocto-4.1] Add the fsl-ls10xx bsp kernel meta

2016-07-06 Thread guojian.zhou 
From: Guojian Zhou 

These patches will supply the fsl-ls10xx bsp scc/cfg kernel meta support
for the linux-yocto-4.1 kernel.

The FSL LS1021A-IOT platform will work well with this kernel.


The following changes since commit 0845ec79bc2fbc45efcf4c44138fd698039960c5:

  mei.cfg: Add CONFIG_INTEL_MEI_TXE=m (2016-07-03 23:58:02 -0400)

are available in the git repository at:

  https://github.com/GuojianZhou/yocto-kernel-cache yocto-4.1

for you to fetch changes up to 48a3d45777ec90a69da4aa77a28551ebec8b28a8:

  fsl-ls10xx: add kernel meta scc/cfg data (2016-07-05 03:11:23 -0700)


Guojian Zhou (1):
  fsl-ls10xx: add kernel meta scc/cfg data

 bsp/fsl-ls10xx/fsl-ls10xx-standard.scc |   8 +
 bsp/fsl-ls10xx/fsl-ls10xx.cfg  | 196 
++
 bsp/fsl-ls10xx/fsl-ls10xx.scc  |  10 ++
 3 files changed, 214 insertions(+)
 create mode 100644 bsp/fsl-ls10xx/fsl-ls10xx-standard.scc
 create mode 100644 bsp/fsl-ls10xx/fsl-ls10xx.cfg
 create mode 100644 bsp/fsl-ls10xx/fsl-ls10xx.scc
-- 
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] What keeps sstate from being used?

2016-07-06 Thread Burton, Ross 
On 6 July 2016 at 15:23, Gary Thomas  wrote:

> Dependency on checksum of file
> MIPS-GAS-Fix-an-ISA-override-not-lifting-ABI-restrictions.patch was removed
>

As this show binutils changing its SRC_URI this suggests that you did
something in between the two runs, or those hashes are not the relevant
pair.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What keeps sstate from being used?

2016-07-06 Thread Gary Thomas 

On 2016-07-06 13:51, Chris Z. wrote:

Hi,

Check:
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#shared-state-cache

"... the build system detects changes in the "inputs" to a given task by 
creating a checksum (or signature) of the
task's inputs. If the checksum changes, the system assumes the inputs have 
changed and the task needs to be rerun. For
the second question, the shared state (sstate) code tracks which tasks add which 
output to the build process "



I don't see how anything could have changed between the two runs.  Literally, I 
ran:
  % bitbake target
  ... failed with error building webkitgtk after some 6000 tasks
  % mv tmp old
  % bitbake target

I traced this down to [at least] these tasks:

gthomas@europa:p0382_2016-01-13$ bitbake-diffsigs 
sstate-cache/66/sstate:binutils-cross-arm::2.26:r0::3:66ee1a83fd248d206fd4fd9fb33ffe26_fetch.tgz.siginfo 
sstate-cache/db/sstate:binutils-cross-arm::2.26:r0::3:dbdcf77671cb88d7220531471eae70a2_fetch.tgz.siginfo

basehash changed from 366d439ed05d276413ffabf7423ebe44 to 
acc4c0150665538a4bdd394b6b6bda13
Variable SRC_URI value changed from ' 
git://sourceware.org/git/binutils-gdb.git;branch=binutils-${BINUPV}-branch;protocol=git 
file://0002-configure-widen-the-regexp-for-SH-architectures.patch 
file://0003-Point-scripts-location-to-libdir.patch 
file://0004-Only-generate-an-RPATH-entry-if-LD_RUN_PATH-is-not-e.patch 
file://0005-Explicitly-link-with-libm-on-uclibc.patch  file://0006-Use-libtool-2.4.patch 
file://0007-Add-the-armv5e-architecture-to-binutils.patch 
file://0008-don-t-let-the-distro-compiler-point-to-the-wrong-ins.patch 
file://0009-warn-for-uses-of-system-directories-when-cross-linki.patch 
file://0010-Fix-rpath-in-libtool-when-sysroot-is-enabled.patch 
file://0011-Change-default-emulation-for-mips64-linux.patch  file://0012-Add-support-for-Netlogic-XLP.patch 
file://0013-Fix-GOT-address-computations-in-initial-PLT-entries-.patch 
file://0014-Correct-nios2-_gp-address-computation.patch 
file://0015-fix-the-incorrect-assembling-for-ppc-wait-mnemonic.patch 
file://MIPS-GAS-Fix-an-ISA-override-not-lifting-ABI-restrictions.patch ' to ' 
git://sourceware.org/git/binutils-gdb.git;branch=binutils-${BINUPV}-branch;protocol=git 
file://0002-configure-widen-the-regexp-for-SH-architectures.patch 
file://0003-Point-scripts-location-to-libdir.patch 
file://0004-Only-generate-an-RPATH-entry-if-LD_RUN_PATH-is-not-e.patch 
file://0005-Explicitly-link-with-libm-on-uclibc.patch  file://0006-Use-libtool-2.4.patch 
file://0007-Add-the-armv5e-architecture-to-binutils.patch 
file://0008-don-t-let-the-distro-compiler-point-to-the-wrong-ins.patch 
file://0009-warn-for-uses-of-system-directories-when-cross-linki.patch 
file://0010-Fix-rpath-in-libtool-when-sysroot-is-enabled.patch 
file://0011-Change-default-emulation-for-mips64-linux.patch  file://0012-Add-support-for-Netlogic-XLP.patch 
file://0013-Fix-GOT-address-computations-in-initial-PLT-entries-.patch 
file://0014-Correct-nios2-_gp-address-computation.patch 
file://0015-fix-the-incorrect-assembling-for-ppc-wait-mnemonic.patch '

Dependency on checksum of file 
MIPS-GAS-Fix-an-ISA-override-not-lifting-ABI-restrictions.patch was removed

gthomas@europa:p0382_2016-01-13$ ls -l 
sstate-cache/66/sstate:binutils-cross-arm::2.26:r0::3:66ee1a83fd248d206fd4fd9fb33ffe26_fetch.tgz.siginfo 
sstate-cache/db/sstate:binutils-cross-arm::2.26:r0::3:dbdcf77671cb88d7220531471eae70a2_fetch.tgz.siginfo
-rw-rw-r-- 1 gthomas gthomas 3966 Jul  6 09:16 
sstate-cache/66/sstate:binutils-cross-arm::2.26:r0::3:66ee1a83fd248d206fd4fd9fb33ffe26_fetch.tgz.siginfo
-rw-rw-r-- 1 gthomas gthomas 3787 Jun 28 05:55 
sstate-cache/db/sstate:binutils-cross-arm::2.26:r0::3:dbdcf77671cb88d7220531471eae70a2_fetch.tgz.siginfo


Notice that the timestamp from today was 09:16.  I had updated my Poky/Yocto 
repo
at 08:04 today and then immediately made the first run (seen above).  When I 
started
the second run it was 11:57, and binutils-cross-arm was created (I think from 
setscene)
at 12:00.  So why could these hashes have caused all those other ripples (which 
took
until 14:15 to finish).

I also saw some very weird behaviour in all of this.  I noticed that my 
virtual/kernel
was totally rebuilt, but the image that's in the deploy directory came from the 
setscene
task, i.e. the first run :-(

None of this seems quite right to me and I'd really like to understand it and, 
if needed,
help figure out how to make it correct (and robust).

I'll save the total state of everything in case I can provide more data...


On Wed, Jul 6, 2016 at 12:10 PM, Gary Thomas > wrote:

I just had a [nearly] complete build failed (building webkitgtk
after some 6000 tasks).  I decided to try the 'rebuild from sstate'
by removing my 'tmp' directory and rebuild.  Bitbake proceeded to
run 2200 setscene tasks and then [it seems] started over on the
build, rebuilding the

[yocto] for MPC8315E-RDB ref board, is CONFIG_SYS_MONITOR_LEN set too low?

2016-07-06 Thread Robert P. J. Day 

  it's possible i'm just hopelessly misreading something, but i just
built (using pure defaults) an image for my MPC8315E-RDB dev kit, and
while the current board config header file
include/configs/MPC8315ERDB.h contains:

/*
 * The reserved memory
 */
#define CONFIG_SYS_MONITOR_LEN  (384 * 1024) /* Reserve 384 kB for Mon */

the actual u-boot binary constructed for this target was:

  -rwxr-xr-x. 2 rpjday rpjday 423964 Jul  5 06:46  \
u-boot-mpc8315e-rdb-v2016.03+gitAUTOINC+df61a74e68-r0.bin

  given that that same file defines:

  #if !defined(CONFIG_SYS_RAMBOOT)
#define CONFIG_ENV_IS_IN_FLASH  1
#define CONFIG_ENV_ADDR \
(CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN)

isn't that going to result in persistent u-boot environment being
saved over top of the tail end of u-boot in NOR flash?

  or am i just confused?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What keeps sstate from being used?

2016-07-06 Thread Daniel. 
Doesn't the sysroots live on tmp/sysroots? Doesn't the crosscompiler
and toolchains live in sysroots? Doesn't you need crosscompilers and
toolchains to compile everything else?

2016-07-06 8:51 GMT-03:00 Chris Z. :
> Hi,
>
> Check:
> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#shared-state-cache
>
> "... the build system detects changes in the "inputs" to a given task by
> creating a checksum (or signature) of the task's inputs. If the checksum
> changes, the system assumes the inputs have changed and the task needs to be
> rerun. For the second question, the shared state (sstate) code tracks which
> tasks add which output to the build process "
>
>
> On Wed, Jul 6, 2016 at 12:10 PM, Gary Thomas  wrote:
>>
>> I just had a [nearly] complete build failed (building webkitgtk
>> after some 6000 tasks).  I decided to try the 'rebuild from sstate'
>> by removing my 'tmp' directory and rebuild.  Bitbake proceeded to
>> run 2200 setscene tasks and then [it seems] started over on the
>> build, rebuilding the target gcc, the kernel, who knows what else...
>> These are all things that I thought had been completed before
>> during the initial ~6000 steps.
>>
>> What could be going on and why couldn't it just pick up using
>> sstate from where it left off?
>>
>> --
>> 
>> Gary Thomas |  Consulting for the
>> MLB Associates  |Embedded world
>> 
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Do or do not. There is no try"
  Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to install a service generated by update-rc.d?

2016-07-06 Thread Daniel. 
Oohhh I see, socketcan is your recipe, excuse me for my mistake.
Andres and Burton are right, you need to install that file, eg:

do_install() {
install -d "${D}${sysconfdir}/init.d/"
install -m 600 "${S}/can_if" "${D}${sysconfdir}/init.d/can_if"
}

Change the second line to point to proper can_if file :)

2016-07-06 10:11 GMT-03:00 Daniel. :
> Isn't "libsocketcan" instead of only "socketcan"!?
>
> Regards,
>
> 2016-07-06 6:45 GMT-03:00 Burton, Ross :
>>
>> On 6 July 2016 at 10:39, Anders Darander  wrote:
>>>
>>> > CONFFILES_${PN} += "${sysconfdir}/init.d/can_if"
>>>
>>> If this is the complete recipe, you never install can_if...
>>
>>
>> Which means the package is empty, which means it doesn't get generated,
>> which explains why you can't add it to an image.
>>
>> Ross
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
>
> --
> "Do or do not. There is no try"
>   Yoda Master



-- 
"Do or do not. There is no try"
  Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to install a service generated by update-rc.d?

2016-07-06 Thread Daniel. 
Isn't "libsocketcan" instead of only "socketcan"!?

Regards,

2016-07-06 6:45 GMT-03:00 Burton, Ross :
>
> On 6 July 2016 at 10:39, Anders Darander  wrote:
>>
>> > CONFFILES_${PN} += "${sysconfdir}/init.d/can_if"
>>
>> If this is the complete recipe, you never install can_if...
>
>
> Which means the package is empty, which means it doesn't get generated,
> which explains why you can't add it to an image.
>
> Ross
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Do or do not. There is no try"
  Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What keeps sstate from being used?

2016-07-06 Thread Chris Z. 
Hi,

Check:
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#shared-state-cache

"... the build system detects changes in the "inputs" to a given task by
creating a checksum (or signature) of the task's inputs. If the checksum
changes, the system assumes the inputs have changed and the task needs to
be rerun. For the second question, the shared state (sstate) code tracks
which tasks add which output to the build process "


On Wed, Jul 6, 2016 at 12:10 PM, Gary Thomas  wrote:

> I just had a [nearly] complete build failed (building webkitgtk
> after some 6000 tasks).  I decided to try the 'rebuild from sstate'
> by removing my 'tmp' directory and rebuild.  Bitbake proceeded to
> run 2200 setscene tasks and then [it seems] started over on the
> build, rebuilding the target gcc, the kernel, who knows what else...
> These are all things that I thought had been completed before
> during the initial ~6000 steps.
>
> What could be going on and why couldn't it just pick up using
> sstate from where it left off?
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> 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] What keeps sstate from being used?

2016-07-06 Thread Gary Thomas 

I just had a [nearly] complete build failed (building webkitgtk
after some 6000 tasks).  I decided to try the 'rebuild from sstate'
by removing my 'tmp' directory and rebuild.  Bitbake proceeded to
run 2200 setscene tasks and then [it seems] started over on the
build, rebuilding the target gcc, the kernel, who knows what else...
These are all things that I thought had been completed before
during the initial ~6000 steps.

What could be going on and why couldn't it just pick up using
sstate from where it left off?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to install a service generated by update-rc.d?

2016-07-06 Thread Burton, Ross 
On 6 July 2016 at 10:39, Anders Darander  wrote:

> > CONFFILES_${PN} += "${sysconfdir}/init.d/can_if"
>
> If this is the complete recipe, you never install can_if...
>

Which means the package is empty, which means it doesn't get generated,
which explains why you can't add it to an image.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to install a service generated by update-rc.d?

2016-07-06 Thread Anders Darander 
* s.jar...@esa-grimma.de  [160706 11:22]:
> I want to start a service that generates Sockets for the CAN Modules. 
> Manually configuring the system is no problem, but I like to have it done 
> by yocto. Below I give the code of my recipe (socketcan.bb):

> SUMMARY = "the config for the can socket interface"
> SECTION = "CAN"
> LICENSE = "CLOSED"

> inherit update-rc.d

> RDEPENDS_${PN} = "initscripts"

> DEPENDS = "iproute2"

> SRC_URI = "file://can_if"

> INITSCRIPT_PARAMS = "start 02 2 3 4 5 . stop 01 0 1 6 ."
> INITSCRIPT_NAME = "can_if"

> CONFFILES_${PN} += "${sysconfdir}/init.d/can_if"

If this is the complete recipe, you never install can_if...

Cheers,
Anders

-- 
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to install a service generated by update-rc.d?

2016-07-06 Thread S . Jaritz 
Hej,

I want to start a service that generates Sockets for the CAN Modules. 
Manually configuring the system is no problem, but I like to have it done 
by yocto. Below I give the code of my recipe (socketcan.bb):
#
SUMMARY = "the config for the can socket interface"
SECTION = "CAN"
LICENSE = "CLOSED"

inherit update-rc.d

RDEPENDS_${PN} = "initscripts"

DEPENDS = "iproute2"

SRC_URI = "file://can_if"

INITSCRIPT_PARAMS = "start 02 2 3 4 5 . stop 01 0 1 6 ."
INITSCRIPT_NAME = "can_if"

CONFFILES_${PN} += "${sysconfdir}/init.d/can_if"
#
It has one file bash script "can_if". This contains the up and down 
commands. I want to generate at the /etc/rc*** Dirs the 
S02can_if/K01can_if links.
Building the recipe via "bitbake socketcan" works fine.
When generating the rootfs via "bitbake core-image-minimal" I got the 
following error:
#
ERROR: core-image-minimal-1.0-r0 do_rootfs: Unable to install packages. 
Command 
'/home/user/myTC/poky/build/tmp/sysroots/x86_64-linux/usr/bin/apt-get 
install --force-yes --allow-unauthenticated python-modules meteocontrol 
webmaint libg3logger0 packagegroup-core-ssh-openssh apt vim curl pmdb 
redis libcsv3 myuser boost packagegroup-core-boot libredox0 libemd2 
python-django python libev4 can-utils run-postinsts util-linux dpkg 
mymodules grep libhiredis0.13 libmydbus0 libconfig iproute2 p7zip 
socketcan' returned 100:
Reading package lists...
Building dependency tree...
Reading state information...
Package socketcan is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'socketcan' has no installation candidate

ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: 
/home/user/myTC/poky/build/tmp/work/sama5d3xek-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.14597
ERROR: Task 9 
(/home/user/myTC/poky/meta/recipes-core/images/core-image-minimal.bb, 
do_rootfs) failed with exit code '1'
#

Any idea how to fix that?

Regards!

Stefan Jaritz


ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 176
Telefax: +49 3437 9211 26
E-Mail: s.jar...@esa-grimma.de
Internet: www.esa-grimma.de


Geschäftsführer:
Dipl.-Ing. Jörg Gaitzsch
Jörg Reinker

Sitz der Gesellschaft: Grimma
Ust.-ID: DE 141784437
Amtsgericht: Leipzig, HRB 5159
Steuernummer: 238/108/00755


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
erhalten 
haben, informieren Sie bitte sofort den Absender und löschen Sie diese 
Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser 
Mail 
ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you 
are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is 
strictly 
forbidden.-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-qt4][PATCH] qt4-native: disable precompiled headers

2016-07-06 Thread Andreas Oberritter 
Using precompiled headers may lead to errors in parallel builds:

| In file included from :0:0:
| /usr/include/stdc-predef.h:59:1: error: one or more PCH files were found, but 
they were invalid
|  #endif
|  ^
| /usr/include/stdc-predef.h:59:1: error: use -Winvalid-pch for more information
| /usr/include/stdc-predef.h:59:1: fatal error: 
.pch/release-shared-emb-x86_64/QtCore: No such file or directory

Upstream bug report:
http://lists.qt-project.org/pipermail/development/2014-July/017689.html

Precompiled headers have been disabled for target builds from
the beginning (commit 46bdf066 in OE-Core).

Signed-off-by: Andreas Oberritter 
---
 recipes-qt4/qt4/qt4-native.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/recipes-qt4/qt4/qt4-native.inc b/recipes-qt4/qt4/qt4-native.inc
index 58acac8..dac267b 100644
--- a/recipes-qt4/qt4/qt4-native.inc
+++ b/recipes-qt4/qt4/qt4-native.inc
@@ -49,6 +49,7 @@ EXTRA_OECONF = "-prefix ${prefix} \
 -embedded -no-freetype -no-glib -no-iconv \
 -exceptions -xmlpatterns \
 -qt3support \
+-no-pch \
 -no-fast -silent -no-rpath"
 
 # yank default -e, otherwise we get the following error:
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto