[PATCH 8/15] bootwrapper: convert flatdevtree to version 16
david at gibson.dropbear.id.au
Fri Sep 28 12:40:52 EST 2007
On Thu, Sep 27, 2007 at 10:44:27AM -0500, Milton Miller wrote:
> On Sep 26, 2007, at 9:45 PM, David Gibson wrote:
> >> What's your souce for saying the were supposed to be backwards
> >> compatable? That dtc fills out the struct header so?
> > Sitting next to BenH and knowing he always intended them to be so.
> >> My source is my involvment when v2 was defined (they were discovered
> >> while writing my device tree generation code):
> >> The actual binary structure is compatable, just not the contents of
> >> the
> >> properties nor how any slave cpus wait (for some trees it doesn't
> >> matter).
> >> http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools-
> >> testing.git;a=blob;f=kexec/arch/ppc64/fs2dt.c;
> >> hb=b84b87747a16f0afbef6f6802bb794a94f4961d9
> > An old version of fs2dt is hardly definitive. It could just be Plain
> > Wrong, nothing to do with the dt version.
> 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, and I doubt current kernels will correctly deal
with v1 trees in this form.
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. 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
measure while kexec-tools itself is fixed to produce v17 trees (say,
by replacing fs2dt with dtc plus a libfdt based post-processing
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
More information about the Linuxppc-dev