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 armada-xp-openblocks-ax3-4: FAIL: mvebu_defconfig omap4-panda-es: FAIL: multi_v7_defconfig armada-xp-openblocks-ax3-4: FAIL: multi_v7_defconfig omap3-tobi,3730storm: FAIL: multi_v7_defconfig
Full Report ===========
omap2plus_defconfig ------------------- am335x-boneblack PASS: 0 min 26.2 sec omap3-beagle-xm PASS: 1 min 1.3 sec am335x-bone PASS: 0 min 27.7 sec omap3-tobi,3530overo PASS: 0 min 23.1 sec omap4-panda PASS: 1 min 8.9 sec omap5-uevm PASS: 0 min 56.7 sec omap4-panda-es PASS: 1 min 5.9 sec omap3-tobi,3730storm FAIL: 1 min 17.8 sec omap3-beagle PASS: 0 min 35.6 sec
multi_lpae_defconfig -------------------- omap5-uevm PASS: 1 min 43.2 sec sun7i-a20-cubieboard2 PASS: 0 min 14.3 sec
tegra_defconfig --------------- tegra30-beaver PASS: 0 min 17.0 sec
imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual PASS: 0 min 17.7 sec imx6dl-wandboard,wand-solo PASS: 0 min 17.7 sec imx6q-wandboard PASS: 0 min 16.4 sec
sunxi_defconfig --------------- sun7i-a20-cubieboard2 PASS: 0 min 12.0 sec sun4i-a10-cubieboard PASS: 0 min 17.8 sec
mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 FAIL: 0 min 20.4 sec armada-370-mirabox PASS: 0 min 20.2 sec
exynos_defconfig ---------------- exynos5250-arndale PASS: 0 min 29.1 sec
multi_v7_defconfig ------------------ ste-snowball PASS: 1 min 17.2 sec tegra30-beaver PASS: 0 min 16.8 sec am335x-boneblack PASS: 0 min 23.5 sec omap3-beagle-xm PASS: 0 min 52.5 sec sun7i-a20-cubieboard2 PASS: 0 min 19.6 sec armada-370-mirabox PASS: 0 min 21.5 sec omap4-panda PASS: 0 min 55.2 sec omap4-panda-es FAIL: 1 min 48.8 sec armada-xp-openblocks-ax3-4 FAIL: 0 min 22.4 sec sun4i-a10-cubieboard PASS: 0 min 19.2 sec imx6dl-wandboard,wand-solo PASS: 0 min 17.9 sec omap3-tobi,3530overo PASS: 0 min 23.0 sec am335x-bone PASS: 0 min 26.2 sec imx6q-wandboard PASS: 0 min 17.4 sec omap3-tobi,3730storm FAIL: 0 min 30.0 sec imx6dl-wandboard,wand-dual PASS: 0 min 18.4 sec omap3-beagle PASS: 0 min 41.6 sec
u8500_defconfig --------------- ste-snowball PASS: 0 min 30.1 sec
sama5_defconfig --------------- sama5d35ek PASS: 0 min 17.5 sec
Console logs for failures =========================
omap2plus_defconfig -------------------
omap3-tobi,3730storm: FAIL: last 24 lines of boot log: ------------------------------------------------------
[ 6.068756] [<c008fbc0>] (generic_handle_irq) from [<c000eda8>] (handle_IRQ+0x4c/0xb4) [ 6.077087] [<c000eda8>] (handle_IRQ) from [<c00085b4>] (omap3_intc_handle_irq+0x60/0x74) [ 6.085723] [<c00085b4>] (omap3_intc_handle_irq) from [<c054bda4>] (__irq_svc+0x44/0x5c) [ 6.094268] Exception stack(0xde0efcc0 to 0xde0efd08) [ 6.099609] fcc0: de515480 01003000 fa0b4000 34020001 de0efd2c de515000 de515000 00008002 [ 6.108215] fce0: de2ac646 de2ac640 de0efde6 00000000 00000000 de0efd08 c044f608 c0438554 [ 6.116851] fd00: 20000113 ffffffff [ 6.120544] [<c054bda4>] (__irq_svc) from [<c0438554>] (mmc_start_request+0xc4/0xe0) [ 6.128723] [<c0438554>] (mmc_start_request) from [<c043867c>] (__mmc_start_req+0x54/0x84) [ 6.137420] [<c043867c>] (__mmc_start_req) from [<c0438b1c>] (mmc_wait_for_cmd+0x58/0x88) [ 6.146057] [<c0438b1c>] (mmc_wait_for_cmd) from [<c0442618>] (mmc_io_rw_direct_host+0xa4/0x13c) [ 6.155334] [<c0442618>] (mmc_io_rw_direct_host) from [<c04433dc>] (sdio_read_cis+0x168/0x298) [ 6.164428] [<c04433dc>] (sdio_read_cis) from [<c04418c0>] (mmc_sdio_init_card+0x3e0/0xaa4) [ 6.173217] [<c04418c0>] (mmc_sdio_init_card) from [<c044228c>] (mmc_attach_sdio+0x78/0x360) [ 6.182128] [<c044228c>] (mmc_attach_sdio) from [<c043addc>] (mmc_rescan+0x260/0x2e8) [ 6.190399] [<c043addc>] (mmc_rescan) from [<c00590bc>] (process_one_work+0x1ac/0x4c4) [ 6.198760] [<c00590bc>] (process_one_work) from [<c0059f54>] (worker_thread+0x114/0x3b4) [ 6.207366] [<c0059f54>] (worker_thread) from [<c005fb48>] (kthread+0xcc/0xe8) [ 6.214996] [<c005fb48>] (kthread) from [<c000e548>] (ret_from_fork+0x14/0x2c) [ 6.222625] ---[ end trace 0f858337cb4b2be9 ]--- ~$off # PYBOOT: Exception: kernel: ERROR: failed to boot: <class 'pexpect.TIMEOUT'> # PYBOOT: Time: 77.85 seconds. # PYBOOT: Result: FAIL
mvebu_defconfig ---------------
armada-xp-openblocks-ax3-4: FAIL: last 24 lines of boot log: ------------------------------------------------------------
[<c04cfc40>] (kernel_init_freeable) from [<c03a2124>] (kernel_init+0x8/0x120) [<c03a2124>] (kernel_init) from [<c000e278>] (ret_from_fork+0x14/0x3c) Code: 8a000012 ebfff583 e2840054 f57ff05b (e1903f9f) ---[ end trace ef63c24d4a59005c ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
CPU1: stopping CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 3.13.0-next-20140122 #1 [<c0014824>] (unwind_backtrace) from [<c00110d4>] (show_stack+0x10/0x14) [<c00110d4>] (show_stack) from [<c03a694c>] (dump_stack+0x80/0x90) [<c03a694c>] (dump_stack) from [<c0013be4>] (handle_IPI+0x148/0x170) [<c0013be4>] (handle_IPI) from [<c00085ac>] (armada_370_xp_handle_irq+0xac/0xb0) [<c00085ac>] (armada_370_xp_handle_irq) from [<c0011c00>] (__irq_svc+0x40/0x50) Exception stack(0xee877fa0 to 0xee877fe8) 7fa0: eefe65b8 00000000 000009a4 00000000 ee876000 c05044ac c03ad9c8 ee876000 7fc0: c0531ab6 00000001 c0531ab6 ee876000 00000000 ee877fe8 c000edec c00556ac 7fe0: 60000113 ffffffff [<c0011c00>] (__irq_svc) from [<c00556ac>] (cpu_startup_entry+0xf4/0x134) [<c00556ac>] (cpu_startup_entry) from [<00008644>] (0x8644) ~$off # PYBOOT: Exception: kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000054
# PYBOOT: Time: 20.35 seconds. # PYBOOT: Result: FAIL
multi_v7_defconfig ------------------
omap4-panda-es: FAIL: last 24 lines of boot log: ------------------------------------------------
[ 1.622222] OMAP4 PM: u-boot >= v2012.07 is required for full PM support [ 1.629333] Registering SWP/SWPB emulation handler [ 1.635345] vwl1271: 1800 mV [ 1.642517] Skipping twl internal clock init and using bootloader value (unknown osc rate) [ 1.651733] twl 0-0048: PIH (irq 39) nested IRQs [ 1.657897] twl_rtc rtc.11: Enabling TWL-RTC [ 1.664733] twl_rtc rtc.11: rtc core: registered rtc.11 as rtc0 [ 1.671997] VAUX1_6030: 1000 <--> 3000 mV at 2800 mV [ 1.677978] VAUX2_6030: 1200 <--> 2800 mV at 1800 mV [ 1.683990] VAUX3_6030: 1000 <--> 3000 mV at 1200 mV [ 1.689941] VMMC: 1200 <--> 3000 mV at 3000 mV [ 1.695404] VPP: 1800 <--> 2500 mV at 1900 mV [ 1.700714] VUSIM: 1200 <--> 2900 mV at 1800 mV [ 1.706085] VDAC: 1800 mV [ 1.706085] VANA: 2100 mV [ 1.712768] VCXIO: 1800 mV [ 1.712768] VUSB: 3300 mV [ 1.719512] V1V8: 1800 mV [ 1.722991] V2V1: 2100 mV [ 1.729919] omap_i2c 48070000.i2c: bus 0 rev0.11 at 400 kHz ~$off # PYBOOT: Exception: kernel: ERROR: failed to boot: <class 'pexpect.TIMEOUT'> # PYBOOT: Time: 108.77 seconds. # PYBOOT: Result: FAIL
armada-xp-openblocks-ax3-4: FAIL: last 24 lines of boot log: ------------------------------------------------------------
[ 1.315916] [<c0810c48>] (kernel_init_freeable) from [<c0586094>] (kernel_init+0x8/0x120) [ 1.324119] [<c0586094>] (kernel_init) from [<c000e578>] (ret_from_fork+0x14/0x3c) [ 1.331710] Code: 8a000012 ebfff583 e2840054 f57ff05b (e1903f9f) [ 1.337853] ---[ end trace f86f26e87e9cb445 ]--- [ 1.342491] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 1.342491] [ 1.351652] CPU1: stopping [ 1.354370] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 3.13.0-next-20140122 #1 [ 1.362491] [<c001584c>] (unwind_backtrace) from [<c00113fc>] (show_stack+0x10/0x14) [ 1.370262] [<c00113fc>] (show_stack) from [<c058bbd8>] (dump_stack+0x84/0x94) [ 1.377506] [<c058bbd8>] (dump_stack) from [<c0014120>] (handle_IPI+0x148/0x174) [ 1.384923] [<c0014120>] (handle_IPI) from [<c00086fc>] (armada_370_xp_handle_irq+0xa8/0x114) [ 1.393471] [<c00086fc>] (armada_370_xp_handle_irq) from [<c0011f80>] (__irq_svc+0x40/0x50) [ 1.401841] Exception stack(0xed077fa0 to 0xed077fe8) [ 1.406908] 7fa0: ffffffed 2d74f000 c089b4e0 00000000 c089a4cc ed076000 c089a450 c093b88b [ 1.415108] 7fc0: c0596128 ed076000 c093b88b ed076000 00000000 ed077fe8 c000f118 c0080fc0 [ 1.423305] 7fe0: 60000113 ffffffff [ 1.426808] [<c0011f80>] (__irq_svc) from [<c0080fc0>] (cpu_startup_entry+0x100/0x144) [ 1.434747] [<c0080fc0>] (cpu_startup_entry) from [<00008944>] (0x8944) ~$off # PYBOOT: Exception: kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000054
# PYBOOT: Time: 22.45 seconds. # PYBOOT: Result: FAIL
omap3-tobi,3730storm: FAIL: last 24 lines of boot log: ------------------------------------------------------
done Bytes transferred = 56692 (dd74 hex) Overo # printenv bootargs printenv bootargs bootargs=console=ttyO2,115200n8 earlyprintk rw root=/dev/mmcblk0p2 rootwait rootfstype=ext4 ip=192.168.1.159:192.168.1.2:192.168.1.254:255.255.255.0::::192.168.1.254:none Overo # bootz ${loadaddr} 0x81000000 0x81f00000 bootz ${loadaddr} 0x81000000 0x81f00000 ## Loading init Ramdisk from Legacy Image at 81000000 ... Image Name: Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 639744 Bytes = 624.8 KiB Load Address: 81000000 Entry Point: 81000000 ## Flattened Device Tree blob at 81f00000 Booting using the fdt blob at 0x81f00000 Loading Ramdisk to 8ff63000, end 8ffff300 ... OK Loading Device Tree to 8ff52000, end 8ff62d73 ... OK
Starting kernel ...
~$off # PYBOOT: Exception: kernel: ERROR: did not start booting. # PYBOOT: Time: 30.01 seconds. # PYBOOT: Result: FAIL
On Wed, Jan 22, 2014 at 4:46 PM, Kevin's boot bot khilman@linaro.org 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@ti.com 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@ti.com Acked-by: Tony Lindgren tony@atomide.com Signed-off-by: Mike Turquette mturquette@linaro.org
Kevin
On 01/23/2014 03:35 AM, Kevin Hilman wrote:
On Wed, Jan 22, 2014 at 4:46 PM, Kevin's boot bot khilman@linaro.org 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_defconfigThese 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@ti.com 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 specificclock init.
Signed-off-by: Tero Kristo <t-kristo@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>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 )
-Tero
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@linaro.org 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_defconfigThese 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@ti.com 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 calledfor all SoC:s, which initializes the DT clocks and calls the SoC specific clock init.
Signed-off-by: Tero Kristo <t-kristo@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>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.
Regards,
Florian
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@linaro.org 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_defconfigThese 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@ti.com 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 calledfor all SoC:s, which initializes the DT clocks and calls the SoC specific clock init.
Signed-off-by: Tero Kristo <t-kristo@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>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
On 01/23/2014 10:00 AM, Tero Kristo wrote:
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@linaro.org 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_defconfigThese 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@ti.com 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 calledfor all SoC:s, which initializes the DT clocks and calls the SoC specific clock init.
Signed-off-by: Tero Kristo <t-kristo@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>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.
I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing the include to omap36xx.dtsi do not fix the issue. I still get the external abort on non-linefetch (full log here [1]).
Florian
On 01/23/2014 10:15 AM, Florian Vaussard wrote:
On 01/23/2014 10:00 AM, Tero Kristo wrote:
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@linaro.org 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_defconfigThese 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@ti.com 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 calledfor all SoC:s, which initializes the DT clocks and calls the SoC specific clock init.
Signed-off-by: Tero Kristo <t-kristo@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>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.
I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing the include to omap36xx.dtsi do not fix the issue. I still get the external abort on non-linefetch (full log here [1]).
So the issue is clearly caused by the hwmod warning just before the panic I think:
omap_hwmod: usb_tll_hs: enabled state can only be entered from initialized, idle, or disabled state
usb_tll_hs is thus not enabled, and we get a panic when trying to read the revision register
ver = usbtll_read(tll->base, OMAP_USBTLL_REVISION);
at drivers/mfd/omap-usb-tll.c:237.
I do not know enough about hwmod to efficiently debug why usb_tll_hs is not _HWMOD_STATE_INITIALIZED before trying to enable it. Are we missing some DT data?
Florian
On 01/23/2014 11:41 AM, Florian Vaussard wrote:
On 01/23/2014 10:15 AM, Florian Vaussard wrote:
On 01/23/2014 10:00 AM, Tero Kristo wrote:
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@linaro.org 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@ti.com 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 calledfor all SoC:s, which initializes the DT clocks and calls the SoC specific clock init.
Signed-off-by: Tero Kristo <t-kristo@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>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.
I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing the include to omap36xx.dtsi do not fix the issue. I still get the external abort on non-linefetch (full log here [1]).
So the issue is clearly caused by the hwmod warning just before the panic I think:
omap_hwmod: usb_tll_hs: enabled state can only be entered from initialized, idle, or disabled state
usb_tll_hs is thus not enabled, and we get a panic when trying to read the revision register
ver = usbtll_read(tll->base, OMAP_USBTLL_REVISION);at drivers/mfd/omap-usb-tll.c:237.
I do not know enough about hwmod to efficiently debug why usb_tll_hs is not _HWMOD_STATE_INITIALIZED before trying to enable it. Are we missing some DT data?
The problem is the point before this one, uart4_fck lookup fails. This causes the hwmod code to bail out early and not init anything after it.
I guess you are still mapping wrong clock init as it fails with uart4. Give the attached patch a shot and see how it behaves.
-Tero
On 01/23/2014 01:27 PM, Tero Kristo wrote:
On 01/23/2014 11:41 AM, Florian Vaussard wrote:
On 01/23/2014 10:15 AM, Florian Vaussard wrote:
On 01/23/2014 10:00 AM, Tero Kristo wrote:
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@linaro.org > 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@ti.com > 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@ti.com > Acked-by: Tony Lindgren tony@atomide.com > Signed-off-by: Mike Turquette mturquette@linaro.org > > 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.
I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing the include to omap36xx.dtsi do not fix the issue. I still get the external abort on non-linefetch (full log here [1]).
So the issue is clearly caused by the hwmod warning just before the panic I think:
omap_hwmod: usb_tll_hs: enabled state can only be entered from initialized, idle, or disabled state
usb_tll_hs is thus not enabled, and we get a panic when trying to read the revision register
ver = usbtll_read(tll->base, OMAP_USBTLL_REVISION);at drivers/mfd/omap-usb-tll.c:237.
I do not know enough about hwmod to efficiently debug why usb_tll_hs is not _HWMOD_STATE_INITIALIZED before trying to enable it. Are we missing some DT data?
The problem is the point before this one, uart4_fck lookup fails. This causes the hwmod code to bail out early and not init anything after it.
I guess you are still mapping wrong clock init as it fails with uart4. Give the attached patch a shot and see how it behaves.
Ok, so with your patch and changing the include from omap34xx to omap36xx, it works. Now I have to come up with a way to manage all the versions without duplicating all the DT files :-(
Regards,
Florian
On 01/23/2014 10:35 AM, Florian Vaussard wrote:
[..]
Ok, so with your patch and changing the include from omap34xx to omap36xx, it works. Now I have to come up with a way to manage all the versions without duplicating all the DT files :-(
you'd also want to be careful about the omap3_pmx_core2 Vs omap3_pmx_core2 split for padconf.
options that come to mind are: a) split omap3-overo.dtsi into omap3-overo-common.dtsi omap3-overo-34xx.dtsi,omap3-overo-36xx.dtsi, corresponding tobi board dts file include as needed b) only have common stuff in omap3-overo.dtsi, include omap34xx.dtsi or omap36xx.dtsi in corresponding tobi board dts.
Hi,
On 01/23/2014 06:33 PM, Nishanth Menon wrote:
On 01/23/2014 10:35 AM, Florian Vaussard wrote:
[..]
Ok, so with your patch and changing the include from omap34xx to omap36xx, it works. Now I have to come up with a way to manage all the versions without duplicating all the DT files :-(
you'd also want to be careful about the omap3_pmx_core2 Vs omap3_pmx_core2 split for padconf.
Yes, I know that this is another problematic point. I guess that I will end up splitting all 34xx-specific and 36xx-specific parts into dedicated files. Unless I can figure out a way to magically compute the offset inside the pinctrl domain, but I doubt. I will try to contain the omap3_pmx_core2 pins to omap3-overo, away from the expansion boards.
options that come to mind are: a) split omap3-overo.dtsi into omap3-overo-common.dtsi omap3-overo-34xx.dtsi,omap3-overo-36xx.dtsi, corresponding tobi board dts file include as needed b) only have common stuff in omap3-overo.dtsi, include omap34xx.dtsi or omap36xx.dtsi in corresponding tobi board dts.
Yes, both are an option. I don't know if b) can work, as omap3-overo.dtsi maybe depends on features declared in omap3yxx.dtsi (to be verified).
The main problem with both options is that Tobi is not the only expansion board (the only mainlined for now). I sent patches for other expansion boards a couple of days ago [1], so at the end we may have ~10 boards if you count only Gumstix's boards, not to mention the boards from other people (like me). So finally, we will double the number of dts files just to support both variants. I hope that Gumstix will not produce a third version of the Overo.
Maybe I can use dt overlay for the expansion boards, like what is done for capes with beaglebone. The expansion board's overlay could be applied to the correct Overo dtb at runtime, like what is done from the hardware's point of view.
I am not familiar with overlays, but from my rapid analysis, the main difference is: cape's overlay is fused by the userspace when the kernel has booted, whereas Overo's expansion boards must be fused early in the boot process (or by the bootloader), as they provide some essential services, like the primary NIC. I need more time to explore the feasibility of this solution.
Regards,
Florian
[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/109589
* Florian Vaussard florian.vaussard@epfl.ch [140123 08:37]:
On 01/23/2014 01:27 PM, Tero Kristo wrote:
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
With the legacy booting, the real problem is that board-overo.c is trying to boot all overos with just one machine ID. Tero's patch works around that issue for legacy booting, but maybe it's best to do the SoC detection in the board-*.c files in init_early as needed rather than patch all the board-*.c files.
Sounds like we need to do the same for legacy booting for the original beagle as well?
Ok, so with your patch and changing the include from omap34xx to omap36xx, it works. Now I have to come up with a way to manage all the versions without duplicating all the DT files :-(
Yeah there's no quick fix here that's suitable in the long run. The proper fix is to have minimal SoC specific .dts files for the supported overo variants that include the common board specific .dtsi file(s).
We did a similar thing recently for the compulab variants, see commit 0f0cfc69547e (ARM: dts: Add support for sbc-3xxx with cm-t3730) for example. Also take a look at the follo-up patches posted to the mailing list.
With device tree based booting we don't want to build data into the kernel for all the SoC variants for things like clocks, pinctrl and hwmod. And we already need to define SoC specific things in the .dts files for pinctrl with clocks and hwmod heading that way too, so relying on the built-in kernel data won't work in the long run.
If we really wanted to, we could set some devices to disabled state in the bootloader or in the kernel and rely on the SoC detection. But then we're back to building all the data into the kernel. And we won't be able to boot new SoC variants with just .dts changes in the long run like device tree is supposed to do.
Regards,
Tony
* Tony Lindgren tony@atomide.com [140123 09:37]:
- Florian Vaussard florian.vaussard@epfl.ch [140123 08:37]:
On 01/23/2014 01:27 PM, Tero Kristo wrote:
> > 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
With the legacy booting, the real problem is that board-overo.c is trying to boot all overos with just one machine ID. Tero's patch works around that issue for legacy booting, but maybe it's best to do the SoC detection in the board-*.c files in init_early as needed rather than patch all the board-*.c files.
Sounds like we need to do the same for legacy booting for the original beagle as well?
Looks like the beagle boards are OK as for legacy booting we're seeting omap_clk_soc_init = omap3xxx_clk_init. And for DT based booting we have separate omap3-beagle.dts and omap3-beagle-xm.dts that include omap34xx.dtsi and omap36xx.dtsi respectively.
So it seems that only the over .dts files need to be fixed.
Ok, so with your patch and changing the include from omap34xx to omap36xx, it works. Now I have to come up with a way to manage all the versions without duplicating all the DT files :-(
Yeah there's no quick fix here that's suitable in the long run. The proper fix is to have minimal SoC specific .dts files for the supported overo variants that include the common board specific .dtsi file(s).
We did a similar thing recently for the compulab variants, see commit 0f0cfc69547e (ARM: dts: Add support for sbc-3xxx with cm-t3730) for example. Also take a look at the follo-up patches posted to the mailing list.
With device tree based booting we don't want to build data into the kernel for all the SoC variants for things like clocks, pinctrl and hwmod. And we already need to define SoC specific things in the .dts files for pinctrl with clocks and hwmod heading that way too, so relying on the built-in kernel data won't work in the long run.
If we really wanted to, we could set some devices to disabled state in the bootloader or in the kernel and rely on the SoC detection. But then we're back to building all the data into the kernel. And we won't be able to boot new SoC variants with just .dts changes in the long run like device tree is supposed to do.
Regards,
Tony
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/23/2014 06:35 PM, Tony Lindgren wrote:
- Florian Vaussard florian.vaussard@epfl.ch [140123 08:37]:
On 01/23/2014 01:27 PM, Tero Kristo wrote:
> > 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
With the legacy booting, the real problem is that board-overo.c is trying to boot all overos with just one machine ID. Tero's patch works around that issue for legacy booting, but maybe it's best to do the SoC detection in the board-*.c files in init_early as needed rather than patch all the board-*.c files.
Sounds like we need to do the same for legacy booting for the original beagle as well?
Ok, so with your patch and changing the include from omap34xx to omap36xx, it works. Now I have to come up with a way to manage all the versions without duplicating all the DT files :-(
Yeah there's no quick fix here that's suitable in the long run. The proper fix is to have minimal SoC specific .dts files for the supported overo variants that include the common board specific .dtsi file(s).
We did a similar thing recently for the compulab variants, see commit 0f0cfc69547e (ARM: dts: Add support for sbc-3xxx with cm-t3730) for example. Also take a look at the follo-up patches posted to the mailing list.
I agree with your approach. But in my case, I have N x M combinations (N Overo variants, M expansion boards). Currently we have something like 2 x 10, so having ~20 dts files (not counting all the common dtsi files) will start to get really messy. And this will only get worst as time goes by (more expansion boards, and maybe other pin-compatible Overo).
With device tree based booting we don't want to build data into the kernel for all the SoC variants for things like clocks, pinctrl and hwmod. And we already need to define SoC specific things in the .dts files for pinctrl with clocks and hwmod heading that way too, so relying on the built-in kernel data won't work in the long run.
If we really wanted to, we could set some devices to disabled state in the bootloader or in the kernel and rely on the SoC detection. But then we're back to building all the data into the kernel. And we won't be able to boot new SoC variants with just .dts changes in the long run like device tree is supposed to do.
Data must by in the dts file, but what is needed is a mechanism similar to the hardware connector: the Overo's dts should be combined with the expansion board's dts (at runtime, or offline). Overlays seem a good candidate, but I have no experience with them. As I said to Nishanth in the other thread, overlays are fused by the userspace in the case of BeagleBone AFAIK. But I need them early in the boot process (otherwise, no NIC, thus no NFS or similar goodies). I need to think more on this.
Regards,
Florian
* Florian Vaussard florian.vaussard@epfl.ch [140123 01:17]:
I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing the include to omap36xx.dtsi do not fix the issue. I still get the external abort on non-linefetch (full log here [1]).
I think the issue here is that you need to have "ti,omap36xx" in the compatible string in addition to including omap36xx.dtsi. Otherwise "ti,omap3" will initialize things for 34xx.
For the initial minimal fix, I suggest we do something like the following. This should fix things for 36xx based tobi, then 34xx based tobi support can be added later on. Untested as I don't have one.
Regards,
Tony
--- a/arch/arm/boot/dts/omap3-overo.dtsi +++ b/arch/arm/boot/dts/omap3-overo.dtsi @@ -9,9 +9,6 @@ /* * The Gumstix Overo must be combined with an expansion board. */ -/dts-v1/; - -#include "omap34xx.dtsi"
/ { pwmleds { --- a/arch/arm/boot/dts/omap3-tobi.dts +++ b/arch/arm/boot/dts/omap3-tobi.dts @@ -10,11 +10,14 @@ * Tobi expansion board is manufactured by Gumstix Inc. */
+/dts-v1/; + +#include "omap36xx.dtsi" #include "omap3-overo.dtsi"
/ { model = "TI OMAP3 Gumstix Overo on Tobi"; - compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"; + compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap36xx", "ti,omap3";
leds { compatible = "gpio-leds";
Hi,
On 01/24/2014 07:11 PM, Tony Lindgren wrote:
- Florian Vaussard florian.vaussard@epfl.ch [140123 01:17]:
I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing the include to omap36xx.dtsi do not fix the issue. I still get the external abort on non-linefetch (full log here [1]).
I think the issue here is that you need to have "ti,omap36xx" in the compatible string in addition to including omap36xx.dtsi. Otherwise "ti,omap3" will initialize things for 34xx.
For the initial minimal fix, I suggest we do something like the following. This should fix things for 36xx based tobi, then 34xx based tobi support can be added later on. Untested as I don't have one.
You are probably right. I will test Monday.
Regards,
Florian
Regards,
Tony
--- a/arch/arm/boot/dts/omap3-overo.dtsi +++ b/arch/arm/boot/dts/omap3-overo.dtsi @@ -9,9 +9,6 @@ /*
- The Gumstix Overo must be combined with an expansion board.
*/ -/dts-v1/;
-#include "omap34xx.dtsi" / { pwmleds { --- a/arch/arm/boot/dts/omap3-tobi.dts +++ b/arch/arm/boot/dts/omap3-tobi.dts @@ -10,11 +10,14 @@
- Tobi expansion board is manufactured by Gumstix Inc.
*/ +/dts-v1/;
+#include "omap36xx.dtsi" #include "omap3-overo.dtsi" / { model = "TI OMAP3 Gumstix Overo on Tobi";
- compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3";
- compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap36xx", "ti,omap3";
leds { compatible = "gpio-leds";
On Fri, Jan 24, 2014 at 10:13 AM, Florian Vaussard florian.vaussard@epfl.ch wrote:
Hi,
On 01/24/2014 07:11 PM, Tony Lindgren wrote:
- Florian Vaussard florian.vaussard@epfl.ch [140123 01:17]:
I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing the include to omap36xx.dtsi do not fix the issue. I still get the external abort on non-linefetch (full log here [1]).
I think the issue here is that you need to have "ti,omap36xx" in the compatible string in addition to including omap36xx.dtsi. Otherwise "ti,omap3" will initialize things for 34xx.
For the initial minimal fix, I suggest we do something like the following. This should fix things for 36xx based tobi, then 34xx based tobi support can be added later on. Untested as I don't have one.
You are probably right. I will test Monday.
Any progress on this?
We still have the 36xx Tobi boards failing basic boot tests -next, but now also in mainline.
Kevin
Hi Kevin,
On 02/05/2014 04:23 PM, Kevin Hilman wrote:
On Fri, Jan 24, 2014 at 10:13 AM, Florian Vaussard florian.vaussard@epfl.ch wrote:
Hi,
On 01/24/2014 07:11 PM, Tony Lindgren wrote:
- Florian Vaussard florian.vaussard@epfl.ch [140123 01:17]:
I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing the include to omap36xx.dtsi do not fix the issue. I still get the external abort on non-linefetch (full log here [1]).
I think the issue here is that you need to have "ti,omap36xx" in the compatible string in addition to including omap36xx.dtsi. Otherwise "ti,omap3" will initialize things for 34xx.
For the initial minimal fix, I suggest we do something like the following. This should fix things for 36xx based tobi, then 34xx based tobi support can be added later on. Untested as I don't have one.
You are probably right. I will test Monday.
Any progress on this?
We still have the 36xx Tobi boards failing basic boot tests -next, but now also in mainline.
Thanks for the reminder. Tony's patch fixes the problem for 36xx Overo, but makes 35xx Overo to fail. I did a patch to split the Tobi between a common include file, and model-specific DTS. Will send it in a couple of minutes.
Regards,
Florian
linaro-kernel@lists.linaro.org
-
Florian Vaussard -
Kevin Hilman -
Kevin's boot bot
-
Nishanth Menon -
Tero Kristo -
Tony Lindgren