On Thu, 2013-12-05 at 18:42 +0100, Marc Kleine-Budde wrote: > On 12/05/2013 06:01 PM, Ian Campbell wrote: > > On Thu, 2013-12-05 at 13:39 +0100, Marc Kleine-Budde wrote: > >> On 12/05/2013 01:15 PM, Ian Campbell wrote: > >>> On Thu, 2013-12-05 at 13:04 +0100, Marc Kleine-Budde wrote: > >>>> On 12/05/2013 12:57 PM, Ian Campbell wrote: > >>>>> On Thu, 2013-12-05 at 12:46 +0100, Marc Kleine-Budde wrote: > >>>>>> On 12/05/2013 12:34 PM, Martin Michlmayr wrote: > >>>>>>> * Marc Kleine-Budde <m...@blackshift.org> [2013-12-05 11:49]: > >>>>>>>> That's no option, as non DT Sheeva Plug support has been removed from > >>>>>>>> the kernel in ffbc50663b69462adc9d97b93b6b92c4fe74b94c: > >>>>>>>> > >>>>>>>> ffbc506 ARM: kirkwood: remove support for legacy booting of > >>>>>>>> Sheevaplug > >>>>>>> > >>>>>>> Interesting. I thought they promised not to remove non-DT support for > >>>>>>> existing devices. > >>>>>> > >>>>>> I personally don't mind, if it's removed once the DT works properly. > >>>>>> > >>>>>>> Anyway, Marc, so thanks for your patch. I wonder if it makes sense to > >>>>>>> add a check to flash-kernel whether DT is required or not. i.e. that > >>>>>>> flash-kernel would append the DT blob on 3.12+ kernels on SheevaPlug > >>>>>>> but not on previous kernels. > >>>>>> > >>>>>> Yes, sounds like the way to go. Otherwise you have to tie certain > >>>>>> flash-kernel versions to the non-DT and DT kernels. This will probably > >>>>>> not scale when more no-DT board are removed from the kernel. > >>>>>> > >>>>>> Where should this information go? What about adding another field to > >>>>>> all.db which limits an entry to certain kernel versions? Something like > >>>>>> this: > >>>>> > >>>>> I think it would be sufficient to have a field marking the DTB as > >>>>> optional and have f-k only do the append if there is a dtb present in > >>>>> the DTS directory (/usr/lib/linux-X.Y/whatever) for the version it is > >>>>> handling. If the kernel needs a DTB but doesn't ship one, well ,that's a > >>>>> bug in the kernel (until we get to the point of burning DTBs into > >>>>> firmware, but lets not worry about that now!). > >>>> > >>>> ...or when the DT sources will be move into a separate repository. > >>> > >>> Indeed. > >>> > >>> Actually, now that I think about it -- a non-DT aware kernel just > >>> shouldn't care if you append a DT to it, it won't ever go looking. It's > >>> probably safe to just append it unconditionally. > >> > >> Yes, should be safe. > >> > >>> Which is what you did, so we've come full circle, sorry for the > >>> distraction. > >> > >> It's good to talk about the implications. If we want to handle > >> downgrading of kernels with an updated flash-kernel, I think, that > >> cannot be done without an additional Kernel-Version field. > >> > >> This is because v3.11 ships with: > >> > >> /usr/lib/linux-image-3.11-2-kirkwood/kirkwood-sheevaplug.dtb > >> > >> But non-DT Sheeva support is still in the kernel, so non-DT Sheeva Plug > >> is used with current flash-kernel and v3.11. Although v3.10 and v3.11 > >> are not Wheezy's kernels. > > > > Is 3.11+DTB actively broken though? > > v3.11+DT works on Sheeva Plug, just tested it.
That's good. Do you know if v3.10 or earlier shipped a DT in the kernel package? > I was thinking of the following scenario: > > I have installed current flash-kernel (without DT support) and kernel > v3.11. Then the new flash-kernel with > append-DT-if-present-in-the-Kernel-package feature is released together > with a new DT only kernel (=v3.12). I upgrade, because I want to have > the shiny new kernel. > > For whatever reason I want to downgrade to v3.11, then I end up with > v3.11 with DT, because the flash-kernel is still the new one. Right, this is the scenario I am worried about. > The system does not behave as I expected. I downgraded to the same > kernel but now the DT Sheeva Plug is booted. Ideally v3.11+DT would work well enough that the user wouldn't care about the difference. even if not I think so long as v3.11+DT works well enough to be able to manually fix things (e.g. by downgrading f-k) then this would be an acceptable trade-off to support such partial upgrades. > Although the bootloader sets the ARCH number, an attached DT seems to be > preferred. That is what I would expect, yes. > >>> I suppose it would be nice to just check that the Wheezy kernel doesn't > >>> complain about or get confused by the appended DTB. Can you check that? > >> > >> I don't have physical access to that Sheeva Plug. > > > > Hrm, this would be something which would be good to try somewhere. > > On Wheezy there is no Sheevaplug DTB to attach... Oh yes, of course. > > Now I think of it the Wheezy kirkwood kernel did have DT and > > APPENDED_DTB support enabled, in order to support dreamplugs. > > http://packages.debian.org/wheezy/armel/linux-image-3.2.0-4-kirkwood/filelist > > Wheezy has two dtb files: > > /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-dreamplug.dtb > /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-iconnect.dtb > > > I have a feeling that would mean that it wouldn't boot if you appended a > > dtb to it. Which would mean we do have to think about versioned checks > > or something. > > Just stating the obvious: The Sheeva Plug probably wouldn't boot if I > attach a dreamplug dtb to it. :) Right, I was thinking/worrying that it won't boot if you attach any DTB to it, including a newer one for the shivaplug. But of course f-k wouldn't ever do that. So the only concern is intermediate kernel versions which have a DT file but prefer non-DT operation. As I say I think so long as it boots well enough to allow repair then this is ok. Do shivaplugs typically provide u-boot console access as standard or does that require soldering and/or cracking the case open? Ian.
signature.asc
Description: This is a digitally signed message part
