x86: Add a pointer to the global data structure to point to the device tree

PATCH Superseded Gabe Black 3 participants 8 messages Dec 6, 2011 – Dec 12, 2011 x86

Share & tools

Gabe Black

author

2011-12-06 01:43 UTC #0 lore raw

PATCH 1/1 x86: Add a pointer to the global data structure to point to the device tree

This change adds a pointer to the global data structure in x86 to point to the device tree. This mirrors an identical pointer in ARM.

Signed-off-by Gabe Black <[email protected]>

---
 arch/x86/include/asm/global_data.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

arch/x86/include/asm/global_data.h +1 -0

index 05a2139..d29d4e9 100644
@@ -53,6 +53,7 @@ typedef	struct global_data {
 	unsigned long	start_addr_sp;	/* start_addr_stackpointer */
 	phys_size_t	ram_size;	/* RAM size */
 	unsigned long	reset_status;	/* reset status register at boot */
+	const void	*blob;		/* Our device tree, NULL if none */
 	void		**jt;		/* jump table */
 	char		env_buf[32];	/* buffer for getenv() before reloc. */
 } gd_t;

Signature · 1 line

1.7.3.1

Simon Glass

2011-12-06 01:47 UTC #1 lore raw

PATCH 1/1 x86: Add a pointer to the global data structure to point to the device tree

Hi Gabe,

Quoted 13 lines · Gabe Black

This change adds a pointer to the global data structure in x86 to point to the device tree. This mirrors an identical pointer in ARM.
Signed-off-by Gabe Black <[email protected]>
---
?arch/x86/include/asm/global_data.h | ? ?1 +
?1 files changed, 1 insertions(+), 0 deletions(-)
arch/x86/include/asm/global_data.h +0 -0
index 05a2139..d29d4e9 100644
@@ -53,6 +53,7 @@ typedef ? ? ? struct global_data {

Quoted 4 lines

? ? ? ?unsigned long ? start_addr_sp; ?/* start_addr_stackpointer */ ? ? ? ?phys_size_t ? ? ram_size; ? ? ? /* RAM size */
? ? ? ?unsigned long ? reset_status; ? /* reset status register at boot */
+ ? ? ? const void ? ? ?*blob; ? ? ? ? ?/* Our device tree, NULL if none */

On ARM we went with fdt_blob for this.

Regards,
Simon

Quoted 6 lines

? ? ? ?void ? ? ? ? ? ?**jt; ? ? ? ? ? /* jump table */
? ? ? ?char ? ? ? ? ? ?env_buf[32]; ? ?/* buffer for getenv() before reloc. */ ?} gd_t;
--
1.7.3.1

Gabe Black

author

2011-12-06 01:58 UTC #2 lore raw

PATCH v2 1/1 x86: Add a pointer to the global data structure to point to the device tree

This change adds a pointer to the global data structure in x86 to point to the device tree. This mirrors an identical pointer in ARM.

Signed-off-by Gabe Black <[email protected]>

---
Changes in v2:
Update the name of the pointer to what ARM is now using.

 arch/x86/include/asm/global_data.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

arch/x86/include/asm/global_data.h +1 -0

index 05a2139..2130f37 100644
@@ -53,6 +53,7 @@ typedef	struct global_data {
 	unsigned long	start_addr_sp;	/* start_addr_stackpointer */
 	phys_size_t	ram_size;	/* RAM size */
 	unsigned long	reset_status;	/* reset status register at boot */
+	const void	*fdt_blob;	/* Our device tree, NULL if none */
 	void		**jt;		/* jump table */
 	char		env_buf[32];	/* buffer for getenv() before reloc. */
 } gd_t;

Signature · 1 line

1.7.3.1

Graeme Russ

2011-12-06 01:49 UTC #3 lore raw

PATCH 1/1 x86: Add a pointer to the global data structure to point to the device tree

In reply to Gabe Black

Hi Gabe,

Quoted 2 lines · Gabe Black

This change adds a pointer to the global data structure in x86 to point to the device tree. This mirrors an identical pointer in ARM.

Out of curiosity, is this paving the way for FDT support in general? If so, to what extent does the Linux kernel support FDT for x86?

I have had thoughts about looking into what Device Tree / FDT is all about, and I'm wondering what it is going to bring to the table (positive and negative) for x86. For example, would this, in theory, depricate the boot_params structure, e820 map etc...

Regards,

Graeme

Gabe Black

author

2011-12-06 02:04 UTC #4 lore raw

PATCH 1/1 x86: Add a pointer to the global data structure to point to the device tree

Quoted 11 lines · Graeme Russ

Hi Gabe,
Quoted 1 line · Gabe Black
This change adds a pointer to the global data structure in x86 to point
to
Quoted 1 line
the device tree. This mirrors an identical pointer in ARM.
Out of curiosity, is this paving the way for FDT support in general? If so, to what extent does the Linux kernel support FDT for x86?

Quoted 9 lines

I have had thoughts about looking into what Device Tree / FDT is all about, and I'm wondering what it is going to bring to the table (positive and negative) for x86. For example, would this, in theory, depricate the boot_params structure, e820 map etc...
Regards,
Graeme

The device tree can be used in two different ways, by u-boot and by the kernel. This is for use by u-boot itself and is one mechanism coreboot can use to make its own runtime modification to how u-boot is set up (if there's a serial console it can use, for instance), and it is fairly useful. The kernel has some very minimal provisions for passing in a device tree in x86 through, if I remember correctly, basically a linked list of entries which hang off the end of the boot_params structure. The kernel doesn't take advantage of it at all, so it wouldn't really be useful to pass one in. There are times when it would be a good solution to certain problems but the kernel would have to actually be set up to take advantage of it first.

Gabe

Graeme Russ

2011-12-06 02:07 UTC #5 lore raw

PATCH 1/1 x86: Add a pointer to the global data structure to point to the device tree

Hi Gabe,

Quoted 26 lines · Gabe Black

Quoted 12 lines · Graeme Russ
Hi Gabe,
Quoted 3 lines · Gabe Black
This change adds a pointer to the global data structure in x86 to point to
the device tree. This mirrors an identical pointer in ARM.
Out of curiosity, is this paving the way for FDT support in general? If so, to what extent does the Linux kernel support FDT for x86?
Quoted 8 lines
I have had thoughts about looking into what Device Tree / FDT is all about, and I'm wondering what it is going to bring to the table (positive and negative) for x86. For example, would this, in theory, depricate the boot_params structure, e820 map etc...
Regards,
Graeme

Quoted 7 lines

The device tree can be used in two different ways, by u-boot and by the kernel. This is for use by u-boot itself and is one mechanism coreboot can use to make its own runtime modification to how u-boot is set up (if there's a serial console it can use, for instance), and it is fairly useful. The kernel has some very minimal provisions for passing in a device tree in x86 through, if I remember correctly, basically a linked list of entries which hang off the end of the boot_params structure. The kernel doesn't take

I thought this list was just a linked list of more e820 entries (and that is what the code seems to suggest)

Quoted 3 lines

advantage of it at all, so it wouldn't really be useful to pass one in. There are times when it would be a good solution to certain problems but the kernel would have to actually be set up to take advantage of it first.

Does UEFI support device trees? If so, I wonder if this is the future of Linux and x86 support is somewhat inevitable?

Regards,

Graeme

Gabe Black

author

2011-12-06 05:45 UTC #6 lore raw

PATCH 1/1 x86: Add a pointer to the global data structure to point to the device tree

Quoted 38 lines · Graeme Russ

Hi Gabe,
Quoted 3 lines · Gabe Black
On Mon, Dec 5, 2011 at 5:49 PM, Graeme Russ <[email protected]>
Quoted 6 lines · wrote:
Quoted 6 lines
Hi Gabe,
Quoted 1 line · Gabe Black
This change adds a pointer to the global data structure in x86 to
point
Quoted 11 lines
Quoted 11 lines
Quoted 2 lines
to
the device tree. This mirrors an identical pointer in ARM.
Out of curiosity, is this paving the way for FDT support in general? If so, to what extent does the Linux kernel support FDT for x86?
I have had thoughts about looking into what Device Tree / FDT is all about, and I'm wondering what it is going to bring to the table (positive and negative) for x86. For example, would this, in theory, depricate the boot_params structure, e820 map etc...
Quoted 8 lines
Quoted 3 lines
Regards,
Graeme
The device tree can be used in two different ways, by u-boot and by the kernel. This is for use by u-boot itself and is one mechanism coreboot
can
Quoted 1 line
use to make its own runtime modification to how u-boot is set up (if
there's
Quoted 2 lines
a serial console it can use, for instance), and it is fairly useful. The kernel has some very minimal provisions for passing in a device tree in

Quoted 9 lines

x86
Quoted 1 line
through, if I remember correctly, basically a linked list of entries
which
Quoted 1 line
hang off the end of the boot_params structure. The kernel doesn't take
I thought this list was just a linked list of more e820 entries (and that is
what the code seems to suggest)

See:
http://lxr.linux.no/linux+v3.1.4/Documentation/x86/boot.txt#L188
http://lxr.linux.no/linux+v3.1.4/Documentation/x86/boot.txt#L636
http://lxr.linux.no/linux+v3.1.4/arch/x86/include/asm/bootparam.h#L12

It's type 2.

Quoted 9 lines

Quoted 3 lines
advantage of it at all, so it wouldn't really be useful to pass one in. There are times when it would be a good solution to certain problems but
the
Quoted 1 line
kernel would have to actually be set up to take advantage of it first.
Does UEFI support device trees? If so, I wonder if this is the future of Linux and x86 support is somewhat inevitable?

I don't know but I don't think so. It wouldn't surprise me *that* much to see device trees in x86 eventually, but there's a long way to go before that happens. From what I heard it took quite a bit of pushing to get it in for the architectures that already support it now. I would be surprised if it happened any time soon.

Quoted 5 lines

Regards,
Graeme

Graeme Russ

2011-12-12 09:08 UTC #7 lore raw

PATCH 1/1 x86: Add a pointer to the global data structure to point to the device tree

In reply to Gabe Black

Hi Gabe,

Quoted 23 lines · Gabe Black

On Mon, Dec 5, 2011 at 5:49 PM, Graeme Russ <[email protected] <mailto:[email protected]>> wrote:
Hi Gabe,
On Tue, Dec 6, 2011 at 12:43 PM, Gabe Black <[email protected] <mailto:[email protected]>> wrote:
> This change adds a pointer to the global data structure in x86 to point to
> the device tree. This mirrors an identical pointer in ARM.
Out of curiosity, is this paving the way for FDT support in general? If so, to what extent does the Linux kernel support FDT for x86?
I have had thoughts about looking into what Device Tree / FDT is all about, and I'm wondering what it is going to bring to the table (positive and negative) for x86. For example, would this, in theory, depricate the boot_params structure, e820 map etc...
Regards,

Quoted 8 lines

Graeme
The device tree can be used in two different ways, by u-boot and by the kernel. This is for use by u-boot itself and is one mechanism coreboot can use to make its own runtime modification to how u-boot is set up (if there's a serial console it can use, for instance), and it is fairly

Hmmm, I'm now looking at PCI interrupt routing and I've had to do a bit of reading on the subject. It looks like I could do it via a table in EBDA or via ACPI. Since I'm booting Linux, I'm thinking the ACPI method which brings me to an interesting thought - Could (should?) I use the device tree to provide the ACPI data?

On first glance though, it looks to me that FDT and ACPI provide related functionality, but on different platforms - Maybe I should provide the ACPI data directly in the uImage like the FDT is?

Thoughts?

Quoted 9 lines

useful. The kernel has some very minimal provisions for passing in a device tree in x86 through, if I remember correctly, basically a linked list of entries which hang off the end of the boot_params structure. The kernel doesn't take advantage of it at all, so it wouldn't really be useful to pass one in. There are times when it would be a good solution to certain problems but the kernel would have to actually be set up to take advantage of it first.
Gabe

Regards,

Graeme