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

[Grant Likely]

On Thu, Oct 28, 2010 at 11: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.

It is quite common.  ARM currently supports this.

>  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.

This is the bit that is architecture specific.  In arm and in powerpc,
each platform or each platform family is recorded in the machine_desc
table (the structure of the entries is completely different for each
arch).  Does x86 have any such mechanism for differentiating between
machines?

g.