On 12/06/2013 09:31 AM, Ian Campbell wrote: >>>> 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? There is no DT for Sheeva Plug in Debian's v3.10, but 25 dtb in total. >> 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. Yes works for me. >> 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. In Debian, v3.11 is the first kernel that ships with a Sheeva Plug DT and that works for me. > Do shivaplugs typically provide u-boot console access as standard or > does that require soldering and/or cracking the case open? No, just plug in a Mini USB Cable and you have a serial console (and a JTAG for debricking via openocd). Marc
Attachment:
signature.asc
Description: OpenPGP digital signature