On Mon, 2014-02-24 at 16:03 +0000, Ian Campbell wrote: > On Fri, 2014-02-21 at 02:00 +0000, Ben Hutchings wrote: > > On Thu, 2014-02-20 at 14:24 +0000, Ian Campbell wrote: > > > On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote: > > [...] > > > > What i suspect we will end up doing it dropping the last patch for the > > > > moment and ensuring ARCH_KIRKWOOD still supports all the DT machines. > > > > I think that just needs care with arch/arm/boot/dts/Makefile. > > > > > > > > Once we have the last four converted over to DT, you can then do a > > > > straight swap, mach-kirkwood for mach-mvebu. > > > > > > That sounds like a good plan, thanks! > > > > > > If we are going to do a straight swap I suppose it might as go for a v5 > > > multiplatform flavour instead of a mvebu specific one. > > [...] > > > > I would love it if we could do that. > > > > By the way, we still have the problem that at least one supported > > orion5x machine (D-Link DNS-323) only has a ~1.5 MB kernel partition. > > So we would probably have to keep a reduced orion5x config for those > > machines, alongside the mvebu or multiplatform kernel. > > Sure. I think at worst we should aim to end up with as many flavour as > we have today, in reality I expect we should be able to end up with > fewer (even if only -= 1). > > BTW, someone (I forget who) at Debconf in Cambridge last year floated > the idea of putting a stage 2 loader in flash to pull the real kernel > from some larger storage. I don't know if that is realistic here, and in > any case I don't intend to work on it myself.
I do remember that, and I like it. But in order to rely on this, I think we would need to provide a mostly automatic and safe upgrade path in Debian. Unless someone is prepared to spend the (possibly substantial) effort to do that, we're stuck with that limitation. Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth
signature.asc
Description: This is a digitally signed message part
