date:20180518

Re: [linux-yocto] : [yocto-4.12]: intel-socfpga: get latest patches from sdk for remote system feature

2018-05-18 Thread Bruce Ashfield


On 2018-05-18 9:16 PM, Li, Meng wrote:

Hi Bruce,

I guess you intent to merge these patches into standard/base after updating 
kernel to 4.12.24. is it right?


Correct. I'm waiting for my round of -stable updates to be confirmed
before I send more changes. I expect these can merge over the weekend.

Bruce



Thanks,
Limeng


-Original Message-
From: linux-yocto-boun...@yoctoproject.org [mailto:linux-yocto-
boun...@yoctoproject.org] On Behalf Of meng...@windriver.com
Sent: Wednesday, May 16, 2018 5:15 PM
To: Ashfield, Bruce
Cc: linux-yocto@yoctoproject.org
Subject: [linux-yocto] : [yocto-4.12]: intel-socfpga: get latest patches from
sdk for remote system feature

From: Limeng 


Hi Bruce,

Now, there are some update for intel-socfpga, Stratix10 SoC from SDK.
These patches are used to implement remote system update feature.

Please help to meger below patches into linux-yocto, kernel 4.12, branch is
standard/base

0001-FogBugz-251539-1-Add-Altera-Quad-SPI-Driver.patch
0002-FogBugz-251539-2-dts-Add-Altera-Quad-SPI-Driver-Devi.patch
0003-arm64-dts-stratix10-Change-pad-skew-values-for-EMAC0.patch
0004-FogBugz-554812-fpga-stratix10-unitialized-data.patch
0005-mtd-spi-nor-cadence-quadspi-Fix-page-fault-kernel-pa.patch
0006-FogBugz-549288-1-misc-Stratix10-Protected-register-a.patch
0007-FogBugz-549288-2-Add-Stratix10-ECC-Manager-binding.patch
0008-FogBugz-549288-3-edac-Add-support-for-Stratix10-SDRA.patch
0009-FogBugz-549288-4-dts-add-Stratix10-sdram-ecc.patch
0010-FogBugz-554835-1-Add-Stratix-10-SoC-RSU-Driver.patch
0011-FogBugz-554835-3-Intel-RSU-binding-documentation.patch
0012-FogBugz-514234-arm64-dts-stratix10-Add-PL330-DMA-to-.patch
0013-intel-socfpga-dts-add-rsu-node-to-enable-rsu-driver.patch
0014-intel-socfpga-dts-improve-qspi-node-for-rsu-feature.patch

Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt|   42
Documentation/devicetree/bindings/firmware/intel,stratix10-rsu.txt |   28
Documentation/devicetree/bindings/mtd/altera_quadspi.txt   |   42
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi  |   37
arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts |6
drivers/edac/Kconfig   |2
drivers/edac/altera_edac.c |  455 ++
drivers/edac/altera_edac.h |  126 +
drivers/fpga/stratix10-soc.c   |1
drivers/misc/Kconfig   |   17
drivers/misc/Makefile  |1
drivers/misc/intel-rsu.c   |  377 +
drivers/misc/intel-service.c   |   51
drivers/misc/intel-smc.h   |  105 +
drivers/mtd/devices/Kconfig|7
drivers/mtd/devices/Makefile   |2
drivers/mtd/devices/altera_quadspi.c   |  667 
++
drivers/mtd/spi-nor/cadence-quadspi.c  |   19
include/linux/intel-service-client.h   |   15
19 files changed, 1962 insertions(+), 38 deletions(-)


thanks,
Limeng


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


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

Re: [linux-yocto] : [yocto-4.12]: intel-socfpga: get latest patches from sdk for remote system feature

2018-05-18 Thread Li, Meng

Hi Bruce,

I guess you intent to merge these patches into standard/base after updating 
kernel to 4.12.24. is it right?

Thanks,
Limeng

> -Original Message-
> From: linux-yocto-boun...@yoctoproject.org [mailto:linux-yocto-
> boun...@yoctoproject.org] On Behalf Of meng...@windriver.com
> Sent: Wednesday, May 16, 2018 5:15 PM
> To: Ashfield, Bruce
> Cc: linux-yocto@yoctoproject.org
> Subject: [linux-yocto] : [yocto-4.12]: intel-socfpga: get latest patches from
> sdk for remote system feature
> 
> From: Limeng 
> 
> 
> Hi Bruce,
> 
> Now, there are some update for intel-socfpga, Stratix10 SoC from SDK.
> These patches are used to implement remote system update feature.
> 
> Please help to meger below patches into linux-yocto, kernel 4.12, branch is
> standard/base
> 
> 0001-FogBugz-251539-1-Add-Altera-Quad-SPI-Driver.patch
> 0002-FogBugz-251539-2-dts-Add-Altera-Quad-SPI-Driver-Devi.patch
> 0003-arm64-dts-stratix10-Change-pad-skew-values-for-EMAC0.patch
> 0004-FogBugz-554812-fpga-stratix10-unitialized-data.patch
> 0005-mtd-spi-nor-cadence-quadspi-Fix-page-fault-kernel-pa.patch
> 0006-FogBugz-549288-1-misc-Stratix10-Protected-register-a.patch
> 0007-FogBugz-549288-2-Add-Stratix10-ECC-Manager-binding.patch
> 0008-FogBugz-549288-3-edac-Add-support-for-Stratix10-SDRA.patch
> 0009-FogBugz-549288-4-dts-add-Stratix10-sdram-ecc.patch
> 0010-FogBugz-554835-1-Add-Stratix-10-SoC-RSU-Driver.patch
> 0011-FogBugz-554835-3-Intel-RSU-binding-documentation.patch
> 0012-FogBugz-514234-arm64-dts-stratix10-Add-PL330-DMA-to-.patch
> 0013-intel-socfpga-dts-add-rsu-node-to-enable-rsu-driver.patch
> 0014-intel-socfpga-dts-improve-qspi-node-for-rsu-feature.patch
> 
> Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt|   42
> Documentation/devicetree/bindings/firmware/intel,stratix10-rsu.txt |   28
> Documentation/devicetree/bindings/mtd/altera_quadspi.txt   |   42
> arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi  |   37
> arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts |6
> drivers/edac/Kconfig   |2
> drivers/edac/altera_edac.c |  455 
> ++
> drivers/edac/altera_edac.h |  126 +
> drivers/fpga/stratix10-soc.c   |1
> drivers/misc/Kconfig   |   17
> drivers/misc/Makefile  |1
> drivers/misc/intel-rsu.c   |  377 
> +
> drivers/misc/intel-service.c   |   51
> drivers/misc/intel-smc.h   |  105 +
> drivers/mtd/devices/Kconfig|7
> drivers/mtd/devices/Makefile   |2
> drivers/mtd/devices/altera_quadspi.c   |  667 
> ++
> drivers/mtd/spi-nor/cadence-quadspi.c  |   19
> include/linux/intel-service-client.h   |   15
> 19 files changed, 1962 insertions(+), 38 deletions(-)
> 
> 
> thanks,
> Limeng
> 
> 
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] Using yocto as a build system

2018-05-18 Thread mamta0925

Thanks Alex and Khem. There are no specific open source packages we want to 
build. We want a build infrastructure which we can pass on to our internal dev 
teams, so they can build packages themselves 

Sent from my iPhone

> On May 18, 2018, at 11:15 AM, Khem Raj  wrote:
> 
> 
> 
>> On 5/18/18 7:12 AM, Alexander Kanavin wrote:
>>> On 05/18/2018 12:06 AM, mamta0...@yahoo.com wrote:
>>> Apologies if these are basic questions but thought this will be the
>>> best place to find answers to the point
>>> 
>>> So our requirement is to build open source packages in Linux, windows
>>> and Mac on a build system. Currently we have an internal build system
>>> which is quite cumbersome to manage. Hence we are looking for outside
>>> options
>>> 
>>> Given our situation, is Yocto our best solution? Does it even provide
>>> for building windows and Mac open source packages?
> 
> I would suggest to look into something like cmake, if you do not build 
> platforms. it might be good for building apps across platforms
> 
>> Generally speaking, no. Yocto is aimed at embedded Linux use cases.
>> If you elaborate about your product and what are the 'open source packages', 
>> maybe someone can suggest other options.
>> Alex

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

Re: [yocto] Using yocto as a build system

2018-05-18 Thread Khem Raj




On 5/18/18 7:12 AM, Alexander Kanavin wrote:

On 05/18/2018 12:06 AM, mamta0...@yahoo.com wrote:


Apologies if these are basic questions but thought this will be the
best place to find answers to the point

So our requirement is to build open source packages in Linux, windows
and Mac on a build system. Currently we have an internal build system
which is quite cumbersome to manage. Hence we are looking for outside
options

Given our situation, is Yocto our best solution? Does it even provide
for building windows and Mac open source packages?


I would suggest to look into something like cmake, if you do not build 
platforms. it might be good for building apps across platforms




Generally speaking, no. Yocto is aimed at embedded Linux use cases.

If you elaborate about your product and what are the 'open source 
packages', maybe someone can suggest other options.


Alex

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

Re: [yocto] TEST_IMAGE issues

2018-05-18 Thread Scott Rifenbark

There is nothing in the docs that says that an image must contain "-image"
or "image-".

Maybe someone can tell me if we should have that.

Scott

On Fri, May 18, 2018 at 4:44 AM, Mirza Krak  wrote:

> Hi all!
>
> Found something interesting (perhaps).
>
> So we where thinking about enabling some of the OE QA tests that that
> are part of poky.
>
> Seemed pretty straight forward. Added following to local.conf:
>
> INHERIT += "testimage"
>
> Build my image and then tried to run:
>
> bitbake -c testimage 
>
> To my despair it did not work and instead produced an error. Tried
> both on "pyro" and "rocko" branches. The error was:
>
> | runqemu started, pid is 45087
> | NOTE: runqemu started, pid is 45087
> | waiting at most 60 seconds for qemu pid
> | NOTE: waiting at most 60 seconds for qemu pid
> | runqemu exited with code 1
> | NOTE: runqemu exited with code 1
> | Output from runqemu:
> | runqemu - ERROR - Unknown path arg
> /tmp/deploy/images/qemux86-64/genivi-dev-platform-qemux86-64.ext4
> | runqemu - ERROR - Try 'runqemu help' on how to use it
>
> Some (a lot) digging later, I finally figured out that error occurs
> because the image name does not contain "-image" or "image-". runqemu
> is not able to parse it and throws a "unknown" argument error (not
> that obvious from the print).
>
> I realize that this is a "problem" in runqemu and not much to do about
> it with a large refactoring job on the runqemu application.
>
> But I am looking for suggesting for an appropriate workaround, other
> then renaming the image which I have verified works.
>
> Does it say somewhere in the docs that all image files must contain
> "-image" or "image-" in their name? If that is the case it makes sense
> to rename it, but trying to avoid that.
>
> --
> Med Vänliga Hälsningar / Best Regards
>
> Mirza Krak
> email: mi...@mkrak.org
> web: https://mkrak.org
> --
> ___
> 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] Using yocto as a build system

2018-05-18 Thread Alexander Kanavin


On 05/18/2018 12:06 AM, mamta0...@yahoo.com wrote:


Apologies if these are basic questions but thought this will be the
best place to find answers to the point

So our requirement is to build open source packages in Linux, windows
and Mac on a build system. Currently we have an internal build system
which is quite cumbersome to manage. Hence we are looking for outside
options

Given our situation, is Yocto our best solution? Does it even provide
for building windows and Mac open source packages?


Generally speaking, no. Yocto is aimed at embedded Linux use cases.

If you elaborate about your product and what are the 'open source 
packages', maybe someone can suggest other options.


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

[yocto] TEST_IMAGE issues

2018-05-18 Thread Mirza Krak

Hi all!

Found something interesting (perhaps).

So we where thinking about enabling some of the OE QA tests that that
are part of poky.

Seemed pretty straight forward. Added following to local.conf:

INHERIT += "testimage"

Build my image and then tried to run:

bitbake -c testimage 

To my despair it did not work and instead produced an error. Tried
both on "pyro" and "rocko" branches. The error was:

| runqemu started, pid is 45087
| NOTE: runqemu started, pid is 45087
| waiting at most 60 seconds for qemu pid
| NOTE: waiting at most 60 seconds for qemu pid
| runqemu exited with code 1
| NOTE: runqemu exited with code 1
| Output from runqemu:
| runqemu - ERROR - Unknown path arg
/tmp/deploy/images/qemux86-64/genivi-dev-platform-qemux86-64.ext4
| runqemu - ERROR - Try 'runqemu help' on how to use it

Some (a lot) digging later, I finally figured out that error occurs
because the image name does not contain "-image" or "image-". runqemu
is not able to parse it and throws a "unknown" argument error (not
that obvious from the print).

I realize that this is a "problem" in runqemu and not much to do about
it with a large refactoring job on the runqemu application.

But I am looking for suggesting for an appropriate workaround, other
then renaming the image which I have verified works.

Does it say somewhere in the docs that all image files must contain
"-image" or "image-" in their name? If that is the case it makes sense
to rename it, but trying to avoid that.

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
email: mi...@mkrak.org
web: https://mkrak.org
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] LIC_FILES_CHKSUM error

2018-05-18 Thread Bruce Ashfield


On 2018-05-18 1:26 AM, He Zhe wrote:

Hi Bruce,

We're experiencing the following error for linux-yocto-dev.

ERROR: linux-yocto-dev-4.16-rc++gitAUTOINC+7c8016b5a8_731190752b-r0 
do_populate_lic: QA Issue: linux-yocto-dev: The LIC_FILES_CHKSUM does not match 
for file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7linux-yocto-dev: The new 
md5 checksum is bbea815ee2795b2f4230826c0c6b8814

This is because mainline COPYING has changed but LIC_FILES_CHKSUM in 
http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/linux/linux-yocto.inc
 have not been updated. As linux-yocto.inc would impact linux-yocto, 
linux-yocto-dev and linux-yocto-VERSION, can we overwrite LIC_FILES_CHKSUM only 
in meta/recipes-kernel/linux/linux-yocto-dev.bb?


I did a patch for this last week, but haven't sent it to the list yet,
since I have one more set of gcc issues to resolve

I'll send it along later today, but you can find it on my zedd/kernel
poky-contrib branch:

yow-bashfiel-d4 [/home/bruc...poky/build]> git show 84928b372cae
commit 84928b372caead127670262e6f8395933140b173
Author: Bruce Ashfield 
Date:   Wed May 9 11:01:35 2018 -0400

linux-yocto-dev: update to v4.17+

Updating the -dev kernel to v4.17+. We also tweak the License checksum
in the -dev kernel since SPDX headers have been inserted upstream and
that has changed the hash value.

Signed-off-by: Bruce Ashfield 

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
b/meta/recipes-kernel/linux/linux-yocto-dev.bb





Thanks,
Zhe




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

Re: [yocto] Display 1920x1080 double LVDS channel problem

2018-05-18 Thread Belisko Marek

Hello,

On Fri, May 18, 2018 at 11:41 AM Enrico Bonomi 
wrote:

> Hi,

> I'm working with an imx6duallite with Yocto 1.7.3. I want to drive a
1920x1080 display with 2 LVDS channels but i came across a problem.
Pictures are shown correctly on display but they have wrong colors (for
example a blue bar during psplash is shown pink).
This is not yocto specific question. I think you can get more help on
meta-freesc...@yoctoproject.org

> my .dts has the following ldb:

>  {
> ipu_id = <1>;
> disp_id = <0>;
> ext_ref = <1>;
> mode = "sep0";
> sec_ipu_id = <1>;
> sec_disp_id = <1>;
> status = "okay";
> split-mode;

> lvds-channel@0{
> fsl,data-mapping = "spwg";
> fsl,data-width = <24>;
> crtc = "ipu1-di0";
> status = "okay";
> };

> lvds-channel@1{
> fsl,data-mapping = "spwg";
> fsl,data-width = <24>;
> crtc = "ipu1-di0";
> status = "okay";
> };



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

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Display 1920x1080 double LVDS channel problem

2018-05-18 Thread Enrico Bonomi

Hi,

I'm working with an imx6duallite with Yocto 1.7.3. I want to drive a
1920x1080 display with 2 LVDS channels but i came across a problem.
Pictures are shown correctly on display but they have wrong colors (for
example a blue bar during psplash is shown pink).

my .dts has the following ldb:

 {
ipu_id = <1>;
disp_id = <0>;
ext_ref = <1>;
mode = "sep0";
sec_ipu_id = <1>;
sec_disp_id = <1>;
status = "okay";
split-mode;

lvds-channel@0{
fsl,data-mapping = "spwg";
fsl,data-width = <24>;
crtc = "ipu1-di0";
status = "okay";
};

lvds-channel@1{
fsl,data-mapping = "spwg";
fsl,data-width = <24>;
crtc = "ipu1-di0";
status = "okay";
};
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Enabling the recipe from menuconfig

2018-05-18 Thread Andrea Galbusera

On Fri, May 18, 2018 at 6:14 AM, chandrasekhar  wrote:
> you want to see in kernel menuconfig??
>
>
>
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> On Behalf Of Ugesh Reddy
> Sent: Friday, May 18, 2018 7:52 AM
> To: 'Yocto-mailing-list'; chandrasekhar
> Subject: Re: [yocto] Enabling the recipe from menuconfig
>
>
>
> Hi,
>
> Thanks for the response,
>
>
>
>  This will add the recipe as a part of image but I want to build and add the
> recipe when it has been selected from the menuconfig.
>
> How to make visible the recipe in menuconfig?

Unlike other distribution build systems, Yocto/OE don't provide any
menuconfig based configuration interface for selecting which package
to include in images you build. There is indeed support for accessing
menuconfig interfaces provided by specific recipes like the linux
kernel. If you need a high level recipe selection tool, your best bet
is probably to look at Toaster.

>
> On Thursday, 17 May, 2018, 9:32:15 AM IST, chandrasekhar
>  wrote:
>
>
>
>
>
> Hi
>
> You can use
>
> IMAGE_INSTALL += "Package Name/Recipes name"
>
>
>
> Regards,
>
> Chandrasekhar
>
>
>
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> On Behalf Of Ugesh Reddy
> Sent: Wednesday, May 16, 2018 9:57 PM
> To: Yocto-mailing-list
> Subject: [yocto] Enabling the recipe from menuconfig
>
>
>
> Hello Team,
>
>
>
>  I have a list of recipes in my custom layer. The recipes in this layer
> shall be enabled/selected through the menuconfig, once it is enabled then it
> shall be the part of image. is it possible to achieve it ? do we have any
> references?
>
>
>
> Regards,
>
> Ugesh
>
>
> --
> ___
> 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] apt-get error

2018-05-18 Thread Rahul jangra

-- Forwarded message --
From: Rahul jangra 
Date: Thu, 17 May 2018 10:29:16 +0530
Subject: Re: [yocto] apt-get error
To: Anuj Mittal 

when I am creating core-image-minimal it easy to build up
but when I am trying to create core-image-full-cmdline he is getting an error

ore-image-full-cmdline-1.0-r0 do_rootfs: Unable to install packages.
Command 
'/home/debianstretch/rpi/build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/apt-get
 install --force-yes --allow-unauthenticated dpkg base-passwd
hello-mender packagegroup-core-ssh-openssh psplash-raspberrypi
run-postinsts shadow packagegroup-core-boot kernel-devicetree
kernel-image-4.14.39 mender packagegroup-core-full-cmdline apt'
returned 100:
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 packagegroup-core-full-cmdline : Depends:
packagegroup-core-full-cmdline-initscripts but it is not going to be
installed
E: Unable to correct problems, you have held broken packages.

ERROR: core-image-full-cmdline-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/home/debianstretch/rpi/build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.105216
ERROR: Task 
(/home/debianstretch/poky-rocko/meta/recipes-extended/images/core-image-full-cmdline.bb:do_rootfs)
failed with exit code '1'





On 5/17/18, Rahul jangra  wrote:
> I am working on mender yocto project of raspberry pi
> and I am sharing my details
> my local.conf file setting
> # Local configuration for meta-RPI images
> # Yocto Project 2.4 Poky distribution [rocko] branch
> # This is a sysvinit system
>
> LICENSE_FLAGS_WHITELIST = "commercial"
>
> DISTRO_FEATURES = "ext2 pam opengl usbhost ${DISTRO_FEATURES_LIBC}"
>
> DISTRO_FEATURES_BACKFILL_CONSIDERED += "pulseaudio"
>
> PREFERRED_PROVIDER_jpeg = "libjpeg-turbo"
> PREFERRED_PROVIDER_jpeg-native = "libjpeg-turbo-native"
>
> PREFERRED_PROVIDER_udev = "eudev"
> #VIRTUAL-RUNTIME_init_manager = "sysvinit"
>
> MACHINE_FEATURES_remove = "apm"
>
> IMAGE_FSTYPES = "tar.xz"
>
> # override the meta-raspberrypi default 4.9 kernel
> PREFERRED_VERSION_linux-raspberrypi = "4.14.%"
>
> # Choose the board you are building for
> #MACHINE="raspberrypi"
> #MACHINE="raspberrypi0"
> #MACHINE="raspberrypi0-wifi"
> #MACHINE="raspberrypi2"
> #MACHINE = "raspberrypi3"
> #MACHINE="raspberrypi-cm"
> #MACHINE="raspberrypi-cm3"
>
> # Choices are Image or zImage if NOT using u-boot (no u-boot is the
> default)
> # Choices are uImage or zImage if using u-boot, though if you choose zImage
> # with u-boot you will also have to change the boot script boot command
> #KERNEL_IMAGETYPE = "zImage"
>
> ENABLE_UART="1"
>
> DL_DIR = "${HOME}/oe-sources"
>
> #SSTATE_DIR = "/oe4/rpi/sstate-cache"
>
> #TMPDIR = "/oe4/rpi/tmp-rocko"
>
> DISTRO = "poky"
>
> #PACKAGE_CLASSES = "package_ipk"
> PACKAGE_CLASSES = "package_deb"
>
> # i686 or x86_64
> SDKMACHINE = "x86_64"
>
> EXTRA_IMAGE_FEATURES = "debug-tweaks"
> INHERIT += "extrausers"
> EXTRA_USERS_PARAMS = "usermod -P nsspl@123 root; "
>
> USER_CLASSES = "image-mklibs image-prelink"
>
> PATCHRESOLVE = "noop"
>
> RM_OLD_IMAGE = "1"
>
> INHERIT += "rm_work"
>
> ONF_VERSION = "1"
>
> # The name of the disk image and Artifact that will be built.
> # This is what the device will report that it is running, and
> different updates must have different names
> # because Mender will skip installation of an Artifact if it is
> already installed.
> MENDER_ARTIFACT_NAME = "release-1"
>
> INHERIT += "mender-full"
>
> # A MACHINE integrated with Mender.
> # raspberrypi3, beaglebone, and vexpress-qemu are reference devices
> MACHINE = "raspberrypi3"
>
> # For Raspberry Pi, uncomment the following block:
> RPI_USE_U_BOOT = "1"
> #MENDER_PARTITION_ALIGNMENT_KB = "4096"
> #MENDER_BOOT_PART_SIZE_MB = "40"
> MENDER_PARTITION_ALIGNMENT_KB = "8192"
> MENDER_BOOT_PART_SIZE_MB = "80"
> MENDER_DATA_PART_SIZE_MB = "128"
> MENDER_STORAGE_TOTAL_SIZE_MB = "5000"
> do_image_sdimg[depends] += " bcm2835-bootfiles:do_populate_sysroot"
> IMAGE_INSTALL_append = " kernel-image kernel-devicetree"
> IMAGE_FSTYPES_remove += " rpi-sdimg"
>
> # Lines below not needed for Yocto Rocko (2.4) or newer.
> # IMAGE_BOOT_FILES_append = " boot.scr u-boot.bin;${SDIMG_KERNELIMAGE}"
> KERNEL_IMAGETYPE = "uImage"
>
> # The version of Mender to build. This needs to match an existing
> recipe in the meta-mender repository.
> #
> # Given your Yocto Project version, see which versions of Mender you
> can currently build here:
> #

Re: [yocto] Enabling the recipe from menuconfig

2018-05-18 Thread chandrasekhar

I think you can use Toaster for that which has a web interface you can select 
packages/receipes

 

Regards,

Chandrasekhar

 

From: Ugesh Reddy [mailto:kumar.ugesh...@yahoo.com] 
Sent: Friday, May 18, 2018 11:15 AM
To: chandrasek...@evolute.in; 'Yocto-mailing-list'
Subject: RE: [yocto] Enabling the recipe from menuconfig

 

The similar kind is required for my custom layer. So that I could enable the 
receipt from the menu config

Sent from Yahoo   Mail on 
Android

 

On Fri, 18 May 2018 at 9:44 a.m., chandrasekhar

 wrote:

you want to see in kernel menuconfig??

 

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Ugesh Reddy
Sent: Friday, May 18, 2018 7:52 AM
To: 'Yocto-mailing-list'; chandrasekhar
Subject: Re: [yocto] Enabling the recipe from menuconfig

 

Hi,

Thanks for the response,

 

 This will add the recipe as a part of image but I want to build and add the 
recipe when it has been selected from the menuconfig.

How to make visible the recipe in menuconfig?

On Thursday, 17 May, 2018, 9:32:15 AM IST, chandrasekhar 
 wrote: 

 

 

Hi 

You can use 

IMAGE_INSTALL += "Package Name/Recipes name"

 

Regards,

Chandrasekhar

 

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Ugesh Reddy
Sent: Wednesday, May 16, 2018 9:57 PM
To: Yocto-mailing-list
Subject: [yocto] Enabling the recipe from menuconfig

 

Hello Team,

 

 I have a list of recipes in my custom layer. The recipes in this layer shall 
be enabled/selected through the menuconfig, once it is enabled then it shall be 
the part of image. is it possible to achieve it ? do we have any references? 

 

Regards,

Ugesh

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

[yocto] [meta-openstack][PATCH] python-requests: remove PREFERRED_VERSION limit

2018-05-18 Thread mingli.yu

From: Mingli Yu 

* Previously, add PREFERRED_VERSION for python-requests
  as we want to use version >=2.10.0 and the full commit
  message as below:

  commit 185eccef8964632f5b255265a0a8e59fe5858397
  Author: Mark Asselstine 
  Date:   Fri Jan 20 16:59:31 2017 -0500

python-requests: use version from meta-openembedded

We want to use a version >=2.10.0 as required by python-keystoneauth1
so set a PREF so we don't get the older version found in
meta-virtualization and used by docker.

Signed-off-by: Mark Asselstine 
Signed-off-by: Bruce Ashfield 

* Now meta-oe upreved python-requests to 2.18.4, remove
  PREFERRED_VERSION limit to avoid bitbake messages like:

  "NOTE: preferred version 2.13.0 of python-requests not available"

Signed-off-by: Mingli Yu 
---
 meta-openstack/conf/layer.conf | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta-openstack/conf/layer.conf b/meta-openstack/conf/layer.conf
index 55df509..c376d58 100644
--- a/meta-openstack/conf/layer.conf
+++ b/meta-openstack/conf/layer.conf
@@ -31,7 +31,6 @@ PREFERRED_VERSION_python-futures = "3.0.3%"
 PREFERRED_VERSION_python-django = "1.8.6"
 PREFERRED_VERSION_python-netaddr = "0.7.19"
 PREFERRED_VERSION_python-sqlalchemy = "1.0.16"
-PREFERRED_VERSION_python-requests = "2.13.0"
 PREFERRED_VERSION_python-eventlet = "0.20.0"
 PREFERRED_VERSION_python-warlock = "1.2.0"
 PREFERRED_VERSION_python-jsonschema = "2.6.0"
-- 
2.7.4

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

Re: [linux-yocto] : [yocto-4.12]: intel-socfpga: get latest patches from sdk for remote system feature

Re: [linux-yocto] : [yocto-4.12]: intel-socfpga: get latest patches from sdk for remote system feature

Re: [yocto] Using yocto as a build system

Re: [yocto] Using yocto as a build system

Re: [yocto] TEST_IMAGE issues

Re: [yocto] Using yocto as a build system

[yocto] TEST_IMAGE issues

Re: [linux-yocto] LIC_FILES_CHKSUM error

Re: [yocto] Display 1920x1080 double LVDS channel problem

[yocto] Display 1920x1080 double LVDS channel problem

Re: [yocto] Enabling the recipe from menuconfig

[yocto] apt-get error

Re: [yocto] Enabling the recipe from menuconfig

[yocto] [meta-openstack][PATCH] python-requests: remove PREFERRED_VERSION limit

14 matches

Site Navigation

Mail list logo

Footer information