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

Grant Likely grant.likely at secretlab.ca
Wed Nov 10 17:03:01 EST 2010


Hi Dirk,

As promised when we talked at plumbers, here is a method that you can
use to bind multiple .dtbs into the kernel and to have symbols
pointing to the beginning of each of them.

Take a look at arch/arm/boot/compressed/piggy.*.S

You'll see this:

        .section .piggydata,#alloc
        .globl  input_data
input_data:
        .incbin "arch/arm/boot/compressed/piggy.gzip"
        .globl  input_data_end
input_data_end:


Which is used to link in a raw binary (compressed vmlinux) and
reference it with the input_data label.

A similar thing could be used for .dtbs with some script and
makefile-fu.  If you added targets for .dts--->.dtb and .dtb-->.S,
where the .dtb-->.S target generates a .S file that looks something
like this:

        .section .init.dtbdata
        .globl dtb_init_<dtb-filename>
dtb_init_<dtb-filename>:
        .incbin "<full-path-to-dtb-filename>"

Then you'd need to add pre and post linker sections with labels that
wraps the entire region of dtbs so that can be found & parsed, and so
that they can be freed.  The individual .dtbs can then be referenced
using the dtb_init_<dtb-filename> symbol.

Make sense?

g.


On Thu, Oct 28, 2010 at 9:26 AM, Dirk Brandewie
<dirk.brandewie at gmail.com> wrote:
> Hi David,
>
> Thanks for looking at the patch.
>
> On 10/27/2010 05:57 PM, David VomLehn wrote:
>>
>> On Wed, Oct 27, 2010 at 05:30:27PM -0700, Dirk Brandewie wrote:
>>>
>>> Here is V2 of the patch.
>>
>> ...
>>>
>>> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
>>> index 3068e1e..0f5eb1d 100644
>>> --- a/arch/x86/kernel/Makefile
>>> +++ b/arch/x86/kernel/Makefile
>>> @@ -120,6 +120,21 @@ obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o
>>>  obj-$(CONFIG_SWIOTLB)                 += pci-swiotlb.o
>>>  obj-$(CONFIG_X86_OF)                  += prom.o
>>>
>>> +ifeq ($(CONFIG_KERNEL_DTB),y)
>>> +ifneq ($(PLATFORM_DTB),)
>>> +obj-y += $(PLATFORM_DTB).dtb.o
>>> +endif
>>> +endif
>>> +
>>> +dtstree        := $(srctree)/arch/x86/boot/dts
>>> +
>>> +$(obj)/%.dtb: $(dtstree)/%.dts
>>> +       $(call if_changed,dtc)
>>> +
>>> +$(obj)/%.dtb.S: $(obj)/%.dtb
>>> +       @echo '.section .dtb,"a"'>  $@
>>> +       @echo '.incbin "$<" '>>  $@
>>> +
>>
>> 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.
>>
>
> I like this idea in general but I have to admit I don't completely
> understand
> all the implications of adding multiple blobs.  I can see a use case where a
> vendor would want to make a single static image that supported multiple
> platforms.  I am not sure how common this would be.  One issue I see with
> linking multiple DTB's into the image is now the platform init code is back
> to
> trying to detect which hardware it is running on to select the correct blob
> to
> get its configuration from.
>
> As part of the complete DTB story on x86 I am adding the ability to pass the
> DTB
> in from the boot loader.  I think this mechanism would be the more common
> case
> for supporting multiple platforms with a single vmlinux image.
>
>
>> 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.
>
> I am still trying to settle on the right way to specify the DTB to be linked
> in
> that won't generate a lot of hate from the build/distribution people where
> they
> are supporting multiple platforms with/without the need of the DTB.
>
> --Dirk
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.


More information about the devicetree-discuss mailing list