Re: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16

[Milton Miller <miltonm@bga.com>]

On Sep 26, 2007, at 9:45 PM, David Gibson wrote:

> On Wed, Sep 26, 2007 at 11:19:47AM -0500, Milton Miller wrote:
>> On Sep 24, 2007, at 10:46 PM, David Gibson wrote:
>>> On Mon, Sep 24, 2007 at 01:54:32AM -0500, Milton Miller wrote:
>>>> On Sep 23, 2007, at 10:36 PM, David Gibson wrote:
>>>>> On Fri, Sep 21, 2007 at 06:05:06PM -0500, Milton Miller wrote:
>>> [snip]
>>>>>> +#define MIN_VERSION 2
>>>>>> +#define OUT_VERSION 16z


>>>> Actually the v1 trees has
>>>> some other differences such as initrd addresses were kernel linear  
>>>> not
>>>> real, cpus were assigned logical numbers  ... so while the structure
>>>> didn't change except for the header field, the contents did.
>>>
>>> !? what's your source for this.  v2 and v3 were absolutely supposed  
>>> to
>>> be backwards compatible with v1 which would not be the case with
>>> silent semantic changes such as this.
>>
>> 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:

http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git; 
a=commitdiff;h=e1b47549d1588ccea1fa5726eb430aae4e80f8ed


>
>> And some more changes just before that:
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;
>> a=history;f=arch/ppc64/kernel/prom_init.c;
>> h=e570799a84cc5328e9f0fd44592cb0b828d8c13a;
>> hb=4ae24c4e8a8f68950a7774ca1cdfe69bfe4e2ffc
>
> I don't know what bit you're referring to in that batch of commits.

The following properties changed semantics and no heuristics are  
employed to check for the old vs new:
(1) tces changed from virtual to real
(2) cpus spin on physical (hw id) not logical (0-n)

Other changes in that series
(3) 0->klimit is not a memreserve in the tree (we now allow overlapping  
reserves, but not at the time)
(4) rtas properties are in a different location (but both could exist)

>
>> So its mostly when the kernel generated and required v1 trees, it was
>> ppc64 only and had these other content and handoff semantics.  If it
>> were to get a v1 tree, it only copes for the boot cpu determination
>> I'm not aware of any code other than the kernel that would actually
>> generate a v1 tree (other than dtc, which always supporteed v2, and
>> doesn't care about these differences).

So trying to boot 2.6.9 (2004-10-18 cutoff) kernel from a tree for  
2.6.10 would fail, and vice versa.  But a 2.6.10 kernel can boot a v1  
tree with properties, memreserves, and cpu ids that it expects, getting  
the boot-cpuid from the extra property in the tree.

Is that compatible?  If you only are talking about parsing the tree it  
is.

milton