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

[Jon Loeliger]

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.

jdl