Automated DT boot report for various ARM defconfigs.
Tree/Branch: next
Git describe: next-20131107
Failed boot tests (console logs at the end)
===========================================
tegra30-beaver: FAIL: tegra_defconfig
tegra30-beaver: FAIL: multi_v7_defconfig
Full Report
===========
omap2plus_defconfig
-------------------
am335x-boneblack PASS: 0 min 27.8 sec
omap3-beagle-xm PASS: 0 min 50.1 sec
am335x-bone PASS: 0 min 26.6 sec
omap4-panda PASS: 1 min 4.4 sec
omap4-panda-es PASS: 1 min 6.3 sec
omap3-tobi,3730storm PASS: 0 min 23.7 sec
omap3-tobi,3530overo PASS: 0 min 21.5 sec
tegra_defconfig
---------------
tegra30-beaver FAIL: 1 min 36.2 sec
imx_v6_v7_defconfig
-------------------
imx6dl-wandboard,wand-dual PASS: 0 min 16.8 sec
imx6dl-wandboard,wand-solo PASS: 0 min 16.8 sec
imx6q-wandboard PASS: 0 min 15.2 sec
mvebu_defconfig
---------------
armada-xp-openblocks-ax3-4 PASS: 0 min 22.0 sec
armada-370-mirabox PASS: 0 min 20.0 sec
exynos_defconfig
----------------
exynos5250-arndale PASS: 0 min 29.9 sec
multi_v7_defconfig
------------------
ste-snowball PASS: 0 min 28.5 sec
tegra30-beaver FAIL: 1 min 36.2 sec
am335x-boneblack PASS: 0 min 34.7 sec
omap3-beagle-xm PASS: 0 min 49.3 sec
armada-370-mirabox PASS: 0 min 20.6 sec
omap4-panda PASS: 1 min 0.2 sec
omap4-panda-es PASS: 0 min 59.4 sec
armada-xp-openblocks-ax3-4 PASS: 0 min 22.7 sec
imx6dl-wandboard,wand-solo PASS: 0 min 17.4 sec
am335x-bone PASS: 0 min 33.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 PASS: 0 min 19.9 sec
u8500_defconfig
---------------
ste-snowball PASS: 0 min 28.9 sec
sama5_defconfig
---------------
sama5d35ek PASS: 0 min 17.4 sec
Console logs for failures
=========================
tegra_defconfig
---------------
tegra30-beaver: FAIL: last 24 lines of boot log:
------------------------------------------------
Tegra30 (Beaver) #if test -n ${initenv}; then run initenv; fi
if test -n ${initenv}; then run initenv; fi
Tegra30 (Beaver) #if test -n ${preboot}; then run preboot; fi
if test -n ${preboot}; then run preboot; fi
(Re)start USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
Tegra30 (Beaver) # setenv autoload no; setenv autoboot no
setenv autoload no; setenv autoboot no
Tegra30 (Beaver) # dhcp
dhcp
No ethernet found.
Tegra30 (Beaver) # dhcp
dhcp
No ethernet found.
Tegra30 (Beaver) # dhcp
dhcp
No ethernet found.
Tegra30 (Beaver) # ~$off
# PYBOOT: Exception: u-boot: ERROR: timeout getting DHCP address.
# PYBOOT: Time: 96.24 seconds.
# PYBOOT: Result: FAIL
multi_v7_defconfig
------------------
tegra30-beaver: FAIL: last 24 lines of boot log:
------------------------------------------------
Tegra30 (Beaver) # if test -n ${initenv}; then run initenv; fi
if test -n ${initenv}; then run initenv; fi
Tegra30 (Beaver) #if test -n ${preboot}; then run preboot; fi
if test -n ${preboot}; then run preboot; fi
(Re)start USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
Tegra30 (Beaver) # setenv autoload no; setenv autoboot no
setenv autoload no; setenv autoboot no
Tegra30 (Beaver) #dhcp
dhcp
No ethernet found.
Tegra30 (Beaver) # dhcp
dhcp
No ethernet found.
Tegra30 (Beaver) # dhcp
dhcp
No ethernet found.
Tegra30 (Beaver) # ~$off
# PYBOOT: Exception: u-boot: ERROR: timeout getting DHCP address.
# PYBOOT: Time: 96.16 seconds.
# PYBOOT: Result: FAIL
From: Mark Brown <broonie(a)linaro.org>
Ensure that the error message if we identify a flash we don't know how to
talk to is displayed on the console in order to aid diagnostics. While
we're at convert the message to use dev_info() rather than our hand rolled
version of it for consistency.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
drivers/mtd/devices/mtd_dataflash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/devices/mtd_dataflash.c b/drivers/mtd/devices/mtd_dataflash.c
index 1cfbfcf..4a47b02 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -879,7 +879,7 @@ static int dataflash_probe(struct spi_device *spi)
break;
/* obsolete AT45DB1282 not (yet?) supported */
default:
- pr_debug("%s: unsupported device (%x)\n", dev_name(&spi->dev),
+ dev_info(&spi->dev, "unsupported device (%x)\n",
status & 0x3c);
status = -ENODEV;
}
--
1.8.4.rc3
Hi Gary,
On 11/05/2013 08:09 PM, Gary Robertson wrote:
> Hello,
>
> LNG has decided we need to stop maintaining our kernel tree config fragments separately from those in the main Linaro tree if
> possible. While assessing what has to be done to accomplish this, I noticed there have been no updates to the 3.10 branches for
> the past three months.
>
> I also noticed that not only have several LNG developers contributed fragments to the config-core-tracking tree, but
> additionally there has been other work consolidating and enhancing fragments in that tree which looks at first glance as though
> it might be desirable for the LNG kernels.
>
> However, I recognize that config variables within the kernel change names, values, and organizational relationships as the
> kernel evolves across release versions. Obviously we will need to incorporate the config fragments which the LNG developers
> added to the tracking tree, but some of the other changes might not apply to the 3.10 kernel cleanly.
>
> So I am writing to as you as tree maintainers and as contributors of many of the recent changes to ask for a quick assessment
> and assist -
>
> 1. how much of the recent cleanup and enhancement in the config-core-tracking branch which follows <commit ID #
> 0dee3586def91d706cef49dfbd2e20c9200df600 configs: Initial core configs> is also applicable to the 3.10 kernel? -and-
I've made a quick look through "non-LNG" commits missing from config-core-3.10 (starting from "kvm-host.conf: enable guest OS
networking" by Kim Phillips), and they all look like applicable to the v3.10.
> 2. do you plan to back-port any of this to the earlier config-core-3.10 branch?
No, we don't plan that. We didn't plan to maintain config fragments for the older kernel versions, just for the most recent one.
Personally, I wouldn't mind if someone from LNG or any other group which continues to use config-core-3.10 (LSK users?) take the
ownership of config-core-3.10 branch.
Also, while we are at it:
would it make sense if we make http://staging.git.linaro.org/kernel/configs.git "the primary" repository now (not waiting to the
switch scheduled for December)?
(currently the git.linaro.org/kernel/configs.git is the primary one, and the changes done to it are periodically copied to
staging.g.l.o/kernel/configs.git).
Then we could try using Gerrit (staging.review.linaro.org) to submit and review the changes to config fragments.
> We would also like to understand how many of the recent updates in config-boards-tracking might be applicable to our 3.10 kernel.
Hard to say. E.g. as for the current Panda config fragments, the omap2plus.conf is tied to the particular kernel version (based
on the omap2plus.defconfig for that kernel version); while panda.conf should be less sensitive to the particular kernel version.
Thanks,
Andrey
> Based on answers to the above we will have to determine whether we can get by safely with merging the tracking config branches,
> or if we will still need to cherry-pick selected commits into our LNG tree.
>
> Any insight you might provide will be helpful and possibly will save us some time spent in trial-and-error experimentation.
>
> Thanks
>
> Gary Robertson
>
Hi,
I've tested a bit more big endian images from rmk/for-next
which has Ben's big endian series merged. I've run into several
issues while testing Pandaboard and Arndale. All three issues
have fairly simple fix once detected.
Here is short explanation/note for each fix
1) ARM: __fixup_smp read of SCU config should do byteswap in BE case
[1] introduced SCU read in __fixup_smp function in case of A9 cpu.
Such read need byteswap in case of BE.
2) ARM: mm: fix __phys_to_virt to work with 64 bit phys_addr_t in BE case
[2] changed type of __phys_to_virt from 'unsigned long' to 'phys_addr_t'
but that causes problem with inline assembler in __phys_to_virt function
that expects 'r' operand but gets 64 bit value. It is very similar to
ASID issue [3]. Small test cases that illustrate inline asm and 64 bit
operand issue could be found in [4].
3) ARM: fix mov to mvn conversion in case of 64 bit phys_addr_t and BE
Conflict resolution between [5] and [6] was not entirely correct for
the case when 'mov' instruction has to be converted into 'mvn'
instruction. I missed it in my previos testing because the issue manifests
itself only if CONFIG_ARCH_PHYS_ADDR_T_64BIT is enabled, which was not,
and I saw this issue only when I got to Arndale testing. In proposed
patch I've fixed this issue trying to push spirit of [6] and do it in
most optimized way. However personally, I think code could be much
readable if we just add instruction byteswap under ARM_BE8 after
read, and before write with common patch logic in between. After all, in
THUMB2 case few lines above code just do that. Please let me know if
folks like this idea better I can respin this fix.
Tests: boots and runs
TC2: LE/BE Thumb2/Non-Thumb2 (no LPAE, no ARCH_PHYS_ADDR_T_64BIT)
Pandaboard: LE/BE multiarch (non-thumb2)
Arndale: LE/BE Thumb2/Non-Thumb2 (with LPAE, with ARCH_PHYS_ADDR_T_64BIT,
no KVM, no MMC_DW_IDMAC)
For testing Arndale and Pandaboard BE BSP changes were used on top of
these patches.
References:
[1] bc41b8724f24b9a27d1dcc6c974b8f686b38d554
ARM: 7846/1: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
[2] ca5a45c06cd4764fb8510740f7fc550d9a0208d4
ARM: mm: use phys_addr_t appropriately in p2v and v2p conversions
[3] a1af3474487cc3b8731b990dceac6b6aad7f3ed8
ARM: tlb: ASID macro should give 32bit result for BE correct operation
[4] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/202584.h…
[5] f52bb722547f43caeaecbcc62db9f3c3b80ead9b
ARM: mm: Correct virt_to_phys patching for 64 bit physical addresses
[6] 2f9bf9beddb1649485b47302a5aba9761cbc9084
ARM: fixup_pv_table bug when CPU_ENDIAN_BE8
Victor Kamensky (3):
ARM: __fixup_smp read of SCU config should do byteswap in BE case
ARM: mm: fix __phys_to_virt to work with 64 bit phys_addr_t in BE case
ARM: fix mov to mvn conversion in case of 64 bit phys_addr_t and BE
arch/arm/include/asm/memory.h | 8 +++++++-
arch/arm/kernel/head.S | 7 ++++++-
2 files changed, 13 insertions(+), 2 deletions(-)
--
1.8.1.4
