[RFC] [PATCH V2] Adding DTB to architecture independent vmlinux

[Grant Likely]

On Thu, Oct 28, 2010 at 1:32 PM, David VomLehn <dvomlehn at cisco.com> wrote:
> On Thu, Oct 28, 2010 at 08:18:25AM -0700, H. Peter Anvin wrote:
>> On 10/27/2010 5:57 PM, David VomLehn wrote:
>>>
>>> I've been playing a bit with the patch, and would suggest something
>>> like the following for the second target:
>>>
>>>      $(obj)/%.dtb.S: $(obj)/%.dtb
>>>              @echo '#include<asm/page.h>'>$@
>>>              @echo '.balign PAGE_SIZE'>>  $@
>>>              @echo '.section .kernel:dtb,"a"'>>  $@
>>>              @echo '.global __$(*F)_dtb'>>  $@
>>>              @echo '__$(*F)_dtb:'>>  $@
>>>              @echo '.incbin "$<" '>>  $@
>>>              @echo '.balign PAGE_SIZE'>>  $@
>>>
>>> Advantages:
>>> 1.   Each blob gets a name that can be used to refer to it. This
>>>      allows multiple blobs to be built into a kernel, each with
>>>      its own name.  The name of each blob is taken from the file
>>>      name, so a source
>>>      file abc.dts would produce a blob referred to as __abc_dtb.
>>> 2.   Blobs are aligned on a page boundary and extend to the nearest
>>>      page boundary. Any blobs you don't care about can then easily
>>>      be completely freed.
>>>
>>> You might then use:
>>>
>>>      obj-y += $(addprefix .dtb.o,$(PLATFORM_DTB))
>>>
>>> to add blob names, but I'm not completely confident this is the way to go.
>>
>> To be able to specify "dtb=<name>" on the command line, you want the
>> name to be manifest in string form, rather than as a symbol.  That means
>> putting a header or something similar in front of the blobs.
>
> Could you not iterate over the blobs and use the "compatible" property to
> match the string? It would seem to me that this would be the right thing
> to do in any case since it would then follow the standard method for
> interpreting that property.

Hmmm, I had mistakenly thought that dtb=<blah> was proposed to pass in
the address of a blob already loaded into memory (perhaps by grub),
but I understand now.  Yes, it could be performed by name.  However,
David's suggestion of passing in a compatible string better matches
existing conventions.

>> How big are these blobs in the typical case?  Padding to the page size
>> could easily add more waste than it saves.  In that case it probably
>> would be better to put the stuff in the init area and copy the active
>> blob to an allocated location.

4-8k typically.  They could also be compressed, but that doesn't gain
a whole lot and it would complicate the process of scanning the
compatible values as suggested above.

> In my case, where there are a lot of up-front reservations of memory
> at a static address, there is a fair amount of work to do before
> it's possible to do the dynamic address allocation for the blob's
> ultimate destination, but I'm okay with either doing blob size and address
> rounding or copying it from init. I don't see a benefit of supporting
> multiple approaches for Linux.

It is already possible to do allocation early allocation in both
powerpc and arm.  Also, blob relocation can be deferred until later in
boot if need be.  The flat tree can be accessed before relocating it.
Just as long as it is done so before unflattening the tree (possibly
as part of).

Regardless, Peter is absolutely right; the linked in .dtbs definitely
must be in an init section so they can be discarded after copy.

g.