When I read the runnable load avg code, I found the task's
avg.load_avg_contrib mainly updated in enqueue/dequeue, and the 'curr'
task in sched_tick.
So, if a sleep long time task is waked/added and kept on a cpu, but the
task is never be the 'curr' in sched_tick. Then the task's load contrib
will never be updated and keep small.
what I missed? or Is it really?
--
Thanks
Alex
This patchset adds cpufreq callbacks to dpm_{suspend|resume}_noirq() for
handling suspend/resume of cpufreq governors. This is required for early suspend
and late resume of governors.
There are multiple problems that are fixed by this patch:
- Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His board
wasn't working well with suspend/resume as calls for removing non-boot CPUs
was turning out into a call to drivers ->target() which then tries to play
with regulators. But regulators and their I2C bus were already suspended and
this resulted in a failure. This is why we need a PM notifier here.
- Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
tunables configuration for clusters/sockets with non-boot CPUs was getting
lost after suspend/resume, as we were notifying governors with
CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
deallocating memory for tunables.
This was earlier sent here:
https://lkml.org/lkml/2013/11/15/107
V1->V2:
- Used direct callbacks from dpm_{suspend|resume}_noirq() for
suspending/resuming govenors instead of doing that with help of PM notifiers.
- Patch 2/2: Switching to the desirable frequency before suspending the
governors.
Viresh Kumar (2):
cpufreq: suspend governors on system suspend/hibernate
cpufreq: Change freq before suspending governors
drivers/base/power/main.c | 3 ++
drivers/cpufreq/cpufreq.c | 79 +++++++++++++++++++++++++++++++++++++++++++++++
include/linux/cpufreq.h | 5 +++
3 files changed, 87 insertions(+)
--
1.7.12.rc2.18.g61b472e
From: Victor Kamensky <victor.kamensky(a)linaro.org>
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky <victor.kamensky(a)linaro.org>
Signed-off-by: Taras Kondratiuk <taras.kondratiuk(a)linaro.org>
---
Posting this as a saparate patch out of RFC series.
RFC: http://patchwork.ozlabs.org/patch/291726/
Only minor comment change is done since RFC patch.
Based on v3.13-rc1
drivers/i2c/busses/i2c-omap.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d76228d..90dcc2e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -266,13 +266,13 @@ static const u8 reg_map_ip_v2[] = {
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
int reg, u16 val)
{
- __raw_writew(val, i2c_dev->base +
+ writew_relaxed(val, i2c_dev->base +
(i2c_dev->regs[reg] << i2c_dev->reg_shift));
}
static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg)
{
- return __raw_readw(i2c_dev->base +
+ return readw_relaxed(i2c_dev->base +
(i2c_dev->regs[reg] << i2c_dev->reg_shift));
}
@@ -1162,9 +1162,9 @@ omap_i2c_probe(struct platform_device *pdev)
* Read the Rev hi bit-[15:14] ie scheme this is 1 indicates ver2.
* On omap1/3/2 Offset 4 is IE Reg the bit [15:14] is 0 at reset.
* Also since the omap_i2c_read_reg uses reg_map_ip_* a
- * raw_readw is done.
+ * readw_relaxed is done.
*/
- rev = __raw_readw(dev->base + 0x04);
+ rev = readw_relaxed(dev->base + 0x04);
dev->scheme = OMAP_I2C_SCHEME(rev);
switch (dev->scheme) {
--
1.7.9.5
This patchset adds cpufreq callbacks to dpm_{suspend|resume}() for handling
suspend/resume of cpufreq governors and core. This is required for early suspend
and late resume of governors and cpufreq core.
There are multiple problems that are fixed by this patch:
- Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His board
wasn't working well with suspend/resume as calls for removing non-boot CPUs
was turning out into a call to drivers ->target() which then tries to play
with regulators. But regulators and their I2C bus were already suspended and
this resulted in a failure. Many platforms have such problems, samsung, tegra,
etc.. They solved it with driver specific PM notifiers where they used to
disable their driver's ->target() routine. Most of these are updated in this
patchset to use new infrastructure.
- Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
tunables configuration for clusters/sockets with non-boot CPUs was getting
lost after suspend/resume, as we were notifying governors with
CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
deallocating memory for tunables. This is also fixed with this patch as don't
allow any operation on Governors during suspend/resume now.
So to solve these issues we introduce early suspend and late resume callbacks
which would remove need of cpufreq drivers to implement PM notifiers to disable
transition after suspend and before resume.
@Nishanth: Can you please test V2 as well and confirm that suspend_noirq()
doesn't work for you. I am sure it will not, but would be better if you confirm
that.
Viresh Kumar (6):
cpufreq: suspend governors on system suspend/hibernate
cpufreq: call driver's suspend/resume for each policy
cpufreq: Implement cpufreq_generic_suspend()
cpufreq: exynos: Use cpufreq_generic_suspend()
cpufreq: s5pv210: Use cpufreq_generic_suspend()
cpufreq: Tegra: Use cpufreq_generic_suspend()
drivers/base/power/main.c | 5 ++
drivers/cpufreq/cpufreq.c | 133 +++++++++++++++++++++-----------------
drivers/cpufreq/exynos-cpufreq.c | 97 ++-------------------------
drivers/cpufreq/s5pv210-cpufreq.c | 49 +-------------
drivers/cpufreq/tegra-cpufreq.c | 54 ++--------------
include/linux/cpufreq.h | 6 ++
6 files changed, 99 insertions(+), 245 deletions(-)
--
1.7.12.rc2.18.g61b472e
Introduction of ARM_PATCH_PHYS_VIRT as default would make the platform to
support dynamic reallocation of memory and also allows phy-to-virt and
virt-to-phy translations functions at boot time and module loading time.
AUTO_ZRELADDR would introduce address calculation of decompressed kernel
from the location of zImage in RAM.
EXYNOS platforms mostly uses Onenand which was developed as replacement
of NOR devices, it is developed such that it plugs directly into existing
NOR interface. OneNAND supports NOR interfaces also for backward compatibility
with NOR supporting system.
Below explaination by Russel in LKML clears the concept of AUTO_ZRELADDR and
ARM_PATCH_PHYS_VIRT
AUTO_ZRELADDR=n ZBOOT_ROM=n => fixed address for decompressed kernel
image to be decompressed to from zreladdr make variable,
decompressor can be loaded to any RAM address.
AUTO_ZRELADDR=y ZBOOT_ROM=n => address for decompressed kernel calculated
from location of zImage in RAM, decompressor must be loaded to
the correct place in RAM and must always copy itself out of
the way prior to decompressing.
AUTO_ZRELADDR=n ZBOOT_ROM=y => fixed address for decompressed kernel
image to be decompressed to from zreladdr make variable,
decompressor can be loaded to any RAM address which doesn't
overlap its BSS segment, or decompressor programmed into
read-only memory at the address to which it was compiled.
AUTO_ZRELADDR=y ZBOOT_ROM=y => invalid (think about it - this results
in a zImage which is built to be run from read-only memory,
and try to write the decompressed image into that read-only
memory.)
This has nothing to do with XIP or not - XIP is a completely separate story,
and if you're building an XIP kernel you're not using the decompressor (so
AUTO_ZRELADDR and ZBOOT_ROM don't even feature.) Neither does the dynamic
code patching stuff like ARM_PATCH_PHYS_VIRT.
ARM_PATCH_PHYS_VIRT has no bearing on AUTO_ZRELADDR or ZBOOT_ROM; that is
a property of the decompressed kernel image itself, and while your
decompressor may restrict where it can decompress the kernel image to,
the decompressed image itself remains free of those dependencies (and
eg, can be turned into a uImage with the appropriate load address
for other platforms.)
As I've said in the past, what I'd _like_ to see is that ARM_PATCH_PHYS_VIRT
be enabled for everything irrespective of any other configuration, and
we're just left with AUTO_ZRELADDR / ZBOOT_ROM to worry about. The
overhead from the P:V patching is soo small that it's not really worth
even having the option in the general case - the only time when P:V
patching doesn't work is with non-linear translations found on some
sparsemem platforms.
But... one thing to note is that it _is_ common to load the decompressor
at a _different_ address to that where the kernel ultimately ends up
residing to avoid the additional copy in the decompressor. My experience
shows that this is quite common on the platforms I had supplied. This
means that if we default to AUTO_ZRELADDR for !ZBOOT_ROM, we end up
having to have developers change their uboot setups to avoid unexpected
results.
panchaxari (1):
ARM:EXYNOS:Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default
arch/arm/Kconfig | 2 ++
1 file changed, 2 insertions(+)
--
1.7.10.4
Add CFLAGS and LDFLAGS for each feature to be checked. This allows
to pass flags and parameters to the feature checks compilation.
Use the per-feature check flags for the unwinding feature in order
to correctly compile the libunwind and libunwind-debug-frame feature
checks.
This change set simplifies the flags passing mechanism between the
Makefiles in config/Makefile and config/feature-checks; this
could be farther optimized by moving the compilation flags to the
per-feature check flags for all features to be checked.
Tested on ARMv7 and ARMv8 with 'make DEBUG=1 LIBUNWIND_DIR=/usr/local
-C tools/perf'
Jean Pihet (2):
perf: add per-feature check flags
perf: unwinding: use the per-feature check flags
tools/perf/config/Makefile | 38 +++++++++++++++++--------------
tools/perf/config/feature-checks/Makefile | 6 ++---
2 files changed, 24 insertions(+), 20 deletions(-)
--
1.7.11.7
On 25 November 2013 19:41, Viresh Kumar <viresh.kumar(a)linaro.org> wrote:
> Currently we have implemented PM notifiers to disable/enable ->target() routines
> functionality during suspend/resume.
>
> Now we have support present in cpufreq core, lets use it.
>
> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
> ---
> drivers/cpufreq/exynos-cpufreq.c | 97 +++-------------------------------------
> 1 file changed, 6 insertions(+), 91 deletions(-)
Jonghwan Choi reported an issue with this patch. He asked me
to look at: 6e45eb
And so following diff is updated for this patch in my repo.. Will get
that fixed in V4:
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 4b6e6a6..3f216da 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -22,8 +22,8 @@
#include "exynos-cpufreq.h"
static struct exynos_dvfs_info *exynos_info;
-
static struct regulator *arm_regulator;
+static unsigned int locking_frequency;
static int exynos_cpufreq_get_index(unsigned int freq)
{
@@ -134,7 +134,7 @@ static int exynos_target(struct cpufreq_policy
*policy, unsigned int index)
static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
policy->clk = exynos_info->cpu_clk;
- policy->suspend_freq = clk_get_rate(exynos_info->cpu_clk) / 1000;
+ policy->suspend_freq = locking_frequency;
return cpufreq_generic_init(policy, exynos_info->freq_table, 100000);
}
@@ -182,6 +182,9 @@ static int __init exynos_cpufreq_init(void)
goto err_vdd_arm;
}
+ /* Done here as we want to capture boot frequency */
+ locking_frequency = clk_get_rate(exynos_info->cpu_clk) / 1000;
+
if (!cpufreq_register_driver(&exynos_driver))
return 0;
Hi,
I am trying to update latest upstream kernel on mphackbox TC2 board
according to this wiki.
https://wiki.linaro.org/Platform/LAVA/DevOps/TC2TilesOnLavaServer/hackbox
I use vexpress-v2p-ca15_a7.dts and vexpress_defconfig kernel config.
after make kernel and dtb images, I updated them as u-zimage.bin and
u-dtb.bin. but the kernel keep panic:
Did I miss sth or the just kernel broken?
===============
loading, please wait...
udevd[730]: starting version 175
Begin: Loading essential drivers ... done.
Begin: Runnimmci-pl18x 1c050000.mmci: no support for card's volts
ng /scripts/initmmc0: error -22 whilst initialising SD card
-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top
... done.
mmci-pl18x 1c050000.mmci: no support for card's volts
mmc0: error -22 whilst initialising SD card
Begin: Running /scripts/local-premount ... FATAL: Could not load
/lib/modules/3.12.0+/modules.dep: No such file or directory
done.
FATAL: Could not load /lib/modules/3.12.0+/modules.dep: No such file or
directory
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... mmci-pl18x 1c050000.mmci: no
support for card's volts
mmc0: error -22 whilst initialising SD card
mount: mounting /dev on /root/dev failed: No such file or directory
done.
mmci-pl18x 1c050000.mmci: no support for card's volts
mmc0: error -22 whilst initialising SD card
mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed: No such file or directory
Target filesystem doesn't have requested /sbin/init.
/init: line 35mmci-pl18x 1c050000.mmci: no support for card's volts
2: can't open /rmmc0: error -22 whilst initialising SD card
oot/dev/console: no such file
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000200
CPU: 0 PID: 1 Comm: init Tainted: G W 3.12.0+ #147
[<8001548c>] (unwind_backtrace+0x0/0xf8) from [<80011aec>]
(show_stack+0x10/0x14)
[<80011aec>] (show_stack+0x10/0x14) from [<80426a44>] (dump_stack+0x70/0x8c)
[<80426a44>] (dump_stack+0x70/0x8c) from [<80423f4c>] (panic+0x90/0x1e8)
[<80423f4c>] (panic+0x90/0x1e8) from [<80023e74>] (do_exit+0x838/0x8d8)
[<80023e74>] (do_exit+0x838/0x8d8) from [<8002401c>]
(do_group_exit+0x3c/0xc4)
[<8002401c>] (do_group_exit+0x3c/0xc4) from [<800240b4>]
(__wake_up_parent+0x0/0x18)
--
Thanks
Alex
Keystone code is big endian compatible,
so mark it as one that supports big endian.
Note this patch just allows to select Big endian build
for ARCH_KEYSTONE, but it does not enable BE by default.
Signed-off-by: Taras Kondratiuk <taras.kondratiuk(a)linaro.org>
---
Based on Linus' master tip (b4789b8).
Tested on Keystone2 EVM.
arch/arm/mach-keystone/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index f20c53e..8a9e943 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -11,6 +11,7 @@ config ARCH_KEYSTONE
select ARM_ERRATA_798181 if SMP
select COMMON_CLK_KEYSTONE
select TI_EDMA
+ select ARCH_SUPPORTS_BIG_ENDIAN
help
Support for boards based on the Texas Instruments Keystone family of
SoCs.
--
1.7.9.5
Sometimes boot loaders set CPU frequency to a value outside of frequency table
present with cpufreq core. In such cases CPU might be unstable if it has to run
on that frequency for long duration of time and so its better to set it to a
frequency which is specified in freq-table. This also makes cpufreq stats
inconsistent as cpufreq-stats would fail to register because current frequency
of CPU isn't found in freq-table.
Because we don't want this change to effect boot process badly, we go for the
next freq which is >= policy->cur ('cur' must be set by now, otherwise we will
end up setting freq to lowest of the table as 'cur' is initialized to zero).
In case where CPU is already running on one of the frequencies present in
freq-table, this would turn into a dummy call as __cpufreq_driver_target() would
return early.
Reported-by: Carlos Hernandez <ceh(a)ti.com>
Reported-by: Nishanth Menon <nm(a)ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
After lots of discussion with Nishanth and others, I feel something like this..
@Nishanth: Please see if this works for you and I hope we don't need any of
these patches anymore:
- https://lkml.org/lkml/2013/11/15/569 : cpufreq: cpufreq-cpu0: Use a sane boot
frequency when booting with a mismatched bootloader configuration
- https://lkml.org/lkml/2013/11/15/503 : cpufreq: stats: Do not populate stats
when policy->cur has no exact match
- https://lkml.org/lkml/2013/11/19/16 : cpufreq/stats: Add "unknown" frequency
field in stats tables
drivers/cpufreq/cpufreq.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 02d534d..d55c843 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1038,6 +1038,32 @@ static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif,
}
}
+ /*
+ * Sometimes boot loaders set CPU frequency to a value outside of
+ * frequency table present with cpufreq core. In such cases CPU might be
+ * unstable if it has to run on that frequency for long duration of time
+ * and so its better to set it to a frequency which is specified in
+ * freq-table. This also makes cpufreq stats inconsistent as
+ * cpufreq-stats would fail to register because current frequency of CPU
+ * isn't found in freq-table.
+ *
+ * Because we don't want this change to effect boot process badly, we go
+ * for the next freq which is >= policy->cur ('cur' must be set by now,
+ * otherwise we will end up setting freq to lowest of the table as 'cur'
+ * is initialized to zero).
+ *
+ * In case where CPU is already running on one of the frequencies
+ * present in freq-table, this would turn into a dummy call as
+ * __cpufreq_driver_target() would return early.
+ */
+ if (has_target()) {
+ ret = __cpufreq_driver_target(policy, policy->cur,
+ CPUFREQ_RELATION_L);
+ if (ret)
+ pr_err("%s: Unable to set frequency from table: %d\n",
+ __func__, ret);
+ }
+
/* related cpus should atleast have policy->cpus */
cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);
--
1.7.12.rc2.18.g61b472e
Hi,
As a part of daily validation of linux-next -> vexpress on vexpress-a9,
These kernel CI jobs builds daily linux-next with vexpress_defconfig and
submits job on vexpress-a9 target which validates build and boot.
LAVA reported boot test failed on vexpress-a9 [3].
Please find boot failed log [4].
Boot failed log:
--------------------
mmci-pl18x 10005000.mmci: dummy supplies not allowed
mmci-pl18x 10005000.mmci: Failed getting OCR mask: 0
mmci-pl18x 10005000.mmci: mmc0: PL180 manf 41 rev0 at 0x10005000 irq 41,42 (pio)
mmci-pl18x 10005000.mmci: no support for card's volts
mmc0: error -22 whilst initialising SD card
mmci-pl18x 10005000.mmci: no support for card's volts
mmc0: error -22 whilst initialising SD card
This issue was reported by QA team and fixed by Fathi [1] couple of months
back. Now this patch is applied on mainline [2]. But boot test still failed
[4].
linux-next.git tree already have this config enabled.
"CONFIG_REGULATOR_VEXPRESS=y"
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next
.git/tree/arch/arm/configs/vexpress_defconfig#n91
Bugs:
--------
https://bugs.launchpad.net/linaro-ci/+bug/1212893https://bugs.launchpad.net/linaro-ci/+bug/1235156
Ref link:
----------
[1] http://archive.arm.linux
.org.uk/lurker/message/20130831.125731.66d5b796.en.html
[2] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next
.git/commit/arch/arm/configs/vexpress_defconfig?id=0ffae27f0f29e877ce52e4794a99926167792378
[3] http://validation.linaro.org/dashboard/image-reports/linux-next
-vexpress_defconfig
[4] http://validation.linaro.org/scheduler/job/84789/log_file#L_33_398
Best regards
Naresh Kamboju
We know the load_idx is a decay for cpu_load of rq. After added
sched_avg, we has 2 kind decay for cpu_load. That is a kind of redundancy.
This patch remove the load_idx. There are 5 _idx in sched_domain,
busy_idx and idle_idx are not zero usually, but newidle_idx, wake_idx
and forkexec_idx are all zero on all arch.
and this patch remove the only place using busy_idx/idle_idx.
Since arm system rarely has much tasks running in system. this removing
should no harm. But it will be great, if someone can measure it with
some performance benchmark.
Do we have some performance testing force in linaro or ARM?
---
>From 6fd05051dbb5aaa28d3bfe11042cc9cbb147bf7c Mon Sep 17 00:00:00 2001
From: Alex Shi <alex.shi(a)linaro.org>
Date: Tue, 19 Nov 2013 17:38:07 +0800
Subject: [PATCH] sched: remove load_idx effect
Shortcut to remove rq->cpu_load[load_idx] effect in scheduler.
All other place rq->cpu_load used cpu_load[0].
Signed-off-by: Alex Shi <alex.shi(a)linaro.org>
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e8b652e..ce683aa 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5633,7 +5633,7 @@ static inline void update_sd_lb_stats(struct
lb_env *env, struct sd_lb_stats *sd
if (child && child->flags & SD_PREFER_SIBLING)
prefer_sibling = 1;
- load_idx = get_sd_load_idx(env->sd, env->idle);
+ load_idx = 0;
do {
struct sg_lb_stats *sgs = &tmp_sgs;
--
1.8.1.2
--
Thanks
Alex
Automated DT boot report for various ARM defconfigs.
Tree/Branch: arm-soc
Git describe: v3.12-9691-g7b6891f
Failed boot tests (console logs at the end)
===========================================
omap3-tobi,3530overo: FAIL: omap2plus_defconfig
am335x-bone: FAIL: multi_v7_defconfig
omap3-tobi,3530overo: FAIL: multi_v7_defconfig
Full Report
===========
omap2plus_defconfig
-------------------
am335x-boneblack PASS: 0 min 27.8 sec
omap3-beagle-xm PASS: 0 min 49.3 sec
am335x-bone PASS: 0 min 26.6 sec
omap4-panda PASS: 1 min 3.4 sec
omap4-panda-es PASS: 1 min 2.3 sec
omap3-tobi,3730storm PASS: 0 min 21.2 sec
omap3-tobi,3530overo FAIL: 0 min 0.2 sec
tegra_defconfig
---------------
tegra30-beaver PASS: 0 min 17.0 sec
imx_v6_v7_defconfig
-------------------
imx6dl-wandboard,wand-dual PASS: 0 min 18.2 sec
imx6dl-wandboard,wand-solo PASS: 0 min 18.5 sec
imx6q-wandboard PASS: 0 min 16.7 sec
mvebu_defconfig
---------------
armada-xp-openblocks-ax3-4 PASS: 0 min 22.0 sec
armada-370-mirabox PASS: 0 min 20.1 sec
multi_v7_defconfig
------------------
ste-snowball PASS: 0 min 25.6 sec
tegra30-beaver PASS: 0 min 17.3 sec
am335x-boneblack PASS: 0 min 34.7 sec
omap3-beagle-xm PASS: 0 min 48.4 sec
sun7i-a20-cubieboard2 PASS: 0 min 13.0 sec
armada-370-mirabox PASS: 0 min 20.6 sec
omap4-panda PASS: 1 min 1.4 sec
omap4-panda-es PASS: 1 min 2.5 sec
armada-xp-openblocks-ax3-4 PASS: 0 min 22.8 sec
imx6dl-wandboard,wand-solo PASS: 0 min 16.5 sec
am335x-bone FAIL: 0 min 31.4 sec
imx6q-wandboard PASS: 0 min 15.8 sec
omap3-tobi,3730storm PASS: 0 min 22.2 sec
imx6dl-wandboard,wand-dual PASS: 0 min 16.7 sec
omap3-tobi,3530overo FAIL: 0 min 0.1 sec
u8500_defconfig
---------------
ste-snowball PASS: 0 min 31.7 sec
sama5_defconfig
---------------
sama5d35ek PASS: 0 min 17.3 sec
Console logs for failures
=========================
omap2plus_defconfig
-------------------
omap3-tobi,3530overo: FAIL: last 24 lines of boot log:
------------------------------------------------------
Conmux::connect vence.lan:41415: connect failed - IO::Socket::INET: connect: Connection refused
~$off
# PYBOOT: Exception: ERROR: Unable to connect to console. Giving up.
# PYBOOT: Time: 0.21 seconds.
# PYBOOT: Result: FAIL
multi_v7_defconfig
------------------
am335x-bone: FAIL: last 24 lines of boot log:
---------------------------------------------
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
Unknown command '~`f~~~~ff~`f~~~~ff~`f~~~~ff' - try 'help'
U-Boot# xp~xp~~$off
# PYBOOT: Exception: ERROR: Could not break into autoboot.
# PYBOOT: Time: 31.37 seconds.
# PYBOOT: Result: FAIL
omap3-tobi,3530overo: FAIL: last 24 lines of boot log:
------------------------------------------------------
Conmux::connect vence.lan:41415: connect failed - IO::Socket::INET: connect: Connection refused
~$off
# PYBOOT: Exception: ERROR: Unable to connect to console. Giving up.
# PYBOOT: Time: 0.15 seconds.
# PYBOOT: Result: FAIL