On 01/23/2014 10:14 AM, Florian Vaussard wrote:
Hello,
On 01/23/2014 07:23 AM, Tero Kristo wrote:
On 01/23/2014 03:35 AM, Kevin Hilman wrote:
On Wed, Jan 22, 2014 at 4:46 PM, Kevin's boot bot <khilman@xxxxxxxxxx>
wrote:
Automated DT boot report for various ARM defconfigs.
Tree/Branch: next
Git describe: next-20140122
Failed boot tests (console logs at the end)
===========================================
omap3-tobi,3730storm: FAIL: omap2plus_defconfig
[...]
omap3-tobi,3730storm: FAIL: multi_v7_defconfig
These OMAP3 failures are new regressions. Full failure boot log
attached.
Bisected down to:
cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 is the first bad commit
commit cfa9667d4ac9da8b3ba2269f934ecd69ae504d39
Author: Tero Kristo <t-kristo@xxxxxx>
Date: Tue Oct 22 11:53:02 2013 +0300
ARM: OMAP2+: io: use new clock init API
clk_init is now separated to a common function which gets called
for all
SoC:s, which initializes the DT clocks and calls the SoC specific
clock init.
Signed-off-by: Tero Kristo <t-kristo@xxxxxx>
Acked-by: Tony Lindgren <tony@xxxxxxxxxxx>
Signed-off-by: Mike Turquette <mturquette@xxxxxxxxxx>
Kevin
Hi,
I think this is because the tobi board is including wrong omap3-soc.dtsi
file (omap34xx.dtsi) through omap3-overo.dtsi.
The board should include omap36xx.dtsi at least based on the boot log:
[ 0.000000] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )
The problem is that the Overo (processor card on the Tobi extension
board) can have a variety of processor depending on the exact model:
- OMAP 35xx (1st generation: Air, Earth, Fire, Sand, Tide, Water, FE)
- OMAP 3730
- AM/DM 37xx
omap3-overo.dtsi includes omap34xx.dtsi to be compatible with the first
generation.
omap34xx.dtsi
|
-> omap3-overo.dtsi (processor card)
|
-> omap3-tobi.dtsi (expansion board)
What is the fundamental incompatibility here? If we have to specifically
include omap36xx for newer Overo, it will become hard to maintain as it
will double the number of Overo / expansion boards possibilities.
Well, you get different board declaration inside
mach-omap2/board-generic.c for omap34xx vs omap36xx.
The clock data issues can be fixed by adding cpu_is_omap34xx() vs.
cpu_is_omap3630() checks within the mach-omap2/io.c file, but this is
probably for Tony/Kevin to comment whether we can/should do that.
-Tero
Regards,
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
