[yocto] Best practice in debugging target software

2016-02-12 Thread Pascal Bach
Hello everybody I'm currently trying to figure out the easiest way to debug an executable on a target. What I ended up is the following approach: 1. Enable Debugfs generation using: `IMAGE_GEN_DEBUGFS = "1"` 2. Switch debug split style to: `PACKAGE_DEBUG_SPLIT_STYLE = "debug-file-directory"`

Re: [yocto] Eclipse IDE plugin failure

2016-02-12 Thread Marius
Thanks Teo, I will give it a go. You should follow steps from http://www.yoctoproject.org/docs/2.0/dev-manual/dev-manual.html#zip-file-method When following steps use “mars/yocto-2.0” branch instead of “luna/yocto-2.0”. You should apply patch with “git am” after doing git checkout at

Re: [yocto] How to create do_populate_sysroot_append task

2016-02-12 Thread Vivek Per
I got the solution for the above issue , we can create a custom has given below in the recipe # addtask copy_files_sysroot after do_populate_sysroot before do_package do_copy_files_sysroot() { --- } # I hope this

Re: [yocto] native tool is not installed before it is used

2016-02-12 Thread Burton, Ross
On 12 February 2016 at 06:10, Sridhar Pitchai wrote: > I have a recipe, where It need protobuf-c-compiler (natvily) to auto > generate files before it can be compiled. i have added protobuf-c-native in > the DEPENDS list. but the compilation is failling at

Re: [yocto] Dropping Debian 7 as supported?

2016-02-12 Thread Nick Leverton
On Thursday 11 Feb 2016 14:32:50 Burton, Ross wrote: > On 11 February 2016 at 14:21, Nick Leverton wrote: > > Possibly a little early - Debian 7 will be going onto LTS security support > > for > > two years, starting some time this month. Quoting from > >

Re: [yocto] Dropping Debian 7 as supported?

2016-02-12 Thread Fred Ollinger
I run debian right now and it works great. $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 8.3 (jessie) Release:8.3 Codename: jessie I prefer debian over ubuntu: 1. Simpler footprint so it feels more customizable out of the

Re: [yocto] Dropping Debian 7 as supported?

2016-02-12 Thread Fred Ollinger
My apologies. From: Burton, Ross Sent: Friday, February 12, 2016 9:18 AM To: Fred Ollinger Cc: Nick Leverton; yocto@yoctoproject.org Subject: Re: [yocto] Dropping Debian 7 as supported? On 12 February 2016 at 17:14, Fred Ollinger

Re: [yocto] Dropping Debian 7 as supported?

2016-02-12 Thread Burton, Ross
On 12 February 2016 at 17:14, Fred Ollinger wrote: > So far, I have zero problems, and it would be nice to not see a scary > message telling me to change distros if my distro actually works great. > You must have missed the bit where I said that Debian 8 was being

[yocto] Changing provider/version on target sysroot only

2016-02-12 Thread Jean-René David
Hello, I'm trying to reproduce an existing linux image using yocto. It's a rather old image. I'm fine using the latest stable version of yocto but I need the packages on the target sysroot to match the versions I have in the old image. How do I specifiy a provider/version for a package on the

Re: [yocto] native tool is not installed before it is used

2016-02-12 Thread Sridhar Pitchai
Thanks. that works. but i am confused :) in the original recipe, i was doing do_autogen "after" configure, assuming do_configure will install all the needed dependencies and i can use those native tools after that. but with your solution (do_configure_prepend, which works), it gives the

Re: [linux-yocto] [PATCH 02/13] ktypes: add extended ktype

2016-02-12 Thread Paul Gortmaker
[Re: [linux-yocto] [PATCH 02/13] ktypes: add extended ktype] On 10/02/2016 (Wed 20:37) Sullivan, California L wrote: > On 02/08/2016 11:24 AM, Bruce Ashfield wrote: > > On 2016-02-07 6:14 PM, Paul Gortmaker wrote: > >> [[linux-yocto] [PATCH 02/13] ktypes: add extended ktype] On 04/02/2016 > >>

Re: [yocto] Yocto/Poky with external linaro toolchain

2016-02-12 Thread Christopher Larson
On Fri, Feb 12, 2016 at 2:47 AM Thomas Kaufmann wrote: > Hi Christopher > > > > thanks for this hint, this prevented a lot of packages from being built. > > However I still face an additional issue. in the last step of > do_populate_sdk, when the sdk is actually

[linux-yocto] [PATCH v2 00/12] ktypes/base: Disable EMBEDDED and DEBUG_KERNEL

2016-02-12 Thread California Sullivan
DEBUG_KERNEL should not be in the base ktype, as a production kernel may not necessarily want any debug turned on. EMBEDDED is also removed, as EMBEDDED selects EXPERT which selects DEBUG_KERNEL. Signed-off-by: California Sullivan --- ktypes/base/base.cfg | 6

[linux-yocto] [PATCH v2 00/12] ktypes: add developer ktype

2016-02-12 Thread California Sullivan
The developer ktype enables EMBEDDED, EXPERT, and DEBUG_KERNEL, opening up more kernel options and setting some defaults. Signed-off-by: California Sullivan --- ktypes/developer/developer.cfg | 19 +++ ktypes/developer/developer.scc | 10

[linux-yocto] [PATCH v2 00/12] intel-common-drivers.scc: move profiling and latencytop to a new file

2016-02-12 Thread California Sullivan
Profiling and latencytop enable DEBUG_KERNEL, which is no longer a standard config option. Move these features to a new file called intel-developer-drivers.scc, which is to be included in intel developer BSPs. Signed-off-by: California Sullivan ---

[linux-yocto] [PATCH v2 00/12] preempt-rt.scc: inlcude developer ktype instead of standard

2016-02-12 Thread California Sullivan
The developer ktype now has the functionality of the previous standard ktype. To keep preempt-rt's functionality consistent we must include developer. Signed-off-by: California Sullivan --- ktypes/preempt-rt/preempt-rt.scc | 2 +- 1 file changed, 1 insertion(+),

[linux-yocto] [PATCH v2 00/12] bsp: remove profiling and latencytop from non-developer common-pc BSPs

2016-02-12 Thread California Sullivan
These features enable DEBUG_KERNEL, which is no longer standard. They are still available in the -developer BSPs. Signed-off-by: California Sullivan --- bsp/common-pc-64/common-pc-64-standard.scc | 2 -- bsp/common-pc/common-pc-standard.scc | 2 -- 2 files

[linux-yocto] [PATCH v2 00/12] bsp: add developer common-pc BSPs

2016-02-12 Thread California Sullivan
By using the developer ktype instead of standard, these BSPs have the same functionality of the old -standard BSPs. Signed-off-by: California Sullivan --- bsp/common-pc-64/common-pc-64-developer.scc | 17 + bsp/common-pc/common-pc-developer.scc

[linux-yocto] [PATCH v2 00/12] intel-common: add intel-developer-drivers.scc to preempt-rt BSPS

2016-02-12 Thread California Sullivan
Since we include the developer ktype we should include developer drivers. Signed-off-by: California Sullivan --- bsp/intel-common/intel-core2-32-preempt-rt.scc | 1 + bsp/intel-common/intel-corei7-64-preempt-rt.scc | 1 + 2 files changed, 2 insertions(+) diff

[linux-yocto] [PATCH v2 00/12] CONFIG_I2C_I801: set option to yes in intel-core* BSPs

2016-02-12 Thread California Sullivan
Without EXPERT, we hit a select on I2C_I801, forcing it to yes and causing a warning. Set I2C_I801 to yes, and if a BSP wants to build it as a module, it can be done through a developer ktype BSP. Signed-off-by: California Sullivan ---

[linux-yocto] [PATCH v2 00/12] features/debug: add debug-kernel feature

2016-02-12 Thread California Sullivan
Since EMBEDDED, EXPERT, and DEBUG_KERNEL are being removed from the base ktype, we can no longer assume DEBUG_KERNEL is enabled. Also add this fragment to features that require DEBUG_KERNEL. Signed-off-by: California Sullivan --- features/debug/debug-kernel.cfg

[linux-yocto] [PATCH v2 00/12] ktype refactoring: move DEBUG_KERNEL, EXPERT and EMBEDDED

2016-02-12 Thread California Sullivan
Targetted for yocto-4.4 and master. Changes since last revision: *Renamed extended to developer* More descriptive name than extended. *Add DEBUG_PREEMPT to debug-kernel feature* This is an important debug feature that we should explicitly enable. Enabling CONFIG_DEBUG_MUTEXES was also proposed,

[linux-yocto] [PATCH v2 00/12] CONFIG_PROCESSOR_SELECT: do not enable

2016-02-12 Thread California Sullivan
The base ktype no longer enables EXPERT, so PROCESSOR_SELECT cannot be enabled by default. Nothing relying on PROCESSOR_SELECT is changed from default, and PROCESSOR_SELECT itself only enables a printk, so this will have no functional change on BSPs using these fragments. Signed-off-by:

Re: [linux-yocto] [PATCH v2 00/12] bsp: add developer common-pc BSPs

2016-02-12 Thread Paul Gortmaker
[[PATCH v2 00/12] bsp: add developer common-pc BSPs] On 12/02/2016 (Fri 17:42) California Sullivan wrote: > By using the developer ktype instead of standard, these BSPs have the > same functionality of the old -standard BSPs. > > Signed-off-by: California Sullivan