Adding DTB to architecture independent vmlinux

Hi All,

I am working on working on adding support device tree support to an x86 based platform, hpa pointed out that the device tree blob is architecture independent and should be part of the generic kernel.

The patch below is a first cut at adding dtb support to the architecture independent kernel and adding a generic dts->dtb build rule.

This has only been tested on x86.

Comments/suggestions gratefully accepted.

--Dirk

of: add support for linking platform dtb into vmlinux

From: Dirk Brandewie <[email protected]>

This patch adds support for linking a device tree blob into vmlinux. The platform DTB to be built and linked into the kernel is specified by passing PLATFORM_DTB=<platform name> to make.

The command:
make PLATFORM_DTB=ce4100

will link the device tree blob into vmlinux

Signed-off-by Dirk Brandewie <[email protected]>

---
 arch/powerpc/boot/zImage.coff.lds.S |    5 ++---
 arch/powerpc/boot/zImage.lds.S      |    5 ++---
 arch/powerpc/boot/zImage.ps3.lds.S  |    5 ++---
 arch/x86/kernel/Makefile            |   15 +++++++++++++++
 include/asm-generic/vmlinux.lds.h   |   12 ++++++++++++
 scripts/Makefile.lib                |    7 +++++++
 7 files changed, 42 insertions(+), 9 deletions(-)

arch/powerpc/boot/zImage.coff.lds.S +1 -0

index 856dc78..c23145f 100644
@@ -1,3 +1,4 @@
+#include <asm-generic/vmlinux.lds.h>
 OUTPUT_ARCH(powerpc:common)
 ENTRY(_zimage_start_opd)
 EXTERN(_zimage_start_opd)

arch/powerpc/boot/zImage.coff.lds.S +0 -0

     _vmlinux_start =  .;
     *(.kernel:vmlinux.strip)

arch/powerpc/boot/zImage.lds.S +2 -3

index 0962d62..f5b9c56 100644
@@ -1,3 +1,4 @@
+#include <asm-generic/vmlinux.lds.h>
 OUTPUT_ARCH(powerpc:common)
 ENTRY(_zimage_start)
 EXTERN(_zimage_start)

@@ -22,9 +23,7 @@ SECTIONS
   }
 
   . = ALIGN(8);
-  _dtb_start = .;
-  .kernel:dtb : { *(.kernel:dtb) }
-  _dtb_end = .;
+  KERNEL_DTB()
 
   . = ALIGN(4096);
   _vmlinux_start =  .;

arch/powerpc/boot/zImage.ps3.lds.S +2 -3

index aaa469c..246d227 100644
@@ -1,3 +1,4 @@
+#include <asm-generic/vmlinux.lds.h>
 OUTPUT_ARCH(powerpc:common)
 ENTRY(_zimage_start)
 EXTERN(_zimage_start)

@@ -8,9 +9,7 @@ SECTIONS
   _vmlinux_end =  .;
 
   . = ALIGN(4096);
-  _dtb_start = .;
-  .kernel:dtb : { *(.kernel:dtb) }
-  _dtb_end = .;
+  KERNEL_DTB()
 
   . = ALIGN(4096);
   _initrd_start =  .;

arch/x86/kernel/Makefile +5 -0

index 3068e1e..992b3dd 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_X86_OF),y)
+ifneq ($(PLATFORM_DTB),)
+obj-y += $(PLATFORM_DTB).dtb.o
+endif
+endif

arch/x86/kernel/Makefile +0 -0

 ###
 # 64 bit specific files
 ifeq ($(CONFIG_X86_64),y)

include/asm-generic/vmlinux.lds.h +12 -0

index 8a92a17..5729a24 100644
@@ -146,6 +146,14 @@
 #define TRACE_SYSCALLS()
 #endif
 
+#ifdef CONFIG_OF
+#define KERNEL_DTB() _dtb_start = .;	    				\
+		   *(.kernel:dtb)					\
+		   _dtb_end = .;					
+#else
+ KERNEL_DTB()
+#endif
+
 /* .data section */
 #define DATA_DATA							\
 	*(.data)							\

@@ -245,6 +253,10 @@
 		VMLINUX_SYMBOL(__end_pci_fixups_suspend) = .;		\
 	}								\
 									\
+	.dtb : AT(ADDR(.dtb) - LOAD_OFFSET) {				\
+	     KERNEL_DTB()      		    				\
+	}		   						\
+								\
 	/* Built-in firmware blobs */					\
 	.builtin_fw        : AT(ADDR(.builtin_fw) - LOAD_OFFSET) {	\
 		VMLINUX_SYMBOL(__start_builtin_fw) = .;			\

scripts/Makefile.lib +7 -0

index 54fd1b7..ce32644 100644
@@ -207,6 +207,13 @@ quiet_cmd_gzip = GZIP    $@
 cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 > $@) || \
 	(rm -f $@ ; false)
 
+# DTC
+#  ---------------------------------------------------------------------------
+
+DTC = $(objtree)/scripts/dtc/dtc
+
+quiet_cmd_dtc = DTC	$@
+      cmd_dtc = $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 -p 1024 $(dtstree)/$*.dts
 
 # Bzip2
 # ---------------------------------------------------------------------------

_______________________________________________
devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss

Quoted 15 lines · Dirk Brandewie

Hi All,

I am working on working on adding support device tree support to an x86 based platform, hpa pointed out that the device tree blob is architecture independent and should be part of the generic kernel.

The patch below is a first cut at adding dtb support to the architecture independent kernel and adding a generic dts->dtb build rule.

This has only been tested on x86.

Comments/suggestions gratefully accepted.

--Dirk

Quoted 7 lines

of: add support for linking platform dtb into vmlinux

From: Dirk Brandewie<[email protected]>

This patch adds support for linking a device tree blob into vmlinux. The platform DTB to be built and linked into the kernel is specified by passing PLATFORM_DTB=<platform name> to make.

I don't think it is worth trying to do this in a cross-architecture way. The powerpc zImage wrappers are already very platform-specific code, and there are no assumptions made about how a dtb image is linked into the wrapper. A wrapper could even link in multiple dtb images.

For the x86 code, linking the dtb into the vmlinux itself is not something that is desired without the option of selecting it between multiple linked-in dtb files if firmware doesn't pass one in for you. This will require some discussion about how best to manage dtbs before merging a patch like this.

Here is V2 of the patch.

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

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.

How big are these blobs in the typical case? Padding to the page size

-hpa

Quoted 1 line · H. Peter Anvin

How big are these blobs in the typical case? Padding to the page size

You usually pad the dtb by 1kib (-p 1024 in dtc). Converting all dtbs in powerpc's tree leads to:
991545 / 130 = 7627 bytes average.

Quoted 6 lines · Sebastian Andrzej Siewior

Quoted 1 line · H. Peter Anvin

How big are these blobs in the typical case? Padding to the page size

You usually pad the dtb by 1kib (-p 1024 in dtc). Converting all dtbs in powerpc's tree leads to:
991545 / 130 = 7627 bytes average.

So expanding to a page is a lot of memory, but it's pretty important to jettison unused DTBs.

-hpa

Quoted 8 lines · H. Peter Anvin

Quoted 6 lines · Sebastian Andrzej Siewior

Quoted 1 line · H. Peter Anvin

How big are these blobs in the typical case? Padding to the page size

You usually pad the dtb by 1kib (-p 1024 in dtc). Converting all dtbs in powerpc's tree leads to:
991545 / 130 = 7627 bytes average.

Quoted 4 lines

So expanding to a page is a lot of memory, but it's pretty important to jettison unused DTBs.

      -hpa

IIRC, the slab allocator will simply use the buddy allocator when allocating close to or above the page size. So, this will use 8192 bytes whether you use what I had proposed or you dynamically allocate space and copy it from the .init section.

If memory usage is not an issue, it would be nice to avoid the copy. Another possible consideration is image size. If you don't do the rounding, you'll have a smaller boot image. Not really sure how to weigh these and whether there are other considerations.

Quoted 19 lines · David VomLehn

Quoted 8 lines · H. Peter Anvin

Quoted 6 lines · Sebastian Andrzej Siewior

Quoted 1 line · H. Peter Anvin

How big are these blobs in the typical case? Padding to the page size

You usually pad the dtb by 1kib (-p 1024 in dtc). Converting all dtbs in powerpc's tree leads to:
991545 / 130 = 7627 bytes average.

Quoted 4 lines

So expanding to a page is a lot of memory, but it's pretty important to jettison unused DTBs.

      -hpa

IIRC, the slab allocator will simply use the buddy allocator when allocating close to or above the page size. So, this will use 8192 bytes whether you use what I had proposed or you dynamically allocate space and copy it from the .init section.

Quoted 4 lines

If memory usage is not an issue, it would be nice to avoid the copy. Another possible consideration is image size. If you don't do the rounding, you'll have a smaller boot image. Not really sure how to weigh these and whether there are other considerations.

The choice to copy could be made a Kconfig option, but I doubt it is warranted. A one time copy of one or two pages at boot is pretty speedy. I'll let someone with benchmarks results prove me otherwise.

g.

Quoted 2 lines · H. Peter Anvin

How big are these blobs in the typical case? Padding to the page size

You usually pad the dtb by 1kib (-p 1024 in dtc). Converting all dtbs in powerpc's tree leads to:
991545 / 130 = 7627 bytes average.

Quoted 25 lines · David VomLehn

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:

Quoted 3 lines

	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.

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.

-hpa

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.

Quoted 8 lines · David VomLehn

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.

The reason I mentioned dynamic allocation is that you still need to do dynamic allocation if you're using a blob from an external source. If you don't end up with pointers *into* the blob, though, then you don't need to do the relocation until some time before you jettison the init section.

Quoted 10 lines · H. Peter Anvin

Quoted 8 lines · David VomLehn

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.

Quoted 5 lines

The reason I mentioned dynamic allocation is that you still need to do dynamic allocation if you're using a blob from an external source. If you don't end up with pointers *into* the blob, though, then you don't need to do the relocation until some time before you jettison the init section.

The way the dtb format is designed, you should almost never work with pointers into the the middle of the blob.

Quoted 17 lines · David Gibson

Quoted 15 lines · H. Peter Anvin

Quoted 8 lines · David VomLehn

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.

The reason I mentioned dynamic allocation is that you still need to do dynamic allocation if you're using a blob from an external source. If you don't end up with pointers *into* the blob, though, then you don't need to do the relocation until some time before you jettison the init section.

Quoted 2 lines

The way the dtb format is designed, you should almost never work with pointers into the the middle of the blob.

"Almost never"? That scares me when I hear it...

Quoted 30 lines · H. Peter Anvin

Quoted 28 lines · David VomLehn

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.

Quoted 3 lines

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.

Quoted 4 lines

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.

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.

On 10/27/2010 4:09 AM, Grant Likely wrote:

Quoted 6 lines

I don't think it is worth trying to do this in a cross-architecture way.  The powerpc zImage wrappers are already very platform-specific code, and there are no assumptions made about how a dtb image is linked into the wrapper.  A wrapper could even link in multiple dtb images.

Quoted 6 lines

For the x86 code, linking the dtb into the vmlinux itself is not something that is desired without the option of selecting it between multiple linked-in dtb files if firmware doesn't pass one in for you. This will require some discussion about how best to manage dtbs before merging a patch like this.

I have to disagree, strongly, that it is not worth doing a cross-architectural patch.  There is nothing that prevents an architecture from having any number of different ones *in addition to* the independent way, but that would clearly establish a baseline that everyone can benefit from.  This is a Very Good Thing[TM].  We already have too many gratuitous differences between architectures in Linux.

As far as linking in multiple dtbs, the one architecture-independent way we have to pass data into the kernel is the kernel command line, and it might make sense to have a command line parameter like "dtb=foo",

although I
expect the vast majority of all users who don't rely on the firmware/bootloader to feed them information are going to have one kernel image per platform anyway, just for space reasons.