[U-Boot] [PATCH] 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 gabeblack@chromium.org --- arch/x86/include/asm/global_data.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h index 05a2139..d29d4e9 100644 --- a/arch/x86/include/asm/global_data.h +++ b/arch/x86/include/asm/global_data.h @@ -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;
Hi Gabe,
On Mon, Dec 5, 2011 at 5:43 PM, Gabe Black gabeblack@chromium.org 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.
Signed-off-by: Gabe Black gabeblack@chromium.org
arch/x86/include/asm/global_data.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h index 05a2139..d29d4e9 100644 --- a/arch/x86/include/asm/global_data.h +++ b/arch/x86/include/asm/global_data.h @@ -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 */
On ARM we went with fdt_blob for this.
Regards, Simon
void **jt; /* jump table */ char env_buf[32]; /* buffer for getenv() before reloc. */ } gd_t; -- 1.7.3.1
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 gabeblack@chromium.org --- 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(-)
diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h index 05a2139..2130f37 100644 --- a/arch/x86/include/asm/global_data.h +++ b/arch/x86/include/asm/global_data.h @@ -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;
Hi Gabe,
On Tue, Dec 6, 2011 at 12:43 PM, Gabe Black gabeblack@chromium.org 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,
Graeme
On Mon, Dec 5, 2011 at 5:49 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Gabe,
On Tue, Dec 6, 2011 at 12:43 PM, Gabe Black gabeblack@chromium.org 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,
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
Hi Gabe,
On Tue, Dec 6, 2011 at 1:04 PM, Gabe Black gabeblack@chromium.org wrote:
On Mon, Dec 5, 2011 at 5:49 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Gabe,
On Tue, Dec 6, 2011 at 12:43 PM, Gabe Black gabeblack@chromium.org 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,
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
I thought this list was just a linked list of more e820 entries (and that is what the code seems to suggest)
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
On Mon, Dec 5, 2011 at 9:07 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Gabe,
On Tue, Dec 6, 2011 at 1:04 PM, Gabe Black gabeblack@chromium.org wrote:
On Mon, Dec 5, 2011 at 5:49 PM, Graeme Russ graeme.russ@gmail.com
wrote:
Hi Gabe,
On Tue, Dec 6, 2011 at 12:43 PM, Gabe Black gabeblack@chromium.org 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,
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
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.
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?
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.
Regards,
Graeme
Hi Gabe,
On 06/12/11 13:04, Gabe Black wrote:
On Mon, Dec 5, 2011 at 5:49 PM, Graeme Russ <graeme.russ@gmail.com mailto:graeme.russ@gmail.com> wrote:
Hi Gabe, On Tue, Dec 6, 2011 at 12:43 PM, Gabe Black <gabeblack@chromium.org <mailto:gabeblack@chromium.org>> 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, GraemeThe 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?
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
participants (3)
-
Gabe Black -
Graeme Russ -
Simon Glass