Skip to contentSkip to conversation

Adding DTB to architecture independent vmlinux

RFC PATCH Dirk Brandewie 2 participants 4 messages Oct 28, 2010 – Nov 10, 2010 1 message not in the archive

lore
Share & tools
lore

Dirk Brandewie

author
#0 lore raw

Hi David,

Thanks for looking at the patch.

Quoted 39 lines · David VomLehn
Quoted 1 line · Dirk Brandewie

Here is V2 of the patch.

...

Quoted 13 lines
arch/x86/kernel/Makefile +5 -0
index 3068e1e..0f5eb1d 100644
@@ -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

arch/x86/kernel/Makefile obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o · line 137

Quoted 10 lines
arch/x86/kernel/Makefile +10 -0
+
+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'>>  $@
Quoted 10 lines

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.

Quoted 5 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 1 line · Dirk Brandewie

On 10/27/2010 05:57 PM, David VomLehn wrote:

[...]

Quoted 11 lines
Quoted 5 lines

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.

Take a look at the arch/powerpc/boot/Makefile where multiple images are produced depending on the build target. There are cuImage.% targets which link in a different .dtb file based on the % part of the target. That allows images for multiple machines to be build from a single config, rather than depending on a magic setting in the .config file.

g.

#3 lore raw
In reply to a message not in the archive
Quoted 59 lines · Dirk Brandewie

Hi David,

Thanks for looking at the patch.

Quoted 43 lines · David VomLehn
Quoted 2 lines · Dirk Brandewie

Here is V2 of the patch.

...

Quoted 14 lines
arch/x86/kernel/Makefile +0 -0
index 3068e1e..0f5eb1d 100644
@@ -120,6 +120,21 @@ obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o

 obj-$(CONFIG_SWIOTLB)                 += pci-swiotlb.o obj-$(CONFIG_X86_OF)                  += prom.o

arch/x86/kernel/Makefile +5 -0
+ifeq ($(CONFIG_KERNEL_DTB),y)
+ifneq ($(PLATFORM_DTB),)
+obj-y += $(PLATFORM_DTB).dtb.o
+endif
+endif

arch/x86/kernel/Makefile

Quoted 10 lines
arch/x86/kernel/Makefile +10 -0
+
+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'>>  $@

Quoted 10 lines

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.

Quoted 5 lines

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.

Quoted 6 lines

 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.

#4 lore raw
In reply to a message not in the archive

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.

Quoted 95 lines · Dirk Brandewie

Hi David,

Thanks for looking at the patch.

Quoted 43 lines · David VomLehn
Quoted 2 lines · Dirk Brandewie

Here is V2 of the patch.

...

Quoted 14 lines
arch/x86/kernel/Makefile +0 -0
index 3068e1e..0f5eb1d 100644
@@ -120,6 +120,21 @@ obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o

 obj-$(CONFIG_SWIOTLB)                 += pci-swiotlb.o obj-$(CONFIG_X86_OF)                  += prom.o

arch/x86/kernel/Makefile +5 -0
+ifeq ($(CONFIG_KERNEL_DTB),y)
+ifneq ($(PLATFORM_DTB),)
+obj-y += $(PLATFORM_DTB).dtb.o
+endif
+endif

arch/x86/kernel/Makefile

Quoted 10 lines
arch/x86/kernel/Makefile +10 -0
+
+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'>>  $@

Quoted 10 lines

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.

Quoted 5 lines

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-uLR06cmDAlY/[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss

Signature · 2 lines
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.