Re: [yocto] General Question: Device specific value store

[Andrea Adami]

On Wed, Jun 26, 2019 at 12:03 PM Morné Lamprecht  wrote:
>
> On Tue, Jun 25, 2019 at 09:25:13AM -0400, Larry Brown wrote:
> >>> I wonder, if there are best practices, how to protect the data from 
> >>> getting
> >>> corrupted (intentionally by an attacker or by accident through ... flash
> >>> corruption or whatever).
>
> Ideally your hardware should have some sort of hw-based secure key storage, 
> and
> use that to support some sort of secure boot scheme. You can then implement a
> chain of trust, allowing you to securely verify a hash signature of the data
> during bootup, to ensure that it hadn't been tampered with or gotten 
> corrupted.
>
> Atmel / Microchip, for example, offers a range of Crypto Authentication ICs 
> that
> could be added to your hardware to support this, if you hardware didn't have
> built in support for something like this. Their offering also included tools 
> to
> securely inject the data into the secure ICs during manufacturing, or
> alternatively, you could write your own tool to interface with their API.
>
> - Morné
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


Hi,
almost all flash have a non-volatile storage.
It was OTP on old NOR, now there are more flavors: your board appears
to have eMMC and so OTP/MTP should be supported by the mmc stack.
Check out this link:
https://www.synopsys.com/designware-ip/technical-bulletin/memory-options.html

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

Re: [yocto] [OE-core] [Openembedded-architecture] Dropping armv5 and armv5e tunes in 2.7

[Andrea Adami]

On Fri, Jan 4, 2019 at 12:21 AM Khem Raj  wrote:
>
> Thanks Adrian
>
> On Thu, Jan 3, 2019 at 2:59 PM Adrian Bunk  wrote:
> >
> > On Thu, Jan 03, 2019 at 02:01:42PM -0800, Khem Raj wrote:
> > > Hello All
> > >
> > > You might have noticed a recent commit in gcc trunk
> > >
> > > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b232e6b58e3766bc66fe08fdb7bcba1bdadda8a2
> > >
> > > Which removed support for deprecated -march=armv5 and armv5e, this
> > > will be released along with gcc-9 release which is upcoming and we
> > > might be able to add gcc9 to 2.7 release or 2.8 release for sure.
> > >
> > > We still have non-thumb tunes for armv5 and armv4 in our tune pack, I
> > > would like to propose a patch to remove them.
> > >...
> >
> > Note that gcc 9 does *not* remove non-thumb armv4 support.
> >
>
> yes that's right. However, I was taking this time to find out if we can drop 
> all
> the ones besides armv5te even if gcc supported it unless there were OE users
> who are still interested in supporting them and had devices running OE
> which need them
>
> > Non-thumb armv5/armv5e have been removed due to
> > "have no known implementations".
> >
> > Non-thumb armv4 support was deprecated in gcc 6 together with armv2/armv3,
> > but there are still people using recent gcc on StrongARM - which is
> > non-thumb armv4.
>
> OK, that's a fair point, however, in OE's case I only have reports from users
> with armv4t devices, but it we can keep the armv4 arm-only tunes around along
> with the arm-thumb v4 ones
>

Khem,

on the kernel side it looks like RMK will not let die amrv4 so easily...

I still have around that Zaurus collie sa1100 armv4 and I think OE is
the only toolchain offering EABI for armv4
My plans were to lead it up to the upcoming linux v.5.0 so it should
not take long.
But all this is for fun I higly doubt there are still 'users'.

So IMHO it is premature to remove armv4.
Cheers
Andrea
> >
> > > Thanks
> > > -Khem
> >
> > cu
> > Adrian
> >
> > --
> >
> >"Is there not promise of rain?" Ling Tan asked suddenly out
> > of the darkness. There had been need of rain for many days.
> >"Only a promise," Lao Er said.
> >Pearl S. Buck - Dragon Seed
> >
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] liblzma: memory allocation failed

[Andrea Adami]

On Mon, Sep 24, 2018 at 9:08 AM Peter Bergin  wrote:
>
> On 2018-09-24 00:06, Andrea Adami wrote:
> > On Fri, Sep 21, 2018 at 1:04 AM Andrea Adami  wrote:
> >> On Thu, Sep 20, 2018 at 1:03 PM Peter Bergin  
> >> wrote:
> >>> On 2018-09-17 10:27, Burton, Ross wrote:
> >>>
> >>> On Mon, 17 Sep 2018 at 08:13, Peter Bergin  wrote:
> >>>
> >>> I'm pretty sure I have narrowed down the root cause to the restriction
> >>> of virtual memory and that liblzma base its memory calculations on
> >>> physical RAM.
> >>>
> >>> To prove this I added a printout in rpm-native/rpmio/rpmio.c and the
> >>> function lzopen_internal.
> >>>
> >>>   uint64_t memory_usage = 
> >>> lzma_stream_encoder_mt_memusage(&mt_options);
> >>>  rpmlog(RPMLOG_NOTICE, "DBG: memory_usage %lu\n", memory_usage);
> >>>
> >>>
> >>> The value of memory_usage is the same regardless of which 'ulimit -v'
> >>> value I set. On the host with 256GB of physical RAM and 32GB of virtual
> >>> memory, memory_usage is ~5.1GB. On another host with 16GB of physical
> >>> RAM I get memory_usage of ~660MB.
> >>>
> >>> I guess you have not seen this kind of failure if you not have
> >>> restricted virutal memory on your host. If you want to try to reproduce
> >>> this set 'ulimit -v 8388608' (8GB) in your shell and then 'bitbake
> >>> glibc-locale -c package_write_rpm -f'.
> >>>
> >>> Wouldn't a solution be to change lzma to look at free memory, not
> >>> total physical memory?
> >>>
> >>> Ross
> >>>
> >>> I have been in contact with the maintainer of liblzma. There is currently 
> >>> no way to restrict the memory usage in liblzma during multi threaded 
> >>> compression. He recommended to adjust the number of threads used during 
> >>> compression. This kind of check is done for 32-bits but not when running 
> >>> 64-bits (in rpmio/rpmio.c lzopen_internal). To rewrite liblzma is another 
> >>> option but I took an easier way out.
> >>>
> >>> I have come up with a patch 
> >>> (https://patchwork.openembedded.org/patch/155017/) that solves my problem 
> >>> and do a restriction of memory usage when the 'ulimit -v' is set. The 
> >>> calculation is based on the assumption that lzopen_internal is run in 
> >>> parallel with as many instances as cpu threads as '#pragma omp parallel' 
> >>> is used in build/pack.c.
> >>>
> >>> When running test on my machine with 4 cores 16GB of physical RAM and 
> >>> 'ulimit -v 2097152' (2GB). It works good and the log shows:
> >>>
> >>> XZ: virtual memory restricted to 2147483648 and per CPU thread 536870912
> >>> XZ: Adjusted the number of threads from 4 to 3 to not exceed the memory 
> >>> usage limit of 2147483648 bytes
> >>>
> >>> Didn't get a clear answer if this is something Yocto/OE should support 
> >>> but I hope my patch solves the issue and it will not affect the normal 
> >>> environments where 'ulimit -v' is not set.
> >>>
> >>> /Peter
> >>> --
> >> Peter,
> >> first of all sorry for butting-in again. My bad I misunderstood the point,
> >>
> >> Looking properly at it, I see the sources do restrict only #if __WORDSIZE 
> >> == 32.
> >>
> >> Again, there is the other way to reduce total memory footprint just
> >> using lower preset in mt_options.
> >> As far as I see default is  #define LZMA_PRESET_DEFAULT UINT32_C(6)
> >> so you could tr to modify   mt_options.preset to your needs.
> >> I think more threads is normally  better.
> >>
> >> Cheers
> >> Andrea
> >>
> >>> ___
> >>> yocto mailing list
> >>> yocto@yoctoproject.org
> >>> https://lists.yoctoproject.org/listinfo/yocto
> >
> > Well,
> > call it luck, I now get similar problems with
> > -  opkg-utils: use multithreaded xz when building packages
> > 369c43cca4f0
> >
> > I build in tmpfs (8GB) and have 8 cores.
> > Strange enough, it does happen with only one machine of our bsp (akita).
> >
> > Build Configuration:
> > BB_VERSION  

Re: [yocto] liblzma: memory allocation failed

[Andrea Adami]

On Fri, Sep 21, 2018 at 1:04 AM Andrea Adami  wrote:
>
> On Thu, Sep 20, 2018 at 1:03 PM Peter Bergin  wrote:
> >
> > On 2018-09-17 10:27, Burton, Ross wrote:
> >
> > On Mon, 17 Sep 2018 at 08:13, Peter Bergin  wrote:
> >
> > I'm pretty sure I have narrowed down the root cause to the restriction
> > of virtual memory and that liblzma base its memory calculations on
> > physical RAM.
> >
> > To prove this I added a printout in rpm-native/rpmio/rpmio.c and the
> > function lzopen_internal.
> >
> >  uint64_t memory_usage = 
> > lzma_stream_encoder_mt_memusage(&mt_options);
> > rpmlog(RPMLOG_NOTICE, "DBG: memory_usage %lu\n", memory_usage);
> >
> >
> > The value of memory_usage is the same regardless of which 'ulimit -v'
> > value I set. On the host with 256GB of physical RAM and 32GB of virtual
> > memory, memory_usage is ~5.1GB. On another host with 16GB of physical
> > RAM I get memory_usage of ~660MB.
> >
> > I guess you have not seen this kind of failure if you not have
> > restricted virutal memory on your host. If you want to try to reproduce
> > this set 'ulimit -v 8388608' (8GB) in your shell and then 'bitbake
> > glibc-locale -c package_write_rpm -f'.
> >
> > Wouldn't a solution be to change lzma to look at free memory, not
> > total physical memory?
> >
> > Ross
> >
> > I have been in contact with the maintainer of liblzma. There is currently 
> > no way to restrict the memory usage in liblzma during multi threaded 
> > compression. He recommended to adjust the number of threads used during 
> > compression. This kind of check is done for 32-bits but not when running 
> > 64-bits (in rpmio/rpmio.c lzopen_internal). To rewrite liblzma is another 
> > option but I took an easier way out.
> >
> > I have come up with a patch 
> > (https://patchwork.openembedded.org/patch/155017/) that solves my problem 
> > and do a restriction of memory usage when the 'ulimit -v' is set. The 
> > calculation is based on the assumption that lzopen_internal is run in 
> > parallel with as many instances as cpu threads as '#pragma omp parallel' is 
> > used in build/pack.c.
> >
> > When running test on my machine with 4 cores 16GB of physical RAM and 
> > 'ulimit -v 2097152' (2GB). It works good and the log shows:
> >
> > XZ: virtual memory restricted to 2147483648 and per CPU thread 536870912
> > XZ: Adjusted the number of threads from 4 to 3 to not exceed the memory 
> > usage limit of 2147483648 bytes
> >
> > Didn't get a clear answer if this is something Yocto/OE should support but 
> > I hope my patch solves the issue and it will not affect the normal 
> > environments where 'ulimit -v' is not set.
> >
> > /Peter
> > --
>
> Peter,
> first of all sorry for butting-in again. My bad I misunderstood the point,
>
> Looking properly at it, I see the sources do restrict only #if __WORDSIZE == 
> 32.
>
> Again, there is the other way to reduce total memory footprint just
> using lower preset in mt_options.
> As far as I see default is  #define LZMA_PRESET_DEFAULT UINT32_C(6)
> so you could tr to modify   mt_options.preset to your needs.
> I think more threads is normally  better.
>
> Cheers
> Andrea
>
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto


Well,
call it luck, I now get similar problems with
-  opkg-utils: use multithreaded xz when building packages
   369c43cca4f0

I build in tmpfs (8GB) and have 8 cores.
Strange enough, it does happen with only one machine of our bsp (akita).

Build Configuration:
BB_VERSION   = "1.39.1"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "ubuntu-16.04"
TARGET_SYS   = "arm-oe-linux-gnueabi"
MACHINE  = "akita"
DISTRO   = "nodistro"
DISTRO_VERSION   = "nodistro.0"
TUNE_FEATURES= "arm armv5 thumb dsp"
TARGET_FPU   = "soft"
meta = "master:8cc08e44cf3e969c124456d459c6c06a76cad018"
meta-handheld= "master:61e16e253ea870b87592075efd87727e8b5c574d"
meta-initramfs
meta-oe  = "master:7ac8d82fec470a8c8e66cfc4216381e2364cb4b2"

...
Installing kernel-module-nls-cp1251-4.14.62-handheld (4.14) on root
Downloading 
file:/tmp/build/tmp-glibc/work/akita-oe-linux-gnueabi/core-image-base/1.0-r0/oe-rootfs-repo/akita/

Re: [yocto] liblzma: memory allocation failed

[Andrea Adami]

On Thu, Sep 20, 2018 at 1:03 PM Peter Bergin  wrote:
>
> On 2018-09-17 10:27, Burton, Ross wrote:
>
> On Mon, 17 Sep 2018 at 08:13, Peter Bergin  wrote:
>
> I'm pretty sure I have narrowed down the root cause to the restriction
> of virtual memory and that liblzma base its memory calculations on
> physical RAM.
>
> To prove this I added a printout in rpm-native/rpmio/rpmio.c and the
> function lzopen_internal.
>
>  uint64_t memory_usage = lzma_stream_encoder_mt_memusage(&mt_options);
> rpmlog(RPMLOG_NOTICE, "DBG: memory_usage %lu\n", memory_usage);
>
>
> The value of memory_usage is the same regardless of which 'ulimit -v'
> value I set. On the host with 256GB of physical RAM and 32GB of virtual
> memory, memory_usage is ~5.1GB. On another host with 16GB of physical
> RAM I get memory_usage of ~660MB.
>
> I guess you have not seen this kind of failure if you not have
> restricted virutal memory on your host. If you want to try to reproduce
> this set 'ulimit -v 8388608' (8GB) in your shell and then 'bitbake
> glibc-locale -c package_write_rpm -f'.
>
> Wouldn't a solution be to change lzma to look at free memory, not
> total physical memory?
>
> Ross
>
> I have been in contact with the maintainer of liblzma. There is currently no 
> way to restrict the memory usage in liblzma during multi threaded 
> compression. He recommended to adjust the number of threads used during 
> compression. This kind of check is done for 32-bits but not when running 
> 64-bits (in rpmio/rpmio.c lzopen_internal). To rewrite liblzma is another 
> option but I took an easier way out.
>
> I have come up with a patch 
> (https://patchwork.openembedded.org/patch/155017/) that solves my problem and 
> do a restriction of memory usage when the 'ulimit -v' is set. The calculation 
> is based on the assumption that lzopen_internal is run in parallel with as 
> many instances as cpu threads as '#pragma omp parallel' is used in 
> build/pack.c.
>
> When running test on my machine with 4 cores 16GB of physical RAM and 'ulimit 
> -v 2097152' (2GB). It works good and the log shows:
>
> XZ: virtual memory restricted to 2147483648 and per CPU thread 536870912
> XZ: Adjusted the number of threads from 4 to 3 to not exceed the memory usage 
> limit of 2147483648 bytes
>
> Didn't get a clear answer if this is something Yocto/OE should support but I 
> hope my patch solves the issue and it will not affect the normal environments 
> where 'ulimit -v' is not set.
>
> /Peter
> --

Peter,
first of all sorry for butting-in again. My bad I misunderstood the point,

Looking properly at it, I see the sources do restrict only #if __WORDSIZE == 32.

Again, there is the other way to reduce total memory footprint just
using lower preset in mt_options.
As far as I see default is  #define LZMA_PRESET_DEFAULT UINT32_C(6)
so you could tr to modify   mt_options.preset to your needs.
I think more threads is normally  better.

Cheers
Andrea

> ___
> 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] liblzma: memory allocation failed

[Andrea Adami]

On Mon, Sep 17, 2018 at 10:28 AM Burton, Ross  wrote:
>
> On Mon, 17 Sep 2018 at 08:13, Peter Bergin  wrote:
> > I'm pretty sure I have narrowed down the root cause to the restriction
> > of virtual memory and that liblzma base its memory calculations on
> > physical RAM.


Hello,

well, not only.
You can set the memory footprint for compression/decompression.

In OE for legacy kernels we use in our BSP:
# sane defaults for devices with only 32Mb RAM (see man xz)
XZ_COMPRESSION_LEVEL = "-2e"

Default is -3, the -2 uses right half the RAM for compressing,.
Pls check man xz.

Cheers
Andrea


> >
> > To prove this I added a printout in rpm-native/rpmio/rpmio.c and the
> > function lzopen_internal.
> >
> >  uint64_t memory_usage = 
> > lzma_stream_encoder_mt_memusage(&mt_options);
> > rpmlog(RPMLOG_NOTICE, "DBG: memory_usage %lu\n", memory_usage);
> >
> >
> > The value of memory_usage is the same regardless of which 'ulimit -v'
> > value I set. On the host with 256GB of physical RAM and 32GB of virtual
> > memory, memory_usage is ~5.1GB. On another host with 16GB of physical
> > RAM I get memory_usage of ~660MB.
> >
> > I guess you have not seen this kind of failure if you not have
> > restricted virutal memory on your host. If you want to try to reproduce
> > this set 'ulimit -v 8388608' (8GB) in your shell and then 'bitbake
> > glibc-locale -c package_write_rpm -f'.
>
> Wouldn't a solution be to change lzma to look at free memory, not
> total physical memory?
>
> Ross
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [poky][PATCH] kernel.bbclass: Fix kernel size checking

[Andrea Adami]

On Fri, Dec 15, 2017 at 9:16 AM, Jaap de Jong  wrote:
> From 4d542a5a37210b4fc8c8e894554a75ba6b9be0af Mon Sep 17 00:00:00 2001
> From: Jaap de Jong 
> Date: Fri, 15 Dec 2017 08:58:09 +0100
> Subject: [poky][PATCH] kernel.bbclass: Fix kernel size checking
> To: yocto@yoctoproject.org
>
> ---
>  meta/classes/kernel.bbclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 7ef4f47..f41c3e4 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -601,12 +601,12 @@ do_sizecheck() {
> if [ ! -z "${KERNEL_IMAGE_MAXSIZE}" ]; then
> invalid=`echo ${KERNEL_IMAGE_MAXSIZE} | sed 's/[0-9]//g'`
> if [ -n "$invalid" ]; then
> -   die "Invalid KERNEL_IMAGE_MAXSIZE:
> ${KERNEL_IMAGE_MAXSIZE}, should be an integerx (The unit is Kbytes)"
> +   die "Invalid KERNEL_IMAGE_MAXSIZE:
> ${KERNEL_IMAGE_MAXSIZE}, should be an integer (The unit is Kbytes)"
> fi
> for type in ${KERNEL_IMAGETYPES} ; do
> size=`du -ks ${B}/${KERNEL_OUTPUT_DIR}/$type | awk
> '{print $1}'`
> if [ $size -ge ${KERNEL_IMAGE_MAXSIZE} ]; then
> -   warn "This kernel $type (size=$size(K) >
> ${KERNEL_IMAGE_MAXSIZE}(K)) is too big for your device. Please reduce the
> size of the kernel by making more of it modular."
> +   die "This kernel $type (size=$size(K) >
> ${KERNEL_IMAGE_MAXSIZE}(K)) is too big for your device. Please reduce the
> size of the kernel by making more of it modular."
> fi
> done
> fi
> --
> 2.7.4
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Hi,

there has been a discussion about do_sizecheck and there is already a
pending patch:

http://lists.openembedded.org/pipermail/openembedded-core/2017-December/145376.html

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

Re: [yocto] Problem with populate_sdk

[Andrea Adami]

On Mon, Oct 23, 2017 at 10:31 PM, Greg Wilson-Lindberg
 wrote:
> Hi Andrea,
> I added the dbg-pkgs to the IMAGE_FEATURES but it didn't seem to make a 
> difference in what was included, still no .a file in the SYSROOT.
> Regards,
> Greg

Hi Greg,
maybe I wasn't clear, from the manual:

SDKIMAGE_FEATURES: Lists the features to include in the "target" part
of the SDK.

IMAGE_FEATURES: Specifies features to include in the image. Most of
these features map to additional packages for installation.

So please use  SDKIMAGE_FEATURES = "dev-pkgs staticdev-pkgs"

Cheers
Andrea

>
>> -Original Message-
>> From: Andrea Adami [mailto:andrea.ad...@gmail.com]
>> Sent: Sunday, October 22, 2017 4:12 PM
>> To: Greg Wilson-Lindberg 
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Problem with populate_sdk
>>
>> On Thu, Oct 19, 2017 at 8:26 PM, Greg Wilson-Lindberg
>>  wrote:
>> > I'm trying to build an SDK for a Raspberry Pi3, and I got a problem
>> > with the files from one of my custom recipes.
>> >
>> >
>> > In my recipe I have:
>> >
>> > FILES_${PN}-dev = "lib/lib${PN}.a lib/lib${PN}_unix.a lib/pkgconfig
>> > include/canfestival/*.h"
>> >
>> >
>> > The *.a files get put into staticdev not dev in the package split.
>> >
>> >
>> > In my image recipe I've added:
>> >
>> > IMAGE_FEATURES += "dev-pkgs  staticdev-pkgs"
>> >
>> > I get all of the libraries in my image. In the SDK I don't get the *.a
>> > libraries from the staticdev, I do get the header files which were put
>> > into dev.
>> >
>> >
>> > So, at this point I'm a bit confused, even though I include both the
>> > dev & staticdev I am only getting the dev files in the SDK. And, also,
>> > why are the *.a libs being put into staticdev in the first place?
>> >
>> >
>>
>> Hi,
>> these defaults are defined in meta/conf/bitbake.conf:
>>
>> PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale
>> ${PACKAGE_BEFORE_PN} ${PN}"
>>
>> This means that staticdev package is created before dev package, just after
>> dbg.
>>
>> and
>>
>> FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a 
>> ${libdir}/${BPN}/*.a"
>>
>> indicates that the .a files in these dirs belongs to the staticdev package.
>>
>> Now, I guess you should try:
>>
>>  SDKIMAGE_FEATURES = "dev-pkgs dbg-pkgs staticdev-pkgs"
>>
>> Se https://lists.yoctoproject.org/pipermail/yocto/2014-
>> September/021645.html
>>
>> Cheers
>> Andrea
>>
>>
>> > Regards, Greg
>> >
>> >
>> > --
>> > ___
>> > 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] Problem with populate_sdk

[Andrea Adami]

On Thu, Oct 19, 2017 at 8:26 PM, Greg Wilson-Lindberg
 wrote:
> I'm trying to build an SDK for a Raspberry Pi3, and I got a problem with the
> files from one of my custom recipes.
>
>
> In my recipe I have:
>
> FILES_${PN}-dev = "lib/lib${PN}.a lib/lib${PN}_unix.a lib/pkgconfig
> include/canfestival/*.h"
>
>
> The *.a files get put into staticdev not dev in the package split.
>
>
> In my image recipe I've added:
>
> IMAGE_FEATURES += "dev-pkgs  staticdev-pkgs"
>
> I get all of the libraries in my image. In the SDK I don't get the *.a
> libraries from the staticdev, I do get the header files which were put into
> dev.
>
>
> So, at this point I'm a bit confused, even though I include both the dev &
> staticdev I am only getting the dev files in the SDK. And, also, why are the
> *.a libs being put into staticdev in the first place?
>
>

Hi,
these defaults are defined in meta/conf/bitbake.conf:

PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale
${PACKAGE_BEFORE_PN} ${PN}"

This means that staticdev package is created before dev package, just after dbg.

and

FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a ${libdir}/${BPN}/*.a"

indicates that the .a files in these dirs belongs to the staticdev package.

Now, I guess you should try:

 SDKIMAGE_FEATURES = "dev-pkgs dbg-pkgs staticdev-pkgs"

Se https://lists.yoctoproject.org/pipermail/yocto/2014-September/021645.html

Cheers
Andrea


> Regards, Greg
>
>
> --
> ___
> 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] Warning: unable to open an initial console

[Andrea Adami]

On Fri, May 26, 2017 at 1:05 PM, Gerard van den Bosch
 wrote:
> Hello,
>
> I have build my vendor custom kernel 2.6.20 with yocto daisy.
> Daisy is used because seems to be last release supporting this old kernel.
>
> I tried building core-image-minimal and core-image-base.
>
> The kernel boots and the rootfs is mounted but then I get:
>
> "Warning: unable to open an initial console."
>
>
> I found on the internet this is because "/dev/console" doesn't exists.
> The dev folder in my generated rootfs is empty.
>
> On internet found can do the following commands:
> "mknod -m 600 /dev/console c 5 1 "
> "mknod -m 666 /dev/null c 1 3"
>
> But if this is the problem how do I add this to my recipe?
> Or is there a proper way to populate this devices?
>
> Cheers,
> Gerard
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Hello Gerard,

if your old kernel lacks devtmpfs you need a "device table".
You need to set at least
IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt"

This is a default set in image.bbclass before and after daisy...dunno
what's happened with this release.

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

Re: [yocto] Dependence from image type to image recipe

[Andrea Adami]

On Mon, Feb 20, 2017 at 1:40 PM, Viguera, Javier
 wrote:
> Hi all,
>
>
>
> I need a bit of help to add a dependence from an image type to an image
> recipe that build and initramfs.
>
>
>
> A bit of background: I have an image type recovery.ubifs that boots using a
> ramdisk. The ramdisk is generated with a different image recipe
> (recovery-initramfs).
>
>
>
> So whenever I configure any image (core-image-minimal, core-image-sato) to
> generate recovery images, it should build first the ramdisk and add it to
> the final recovery image.
>
>
>
> In Jethro this was working file using IMAGE_DEPENDS in my custom
> image-creation class:
>
>
>
> IMAGE_DEPENDS_recovery.ubifs = " \
>
> mtd-utils-native:do_populate_sysroot \
>
> u-boot:do_deploy \
>
> virtual/kernel:do_deploy \
>
> recovery-initramfs:do_rootfs \
>
> "
>
>
>
> Now I'm migrating to Morty, and this does not seem to work anymore. When
> instructed to generate a recovery image, it does not detect the dependence
> on the recovery-initramfs image, and fails to generate the final image.
>
>
>
> How should I code such dependence? Remember is not a dependence from any
> other image recipe, it's a dependence from an image FSTYPE.
>

Hello,
I think you have just to adapt to the changes in oe-core [1]

 -recovery-initramfs:do_rootfs \
 +recovery-initramfs:do_image_complete \

Cheers
Andrea


[1] 
http://cgit.openembedded.org/openembedded-core/commit/?id=59a5f596ca29b1eb8283706e3c60fbb39f9c2c23



>
>
> Hope the description is clear enough. Otherwise please say so and I'll try
> to explain it better.
>
>
>
> --
>
> Thanks.
>
>
>
> Javier Viguera
>
>
> --
> ___
> 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 organize my patches for multiple kernels and multiple target boards?

[Andrea Adami]

On Tue, Mar 1, 2016 at 12:19 AM, Robert P. J. Day  wrote:
>   (i posted a much lengthier version of this on oe-core recently, but i want
> to cut it down and ask specific questions to clarify what i *think* is going
> on.)
>
>   i want to pull in an existing layer with recipes for linux-4.0.bb and
> linux-4.1.bb, and extend them with .bbappend files, to support two
> closely-related
> machines i'm defining -- call them "mach1" and "mach2". AFAICT, my patches
> will
> fall somewhere in a 3x3 matrix of possibilities:
>
>   * 3 possibilities of applying against mach1, mach2 or both
>   * 3 possibilities of applying against linux-4.0, linux-4.1 or both
>
> so there's my 3x3 matrix.
>
>   the obvious kernel recipe directory structure would be:
>
>   linux/
> linux-4.0.bbappend
> linux-4.1.bbappend
> linux-4.0/[4.0-specific patches]
> linux-4.1/[4.1-specific patches]
> linux/[patches that apply to both]
>
> which suggests that both my .bbappend files would have to contain the line:
>
>   FILESEXTRAPATHS_prepend := "${THISDIR}/${BP}:${THISDIR}/${BPN}"
>
> so the SRC_URI search path for linux-4.0.bbappend entries would be
> prepended with:
>
>   * linux-4.0/[4.0-specific patches]
>   * linux/[patches that apply to both]
>
> and similarly for linux.4.1.bbappend. how am i doing so far? this would
> mean that, for each recipe, the more specific directory would be searched
> before the general directory. but wait ... there's more.
>
>   now i want to further categorize patches based on exclusive to mach1,
> exclusive to mach2, or applicable to both, and since the machine name is
> one of the entries in FILESOVERRIDES, i can extend the directory structure
> as:
>
>   linux-4.0/
> mach1/
> mach2/
>   linux-4.1/
> mach1/
> mach2/
>   linux/
> mach1/
> mach2/
>
> and there's my 3x3 matrix of patches, correct? and here's where it gets
> unclear.
>
>   i really don't want to have to number all my patches with prefixes like
> 0001-, 0002- and so on, so what is the ordering of processing for .scc,
> .cfg and .patch/.diff files? rather than just lump all the patches into
> a single .scc file, i want to refine the patches across multiple .scc
> files. is there an imposed order on SRC_URI entries, .scc files and so
> on? that's probably all i need to finish this off.
>
> rday

Robert,

in the past I have done pretty much the same: scc,cfg and patches all
packed in the recipe.
Please see these (outdated) layout examples for linux-yocto* that were
in meta-handheld.

for 3.10, using .cfg & .scc
http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux?h=dylan

Or simplified, for 3.14, using defconfig, with patches listed in SRC_URI
http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux?h=dizzy

Regards

Andrea

>
>
>
> --
> ___
> 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] Microcontroller Cross Compiler

[Andrea Adami]

On Thu, Dec 18, 2014 at 8:09 PM, Darcy Watkins
 wrote:
> Hello,
>
> In my target system I have a microcontroller (MCU) that handles some I/O, 
> power supplies and system boot up to the point of taking the main CPU out of 
> reset.  At present, we build the MCU firmware from source and then the binary 
> file is packaged to be used as payload with an MCU firmware update utility.
>
> Now my main question...  does anyone have suggestions (or is there a 'yocto' 
> way) to build such a cross compiler for the MCU so that it can be invoked to 
> build MCU firmware from source as part of the bitbake build for the Linux 
> target's image.  The idea would be to build MCU firmware image from source 
> using the MCU cross compiler, but obviously to build drivers and utilities 
> that run on the main CPU using the normal cross-compiler toolchains built 
> under yocto.  Then I could package the payload firmware image along with 
> utilities all as part of the same RPM package.
>
> The MCU cross compiler we use was originally generated using crosstool-ng, 
> and is essentially a gcc cross compiler for 'bare metal' MCU target.
>
> Does anyone who has gone down this road have suggestions?
>
> Thanks in advance!
>
>
> Regards,
>
> Darcy
>
> Darcy Watkins ::  Staff Engineer, Firmware
>
> SIERRA WIRELESS
> Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604 231 1100
> 13811 Wireless Way  :: Richmond, BC Canada V6V 3A4
> [P2]
> dwatk...@sierrawireless.com :: www.sierrawireless.com :: 
> www.inmotiontechnology.com
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Hi Darcy,

if I understand correctly you use the standard toolchain for the
target image and a custom $CC to build one custom binary.

We use klcc for a couple of klibc-static-recipes thus we created a
.bbclass to be inherited.
See 
http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/classes/klibc.bbclass

Regards

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

Re: [yocto] [PATCH 0/2] Add support for MIPS32r2 and CI20 to Yocto

[Andrea Adami]

On Fri, Sep 12, 2014 at 6:35 PM, Vicente Olivert Riera
 wrote:
> Add support for the MIPS Creator CI20 machine. That board has a MIPS32r2
> architecture so we also add support for that.
>
> Vicente Olivert Riera (2):
>   Add support for MIPS32r2
>   Add MIPS Creator CI20 machine
>
>  meta-yocto-bsp/conf/machine/ci20.conf   |   10 ++
>  meta/conf/machine/include/tune-mips32r2.inc |   25 +
>  2 files changed, 35 insertions(+), 0 deletions(-)
>  create mode 100644 meta-yocto-bsp/conf/machine/ci20.conf
>  create mode 100644 meta/conf/machine/include/tune-mips32r2.inc
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Hi Vicente,

there is already some support for mips32r2 (see
include/tune-mips32r2.inc) in oe-core master.
It looks like your patch is extending it so please rebase and resend
the patch to openembedded-c...@lists.openembedded.org for review.

Thanks

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

Re: [yocto] How to copy recipe and have different target names

[Andrea Adami]

On Tue, Jun 17, 2014 at 10:11 PM, Brian Smucker  wrote:
> Hi Andrea and all,
>
> So I am using your suggestion to make another variant of busybox:
> busybox-static, and I add the static.bblcass file.
>
> So when I try to do bitbake busybox-static, it ends up unpacking to
> busybox-static-1.20.2-r2/busybox-1.20.2 (which does not correspond to the S
> variable).
> And it errors out when it attempts to patch to
> busybox-static-1.20.2-r2/busybox-static-1.20.2 (the S variable path).
>
> What am I missing?
>

Hi,
sorry but I couldn't do a build-test yet so take my observations with
a grain of salt.
As I prevously hinted there are cases like this requiring some vars
adjustements because you have changed the BPN and PN (base/package
name).

In your -static recipe you could try to redefine

S = "${WORKDIR}/busybox-${PV}

Neverthless, busybox recipe is a special one because it is used
instead of a lot of single utilities.
This implies there are special cares to take to avoid conflicts with
busybox when a recipe is providing the same stuff.

AFAIS packaging should work because the recipe is using ${PN} so
you'll get distinct packages but check the manual about U_A (update
alternatives) and provider conflicts.

You have chosen one of the most complicate recipes to play with ;)

Cheers

Andrea
>
> Thanks,
>
> Brian
>
>
>
> On 6/17/2014 9:31 AM, Andrea Adami wrote:
>>
>> On Tue, Jun 17, 2014 at 5:41 PM, Brian Smucker 
>> wrote:
>>>
>>> Hello,
>>>
>>> I would like to have yocto generate two copies of busybox, one
>>> statically-linked and one dynamically linked. So I try to make a copy of
>>> the
>>> busybox recipe and give it a new name like busybox-s_x.bb
>>>
>>> But my knowlege of yocto comes up short and I get lots of errors.
>>>
>>> Is there a way to do this cleanly?  Or should I be trying to do a
>>> different
>>> approach?
>>>
>>> Thanks,
>>>
>>> Brian
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>> Brian,
>>
>> I don't think there is an 'official' way to do that.
>> For a similar purpose (buidling static binaries against klibc) I have
>> developed two solutions, both using a custom class:
>>
>> 1) for easy-to-adapt recipes, BBCLASSEXTEND +  the custom class
>>
>> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-bsp/kexecboot/kexecboot_0.6.bb
>>
>> 2) for the stubborn cases, create a copy of the recipe and may need to
>> adjust some vars (S, FILESPATH or better FILESEXTRAPATHS, ...)
>> see  i.e.
>>
>> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.0.bb
>>
>> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-kernel/kexec/kexec-tools-klibc_2.0.2.bb
>>
>> I guess busybox belongs to the heavy ones...
>>
>> Cheers
>>
>> Andrea
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to copy recipe and have different target names

[Andrea Adami]

On Tue, Jun 17, 2014 at 5:41 PM, Brian Smucker  wrote:
> Hello,
>
> I would like to have yocto generate two copies of busybox, one
> statically-linked and one dynamically linked. So I try to make a copy of the
> busybox recipe and give it a new name like busybox-s_x.bb
>
> But my knowlege of yocto comes up short and I get lots of errors.
>
> Is there a way to do this cleanly?  Or should I be trying to do a different
> approach?
>
> Thanks,
>
> Brian
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Brian,

I don't think there is an 'official' way to do that.
For a similar purpose (buidling static binaries against klibc) I have
developed two solutions, both using a custom class:

1) for easy-to-adapt recipes, BBCLASSEXTEND +  the custom class
http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-bsp/kexecboot/kexecboot_0.6.bb

2) for the stubborn cases, create a copy of the recipe and may need to
adjust some vars (S, FILESPATH or better FILESEXTRAPATHS, ...)
see  i.e.
http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.0.bb
http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-kernel/kexec/kexec-tools-klibc_2.0.2.bb

I guess busybox belongs to the heavy ones...

Cheers

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

Re: [yocto] Procedure to build Initramfs Image

[Andrea Adami]

On Thu, Jun 5, 2014 at 1:37 AM, Sasikanth babu  wrote:
> Hi all,
>
> How to build initramfs image (rootfs embedded in kernel - uimage)?. I
> know it has been asked several time on this mailing list  but could find a
> solution?.
>
>
> I tried steps mentioned in the below link
>
> http://kexecboot.org/documentation/crosscompiling/oe-yocto


Hi Sasikanth,

this set of recipes is not the generic way to embedd an initramfs but
covers a special usercase: different libc (klibc) for compiling the
cpio.

>
> but I got rootfs.cpio.gz and uimage no initramfs(rootfs embedded in kernel);
>

You have to manually bitbake the "linux-my-initramfs" recipe. Unless
explicitely specified in your machine.conf building the initramfs or
the virtual/kernel does not trigger the automatic build of your second
kernel containing the cpio.

>
> Any suggestions or links on how to build initamfs image.
>

See for reference the patch introducing the easy-embedding [1] and
further changes :
[1]
http://cgit.openembedded.org/openembedded-core/commit/meta?id=609d5a9ab9e58bb1c2bcc2145399fbc8b701b85a


> Thanks in advance.
>
> - Sasi


Cheers
Andrea

>
> --
> ___
> 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] Custom defconfig is not used

[Andrea Adami]

On Tue, Oct 29, 2013 at 11:33 AM, Diego Sueiro  wrote:
>
> 2013/10/28 Bruce Ashfield 
>>
>> I'm using dylan for my yocto checkout (not oe-core standalone, since
>> this is a yocto list/question),
>
> I thought that opemenbedded-core and poky were sharing the same core
> components, classes and functions.
>
>>
>> My build shows:
>>
>> meta
>> meta-yocto
>> meta-yocto-bsp= "dylan:3dc4505f0e744177ae4ddff1e1ce8b31b95dfaa6"
>> meta-ti   = "master:c14c386946e1ea341faeea292580e37d538d645d"
>> meta-alphalem = "master:a5c0e8ff51297a4090cd47d669b4fc9c94696908"
>> meta-alphalem-bsp = "master:56086e4dc618e975c9a46491793041f0d18e47a2"
>>
>> Mike indicated that he was using dylan for meta-ti, but that doesn't
>> make a difference either, since for our purposed. It's kernel.bbclass
>> and the yocto kernel processing that matters.
>
> I'll build a setup with yocto (dylan), meta-beagleboard (dylan) and
> meta-mine to check if I can reproduce the issues.
>
>>
>> In meta-alphalem-bsp, I have linux-mainline_3.2.bbappend, with the
>> following content:
>>
>> > cat linux-mainline_3.2.bbappend
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.2:"
>>
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>>
>> COMPATIBLE_MACHINE = "(beagleboard)"
>>
>> SRC_URI_append = " file://defconfig"
>> SRC_URI_append = " file://my_frag.cfg"
>>
>> And I added a fragment which has:
>>
>> > cat my_frag.cfg
>> CONFIG_WATCHDOG_NOWAYOUT=y
>> CONFIG_NTFS_FS=y
>> CONFIG_NTFS_RW=y
>>
>> When both are applied to the kernel build, we should see CONFIG_NTFS_FS
>> transition from =m to =y:
>>
>> > grep CONFIG_NTFS_FS *
>> defconfig:CONFIG_NTFS_FS=m
>> my_frag.cfg:CONFIG_NTFS_FS=y
>>
>> After invoking linux-mainline's configure task, I see the following:
>>
>> > grep CONFIG_NTFS_FS linux-beagleboard-standard-build/.config
>> CONFIG_NTFS_FS=y
>>
>> And other elements of the defconfig and fragment are properly applied
>> to the configuration phase.
>>
>> I'm also seeing good results on master, which means that I'm at a
>> standstill to reproduce any problems.
>>
>> Diego: can you confirm for me what triggers you are seeing that shows
>> the defconfig and fragment are not used. I assume the config options
>> are not present, but I just want to be sure.
>
> For the full defconfig replacement after doing a do_configure I've checked
> .config on ${S} and it did not included my CONFIGS.
> For config fragment it got stuck on do_patch task.
>
>
>
> Regards,
>
> --
> *dS
> Diego Sueiro
>
> /*long live rock 'n roll*/
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

I'll jump in one more time...

Have you tried putting defconfig and patch under  subdir?

recipes-kernel/linux/linux-yocto-3.2/
defconfig
my-own.patch

I've recently added two similar entries for 3.10 and it works.
Afaik it was impossible to put a common patch under /linux-yocto-.3.2
at the time.

Regards

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

Re: [yocto] Custom defconfig is not used

[Andrea Adami]

On Thu, Oct 17, 2013 at 3:19 PM, Bruce Ashfield
 wrote:
> On 13-10-17 09:15 AM, Diego Sueiro wrote:
>>
>>
>> 2013/10/17 Bruce Ashfield > >
>>
>>
>>
>>
>> I expected to get this working "out-of-box".
>>
>>
>> Did you do a  "bitbake -e " ? and then look at
>> the SRC_URI ? That will tell us if for some reason the beagle layer's
>> defconfig is on there twice.
>>
>> I'll do it after my current build gets finished.
>>
>>
>>
>> Why config fragments did not worked too?
>>
>>
>> recipes must inherit linux-yocto to get that support, since it is
>> optional and not something we force on all kernel recipes. So if you
>> want fragment support, creating your own kernel recipe, based on the
>> one in the layers you are using, which inherits linux-yocto is one
>> route to take.
>>
>> Can I do it on bbappend, or do I need to copy the entirely
>> linux-mainline_3.8.bb  from
>>
>> meta-bleagleboard to my layer and add "inherit linux-yocto"?
>> Do I need to "inherit linux-yocto", "require
>> recipes-kernel/linux/linux-yocto.inc" or "inherit kernel-yocto"?
>
>
> Look at oe-core/meta-skeleton for the custom kernel recipe example.
> It has the inherit/include combinations that you need to follow.
>
>
>> My concern is: if doing this to just have the config fragment feature,
>> I'll possibly mess up the kernel build.
>
>
> It shouldn't. It only adds to existing phases, and doesn't make
> any changes. I've tested it in many combinations and it should
> work fine.
>
> If something breaks, I'd like to know, so we can fix it.
>
> Bruce
>
>
>>
>>
>> Regards,
>>
>> --
>> *dS
>> Diego Sueiro
>>
>> /*long live rock 'n roll*/
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

As a final note, the defconfig is overwritten by the
do_configure_prepend() code in linux.inc.
This is how kernel recipes did work before linux-yocto.

Cheers

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

Re: [yocto] Custom defconfig is not used

[Andrea Adami]

Hi,

I guess you're setting a wrong FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

See this example, using simple defconfig for some devices and an
experimental configuration (WIP ;) fo others using fragments.

http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-yocto_3.10.bbappend

Cheers

Andrea


On Tue, Oct 15, 2013 at 11:49 PM, Rudolf Streif
 wrote:
> Diego,
>
> You are appending a kernel recipe that uses the Linux Yocto tooling. The
> defconfig is essentially comprised of many different pieces from the meta
> branch of the Yocto kernel repository and optional configuration fragments
> that you provide. This tooling will not recognize a defconfig file you
> provide but it does recognize configuration fragments to be added to
> .config.
>
> You need to put
>
> CONFIG_WATCHDOG_NOWAYOUT=y
>
> into a file that ends with .cfg eg. watchdog.cfg and then modify your
> bbappend to
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI += " file://0019-mine.patch \
>  file://watchdog.cfg \
>  "
>
> Rudi
>
>
>
> On Tue, Oct 15, 2013 at 2:07 PM, Diego Sueiro 
> wrote:
>>
>> Folks,
>>
>> I created the following bbapend recipe for linux-mainline_3.8.bb (from
>> meta-beagleboard on dylan branch) for beaglebone.
>> meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>> SRC_URI += " file://0019-mine.patch \
>>  file://defconfig \
>>  "
>>
>> But the defconfig and .config files on ${S} and ${WORKDIR} used are from
>> meta-beagleboad, not from my bbappend.
>>
>> I tried to follow the instructions to add config fragments on the page
>> below but it did not worked too.
>>
>> http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#changing-the-configuration
>>
>> The strange thing is: My patch is applied but my defconfig, or config
>> fragment is not used.
>> I just want to add CONFIG_WATCHDOG_NOWAYOUT=y.
>>
>> I already did a cleasstate but no success.
>>
>> Any hints?
>>
>>
>> Regards,
>>
>> --
>> *dS
>> Diego Sueiro
>>
>> /*long live rock 'n roll*/
>>
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
>
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building linux-yocto kernel in own bsp layer

[Andrea Adami]

On Wed, Jul 31, 2013 at 9:21 AM, Martin Ertsaas  wrote:
> Hi.
>
> I'm creating my own bsp layer for omap4 chips (Yes, I know of meta-ti,
> but I want to learn how to do this myself :)). I'm trying to use the
> linux-yocto 3.4 kernel,
> and have gotten it to work locally. I then made a
> linux-yocto_3.4.bbappend which contains the following:
>
> COMPATIBLE_MACHINE_pandaboard = "pandaboard"
>
> SRCREV_machine_pandaboard ?= "7eb5fbf903d9db90c3cf371b65e1f2a68d5676d7"
>
> THISDIR := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.4"

Martin,

the code in kernel.bbclass does already copy defonfig to .config, see
http://cgit.openembedded.org/openembedded-core/tree/meta/classes/kernel.bbclass#n216

I think your problem is the deconfig is not found,  you miss a colon at the end.
Use something like

FILESEXTRAPATHS_prepend :=
"${THISDIR}/${PN}-3.4:${THISDIR}/${PN}:${THISDIR}/files:"

Cheers

Andrea


>
> SRC_URI += "file://defconfig"
>
> do_configure_prepend() {
> cp ${WORKDIR}/defconfig ${S}/.config
> }
>
> Problem I get is, without this configure_prepend, my defconfig is not
> copied into .config the kernel folder. With this however, I get a
> complaint from the kernel that the kernel directory is not clean and I
> have to run make mrproper.
>
> I would greatly appreciate any pointer/help/explanations as to what I
> have done wrong here, and how to fix it. Have been struggling for this
> for a while now, and have no idea what I have done wrong.
>
> Best regards
> Martin Ertsaas
> ___
> 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] qemux86 Image won't boot from CF

[Andrea Adami]

On Tue, Jun 12, 2012 at 2:04 PM, Andrea Adami  wrote:
> On Tue, Jun 12, 2012 at 1:07 PM, Jürgen Messerer
>  wrote:
>> Hi everybody.
>>
>>
>>
>> The following problem occurs when I try to start a x86 linux system from
>> CF-Card.
>>
>>
>>
>> I have generate a qemux86 core-image-minimal  image with the latest pokey.
>>
>> After that I have copied everything on a CF including
>> bzImage-3.2.1-yocto-standard
>>
>> Grub was already installed from an old linux version.
>>
>>
>>
>> I configured grubs menu.lst.
>>
>> Ther kernel starts perfectly util it like to finde the rootfs.
>>
>> Only one ext2 partion exist on the CF-Card.
>>
>> If have tried hda1 hdb1 hdc1 sda1 sdb1 sdc1 for the to root option. Same
>> problem.
>>
>
> Surely it is /dev/sdX since 2.6.3x
> Do you have all the necessary config options set for boot from CF?
> You need the block (pcmcia, pata, ..) devices and the filesystems
> built in kernel.


Ah, pls. add 'rootwait' to cmdline when booting from those kind of
removable media.

Cheers

Andrea

>
> Cheers
>
> Andrea
>
>> I also tried initrd. Same problem.
>>
>> I also tried rootfs from narcissus. Same problem.
>>
>>
>>
>> I appreciate any help.
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Regards
>>
>>
>>
>> Juergen
>>
>>
>>
>> 
>>
>> Menu.lst :
>>
>> 
>>
>> serial --unit=0 --speed=57600
>>
>> terminal --timeout=1 serial console
>>
>> default 0
>>
>>
>>
>> # tell grub to find the kernel on /dev/hda1
>>
>> root (hd0,0)
>>
>> savedefault
>>
>>
>>
>> # start menu entry with title
>>
>> title OpenEmbedded GNU/Linux
>>
>>
>>
>> title New OE serial console
>>
>> root (hd0,0)
>>
>> kernel /boot/bzImage-3.2.11-yocto-standard serialconsole root=/dev/hdb1
>> init=/sbin/init console=tty0 console=ttyS0,57600n8
>>
>> savedefault
>>
>>
>>
>>
>>
>> 
>>
>> KERNEL Output:
>>
>> 
>>
>>   Booting 'New OE serial console'
>>
>>
>>
>> root (hd0,0)
>>
>> Filesystem type is ext2fs, partition type 0x83
>>
>> kernel /boot/bzImage-3.2.11-yocto-standard serialconsole root=/dev/hdb1
>> init=/s
>>
>> bin/init console=tty0 console=ttyS0,57600n8
>>
>>    [Linux-bzImage, setup=0x3a00, size=0x441020]
>>
>> savedefault
>>
>>
>>
>> Initializing cgroup subsys cpuset
>>
>> Initializing cgroup subsys cpu
>>
>> Linux version 3.2.11-yocto-standard (blabla@blabla-virtual-machine) (gcc
>> version 4.6.4 20120303 (prerelea2
>>
>> BIOS-provided physical RAM map:
>>
>> BIOS-e820:  - 0009e000 (usable)
>>
>> BIOS-e820: 0009e000 - 000a (reserved)
>>
>> BIOS-e820: 000f - 0010 (reserved)
>>
>> BIOS-e820: 0010 - 0f7c (usable)
>>
>> BIOS-e820:  - 0001 (reserved)
>>
>> Notice: NX (Execute Disable) protection missing in CPU!
>>
>> DMI 2.2 present.
>>
>> last_pfn = 0xf7c0 max_arch_pfn = 0x10
>>
>> init_memory_mapping: -0f7c
>>
>> ACPI Error: A valid RSDP was not found (20110623/tbxfroot-219)
>>
>> 0MB HIGHMEM available.
>>
>> 247MB LOWMEM available.
>>
>>   mapped low ram: 0 - 0f7c
>>
>>   low ram: 0 - 0f7c
>>
>> Zone PFN ranges:
>>
>>   DMA  0x0010 -> 0x1000
>>
>>   Normal   0x1000 -> 0xf7c0
>>
>>   HighMem  empty
>>
>> Movable zone start PFN for each node
>>
>> early_node_map[2] active PFN ranges
>>
>>     0: 0x0010 -> 0x009e
>>
>>     0: 0x0100 -> 0xf7c0
>>
>> Using APIC driver default
>>
>> SMP: Allowing 1 CPUs, 0 hotplug CPUs
>>
>> No local APIC present or hardware disabled
>>
>> APIC: disable apic facility
>>
>> APIC: switched to apic NOOP
>>
>> Allocating PCI resources starting at f7c (gap: f7c:f083)
>>
>> setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1
>>
>> 

Re: [yocto] qemux86 Image won't boot from CF

[Andrea Adami]

On Tue, Jun 12, 2012 at 1:07 PM, Jürgen Messerer
 wrote:
> Hi everybody.
>
>
>
> The following problem occurs when I try to start a x86 linux system from
> CF-Card.
>
>
>
> I have generate a qemux86 core-image-minimal  image with the latest pokey.
>
> After that I have copied everything on a CF including
> bzImage-3.2.1-yocto-standard
>
> Grub was already installed from an old linux version.
>
>
>
> I configured grubs menu.lst.
>
> Ther kernel starts perfectly util it like to finde the rootfs.
>
> Only one ext2 partion exist on the CF-Card.
>
> If have tried hda1 hdb1 hdc1 sda1 sdb1 sdc1 for the to root option. Same
> problem.
>

Surely it is /dev/sdX since 2.6.3x
Do you have all the necessary config options set for boot from CF?
You need the block (pcmcia, pata, ..) devices and the filesystems
built in kernel.

Cheers

Andrea

> I also tried initrd. Same problem.
>
> I also tried rootfs from narcissus. Same problem.
>
>
>
> I appreciate any help.
>
>
>
> Thanks.
>
>
>
> Regards
>
>
>
> Juergen
>
>
>
> 
>
> Menu.lst :
>
> 
>
> serial --unit=0 --speed=57600
>
> terminal --timeout=1 serial console
>
> default 0
>
>
>
> # tell grub to find the kernel on /dev/hda1
>
> root (hd0,0)
>
> savedefault
>
>
>
> # start menu entry with title
>
> title OpenEmbedded GNU/Linux
>
>
>
> title New OE serial console
>
> root (hd0,0)
>
> kernel /boot/bzImage-3.2.11-yocto-standard serialconsole root=/dev/hdb1
> init=/sbin/init console=tty0 console=ttyS0,57600n8
>
> savedefault
>
>
>
>
>
> 
>
> KERNEL Output:
>
> 
>
>   Booting 'New OE serial console'
>
>
>
> root (hd0,0)
>
> Filesystem type is ext2fs, partition type 0x83
>
> kernel /boot/bzImage-3.2.11-yocto-standard serialconsole root=/dev/hdb1
> init=/s
>
> bin/init console=tty0 console=ttyS0,57600n8
>
>    [Linux-bzImage, setup=0x3a00, size=0x441020]
>
> savedefault
>
>
>
> Initializing cgroup subsys cpuset
>
> Initializing cgroup subsys cpu
>
> Linux version 3.2.11-yocto-standard (blabla@blabla-virtual-machine) (gcc
> version 4.6.4 20120303 (prerelea2
>
> BIOS-provided physical RAM map:
>
> BIOS-e820:  - 0009e000 (usable)
>
> BIOS-e820: 0009e000 - 000a (reserved)
>
> BIOS-e820: 000f - 0010 (reserved)
>
> BIOS-e820: 0010 - 0f7c (usable)
>
> BIOS-e820:  - 0001 (reserved)
>
> Notice: NX (Execute Disable) protection missing in CPU!
>
> DMI 2.2 present.
>
> last_pfn = 0xf7c0 max_arch_pfn = 0x10
>
> init_memory_mapping: -0f7c
>
> ACPI Error: A valid RSDP was not found (20110623/tbxfroot-219)
>
> 0MB HIGHMEM available.
>
> 247MB LOWMEM available.
>
>   mapped low ram: 0 - 0f7c
>
>   low ram: 0 - 0f7c
>
> Zone PFN ranges:
>
>   DMA  0x0010 -> 0x1000
>
>   Normal   0x1000 -> 0xf7c0
>
>   HighMem  empty
>
> Movable zone start PFN for each node
>
> early_node_map[2] active PFN ranges
>
>     0: 0x0010 -> 0x009e
>
>     0: 0x0100 -> 0xf7c0
>
> Using APIC driver default
>
> SMP: Allowing 1 CPUs, 0 hotplug CPUs
>
> No local APIC present or hardware disabled
>
> APIC: disable apic facility
>
> APIC: switched to apic NOOP
>
> Allocating PCI resources starting at f7c (gap: f7c:f083)
>
> setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1
>
> PERCPU: Embedded 13 pages/cpu @cf00 s29056 r0 d24192 u4194304
>
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 62814
>
> Kernel command line: serialconsole root=/dev/hdb1 init=/sbin/init
> console=tty0 console=ttyS0,57600n8
>
> PID hash table entries: 1024 (order: 0, 4096 bytes)
>
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
>
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
>
> Initializing CPU#0
>
> allocated 1014528 bytes of page_cgroup
>
> please try 'cgroup_disable=memory' option if you don't want memory cgroups
>
> Initializing HighMem for node 0 (:)
>
> Memory: 241100k/253696k available (5440k kernel code, 12140k reserved, 2458k
> data, 492k init, 0k highmem)
>
> virtual kernel memory layout:
>
>     fixmap  : 0xfff17000 - 0xf000   ( 928 kB)
>
>     pkmap   : 0xff80 - 0xffc0   (4096 kB)
>
>     vmalloc : 0xcffc - 0xff7fe000   ( 760 MB)
>
>     lowmem  : 0xc000 - 0xcf7c   ( 247 MB)
>
>   .init : 0xc17b7000 - 0xc1832000   ( 492 kB)
>
>   .data : 0xc1550219 - 0xc17b6a80   (2458 kB)
>
>   .text : 0xc100 - 0xc1550219   (5440 kB)
>
> Checking if this processor honours the WP bit even in supervisor mode...Ok.
>
> SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>
> Preemptible hierarchical RCU implementation.
>
> NR_IRQS:2304 nr_irqs:256 16
>
> Console: colour VGA+ 80x25
>
> console [tty0] enabled
>
> console [ttyS0] enabled
>
> Fast TSC calibration using PIT
>
> De

Re: [yocto] Help in building an ad-hoc qte image

[Andrea Adami]

On Tue, May 29, 2012 at 12:56 PM, Paul Eggleton
 wrote:
> On Tuesday 29 May 2012 12:25:27 marco.mongu...@exorint.it wrote:
>> let me rephrase for the sake of clearness.
>> This part of recipe:
>>
>> RDEPENDS_${PN}-base_ANOTHERBOARD  = " \
>>         libqt-embeddedphonon4 \
>>         qt4-embedded-plugin-phonon-backend-gstreamer \
>>         "
>>
>> has the ultimate goal of adding phonon + gstreamer backend
>> for ANOTHERBOARD only to the rootfs.
>> It appears ok. We normally do not get indeed phonon + gstreamer backend.
>>

and btw this doesn't look right to me.

maybe you meant

>> RDEPENDS_${PN}-base_append_ANOTHERBOARD  = " \

Finally, it looks like you could easily workaround your problem by
defining a specific recipe for ANOTHERBOARD.

Regards

Andrea

P.S.: try bitbake -g XYZ  or   bitbake -g -u depexp XYZ  to quickly
inspect dependencies



>> The issue is that we get contents of
>> meta\recipes-multimedia\gstreamer\gstreamer_0.10.36.bb
>> (see original post for listing) in the rootfs and do not get what pull
>> them in.
>
> Ah, right, now I understand the question. So you've asked for task-qt4e-xyz-
> base to be installed, and task-qt4e-xyz-base for ANOTHERBOARD RDEPENDS upon
> qt4-embedded-plugin-phonon-backend-gstreamer. The "missing link" is that in
> do_package we have some code to analyse shared libraries (.so) that are going
> into a package in order to detect which other shared libraries they need, and
> if any are found we look to see which package provides them and automatically
> add that package to RDEPENDS. Thus we look at the .so files in qt4-embedded-
> plugin-phonon-backend-gstreamer and determine from them that gstreamer is
> required, thus gstreamer (along with libgstaudio and libgstvideo) is added to
> RDEPENDS. See classes/package.bbclass if you want to see the code for this
> (look for shlibdeps).
>
> Note that sometimes this highlights problems with package granularity - I
> don't know enough about gstreamer to know if any of the files currently in the
> "gstreamer" package could actually be separated out if they aren't desired in
> some installations. Occasionally as a result we do split packages further to
> avoid unnecessary files being installed for all situations.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> ___
> 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] initramfs image

[Andrea Adami]

On Wed, May 9, 2012 at 8:44 PM, Andrea Adami  wrote:
> On Wed, May 9, 2012 at 8:18 PM, Darren Hart  wrote:
>>
>>
>> On 05/08/2012 06:54 PM, Manuel Bessler wrote:
>>> Hi,
>>>
>>> I'm trying to figure out how to build an image of type initramfs, ie.
>>> kernel with built-in rootfs.
>>> I've got a rootfs.cpio.gz in build/tmp/deploy/images. But how do I
>>> tell the kernel to actually use it
>>> and "swallow in" the rootfs.
>>
>> This isn't currently supported. The problem is the kernel would have to
>> wait for the image to be completed, and the image currently waits for
>> the kernel to be completed. In practice, this is often done in two
>> stages, the kernel is built, the rootfs is built, then the kernel is
>> rebuilt. This workflow has not been configured for OE/Yocto yet. If this
>> is an important feature for you, please consider opening a feature request.
>>
>> Regards,
>>
>> Darren Hart
>>
>>>
>>> I've found a few variable that have to do with initramfs', but there
>>> are no simple examples,
>>> and for some variables I've not found any examples nor documentation at all.
>>>
>>> in  .../images/myimage-initramfs.bb I have:
>>> require myimage.bb
>>> INITRAMFS_FSTYPES = "cpio.gz"
>>> IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
>>>
>>> In the same file I tried to set INITRAMFS_IMAGE to:
>>> INITRAMFS_IMAGE = "myimage "
>>>
>>>
>>> Do I need to set CONFIG_INITRAMFS_SOURCE in my kernel config manually,
>>> and if yes, to what?
>>> My kernel recipe is (for now) a simple kernel build, ie "inherit
>>> kernel"-based only.
>>>
>>> Am I using INITRAMFS_IMAGE the right way? What about INITRAMFS_TASK ?
>>> I could not find any information on this variable
>>>
>>> I'm using yocto 1.2.
>>>
>>>
>>> Does anyone have a simple example on how to build a kernel with
>>> initramfs built in?
>>>
>>> I'd appreciate any help.
>>> Thanks,
>>> Manuel
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>> --
>> Darren Hart
>> Intel Open Source Technology Center
>> Yocto Project - Linux Kernel
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
> I think I've answered a similar question last week.
>
> Pls. see  this thread:
> https://lists.yoctoproject.org/pipermail/yocto/2012-May/008625.htmlsimilar
> question was answ
>
> Regards
>
> Andrea

Bad copy&paste :/ sry

 https://lists.yoctoproject.org/pipermail/yocto/2012-May/008625.html
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] initramfs image

[Andrea Adami]

On Wed, May 9, 2012 at 8:18 PM, Darren Hart  wrote:
>
>
> On 05/08/2012 06:54 PM, Manuel Bessler wrote:
>> Hi,
>>
>> I'm trying to figure out how to build an image of type initramfs, ie.
>> kernel with built-in rootfs.
>> I've got a rootfs.cpio.gz in build/tmp/deploy/images. But how do I
>> tell the kernel to actually use it
>> and "swallow in" the rootfs.
>
> This isn't currently supported. The problem is the kernel would have to
> wait for the image to be completed, and the image currently waits for
> the kernel to be completed. In practice, this is often done in two
> stages, the kernel is built, the rootfs is built, then the kernel is
> rebuilt. This workflow has not been configured for OE/Yocto yet. If this
> is an important feature for you, please consider opening a feature request.
>
> Regards,
>
> Darren Hart
>
>>
>> I've found a few variable that have to do with initramfs', but there
>> are no simple examples,
>> and for some variables I've not found any examples nor documentation at all.
>>
>> in  .../images/myimage-initramfs.bb I have:
>> require myimage.bb
>> INITRAMFS_FSTYPES = "cpio.gz"
>> IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
>>
>> In the same file I tried to set INITRAMFS_IMAGE to:
>> INITRAMFS_IMAGE = "myimage "
>>
>>
>> Do I need to set CONFIG_INITRAMFS_SOURCE in my kernel config manually,
>> and if yes, to what?
>> My kernel recipe is (for now) a simple kernel build, ie "inherit
>> kernel"-based only.
>>
>> Am I using INITRAMFS_IMAGE the right way? What about INITRAMFS_TASK ?
>> I could not find any information on this variable
>>
>> I'm using yocto 1.2.
>>
>>
>> Does anyone have a simple example on how to build a kernel with
>> initramfs built in?
>>
>> I'd appreciate any help.
>> Thanks,
>> Manuel
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


I think I've answered a similar question last week.

Pls. see  this thread:
https://lists.yoctoproject.org/pipermail/yocto/2012-May/008625.htmlsimilar
question was answ

Regards

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

[yocto] Fwd: Need help for building kernel image with embeddedinitramfs.cpio

[Andrea Adami]

I've realized my answer was not sent to the list.

I'll do it now, being the subject may be of interest.

Andrea


-- Forwarded message ------
From: Andrea Adami 
Date: Thu, May 3, 2012 at 6:24 PM
Subject: Re: [yocto] Need help for building kernel image with
embeddedinitramfs.cpio
To: giovanni.pav...@exorint.it


On Thu, May 3, 2012 at 6:00 PM,   wrote:
> Thanks for your suggestion. I have not yet tried with kernel modules
> but the whole build sequence appears fine and the output is running.
>
> I am hitting a problem thought with step 3
>
> I have this layout (meta-mylayer is parallel to meta-yocto):
>
> meta-mylayer/conf/machine/mymachine.conf
> meta-mylayer/recipes-kernel/linux/linux.inc
> meta-mylayer/recipes-kernel/linux/linux_2.6.37.bb
> meta-mylayer/recipes-kernel/linux/linux_2.6.37/mymachine/defconfig
>
> linux.inc inherit from kernel and I am setting
> PREFERRED_PROVIDER_virtual/kernel = "linux"
> PREFERRED_VERSION_linux ?= "2.6.37"
> in mymachine.conf.
>
> This builds and deploys a uImage-mymachine-"stamp1".bin fine for mymachine.
>
> I added a kernel recipe in my recipe-kernel layer
> like this:
>
> meta-mylayer/recipes-kernel/linux/linuxramfs_2.6.37.bb
> meta-mylayer/recipes-kernel/linux/linuxramfs_2.6.37/mymachine/defconfig
>
> in linuxramfs_2.6.37/mymachine/defconfig I patched all options for ramfs
> (source / compression etc)
> and tweaked linuxramfs_2.6.37.bb as per your indication (starting from the
> linux_2.6.37.bb
> I had up and running).
>
> Problems:
>
> 1. when I run "bitbake linuxramfs" I get
> "ERROR: Multiple .bb files are due to be built which each provide
> virtual/kernel"
>
> I am seeing multiple reference on the net about this error but I am not
> understanding
> how to handle. Both linuxramfs_2.6.37.bb and linux_2.6.37.bb are providing
> virtual/kernel.
>
this can be solved adding  PROVIDES = ""
(see the kexecboot kernels linked above)

> 2. "bitbake linuxramfs" deploys a uImage-mymachine-"stamp2".bin
> To overwrite this in a way I get a uImage-ramfs-mymachine-"stampxxx".bin
> (so that I can easily identify it against a normal uImage - only kernel)
> what do_* task should I reimplement in my linuxramfs_2.6.37.bb recipe?
>
KERNEL_IMAGE_BASE_NAME
KERNEL_IMAGE_SYMLINK_NAME

see:
http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-kernel/linux/linux-yocto-tiny-kexecboot_3.2.bb

> Thanks in advance for your attention
>
YW

Cheers

Andrea (from Verona)

> Giovanni Pavoni
> R&D Department
>
> Exor International S.p.A.
> Via Monte Fiorino,9
> I-37057 San Giovanni Lupatoto (VR)
> Phone:+390458774839 - Fax:+390458779023
>
> giovanni.pav...@exorint.it - www.exorint.net - www.exorint.it
>
>
> ATTENZIONE: Privacy Policy – D.Lgs. 196/2003
>  Le informazioni contenute in questo messaggio di posta elettronica sono di
> carattere privato e confidenziale ed esclusivamente rivolte al destinatario
> sopra indicato. Nel caso aveste ricevuto questo messaggio di posta
> elettronica per errore, vi comunichiamo che ai sensi del suddetto decreto è
> vietato l’uso, la diffusione, distribuzione o riproduzione da parte di ogni
> altra persona. Siete pregati di segnalarlo immediatamente rispondendo al
> mittente e di distruggere quanto ricevuto (compresi i file allegati) senza
> farne copia o leggerne il contenuto.
>
> This e-mail transmission contains information that is confidential and may
> be privileged. It is intended only for the addressee(s) named above. If you
> receive this e-mail in error, please do not read, copy or disseminate it in
> any manner. If you are not the intended recipient, any disclosure, copying,
> distribution or use of the contents of this information is prohibited.
> Please reply to the message immediately by informing the sender that the
> message was misdirected. After replying, please erase it from your computer
> system. Your assistance in correcting this error is appreciated.
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Need help for building kernel image with embedded initramfs.cpio

[Andrea Adami]

On Thu, May 3, 2012 at 12:22 PM,   wrote:
> Dear Sirs,
>
> for my cortex A8 based system, I am in the need to deploy
> a sort of "safe mode image" that should bootstrap only
> in case of system recovery.
>
> This image fits particularily well the model of a ramfs based system
> with contents such as core-image-minimal-mtdutils plus some tools addition.
>
> I defined a "myimage.bb" recipe for this image that generates a
> "myimage.cpio"
>
> However I am in the need to:
>
> 1. establish in myimage.bb a relation with virtual/kernel and ask to
> generate
> kernel modules only.
>
> 2. retrieve modules only from the kernel staging area and made them part of
> "myimage.cpio"
>
> 3. change the config of my kernel to add CONFIG_INITRAMFS_SOURCE =
> "myimage.cpio"
> and copy myimage.cpio from staging area to kernel build location.
>
> 4. build kernel and deploy the emitted uImage as "mykernel+myimage"
>
> Anyone can help with suggestions/guidelines and/or codesnips?
>
Hi Giovanni,

we have already done something similar for kexecboot project.
You need:

1) set in your $machine.conf :
INITRAMFS_FSTYPES ?= "cpio.gz cpio.lzma"
KERNEL_IMAGETYPE ?= "uImage"

2) a XYZ-image.bb recipe for the image which will be the cpio containing:
IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
and custom  IMAGE_INSTALL = "your list of packages and modules"
For the modules you can use kernel-modules meta-package or the single
kernel-module xyz.

3) a recipe for the kernel containing the line:
INITRAMFS_IMAGE = "XYZ-image"

This will be embedded in the kernel.


> Kind regards
>

Cheers
Andrea


>
> Giovanni Pavoni
> R&D Department
>
> Exor International S.p.A.
> Via Monte Fiorino,9
> I-37057 San Giovanni Lupatoto (VR)
> Phone:+390458774839 - Fax:+390458779023
>
> giovanni.pav...@exorint.it - www.exorint.net - www.exorint.it
>
>
> ATTENZIONE: Privacy Policy – D.Lgs. 196/2003
>  Le informazioni contenute in questo messaggio di posta elettronica sono di
> carattere privato e confidenziale ed esclusivamente rivolte al destinatario
> sopra indicato. Nel caso aveste ricevuto questo messaggio di posta
> elettronica per errore, vi comunichiamo che ai sensi del suddetto decreto è
> vietato l’uso, la diffusione, distribuzione o riproduzione da parte di ogni
> altra persona. Siete pregati di segnalarlo immediatamente rispondendo al
> mittente e di distruggere quanto ricevuto (compresi i file allegati) senza
> farne copia o leggerne il contenuto.
>
> This e-mail transmission contains information that is confidential and may
> be privileged. It is intended only for the addressee(s) named above. If you
> receive this e-mail in error, please do not read, copy or disseminate it in
> any manner. If you are not the intended recipient, any disclosure, copying,
> distribution or use of the contents of this information is prohibited.
> Please reply to the message immediately by informing the sender that the
> message was misdirected. After replying, please erase it from your computer
> system. Your assistance in correcting this error is appreciated.
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto