[PATCH 8/15] bootwrapper: convert flatdevtree to version 16
miltonm at bga.com
Sat Sep 29 01:16:51 EST 2007
On Sep 27, 2007, at 9:40 PM, David Gibson wrote:
> On Thu, Sep 27, 2007 at 10:44:27AM -0500, Milton Miller wrote:
>> On Sep 26, 2007, at 9:45 PM, David Gibson wrote:
>>>> The actual binary structure is compatable, just not the contents of
>>>> properties nor how any slave cpus wait (for some trees it doesn't
>> Sorry, copy and paste error. I was tring to point out this changelog
>> in 2.6.10:
> Hrm, I see, yes that seems conclusive enough. Yuck.
> In which case, I think we should try to forget that v1 ever existed.
> I don't think anyone ever generated v1 trees other than kernels which
> also consumed them,
I believe this to be true, unless you count telling dtc to do so.
> and I doubt current kernels will correctly deal
> with v1 trees in this form.
I'm quite certain of that.
> In any case, this is all rather beside the point. My basic point is
> that this bootwrapper stuff should not attempt to be a general
> backwards compatibility layer for every broken early dt format that
> ever existed.
The only broken format was v1; I was submitting v2 :-). Version 16 was
"... to support a more compact representation, for use by embedded
> In general we should try to make sure nothing ever uses
> <v16 trees. We want, here, to do the minimum we can get away with to
> support the specific v2 trees produced by kexec-tools, as an interim
As I stated, that by itself isn't sufficient for my usage, as I have
other v2 trees I need to deal with, at least until that generator gets
> while kexec-tools itself is fixed to produce v17 trees (say,
> by replacing fs2dt with dtc plus a libfdt based post-processing
If you thought there were complaints trying to require an external
utility to build zImage, just wait until you try to make kexec-tools
not be self-contained. Currently kexec doesn't even use a data
directory, instead it builds the purgatory and other trampoline
binaries into the kexec program. Incorporating the post-processing and
generation using libfdt (with a copy of the library in the source)
could fly, if people don't care about kexec into kernels from 2.6.10 to
2.6.14 when v16 was merged (about 1 year).
Actually, there is another approach: put this converter in kexec's
purgatory or even the kexec program. It can then run conditionally
under command line flags to keep compatibility with the old kernels.
If and when its is decided to only support >=v16 in kexec-tools it can
be removed and we don't have this interim support code in the kernel
forever (I'll handle my other usage out of tree).
More information about the Linuxppc-dev