Run-time configuration of U-Boot via a flat device tree (fdt)

This new option allows U-Boot to embed a binary device tree into its image to allow run-time control of peripherals. This device tree is for U-Boot's own use and is not necessarily the same one as is passed to the kernel.

The device tree compiler output should be placed in the $(obj) rooted tree. Since $(OBJCOPY) insists on adding the path to the generated symbol names, to ensure consistency it should be invoked from the directory where the .dtb file is located and given the input file name without the path.

This commit contains my entry for the ugliest Makefile / shell interaction competition.

Signed-off-by Simon Glass<[email protected]>

---

doc/README.fdt-control new file +31 -0

+Device Tree Control in U-Boot
+=============================
+
+This feature provides for run-time configuration of U-Boot via a flat
+device tree (fdt). U-Boot configuration has traditionally been done
+using CONFIG options in the board config file. This feature aims to
+make it possible for a single U-Boot binary to support multiple boards,
+with the exact configuration of each board controlled by a flat device
+tree (fdt). This is the approach recently taken by the ARM Linux kernel
+and has been used by PowerPC for some time.
+
+The fdt is a convenient vehicle for implementing run-time configuration
+for three reasons. Firstly it is easy to use, being a simple text file.
+It is extensible since it consists of nodes and properties in a nice
+hierarchical format.
+
+Finally, there is already excellent infrastructure for the fdt: a
+compiler checks the text file and converts it to a compact binary
+format, and a library is already available in U-Boot (libfdt) for
+handling this format.
+
+The dts directory contains a Makefile for building the device tree blob
+and embedding it in your U-Boot image. This is useful since it allows
+U-Boot to configure itself according to what it finds there. If you have
+a number of similar boards with different peripherals, you can describe
+the features of each board in the device tree file, and have a single
+generic source base.
+
+To enable this feature, add CONFIG_OF_CONTROL to your board config file.
+
+

doc/README.fdt-control new file +29 -0

+Where do I get an fdt file for my board?
+----------------------------------------
+
+You may find that the Linux kernel has a suitable file. Look in the
+kernel source in arch/<arch>/boot/dts.
+
+If not you might find other boards with suitable files that you can
+modify to your needs. Look in the board directories for files with a
+.dts extension.
+
+Failing that, you could write one from scratch yourself!
+
+
+Configuration
+-------------
+
+Use:
+
+#define CONFIG_DEFAULT_DEVICE_TREE	"<name>"
+
+to set the filename of the device tree source. Then put your device tree
+file into
+
+	board/<vendor>/dts/<name>.dts
+
+This should include your CPU or SOC's device tree file, placed in
+arch/<arch>/dts, and then make any adjustments required. The name of this
+is CONFIG_ARCH_DEVICE_TREE.dts.
+

Dear Simon,

Quoted 16 lines · Simon Glass

This new option allows U-Boot to embed a binary device tree into its image to allow run-time control of peripherals. This device tree is for U-Boot's own use and is not necessarily the same one as is passed to the kernel.

The device tree compiler output should be placed in the $(obj) rooted tree. Since $(OBJCOPY) insists on adding the path to the generated symbol names, to ensure consistency it should be invoked from the directory where the .dtb file is located and given the input file name without the path.

This commit contains my entry for the ugliest Makefile / shell interaction competition.

Signed-off-by Simon Glass<[email protected]>

---

...

doc/README.fdt-control

Quoted 5 lines

doc/README.fdt-control new file +0 -0

new file mode 100644
index 0000000..3f8bb5a

...

Reading your README.fdt-control and browsing the source code a little for the CONFIG_OF_* options I found two questions. Sorry if I haven't read carefully enough ;)

Quoted 31 lines

doc/README.fdt-control new file +31 -0

+Device Tree Control in U-Boot
+=============================
+
+This feature provides for run-time configuration of U-Boot via a flat
+device tree (fdt). U-Boot configuration has traditionally been done
+using CONFIG options in the board config file. This feature aims to
+make it possible for a single U-Boot binary to support multiple boards,
+with the exact configuration of each board controlled by a flat device
+tree (fdt). This is the approach recently taken by the ARM Linux kernel
+and has been used by PowerPC for some time.
+
+The fdt is a convenient vehicle for implementing run-time configuration
+for three reasons. Firstly it is easy to use, being a simple text file.
+It is extensible since it consists of nodes and properties in a nice
+hierarchical format.
+
+Finally, there is already excellent infrastructure for the fdt: a
+compiler checks the text file and converts it to a compact binary
+format, and a library is already available in U-Boot (libfdt) for
+handling this format.
+
+The dts directory contains a Makefile for building the device tree blob
+and embedding it in your U-Boot image. This is useful since it allows
+U-Boot to configure itself according to what it finds there. If you have
+a number of similar boards with different peripherals, you can describe
+the features of each board in the device tree file, and have a single
+generic source base.
+
+To enable this feature, add CONFIG_OF_CONTROL to your board config file.
+
+

...

Quoted 37 lines

doc/README.fdt-control new file +37 -0

+Where do I get an fdt file for my board?
+----------------------------------------
+
+You may find that the Linux kernel has a suitable file. Look in the
+kernel source in arch/<arch>/boot/dts.
+
+If not you might find other boards with suitable files that you can
+modify to your needs. Look in the board directories for files with a
+.dts extension.
+
+Failing that, you could write one from scratch yourself!
+
+
+Configuration
+-------------
+
+Use:
+
+#define CONFIG_DEFAULT_DEVICE_TREE ? ? "<name>"
+
+to set the filename of the device tree source. Then put your device tree
+file into
+
+ ? ? ? board/<vendor>/dts/<name>.dts
+
+This should include your CPU or SOC's device tree file, placed in
+arch/<arch>/dts, and then make any adjustments required. The name of this
+is CONFIG_ARCH_DEVICE_TREE.dts.
+
+If CONFIG_OF_EMBED is defined, then it will be picked up and built into
+the U-Boot image (including u-boot.bin).
+
+If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
+a u-boot.dtb file alongside u-boot.bin. A common approach is then to
+join the two:
+
+ ? ? ? cat u-boot.bin u-boot.dtb>image.bin

doc/README.fdt-control

Quoted 2 lines

doc/README.fdt-control new file +2 -0

+
+and then flash image.bin onto your board.

1. Above, the README.fdt-control talks about "make it possible for a single U-Boot binary to support multiple boards". Now, if I understood correctly, the 'Configuration' section above describes how to include/append *one* dtb. But wouldn't we need to include *multiple* dtbs to support multiple boards?

2. The section 'Where do I get an fdt file for my board' talks about taking the fdt from the Linux kernel. This is fine. Is U-Boot able to pass the included/appended (OF_EMBED/OF_SEPARATE) dtb to the Linux kernel, then, too? Or is the included/appended dtb only used for the U-Boot configuration? And the one passed to the Linux kernel has to be taken from anywhere else, additionally?

Many thanks and best regards

Dirk

P.S.: Any idea about

http://lists.denx.de/pipermail/u-boot/2012-March/120916.html

?

This locates the device tree either embedded within U-Boot or attached to the end as a separate binary.

When CONFIG_OF_CONTROL is defined, U-Boot requires a valid fdt. A check is provided for this early in initialisation.

Signed-off-by Simon Glass <[email protected]>

---
arch/arm/lib/board.c | 22 ++++++++++++++++++++++

1 files changed, 22 insertions(+), 0 deletions(-)

arch/arm/lib/board.c +2 -0

index 1fe3751..b0f3162 100644
@@ -48,6 +48,7 @@
 #include <nand.h>
 #include <onenand_uboot.h>
 #include <mmc.h>
+#include <libfdt.h>
 #include <post.h>
 #include <logbuff.h>
 

@@ -197,6 +198,17 @@ static int arm_pci_init(void)
 }
 #endif /* CONFIG_CMD_PCI || CONFIG_PCI */
 
+#ifdef CONFIG_OF_CONTROL

arch/arm/lib/board.c +10 -0

 /*
 * Breathe some life into the board...
 *

@@ -239,6 +251,9 @@ init_fnc_t *init_sequence[] = {
 #if defined(CONFIG_BOARD_EARLY_INIT_F)
 	board_early_init_f,
 #endif
+#ifdef CONFIG_OF_CONTROL
+	check_fdt,
+#endif
 	timer_init,		/* initialize timer */
 #ifdef CONFIG_FSL_ESDHC
 	get_clocks,

@@ -276,6 +291,13 @@ void board_init_f(ulong bootflag)
 	memset((void *)gd, 0, sizeof(gd_t));
 
 	gd->mon_len = _bss_end_ofs;
+#ifdef CONFIG_OF_EMBED
+	/* Get a pointer to the FDT */
+	gd->fdt_blob = _binary_dt_dtb_start;
+#elif defined CONFIG_OF_SEPARATE
+	/* FDT is at end of image */
+	gd->fdt_blob = (void *)(_end_ofs + _TEXT_BASE);
+#endif
 
 	for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
 		if ((*init_fnc_ptr)() != 0) {

Signature · 1 line

1.7.3.1

Quoted 27 lines · Simon Glass

This locates the device tree either embedded within U-Boot or attached to the end as a separate binary.

When CONFIG_OF_CONTROL is defined, U-Boot requires a valid fdt. A check is provided for this early in initialisation.

Signed-off-by Simon Glass <[email protected]>

---
arch/arm/lib/board.c | ? 22 ++++++++++++++++++++++

1 files changed, 22 insertions(+), 0 deletions(-)

arch/arm/lib/board.c +1 -0

index 1fe3751..b0f3162 100644
@@ -48,6 +48,7 @@
 #include <nand.h>
 #include <onenand_uboot.h>
 #include <mmc.h>
+#include <libfdt.h>
 #include <post.h>
 #include <logbuff.h>
 

@@ -197,6 +198,17 @@ static int arm_pci_init(void)
 }
 #endif /* CONFIG_CMD_PCI || CONFIG_PCI */
 

arch/arm/lib/board.c static int arm_pci_init(void) · line 211

Quoted 11 lines

arch/arm/lib/board.c +11 -0

+#ifdef CONFIG_OF_CONTROL
+static int check_fdt(void)
+{
+ ? ? /* We must have an fdt */
+ ? ? if (fdt_check_header(gd->fdt_blob))
+ ? ? ? ? ? ? panic("No valid fdt found - please append one to U-Boot\n"
+ ? ? ? ? ? ? ? ? ? ? "binary or define CONFIG_OF_EMBED\n");
+ ? ? return 0;
+}
+#endif
+

this isn't arm specific, maybe put in fdt_support.c

Quoted 30 lines

arch/arm/lib/board.c +0 -0

 /*

?* Breathe some life into the board...
?*

arch/arm/lib/board.c +3 -0

@@ -239,6 +251,9 @@ init_fnc_t *init_sequence[] = {
 #if defined(CONFIG_BOARD_EARLY_INIT_F)
 ? ? ? board_early_init_f,
 #endif
+#ifdef CONFIG_OF_CONTROL
+ ? ? check_fdt,
+#endif

? ? ? timer_init, ? ? ? ? ? ? /* initialize timer */ #ifdef CONFIG_FSL_ESDHC
? ? ? get_clocks,

arch/arm/lib/board.c +7 -1

@@ -276,6 +291,13 @@ void board_init_f(ulong bootflag)
 ? ? ? memset((void *)gd, 0, sizeof(gd_t));
 
 ? ? ? gd->mon_len = _bss_end_ofs;
+#ifdef CONFIG_OF_EMBED
+ ? ? /* Get a pointer to the FDT */
+ ? ? gd->fdt_blob = _binary_dt_dtb_start;
+#elif defined CONFIG_OF_SEPARATE
+ ? ? /* FDT is at end of image */
+ ? ? gd->fdt_blob = (void *)(_end_ofs + _TEXT_BASE);
+#endif
 
 ? ? ? for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
 ? ? ? ? ? ? ? if ((*init_fnc_ptr)() != 0) {
--

1.7.3.1

lib/fdtdec.c

Quoted 4 lines · On Saturday 15 October 2011 11:48:25 Simon Glass wrote:

lib/fdtdec.c new file +1 -0

 
+static const char *compat_names[COMPAT_COUNT] = {

static const char * const compat_names[COMPAT_COUNT] = { -mike

Dear Simon Glass,

is there going to be an updated version of this patch series?

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "The algorithm to do that is extremely nasty. You might want ?to ?mug someone with it." ? ? ? ? ? ? ? ? ? - M. Devine, Computer Science 340

There was a request to move the check_fdt function into the fdtdec library, and I think it makes sense. So I will do that and send an

update. I don't have any other changes ATM.

Dear Simon Glass,

Quoted 1 line · In message <CAPnjgZ22OPHxn5DDuOLoRwaeCDeWV11FdqeqpD4e=ba9ZyfsHA@mail.gmail.com>…

Quoted 2 lines

There was a request to move the check_fdt function into the fdtdec library, and I think it makes sense. So I will do that and send an

That was my unerstanding, too.

Quoted 1 line

update. I don't have any other changes ATM.

And that's why I asked :-)

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "To IBM, 'open' means there is a modicum ?of ?interoperability ?among some of their equipment." ? ? ? ? ? ? ? ? ? ? ? ? ? ?- Harv Masterson