[yocto] BeagleBone with meta-ti layer
Hello everyone, I will soon be receiving a Beaglebone and I wish to transfer the work I have been doing with Yocto on the Beagleboard over to the Beaglebone, to show my company how the same application codebase can be run different platforms using Linux/Yocto/etc.. I have been looking at the meta-ti layer and trying to figure out how it works and how I will integrate it into the yocto build environment, but I thought I would just throw a query out to see if anybody is doing this and if there are any pitfalls I should avoid. It would also be nice to transfer the beagleboard onto the meta-ti config as is it manufacturer supported, is anyone doing this? Cheers, Jack. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BeagleBone with meta-ti layer
Op 26 jan. 2012, om 12:06 heeft Jack Mitchell het volgende geschreven: > Hello everyone, > > I will soon be receiving a Beaglebone and I wish to transfer the work I have > been doing with Yocto on the Beagleboard over to the Beaglebone, to show my > company how the same application codebase can be run different platforms > using Linux/Yocto/etc.. > > I have been looking at the meta-ti layer and trying to figure out how it > works and how I will integrate it into the yocto build environment, but I > thought I would just throw a query out to see if anybody is doing this and if > there are any pitfalls I should avoid. There's a README in the meta-ti layer, follow the instructions in there. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BeagleBone with meta-ti layer
On 26/01/12 12:00, Koen Kooi wrote: Op 26 jan. 2012, om 12:06 heeft Jack Mitchell het volgende geschreven: Hello everyone, I will soon be receiving a Beaglebone and I wish to transfer the work I have been doing with Yocto on the Beagleboard over to the Beaglebone, to show my company how the same application codebase can be run different platforms using Linux/Yocto/etc.. I have been looking at the meta-ti layer and trying to figure out how it works and how I will integrate it into the yocto build environment, but I thought I would just throw a query out to see if anybody is doing this and if there are any pitfalls I should avoid. There's a README in the meta-ti layer, follow the instructions in there. Hi Koen, I understand that there is a readme in the meta-ti layer however this refers specifically to using Angstrom and associated layers, where as I want to build specifically for yocto. So I was looking for pointers for abstracting the meta-ti layer form angstrom over to Yocto. Regards, Jack. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BeagleBone with meta-ti layer
On 2012-01-26 05:01, Jack Mitchell wrote:
On 26/01/12 12:00, Koen Kooi wrote:
Op 26 jan. 2012, om 12:06 heeft Jack Mitchell het volgende geschreven:
Hello everyone,
I will soon be receiving a Beaglebone and I wish to transfer the work I have
been doing with Yocto on the Beagleboard over to the Beaglebone, to show my
company how the same
application codebase can be run different platforms using Linux/Yocto/etc..
I have been looking at the meta-ti layer and trying to figure out how it works
and how I will integrate it into the yocto build environment, but I thought I
would just throw a
query out to see if anybody is doing this and if there are any pitfalls I
should avoid.
There's a README in the meta-ti layer, follow the instructions in there.
Hi Koen,
I understand that there is a readme in the meta-ti layer however this refers
specifically to using Angstrom and associated layers, where as I want to build
specifically for yocto.
So I was looking for pointers for abstracting the meta-ti layer form angstrom
over to Yocto.
I gave this a try, just adding the meta-ti layer into my stack.
Sadly, it blew up right away with this error:
ERROR: Failure expanding variable FILESPATH, expression was ${@base_contains('DISTRO_FEATURES', 'tipspkernel',
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kern
el/linux/linux-ti33x-psp-3.1/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti/re
cipes-kernel/linux/linux-ti33x-psp/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti/reci
pes-kernel/linux/files/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/:",
"", d)}${@base_set_filespath([ "/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1-r0",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1", "/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1", "/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/files", "/home/local/poky-multi/meta-ti/recipes-kernel/linux" ], d)} which triggered exceptio
Re: [yocto] BeagleBone with meta-ti layer
On 2012-01-26 05:35, Gary Thomas wrote:
On 2012-01-26 05:01, Jack Mitchell wrote:
On 26/01/12 12:00, Koen Kooi wrote:
Op 26 jan. 2012, om 12:06 heeft Jack Mitchell het volgende geschreven:
Hello everyone,
I will soon be receiving a Beaglebone and I wish to transfer the work I have
been doing with Yocto on the Beagleboard over to the Beaglebone, to show my
company how the same
application codebase can be run different platforms using Linux/Yocto/etc..
I have been looking at the meta-ti layer and trying to figure out how it works
and how I will integrate it into the yocto build environment, but I thought I
would just throw a
query out to see if anybody is doing this and if there are any pitfalls I
should avoid.
There's a README in the meta-ti layer, follow the instructions in there.
Hi Koen,
I understand that there is a readme in the meta-ti layer however this refers
specifically to using Angstrom and associated layers, where as I want to build
specifically for yocto.
So I was looking for pointers for abstracting the meta-ti layer form angstrom
over to Yocto.
I gave this a try, just adding the meta-ti layer into my stack.
Sadly, it blew up right away with this error:
ERROR: Failure expanding variable FILESPATH, expression was
${@base_contains('DISTRO_FEATURES', 'tipspkernel',
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-ke
rn
el/linux/linux-ti33x-psp-3.1/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti/
re
cipes-kernel/linux/linux-ti33x-psp/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti/re
ci
pes-kernel/linux/files/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/:",
"", d)}${@base_set_filespath([
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1-r0",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/files",
"/home/local/poky-multi/meta-ti/r
Re: [yocto] BeagleBone with meta-ti layer
On 26/01/12 13:27, Gary Thomas wrote:
On 2012-01-26 05:35, Gary Thomas wrote:
On 2012-01-26 05:01, Jack Mitchell wrote:
On 26/01/12 12:00, Koen Kooi wrote:
Op 26 jan. 2012, om 12:06 heeft Jack Mitchell het volgende geschreven:
Hello everyone,
I will soon be receiving a Beaglebone and I wish to transfer the
work I have been doing with Yocto on the Beagleboard over to the
Beaglebone, to show my company how the same
application codebase can be run different platforms using
Linux/Yocto/etc..
I have been looking at the meta-ti layer and trying to figure out
how it works and how I will integrate it into the yocto build
environment, but I thought I would just throw a
query out to see if anybody is doing this and if there are any
pitfalls I should avoid.
There's a README in the meta-ti layer, follow the instructions in
there.
Hi Koen,
I understand that there is a readme in the meta-ti layer however
this refers specifically to using Angstrom and associated layers,
where as I want to build specifically for yocto.
So I was looking for pointers for abstracting the meta-ti layer form
angstrom over to Yocto.
I gave this a try, just adding the meta-ti layer into my stack.
Sadly, it blew up right away with this error:
ERROR: Failure expanding variable FILESPATH, expression was
${@base_contains('DISTRO_FEATURES', 'tipspkernel',
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-k
e
rn
el/linux/linux-ti33x-psp-3.1/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti
/
re
cipes-kernel/linux/linux-ti33x-psp/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti/r
e
ci
pes-kernel/linux/files/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/:",
"", d)}${@base_set_filespath([
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1-r0",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp",
"/home/local/poky-multi/meta-ti/recipes
Re: [yocto] BeagleBone with meta-ti layer
On 2012-01-26 06:50, Jack Mitchell wrote:
On 26/01/12 13:27, Gary Thomas wrote:
On 2012-01-26 05:35, Gary Thomas wrote:
On 2012-01-26 05:01, Jack Mitchell wrote:
On 26/01/12 12:00, Koen Kooi wrote:
Op 26 jan. 2012, om 12:06 heeft Jack Mitchell het volgende geschreven:
Hello everyone,
I will soon be receiving a Beaglebone and I wish to transfer the work I have
been doing with Yocto on the Beagleboard over to the Beaglebone, to show my
company how the same
application codebase can be run different platforms using Linux/Yocto/etc..
I have been looking at the meta-ti layer and trying to figure out how it works
and how I will integrate it into the yocto build environment, but I thought I
would just throw a
query out to see if anybody is doing this and if there are any pitfalls I
should avoid.
There's a README in the meta-ti layer, follow the instructions in there.
Hi Koen,
I understand that there is a readme in the meta-ti layer however this refers
specifically to using Angstrom and associated layers, where as I want to build
specifically for yocto.
So I was looking for pointers for abstracting the meta-ti layer form angstrom
over to Yocto.
I gave this a try, just adding the meta-ti layer into my stack.
Sadly, it blew up right away with this error:
ERROR: Failure expanding variable FILESPATH, expression was
${@base_contains('DISTRO_FEATURES', 'tipspkernel',
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-
k
e
rn
el/linux/linux-ti33x-psp-3.1/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-t
i
/
re
cipes-kernel/linux/linux-ti33x-psp/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti/
r
e
ci
pes-kernel/linux/files/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/:",
"", d)}${@base_set_filespath([
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1-r0",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-
Re: [yocto] BeagleBone with meta-ti layer
On 2012-01-26 07:06, Gary Thomas wrote:
On 2012-01-26 06:50, Jack Mitchell wrote:
On 26/01/12 13:27, Gary Thomas wrote:
On 2012-01-26 05:35, Gary Thomas wrote:
On 2012-01-26 05:01, Jack Mitchell wrote:
On 26/01/12 12:00, Koen Kooi wrote:
Op 26 jan. 2012, om 12:06 heeft Jack Mitchell het volgende geschreven:
Hello everyone,
I will soon be receiving a Beaglebone and I wish to transfer the work I have
been doing with Yocto on the Beagleboard over to the Beaglebone, to show my
company how the same
application codebase can be run different platforms using Linux/Yocto/etc..
I have been looking at the meta-ti layer and trying to figure out how it works
and how I will integrate it into the yocto build environment, but I thought I
would just throw a
query out to see if anybody is doing this and if there are any pitfalls I
should avoid.
There's a README in the meta-ti layer, follow the instructions in there.
Hi Koen,
I understand that there is a readme in the meta-ti layer however this refers
specifically to using Angstrom and associated layers, where as I want to build
specifically for
yocto.
So I was looking for pointers for abstracting the meta-ti layer form angstrom
over to Yocto.
I gave this a try, just adding the meta-ti layer into my stack.
Sadly, it blew up right away with this error:
ERROR: Failure expanding variable FILESPATH, expression was
${@base_contains('DISTRO_FEATURES', 'tipspkernel',
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes
-
k
e
rn
el/linux/linux-ti33x-psp-3.1/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-
t
i
/
re
cipes-kernel/linux/linux-ti33x-psp/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti
/
r
e
ci
pes-kernel/linux/files/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/:",
"", d)}${@base_set_filespath([
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1-r0",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1",
"/hom
Re: [yocto] BeagleBone with meta-ti layer
On 2012-01-26 08:07, Gary Thomas wrote:
On 2012-01-26 07:06, Gary Thomas wrote:
On 2012-01-26 06:50, Jack Mitchell wrote:
On 26/01/12 13:27, Gary Thomas wrote:
On 2012-01-26 05:35, Gary Thomas wrote:
On 2012-01-26 05:01, Jack Mitchell wrote:
On 26/01/12 12:00, Koen Kooi wrote:
Op 26 jan. 2012, om 12:06 heeft Jack Mitchell het volgende geschreven:
Hello everyone,
I will soon be receiving a Beaglebone and I wish to transfer the work I have
been doing with Yocto on the Beagleboard over to the Beaglebone, to show my
company how the same
application codebase can be run different platforms using Linux/Yocto/etc..
I have been looking at the meta-ti layer and trying to figure out how it works
and how I will integrate it into the yocto build environment, but I thought I
would just throw a
query out to see if anybody is doing this and if there are any pitfalls I
should avoid.
There's a README in the meta-ti layer, follow the instructions in there.
Hi Koen,
I understand that there is a readme in the meta-ti layer however this refers
specifically to using Angstrom and associated layers, where as I want to build
specifically for
yocto.
So I was looking for pointers for abstracting the meta-ti layer form angstrom
over to Yocto.
I gave this a try, just adding the meta-ti layer into my stack.
Sadly, it blew up right away with this error:
ERROR: Failure expanding variable FILESPATH, expression was
${@base_contains('DISTRO_FEATURES', 'tipspkernel',
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipe
s
-
k
e
rn
el/linux/linux-ti33x-psp-3.1/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta
-
t
i
/
re
cipes-kernel/linux/linux-ti33x-psp/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-t
i
/
r
e
ci
pes-kernel/linux/files/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/:",
"", d)}${@base_set_filespath([
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1-r0",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp",
"/home/local/poky-multi/met
Re: [yocto] BeagleBone with meta-ti layer
On 26/01/12 15:24, Gary Thomas wrote:
On 2012-01-26 08:07, Gary Thomas wrote:
On 2012-01-26 07:06, Gary Thomas wrote:
On 2012-01-26 06:50, Jack Mitchell wrote:
On 26/01/12 13:27, Gary Thomas wrote:
On 2012-01-26 05:35, Gary Thomas wrote:
On 2012-01-26 05:01, Jack Mitchell wrote:
On 26/01/12 12:00, Koen Kooi wrote:
Op 26 jan. 2012, om 12:06 heeft Jack Mitchell het volgende
geschreven:
Hello everyone,
I will soon be receiving a Beaglebone and I wish to transfer
the work I have been doing with Yocto on the Beagleboard over
to the Beaglebone, to show my company how the same
application codebase can be run different platforms using
Linux/Yocto/etc..
I have been looking at the meta-ti layer and trying to figure
out how it works and how I will integrate it into the yocto
build environment, but I thought I would just throw a
query out to see if anybody is doing this and if there are any
pitfalls I should avoid.
There's a README in the meta-ti layer, follow the instructions
in there.
Hi Koen,
I understand that there is a readme in the meta-ti layer however
this refers specifically to using Angstrom and associated
layers, where as I want to build specifically for
yocto.
So I was looking for pointers for abstracting the meta-ti layer
form angstrom over to Yocto.
I gave this a try, just adding the meta-ti layer into my stack.
Sadly, it blew up right away with this error:
ERROR: Failure expanding variable FILESPATH, expression was
${@base_contains('DISTRO_FEATURES', 'tipspkernel',
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recip
e
s
-
k
e
rn
el/linux/linux-ti33x-psp-3.1/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/met
a
-
t
i
/
re
cipes-kernel/linux/linux-ti33x-psp/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp/tipspkernel/:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/linux-gnueabi:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/arm:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/build-linux:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/pn-linux-ti33x-psp:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/beaglebone:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/armv7a:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/amltd:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/forcevariable:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/${FEED_ARCH}:/home/local/poky-multi/meta-
t
i
/
r
e
ci
pes-kernel/linux/files/tipspkernel/ti33x:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/libc-glibc:/home/local/poky-multi/meta-ti/recipes-kernel/linux/files/tipspkernel/:",
"", d)}${@base_set_filespath([
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1-r0",
"/home/local/poky-multi/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.1",
"/home/local/poky-multi/meta-ti/recip
Re: [yocto] BeagleBone with meta-ti layer
I grabbed a bag of chips and a beverage ... watching this thread! I'm right behind you guys so thanks for blazing the trail. I have other TI parts to work with but starting with first BeagleBoard (& BeagleBone) since that is the reference. Regards, Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to get opkg in rootfilesystem
On Thu, Jan 26, 2012 at 12:51 AM, Khem Raj wrote: > add package-management to your image > EXTRA_IMAGE_FEATURES_append_pn- = " > package-management" Hi Khem, Just want to make sure I'm following you. In my local.conf I have: EXTRA_IMAGE_FEATURES_append_pn-core-image-base = "package-management" Maybe my google-fu is lacking but I searched on EXTRA_IMAGE_FEATURES package-management and could find no examples so I don't know how in the would I would have ever found EXTRA_IMAGE_FEATURES_append_pn Can you also enlighten me on how this gets used ... I couldn't find where it was referenced from? I'm not used to opkg being left out of a base image. Seems counter productive to me. Thanks for your help ... I don't think I would have ever found that one! Regards, Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to get opkg in rootfilesystem
Update, I'm still not doing something right. I did a clean rebuild of core-image-base and a tar jtvf core-image-base-beagleboard.tar.bz2 reveals opkg stuff in /var/lib/opkg only. No opkg bin. I guess I'm still in shock over this. I mean why should I have to do anything other than: PACKAGE_CLASSES ?= "package_ipk" I mean, if I specify I want package_ipk in the "Package Management configuration" section, doesn't logic follow that the image would be created with opkg and some sample opkg.conf files? What use is it to generate all those .ipk's for the repository the build does without opkg being there? Regards, Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to get opkg in rootfilesystem
On Thu, Jan 26, 2012 at 8:36 AM, Brian Hutchinson wrote: > Update, > > I'm still not doing something right. I did a clean rebuild of > core-image-base and a tar jtvf core-image-base-beagleboard.tar.bz2 > reveals opkg stuff in /var/lib/opkg only. No opkg bin. > > I guess I'm still in shock over this. I mean why should I have to do > anything other than: > PACKAGE_CLASSES ?= "package_ipk" this means thats what format you want for package to be spitted out. weather you want online (on device) package management is a different story > > I mean, if I specify I want package_ipk in the "Package Management > configuration" section, doesn't logic follow that the image would be > created with opkg and some sample opkg.conf files? What use is it to > generate all those .ipk's for the repository the build does without > opkg being there? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] understanding recipes
I'm trying to understand the concept of creating a recipe and having it
included in the build I do.
For example, suppose I want to create the meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello world
as shown in 3.1.2 Autotooled Package section of the Poky reference Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set correctly?
And what does the following line do or require me to do:
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
Is this all that is needed to get helloworld put into /usr/bin so it can
be executed at the command line when the image is booted?
Jim A
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to get opkg in rootfilesystem
On Thu, Jan 26, 2012 at 11:39 AM, Khem Raj wrote: > weather you want online (on device) package management is a different story OK, I want to hear that story :) Regards, Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to get opkg in rootfilesystem
On Thursday 26 January 2012 11:36:31 Brian Hutchinson wrote: > Update, > > I'm still not doing something right. I did a clean rebuild of > core-image-base and a tar jtvf core-image-base-beagleboard.tar.bz2 > reveals opkg stuff in /var/lib/opkg only. No opkg bin. > > I guess I'm still in shock over this. I mean why should I have to do > anything other than: > PACKAGE_CLASSES ?= "package_ipk" > > I mean, if I specify I want package_ipk in the "Package Management > configuration" section, doesn't logic follow that the image would be > created with opkg and some sample opkg.conf files? What use is it to > generate all those .ipk's for the repository the build does without > opkg being there? Not necessarily. The way our rootfs construction works, it has to be done via some package management backend, but many people don't want/need it in their final image. FYI some image recipes default to adding the package-management feature but core-image-base clearly does not. It's actually easier to enable this than Khem suggested, however. The default Yocto local.conf contains a line that sets EXTRA_IMAGE_FEATURES - just add package-management within this, and you'll get package management in your image. (FYI the reason his example probably didn't work when you tried it is I think you may have left out the initial space - the list is space-separated and _append does not add a space beforehand.) Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to get opkg in rootfilesystem
On 2012-01-26 09:36, Brian Hutchinson wrote: Update, I'm still not doing something right. I did a clean rebuild of core-image-base and a tar jtvf core-image-base-beagleboard.tar.bz2 reveals opkg stuff in /var/lib/opkg only. No opkg bin. I guess I'm still in shock over this. I mean why should I have to do anything other than: PACKAGE_CLASSES ?= "package_ipk" I mean, if I specify I want package_ipk in the "Package Management configuration" section, doesn't logic follow that the image would be created with opkg and some sample opkg.conf files? What use is it to generate all those .ipk's for the repository the build does without opkg being there? Because you asked to build an absolutely minimal root file system. In this case, it's expected that you don't want to have opkg available. If you still want this very minimal system *and* opkg, just add the package management as previously instructed. EXTRA_IMAGE_FEATURES += "package_management" -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding recipes
On 26/01/12 16:44, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and having
it included in the build I do.
For example, suppose I want to create the meta-intel/meta-cedartrail
BSP with the core-image-minimal image, but I wanted to include hello
world as shown in 3.1.2 Autotooled Package section of the Poky
reference Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa directory
at the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set correctly?
And what does the following line do or require me to do:
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#usingpoky-configuring-LIC_FILES_CHKSUM
Is this all that is needed to get helloworld put into /usr/bin so it
can be executed at the command line when the image is booted?
Jim A
___
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] [meta-intel] [PATCH 0/1] meta-cedartrail: Add smp feature for rt kernel build
From: Kishore Bodke Hi, The patch is for enabling the smp feature for the rt kernel build for the Cedartrail BSP. Please pull into master. Thanks Kishore. The following changes since commit 3f86785a9a510773ca9eb7b31903f90ac78a297e: meta-cedartrail: update linux-yocto-3.0 SRCREVs (2012-01-24 23:04:15 -0600) are available in the git repository at: git://git.pokylinux.org/meta-intel-contrib kishore/enable-smp-rt-fix http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=kishore/enable-smp-rt-fix Kishore Bodke (1): meta-cedartrail: enable smp for linux-yocto-rt_3.0 .../linux/linux-yocto-rt_3.0.bbappend |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) -- 1.7.5.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-intel] [PATCH 1/1] meta-cedartrail: enable smp for linux-yocto-rt_3.0
From: Kishore Bodke
Add smp feature to linux-yocto-rt_3.0.
Signed-off-by: Kishore Bodke
---
.../linux/linux-yocto-rt_3.0.bbappend |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
b/meta-cedartrail/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
index 372b139..5a95d3e 100644
--- a/meta-cedartrail/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
+++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
@@ -2,6 +2,8 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
COMPATIBLE_MACHINE_cedartrail = "cedartrail"
KMACHINE_cedartrail = "cedartrail"
+KERNEL_FEATURES_append_cedartrail += " cfg/smp.scc"
+
# Update the following to use a different BSP branch or meta SRCREV
#KBRANCH_cedartrail = "yocto/standard/preempt-rt/base"
#SRCREV_machine_pn-linux-yocto-rt_cedartrail ?=
--
1.7.5.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to get opkg in rootfilesystem
On Thu, Jan 26, 2012 at 11:47 AM, Gary Thomas wrote: > On 2012-01-26 09:36, Brian Hutchinson wrote: > Because you asked to build an absolutely minimal root file system. > In this case, it's expected that you don't want to have opkg available. > If you still want this very minimal system *and* opkg, just add the > package management as previously instructed. > EXTRA_IMAGE_FEATURES += "package_management" I'm not building minimal. I built core-image-minimal and it truly was minimal. Nothing in /usr/lib! Next I build core-image-base. Most of the Angstrom & Arago images I've build that were minimal-ish had opkg. I know I should probably be doing this with recipes/layers but I'm not quite there yet. Here is my typical use case. I start with a base image (NFS mounted) and then install only the packages I need to a target for what I'm doing. For development, I'll include a bunch of things that are not in the rootfs of something that is shipped in a product. But for development, an engineer might be interested in trying something quick and it is nice to be able to do a opkg install and pull a package from a local repository quickly rather than me try to come up with a custom layer and wait hours for it to build. I'm doing a build now and it looks like it is pulling in some opkg stuff this time. I took the EXTRA_IMAGE_FEATURES_append_pn- = from Khem's email literal as I know enough about yocto to be dangerous at this point. ;) Ah, build just finish and a grep of the rootfs tar shows a /etc/opkg.conf and a opkg bin sym link so I'm good for the moment! Thank you all for showing me the way (again)! Regards, Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding recipes
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and having it
included in the build I do.
For example, suppose I want to create the meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello world
as shown in 3.1.2 Autotooled Package section of the Poky reference Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path to your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set correctly?
Those examples are defined in the bitbake classes you have in your base
layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES += "helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to get opkg in rootfilesystem
On Thu, Jan 26, 2012 at 10:53 AM, Brian Hutchinson wrote: > I'm not building minimal. I built core-image-minimal and it truly was > minimal. Nothing in /usr/lib! > > Next I build core-image-base. Most of the Angstrom & Arago images > I've build that were minimal-ish had opkg. Every distro defines their own policies for images and there ought to be differences its normal. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding recipes
On 01/26/2012 01:55 PM, Scott Garman wrote:
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and having it
included in the build I do.
For example, suppose I want to create the meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello world
as shown in 3.1.2 Autotooled Package section of the Poky reference
Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path to your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set correctly?
Those examples are defined in the bitbake classes you have in your
base layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES += "helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
I got the layer created like you said, but the test had a fetch problem
and it just locked up there. Had to control-C out of it. Console below:
jim@ubuntu-x64:/build/mycdv-minimal$ bitbake helloworld
Loading cache: 100%
|###| ETA: 00:00:00
Loaded 1037 entries from dependency cache.
OE Build Configuration:
BB_VERSION= "1.13.3"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "mycdv"
DISTRO= "poky"
DISTRO_VERSION= "1.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU= ""
meta
meta-yocto= "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
meta-mycdv= "edison:34478f24de65dd8de8a4c8b913a1458d82dac1fa"
meta-jfa = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 514 of 693 (ID: 4,
/home/jim/poky/meta-jfa/recipes-jfa/helloworld/helloworld.bb, do_fetch)
NOTE: package helloworld-1.0-r0: task do_fetch: Started
WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1413"; export
SSH_AUTH_SOCK="/tmp/keyring-2QW6yC/ssh"; export
GIT_CONFIG="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/etc/gitconfig";
export
PATH="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/build/mycdv-minimal/tmp/sysroots/mycdv/usr/bin/crossscripts:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux//bin:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/poky/scripts";
/usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P
/home/jim/yocto-downloads 'ftp://ftp.gnu.org/gnu/hello/hello-1.0.tar.gz'
failed with signal 8, output:
I don't see 1.0.tar on the ftp site. How do I control this?
Scott
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding recipes
On 01/26/2012 01:32 PM, jfabernathy wrote:
On 01/26/2012 01:55 PM, Scott Garman wrote:
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and having it
included in the build I do.
For example, suppose I want to create the meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello world
as shown in 3.1.2 Autotooled Package section of the Poky reference
Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path to your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set correctly?
Those examples are defined in the bitbake classes you have in your
base layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES += "helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
I got the layer created like you said, but the test had a fetch problem
and it just locked up there. Had to control-C out of it. Console below:
jim@ubuntu-x64:/build/mycdv-minimal$ bitbake helloworld
Loading cache: 100%
|###| ETA: 00:00:00
Loaded 1037 entries from dependency cache.
OE Build Configuration:
BB_VERSION = "1.13.3"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "mycdv"
DISTRO = "poky"
DISTRO_VERSION = "1.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-yocto = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
meta-mycdv = "edison:34478f24de65dd8de8a4c8b913a1458d82dac1fa"
meta-jfa = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 514 of 693 (ID: 4,
/home/jim/poky/meta-jfa/recipes-jfa/helloworld/helloworld.bb, do_fetch)
NOTE: package helloworld-1.0-r0: task do_fetch: Started
WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1413"; export
SSH_AUTH_SOCK="/tmp/keyring-2QW6yC/ssh"; export
GIT_CONFIG="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/etc/gitconfig";
export
PATH="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/build/mycdv-minimal/tmp/sysroots/mycdv/usr/bin/crossscripts:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux//bin:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/poky/scripts";
/usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P
/home/jim/yocto-downloads 'ftp://ftp.gnu.org/gnu/hello/hello-1.0.tar.gz'
failed with signal 8, output:
I don't see 1.0.tar on the ftp site. How do I control this?
If you look in:
ftp://ftp.gnu.org/gnu/hello/
you'll see which versions are available. Rename your recipe filename to
reflect the version you wish to use, for example helloworld_2.7.bb
The part of the filename after the underscore is what will get
interpolated into ${PV}.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/list
Re: [yocto] understanding recipes
On 01/26/2012 04:38 PM, Scott Garman wrote:
On 01/26/2012 01:32 PM, jfabernathy wrote:
On 01/26/2012 01:55 PM, Scott Garman wrote:
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and
having it
included in the build I do.
For example, suppose I want to create the
meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello world
as shown in 3.1.2 Autotooled Package section of the Poky reference
Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path to your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set correctly?
Those examples are defined in the bitbake classes you have in your
base layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so
it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES += "helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
I got the layer created like you said, but the test had a fetch problem
and it just locked up there. Had to control-C out of it. Console below:
jim@ubuntu-x64:/build/mycdv-minimal$ bitbake helloworld
Loading cache: 100%
|###| ETA:
00:00:00
Loaded 1037 entries from dependency cache.
OE Build Configuration:
BB_VERSION = "1.13.3"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "mycdv"
DISTRO = "poky"
DISTRO_VERSION = "1.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-yocto = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
meta-mycdv = "edison:34478f24de65dd8de8a4c8b913a1458d82dac1fa"
meta-jfa = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 514 of 693 (ID: 4,
/home/jim/poky/meta-jfa/recipes-jfa/helloworld/helloworld.bb, do_fetch)
NOTE: package helloworld-1.0-r0: task do_fetch: Started
WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1413"; export
SSH_AUTH_SOCK="/tmp/keyring-2QW6yC/ssh"; export
GIT_CONFIG="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/etc/gitconfig";
export
PATH="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/build/mycdv-minimal/tmp/sysroots/mycdv/usr/bin/crossscripts:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux//bin:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/poky/scripts";
/usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P
/home/jim/yocto-downloads 'ftp://ftp.gnu.org/gnu/hello/hello-1.0.tar.gz'
failed with signal 8, output:
I don't see 1.0.tar on the ftp site. How do I control this?
If you look in:
ftp://ftp.gnu.org/gnu/hello/
you'll see which versions are available. Rename your recipe filename
to reflect the version you wish to use, for example helloworld_2.7.bb
Duh! Now that makes sense. Sorry for being so dense. That's what
happens when your been programing since Fortran was at the 1.0 level.
Brain goes soft.
Jim A
The part of the filename after the underscore is what will get
interpolated into ${PV}.
Re: [yocto] understanding recipes
On 01/26/2012 04:38 PM, Scott Garman wrote:
On 01/26/2012 01:32 PM, jfabernathy wrote:
On 01/26/2012 01:55 PM, Scott Garman wrote:
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and
having it
included in the build I do.
For example, suppose I want to create the
meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello world
as shown in 3.1.2 Autotooled Package section of the Poky reference
Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path to your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set correctly?
Those examples are defined in the bitbake classes you have in your
base layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so
it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES += "helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
I got the layer created like you said, but the test had a fetch problem
and it just locked up there. Had to control-C out of it. Console below:
jim@ubuntu-x64:/build/mycdv-minimal$ bitbake helloworld
Loading cache: 100%
|###| ETA:
00:00:00
Loaded 1037 entries from dependency cache.
OE Build Configuration:
BB_VERSION = "1.13.3"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "mycdv"
DISTRO = "poky"
DISTRO_VERSION = "1.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-yocto = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
meta-mycdv = "edison:34478f24de65dd8de8a4c8b913a1458d82dac1fa"
meta-jfa = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 514 of 693 (ID: 4,
/home/jim/poky/meta-jfa/recipes-jfa/helloworld/helloworld.bb, do_fetch)
NOTE: package helloworld-1.0-r0: task do_fetch: Started
WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1413"; export
SSH_AUTH_SOCK="/tmp/keyring-2QW6yC/ssh"; export
GIT_CONFIG="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/etc/gitconfig";
export
PATH="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/build/mycdv-minimal/tmp/sysroots/mycdv/usr/bin/crossscripts:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux//bin:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/poky/scripts";
/usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P
/home/jim/yocto-downloads 'ftp://ftp.gnu.org/gnu/hello/hello-1.0.tar.gz'
failed with signal 8, output:
I don't see 1.0.tar on the ftp site. How do I control this?
If you look in:
ftp://ftp.gnu.org/gnu/hello/
you'll see which versions are available. Rename your recipe filename
to reflect the version you wish to use, for example helloworld_2.7.bb
The part of the filename after the underscore is what will get
interpolated into ${PV}.
Scott
Now I have gotten by the fetching but the license file information in
the .bb file from the example is incorrect. I can't see from the
Reference manual Li
Re: [yocto] understanding recipes
On 01/26/2012 02:04 PM, jfabernathy wrote:
On 01/26/2012 04:38 PM, Scott Garman wrote:
On 01/26/2012 01:32 PM, jfabernathy wrote:
On 01/26/2012 01:55 PM, Scott Garman wrote:
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and
having it
included in the build I do.
For example, suppose I want to create the
meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello world
as shown in 3.1.2 Autotooled Package section of the Poky reference
Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path to your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set correctly?
Those examples are defined in the bitbake classes you have in your
base layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so
it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES += "helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
I got the layer created like you said, but the test had a fetch problem
and it just locked up there. Had to control-C out of it. Console below:
jim@ubuntu-x64:/build/mycdv-minimal$ bitbake helloworld
Loading cache: 100%
|###| ETA:
00:00:00
Loaded 1037 entries from dependency cache.
OE Build Configuration:
BB_VERSION = "1.13.3"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "mycdv"
DISTRO = "poky"
DISTRO_VERSION = "1.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-yocto = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
meta-mycdv = "edison:34478f24de65dd8de8a4c8b913a1458d82dac1fa"
meta-jfa = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 514 of 693 (ID: 4,
/home/jim/poky/meta-jfa/recipes-jfa/helloworld/helloworld.bb, do_fetch)
NOTE: package helloworld-1.0-r0: task do_fetch: Started
WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1413"; export
SSH_AUTH_SOCK="/tmp/keyring-2QW6yC/ssh"; export
GIT_CONFIG="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/etc/gitconfig";
export
PATH="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/build/mycdv-minimal/tmp/sysroots/mycdv/usr/bin/crossscripts:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux//bin:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/poky/scripts";
/usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P
/home/jim/yocto-downloads 'ftp://ftp.gnu.org/gnu/hello/hello-1.0.tar.gz'
failed with signal 8, output:
I don't see 1.0.tar on the ftp site. How do I control this?
If you look in:
ftp://ftp.gnu.org/gnu/hello/
you'll see which versions are available. Rename your recipe filename
to reflect the version you wish to use, for example helloworld_2.7.bb
The part of the filename after the underscore is what will get
interpolated into ${PV}.
Scott
Now I have gotten by the fetching but the license file information in
the .bb file from the example is incorrect. I can't see fro
Re: [yocto] understanding recipes
On 01/26/2012 05:11 PM, Scott Garman wrote:
On 01/26/2012 02:04 PM, jfabernathy wrote:
On 01/26/2012 04:38 PM, Scott Garman wrote:
On 01/26/2012 01:32 PM, jfabernathy wrote:
On 01/26/2012 01:55 PM, Scott Garman wrote:
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and
having it
included in the build I do.
For example, suppose I want to create the
meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello
world
as shown in 3.1.2 Autotooled Package section of the Poky reference
Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa
directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path to
your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set
correctly?
Those examples are defined in the bitbake classes you have in your
base layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so
it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES +=
"helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
I got the layer created like you said, but the test had a fetch
problem
and it just locked up there. Had to control-C out of it. Console
below:
jim@ubuntu-x64:/build/mycdv-minimal$ bitbake helloworld
Loading cache: 100%
|###| ETA:
00:00:00
Loaded 1037 entries from dependency cache.
OE Build Configuration:
BB_VERSION = "1.13.3"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "mycdv"
DISTRO = "poky"
DISTRO_VERSION = "1.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-yocto = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
meta-mycdv = "edison:34478f24de65dd8de8a4c8b913a1458d82dac1fa"
meta-jfa = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 514 of 693 (ID: 4,
/home/jim/poky/meta-jfa/recipes-jfa/helloworld/helloworld.bb,
do_fetch)
NOTE: package helloworld-1.0-r0: task do_fetch: Started
WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1413"; export
SSH_AUTH_SOCK="/tmp/keyring-2QW6yC/ssh"; export
GIT_CONFIG="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/etc/gitconfig";
export
PATH="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/build/mycdv-minimal/tmp/sysroots/mycdv/usr/bin/crossscripts:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux//bin:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/poky/scripts";
/usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P
/home/jim/yocto-downloads
'ftp://ftp.gnu.org/gnu/hello/hello-1.0.tar.gz'
failed with signal 8, output:
I don't see 1.0.tar on the ftp site. How do I control this?
If you look in:
ftp://ftp.gnu.org/gnu/hello/
you'll see which versions are available. Rename your recipe filename
to reflect the version you wish to use, for example helloworld_2.7.bb
The part of the filename after the underscore is what will get
interpolated into ${PV}.
Scott
Now I have gotten by the fetching but the license file informat
Re: [yocto] understanding recipes
On 2012-01-26 15:11, Scott Garman wrote:
On 01/26/2012 02:04 PM, jfabernathy wrote:
On 01/26/2012 04:38 PM, Scott Garman wrote:
On 01/26/2012 01:32 PM, jfabernathy wrote:
On 01/26/2012 01:55 PM, Scott Garman wrote:
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and
having it
included in the build I do.
For example, suppose I want to create the
meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello world
as shown in 3.1.2 Autotooled Package section of the Poky reference
Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path to your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set correctly?
Those examples are defined in the bitbake classes you have in your
base layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so
it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES += "helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
I got the layer created like you said, but the test had a fetch problem
and it just locked up there. Had to control-C out of it. Console below:
jim@ubuntu-x64:/build/mycdv-minimal$ bitbake helloworld
Loading cache: 100%
|###| ETA:
00:00:00
Loaded 1037 entries from dependency cache.
OE Build Configuration:
BB_VERSION = "1.13.3"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "mycdv"
DISTRO = "poky"
DISTRO_VERSION = "1.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-yocto = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
meta-mycdv = "edison:34478f24de65dd8de8a4c8b913a1458d82dac1fa"
meta-jfa = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 514 of 693 (ID: 4,
/home/jim/poky/meta-jfa/recipes-jfa/helloworld/helloworld.bb, do_fetch)
NOTE: package helloworld-1.0-r0: task do_fetch: Started
WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1413"; export
SSH_AUTH_SOCK="/tmp/keyring-2QW6yC/ssh"; export
GIT_CONFIG="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/etc/gitconfig";
export
PATH="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/build/mycdv-minimal/tmp/sysroots/mycdv/usr/bin/crossscripts:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux//bin:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/poky/scripts";
/usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P
/home/jim/yocto-downloads 'ftp://ftp.gnu.org/gnu/hello/hello-1.0.tar.gz'
failed with signal 8, output:
I don't see 1.0.tar on the ftp site. How do I control this?
If you look in:
ftp://ftp.gnu.org/gnu/hello/
you'll see which versions are available. Rename your recipe filename
to reflect the version you wish to use, for example helloworld_2.7.bb
The part of the filename after the underscore is what will get
interpolated into ${PV}.
Scott
Now I have gotten by the fetching but the license file information in
the .bb file fro
[yocto] opkg-utils to move to git.yoctoproject.org
Folks, Currently opkg-utils is hosted on svn.openmoko.org, that host seems to be failing and is not a reliable upstream. We have a copy of opkg-utils under git.yoctoproject.org (captured the last time svn.openmoko.org was up). This move would also allow us to apply some pending patches. We will make this change next week barring any major objections. -- Sau! Saul Wold Yocto Component Wrangler @ Intel Yocto Project / Poky Build System ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding recipes
On 01/26/2012 05:37 PM, Gary Thomas wrote:
On 2012-01-26 15:11, Scott Garman wrote:
On 01/26/2012 02:04 PM, jfabernathy wrote:
On 01/26/2012 04:38 PM, Scott Garman wrote:
On 01/26/2012 01:32 PM, jfabernathy wrote:
On 01/26/2012 01:55 PM, Scott Garman wrote:
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and
having it
included in the build I do.
For example, suppose I want to create the
meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello
world
as shown in 3.1.2 Autotooled Package section of the Poky reference
Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa
directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path to
your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set
correctly?
Those examples are defined in the bitbake classes you have in your
base layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so
it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image file.
The
simplest way to do this is to add EXTRA_IMAGE_FEATURES +=
"helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
I got the layer created like you said, but the test had a fetch
problem
and it just locked up there. Had to control-C out of it. Console
below:
jim@ubuntu-x64:/build/mycdv-minimal$ bitbake helloworld
Loading cache: 100%
|###| ETA:
00:00:00
Loaded 1037 entries from dependency cache.
OE Build Configuration:
BB_VERSION = "1.13.3"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "mycdv"
DISTRO = "poky"
DISTRO_VERSION = "1.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-yocto = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
meta-mycdv = "edison:34478f24de65dd8de8a4c8b913a1458d82dac1fa"
meta-jfa = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 514 of 693 (ID: 4,
/home/jim/poky/meta-jfa/recipes-jfa/helloworld/helloworld.bb,
do_fetch)
NOTE: package helloworld-1.0-r0: task do_fetch: Started
WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1413"; export
SSH_AUTH_SOCK="/tmp/keyring-2QW6yC/ssh"; export
GIT_CONFIG="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/etc/gitconfig";
export
PATH="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/build/mycdv-minimal/tmp/sysroots/mycdv/usr/bin/crossscripts:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux//bin:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/poky/scripts";
/usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P
/home/jim/yocto-downloads
'ftp://ftp.gnu.org/gnu/hello/hello-1.0.tar.gz'
failed with signal 8, output:
I don't see 1.0.tar on the ftp site. How do I control this?
If you look in:
ftp://ftp.gnu.org/gnu/hello/
you'll see which versions are available. Rename your recipe filename
to reflect the version you wish to use, for example helloworld_2.7.bb
The part of the filename after the underscore is what will get
interpolated into ${PV}.
Scott
Now I have gotten by
Re: [yocto] understanding recipes
On 2012-01-26 16:44, jfabernathy wrote:
On 01/26/2012 05:37 PM, Gary Thomas wrote:
On 2012-01-26 15:11, Scott Garman wrote:
On 01/26/2012 02:04 PM, jfabernathy wrote:
On 01/26/2012 04:38 PM, Scott Garman wrote:
On 01/26/2012 01:32 PM, jfabernathy wrote:
On 01/26/2012 01:55 PM, Scott Garman wrote:
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and
having it
included in the build I do.
For example, suppose I want to create the
meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello world
as shown in 3.1.2 Autotooled Package section of the Poky reference
Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path to your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set correctly?
Those examples are defined in the bitbake classes you have in your
base layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so
it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES += "helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
I got the layer created like you said, but the test had a fetch problem
and it just locked up there. Had to control-C out of it. Console below:
jim@ubuntu-x64:/build/mycdv-minimal$ bitbake helloworld
Loading cache: 100%
|###| ETA:
00:00:00
Loaded 1037 entries from dependency cache.
OE Build Configuration:
BB_VERSION = "1.13.3"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "mycdv"
DISTRO = "poky"
DISTRO_VERSION = "1.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-yocto = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
meta-mycdv = "edison:34478f24de65dd8de8a4c8b913a1458d82dac1fa"
meta-jfa = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 514 of 693 (ID: 4,
/home/jim/poky/meta-jfa/recipes-jfa/helloworld/helloworld.bb, do_fetch)
NOTE: package helloworld-1.0-r0: task do_fetch: Started
WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1413"; export
SSH_AUTH_SOCK="/tmp/keyring-2QW6yC/ssh"; export
GIT_CONFIG="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/etc/gitconfig";
export
PATH="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/build/mycdv-minimal/tmp/sysroots/mycdv/usr/bin/crossscripts:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux//bin:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/poky/scripts";
/usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P
/home/jim/yocto-downloads 'ftp://ftp.gnu.org/gnu/hello/hello-1.0.tar.gz'
failed with signal 8, output:
I don't see 1.0.tar on the ftp site. How do I control this?
If you look in:
ftp://ftp.gnu.org/gnu/hello/
you'll see which versions are available. Rename your recipe filename
to reflect the version you wish to use, for example helloworld_2.7.bb
The part of the filename after the underscore is what will get
interpolated into ${PV}.
Scott
Re: [yocto] understanding recipes
On 01/26/2012 06:52 PM, Gary Thomas wrote:
On 2012-01-26 16:44, jfabernathy wrote:
On 01/26/2012 05:37 PM, Gary Thomas wrote:
On 2012-01-26 15:11, Scott Garman wrote:
On 01/26/2012 02:04 PM, jfabernathy wrote:
On 01/26/2012 04:38 PM, Scott Garman wrote:
On 01/26/2012 01:32 PM, jfabernathy wrote:
On 01/26/2012 01:55 PM, Scott Garman wrote:
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and
having it
included in the build I do.
For example, suppose I want to create the
meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include
hello world
as shown in 3.1.2 Autotooled Package section of the Poky
reference
Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa
directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep
all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like
the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path
to your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set
correctly?
Those examples are defined in the bitbake classes you have in your
base layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so
it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image
file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES +=
"helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
I got the layer created like you said, but the test had a fetch
problem
and it just locked up there. Had to control-C out of it. Console
below:
jim@ubuntu-x64:/build/mycdv-minimal$ bitbake helloworld
Loading cache: 100%
|###| ETA:
00:00:00
Loaded 1037 entries from dependency cache.
OE Build Configuration:
BB_VERSION = "1.13.3"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "mycdv"
DISTRO = "poky"
DISTRO_VERSION = "1.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-yocto = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
meta-mycdv = "edison:34478f24de65dd8de8a4c8b913a1458d82dac1fa"
meta-jfa = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 514 of 693 (ID: 4,
/home/jim/poky/meta-jfa/recipes-jfa/helloworld/helloworld.bb,
do_fetch)
NOTE: package helloworld-1.0-r0: task do_fetch: Started
WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1413"; export
SSH_AUTH_SOCK="/tmp/keyring-2QW6yC/ssh"; export
GIT_CONFIG="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/etc/gitconfig";
export
PATH="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/build/mycdv-minimal/tmp/sysroots/mycdv/usr/bin/crossscripts:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux//bin:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/poky/scripts";
/usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P
/home/jim/yocto-downloads
'ftp://ftp.gnu.org/gnu/hello/hello-1.0.tar.gz'
failed with signal 8, output:
I don't see 1.0.tar on the ftp site. How do I control this?
If you look in:
ftp://ftp.gnu.org/gnu/hello/
you'll see which versions are available. Rename your recipe filename
to reflect the version you wish to use, for example
helloworld_2.7.bb
The part of the filename
Re: [yocto] understanding recipes
On 01/26/2012 05:12 PM, jfabernathy wrote:
On 01/26/2012 06:52 PM, Gary Thomas wrote:
On 2012-01-26 16:44, jfabernathy wrote:
On 01/26/2012 05:37 PM, Gary Thomas wrote:
On 2012-01-26 15:11, Scott Garman wrote:
On 01/26/2012 02:04 PM, jfabernathy wrote:
On 01/26/2012 04:38 PM, Scott Garman wrote:
On 01/26/2012 01:32 PM, jfabernathy wrote:
On 01/26/2012 01:55 PM, Scott Garman wrote:
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and
having it
included in the build I do.
For example, suppose I want to create the
meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include
hello world
as shown in 3.1.2 Autotooled Package section of the Poky
reference
Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa
directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep
all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like
the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path
to your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set
correctly?
Those examples are defined in the bitbake classes you have in your
base layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so
it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image
file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES +=
"helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
I got the layer created like you said, but the test had a fetch
problem
and it just locked up there. Had to control-C out of it. Console
below:
jim@ubuntu-x64:/build/mycdv-minimal$ bitbake helloworld
Loading cache: 100%
|###| ETA:
00:00:00
Loaded 1037 entries from dependency cache.
OE Build Configuration:
BB_VERSION = "1.13.3"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "mycdv"
DISTRO = "poky"
DISTRO_VERSION = "1.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-yocto = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
meta-mycdv = "edison:34478f24de65dd8de8a4c8b913a1458d82dac1fa"
meta-jfa = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 514 of 693 (ID: 4,
/home/jim/poky/meta-jfa/recipes-jfa/helloworld/helloworld.bb,
do_fetch)
NOTE: package helloworld-1.0-r0: task do_fetch: Started
WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1413"; export
SSH_AUTH_SOCK="/tmp/keyring-2QW6yC/ssh"; export
GIT_CONFIG="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/etc/gitconfig";
export
PATH="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/build/mycdv-minimal/tmp/sysroots/mycdv/usr/bin/crossscripts:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux//bin:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/poky/scripts";
/usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P
/home/jim/yocto-downloads
'ftp://ftp.gnu.org/gnu/hello/hello-1.0.tar.gz'
failed with signal 8, output:
I don't see 1.0.tar on the ftp site. How do I control this?
If you look in:
ftp://ftp.gnu.org/gnu/hello/
you'll see which versions are available. Rename your recipe filename
to reflect the version you wish to use, for example
helloworld_2.7.bb
The par
[yocto] New recipes not installing in core-image-minimal
In support of a new BSP I've written two new recipes and appended to another to depend on them. The new recipes files are not appearing in the resulting images. I'm sure I'm overlooking something trivial, but I'm not sure what it would be. The layer is available here: http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=dvhart/sys940x I've added ranpwd, genmac, and appended to netbase. netbase RDEPENDS on genmac and genmac RDEPENDS on ranpwd. Building core-image-minimal triggers the build of genmac and ranpwd, and the modified /etc/network/interfaces appears in the rootfs. genmac and ranpwd place the appropriate files in their workdir/image directory, but those files don't make it into the rootfs. Can anyone offer an explanation as to why that might be? The top 4 commits of the repository linked to above will list the new recipes and the bbappend for reference. Thanks, -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] New recipes not installing in core-image-minimal
On 01/26/2012 05:29 PM, Darren Hart wrote:
In support of a new BSP I've written two new recipes and appended to
another to depend on them. The new recipes files are not appearing in
the resulting images. I'm sure I'm overlooking something trivial, but
I'm not sure what it would be. The layer is available here:
http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=dvhart/sys940x
I've added ranpwd, genmac, and appended to netbase.
netbase RDEPENDS on genmac and genmac RDEPENDS on ranpwd. Building
core-image-minimal triggers the build of genmac and ranpwd, and the
modified /etc/network/interfaces appears in the rootfs. genmac and
ranpwd place the appropriate files in their workdir/image directory, but
those files don't make it into the rootfs.
RDEPENDS_${PN} would work much better !
Sau!
Can anyone offer an explanation as to why that might be? The top 4
commits of the repository linked to above will list the new recipes and
the bbappend for reference.
Thanks,
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] New recipes not installing in core-image-minimal
On 01/26/2012 05:42 PM, Saul Wold wrote:
> On 01/26/2012 05:29 PM, Darren Hart wrote:
>> In support of a new BSP I've written two new recipes and appended to
>> another to depend on them. The new recipes files are not appearing in
>> the resulting images. I'm sure I'm overlooking something trivial, but
>> I'm not sure what it would be. The layer is available here:
>>
>> http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=dvhart/sys940x
>>
>> I've added ranpwd, genmac, and appended to netbase.
>>
>> netbase RDEPENDS on genmac and genmac RDEPENDS on ranpwd. Building
>> core-image-minimal triggers the build of genmac and ranpwd, and the
>> modified /etc/network/interfaces appears in the rootfs. genmac and
>> ranpwd place the appropriate files in their workdir/image directory, but
>> those files don't make it into the rootfs.
>>
> RDEPENDS_${PN} would work much better !
Perhaps, but it didn't fix this particular problem. Neither
/usr/bin/ranpwd nor /etc/init.d/genmac appear in the rootfs. However,
each still appears in their respective workdir/image:
$ find
tmp/work/sys940x_noemgd-poky-linux/core-image-minimal-1.0-r0/rootfs
-name "ranpwd"
$ find
tmp/work/sys940x_noemgd-poky-linux/core-image-minimal-1.0-r0/rootfs
-name "genmac"
$ ls tmp/work/core2-poky-linux/genmac-1.0-r0/image/etc/init.d/
genmac
$ ls tmp/work/core2-poky-linux/ranpwd-git-r0/image/usr/bin/
ranpwd
genmac doesn't have a log.do_install in the workdir/temp directory. Is
that significant?
ranpwd does, but it isn't instructive:
$ cat tmp/work/core2-poky-linux/ranpwd-git-r0/temp/log.do_install
DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common',
'common-linux', 'common-glibc', 'i586-linux', 'common']
Any other thoughts?
>
> Sau!
>
>> Can anyone offer an explanation as to why that might be? The top 4
>> commits of the repository linked to above will list the new recipes and
>> the bbappend for reference.
>>
>> Thanks,
>>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding recipes
On 01/26/2012 03:52 PM, Gary Thomas wrote: Any ideas as to why EXTRA_IMAGE_FEATURES += "hello" didn't add the hello code to the final image? EXTRA_IMAGE_FEATURES enables target *features*, not packages. To get your package added, use this in local.conf IMAGE_INSTALL += " hello " Good catch. Thanks, Gary. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
