Hi, On Fri, Oct 02, 2015 at 11:07:35AM +0100, Julien Grall wrote: > Hi Maxime, > > On 01/10/15 21:45, Maxime Ripard wrote: > > On Thu, Oct 01, 2015 at 09:47:11AM +0100, Ian Campbell wrote: > >> Booting a recent kernel with the DTB supplied with Debian Jessie (3.16 > >> based) breaks on Cubietruck because that DTB lacks the clock-indices nodes > >> which the new driver from the commit below adds (replacing the hardcoding > >> which used to be in clk-sunxi.c). > >> > >> It is panicing in drivers/clocksource/timer-sun5i.c with: > >> > >> [ 0.015413] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns > >> [ 0.025049] Kernel panic - not syncing: Can't get timer clock > >> [ 0.030794] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.3.0-rc2-arm-native+ #6 > >> [ 0.038002] Hardware name: Allwinner sun7i (A20) Family > >> [ 0.043253] [<c0219794>] (unwind_backtrace) from [<c0214e44>] (show_stack+0x10/0x14) > >> [ 0.050992] [<c0214e44>] (show_stack) from [<c048159c>] (dump_stack+0x88/0x98) > >> [ 0.058213] [<c048159c>] (dump_stack) from [<c02caa98>] (panic+0xa4/0x22c) > >> [ 0.065090] [<c02caa98>] (panic) from [<c0d7c518>] (sun5i_timer_init+0x80/0x384) > >> [ 0.072482] [<c0d7c518>] (sun5i_timer_init) from [<c0d7aad0>] (clocksource_of_init+0x4c/0x8c) > >> [ 0.081001] [<c0d7aad0>] (clocksource_of_init) from [<c0d39b48>] (start_kernel+0x28c/0x3c4) > >> [ 0.089343] [<c0d39b48>] (start_kernel) from [<4020807c>] (0x4020807c) > >> [ 0.095866] ---[ end Kernel panic - not syncing: Can't get timer clock > >> > >> Reverting ee38b2698ae2 fixes this specific issue for me (it boots further, > >> but there seems to be other problems later when earlycon hands over to > >> proper console, which I've not yet looked into). > >> > >> Is this considered acceptable linkage between the kernel and the dtbs? > >> > >> I suspect that even if anyone does care this is going to be an uphill > >> struggle for that minority so I'm going to adjust our test infrastructure > >> to pickup the dtbs from the kernel it is trying to test rather then reusing > >> the one from the OS install. > > > > It's never been something we supported (or even claim to support), so > > it's actually surprising that it's the only commit that need to be > > reverted, but yeah, you should keep your DTB in sync. > > I would have though the bindings are stable, i.e the compatibility with > old DT would have been kept in newer kernel. > > So is it something specific to cubietruck? Nope. All the platforms I've been using on a regular basis do not guarantee this. Allwinner, obviously, but also: Atmel: * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Atmel/README#n110 OMAP: * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8b9a2810b02e3d9806ba2bf307c8e8dcedaf902d Berlin: * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fd26031ba6356d2b0f7aa214ebff4b12736b6529 Rockchip: * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=26ab69cb4c1f77060bece483f2ec210163867782 etc... > If no, that's very unfortunate because it means that you can't > re-use the same DT across multiple OS and the DT provided by the > firmware (if it's built-in). Is there such OS yet (and by that, I mean one that actually shares our DT, instead of rewriting its own) ? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
