[linux-yocto] [PATCH 4/4] cpufreq: intel_p_state: core_get_turbo_ratio_limit() can be static

[Yong, Jonathan]

From: kbuild test robot 

Signed-off-by: Fengguang Wu 
Signed-off-by: Yong, Jonathan 
---
 drivers/cpufreq/intel_pstate.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 6314fb9..3895f57 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -658,7 +658,7 @@ static void core_set_pstate(struct cpudata *cpudata, int 
pstate)
wrmsrl_on_cpu(cpudata->cpu, MSR_IA32_PERF_CTL, val);
 }
 
-u64 core_get_turbo_ratio_limit(struct cpudata *cpudata)
+static u64 core_get_turbo_ratio_limit(struct cpudata *cpudata)
 {
u64 value;
 
@@ -667,8 +667,8 @@ u64 core_get_turbo_ratio_limit(struct cpudata *cpudata)
return value;
 }
 
-int core_set_turbo_ratio_limit(struct cpudata *cpudata, u64 def_ratio,
-  u64 new_ratio)
+static int core_set_turbo_ratio_limit(struct cpudata *cpudata, u64 def_ratio,
+ u64 new_ratio)
 {
u64 value;
 
-- 
2.7.3

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

[linux-yocto] [PATCH 1/4] intel_pstate: add support for BXT-P

[Yong, Jonathan]

From: Kristen Carlson Accardi 

BXT-P cpuid added to whitelist.  BXT-P needs to use core_params
because the MSRs for BYT/CHT don't work on BXT.  Tuning for
BXT is TBD.

Signed-off-by: Kristen Carlson Accardi 
Signed-off-by: Yong, Jonathan 
---
 drivers/cpufreq/intel_pstate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index c374816..7d02796 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -913,6 +913,7 @@ static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
ICPU(0x4c, byt_params),
ICPU(0x4e, core_params),
ICPU(0x4f, core_params),
+   ICPU(0x5c, core_params),
ICPU(0x5e, core_params),
ICPU(0x56, core_params),
ICPU(0x57, knl_params),
-- 
2.7.3

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

[linux-yocto] [PATCH 2/4] cpufreq: intel_p_state: Fix P1 and below as guaranteed performance

[Yong, Jonathan]

From: Srinivas Pandruvada 

Request for performance states P1 and below should be honored unless
limited by some platform thermals, but shouldn't get more than what
OS requested. On several platforms when we restrict P state to P1 or
below, we see jump to turbo range. We get the max non turbo P state
from read only MSR 0xCE (PLATFORM_INFO). But the turbo activation ratio
doesn't follow the value read from this MSR. This uses
MSR TURBO_ACTIVATION_RATIO(0x64C). BIOS is supposed to set the
TURBO_ACTIVATION_RATIO. The value currently set on these platform is very
low. For example on Surface 3 pro, the max non turbo P state is 0x17,
but turbo activation ratio is set to 0x10. So any P state above 0x10
will force P state to turbo range, where it will execute in any state
between P1 and P0. This change programs TURBO_ACTIVATION_RATIO to max non
turbo P state from PLATFORM_INFO.

Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Yong, Jonathan 
---
 arch/x86/include/uapi/asm/msr-index.h |  1 +
 drivers/cpufreq/intel_pstate.c| 26 ++
 2 files changed, 27 insertions(+)

diff --git a/arch/x86/include/uapi/asm/msr-index.h 
b/arch/x86/include/uapi/asm/msr-index.h
index a63a302..899effc 100644
--- a/arch/x86/include/uapi/asm/msr-index.h
+++ b/arch/x86/include/uapi/asm/msr-index.h
@@ -64,6 +64,7 @@
 #define MSR_TURBO_RATIO_LIMIT  0x01ad
 #define MSR_TURBO_RATIO_LIMIT1 0x01ae
 #define MSR_TURBO_RATIO_LIMIT2 0x01af
+#define MSR_TURBO_ACTIVATION_RATIO 0x064c
 
 #define MSR_LBR_SELECT 0x01c8
 #define MSR_LBR_TOS0x01c9
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 7d02796..389e55b 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -129,6 +129,7 @@ struct pstate_funcs {
int (*get_max)(void);
int (*get_min)(void);
int (*get_turbo)(void);
+   void (*adjust_states)(struct cpudata *);
int (*get_scaling)(void);
void (*set)(struct cpudata*, int pstate);
void (*get_vid)(struct cpudata *);
@@ -601,6 +602,26 @@ static int core_get_turbo_pstate(void)
return ret;
 }
 
+static void core_adjust_states(struct cpudata *cpudata)
+{
+   u64 value;
+
+   if (rdmsrl_safe(MSR_TURBO_ACTIVATION_RATIO, ))
+   return;
+
+   if (value & BIT(31))
+   return; /* locked */
+
+   if (cpudata->pstate.max_pstate > value) {
+   int err;
+
+   value = cpudata->pstate.max_pstate & 0xff;
+   err = wrmsrl_safe(MSR_TURBO_ACTIVATION_RATIO, value);
+   if (err)
+   pr_err("Adjust MSR_TURBO_ACTIVATION_RATIO failed\n");
+   }
+}
+
 static inline int core_get_scaling(void)
 {
return 10;
@@ -645,6 +666,7 @@ static struct cpu_defaults core_params = {
.get_turbo = core_get_turbo_pstate,
.get_scaling = core_get_scaling,
.set = core_set_pstate,
+   .adjust_states = core_adjust_states,
},
 };
 
@@ -738,6 +760,9 @@ static void intel_pstate_get_cpu_pstates(struct cpudata 
*cpu)
if (pstate_funcs.get_vid)
pstate_funcs.get_vid(cpu);
intel_pstate_set_pstate(cpu, cpu->pstate.min_pstate, false);
+
+   if (pstate_funcs.adjust_states)
+   pstate_funcs.adjust_states(cpu);
 }
 
 static inline void intel_pstate_calc_busy(struct cpudata *cpu)
@@ -1106,6 +1131,7 @@ static void copy_cpu_funcs(struct pstate_funcs *funcs)
pstate_funcs.get_scaling = funcs->get_scaling;
pstate_funcs.set   = funcs->set;
pstate_funcs.get_vid   = funcs->get_vid;
+   pstate_funcs.adjust_states   = funcs->adjust_states;
 }
 
 #if IS_ENABLED(CONFIG_ACPI)
-- 
2.7.3

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

[linux-yocto] [PATCH 0/4] P-state patches for linux-yocto-4.1 (atandard/intel/base)

[Yong, Jonathan]

These patches are for Apollo Lake Pstate support. These are not in Linus's
kernel tree yet, so these should go into standard/intel/base.

This series should apply AFTER the 2 P-state patches for linux-yocto-4.1
series.

Thanks.

Kristen Carlson Accardi (1):
  intel_pstate: add support for BXT-P

Srinivas Pandruvada (2):
  cpufreq: intel_p_state: Fix P1 and below as guaranteed performance
  cpufreq: intel_p_state: Fix limiting turbo sub states

kbuild test robot (1):
  cpufreq: intel_p_state: core_get_turbo_ratio_limit() can be static

 arch/x86/include/uapi/asm/msr-index.h |   1 +
 drivers/cpufreq/intel_pstate.c| 122 +-
 2 files changed, 121 insertions(+), 2 deletions(-)

-- 
2.7.3

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

[linux-yocto] [PATCH 0/2] P-state patches for linux-yocto-4.1 part 2

[Yong, Jonathan]

After digging through the development logs much deeper, these 2
changes were also found in the mainline kernel, originally meant
for standard/intel/base, can now be moved to standard/base.

Meant to be applied AFTER the first P-state patch series.

Thanks.

Kristen Carlson Accardi (2):
  intel_pstate: enable HWP per CPU
  intel_pstate: Add SKY-S support

 drivers/cpufreq/intel_pstate.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

-- 
2.7.3

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

[linux-yocto] [PATCH 1/2] intel_pstate: enable HWP per CPU

[Yong, Jonathan]

From: Kristen Carlson Accardi 

HWP previously was only enabled at driver load time, on the boot
CPU, however, HWP must be enabled per package. Move the code to
enable HWP to the cpufreq driver init path so that it will be
called per CPU.

Signed-off-by: Kristen Carlson Accardi 
Tested-by: David Zhuang 
Signed-off-by: Rafael J. Wysocki 
(cherry picked from commit ba88d4338f226766f510e207911dde8c1875e072)
Signed-off-by: Yong, Jonathan 
---
 drivers/cpufreq/intel_pstate.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index aba2117..17894f3 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -484,12 +484,11 @@ static void __init intel_pstate_sysfs_expose_params(void)
 }
 /** sysfs end /
 
-static void intel_pstate_hwp_enable(void)
+static void intel_pstate_hwp_enable(struct cpudata *cpudata)
 {
-   hwp_active++;
pr_info("intel_pstate: HWP enabled\n");
 
-   wrmsrl( MSR_PM_ENABLE, 0x1);
+   wrmsrl_on_cpu(cpudata->cpu, MSR_PM_ENABLE, 0x1);
 }
 
 static int byt_get_min_pstate(void)
@@ -938,6 +937,10 @@ static int intel_pstate_init_cpu(unsigned int cpunum)
cpu = all_cpu_data[cpunum];
 
cpu->cpu = cpunum;
+
+   if (hwp_active)
+   intel_pstate_hwp_enable(cpu);
+
intel_pstate_get_cpu_pstates(cpu);
 
init_timer_deferrable(>timer);
@@ -1251,7 +1254,7 @@ static int __init intel_pstate_init(void)
return -ENOMEM;
 
if (static_cpu_has_safe(X86_FEATURE_HWP) && !no_hwp)
-   intel_pstate_hwp_enable();
+   hwp_active++;
 
if (!hwp_active && hwp_only)
goto out;
-- 
2.7.3

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

[linux-yocto] [PATCH 2/2] intel_pstate: Add SKY-S support

[Yong, Jonathan]

From: Kristen Carlson Accardi 

Whitelist the SKL-S processor

Signed-off-by: Kristen Carlson Accardi 
Signed-off-by: Rafael J. Wysocki 
(cherry picked from commit 1c9391238753ffb370f02743b5f43bac6dea304b)
Signed-off-by: Yong, Jonathan 
---
 drivers/cpufreq/intel_pstate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 17894f3..c374816 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -913,6 +913,7 @@ static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
ICPU(0x4c, byt_params),
ICPU(0x4e, core_params),
ICPU(0x4f, core_params),
+   ICPU(0x5e, core_params),
ICPU(0x56, core_params),
ICPU(0x57, knl_params),
{}
-- 
2.7.3

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

[linux-yocto] [PATCH 4/4] x86/mm: Decouple from

[Yong, Jonathan]

From: Stephen Rothwell 

Nothing in  uses anything from , so
remove it from there and fix up the resulting build problems
triggered on x86 {64|32}-bit {def|allmod|allno}configs.

The breakages were triggering in places where x86 builds relied
on vmalloc() facilities but did not include 
explicitly and relied on the implicit inclusion via .

Also add:

  -  to 
  -  to 

... which were two other implicit header file dependencies.

Suggested-by: David Miller 
Signed-off-by: Stephen Rothwell 
[ Tidied up the changelog. ]
Acked-by: David Miller 
Acked-by: Takashi Iwai 
Acked-by: Viresh Kumar 
Acked-by: Vinod Koul 
Cc: Andrew Morton 
Cc: Anton Vorontsov 
Cc: Boris Ostrovsky 
Cc: Colin Cross 
Cc: David Vrabel 
Cc: H. Peter Anvin 
Cc: Haiyang Zhang 
Cc: James E.J. Bottomley 
Cc: Jaroslav Kysela 
Cc: K. Y. Srinivasan 
Cc: Kees Cook 
Cc: Konrad Rzeszutek Wilk 
Cc: Kristen Carlson Accardi 
Cc: Len Brown 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Rafael J. Wysocki 
Cc: Suma Ramars 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Signed-off-by: Ingo Molnar 

(cherry picked from commit d6472302f242559d45dcf4ebace62508dc4d8aeb)
Signed-off-by: Yong, Jonathan 
---
 arch/x86/include/asm/io.h  | 3 +--
 arch/x86/kernel/crash.c| 1 +
 arch/x86/kernel/machine_kexec_64.c | 1 +
 arch/x86/mm/pageattr-test.c| 1 +
 arch/x86/mm/pageattr.c | 1 +
 arch/x86/xen/p2m.c | 1 +
 drivers/acpi/apei/erst.c   | 1 +
 drivers/cpufreq/intel_pstate.c | 1 +
 drivers/dma/mic_x100_dma.c | 1 +
 drivers/net/hyperv/netvsc.c| 1 +
 drivers/net/hyperv/rndis_filter.c  | 1 +
 drivers/scsi/fnic/fnic_debugfs.c   | 1 +
 drivers/scsi/fnic/fnic_trace.c | 1 +
 include/linux/io.h | 1 +
 sound/pci/asihpi/hpioctl.c | 1 +
 15 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 34a5b93..2a3543a 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define build_mmio_read(name, size, type, reg, barrier) \
 static inline type name(const volatile void __iomem *addr) \
@@ -197,8 +198,6 @@ extern void set_iounmap_nonlazy(void);
 
 #include 
 
-#include 
-
 /*
  * Convert a virtual cached pointer to an uncached pointer
  */
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 403ace5..74ca2fe 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/kernel/machine_kexec_64.c 
b/arch/x86/kernel/machine_kexec_64.c
index 415480d..11546b4 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/mm/pageattr-test.c b/arch/x86/mm/pageattr-test.c
index 6629f39..8ff686a 100644
--- a/arch/x86/mm/pageattr-test.c
+++ b/arch/x86/mm/pageattr-test.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 2dd9b3a..c5d0fdc 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index b47124d..8b7f18e 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -67,6 +67,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/drivers/acpi/apei/erst.c b/drivers/acpi/apei/erst.c
index ed65e9c..3670bba 100644
--- a/drivers/acpi/apei/erst.c
+++ b/drivers/acpi/apei/erst.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "apei-internal.h"
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index ad68c1f..aba2117 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/drivers/dma/mic_x100_dma.c b/drivers/dma/mic_x100_dma.c
index 6de2e67..74d9db0 100644
--- a/drivers/dma/mic_x100_dma.c
+++ b/drivers/dma/mic_x100_dma.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mic_x100_dma.h"
 
diff 

[linux-yocto] [PATCH 3/4] intel_pstate: Force setting target pstate when required

[Yong, Jonathan]

From: Doug Smythies 

During initialization and exit it is possible that the target pstate
might not actually be set. Furthermore, the result can be that the
driver and the processor are out of synch and, under some conditions,
the driver might never send the processor the proper target pstate.

This patch adds a bypass or do_checks flag to the call to
intel_pstate_set_pstate. If bypass, then specifically bypass clamp
checks and the do not send if it is the same as last time check. If
do_checks, then, and as before, do the current policy clamp checks,
and do not do actual send if the new target is the same as the old.

Signed-off-by: Doug Smythies 
Reported-by: Marien Zwart 
Reported-by: Alex Lochmann 
Reported-by: Piotr Ko?aczkowski 
Reported-by: Clemens Eisserer 
Tested-by: Marien Zwart 
Tested-by: Doug Smythies 
[ rjw: Dropped pointless symbol definitions, rebased ]
Signed-off-by: Rafael J. Wysocki 

(cherry picked from commit 6c1e45917dec5e7c99ba8125fd8cc50f6e482a21)
Signed-off-by: Yong, Jonathan 
---
 drivers/cpufreq/intel_pstate.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index f93c7e4..ad68c1f 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -707,19 +707,20 @@ static void intel_pstate_get_min_max(struct cpudata *cpu, 
int *min, int *max)
*min = clamp_t(int, min_perf, cpu->pstate.min_pstate, max_perf);
 }
 
-static void intel_pstate_set_pstate(struct cpudata *cpu, int pstate)
+static void intel_pstate_set_pstate(struct cpudata *cpu, int pstate, bool 
force)
 {
int max_perf, min_perf;
 
-   update_turbo_state();
-
-   intel_pstate_get_min_max(cpu, _perf, _perf);
+   if (force) {
+   update_turbo_state();
 
-   pstate = clamp_t(int, pstate, min_perf, max_perf);
+   intel_pstate_get_min_max(cpu, _perf, _perf);
 
-   if (pstate == cpu->pstate.current_pstate)
-   return;
+   pstate = clamp_t(int, pstate, min_perf, max_perf);
 
+   if (pstate == cpu->pstate.current_pstate)
+   return;
+   }
trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
 
cpu->pstate.current_pstate = pstate;
@@ -736,7 +737,7 @@ static void intel_pstate_get_cpu_pstates(struct cpudata 
*cpu)
 
if (pstate_funcs.get_vid)
pstate_funcs.get_vid(cpu);
-   intel_pstate_set_pstate(cpu, cpu->pstate.min_pstate);
+   intel_pstate_set_pstate(cpu, cpu->pstate.min_pstate, false);
 }
 
 static inline void intel_pstate_calc_busy(struct cpudata *cpu)
@@ -861,7 +862,7 @@ static inline void intel_pstate_adjust_busy_pstate(struct 
cpudata *cpu)
ctl = pid_calc(pid, busy_scaled);
 
/* Negative values of ctl increase the pstate and vice versa */
-   intel_pstate_set_pstate(cpu, cpu->pstate.current_pstate - ctl);
+   intel_pstate_set_pstate(cpu, cpu->pstate.current_pstate - ctl, true);
 
sample = >sample;
trace_pstate_sample(fp_toint(sample->core_pct_busy),
@@ -1024,7 +1025,7 @@ static void intel_pstate_stop_cpu(struct cpufreq_policy 
*policy)
if (hwp_active)
return;
 
-   intel_pstate_set_pstate(cpu, cpu->pstate.min_pstate);
+   intel_pstate_set_pstate(cpu, cpu->pstate.min_pstate, false);
 }
 
 static int intel_pstate_cpu_init(struct cpufreq_policy *policy)
-- 
2.7.3

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

[linux-yocto] [PATCH 2/4] intel_pstate: change some inconsistent debug information

[Yong, Jonathan]

From: Doug Smythies 

Commit ce717613f3fb (intel_pstate: Turn per cpu printk into pr_debug)
turned per cpu printk into pr_debug.  However, only half of the change
was done, introducing an inconsistency between entry and exit from
driver pstate control.  This patch changes the exit message to pr_debug
also.

The various messages are inconsistent with respect to any identifier
text that can be used to help isolate the desired information from a
huge log.  This patch makes a consistent identifier portion of the
string.

Amends: ce717613f3fb (intel_pstate: Turn per cpu printk into pr_debug)
Signed-off-by: Doug Smythies 
Signed-off-by: Rafael J. Wysocki 
(cherry picked from commit f16255eb930173f386db0ce78ed41401aa8a94a6)
Signed-off-by: Yong, Jonathan 
---
 drivers/cpufreq/intel_pstate.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 9860f90..f93c7e4 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -398,7 +398,7 @@ static ssize_t store_no_turbo(struct kobject *a, struct 
attribute *b,
 
update_turbo_state();
if (limits.turbo_disabled) {
-   pr_warn("Turbo disabled by BIOS or unavailable on processor\n");
+   pr_warn("intel_pstate: Turbo disabled by BIOS or unavailable on 
processor\n");
return -EPERM;
}
 
@@ -486,7 +486,7 @@ static void __init intel_pstate_sysfs_expose_params(void)
 static void intel_pstate_hwp_enable(void)
 {
hwp_active++;
-   pr_info("intel_pstate HWP enabled\n");
+   pr_info("intel_pstate: HWP enabled\n");
 
wrmsrl( MSR_PM_ENABLE, 0x1);
 }
@@ -952,7 +952,7 @@ static int intel_pstate_init_cpu(unsigned int cpunum)
 
add_timer_on(>timer, cpunum);
 
-   pr_debug("Intel pstate controlling: cpu %d\n", cpunum);
+   pr_debug("intel_pstate: controlling: cpu %d\n", cpunum);
 
return 0;
 }
@@ -1018,7 +1018,7 @@ static void intel_pstate_stop_cpu(struct cpufreq_policy 
*policy)
int cpu_num = policy->cpu;
struct cpudata *cpu = all_cpu_data[cpu_num];
 
-   pr_info("intel_pstate CPU %d exiting\n", cpu_num);
+   pr_debug("intel_pstate: CPU %d exiting\n", cpu_num);
 
del_timer_sync(_cpu_data[cpu_num]->timer);
if (hwp_active)
-- 
2.7.3

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

[linux-yocto] [PATCH 1/4] intel_pstate: Add tsc collection and keep previous target pstate

[Yong, Jonathan]

From: Doug Smythies 

The intel_pstate driver is difficult to debug and investigate without tsc.

Also, it is likely use of tsc, and some version of C0 percentage,
will be re-introdcued in futute.

There have also been occasions where it is desirebale to know, and
confirm, the previous target pstate.

This patch brings back tsc, adds previous target pstate,
and adds both to the trace data collection.

Signed-off-by: Doug Smythies 
Acked-by: Kristen Carlson Accardi 
Signed-off-by: Rafael J. Wysocki 
(cherry picked from commit 4055fad34086dcf5229c43846e0a3cf0fb3692e3)
Signed-off-by: Yong, Jonathan 
---
 drivers/cpufreq/intel_pstate.c | 31 +--
 include/trace/events/power.h   | 25 +
 2 files changed, 38 insertions(+), 18 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 1ee2ab5..9860f90 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -68,6 +68,7 @@ struct sample {
int32_t core_pct_busy;
u64 aperf;
u64 mperf;
+   u64 tsc;
int freq;
ktime_t time;
 };
@@ -109,6 +110,7 @@ struct cpudata {
ktime_t last_sample_time;
u64 prev_aperf;
u64 prev_mperf;
+   u64 prev_tsc;
struct sample sample;
 };
 
@@ -757,6 +759,7 @@ static inline void intel_pstate_sample(struct cpudata *cpu)
 {
u64 aperf, mperf;
unsigned long flags;
+   u64 tsc;
 
local_irq_save(flags);
rdmsrl(MSR_IA32_APERF, aperf);
@@ -766,19 +769,23 @@ static inline void intel_pstate_sample(struct cpudata 
*cpu)
return;
}
 
+   tsc = native_read_tsc();
local_irq_restore(flags);
 
cpu->last_sample_time = cpu->sample.time;
cpu->sample.time = ktime_get();
cpu->sample.aperf = aperf;
cpu->sample.mperf = mperf;
+   cpu->sample.tsc =  tsc;
cpu->sample.aperf -= cpu->prev_aperf;
cpu->sample.mperf -= cpu->prev_mperf;
+   cpu->sample.tsc -= cpu->prev_tsc;
 
intel_pstate_calc_busy(cpu);
 
cpu->prev_aperf = aperf;
cpu->prev_mperf = mperf;
+   cpu->prev_tsc = tsc;
 }
 
 static inline void intel_hwp_set_sample_time(struct cpudata *cpu)
@@ -843,6 +850,10 @@ static inline void intel_pstate_adjust_busy_pstate(struct 
cpudata *cpu)
int32_t busy_scaled;
struct _pid *pid;
signed int ctl;
+   int from;
+   struct sample *sample;
+
+   from = cpu->pstate.current_pstate;
 
pid = >pid;
busy_scaled = intel_pstate_get_scaled_busy(cpu);
@@ -851,6 +862,16 @@ static inline void intel_pstate_adjust_busy_pstate(struct 
cpudata *cpu)
 
/* Negative values of ctl increase the pstate and vice versa */
intel_pstate_set_pstate(cpu, cpu->pstate.current_pstate - ctl);
+
+   sample = >sample;
+   trace_pstate_sample(fp_toint(sample->core_pct_busy),
+   fp_toint(busy_scaled),
+   from,
+   cpu->pstate.current_pstate,
+   sample->mperf,
+   sample->aperf,
+   sample->tsc,
+   sample->freq);
 }
 
 static void intel_hwp_timer_func(unsigned long __data)
@@ -864,21 +885,11 @@ static void intel_hwp_timer_func(unsigned long __data)
 static void intel_pstate_timer_func(unsigned long __data)
 {
struct cpudata *cpu = (struct cpudata *) __data;
-   struct sample *sample;
 
intel_pstate_sample(cpu);
 
-   sample = >sample;
-
intel_pstate_adjust_busy_pstate(cpu);
 
-   trace_pstate_sample(fp_toint(sample->core_pct_busy),
-   fp_toint(intel_pstate_get_scaled_busy(cpu)),
-   cpu->pstate.current_pstate,
-   sample->mperf,
-   sample->aperf,
-   sample->freq);
-
intel_pstate_set_sample_time(cpu);
 }
 
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index d19840b..630d1e5 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -42,45 +42,54 @@ TRACE_EVENT(pstate_sample,
 
TP_PROTO(u32 core_busy,
u32 scaled_busy,
-   u32 state,
+   u32 from,
+   u32 to,
u64 mperf,
u64 aperf,
+   u64 tsc,
u32 freq
),
 
TP_ARGS(core_busy,
scaled_busy,
-   state,
+   from,
+   to,
mperf,
aperf,
+   tsc,
freq
),
 
TP_STRUCT__entry(
__field(u32, core_busy)
__field(u32, scaled_busy)
-   __field(u32, state)
+   __field(u32, from)
+   __field(u32, to)
   

[linux-yocto] [PATCH 0/4] P-state patches for linux-yocto-4.1

[Yong, Jonathan]

Backported from mainline kernel and tested on Apollo Lake.
This should go into standard/base.

Thanks.

Doug Smythies (3):
  intel_pstate: Add tsc collection and keep previous target pstate
  intel_pstate: change some inconsistent debug information
  intel_pstate: Force setting target pstate when required

Stephen Rothwell (1):
  x86/mm: Decouple  from 

 arch/x86/include/asm/io.h  |  3 +-
 arch/x86/kernel/crash.c|  1 +
 arch/x86/kernel/machine_kexec_64.c |  1 +
 arch/x86/mm/pageattr-test.c|  1 +
 arch/x86/mm/pageattr.c |  1 +
 arch/x86/xen/p2m.c |  1 +
 drivers/acpi/apei/erst.c   |  1 +
 drivers/cpufreq/intel_pstate.c | 61 +++---
 drivers/dma/mic_x100_dma.c |  1 +
 drivers/net/hyperv/netvsc.c|  1 +
 drivers/net/hyperv/rndis_filter.c  |  1 +
 drivers/scsi/fnic/fnic_debugfs.c   |  1 +
 drivers/scsi/fnic/fnic_trace.c |  1 +
 include/linux/io.h |  1 +
 include/trace/events/power.h   | 25 +++-
 sound/pci/asihpi/hpioctl.c |  1 +
 16 files changed, 68 insertions(+), 34 deletions(-)

-- 
2.7.3

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

Re: [yocto] [oe] Patchwork users: Help test new version

[Burton, Ross]

On 20 June 2016 at 18:47, Michael Halstead 
wrote:

> OpenEmbedded is nearly ready to upgrade to a new version of Patchwork.
> The new version offers several new features that will allow OpenEmbedded
> to improve developer workflow and automated checks on incoming patches.
>

Woohoo!

Thanks Michael (and everyone else who helped on this over the months).

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

[yocto] [[PATCH][AUH] 3/3] upgradehelper.py: Disable _order_pkgs_to_upgrade functionality

[Aníbal Limón]

The _order_pkgs_to_upgrade function order a set of packages to
be upgraded based on bitbake dependency graph, currently _order_pkgs_to_upgrade
is broken so disable it while fix.

Signed-off-by: Aníbal Limón 
---
 upgradehelper.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 386cbcc..239fd88 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -500,8 +500,9 @@ class Updater(object):
 return pkgs_to_upgrade_ordered
 
 def run(self, package_list=None):
-pkgs_to_upgrade = self._order_pkgs_to_upgrade(
-self._get_packages_to_upgrade(package_list))
+#pkgs_to_upgrade = self._order_pkgs_to_upgrade(
+#self._get_packages_to_upgrade(package_list))
+pkgs_to_upgrade = self._get_packages_to_upgrade(package_list)
 total_pkgs = len(pkgs_to_upgrade)
 
 pkgs_ctx = {}
-- 
2.1.4

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

[yocto] [[PATCH][AUH] 1/3] Small fixes to use with Python3.

[Aníbal Limón]

[YOCTO #9747]

Signed-off-by: Aníbal Limón 
---
 modules/recipe/svn.py | 2 +-
 modules/utils/emailhandler.py | 2 +-
 upgradehelper.py  | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/modules/recipe/svn.py b/modules/recipe/svn.py
index 6d60529..6dadafd 100644
--- a/modules/recipe/svn.py
+++ b/modules/recipe/svn.py
@@ -22,7 +22,7 @@
 # Marius Avram  
 #
 
-from base import Recipe
+from recipe.base import Recipe
 
 class SvnRecipe(Recipe):
 pass
diff --git a/modules/utils/emailhandler.py b/modules/utils/emailhandler.py
index 970fb59..8436364 100644
--- a/modules/utils/emailhandler.py
+++ b/modules/utils/emailhandler.py
@@ -33,7 +33,7 @@ from email.mime.base import MIMEBase
 from email.mime.multipart import MIMEMultipart
 from email.generator import Generator
 import shutil
-from cStringIO import StringIO
+from io import StringIO
 
 class Email(object):
 def __init__(self, settings):
diff --git a/upgradehelper.py b/upgradehelper.py
index d4b8afb..499c539 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 # vim: set ts=4 sw=4 et:
 #
 # Copyright (c) 2013 - 2014 Intel Corporation
@@ -40,7 +40,7 @@ from logging import critical as C
 import re
 import signal
 import sys
-import ConfigParser as cp
+import configparser as cp
 from datetime import datetime
 from datetime import date
 import shutil
-- 
2.1.4

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

[yocto] [[PATCH][AUH] 2/3] upgradehelper.py: Move build of gcc runtime after discover packages

[Aníbal Limón]

If no packages are found to upgrade, it didn't make sense to build
gcc runtime before is only a waste of time.

Signed-off-by: Aníbal Limón 
---
 upgradehelper.py | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 499c539..386cbcc 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -500,20 +500,6 @@ class Updater(object):
 return pkgs_to_upgrade_ordered
 
 def run(self, package_list=None):
-I(" Building gcc runtimes ...")
-for machine in self.opts['machines']:
-I("  building gcc runtime for %s" % machine)
-try:
-self.bb.complete("gcc-runtime", machine)
-except Exception as e:
-E(" Can't build gcc-runtime for %s." % machine)
-
-if isinstance(e, Error):
-E(e.stdout)
-else:
-import traceback
-traceback.print_exc(file=sys.stdout)
-
 pkgs_to_upgrade = self._order_pkgs_to_upgrade(
 self._get_packages_to_upgrade(package_list))
 total_pkgs = len(pkgs_to_upgrade)
@@ -532,6 +518,21 @@ class Updater(object):
 pkgs_ctx[p]['base_dir'] = self.uh_recipes_all_dir
 I(" ")
 
+if pkgs_to_upgrade:
+I(" Building gcc runtimes ...")
+for machine in self.opts['machines']:
+I("  building gcc runtime for %s" % machine)
+try:
+self.bb.complete("gcc-runtime", machine)
+except Exception as e:
+E(" Can't build gcc-runtime for %s." % machine)
+
+if isinstance(e, Error):
+E(e.stdout)
+else:
+import traceback
+traceback.print_exc(file=sys.stdout)
+
 succeeded_pkgs_ctx = []
 failed_pkgs_ctx = []
 attempted_pkgs = 0
-- 
2.1.4

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

Re: [yocto] Crosscompiling python extensions with yocto generated toolchains!?

[Daniel.]

My first doubt was how to trully cross-compile python extensions. Since I
can't find anything usefull on internet I ask my self: How OE does it? It
seems that OE uses an patched distutils to get bits build. This
"assumption" comes from what I see at distutils/sysconfig.py that lives at
build/tmp/sysroot/.. folder. After more digging I found this patch:
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/python/python-native/12-distutils-prefix-is-inside-staging-area.patch?h=daisy

The variables are aplied by this patch to the python-native (since I'm
still in Daisy, shame on me). At the top of the patch we see:

The proper prefix is inside our staging area.

So I'll try to contact these people to track the "proper fix". Since
crosscompiling python extensions is lacking of

documentation reading the source and talking to the gurus is the only
option avaible right now :) .


Regards,



2016-06-20 16:23 GMT-03:00 Khem Raj :

> On Mon, Jun 20, 2016 at 12:08 PM, Daniel.  wrote:
> > I've found this recipe "python-pycurl" with exports libcurl to python.
> What
> > I did was build it and take a look at temp folder to stalk what line is
> used
> > to compile that stuff. Here it is:
> >
> > distutils_do_compile() {
> >
> >
> STAGING_INCDIR=/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/pharosserver-imx6/usr/include
> > \
> >
> >
> STAGING_LIBDIR=/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/pharosserver-imx6/usr/lib
> > \
> >  BUILD_SYS=x86_64-linux HOST_SYS=arm-poky-linux-gnueabi \
> >
> >
> /home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/x86_64-linux/usr/bin/python-native/python
> > setup.py build  || \
> >  bbfatal "python setup.py build_ext execution failed."
> >
> > }
> >
> >
> > So I go to my extension's source folder and paste
> >
> STAGING_INCDIR=/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/pharosserver-imx6/usr/include
> > \
> >
> STAGING_LIBDIR=/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/pharosserver-imx6/usr/lib
> > \
> > BUILD_SYS=x86_64-linux HOST_SYS=arm-poky-linux-gnueabi \
> >
> /home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/x86_64-linux/usr/bin/python-native/python
> > setup.py build
> >
> > and everything works fine, I got my extension compiled. So, in what magic
> > are these enviroment variables envolved? STAGING_INCDIR
> > and STAGING_LIBDIR are OE stuff, what are these BUILD_SYS and HOST_SYS
> > related?! I'm still searching, anyway thanks Khen for
> > pointing me meta-python sources. It helped me a lot.
>
>
> OE has several classes where common operations are abstracted out and
> you can see that in recipes
> e.g. inherit setuptools etc. you should copy the recipe which is
> closest to your package and modify it
> to use your package source etc. and make other needed tweaks.
>
> >
> > Regards,
> >
> >
> > 2016-06-20 15:29 GMT-03:00 Daniel. :
> >>
> >> Thank you Khem!!
> >>
> >> Regards,
> >>
> >> 2016-06-20 15:02 GMT-03:00 Khem Raj :
> >>>
> >>> On Mon, Jun 20, 2016 at 10:44 AM, Daniel. 
> wrote:
> >>> > Hi everybody..
> >>> >
> >>> > I've been playing with python extensions. Now I want to compile a
> >>> > simple
> >>> > hello world extension
> >>> > to my Yocto's target, but I really can't find any good resource about
> >>> > doing
> >>> > it. So what is the teory behind it?
> >>> >
> >>> > I know that I need python headers "Python.h and others" and that I
> need
> >>> > distutils installed. After that everything is done by distutils and
> >>> > setup.py
> >>> > script, but what is done is a mistery. I found distutilscross on
> >>> > internet
> >>> > but no documentation about it!?
> >>> >
> >>> > How are python extensions cross-compiled by Yocto? Can somebody point
> >>> > me an
> >>> > example?!
> >>>
> >>> take a look at meta-python.
> >>>
> >>> http://cgit.openembedded.org/meta-openembedded/tree/meta-python
> >>>
> >>> You might find some examples close to what you are looking for.
> >>>
> >>> >
> >>> > Regards,
> >>> >
> >>> > --
> >>> > "Do or do not. There is no try"
> >>> >   Yoda Master
> >>> >
> >>> > --
> >>> > ___
> >>> > yocto mailing list
> >>> > yocto@yoctoproject.org
> >>> > https://lists.yoctoproject.org/listinfo/yocto
> >>> >
> >>
> >>
> >>
> >>
> >> --
> >> "Do or do not. There is no try"
> >>   Yoda Master
> >
> >
> >
> >
> > --
> > "Do or do not. There is no try"
> >   Yoda Master
>



-- 
*"Do or do not. There is no try"*
  *Yoda Master*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Crosscompiling python extensions with yocto generated toolchains!?

[Khem Raj]

On Mon, Jun 20, 2016 at 12:08 PM, Daniel.  wrote:
> I've found this recipe "python-pycurl" with exports libcurl to python. What
> I did was build it and take a look at temp folder to stalk what line is used
> to compile that stuff. Here it is:
>
> distutils_do_compile() {
>
> STAGING_INCDIR=/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/pharosserver-imx6/usr/include
> \
>
> STAGING_LIBDIR=/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/pharosserver-imx6/usr/lib
> \
>  BUILD_SYS=x86_64-linux HOST_SYS=arm-poky-linux-gnueabi \
>
> /home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/x86_64-linux/usr/bin/python-native/python
> setup.py build  || \
>  bbfatal "python setup.py build_ext execution failed."
>
> }
>
>
> So I go to my extension's source folder and paste
> STAGING_INCDIR=/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/pharosserver-imx6/usr/include
> \
> STAGING_LIBDIR=/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/pharosserver-imx6/usr/lib
> \
> BUILD_SYS=x86_64-linux HOST_SYS=arm-poky-linux-gnueabi \
> /home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/x86_64-linux/usr/bin/python-native/python
> setup.py build
>
> and everything works fine, I got my extension compiled. So, in what magic
> are these enviroment variables envolved? STAGING_INCDIR
> and STAGING_LIBDIR are OE stuff, what are these BUILD_SYS and HOST_SYS
> related?! I'm still searching, anyway thanks Khen for
> pointing me meta-python sources. It helped me a lot.


OE has several classes where common operations are abstracted out and
you can see that in recipes
e.g. inherit setuptools etc. you should copy the recipe which is
closest to your package and modify it
to use your package source etc. and make other needed tweaks.

>
> Regards,
>
>
> 2016-06-20 15:29 GMT-03:00 Daniel. :
>>
>> Thank you Khem!!
>>
>> Regards,
>>
>> 2016-06-20 15:02 GMT-03:00 Khem Raj :
>>>
>>> On Mon, Jun 20, 2016 at 10:44 AM, Daniel.  wrote:
>>> > Hi everybody..
>>> >
>>> > I've been playing with python extensions. Now I want to compile a
>>> > simple
>>> > hello world extension
>>> > to my Yocto's target, but I really can't find any good resource about
>>> > doing
>>> > it. So what is the teory behind it?
>>> >
>>> > I know that I need python headers "Python.h and others" and that I need
>>> > distutils installed. After that everything is done by distutils and
>>> > setup.py
>>> > script, but what is done is a mistery. I found distutilscross on
>>> > internet
>>> > but no documentation about it!?
>>> >
>>> > How are python extensions cross-compiled by Yocto? Can somebody point
>>> > me an
>>> > example?!
>>>
>>> take a look at meta-python.
>>>
>>> http://cgit.openembedded.org/meta-openembedded/tree/meta-python
>>>
>>> You might find some examples close to what you are looking for.
>>>
>>> >
>>> > Regards,
>>> >
>>> > --
>>> > "Do or do not. There is no try"
>>> >   Yoda Master
>>> >
>>> > --
>>> > ___
>>> > yocto mailing list
>>> > yocto@yoctoproject.org
>>> > https://lists.yoctoproject.org/listinfo/yocto
>>> >
>>
>>
>>
>>
>> --
>> "Do or do not. There is no try"
>>   Yoda Master
>
>
>
>
> --
> "Do or do not. There is no try"
>   Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Crosscompiling python extensions with yocto generated toolchains!?

[Daniel.]

I've found this recipe "python-pycurl" with exports libcurl to python. What
I did was build it and take a look at temp folder to stalk what line is
used to compile that stuff. Here it is:

distutils_do_compile() {

STAGING_INCDIR=/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/pharosserver-imx6/usr/include
\

STAGING_LIBDIR=/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/pharosserver-imx6/usr/lib
\
 BUILD_SYS=x86_64-linux HOST_SYS=arm-poky-linux-gnueabi \

/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/x86_64-linux/usr/bin/python-native/python
setup.py build  || \
 bbfatal "python setup.py build_ext execution failed."

}


So I go to my extension's source folder and paste
STAGING_INCDIR=/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/pharosserver-imx6/usr/include
\
STAGING_LIBDIR=/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/pharosserver-imx6/usr/lib
\
BUILD_SYS=x86_64-linux HOST_SYS=arm-poky-linux-gnueabi \
/home/geckos/yocto/yocto-daisy/build_x11/tmp/sysroots/x86_64-linux/usr/bin/python-native/python
setup.py build

and everything works fine, I got my extension compiled. So, in what magic
are these enviroment variables envolved? STAGING_INCDIR
and STAGING_LIBDIR are OE stuff, what are these BUILD_SYS and HOST_SYS
related?! I'm still searching, anyway thanks Khen for
pointing me meta-python sources. It helped me a lot.

Regards,


2016-06-20 15:29 GMT-03:00 Daniel. :

> Thank you Khem!!
>
> Regards,
>
> 2016-06-20 15:02 GMT-03:00 Khem Raj :
>
>> On Mon, Jun 20, 2016 at 10:44 AM, Daniel.  wrote:
>> > Hi everybody..
>> >
>> > I've been playing with python extensions. Now I want to compile a simple
>> > hello world extension
>> > to my Yocto's target, but I really can't find any good resource about
>> doing
>> > it. So what is the teory behind it?
>> >
>> > I know that I need python headers "Python.h and others" and that I need
>> > distutils installed. After that everything is done by distutils and
>> setup.py
>> > script, but what is done is a mistery. I found distutilscross on
>> internet
>> > but no documentation about it!?
>> >
>> > How are python extensions cross-compiled by Yocto? Can somebody point
>> me an
>> > example?!
>>
>> take a look at meta-python.
>>
>> http://cgit.openembedded.org/meta-openembedded/tree/meta-python
>>
>> You might find some examples close to what you are looking for.
>>
>> >
>> > Regards,
>> >
>> > --
>> > "Do or do not. There is no try"
>> >   Yoda Master
>> >
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>> >
>>
>
>
>
> --
> *"Do or do not. There is no try"*
>   *Yoda Master*
>



-- 
*"Do or do not. There is no try"*
  *Yoda Master*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Crosscompiling python extensions with yocto generated toolchains!?

[Daniel.]

Thank you Khem!!

Regards,

2016-06-20 15:02 GMT-03:00 Khem Raj :

> On Mon, Jun 20, 2016 at 10:44 AM, Daniel.  wrote:
> > Hi everybody..
> >
> > I've been playing with python extensions. Now I want to compile a simple
> > hello world extension
> > to my Yocto's target, but I really can't find any good resource about
> doing
> > it. So what is the teory behind it?
> >
> > I know that I need python headers "Python.h and others" and that I need
> > distutils installed. After that everything is done by distutils and
> setup.py
> > script, but what is done is a mistery. I found distutilscross on internet
> > but no documentation about it!?
> >
> > How are python extensions cross-compiled by Yocto? Can somebody point me
> an
> > example?!
>
> take a look at meta-python.
>
> http://cgit.openembedded.org/meta-openembedded/tree/meta-python
>
> You might find some examples close to what you are looking for.
>
> >
> > Regards,
> >
> > --
> > "Do or do not. There is no try"
> >   Yoda Master
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>



-- 
*"Do or do not. There is no try"*
  *Yoda Master*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Crosscompiling python extensions with yocto generated toolchains!?

[Khem Raj]

On Mon, Jun 20, 2016 at 10:44 AM, Daniel.  wrote:
> Hi everybody..
>
> I've been playing with python extensions. Now I want to compile a simple
> hello world extension
> to my Yocto's target, but I really can't find any good resource about doing
> it. So what is the teory behind it?
>
> I know that I need python headers "Python.h and others" and that I need
> distutils installed. After that everything is done by distutils and setup.py
> script, but what is done is a mistery. I found distutilscross on internet
> but no documentation about it!?
>
> How are python extensions cross-compiled by Yocto? Can somebody point me an
> example?!

take a look at meta-python.

http://cgit.openembedded.org/meta-openembedded/tree/meta-python

You might find some examples close to what you are looking for.

>
> Regards,
>
> --
> "Do or do not. There is no try"
>   Yoda Master
>
> --
> ___
> 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] Patchwork users: Help test new version

[akuster]

On 06/20/2016 10:47 AM, Michael Halstead wrote:
> Hello,
> 
> OpenEmbedded is nearly ready to upgrade to a new version of Patchwork.
> The new version offers several new features that will allow OpenEmbedded
> to improve developer workflow and automated checks on incoming patches.


> 
> If you are a Patchwork user please visit
> https://patchwork-next.openembedded.org/ and take a look. If you find
> anything amiss please e-mail me directly and include patchwork in the
> subject line.

great. I will take a look.

> 
> Thank you for your help upgrading this important system!
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Patchwork users: Help test new version

[Michael Halstead]

Hello,

OpenEmbedded is nearly ready to upgrade to a new version of Patchwork.
The new version offers several new features that will allow OpenEmbedded
to improve developer workflow and automated checks on incoming patches.

If you are a Patchwork user please visit
https://patchwork-next.openembedded.org/ and take a look. If you find
anything amiss please e-mail me directly and include patchwork in the
subject line.

Thank you for your help upgrading this important system!

-- 
Michael Halstead
Linux Foundation / SysAdmin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Crosscompiling python extensions with yocto generated toolchains!?

[Daniel.]

Hi everybody..

I've been playing with python extensions. Now I want to compile a simple
hello world extension
to my Yocto's target, but I really can't find any good resource about doing
it. So what is the teory behind it?

I know that I need python headers "Python.h and others" and that I need
distutils installed. After that everything is done by distutils and
setup.py script, but what is done is a mistery. I found distutilscross on
internet but no documentation about it!?

How are python extensions cross-compiled by Yocto? Can somebody point me an
example?!

Regards,

-- 
*"Do or do not. There is no try"*
  *Yoda Master*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] autoreconf

[Rajasekaran, Monica]

Thanks for the answer. But that threw the following errors:

ERROR: Nothing PROVIDES 'libcap-ng'. Close matches:
  libpng
  libcap
  libpcap

Thanks,
Monica 


-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: Monday, June 20, 2016 11:23 AM
To: Rajasekaran, Monica 
Cc: Paul Eggleton ; yocto@yoctoproject.org
Subject: Re: [yocto] autoreconf

OK its a library so debian renaming might be tricking you here.
IMAGE_INSTALL expects the output package names  ( not recipe name) sometimes 
there is a package with same name as recipe name generated so it may seem like 
you can use package name or recipe name but thats not how it works. So please 
do this

bitbake libcap-ng

then see whats the emitted ipk or rpm in deloy/ area. Add that name to 
IMAGE_INSTALL

On Mon, Jun 20, 2016 at 9:18 AM, Rajasekaran, Monica 
 wrote:
> Yes, I did the same.
>
> Thanks,
> Monica
>
>
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Monday, June 20, 2016 11:15 AM
> To: Rajasekaran, Monica 
> Cc: Paul Eggleton ; 
> yocto@yoctoproject.org
> Subject: Re: [yocto] autoreconf
>
> On Mon, Jun 20, 2016 at 9:12 AM, Rajasekaran, Monica 
>  wrote:
>> Thanks Paul and Khem, that worked!
>>
>> I also tried adding libcap-ng but it gives me the following error:
>
> where did you add it to ? it is a package so you have to add it to 
> IMAGE_INSTALL
>
>>
>> ERROR: Nothing RPROVIDES 'libcap-ng' (but 
>> /data/users/mrajase/l100_label_based_r100poc/repo/poky/meta-fss-produ
>> c t/recipes-core/images/fss-image-full.bb RDEPENDS on or otherwise 
>> requires it)
>>
>> But, I see it present at 
>> http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-support/libcap-ng/.??
>>
>> Thanks,
>> Monica
>>
>> -Original Message-
>> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
>> Sent: Sunday, June 19, 2016 5:14 PM
>> To: Rajasekaran, Monica 
>> Cc: Khem Raj ; yocto@yoctoproject.org
>> Subject: Re: [yocto] autoreconf
>>
>> Hi Monica,
>>
>> As shown in Khem's original example you need to add this through 
>> EXTRA_IMAGE_FEATURES, not IMAGE_INSTALL (since tools-sdk is a feature name, 
>> not a package name).
>>
>> Cheers,
>> Paul
>>
>> On Sun, 19 Jun 2016 20:23:53 Rajasekaran, Monica wrote:
>>> I added the following line to my recipe file,
>>>
>>> IMAGE_INSTALL += "tools-sdk"
>>>
>>> But there was the following error with the build:
>>>
>>> ERROR: Nothing RPROVIDES 'tools-sdk' (but 
>>> /data/users/mrajase/l100_label_based_r100poc/repo/poky/meta-fss-prod
>>> u c t/rec ipes-core/images/fss-image-full.bb RDEPENDS on or 
>>> otherwise requires it)
>>> NOTE: Runtime target 'tools-sdk' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['tools-sdk']
>>> ERROR: Required build target 'fss-image-full' has no buildable providers.
>>> Missing or unbuildable dependency chain was: ['fss-image-full', 
>>> 'tools-sdk']
>>
>>> Any idea on this?
>>>
>>> Thanks,
>>> Monica
>>>
>>> -Original Message-
>>> From: Khem Raj [mailto:raj.k...@gmail.com]
>>> Sent: Wednesday, June 15, 2016 3:48 PM
>>> To: Rajasekaran, Monica 
>>> Cc: Paul Eggleton ; 
>>> yocto@yoctoproject.org
>>> Subject: Re: [yocto] autoreconf
>>>
>>> That might work, however you might need more packages, so adding 
>>> tools-sdk will cover all of them in one go
>>
>>>
>>> > On Jun 15, 2016, at 1:47 PM, Rajasekaran, Monica 
>>> >  wrote:
>>
>>> > Hi Raj,
>>> >
>>> > Will adding a line in the image's recipe file like this work ?
>>> >
>>> > IMAGE_INSTALL = ”autoconf”
>>> >
>>> > I installed "git" and "resolvconf" in the same way. Just not sure 
>>> > about the package name this time.
>>
>>> > Thanks,
>>> > Monica
>>> >
>>> >
>>> > -Original Message-
>>> > From: Khem Raj [mailto:raj.k...@gmail.com]
>>> > Sent: Wednesday, June 15, 2016 3:42 PM
>>> > To: Rajasekaran, Monica 
>>> > Cc: Paul Eggleton ; 
>>> > yocto@yoctoproject.org
>>> > Subject: Re: [yocto] autoreconf
>>> >
>>> > You need to add autoconf to your target image, if you do not use 
>>> > Online package management
>>
>>> > EXTRA_IMAGE_FEATURES_append = “ tools-sdk”
>>> >
>>> > in local.conf might help
>>> >
>>> >
>>> >
>>> >> On Jun 15, 2016, at 1:35 PM, Rajasekaran, Monica 
>>> >>  wrote:
>>
>>> >> Hi Paul,
>>> >>
>>> >> Thank you. This is in the target.
>>> >>
>>> >> Thanks,
>>> >> Monica
>>> >>
>>> >> -Original Message-
>>> >> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
>>> >> Sent: Wednesday, June 15, 2016 3:25 PM
>>> >> To: Rajasekaran, Monica 

Re: [yocto] ubuntu xenial support

[Khem Raj]

On Mon, Jun 20, 2016 at 9:24 AM, Fred Ollinger
 wrote:
> Anyone using Ubuntu Xenial release yet?
>
> Any tricks to get it working?

master OE just works fine on 16.04 here

>
> Frederick
> --
> ___
> 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] ubuntu xenial support

[Fred Ollinger]

Anyone using Ubuntu Xenial release yet?

Any tricks to get it working?

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

Re: [yocto] autoreconf

[Khem Raj]

OK its a library so debian renaming might be tricking you here.
IMAGE_INSTALL expects the output package names  ( not recipe name)
sometimes there is a package with same name as recipe name generated
so it may seem like you can use package name or recipe name but thats
not how it works. So please do this

bitbake libcap-ng

then see whats the emitted ipk or rpm in deloy/ area. Add that name to
IMAGE_INSTALL

On Mon, Jun 20, 2016 at 9:18 AM, Rajasekaran, Monica
 wrote:
> Yes, I did the same.
>
> Thanks,
> Monica
>
>
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Monday, June 20, 2016 11:15 AM
> To: Rajasekaran, Monica 
> Cc: Paul Eggleton ; yocto@yoctoproject.org
> Subject: Re: [yocto] autoreconf
>
> On Mon, Jun 20, 2016 at 9:12 AM, Rajasekaran, Monica 
>  wrote:
>> Thanks Paul and Khem, that worked!
>>
>> I also tried adding libcap-ng but it gives me the following error:
>
> where did you add it to ? it is a package so you have to add it to 
> IMAGE_INSTALL
>
>>
>> ERROR: Nothing RPROVIDES 'libcap-ng' (but
>> /data/users/mrajase/l100_label_based_r100poc/repo/poky/meta-fss-produc
>> t/recipes-core/images/fss-image-full.bb RDEPENDS on or otherwise
>> requires it)
>>
>> But, I see it present at 
>> http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-support/libcap-ng/.??
>>
>> Thanks,
>> Monica
>>
>> -Original Message-
>> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
>> Sent: Sunday, June 19, 2016 5:14 PM
>> To: Rajasekaran, Monica 
>> Cc: Khem Raj ; yocto@yoctoproject.org
>> Subject: Re: [yocto] autoreconf
>>
>> Hi Monica,
>>
>> As shown in Khem's original example you need to add this through 
>> EXTRA_IMAGE_FEATURES, not IMAGE_INSTALL (since tools-sdk is a feature name, 
>> not a package name).
>>
>> Cheers,
>> Paul
>>
>> On Sun, 19 Jun 2016 20:23:53 Rajasekaran, Monica wrote:
>>> I added the following line to my recipe file,
>>>
>>> IMAGE_INSTALL += "tools-sdk"
>>>
>>> But there was the following error with the build:
>>>
>>> ERROR: Nothing RPROVIDES 'tools-sdk' (but
>>> /data/users/mrajase/l100_label_based_r100poc/repo/poky/meta-fss-produ
>>> c t/rec ipes-core/images/fss-image-full.bb RDEPENDS on or otherwise
>>> requires it)
>>> NOTE: Runtime target 'tools-sdk' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['tools-sdk']
>>> ERROR: Required build target 'fss-image-full' has no buildable providers.
>>> Missing or unbuildable dependency chain was: ['fss-image-full',
>>> 'tools-sdk']
>>
>>> Any idea on this?
>>>
>>> Thanks,
>>> Monica
>>>
>>> -Original Message-
>>> From: Khem Raj [mailto:raj.k...@gmail.com]
>>> Sent: Wednesday, June 15, 2016 3:48 PM
>>> To: Rajasekaran, Monica 
>>> Cc: Paul Eggleton ;
>>> yocto@yoctoproject.org
>>> Subject: Re: [yocto] autoreconf
>>>
>>> That might work, however you might need more packages, so adding
>>> tools-sdk will cover all of them in one go
>>
>>>
>>> > On Jun 15, 2016, at 1:47 PM, Rajasekaran, Monica
>>> >  wrote:
>>
>>> > Hi Raj,
>>> >
>>> > Will adding a line in the image's recipe file like this work ?
>>> >
>>> > IMAGE_INSTALL = ”autoconf”
>>> >
>>> > I installed "git" and "resolvconf" in the same way. Just not sure
>>> > about the package name this time.
>>
>>> > Thanks,
>>> > Monica
>>> >
>>> >
>>> > -Original Message-
>>> > From: Khem Raj [mailto:raj.k...@gmail.com]
>>> > Sent: Wednesday, June 15, 2016 3:42 PM
>>> > To: Rajasekaran, Monica 
>>> > Cc: Paul Eggleton ;
>>> > yocto@yoctoproject.org
>>> > Subject: Re: [yocto] autoreconf
>>> >
>>> > You need to add autoconf to your target image, if you do not use
>>> > Online package management
>>
>>> > EXTRA_IMAGE_FEATURES_append = “ tools-sdk”
>>> >
>>> > in local.conf might help
>>> >
>>> >
>>> >
>>> >> On Jun 15, 2016, at 1:35 PM, Rajasekaran, Monica
>>> >>  wrote:
>>
>>> >> Hi Paul,
>>> >>
>>> >> Thank you. This is in the target.
>>> >>
>>> >> Thanks,
>>> >> Monica
>>> >>
>>> >> -Original Message-
>>> >> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
>>> >> Sent: Wednesday, June 15, 2016 3:25 PM
>>> >> To: Rajasekaran, Monica 
>>> >> Cc: yocto@yoctoproject.org
>>> >> Subject: Re: [yocto] autoreconf
>>> >>
>>> >> Hi Monica,
>>> >>
>>> >> On Wed, 15 Jun 2016 20:17:16 Rajasekaran, Monica wrote:
>>> >>
>>> >>> What is the package to install autoreconf ? (Ubuntu equivalent:
>>> >>> apt-get install dh-autoreconf )
>>> >>>
>>> >>> I am getting the following error for one of my applications:
>>> >>> "autoreconf: command not found"
>>> >>
>>> >>
>>> >> autoreconf is 

Re: [yocto] autoreconf

[Rajasekaran, Monica]

It worked by replacing libcap-ng with just "libcap".

Thanks,
Monica 


-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Rajasekaran, Monica
Sent: Monday, June 20, 2016 11:19 AM
To: Khem Raj 
Cc: Paul Eggleton ; yocto@yoctoproject.org
Subject: Re: [yocto] autoreconf

Yes, I did the same. 

Thanks,
Monica


-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Monday, June 20, 2016 11:15 AM
To: Rajasekaran, Monica 
Cc: Paul Eggleton ; yocto@yoctoproject.org
Subject: Re: [yocto] autoreconf

On Mon, Jun 20, 2016 at 9:12 AM, Rajasekaran, Monica 
 wrote:
> Thanks Paul and Khem, that worked!
>
> I also tried adding libcap-ng but it gives me the following error:

where did you add it to ? it is a package so you have to add it to IMAGE_INSTALL

>
> ERROR: Nothing RPROVIDES 'libcap-ng' (but 
> /data/users/mrajase/l100_label_based_r100poc/repo/poky/meta-fss-produc
> t/recipes-core/images/fss-image-full.bb RDEPENDS on or otherwise 
> requires it)
>
> But, I see it present at 
> http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-support/libcap-ng/.??
>
> Thanks,
> Monica
>
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Sunday, June 19, 2016 5:14 PM
> To: Rajasekaran, Monica 
> Cc: Khem Raj ; yocto@yoctoproject.org
> Subject: Re: [yocto] autoreconf
>
> Hi Monica,
>
> As shown in Khem's original example you need to add this through 
> EXTRA_IMAGE_FEATURES, not IMAGE_INSTALL (since tools-sdk is a feature name, 
> not a package name).
>
> Cheers,
> Paul
>
> On Sun, 19 Jun 2016 20:23:53 Rajasekaran, Monica wrote:
>> I added the following line to my recipe file,
>>
>> IMAGE_INSTALL += "tools-sdk"
>>
>> But there was the following error with the build:
>>
>> ERROR: Nothing RPROVIDES 'tools-sdk' (but 
>> /data/users/mrajase/l100_label_based_r100poc/repo/poky/meta-fss-produ
>> c t/rec ipes-core/images/fss-image-full.bb RDEPENDS on or otherwise 
>> requires it)
>> NOTE: Runtime target 'tools-sdk' is unbuildable, removing...
>> Missing or unbuildable dependency chain was: ['tools-sdk']
>> ERROR: Required build target 'fss-image-full' has no buildable providers.
>> Missing or unbuildable dependency chain was: ['fss-image-full', 
>> 'tools-sdk']
>
>> Any idea on this?
>>
>> Thanks,
>> Monica
>>
>> -Original Message-
>> From: Khem Raj [mailto:raj.k...@gmail.com]
>> Sent: Wednesday, June 15, 2016 3:48 PM
>> To: Rajasekaran, Monica 
>> Cc: Paul Eggleton ; 
>> yocto@yoctoproject.org
>> Subject: Re: [yocto] autoreconf
>>
>> That might work, however you might need more packages, so adding 
>> tools-sdk will cover all of them in one go
>
>>
>> > On Jun 15, 2016, at 1:47 PM, Rajasekaran, Monica 
>> >  wrote:
>
>> > Hi Raj,
>> >
>> > Will adding a line in the image's recipe file like this work ?
>> >
>> > IMAGE_INSTALL = ”autoconf”
>> >
>> > I installed "git" and "resolvconf" in the same way. Just not sure 
>> > about the package name this time.
>
>> > Thanks,
>> > Monica
>> >
>> >
>> > -Original Message-
>> > From: Khem Raj [mailto:raj.k...@gmail.com]
>> > Sent: Wednesday, June 15, 2016 3:42 PM
>> > To: Rajasekaran, Monica 
>> > Cc: Paul Eggleton ; 
>> > yocto@yoctoproject.org
>> > Subject: Re: [yocto] autoreconf
>> >
>> > You need to add autoconf to your target image, if you do not use 
>> > Online package management
>
>> > EXTRA_IMAGE_FEATURES_append = “ tools-sdk”
>> >
>> > in local.conf might help
>> >
>> >
>> >
>> >> On Jun 15, 2016, at 1:35 PM, Rajasekaran, Monica 
>> >>  wrote:
>
>> >> Hi Paul,
>> >>
>> >> Thank you. This is in the target.
>> >>
>> >> Thanks,
>> >> Monica
>> >>
>> >> -Original Message-
>> >> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
>> >> Sent: Wednesday, June 15, 2016 3:25 PM
>> >> To: Rajasekaran, Monica 
>> >> Cc: yocto@yoctoproject.org
>> >> Subject: Re: [yocto] autoreconf
>> >>
>> >> Hi Monica,
>> >>
>> >> On Wed, 15 Jun 2016 20:17:16 Rajasekaran, Monica wrote:
>> >>
>> >>> What is the package to install autoreconf ? (Ubuntu equivalent:
>> >>> apt-get install dh-autoreconf )
>> >>>
>> >>> I am getting the following error for one of my applications:
>> >>> "autoreconf: command not found"
>> >>
>> >>
>> >> autoreconf is part of autoconf.
>> >>
>> >> Where is this? On the target or within the build system?
>> >>
>> >> Cheers,
>> >> Paul
>> >>
>> >> --
>> >>
>> >> Paul Eggleton
>> >> Intel Open Source Technology Centre
>> >> --
>> >> ___
>> 

Re: [yocto] autoreconf

[Rajasekaran, Monica]

Yes, I did the same. 

Thanks,
Monica


-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: Monday, June 20, 2016 11:15 AM
To: Rajasekaran, Monica 
Cc: Paul Eggleton ; yocto@yoctoproject.org
Subject: Re: [yocto] autoreconf

On Mon, Jun 20, 2016 at 9:12 AM, Rajasekaran, Monica 
 wrote:
> Thanks Paul and Khem, that worked!
>
> I also tried adding libcap-ng but it gives me the following error:

where did you add it to ? it is a package so you have to add it to IMAGE_INSTALL

>
> ERROR: Nothing RPROVIDES 'libcap-ng' (but 
> /data/users/mrajase/l100_label_based_r100poc/repo/poky/meta-fss-produc
> t/recipes-core/images/fss-image-full.bb RDEPENDS on or otherwise 
> requires it)
>
> But, I see it present at 
> http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-support/libcap-ng/.??
>
> Thanks,
> Monica
>
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Sunday, June 19, 2016 5:14 PM
> To: Rajasekaran, Monica 
> Cc: Khem Raj ; yocto@yoctoproject.org
> Subject: Re: [yocto] autoreconf
>
> Hi Monica,
>
> As shown in Khem's original example you need to add this through 
> EXTRA_IMAGE_FEATURES, not IMAGE_INSTALL (since tools-sdk is a feature name, 
> not a package name).
>
> Cheers,
> Paul
>
> On Sun, 19 Jun 2016 20:23:53 Rajasekaran, Monica wrote:
>> I added the following line to my recipe file,
>>
>> IMAGE_INSTALL += "tools-sdk"
>>
>> But there was the following error with the build:
>>
>> ERROR: Nothing RPROVIDES 'tools-sdk' (but 
>> /data/users/mrajase/l100_label_based_r100poc/repo/poky/meta-fss-produ
>> c t/rec ipes-core/images/fss-image-full.bb RDEPENDS on or otherwise 
>> requires it)
>> NOTE: Runtime target 'tools-sdk' is unbuildable, removing...
>> Missing or unbuildable dependency chain was: ['tools-sdk']
>> ERROR: Required build target 'fss-image-full' has no buildable providers.
>> Missing or unbuildable dependency chain was: ['fss-image-full', 
>> 'tools-sdk']
>
>> Any idea on this?
>>
>> Thanks,
>> Monica
>>
>> -Original Message-
>> From: Khem Raj [mailto:raj.k...@gmail.com]
>> Sent: Wednesday, June 15, 2016 3:48 PM
>> To: Rajasekaran, Monica 
>> Cc: Paul Eggleton ; 
>> yocto@yoctoproject.org
>> Subject: Re: [yocto] autoreconf
>>
>> That might work, however you might need more packages, so adding 
>> tools-sdk will cover all of them in one go
>
>>
>> > On Jun 15, 2016, at 1:47 PM, Rajasekaran, Monica 
>> >  wrote:
>
>> > Hi Raj,
>> >
>> > Will adding a line in the image's recipe file like this work ?
>> >
>> > IMAGE_INSTALL = ”autoconf”
>> >
>> > I installed "git" and "resolvconf" in the same way. Just not sure 
>> > about the package name this time.
>
>> > Thanks,
>> > Monica
>> >
>> >
>> > -Original Message-
>> > From: Khem Raj [mailto:raj.k...@gmail.com]
>> > Sent: Wednesday, June 15, 2016 3:42 PM
>> > To: Rajasekaran, Monica 
>> > Cc: Paul Eggleton ; 
>> > yocto@yoctoproject.org
>> > Subject: Re: [yocto] autoreconf
>> >
>> > You need to add autoconf to your target image, if you do not use 
>> > Online package management
>
>> > EXTRA_IMAGE_FEATURES_append = “ tools-sdk”
>> >
>> > in local.conf might help
>> >
>> >
>> >
>> >> On Jun 15, 2016, at 1:35 PM, Rajasekaran, Monica 
>> >>  wrote:
>
>> >> Hi Paul,
>> >>
>> >> Thank you. This is in the target.
>> >>
>> >> Thanks,
>> >> Monica
>> >>
>> >> -Original Message-
>> >> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
>> >> Sent: Wednesday, June 15, 2016 3:25 PM
>> >> To: Rajasekaran, Monica 
>> >> Cc: yocto@yoctoproject.org
>> >> Subject: Re: [yocto] autoreconf
>> >>
>> >> Hi Monica,
>> >>
>> >> On Wed, 15 Jun 2016 20:17:16 Rajasekaran, Monica wrote:
>> >>
>> >>> What is the package to install autoreconf ? (Ubuntu equivalent:
>> >>> apt-get install dh-autoreconf )
>> >>>
>> >>> I am getting the following error for one of my applications:
>> >>> "autoreconf: command not found"
>> >>
>> >>
>> >> autoreconf is part of autoconf.
>> >>
>> >> Where is this? On the target or within the build system?
>> >>
>> >> Cheers,
>> >> Paul
>> >>
>> >> --
>> >>
>> >> Paul Eggleton
>> >> Intel Open Source Technology Centre
>> >> --
>> >> ___
>> >> yocto mailing list
>> >> yocto@yoctoproject.org
>> >> https://lists.yoctoproject.org/listinfo/yocto
>> >
>> >
>>
>>
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] autoreconf

[Khem Raj]

On Mon, Jun 20, 2016 at 9:12 AM, Rajasekaran, Monica
 wrote:
> Thanks Paul and Khem, that worked!
>
> I also tried adding libcap-ng but it gives me the following error:

where did you add it to ? it is a package so you have to add it to IMAGE_INSTALL

>
> ERROR: Nothing RPROVIDES 'libcap-ng' (but 
> /data/users/mrajase/l100_label_based_r100poc/repo/poky/meta-fss-product/recipes-core/images/fss-image-full.bb
>  RDEPENDS on or otherwise requires it)
>
> But, I see it present at 
> http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-support/libcap-ng/.??
>
> Thanks,
> Monica
>
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Sunday, June 19, 2016 5:14 PM
> To: Rajasekaran, Monica 
> Cc: Khem Raj ; yocto@yoctoproject.org
> Subject: Re: [yocto] autoreconf
>
> Hi Monica,
>
> As shown in Khem's original example you need to add this through 
> EXTRA_IMAGE_FEATURES, not IMAGE_INSTALL (since tools-sdk is a feature name, 
> not a package name).
>
> Cheers,
> Paul
>
> On Sun, 19 Jun 2016 20:23:53 Rajasekaran, Monica wrote:
>> I added the following line to my recipe file,
>>
>> IMAGE_INSTALL += "tools-sdk"
>>
>> But there was the following error with the build:
>>
>> ERROR: Nothing RPROVIDES 'tools-sdk' (but
>> /data/users/mrajase/l100_label_based_r100poc/repo/poky/meta-fss-produc
>> t/rec ipes-core/images/fss-image-full.bb RDEPENDS on or otherwise
>> requires it)
>> NOTE: Runtime target 'tools-sdk' is unbuildable, removing...
>> Missing or unbuildable dependency chain was: ['tools-sdk']
>> ERROR: Required build target 'fss-image-full' has no buildable providers.
>> Missing or unbuildable dependency chain was: ['fss-image-full',
>> 'tools-sdk']
>
>> Any idea on this?
>>
>> Thanks,
>> Monica
>>
>> -Original Message-
>> From: Khem Raj [mailto:raj.k...@gmail.com]
>> Sent: Wednesday, June 15, 2016 3:48 PM
>> To: Rajasekaran, Monica 
>> Cc: Paul Eggleton ;
>> yocto@yoctoproject.org
>> Subject: Re: [yocto] autoreconf
>>
>> That might work, however you might need more packages, so adding
>> tools-sdk will cover all of them in one go
>
>>
>> > On Jun 15, 2016, at 1:47 PM, Rajasekaran, Monica
>> >  wrote:
>
>> > Hi Raj,
>> >
>> > Will adding a line in the image's recipe file like this work ?
>> >
>> > IMAGE_INSTALL = ”autoconf”
>> >
>> > I installed "git" and "resolvconf" in the same way. Just not sure
>> > about the package name this time.
>
>> > Thanks,
>> > Monica
>> >
>> >
>> > -Original Message-
>> > From: Khem Raj [mailto:raj.k...@gmail.com]
>> > Sent: Wednesday, June 15, 2016 3:42 PM
>> > To: Rajasekaran, Monica 
>> > Cc: Paul Eggleton ;
>> > yocto@yoctoproject.org
>> > Subject: Re: [yocto] autoreconf
>> >
>> > You need to add autoconf to your target image, if you do not use
>> > Online package management
>
>> > EXTRA_IMAGE_FEATURES_append = “ tools-sdk”
>> >
>> > in local.conf might help
>> >
>> >
>> >
>> >> On Jun 15, 2016, at 1:35 PM, Rajasekaran, Monica
>> >>  wrote:
>
>> >> Hi Paul,
>> >>
>> >> Thank you. This is in the target.
>> >>
>> >> Thanks,
>> >> Monica
>> >>
>> >> -Original Message-
>> >> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
>> >> Sent: Wednesday, June 15, 2016 3:25 PM
>> >> To: Rajasekaran, Monica 
>> >> Cc: yocto@yoctoproject.org
>> >> Subject: Re: [yocto] autoreconf
>> >>
>> >> Hi Monica,
>> >>
>> >> On Wed, 15 Jun 2016 20:17:16 Rajasekaran, Monica wrote:
>> >>
>> >>> What is the package to install autoreconf ? (Ubuntu equivalent:
>> >>> apt-get install dh-autoreconf )
>> >>>
>> >>> I am getting the following error for one of my applications:
>> >>> "autoreconf: command not found"
>> >>
>> >>
>> >> autoreconf is part of autoconf.
>> >>
>> >> Where is this? On the target or within the build system?
>> >>
>> >> Cheers,
>> >> Paul
>> >>
>> >> --
>> >>
>> >> Paul Eggleton
>> >> Intel Open Source Technology Centre
>> >> --
>> >> ___
>> >> yocto mailing list
>> >> yocto@yoctoproject.org
>> >> https://lists.yoctoproject.org/listinfo/yocto
>> >
>> >
>>
>>
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] autoreconf

[Rajasekaran, Monica]

Thanks Paul and Khem, that worked!

I also tried adding libcap-ng but it gives me the following error:

ERROR: Nothing RPROVIDES 'libcap-ng' (but 
/data/users/mrajase/l100_label_based_r100poc/repo/poky/meta-fss-product/recipes-core/images/fss-image-full.bb
 RDEPENDS on or otherwise requires it)

But, I see it present at 
http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-support/libcap-ng/.??

Thanks,
Monica 

-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] 
Sent: Sunday, June 19, 2016 5:14 PM
To: Rajasekaran, Monica 
Cc: Khem Raj ; yocto@yoctoproject.org
Subject: Re: [yocto] autoreconf

Hi Monica,

As shown in Khem's original example you need to add this through 
EXTRA_IMAGE_FEATURES, not IMAGE_INSTALL (since tools-sdk is a feature name, not 
a package name).

Cheers,
Paul

On Sun, 19 Jun 2016 20:23:53 Rajasekaran, Monica wrote:
> I added the following line to my recipe file,
> 
> IMAGE_INSTALL += "tools-sdk"
> 
> But there was the following error with the build:
> 
> ERROR: Nothing RPROVIDES 'tools-sdk' (but 
> /data/users/mrajase/l100_label_based_r100poc/repo/poky/meta-fss-produc
> t/rec ipes-core/images/fss-image-full.bb RDEPENDS on or otherwise 
> requires it)
> NOTE: Runtime target 'tools-sdk' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['tools-sdk']
> ERROR: Required build target 'fss-image-full' has no buildable providers.
> Missing or unbuildable dependency chain was: ['fss-image-full', 
> 'tools-sdk']
 
> Any idea on this?
> 
> Thanks,
> Monica
> 
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Wednesday, June 15, 2016 3:48 PM
> To: Rajasekaran, Monica 
> Cc: Paul Eggleton ; 
> yocto@yoctoproject.org
> Subject: Re: [yocto] autoreconf
> 
> That might work, however you might need more packages, so adding 
> tools-sdk will cover all of them in one go
 
> 
> > On Jun 15, 2016, at 1:47 PM, Rajasekaran, Monica 
> >  wrote:
 
> > Hi Raj,
> > 
> > Will adding a line in the image's recipe file like this work ?
> > 
> > IMAGE_INSTALL = ”autoconf”
> > 
> > I installed "git" and "resolvconf" in the same way. Just not sure 
> > about the package name this time.
 
> > Thanks,
> > Monica
> > 
> > 
> > -Original Message-
> > From: Khem Raj [mailto:raj.k...@gmail.com]
> > Sent: Wednesday, June 15, 2016 3:42 PM
> > To: Rajasekaran, Monica 
> > Cc: Paul Eggleton ; 
> > yocto@yoctoproject.org
> > Subject: Re: [yocto] autoreconf
> > 
> > You need to add autoconf to your target image, if you do not use 
> > Online package management
 
> > EXTRA_IMAGE_FEATURES_append = “ tools-sdk”
> > 
> > in local.conf might help
> > 
> > 
> > 
> >> On Jun 15, 2016, at 1:35 PM, Rajasekaran, Monica 
> >>  wrote:
 
> >> Hi Paul,
> >> 
> >> Thank you. This is in the target.
> >> 
> >> Thanks,
> >> Monica
> >> 
> >> -Original Message-
> >> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> >> Sent: Wednesday, June 15, 2016 3:25 PM
> >> To: Rajasekaran, Monica 
> >> Cc: yocto@yoctoproject.org
> >> Subject: Re: [yocto] autoreconf
> >> 
> >> Hi Monica,
> >> 
> >> On Wed, 15 Jun 2016 20:17:16 Rajasekaran, Monica wrote:
> >> 
> >>> What is the package to install autoreconf ? (Ubuntu equivalent:
> >>> apt-get install dh-autoreconf )
> >>> 
> >>> I am getting the following error for one of my applications:
> >>> "autoreconf: command not found"
> >> 
> >> 
> >> autoreconf is part of autoconf.
> >> 
> >> Where is this? On the target or within the build system?
> >> 
> >> Cheers,
> >> Paul
> >> 
> >> --
> >> 
> >> Paul Eggleton
> >> Intel Open Source Technology Centre
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> > 
> > 
> 
> 

-- 

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

Re: [linux-yocto] [PATCH 0/6] tsc_msr patches for linux-yocto-4.1 standard/intel/base

[Bruce Ashfield]

On 2016-06-20 04:25 AM, Yong, Jonathan wrote:

These patches are used to correct the TSC frequency calculation on Apollo
Lake but are not on mainline Linux yet. This should go into
standard/intel/base.


I've grabbed the changes. When my test builds are complete, I'll push
this along with the other staged changes.

Bruce



Len Brown (6):
   x86 tsc_msr: Identify Intel-specific code
   x86 tsc_msr: Remove debugging messages
   x86 tsc_msr: Update comments, expand definitions
   x86 tsc_msr: Correct Silvermont reference clock values
   x86 tsc_msr: Add Airmont reference clock values
   x86 tsc_msr: Remove irqoff around MSR-based TSC enumeration

  arch/x86/include/asm/tsc.h |  3 +--
  arch/x86/kernel/tsc.c  |  5 +---
  arch/x86/kernel/tsc_msr.c  | 65 +++---
  3 files changed, 23 insertions(+), 50 deletions(-)



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

Re: [linux-yocto] [PATCH 0/4] mmc: block: Pause re-tuning while switched to the RPMB partition

[Bruce Ashfield]

On 2016-06-17 01:58 AM, Lim Key Seong wrote:

Hi Bruce,

These patches are backport to resolve MMC re-tune issue on RPMB partition.
Three patches upstream to mainline by Adrian Hunter, are required to resolve 
RPMB re-tune
issue completely.
The patch upstream to mainline by Jon Hunter is the dependency patch, so that 
the RPMB
re-tune patches can be applied cleanly.
These 4 patches are targeted for linux-yocto-4.1, standard/base branch.



I've staged these changes.

Bruce


Thanks

Best regards
KS LIM

Adrian Hunter (3):
   mmc: core: Add a facility to "pause" re-tuning
   mmc: block: Always switch back to main area after RPMB access
   mmc: block: Pause re-tuning while switched to the RPMB partition

Jon Hunter (1):
   mmc: block: Add new ioctl to send multi commands

  drivers/mmc/card/block.c   | 225 +++--
  drivers/mmc/core/host.c|  24 +
  include/linux/mmc/host.h   |   4 +
  include/uapi/linux/mmc/ioctl.h |  19 +++-
  4 files changed, 215 insertions(+), 57 deletions(-)

--
1.9.1



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

Re: [linux-yocto] [PULL REQUEST] Support async probe for linux-yocto-4.1

[Bruce Ashfield]

On 2016-06-17 12:00 AM, Yong, Jonathan wrote:

git URL: https://github.com/jyong2/yocto-backports.git
branch: for-linux-yocto-4.1-core

This series allows drivers to be loaded asynchronously.

All patches from Linus's tree, for linux-yocto-4.1 standard/base.
for-linux-yocto-4.1-core is based on the latest standard/base as of
writing.


This series has now been staged.

Bruce




Dmitry Torokhov (3):
  driver-core: add asynchronous probing support for drivers
  driver-core: make __device_attach() static
  driver-core: fix build for !CONFIG_MODULES

Luis R. Rodriguez (3):
  driver-core: add driver module asynchronous probe support
  driver-core: enable drivers to opt-out of async probe
  module: add extra argument for parse_params() callback

Mika Westerberg (1):
  ACPI / PM: Attach ACPI power domain only once

Rafael J. Wysocki (1):
  Driver core: wakeup the parent device before trying probe

Shailendra Verma (1):
  base:dd - Fix for typo in comment to function
driver_deferred_probe_trigger().

 Documentation/kernel-parameters.txt |   3 +
 arch/powerpc/mm/hugetlbpage.c   |   4 +-
 drivers/acpi/device_pm.c|   8 ++
 drivers/acpi/internal.h |   2 +
 drivers/acpi/scan.c |  46 +
 drivers/base/base.h |   1 +
 drivers/base/bus.c  |  31 --
 drivers/base/dd.c   | 183

 include/linux/device.h  |  31 ++
 include/linux/module.h  |  13 +++
 include/linux/moduleparam.h |   3 +-
 init/main.c |  25 +++--
 kernel/module.c |  18 +++-
 kernel/params.c |  11 ++-
 lib/dynamic_debug.c |   4 +-
 15 files changed, 316 insertions(+), 67 deletions(-)




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

Re: [yocto] [PATCH][yocto-autobuilder] autobuilder/Autobuilder.p: Add missing import of buildbot.util.

[Aníbal Limón]

On 06/20/2016 02:42 AM, Beth 'pidge' Flanagan wrote:
> On Fri, 2016-06-17 at 11:05 -0500, Aníbal Limón wrote:
>> When try to start Autobuilder fails with the next exception,
>>
>> 2016-06-07 17:06:45-0500 [-] LOADING CONFIG FILE
>> 2016-06-07 17:06:45-0500 [-] error while parsing config file:
>>
>> Traceback (most recent call last):
>>   File
>> "/home/alimon/repos/yocto-autobuilder/lib/python2.7/site-
>> packages/Twisted-12.2.0-py2.7-linux-
>> x86_64.egg/twisted/internet/defer.py",
>> line 551, in _runCallbacks
>> ..
>> ..
>> ..
>>   File
>> "/home/alimon/repos/yocto-autobuilder/lib/python2.7/site-
>> packages/autobuilder/Autobuilder.py",
>> line 54, in createBuildsets
>> util.naturalSort(buildersSorted)
>> exceptions.NameError: global name 'util' is not defined
>>
>> Signed-off-by: Aníbal Limón 
> 
> Pulled into master.
> 
> I'm going to have a few patches today to pull in. One from Bill Randle,
> and if you have the rebase done for our bitbakeshell branch, that as
> well, so we might want to consider getting production updated.
> 
> Have we run your BitbakeShell branch of the devel cluster (or any
> cluster not on a single machine, which is generally where we find
> issues) yet?

I ran into my machine and it works ok, but for BitbakeShell related
changes we need to wait the integration of other related changes into
Error report web because with the new changes the AB starts to send a
new field to the ERW and it possible could cause problems.

alimon

> 
> -b
> 
> 
>> ---
>>  lib/python2.7/site-packages/autobuilder/Autobuilder.py | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/lib/python2.7/site-packages/autobuilder/Autobuilder.py
>> b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
>> index 6c3e578..23f0a74 100644
>> --- a/lib/python2.7/site-packages/autobuilder/Autobuilder.py
>> +++ b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
>> @@ -19,6 +19,7 @@ from buildbot.schedulers.basic  import
>> SingleBranchScheduler
>>  from buildbot.changes import filter
>>  from buildbot.changes.pb import PBChangeSource
>>  from buildbot.changes.gitpoller import *
>> +from buildbot import util
>>  from lib.ABTools import capitalize
>>  import ast
>>  import BuildSet



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder][PATCH] nightly-world-lsb.conf: skip Publish step so artifacts don't overwrite nightly-world ones

[Bill Randle]

Signed-off-by: Bill Randle 
---
 buildset-config.controller/nightly-world-lsb.conf | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/buildset-config.controller/nightly-world-lsb.conf 
b/buildset-config.controller/nightly-world-lsb.conf
index 4c9994c..f755920 100644
--- a/buildset-config.controller/nightly-world-lsb.conf
+++ b/buildset-config.controller/nightly-world-lsb.conf
@@ -21,6 +21,7 @@ steps: [{'SetDest':{}},
 'distro': 'poky-lsb'}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'BuildImages': {'images': 'world'}},
-{'SendErrorReport': {}},
-{'PublishArtifacts': {'artifacts': ['ipk', 'rpm', 'deb']}}]
+{'SendErrorReport': {}}]
+# skip Publish step so artifacts don't overwrite nightly-world ones
+#{'PublishArtifacts': {'artifacts': ['ipk', 'rpm', 'deb']}}]
 
-- 
2.5.5

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

[yocto] Multiple images/filesystems

[Martin Townsend]

Hi,

I currently have a read only filesystem image. What I would like to do
is have part of the filesystem read/write which is basically a
particular user account, say /home/scratch
To complicate things we have two flash devices,
1) eMMC with ext3 filesystem
2) NAND with ubifs filesystem

So I would have 2 partitions for eMMC one for /home/scratch and the
other for the rest of the rootfs.
For NAND I think I need 2 UBI volumes one contains a UBIFS with
/home/scratch the other with the remaining rootfs.
I think I have to create my own image_type.bbclass file to create the
ubifs and ext3 filesystems but I don't see how I separate out the
/home/scratch from the image's rootfs.  Anyone know what the best way
to do this is.

Many Thanks,
Martin.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] prelink support

[Kyle Russell]

Thanks, Mark and Richard.  Great update!  I'll try out the staging branch
and report back with results.

On Mon, Jun 20, 2016 at 9:15 AM, Mark Hatle 
wrote:

> On 6/20/16 7:24 AM, Kyle Russell wrote:
> > It looks like the image-prelink support is still disabled in master
> because of
> > an issue with IFUNC symbol relocation.
> >
> >
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta-poky/conf/local.conf.sample?id=8debfea81e69d038bd2d56314b272cb74f5582ed
> >
> > Is there still a problem, or is it safe to reenable image-prelink?  I
> see a "Fix
> > ARM IFUNC support" in the prelink-cross repo, but that appears to have
> been
> > committed several months before image-prelink was disabled.  We'd like
> to enable
> > image-prelink on a build off jethro.
> >
> > Any help or links to a recent discussion thread would be helpful.
> Thanks!
> >
> >
>
> The ARM fix is for a different IFUNC problem.
>
> Disabling the prelinker was caused by a serious of problems that started
> with a
> fork failure traced back to shared library processing orders.
>
> (For comments below, I'm referring to the repository:
> http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/)
>
> The initial problem, IFUNC processing, showed that processing order of the
> shared libraries could lead to a case where the wrong IFUNC was used.  We
> believe this particular issues was fixed in the staging tree.
>
> In the tree you'll see a cross_prelink_staging branch.  In that branch the
> fix
> is commit ID: "8f55afd84b3580b1f1d6af904e8c2a39221055b7"  This fixes the
> 'fork'
> issue by ensuring the proper sort order for shared library processing.
> (This
> was finally fixed in March.)
>
> However with that we determined there was at least one more issue related
> to
> section ordering.  The prelink test suite was failing due to various
> integrity
> checks showing that once we prelinked something, we could not reverse the
> process.  It has taken us months to identify the cause of the problem and
> the
> solution.  (Cause BTW was a change in binutils-2.22 that no longer ensured
> that
> the section order was sorted by offset order... a small amount of the
> prelink
> processing needed to be changed to deal with that behavior.  It's taken far
> longer to fix then we had ever expected.)
>
> See commit (33be255d62af533189f1f7bc66c06602b703980a) in the
> cross_prelink_staging branch.
>
> With this commit, I think the two major issues have been resolved.  I've
> got a
> small set of additional patches I need to put into place -- and then I
> have to
> finish going through the regression suite to verify everything is working
> properly.  (Seems like every time I get to this step, something else comes
> up
> and I'm not getting it done...)
>
> So if you've read this far, the point in all of this is that I THINK that
> the
> cross_prelink_staging branch and current top commit
> "33be255d62af533189f1f7bc66c06602b703980a" are working.  However, I've not
> completed testing so I'm not sure of that yet.
>
> If you can help with testing, you should modify your prelink recipe to use
> the
> 'cross_prelink_staging' branch, and the 33be255 commit.  Verify that this
> is
> working for your use cases.  If you are using glib or graphical
> environments pay
> particular attention to process startup messages that indicate failures.
>
> If this IS working for you, I'd like a reply back with the architecture and
> processor you are using so I can add that to my matrix.  (I'm traveling
> for the
> next couple of days, and then should be back in the officer where I hope to
> finish my regression testing, apply the last couple of patches from Gentoo
> developers, regression test again and prepare a release version.)
>
> Any help is appreciated, thanks for understanding why this is taking so
> long.
>
> --Mark
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] prelink support

[Mark Hatle]

On 6/20/16 7:24 AM, Kyle Russell wrote:
> It looks like the image-prelink support is still disabled in master because of
> an issue with IFUNC symbol relocation.
> 
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta-poky/conf/local.conf.sample?id=8debfea81e69d038bd2d56314b272cb74f5582ed
> 
> Is there still a problem, or is it safe to reenable image-prelink?  I see a 
> "Fix
> ARM IFUNC support" in the prelink-cross repo, but that appears to have been
> committed several months before image-prelink was disabled.  We'd like to 
> enable
> image-prelink on a build off jethro.
> 
> Any help or links to a recent discussion thread would be helpful.  Thanks!
> 
> 

The ARM fix is for a different IFUNC problem.

Disabling the prelinker was caused by a serious of problems that started with a
fork failure traced back to shared library processing orders.

(For comments below, I'm referring to the repository:
http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/)

The initial problem, IFUNC processing, showed that processing order of the
shared libraries could lead to a case where the wrong IFUNC was used.  We
believe this particular issues was fixed in the staging tree.

In the tree you'll see a cross_prelink_staging branch.  In that branch the fix
is commit ID: "8f55afd84b3580b1f1d6af904e8c2a39221055b7"  This fixes the 'fork'
issue by ensuring the proper sort order for shared library processing.  (This
was finally fixed in March.)

However with that we determined there was at least one more issue related to
section ordering.  The prelink test suite was failing due to various integrity
checks showing that once we prelinked something, we could not reverse the
process.  It has taken us months to identify the cause of the problem and the
solution.  (Cause BTW was a change in binutils-2.22 that no longer ensured that
the section order was sorted by offset order... a small amount of the prelink
processing needed to be changed to deal with that behavior.  It's taken far
longer to fix then we had ever expected.)

See commit (33be255d62af533189f1f7bc66c06602b703980a) in the
cross_prelink_staging branch.

With this commit, I think the two major issues have been resolved.  I've got a
small set of additional patches I need to put into place -- and then I have to
finish going through the regression suite to verify everything is working
properly.  (Seems like every time I get to this step, something else comes up
and I'm not getting it done...)

So if you've read this far, the point in all of this is that I THINK that the
cross_prelink_staging branch and current top commit
"33be255d62af533189f1f7bc66c06602b703980a" are working.  However, I've not
completed testing so I'm not sure of that yet.

If you can help with testing, you should modify your prelink recipe to use the
'cross_prelink_staging' branch, and the 33be255 commit.  Verify that this is
working for your use cases.  If you are using glib or graphical environments pay
particular attention to process startup messages that indicate failures.

If this IS working for you, I'd like a reply back with the architecture and
processor you are using so I can add that to my matrix.  (I'm traveling for the
next couple of days, and then should be back in the officer where I hope to
finish my regression testing, apply the last couple of patches from Gentoo
developers, regression test again and prepare a release version.)

Any help is appreciated, thanks for understanding why this is taking so long.

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

Re: [yocto] prelink support

[Richard Purdie]

On Mon, 2016-06-20 at 08:24 -0400, Kyle Russell wrote:
> It looks like the image-prelink support is still disabled in master
> because of an issue with IFUNC symbol relocation.
> 
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta-poky/conf
> /local.conf.sample?id=8debfea81e69d038bd2d56314b272cb74f5582ed
> 
> Is there still a problem, or is it safe to reenable image-prelink?  I
> see a "Fix ARM IFUNC support" in the prelink-cross repo, but that
> appears to have been committed several months before image-prelink
> was disabled.  We'd like to enable image-prelink on a build off
> jethro.
> 
> Any help or links to a recent discussion thread would be helpful. 
> Thanks!

Basically, its still broken. I actually ran into a bug the other day
caused by the issue where I had prelink enabled locally.

I know Mark is working on some fixes but its an onion problem, you fix
one thing, then find other issues. Mark can give the full story but
right now, its not able to be re-enabled.

Cheers,

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

[yocto] prelink support

[Kyle Russell]

It looks like the image-prelink support is still disabled in master because
of an issue with IFUNC symbol relocation.

https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta-poky/conf/local.conf.sample?id=8debfea81e69d038bd2d56314b272cb74f5582ed

Is there still a problem, or is it safe to reenable image-prelink?  I see a
"Fix ARM IFUNC support" in the prelink-cross repo, but that appears to have
been committed several months before image-prelink was disabled.  We'd like
to enable image-prelink on a build off jethro.

Any help or links to a recent discussion thread would be helpful.  Thanks!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH 3/6] x86 tsc_msr: Update comments, expand definitions

[Yong, Jonathan]

From: Len Brown 

Syntax only, no functional change.

Signed-off-by: Len Brown 
Signed-off-by: Yong, Jonathan 
---
 arch/x86/kernel/tsc_msr.c | 36 ++--
 1 file changed, 10 insertions(+), 26 deletions(-)

diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index f7ba44b..4110f72 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -1,14 +1,5 @@
 /*
- * tsc_msr.c - MSR based TSC calibration on Intel Atom SoC platforms.
- *
- * TSC in Intel Atom SoC runs at a constant rate which can be figured
- * by this formula:
- *  * 
- * See Intel 64 and IA-32 System Programming Guid section 16.12 and 30.11.5
- * for details.
- * Especially some Intel Atom SoCs don't have PIT(i8254) or HPET, so MSR
- * based calibration is the only option.
- *
+ * tsc_msr.c - TSC frequency enumeration via MSR
  *
  * Copyright (C) 2013 Intel Corporation
  * Author: Bin Gao 
@@ -22,17 +13,10 @@
 #include 
 #include 
 
-/* CPU reference clock frequency: in KHz */
-#define FREQ_8383200
-#define FREQ_100   99840
-#define FREQ_133   133200
-#define FREQ_166   166400
-
 #define MAX_NUM_FREQS  8
 
 /*
- * According to Intel 64 and IA-32 System Programming Guide,
- * if MSR_PERF_STAT[31] is set, the maximum resolved bus ratio can be
+ * If MSR_PERF_STAT[31] is set, the maximum resolved bus ratio can be
  * read in MSR_PLATFORM_ID[12:8], otherwise in MSR_PERF_STAT[44:40].
  * Unfortunately some Intel Atom SoCs aren't quite compliant to this,
  * so we need manually differentiate SoC families. This is what the
@@ -47,15 +31,15 @@ struct freq_desc {
 
 static struct freq_desc freq_desc_tables[] = {
/* PNW */
-   { 6, 0x27, 0, { 0, 0, 0, 0, 0, FREQ_100, 0, FREQ_83 } },
+   { 6, 0x27, 0, { 0, 0, 0, 0, 0, 99840, 0, 83200 } },
/* CLV+ */
-   { 6, 0x35, 0, { 0, FREQ_133, 0, 0, 0, FREQ_100, 0, FREQ_83 } },
-   /* TNG */
-   { 6, 0x4a, 1, { 0, FREQ_100, FREQ_133, 0, 0, 0, 0, 0 } },
-   /* VLV2 */
-   { 6, 0x37, 1, { FREQ_83, FREQ_100, FREQ_133, FREQ_166, 0, 0, 0, 0 } },
-   /* ANN */
-   { 6, 0x5a, 1, { FREQ_83, FREQ_100, FREQ_133, FREQ_100, 0, 0, 0, 0 } },
+   { 6, 0x35, 0, { 0, 133200, 0, 0, 0, 99840, 0, 83200 } },
+   /* TNG - Intel Atom processor Z3400 series */
+   { 6, 0x4a, 1, { 0, 99840, 133200, 0, 0, 0, 0, 0 } },
+   /* VLV2 - Intel Atom processor E3000, Z3600, Z3700 series */
+   { 6, 0x37, 1, { 83200, 99840, 133200, 166400, 0, 0, 0, 0 } },
+   /* ANN - Intel Atom processor Z3500 series */
+   { 6, 0x5a, 1, { 83200, 99840, 133200, 99840, 0, 0, 0, 0 } },
 };
 
 static int match_cpu(u8 family, u8 model)
-- 
2.7.3

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

[linux-yocto] [PATCH 6/6] x86 tsc_msr: Remove irqoff around MSR-based TSC enumeration

[Yong, Jonathan]

From: Len Brown 

Remove the irqoff/irqon around MSR-based TSC enumeration,
as it is not necessary.

Also rename: try_msr_calibrate_tsc() to cpu_khz_from_msr(),
as that better describes what the routine does.

Signed-off-by: Len Brown 
Signed-off-by: Yong, Jonathan 
---
 arch/x86/include/asm/tsc.h | 3 +--
 arch/x86/kernel/tsc.c  | 5 +
 arch/x86/kernel/tsc_msr.c  | 2 +-
 3 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/tsc.h b/arch/x86/include/asm/tsc.h
index d0f9013..5c61c244 100644
--- a/arch/x86/include/asm/tsc.h
+++ b/arch/x86/include/asm/tsc.h
@@ -67,7 +67,6 @@ extern int notsc_setup(char *);
 extern void tsc_save_sched_clock_state(void);
 extern void tsc_restore_sched_clock_state(void);
 
-/* MSR based TSC calibration for Intel Atom SoC platforms */
-unsigned long try_msr_calibrate_tsc(void);
+unsigned long cpu_khz_from_msr(void);
 
 #endif /* _ASM_X86_TSC_H */
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index fc39d74..7b07f7e 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -656,10 +656,7 @@ unsigned long native_calibrate_tsc(void)
unsigned long flags, latch, ms, fast_calibrate;
int hpet = is_hpet_enabled(), i, loopmin;
 
-   /* Calibrate TSC using MSR for Intel Atom SoCs */
-   local_irq_save(flags);
-   fast_calibrate = try_msr_calibrate_tsc();
-   local_irq_restore(flags);
+   fast_calibrate = cpu_khz_from_msr();
if (fast_calibrate)
return fast_calibrate;
 
diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index 65b3d8cb..0fe720d 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -68,7 +68,7 @@ static int match_cpu(u8 family, u8 model)
  * Set global "lapic_timer_frequency" to bus_clock_cycles/jiffy
  * Return processor base frequency in KHz, or 0 on failure.
  */
-unsigned long try_msr_calibrate_tsc(void)
+unsigned long cpu_khz_from_msr(void)
 {
u32 lo, hi, ratio, freq_id, freq;
unsigned long res;
-- 
2.7.3

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

[linux-yocto] [PATCH 4/6] x86 tsc_msr: Correct Silvermont reference clock values

[Yong, Jonathan]

From: Len Brown 

Atom processors use a 19.2 MHz crystal oscillator.

Early processors generate 100 MHz via 19.2 MHz * 26 / 5 = 99.84 MHz.

Later preocessor generate 100 MHz via 19.2 MHz * 125 / 24 = 100 MHz.

Update the Silvermont-based tables accordingly,
matching the Software Developers Manual.

Also, correct a 166 MHz entry that should have been 116 MHz,
and add a missing 80 MHz entry.

Reported-by: Stephane Gasparini 
Signed-off-by: Len Brown 
Signed-off-by: Yong, Jonathan 
---
 arch/x86/kernel/tsc_msr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index 4110f72..20487e2 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -35,11 +35,11 @@ static struct freq_desc freq_desc_tables[] = {
/* CLV+ */
{ 6, 0x35, 0, { 0, 133200, 0, 0, 0, 99840, 0, 83200 } },
/* TNG - Intel Atom processor Z3400 series */
-   { 6, 0x4a, 1, { 0, 99840, 133200, 0, 0, 0, 0, 0 } },
+   { 6, 0x4a, 1, { 0, 10, 133300, 0, 0, 0, 0, 0 } },
/* VLV2 - Intel Atom processor E3000, Z3600, Z3700 series */
-   { 6, 0x37, 1, { 83200, 99840, 133200, 166400, 0, 0, 0, 0 } },
+   { 6, 0x37, 1, { 83300, 10, 133300, 116700, 8, 0, 0, 0 } },
/* ANN - Intel Atom processor Z3500 series */
-   { 6, 0x5a, 1, { 83200, 99840, 133200, 99840, 0, 0, 0, 0 } },
+   { 6, 0x5a, 1, { 83300, 10, 133300, 10, 0, 0, 0, 0 } },
 };
 
 static int match_cpu(u8 family, u8 model)
-- 
2.7.3

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

[linux-yocto] [PATCH 2/6] x86 tsc_msr: Remove debugging messages

[Yong, Jonathan]

From: Len Brown 

Debugging messages are not necessary after all of the
possible hardware failures that never occur.
Instead, this code can simply return 0.

This code also doesn't need to print in the success case.
tsc_init() already prints the TSC frequency,
and apic=debug is available if anybody really is
interested in printing the LAPIC frequency.

Signed-off-by: Len Brown 
Signed-off-by: Yong, Jonathan 
---
 arch/x86/kernel/tsc_msr.c | 19 +++
 1 file changed, 3 insertions(+), 16 deletions(-)

diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index 4ec5e56..f7ba44b 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -76,9 +76,10 @@ static int match_cpu(u8 family, u8 model)
(freq_desc_tables[cpu_index].freqs[freq_id])
 
 /*
- * Do MSR calibration only for known/supported CPUs.
+ * MSR-based CPU/TSC frequency discovery for certain CPUs.
  *
- * Returns the calibration value or 0 if MSR calibration failed.
+ * Set global "lapic_timer_frequency" to bus_clock_cycles/jiffy
+ * Return processor base frequency in KHz, or 0 on failure.
  */
 unsigned long try_msr_calibrate_tsc(void)
 {
@@ -100,31 +101,17 @@ unsigned long try_msr_calibrate_tsc(void)
rdmsr(MSR_IA32_PERF_STATUS, lo, hi);
ratio = (hi >> 8) & 0x1f;
}
-   pr_info("Maximum core-clock to bus-clock ratio: 0x%x\n", ratio);
-
-   if (!ratio)
-   goto fail;
 
/* Get FSB FREQ ID */
rdmsr(MSR_FSB_FREQ, lo, hi);
freq_id = lo & 0x7;
freq = id_to_freq(cpu_index, freq_id);
-   pr_info("Resolved frequency ID: %u, frequency: %u KHz\n",
-   freq_id, freq);
-   if (!freq)
-   goto fail;
 
/* TSC frequency = maximum resolved freq * maximum resolved bus ratio */
res = freq * ratio;
-   pr_info("TSC runs at %lu KHz\n", res);
 
 #ifdef CONFIG_X86_LOCAL_APIC
lapic_timer_frequency = (freq * 1000) / HZ;
-   pr_info("lapic_timer_frequency = %d\n", lapic_timer_frequency);
 #endif
return res;
-
-fail:
-   pr_warn("Fast TSC calibration using MSR failed\n");
-   return 0;
 }
-- 
2.7.3

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

[linux-yocto] [PATCH 0/6] tsc_msr patches for linux-yocto-4.1 standard/intel/base

[Yong, Jonathan]

These patches are used to correct the TSC frequency calculation on Apollo
Lake but are not on mainline Linux yet. This should go into
standard/intel/base.

Len Brown (6):
  x86 tsc_msr: Identify Intel-specific code
  x86 tsc_msr: Remove debugging messages
  x86 tsc_msr: Update comments, expand definitions
  x86 tsc_msr: Correct Silvermont reference clock values
  x86 tsc_msr: Add Airmont reference clock values
  x86 tsc_msr: Remove irqoff around MSR-based TSC enumeration

 arch/x86/include/asm/tsc.h |  3 +--
 arch/x86/kernel/tsc.c  |  5 +---
 arch/x86/kernel/tsc_msr.c  | 65 +++---
 3 files changed, 23 insertions(+), 50 deletions(-)

-- 
2.7.3

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

Re: [yocto] [PATCH][yocto-autobuilder] autobuilder/Autobuilder.p: Add missing import of buildbot.util.

[Beth 'pidge' Flanagan]

On Fri, 2016-06-17 at 11:05 -0500, Aníbal Limón wrote:
> When try to start Autobuilder fails with the next exception,
> 
> 2016-06-07 17:06:45-0500 [-] LOADING CONFIG FILE
> 2016-06-07 17:06:45-0500 [-] error while parsing config file:
> 
> Traceback (most recent call last):
>   File
> "/home/alimon/repos/yocto-autobuilder/lib/python2.7/site-
> packages/Twisted-12.2.0-py2.7-linux-
> x86_64.egg/twisted/internet/defer.py",
> line 551, in _runCallbacks
> ..
> ..
> ..
>   File
> "/home/alimon/repos/yocto-autobuilder/lib/python2.7/site-
> packages/autobuilder/Autobuilder.py",
> line 54, in createBuildsets
> util.naturalSort(buildersSorted)
> exceptions.NameError: global name 'util' is not defined
> 
> Signed-off-by: Aníbal Limón 

Pulled into master.

I'm going to have a few patches today to pull in. One from Bill Randle,
and if you have the rebase done for our bitbakeshell branch, that as
well, so we might want to consider getting production updated.

Have we run your BitbakeShell branch of the devel cluster (or any
cluster not on a single machine, which is generally where we find
issues) yet?

-b


> ---
>  lib/python2.7/site-packages/autobuilder/Autobuilder.py | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/python2.7/site-packages/autobuilder/Autobuilder.py
> b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
> index 6c3e578..23f0a74 100644
> --- a/lib/python2.7/site-packages/autobuilder/Autobuilder.py
> +++ b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
> @@ -19,6 +19,7 @@ from buildbot.schedulers.basic  import
> SingleBranchScheduler
>  from buildbot.changes import filter
>  from buildbot.changes.pb import PBChangeSource
>  from buildbot.changes.gitpoller import *
> +from buildbot import util
>  from lib.ABTools import capitalize
>  import ast
>  import BuildSet
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto