OMAP2430 SDP boot broken after Linus' rmk merge

After Linus's commit fb2af0020a51709ad87ea8055c325d3fbde04158 ("Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm"), the OMAP2430 SDP here stopped booting.

Here's the bootlog at the commit before the merge, commit 790eac5640:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722015454/

and here's a log at commit fb2af0020a5:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722005921/

Any ideas as to what might have caused this?

Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system.

Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem.

I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).

Quoted 7 lines · Russell King - ARM Linux

Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system.

I understand completely...

Quoted 4 lines

Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem.

Quoted 3 lines

I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).

OK, will dig deeper here at the next opportunity.

- Paul

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 16 lines · Paul Walmsley

Quoted 7 lines · Russell King - ARM Linux

Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system.

I understand completely...

Quoted 4 lines

Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem.

Quoted 5 lines

Quoted 3 lines

I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).

OK, will dig deeper here at the next opportunity.

Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on 2430sdp as the subject says, or was that a typo?

Hi Rajendra,

Quoted 23 lines · Rajendra Nayak

Quoted 21 lines · Paul Walmsley

Quoted 7 lines · Russell King - ARM Linux

Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system.

I understand completely...

Quoted 7 lines

Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem.

I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).

OK, will dig deeper here at the next opportunity.

Quoted 2 lines

Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on 2430sdp as the subject says, or was that a typo?

Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my testbed.

I don't have a 4430SDP, so you might consider touching base with rmk for that one.

- Paul

Quoted 33 lines · Paul Walmsley

Hi Rajendra,

Quoted 17 lines · Rajendra Nayak

Quoted 16 lines · Paul Walmsley

Quoted 7 lines · Russell King - ARM Linux

Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system.

I understand completely...

Quoted 4 lines

Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).

OK, will dig deeper here at the next opportunity.

Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on 2430sdp as the subject says, or was that a typo?

Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my testbed.

Quoted 2 lines

I don't have a 4430SDP, so you might consider touching base with rmk for that one.

So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB)

Quoted 37 lines · Rajendra Nayak

Quoted 35 lines · Paul Walmsley

Hi Rajendra,

Quoted 17 lines · Rajendra Nayak

Quoted 16 lines · Paul Walmsley

Quoted 7 lines · Russell King - ARM Linux

Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system.

I understand completely...

Quoted 4 lines

Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).

OK, will dig deeper here at the next opportunity.

Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on 2430sdp as the subject says, or was that a typo?

Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my testbed.

I don't have a 4430SDP, so you might consider touching base with rmk for that one.

Quoted 3 lines

So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB)

Any update on this? If it's an issue introduced by architectural changes, I'd really like to bisect it down but I don't have a board.

From the other thread, RMK did manage to get the board booting finally

Quoted 38 lines · Will Deacon

Quoted 37 lines · Rajendra Nayak

Quoted 35 lines · Paul Walmsley

Hi Rajendra,

Quoted 17 lines · Rajendra Nayak

Quoted 16 lines · Paul Walmsley

Quoted 7 lines · Russell King - ARM Linux

Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system.

I understand completely...

Quoted 4 lines

Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).

OK, will dig deeper here at the next opportunity.

Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on 2430sdp as the subject says, or was that a typo?

Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my testbed.

I don't have a 4430SDP, so you might consider touching base with rmk for that one.

Quoted 7 lines

Quoted 3 lines

So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB)

Any update on this? If it's an issue introduced by architectural changes, I'd really like to bisect it down but I don't have a board.

From the other thread, RMK did manage to get the board booting finally (uImage related issues, low level debug problem) but with DT only supported build, the audio and DSS was not at same state as before(non-DT build). And then Tony pointed the issues to Peter and Tomy to address it further.

Russell,
Is above right or I am missing something ?

Quoted 51 lines · Santosh Shilimkar

Quoted 38 lines · Will Deacon

Quoted 37 lines · Rajendra Nayak

Quoted 35 lines · Paul Walmsley

Hi Rajendra,

Quoted 17 lines · Rajendra Nayak

Quoted 16 lines · Paul Walmsley

Quoted 7 lines · Russell King - ARM Linux

Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system.

I understand completely...

Quoted 4 lines

Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).

OK, will dig deeper here at the next opportunity.

Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on 2430sdp as the subject says, or was that a typo?

Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my testbed.

I don't have a 4430SDP, so you might consider touching base with rmk for that one.

Quoted 7 lines

Quoted 3 lines

So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB)

Any update on this? If it's an issue introduced by architectural changes, I'd really like to bisect it down but I don't have a board.

From the other thread, RMK did manage to get the board booting finally (uImage related issues, low level debug problem) but with DT only supported build, the audio and DSS was not at same state as before(non-DT build). And then Tony pointed the issues to Peter and Tomy to address it further.

Quoted 2 lines

Russell,
Is above right or I am missing something ?

I thought that was the 4430 from before the merge window. Ths issue here is the 2430 running mainline, as reported by Paul

Tonight I put on a Jon Hopkins album, in recollection of my UK ARM Linux colleagues perhaps, and started testing, and eventually wound up with this one:

commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc
Author: Will Deacon <[email protected]>

Date: Wed Jun 12 12:25:56 2013 +0100

ARM: 7757/1: mm: don't flush icache in switch_mm with hardware broadcasting

When scheduling an mm on a CPU where it hasn't previously been used, we flush the icache on that CPU so that any code loaded previously on a different core can be safely executed.

For cores with hardware broadcasting of cache maintenance operations, this is clearly unnecessary, since the inner-shareable invalidation in __sync_icache_dcache will affect all CPUs.

This patch conditionalises the icache flush in switch_mm based on cache_ops_need_broadcast().

Acked-by Catalin Marinas <[email protected]>

Reported-by Albin Tonnerre <[email protected]>

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Russell King <[email protected]>

...

v3.11-rc2 boots with it reverted. What also works is v3.11-rc2 with the below patch applied.

Would be pleased to boot-test anything you'd care to send my way, as long as you can tolerate response latency jitter.

That's very odd -- I *suspect* your bootloader is up to no good (iirc, we've had issues with the bootloader on this machine in the past, since it enters the kernel in ABT mode or something).

Can you try this quick hack please? It clobbers the I-cache as soon as we enter the kernel, so it should tell us whether my theory is correct.

Ensure that the remaining callers of read_cpuid_ext can't attempt an extended CP15 register read on ARMv6.

Ensure that the remaining callers of read_cpuid_ext can't attempt an extended CP15 register read on ARMv6 cores that don't support it. The only one that appears dodgy is tlb_ops_need_broadcast().

While here, convert feat_v6_fixup() to use cpu_is_arm1136_r0() to save a few lines of code.

Signed-off-by Paul Walmsley <[email protected]>

Cc Will Deacon <[email protected]>

Cc Russell King <[email protected]>

Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks the boot on OMAP2430SDP with omap2plus_defconfig. Tracked to an undefined instruction abort from the CP15 read in cache_ops_need_broadcast(). It turns out that early ARM1136 variants don't support several CP15 registers that later ARM cores do. ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.

arch/arm/include/asm/smp_plat.h +0 -1

index 6462a72..76214cb 100644
@@ -25,7 +25,6 @@ static inline bool is_smp(void)
 #endif
 }
 
-/* all SMP configurations have the extended CPUID registers */
 #ifndef CONFIG_MMU
 #define tlb_ops_need_broadcast()	0
 #else

Hi Paul,

Cheers for sticking with this!

Quoted 8 lines · Paul Walmsley

Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks the boot on OMAP2430SDP with omap2plus_defconfig. Tracked to an undefined instruction abort from the CP15 read in cache_ops_need_broadcast(). It turns out that early ARM1136 variants don't support several CP15 registers that later ARM cores do. ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.

Intriguing... I wouldn't expect a cp15 read to be emitted for 1136, since the SMP_ON_UP magic should have caused is_smp() to return false.

We don't want to make the asm() itself volatile, because that means the asm() statement can't be optimised away.

Adding a memory clobber to that asm seems to place it more appropriately, but again, that's not particularly desirable.

Another solution would be to make both tlb_ops_need_broadcast and cache_ops_need_broadcast both be a flag test, but that introduces a memory load in all those paths no matter if we're running on SMP_ON_UP or not.

Quoted 8 lines · Paul Walmsley

Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks the boot on OMAP2430SDP with omap2plus_defconfig. Tracked to an undefined instruction abort from the CP15 read in cache_ops_need_broadcast(). It turns out that early ARM1136 variants don't support several CP15 registers that later ARM cores do. ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.

Intriguing... I wouldn't expect a cp15 read to be emitted for 1136, since the SMP_ON_UP magic should have caused is_smp() to return false.

So we should have returned 0 here without exploding (this just reads a .globl initialised in head.S). Are we somehow misidentifying your 1136 as an SMP core?

Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks the boot on OMAP2430SDP with omap2plus_defconfig. Tracked to an undefined instruction abort from the CP15 read in cache_ops_need_broadcast(). It turns out that gcc reorders the extended CP15 read above the is_smp() test. This breaks ARM1136 r0 cores, since they don't support several CP15 registers that later ARM cores do. ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.

So, when the kernel is built for ARMv6 cores, mark the extended CP15 read as clobbering memory, which seems to prevent the compiler from reordering it before the is_smp() test. Russell states that the code generated from this approach is preferable to marking the inline asm as volatile.

This patch was developed in collaboration with Will Deacon and Russell King.

Signed-off-by Paul Walmsley <[email protected]>

Cc Will Deacon <[email protected]>

Cc Russell King <[email protected]>

Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks the boot on OMAP2430SDP with omap2plus_defconfig. Tracked to an undefined instruction abort from the CP15 read in cache_ops_need_broadcast(). It turns out that gcc reorders the extended CP15 read above the is_smp() test. This breaks ARM1136 r0 cores, since they don't support several CP15 registers that later ARM cores do. ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.

arch/arm/include/asm/cputype.h +12 -0

index 8c25dc4..f428eb0 100644
@@ -89,13 +89,25 @@ extern unsigned int processor_id;
 		__val;							\
 	})
 
+
+# if defined(CONFIG_CPU_V6)
+/*
+ * The mrc in the read_cpuid_ext macro must not be reordered on ARMv6,
+ * else the compiler may move it before an is_smp() test, causing
+ * undefined instruction aborts on ARM1136 r0.
+ */
+# define CPUID_EXT_REORDER	"cc", "memory"
+# else
+# define CPUID_EXT_REORDER	"cc"
+# endif
+

I wouldn't worry about checking for CPU_V6. Besides, we probably need this to be re-evaluated across barrier() when we get CPU migration on a big-little platform anyway (we should probably also drop the __attribute_const__ for that).

So you can just replace the "cc" (now that Nico kindly explained why those aren't needed the other day) with "memory".

An alternative is to add barrier() between is_smp() and the read_cpuid_ext() in all callers, adding a fake read from the stack to the latter (like I did for the per-cpu accessor). However, this relies on fixing all callers for very little gain, so I don't think it's worth the hassle.

I can cook a patch if you're tied up with other things -- just let me know.

Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks the boot on OMAP2430SDP with omap2plus_defconfig. Tracked to an undefined instruction abort from the CP15 read in cache_ops_need_broadcast(). It turns out that gcc 4.5 reorders the extended CP15 read above the is_smp() test. This breaks ARM1136 r0 cores, since they don't support several CP15 registers that later ARM cores do. ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.

So mark the extended CP15 read as clobbering memory, which prevents the compiler from reordering it before the is_smp() test. Russell states that the code generated from this approach is preferable to marking the inline asm as volatile. Remove the existing condition code clobber as it's obsolete, per Nico's post:

    http://www.spinics.net/lists/arm-kernel/msg261208.html

This patch is a collaboration with Will Deacon and Russell King.

Signed-off-by Paul Walmsley <[email protected]>

Cc Will Deacon <[email protected]>

Cc Russell King <[email protected]>

Cc Nicolas Pitre <[email protected]>

Cc Tony Lindgren <[email protected]>

---

Quoted 45 lines · Will Deacon

Quoted 34 lines · Rajendra Nayak

Quoted 33 lines · Paul Walmsley

Hi Rajendra,

Quoted 17 lines · Rajendra Nayak

Quoted 16 lines · Paul Walmsley

Quoted 7 lines · Russell King - ARM Linux

Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system.

I understand completely...

Quoted 4 lines

Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).

OK, will dig deeper here at the next opportunity.

Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on 2430sdp as the subject says, or was that a typo?

Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my testbed.

Quoted 6 lines

Quoted 2 lines

I don't have a 4430SDP, so you might consider touching base with rmk for that one.

So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB)

Any update on this? If it's an issue introduced by architectural changes, I'd really like to bisect it down but I don't have a board.

Quoted 1 line

From the other thread, RMK did manage to get the board booting finally

(uImage related issues, low level debug problem) but with DT only supported build, the audio and DSS was not at same state as before(non-DT build). And then Tony pointed the issues to Peter and Tomy to address it further.

Russell,
Is above right or I am missing something ?

Quoted 3 lines · Santosh Shilimkar

Quoted 2 lines · Will Deacon

Quoted 1 line · Rajendra Nayak

On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:

Quoted 15 lines

Quoted 11 lines

Quoted 6 lines

Quoted 2 lines

I don't have a 4430SDP, so you might consider touching base with rmk for that one.

So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB)

Any update on this? If it's an issue introduced by architectural changes, I'd really like to bisect it down but I don't have a board.

From the other thread, RMK did manage to get the board booting finally

(uImage related issues, low level debug problem) but with DT only supported build, the audio and DSS was not at same state as before(non-DT build). And then Tony pointed the issues to Peter and Tomy to address it further.

Quoted 2 lines

Russell,
Is above right or I am missing something ?

Will is referring to the 2430 issues I think; the original topic of this thread.

I've not enabled the 4430 again in the build system because I see no point to it - it can't find its rootfs because the device numbering for the MMC/SD cards has reversed itself. Not only does that need the kernel command line changed, but it also needs fixing in the fstab on the SD card rootfs, and quite frankly I really can't be bothered at the moment with this kind of pointless boot breaking churn.

I also continue to be disappointed by the lack of things working on the 4430 - it's been a number of years now and _still_ the on-board LCDs do not work. People have tried to blame that on hardware faults and the like, but they're just being idiotic when they say stuff like that. It

can't be hardware faults when the kernel supplied with the board is able to make them work to the extent that userspace can play back video on all three output devices simultaneously, without hiccup or any imperfection. I don't know whether it's just that the backlight support isn't working or what - because any information on the 4430 seems to be a tightly controlled secret that only a few select people are permitted to know about. As far as I'm concerned, much of the hardware is a black box to me.

And yes, my 4430 has the projector module on it. Never ever seen that work, and no idea how to make it work because there's no information available on the hardware.

It's a bit like the useless 3430LDP - though there's information available there's no way to work out which of the many different designs of 3430LDP the one I have ties up with, and I'm pretty sure that all the published revisions of the circuits for the 3430LDP do not match the version I have here - which means when things go wrong, there's no way for me to look at stuff.

And no, I don't want another Beagle board or Panda board or whatever, I have those (I think I have one of each), and they've never been powered up because they have no ethernet on them, and I have no USB to ethernet still, partly because I don't really do USB here *at* *all*, so I don't know what works well and what doesn't with Linux. Even if I did provide them with a USB ethernet, I doubt they'd be able to boot a kernel via the network.

My experience of USB is hellishly poor - I have an icybox eSATA enclosure which also provides USB. The USB interface on that regularly drops out with errors, timeouts, and even isn't recognised on many occasions. I see slow serial comms with USB serial devices on platforms like the 4430SDP and Dove Cubox - the speed is very much like a 4800baud modem, even though the serial runs at 115200 baud. No, don't even _think_ about blaming the host, because this happens whether it be a Thinkpad, or the USB hosts in a Thecus N2100.

I can believe why this all happens, when you see USB interrupts taking upwards of 3ms to complete:

Longest time: 3247506ns
Longest irq: 24
Longest handler: usb_hcd_irq+0x0/0x68

is it hardly surprising that USB is soo crap? And the above 3ms is just for handling a USB keyboard - what takes 3ms over servicing a USB keyboard? I mean, what crap USB really is when it behaves like that... and is it no wonder I hate the bloody thing.

Quoted 4 lines · Russell King - ARM Linux

I also continue to be disappointed by the lack of things working on the 4430 - it's been a number of years now and _still_ the on-board LCDs do not work. People have tried to blame that on hardware faults and the like, but they're just being idiotic when they say stuff like that. It

Quoted 9 lines

can't be hardware faults when the kernel supplied with the board is able to make them work to the extent that userspace can play back video on all three output devices simultaneously, without hiccup or any imperfection. I don't know whether it's just that the backlight support isn't working or what - because any information on the 4430 seems to be a tightly controlled secret that only a few select people are permitted to know about. As far as I'm concerned, much of the hardware is a black box to me.

On the display related issues, Tomi and Archit have been sorting out issue but am not sure about the current state. If the pre-built binaries video playback works means your hardware seems to be fine.

Quoted 14 lines · Santosh Shilimkar

Quoted 4 lines · Russell King - ARM Linux

I also continue to be disappointed by the lack of things working on the 4430 - it's been a number of years now and _still_ the on-board LCDs do not work. People have tried to blame that on hardware faults and the like, but they're just being idiotic when they say stuff like that. It

Quoted 9 lines

can't be hardware faults when the kernel supplied with the board is able to make them work to the extent that userspace can play back video on all three output devices simultaneously, without hiccup or any imperfection. I don't know whether it's just that the backlight support isn't working or what - because any information on the 4430 seems to be a tightly controlled secret that only a few select people are permitted to know about. As far as I'm concerned, much of the hardware is a black box to me.

Quoted 3 lines

On the display related issues, Tomi and Archit have been sorting out issue but am not sure about the current state. If the pre-built binaries video playback works means your hardware seems to be fine.

Just let me be absolutely crystal clear about this: the on-board LCDs have _never_ worked with a mainline kernel, but they did work with the kernel which originally came with the board with the original 4430 SoC. I can right now put the original 4430 SoC back on the board and boot using the kernel which is still on the SD card and they will work.

Even with the original 4430 SoC and mainline kernels, they have never worked.

I tried it back and forth several times, but even with this, the explanation was always "your hardware must be faulty". And then the wrong voltage levels was found which was preventing the LCD modules from even being recognised... but still, no sign of life on the LCD panels.

It may be that there's some error in the kernel configuration I'm building. I don't know, because I have _no_ idea what hardware is involved in bringing the LCDs online. Like I said above, the 4430SDP board is just a black box. I am totally reliant on others telling me what the right config options are supposed to be and fixing problems when things don't work.

With the lack of information on this board, all I can do when things don't work is whinge and moan at people. I am powerless to debug the problems myself, even if they're a simple misconfiguration.

Is there information available on the 4430SDP? Is there any reason I can't have access to it?

I also continue to be disappointed by the lack of things working on the 4430 - it's been a number of years now and _still_ the on-board LCDs do not work. People have tried to blame that on hardware faults and the like, but they're just being idiotic when they say stuff like that. It

can't be hardware faults when the kernel supplied with the board is able to make them work to the extent that userspace can play back video on all three output devices simultaneously, without hiccup or any imperfection. I don't know whether it's just that the backlight support isn't working or what - because any information on the 4430 seems to be a tightly controlled secret that only a few select people are permitted to know about. As far as I'm concerned, much of the hardware is a black box to me.

And yes, my 4430 has the projector module on it. Never ever seen that work, and no idea how to make it work because there's no information available on the hardware.

And no, I don't want another Beagle board or Panda board or whatever, I have those (I think I have one of each), and they've never been powered up because they have no ethernet on them, and I have no USB to ethernet still, partly because I don't really do USB here *at* *all*, so I don't know what works well and what doesn't with Linux. Even if I did provide them with a USB ethernet, I doubt they'd be able to boot a kernel via the network.

Quoted 4 lines · Russell King - ARM Linux

I also continue to be disappointed by the lack of things working on the 4430 - it's been a number of years now and _still_ the on-board LCDs do not work. People have tried to blame that on hardware faults and the like, but they're just being idiotic when they say stuff like that. It

Quoted 8 lines

can't be hardware faults when the kernel supplied with the board is able to make them work to the extent that userspace can play back video on all three output devices simultaneously, without hiccup or any imperfection. I don't know whether it's just that the backlight support isn't working or what - because any information on the 4430 seems to be a tightly controlled secret that only a few select people are permitted to know about. As far as I'm concerned, much of the hardware is a black box to me.

The 4430SDP's backlight hasn't been working in the mainline due to missing support from the TWL driver. But we finally did get that in for 3.10 (or maybe 3.9), and booting 3.10 non-DT kernel brings up the backlights. However, the BL doesn't work yet with DT boot, so again with 3.11, with no board files, the BL is out... Sigh.

Quoted 15 lines · Tomi Valkeinen

Quoted 12 lines · Russell King - ARM Linux

I also continue to be disappointed by the lack of things working on the 4430 - it's been a number of years now and _still_ the on-board LCDs do not work. People have tried to blame that on hardware faults and the like, but they're just being idiotic when they say stuff like that. It can't be hardware faults when the kernel supplied with the board is able to make them work to the extent that userspace can play back video on all three output devices simultaneously, without hiccup or any imperfection. I don't know whether it's just that the backlight support isn't working or what - because any information on the 4430 seems to be a tightly controlled secret that only a few select people are permitted to know about. As far as I'm concerned, much of the hardware is a black box to me.

Quoted 5 lines

The 4430SDP's backlight hasn't been working in the mainline due to missing support from the TWL driver. But we finally did get that in for 3.10 (or maybe 3.9), and booting 3.10 non-DT kernel brings up the backlights. However, the BL doesn't work yet with DT boot, so again with 3.11, with no board files, the BL is out... Sigh.

Ah, sorry, I take that back. Backlight seems to be working fine with 3.11.

So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB)

[    0.000000] clock: dpll_usb_ck failed transition to 'locked'
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] clock: trace_clk_div_ck: could not find divisor for target rate 0 for parent pmd_trace_clk_mux_ck
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)

[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] clock: dpll_per_m7x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m6x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m5x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m4x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck

Quoted 4 lines

- Paul

Hi Rajendra,

Quoted 3 lines · Rajendra Nayak

So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB)

Could you please send patches to fix these problems, or ensure that someone else from TI fixes them? Let's see if we can deal with the remaining bootloader dependencies here.

thanks

- Paul

Quoted 55 lines

[    0.000000] clock: dpll_usb_ck failed transition to 'locked'
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] clock: trace_clk_div_ck: could not find divisor for target rate 0 for parent pmd_trace_clk_mux_ck
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)

Quoted 14 lines

[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] clock: dpll_per_m7x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m6x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m5x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m4x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck

Quoted 4 lines

- Paul

- Paul

Quoted 8 lines · Paul Walmsley

Hi Rajendra,

Quoted 3 lines · Rajendra Nayak

So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB)

Quoted 3 lines

Could you please send patches to fix these problems, or ensure that someone else from TI fixes them? Let's see if we can deal with the remaining bootloader dependencies here.

Sure Paul, I'll take a look at this.

Quoted 80 lines

thanks

- Paul

Quoted 55 lines

[    0.000000] clock: dpll_usb_ck failed transition to 'locked'
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] clock: trace_clk_div_ck: could not find divisor for target rate 0 for parent pmd_trace_clk_mux_ck
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)

Quoted 14 lines

[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] clock: dpll_per_m7x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m6x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m5x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m4x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck

Quoted 4 lines

- Paul

- Paul

Hi,

After Linus's commit fb2af0020a51709ad87ea8055c325d3fbde04158 ("Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm"), the OMAP2430 SDP here stopped booting.

Here's the bootlog at the commit before the merge, commit 790eac5640:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722015454/

and here's a log at commit fb2af0020a5:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722005921/

Any ideas as to what might have caused this?

I've just had a quick go at booting 3.11-rc2 on an integrator-cp (1136) in the hope that we might be able to reproduce this on those boards, but I'm afraid the integrator works...

I took your config, modified it as little as possible to switch to Integrator and turn on earlyprintk, and then tried to boot. That *did* require switching away from ARCH_MULTIPLATFORM, so it isn't as similar as I'd like, though...

So I think we can at least say that this is not 1136 specific... Sorry not to be more helpful...