[patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.

[Jimi Xenidis]

ok, to accept (1) means to accept (2).

AFAICT LMB is already handling overlaps.
So the first rough patch I sent should be sufficient.

On Apr 18, 2006, at 2:04 PM, Michael Ellerman wrote:

> On Tue, 2006-04-18 at 11:48 -0500, Jon Loeliger wrote:
>> On Thu, 2006-04-13 at 09:34, Michael Ellerman wrote:
>>> On Thu, 2006-04-13 at 09:19 -0400, Jimi Xenidis wrote:
>>>> Actually, is this even an issue? can the LMB handle repeated
>>>> reservations?
>>>
>>> It can, but we were thinking about adding code to check and warn if
>>> reservations overlap, because it usually indicates a bug. Although
>>> that's probably ok in this case, as long as dtc gets fixed  
>>> eventually.
>>> Another option would be to not warn for identical reservations.
>>
>>>>>>>>> NOTE: that the dtc must also not generate the blob reservation
>>>>>>>>> entry.
>>
>>>>>> looking passed my own world I see:
>>>>>>    - iSeries: not reserving the blob at all
>>>>>
>>>>> That sounds right. I think having the kernel do it is  
>>>>> definitely the
>>>>> right option.
>>
>>
>> OK, I'm back to reading the list and beginning to catch
>> up some here...
>>
>> Let me see if I understand the consensus and direction:
>>
>>     1) DTC should NOT reserve its own blob space in the
>>        memory map, as it does for generated ASM code now,
>>
>>     2) Kernel should reserve the blob space early so as
>>        not to step on itself later,
>>
>>     3a) Kernel LMB handling should be modified to warn
>>         for overlapping LMB reservations,
>>
>> Except that Ben says:
>>
>>     3b) We should make lmb_reserve() of redudant/overlapping
>>         entries become harmless I think. We need to be
>>         backward compatible with earlier blobs that do
>>         contain themselves in the reserve map.
>>
>> I think we should interpret "harmless" to be "warn" and not
>> cause an error at this point in time.
>>
>> I do not think we should have the blob generate its own
>> reservation because it is possible that some post-processing
>> (like U-Boot) can modify and extend it.  Only after that can
>> the blob's true size be determined.  (Sure, it could update
>> on the fly too... but double blah).
>>
>> In all of this, I'm on deck for step 1) above.
>
> Nice summary :)
> I'm up for 3a, we should make redundant/overlapping reserves  
> "harmless",
> by which I mean "not an error", but there should definitely be a  
> warning
> in the dmesg - as it will _usually_ indicate a bug.
>
> cheers
>
> -- 
> Michael Ellerman
> IBM OzLabs
>
> wwweb: http://michael.ellerman.id.au
> phone: +61 2 6212 1183 (tie line 70 21183)
>
> We do not inherit the earth from our ancestors,
> we borrow it from our children. - S.M.A.R.T Person
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev