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(_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"
> > NATIVELSBSTRI

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(_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/kernel-module-nls-cp1251-4.14.62-handheld_4.14-r0_akita.ipk.
Installing kernel-mo
ERROR: 

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(_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(_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
<gwil...@sakuraus.com> 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 <gwil...@sakuraus.com>
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Problem with populate_sdk
>>
>> On Thu, Oct 19, 2017 at 8:26 PM, Greg Wilson-Lindberg
>> <gwil...@sakuraus.com> 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
dwatk...@sierrawireless.com 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
vincent.ri...@imgtec.com 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 b...@bsmucker.eu.org 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 b...@bsmucker.eu.org
 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 b...@bsmucker.eu.org 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 sasikanth@gmail.com 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 diego.sue...@gmail.com wrote:

 2013/10/28 Bruce Ashfield bruce.ashfi...@windriver.com

 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 machine subdir?

recipes-kernel/linux/linux-yocto-3.2/machine
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
bruce.ashfi...@windriver.com wrote:
 On 13-10-17 09:15 AM, Diego Sueiro wrote:


 2013/10/17 Bruce Ashfield bruce.ashfi...@windriver.com
 mailto:bruce.ashfi...@windriver.com




 I expected to get this working out-of-box.


 Did you do a  bitbake -e your kernel recipe ? 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 http://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
rstr...@linuxfoundation.org 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 diego.sue...@gmail.com
 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 marti...@gmail.com 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 1:07 PM, Jürgen Messerer
juergen.messe...@bbv.ch 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

 Detected 499.922 MHz processor.

 Calibrating delay loop (skipped), value calculated using timer frequency..
 999.84 BogoMIPS (lpj=1999688)

 pid_max: default: 32768 minimum: 301

 Security Framework initialized

 

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

[Andrea Adami]

On Tue, Jun 12, 2012 at 2:04 PM, Andrea Adami andrea.ad...@gmail.com wrote:
 On Tue, Jun 12, 2012 at 1:07 PM, Jürgen Messerer
 juergen.messe...@bbv.ch 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

 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

 Detected 499.922 MHz processor

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

[Andrea Adami]

On Tue, May 29, 2012 at 12:56 PM, Paul Eggleton
paul.eggle...@linux.intel.com 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

[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 andrea.ad...@gmail.com
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,  giovanni.pav...@exorint.it 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
 RD 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] initramfs image

[Andrea Adami]

On Wed, May 9, 2012 at 8:18 PM, Darren Hart dvh...@linux.intel.com 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

Re: [yocto] initramfs image

[Andrea Adami]

On Wed, May 9, 2012 at 8:44 PM, Andrea Adami andrea.ad...@gmail.com wrote:
 On Wed, May 9, 2012 at 8:18 PM, Darren Hart dvh...@linux.intel.com 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 copypaste :/ 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] Need help for building kernel image with embedded initramfs.cpio

[Andrea Adami]

On Thu, May 3, 2012 at 12:22 PM,  giovanni.pav...@exorint.it 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
 RD 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