[yocto] Difference b/w SDK and ADT

[Raghavendra Kakarla]

Hi All,  

I have the following doubts regarding the yocto SDK and ADT. Could you please 
clarify them.

They are:

   1. What is the difference b/w the YOCTO SDK and ADT?
   2.  With the ADT can use the my bitbake generated sysroot for my 
application development? Because I built   the required custom packages in 
yocto for my software development. 

 Thanks in advance.
 Regards,
 Raghavendra Kakarla.


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

Re: [yocto] How to specify required kernel version and BlueZ version in custom layer configuration?

[Khem Raj]

> On Apr 23, 2015, at 6:12 PM, Cai, Juliet Z  wrote:
> 
> I have a custom layer with recipes that require kernel 3.19 and BlueZ 5.  I 
> have two questions.
>  
> 1.  Is there a place in my layer to specified required kernel version?  I 
> see it can be done in machine/config, but my layer is not machine specific.

kernel versions are generally dictated by machine configs. you may document it 
in your README as to what you require for your layer to go into mix. you could 
also write a kernel bbappend which checks for kernel version ‘pythonically’ and 
barfs 

> 2.  To switch to Bluez 5, I can add DISTRO_FEATURES_append = “ bluez5” to 
> local.config. Can I do something in my own layer configuration to have the 
> same effect?

you can add same in layer.conf

>  
> Thanks in advance,
> Juliet
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Deploy rootfs image within another rootfs image

[Khem Raj]

> On Apr 23, 2015, at 4:44 PM, Craig McQueen  
> wrote:
> 
> I've got two scenarios where I want to put a rootfs image within another 
> rootfs image.
> 
> One scenario is for factory programming: My target is a BeagleBone Black type 
> of system. I want to make a simple programmer to boot from SD card, which 
> will partition and format the on-board eMMC and then write the bootloaders 
> onto one partitions, and a rootfs image onto the other partition. So I want 
> to make a recipe to build the programmer image, which contains another 
> previously-built rootfs image at say /lib/firmware/rootfs.tar.gz. 
> 
> Another scenario is to implement firmware upgrade in-the-field. I am 
> considering making a rootfs as a read-only SquashFS image. That image would 
> then be put into a writable ext4 filesystem. An initramfs would use OverlayFS 
> to mount the writable ext4 filesystem over the SquashFS image that is 
> loop-back mounted.
> 
> What is necessary to make a Yocto recipe to make an image, that will build 
> another image, and then copy its deployed .tar.gz image into its own rootfs 
> image?


looks into initramfs support. start here 
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-CONFIG_INITRAMFS_SOURCE
and google will find you more examples.
> 
> -- 
> Craig McQueen
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

[yocto] How to specify required kernel version and BlueZ version in custom layer configuration?

[Cai, Juliet Z]

I have a custom layer with recipes that require kernel 3.19 and BlueZ 5.  I 
have two questions.


1.  Is there a place in my layer to specified required kernel version?  I 
see it can be done in machine/config, but my layer is not machine specific.

2.  To switch to Bluez 5, I can add DISTRO_FEATURES_append = " bluez5" to 
local.config. Can I do something in my own layer configuration to have the same 
effect?

Thanks in advance,
Juliet
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Strange error trying to use externalsrc

[Paul Eggleton]

On Thursday 23 April 2015 12:37:30 Matt Schuckmann wrote:
> I'm trying to use the externalsrc class to make it easier build an
> application under active development.
> 
> I'm working off of the Dylan branch.
> 
> If I add the following 2 lines to my site.conf
> 
> INHERIT += "externalsrc"
> S_pn-keypadd = "/home/dev/builds/zanzibar/keypadd"
> 
> I get the following error when I try to build the keypadd recipe.
> 
> ERROR: Function failed: gnu-config-native: LIC_FILES_CHKSUM points to an
> invalid file:
> /home/dev/builds/zanzibar/tisdk/zanzibar/build/arago-tmp-external-linaro-to
> olchain/work/i686-linux/gnu-config-native/20120814-r0/gnu-config-20120814/co
> nfig.guess ERROR: Logfile of failure stored in:
> /home/dev/builds/zanzibar/tisdk/zanzibar/build/arago-tmp-external-linaro-to
> olchain/work/i686-linux/gnu-config-native/20120814-r0/temp/log.do_configure.
> 11698
> Log data follows:
> | DEBUG: Executing python function sysroot_cleansstate
> | DEBUG: Python function sysroot_cleansstate finished
> | DEBUG: Executing shell function do_configure
> | DEBUG: Shell function do_configure finished
> | DEBUG: Executing python function do_qa_configure
> | NOTE: Checking autotools environment for common misconfiguration
> | DEBUG: Python function do_qa_configure finished
> | ERROR: Function failed: gnu-config-native: LIC_FILES_CHKSUM points to an
> | invalid file:
> | /home/dev/builds/zanzibar/tisdk/zanzibar/build/arago-tmp-external-linaro-
> | toolchain/work/i686-linux/gnu-config-native/20120814-r0/gnu-config-2012081
> | 4/config.guess
> ERROR: Task 26
> (virtual:native:/home/dev/builds/zanzibar/tisdk/zanzibar/sources/oe-core/me
> ta/recipes-devtools/gnu-config/gnu-config_20120814.bb, do_configure) failed
> with exit code '1'
> 
> 
> The keypadd recipe is marked as CLOSED but I've also tried MIT and GPL. I've
> even added a license file and MD5 checksum. Interestingly externalsrc seems
> to work if I add these 2 lines to the recipe.
> 
> inherit externalsrc
> S = "/home/dev/builds/zanzibar/keypadd"
> 
> But I don't want to have to edit the recipe every time I want to switch to
> building from a local directory.
> 
> Any suggestions as to what is wrong?

Don't set S to specify the path to the external source tree - set EXTERNALSRC 
instead, or otherwise externalsrc.bbclass's actual functionality isn't active.

Cheers,
Paul

-- 

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

[yocto] Deploy rootfs image within another rootfs image

[Craig McQueen]

I've got two scenarios where I want to put a rootfs image within another rootfs 
image.

One scenario is for factory programming: My target is a BeagleBone Black type 
of system. I want to make a simple programmer to boot from SD card, which will 
partition and format the on-board eMMC and then write the bootloaders onto one 
partitions, and a rootfs image onto the other partition. So I want to make a 
recipe to build the programmer image, which contains another previously-built 
rootfs image at say /lib/firmware/rootfs.tar.gz. 

Another scenario is to implement firmware upgrade in-the-field. I am 
considering making a rootfs as a read-only SquashFS image. That image would 
then be put into a writable ext4 filesystem. An initramfs would use OverlayFS 
to mount the writable ext4 filesystem over the SquashFS image that is loop-back 
mounted.

What is necessary to make a Yocto recipe to make an image, that will build 
another image, and then copy its deployed .tar.gz image into its own rootfs 
image?

-- 
Craig McQueen

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

[yocto] Jobs page on Openembedded.org

[Philip Balister]

I've made a page on OpenEmbedded.org for people to link to jobs they
know about. The job posting hsould have some OpenEmbedded/Yocto Project
content:

http://openembedded.org/wiki/Jobs

I know you can search places like Linkedin for OpenEmbedded and get lots
of hits, but I'd like this to be community driven. Let's see how it
develops. Try and keep the jobs organized by the month they are listed
so we can easily prune stale postings.

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

[yocto] Strange error trying to use externalsrc

[Matt Schuckmann]

I'm trying to use the externalsrc class to make it easier build an application 
under active development. 

I'm working off of the Dylan branch. 

If I add the following 2 lines to my site.conf

INHERIT += "externalsrc"
S_pn-keypadd = "/home/dev/builds/zanzibar/keypadd"

I get the following error when I try to build the keypadd recipe. 

ERROR: Function failed: gnu-config-native: LIC_FILES_CHKSUM points to an 
invalid file: 
/home/dev/builds/zanzibar/tisdk/zanzibar/build/arago-tmp-external-linaro-toolchain/work/i686-linux/gnu-config-native/20120814-r0/gnu-config-20120814/config.guess
ERROR: Logfile of failure stored in: 
/home/dev/builds/zanzibar/tisdk/zanzibar/build/arago-tmp-external-linaro-toolchain/work/i686-linux/gnu-config-native/20120814-r0/temp/log.do_configure.11698
Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: Executing shell function do_configure
| DEBUG: Shell function do_configure finished
| DEBUG: Executing python function do_qa_configure
| NOTE: Checking autotools environment for common misconfiguration
| DEBUG: Python function do_qa_configure finished
| ERROR: Function failed: gnu-config-native: LIC_FILES_CHKSUM points to an 
invalid file: 
/home/dev/builds/zanzibar/tisdk/zanzibar/build/arago-tmp-external-linaro-toolchain/work/i686-linux/gnu-config-native/20120814-r0/gnu-config-20120814/config.guess
ERROR: Task 26 
(virtual:native:/home/dev/builds/zanzibar/tisdk/zanzibar/sources/oe-core/meta/recipes-devtools/gnu-config/gnu-config_20120814.bb,
 do_configure) failed with exit code '1'


The keypadd recipe is marked as CLOSED but I've also tried MIT and GPL. I've 
even added a license file and MD5 checksum. 
Interestingly externalsrc seems to work if I add these 2 lines to the recipe. 

inherit externalsrc
S = "/home/dev/builds/zanzibar/keypadd"

But I don't want to have to edit the recipe every time I want to switch to 
building from a local directory. 

Any suggestions as to what is wrong? 

Thanks,
Matt S. 

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

Re: [yocto] creating images which include actively developed applications

[Paul Eggleton]

On Thursday 23 April 2015 02:05:49 Khem Raj wrote:
> > On Apr 23, 2015, at 1:45 AM, Paul Eggleton 
> > wrote:> 
> > On Wednesday 22 April 2015 23:49:41 Khem Raj wrote:
> >>> On Apr 22, 2015, at 4:22 PM, Paul Eggleton
> >>> 
> >>> wrote:>
> >>> 
> >>> On Wednesday 22 April 2015 20:51:08 Brian Karcz wrote:
>  Thanks for pointing me to that. It sounds like exactly what I need. I
>  can't believe that I've not come across that in my searches. I suppose
>  its a matter of using the right search criteria.
> >>> 
> >>> So I do want to mention one thing - we envisaged externalsrc more for
> >>> situations where you temporarily want to build from an external source
> >>> tree (for example, when you're in the middle of development). The
> >>> expectation is that when you reach production you switch over to a
> >>> standard repository
> >>> specified in SRC_URI. Having said that there aren't any actual barriers
> >>> to
> >>> using it on a more permanent basis as it sounds like you may  be
> >>> considering (although perhaps I've misunderstood.)
> >> 
> >> Application development doesn’t end is what really happens, so developers
> >> will need to keep using something like this forever on a given
> >> application,
> >> and somehow externalsrc sounds temporary i.e. not included into regular
> >> workflow.
> > 
> > But does the source tree persist on one developer's machine? Or should it
> > in fact be on a proper server in a repository of its own?
> 
> its on a SCM as well. Developer checks it out himself or via a tool for
> workspace management now you have two ways to build it. One w/o externalsrc
> which is common for system integrators but not much liked by developers.
> The other one is externalsrc which is well known method for developers.

Right, yes - but is that a problem? In 1.8 with devtool making it easy to 
switch in and out of "development" locally you ought to be able to get the 
best of both worlds.

>  2) can the SRC_URI now be omitted in the recipe since there is nothing
>  to fetch?
> >>> 
> >>> You can leave it completely blank if you wish. In dizzy and earlier,
> >>> SRC_URI is effectively ignored with externalsrc. In master and the
> >>> just-released fido release, any local file:// references will still be
> >>> fetched if present, remote URIs will be ignored.
> >> 
> >> Will they be just fetched or also applied to source tree like in
> >> non-externalsrc case. getting a  'prepared source tree' in an externalsrc
> >> env is a big confusion point for developers where a given component is
> >> building totally fine and if one want to use externalsrc then developer
> >> needs to do ‘preparation of source tree’, so it seems post 1.7 we have
> >> something inbetween solution ?
> > 
> > They will be unpacked into the workdir as they would have been without
> > externalsrc. They do not go into the source tree.
> 
> hmm, it will then get my patches and put them in workdir, so then I should
> manually apply these patches I see that if i have any config files etc. (
> non-patch files) in SRC_URI ponting into local meta-data then they will be
> available at WORKDIR location much like the case w/o externalsrc so thats
> probably slight improvemnt

One thing I neglected to highlight was in 1.8, if you use devtool modify -x, 
it will apply the patches to for you when preparing the source tree. 
externalsrc doesn't do anything with them though so yes if you want to prepare 
the source tree yourself you will need to apply any patches from the recipe by 
hand, but there is now an easier way to do that with devtool.

Cheers,
Paul

-- 

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

Re: [yocto] creating images which include actively developed applications

[Mike Looijmans]

On 22-04-15 19:58, Paul Eggleton wrote:

Hi Brian,

On Wednesday 22 April 2015 15:32:06 Brian Karcz wrote:

 ..
Is there a way to create a recipe to build actively developed code located
in an external source directory? Basically skip the fetch and unpack steps
and always execute the compile and populate steps each time and image is
built?


Indeed there is:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source


Man, I've been working with OE for years, and this is the first time I ever 
saw this.


You should create a link to this page using ten feet neon tubes. Seriously. 
People have been asking me this question over and over, and all I had to offer 
was some crappy scripts to invalidate and rebuild a package.


Kind regards,
Mike.



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] creating images which include actively developed applications

[Khem Raj]

> On Apr 23, 2015, at 1:45 AM, Paul Eggleton  
> wrote:
> 
> On Wednesday 22 April 2015 23:49:41 Khem Raj wrote:
>>> On Apr 22, 2015, at 4:22 PM, Paul Eggleton 
>>> wrote:> 
>>> On Wednesday 22 April 2015 20:51:08 Brian Karcz wrote:
 Thanks for pointing me to that. It sounds like exactly what I need. I
 can't believe that I've not come across that in my searches. I suppose
 its a matter of using the right search criteria.
>>> 
>>> So I do want to mention one thing - we envisaged externalsrc more for
>>> situations where you temporarily want to build from an external source
>>> tree (for example, when you're in the middle of development). The
>>> expectation is that when you reach production you switch over to a
>>> standard repository
>>> specified in SRC_URI. Having said that there aren't any actual barriers to
>>> using it on a more permanent basis as it sounds like you may  be
>>> considering (although perhaps I've misunderstood.)
>> 
>> Application development doesn’t end is what really happens, so developers
>> will need to keep using something like this forever on a given application,
>> and somehow externalsrc sounds temporary i.e. not included into regular
>> workflow.
> 
> But does the source tree persist on one developer's machine? Or should it in 
> fact be on a proper server in a repository of its own?

its on a SCM as well. Developer checks it out himself or via a tool for 
workspace management
now you have two ways to build it. One w/o externalsrc which is common for 
system integrators
but not much liked by developers. The other one is externalsrc which is well 
known method
for developers.

> 
 2) can the SRC_URI now be omitted in the recipe since there is nothing to
 fetch?
>>> 
>>> You can leave it completely blank if you wish. In dizzy and earlier,
>>> SRC_URI is effectively ignored with externalsrc. In master and the
>>> just-released fido release, any local file:// references will still be
>>> fetched if present, remote URIs will be ignored.
>> 
>> Will they be just fetched or also applied to source tree like in
>> non-externalsrc case. getting a  'prepared source tree' in an externalsrc
>> env is a big confusion point for developers where a given component is
>> building totally fine and if one want to use externalsrc then developer
>> needs to do ‘preparation of source tree’, so it seems post 1.7 we have
>> something inbetween solution ?
> 
> They will be unpacked into the workdir as they would have been without 
> externalsrc. They do not go into the source tree.

hmm, it will then get my patches and put them in workdir, so then I should 
manually apply these patches
I see that if i have any config files etc. ( non-patch files) in SRC_URI 
ponting into local meta-data then they
will be available at WORKDIR location much like the case w/o externalsrc so 
thats probably slight improvemnt

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

Re: [yocto] creating images which include actively developed applications

[Paul Eggleton]

On Wednesday 22 April 2015 23:49:41 Khem Raj wrote:
> > On Apr 22, 2015, at 4:22 PM, Paul Eggleton 
> > wrote:> 
> > On Wednesday 22 April 2015 20:51:08 Brian Karcz wrote:
> >> Thanks for pointing me to that. It sounds like exactly what I need. I
> >> can't believe that I've not come across that in my searches. I suppose
> >> its a matter of using the right search criteria.
> > 
> > So I do want to mention one thing - we envisaged externalsrc more for
> > situations where you temporarily want to build from an external source
> > tree (for example, when you're in the middle of development). The
> > expectation is that when you reach production you switch over to a
> > standard repository
> > specified in SRC_URI. Having said that there aren't any actual barriers to
> > using it on a more permanent basis as it sounds like you may  be
> > considering (although perhaps I've misunderstood.)
> 
> Application development doesn’t end is what really happens, so developers
> will need to keep using something like this forever on a given application,
> and somehow externalsrc sounds temporary i.e. not included into regular
> workflow.

But does the source tree persist on one developer's machine? Or should it in 
fact be on a proper server in a repository of its own?

> >> 2) can the SRC_URI now be omitted in the recipe since there is nothing to
> >> fetch?
> > 
> > You can leave it completely blank if you wish. In dizzy and earlier,
> > SRC_URI is effectively ignored with externalsrc. In master and the
> > just-released fido release, any local file:// references will still be
> > fetched if present, remote URIs will be ignored.
> 
> Will they be just fetched or also applied to source tree like in
> non-externalsrc case. getting a  'prepared source tree' in an externalsrc
> env is a big confusion point for developers where a given component is
> building totally fine and if one want to use externalsrc then developer
> needs to do ‘preparation of source tree’, so it seems post 1.7 we have
> something inbetween solution ?

They will be unpacked into the workdir as they would have been without 
externalsrc. They do not go into the source tree.

Cheers,
Paul

-- 

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

[yocto] Location of U-Boot environment for BeagleBone Black

[Craig McQueen]

I'm building Yocto for BeagleBone using the meta-ti layer and the kernel and 
U-Boot provided by that layer.

I'm having some trouble understanding the location where U-Boot saves its 
environment for BeagleBone Black.

After doing some reading, it looks as though it might be saving environment on 
a "special" eMMC boot partition (which is not the same as the FAT16 partition 1 
I created to store MLO and u-boot.img).

However, this is only when booting from the on-board eMMC I think. When booting 
from SD card, where is environment stored? I can do "saveenv" command in 
U-Boot, and it says it's saving it to MMC.

U-Boot# saveenv
Saving Environment to MMC...
Writing to MMC(1)... done

But then after a reboot, it says:

MMC: block number 0x100 exceeds max(0x0)
MMC: block number 0x200 exceeds max(0x0)
*** Error - No Valid Environment Area found
Using default environment

So does that mean that U-Boot can't use a saved environment when booting from 
SD card?

Actually, based on some simple testing, it seems that it _is_ writing to the 
boot partition of the on-board eMMC, and loading it when it reboots from SD 
card, despite the error message. This is confusing.

What about the case of a board with no eMMC, such as BeagleBone White? Where 
would it save environment then?

How can I erase the saved environment when booting from eMMC, to ensure that 
U-Boot defaults will be used? I see that when Linux boots, there are block 
devices /dev/mmcblk0boot0 and /dev/mmcblk0boot1. But it seems I can't write to 
them:

# dd if=/dev/zero of=/dev/mmcblk0boot1 bs=1k count=1k
dd: writing '/dev/mmcblk0boot1': Operation not permitted
1+0 records in
0+0 records out

-- 
Craig McQueen

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