Skip to contentSkip to conversation

Adding DTB to architecture independent vmlinux

RFC PATCH Superseded [email protected] 3 participants 8 messages Nov 10, 2010 5 messages not in the archive

Subsystems (4)

v3 of 4 Superseded Latest is v4 →

lore
Share & tools
lore
#0 lore raw

v3 cover Adding DTB to architecture independent vmlinux

From: Dirk Brandewie <[email protected]>

These patches add support for linking device tree blob(s) into vmlinux.

The changes since V2:
patch has been split into architecture independent and x86 specific parts.

The DTB's have been moved into the .init.data section.

The DTB's linked into vmlinux is controlled by kernel config variables. Specifying the DTB on the make command line is gone.

Linking multiple DTB's into image is supported. (suggested by David VomLehn and refined with the help of HPA and Grant Likely)

Specific issues I would like feed back on:
Is the padding added on the dtc invocation needed since the paltform code will have to copy the tree out of the init section?

Setting $(dtstree) in the arch specific makefile is required is there a better write the cmd_dtc in Makefile.lib?

Things on the TODO list:
[generic]
Pass DTB name/compatible string on the kernel command line. Add funciton to find "compatible" root node in the set of DTB's linked in.
[x86]
Add function to relocate DTB whose address is passed in via setup_data ala init_rd.

Comments/Suggestions?

Dirk Brandewie (2):
of: Add support for linking device tree blobs into vmlinux x86/of: Support building device tree blob(s) into image.

 arch/x86/Kconfig                  |    6 +++++-
 arch/x86/boot/dts/Kconfig         |    8 ++++++++
 arch/x86/kernel/Makefile          |   11 +++++++++++
 include/asm-generic/vmlinux.lds.h |   12 ++++++++++++
 init/Kconfig                      |    7 +++++++
 scripts/Makefile.lib              |   14 ++++++++++++++
 6 files changed, 57 insertions(+), 1 deletions(-)
 create mode 100644 arch/x86/boot/dts/Kconfig
Signature · 1 line
1.7.2.3

A message that is not in the archive (sent off-list or not yet received): cover.1289411770.git.dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

#2 lore raw
Quoted 3 lines · On 11/10/2010 10:52 AM, [email protected]…

The DTB's have been moved into the .init.data section.

Writeable? (As opposed to .init.rodata)?

-hpa

A message that is not in the archive (sent off-list or not yet received): 4CDAE874.1000707-VuQAYsv1563Yd54FQh9/[email protected]

#4 lore raw
Quoted 7 lines · H. Peter Anvin
Quoted 3 lines · On 11/10/2010 10:52 AM, [email protected]…

The DTB's have been moved into the .init.data section.

Writeable? (As opposed to .init.rodata)?

That is what I remember from the conversation with Grant but I could be mistaken. It is simple enough to move as long as the interested parties agree :-)

--Dirk

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

#6 lore raw
Quoted 11 lines · Dirk Brandewie
Quoted 6 lines · H. Peter Anvin
Quoted 2 lines · On 11/10/2010 10:52 AM, [email protected]…

The DTB's have been moved into the .init.data section.

Writeable? (As opposed to .init.rodata)?

That is what I remember from the conversation with Grant but I could be mistaken. It is simple enough to move as long as the interested parties agree :-)

Obviously. I'd like to see it readonly unless there is an explicit reason not to, of course.

-hpa

A message that is not in the archive (sent off-list or not yet received): 4CDAEA26.6040206-VuQAYsv1563Yd54FQh9/[email protected]

#8 lore raw
Quoted 9 lines · H. Peter Anvin
Quoted 8 lines · Dirk Brandewie
Quoted 6 lines · H. Peter Anvin
Quoted 2 lines · On 11/10/2010 10:52 AM, [email protected]…

The DTB's have been moved into the .init.data section.

Writeable?  (As opposed to .init.rodata)?

Quoted 6 lines
Quoted 3 lines

That is what I remember from the conversation with Grant but I could be mistaken.  It is simple enough to move as long as the interested parties agree :-)

Obviously.  I'd like to see it readonly unless there is an explicit reason not to, of course.

Definitely it should be ro

g.

A message that is not in the archive (sent off-list or not yet received): AANLkTimgLO0vAQiF4uwHkHnz7SHxiq+KD2iUYV_Y8-Fk-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org

#10 lore raw
Quoted 10 lines · Grant Likely
Quoted 9 lines · H. Peter Anvin
Quoted 8 lines · Dirk Brandewie
Quoted 6 lines · H. Peter Anvin
Quoted 2 lines · On 11/10/2010 10:52 AM, [email protected]…

The DTB's have been moved into the .init.data section.

Writeable? (As opposed to .init.rodata)?

Quoted 9 lines
Quoted 6 lines
Quoted 3 lines

That is what I remember from the conversation with Grant but I could be mistaken. It is simple enough to move as long as the interested parties agree :-)

Obviously. I'd like to see it readonly unless there is an explicit reason not to, of course.

Definitely it should be ro

So I am a little confused (no big surprise :-)

objdump -h vmlinux shows in part:
3 .rodata 000d61b8 c1358000 01358000 00359000 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 __init_rodata 00003a90 c1450be0 01450be0 00451be0 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA
13 .init.text 0002b297 c1488000 01488000 00489000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
14 .init.data 0001e5e0 c14b32a0 014b32a0 004b42a0 2**5
CONTENTS, ALLOC, LOAD, DATA

There is no .init.rodata section that I can find.

It seems like correct place to park the DTB with the other init data in .init.data. section by adding the KERNEL_DTB macro to the INIT_DATA macro in vmlinux.lds.h. This picks up the largest number of architectures that use vmlinux.lds.h. INIT_DATA gets picked up by

#define INIT_DATA_SECTION(initsetup_align)				\
	.init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {		\
		INIT_DATA						\
		INIT_SETUP(initsetup_align)				\
		INIT_CALLS						\
		CON_INITCALL						\
		SECURITY_INITCALL					\
		INIT_RAM_FS						\
	}

We could go into the INIT_TEXT macro to get the blobs into a RO section but that seems kind of wrong.

IMHO if someone starts modifying things in .init.data and expect the changes to stick they deserve what they get.

Comments/Suggestions?

--Dirk

#11 lore raw

PATCH 1/3 of: Add support for linking device tree blobs into vmlinux

In reply to a message not in the archive

From: Dirk Brandewie <[email protected]>

This patch adds support for linking device tree blobs into vmlinux. The device tree blobs are placed in the init.data section.

---
 include/asm-generic/vmlinux.lds.h |   12 ++++++++++++
 init/Kconfig                      |    7 +++++++
 scripts/Makefile.lib              |   14 ++++++++++++++
 3 files changed, 33 insertions(+), 0 deletions(-)
include/asm-generic/vmlinux.lds.h +12 -0
index bd69d79..a36dab5 100644
@@ -146,6 +146,17 @@
 #define TRACE_SYSCALLS()
 #endif
 
+#ifdef CONFIG_KERNEL_DTB
+#define KERNEL_DTB							\
+	. = ALIGN(4);							\
+	VMLINUX_SYMBOL(__dtb_start) = .;				\
+	*(.dtb)			      					\
+	VMLINUX_SYMBOL(__dtb_end) = .;
+
+#else
+#define KERNEL_DTB
+#endif
+
 /* .data section */
 #define DATA_DATA							\
 	*(.data)							\
@@ -772,6 +783,7 @@
 		CON_INITCALL						\
 		SECURITY_INITCALL					\
 		INIT_RAM_FS						\
+		KERNEL_DTB						\
 	}
 
 #define BSS_SECTION(sbss_align, bss_align, stop_align)			\
init/Kconfig +7 -0
index 88c1046..fddfc0f 100644
@@ -1083,6 +1083,13 @@ config PCI_QUIRKS
           bugs/quirks. Disable this only if your target machine is
           unaffected by PCI quirks.
 
+config KERNEL_DTB
+       bool "Support linking a device tree blob into vmlinux"
+       default n
+       help
+         This option provides support for adding a device tree blob(s)
+	 directly to vmlinux
+
 config SLUB_DEBUG
 	default y
 	bool "Enable SLUB debugging support" if EMBEDDED
scripts/Makefile.lib +14 -0
index 4c72c11..6481f27 100644
@@ -200,6 +200,20 @@ quiet_cmd_gzip = GZIP    $@
 cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 > $@) || \
 	(rm -f $@ ; false)
 
+# DTC
+#  ---------------------------------------------------------------------------
+$(obj)/%.dtb.S: $(obj)/%.dtb
+	@echo '.section .dtb,"a"' > $@
+	@echo '.global __$(*F)_dtb_begin' >> $@
+	@echo '__$(*F)_dtb_begin:' >> $@
+	@echo '.incbin "$<" ' >> $@
+	@echo '.global __$(*F)_dtb_end' >> $@
+	@echo '__$(*F)_dtb_end:' >> $@
+
+DTC = $(objtree)/scripts/dtc/dtc
+
+quiet_cmd_dtc = DTC	$@
+      cmd_dtc = $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 -p 1024 $(dtstree)/$*.dts
 
 # Bzip2
 # ---------------------------------------------------------------------------
Signature · 1 line
1.7.2.3
#12 lore raw

PATCH 2/3 x86/of: Support building device tree blob(s) into image.

In reply to a message not in the archive

From: Dirk Brandewie <[email protected]>

This patch adds support for linking device tree blobs into vmlinux. The blobs linked into the image is controlled via kernel config variables

---
 arch/x86/Kconfig          |    6 +++++-
 arch/x86/boot/dts/Kconfig |    8 ++++++++
 arch/x86/kernel/Makefile  |   11 +++++++++++
 3 files changed, 24 insertions(+), 1 deletions(-)
 create mode 100644 arch/x86/boot/dts/Kconfig
arch/x86/Kconfig +5 -1
index 5904f38..62c195d 100644
@@ -299,13 +299,17 @@ config X86_BIGSMP
 	---help---
 	  This option is needed for the systems that have more than 8 CPUs
 
-config X86_OF
+menuconfig X86_OF
 	bool "Support for device tree"
 	select OF
 	select OF_FLATTREE
 	---help---
 	  Device tree support on X86.
 
+if X86_OF
+source "arch/x86/boot/dts/Kconfig
+endif
+
 if X86_32
 config X86_EXTENDED_PLATFORM
 	bool "Support for extended (non-PC) x86 platforms"
arch/x86/boot/dts/Kconfig new file +8 -0
new file mode 100644
index 0000000..5380b6b
@@ -0,0 +1,8 @@
+config CE4100_DTB
+       bool "Intel CE4100"
+       depends on X86_OF && KERNEL_DTB
+
+config TEST_DTB
+       bool "Test DTS"
+       depends on  X86_OF && KERNEL_DTB
+
arch/x86/kernel/Makefile +11 -0
index 586df14..cf15e8c 100644
@@ -113,6 +113,17 @@ 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)
+obj-$(CONFIG_CE4100_DTB) += ce4100.dtb.o
+obj-$(CONFIG_TEST_DTB) += test.dtb.o
+endif
+
+dtstree	:= $(srctree)/arch/x86/boot/dts
+
+$(obj)/%.dtb: $(dtstree)/%.dts
+	$(call if_changed,dtc)
+
+
 ###
 # 64 bit specific files
 ifeq ($(CONFIG_X86_64),y)
Signature · 1 line
1.7.2.3