Patchwork [U-Boot] x86: Add a pointer to the global data structure to point to the device tree

login
register
mail settings
Submitter Gabe Black
Date Dec. 6, 2011, 1:43 a.m.
Message ID <1323135833-20191-1-git-send-email-gabeblack@chromium.org>
Download mbox | patch
Permalink /patch/129492/
State Superseded
Delegated to: Graeme Russ
Headers show

Comments

Gabe Black - Dec. 6, 2011, 1:43 a.m.
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(-)
Simon Glass - Dec. 6, 2011, 1:47 a.m.
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
>
Graeme Russ - Dec. 6, 2011, 1:49 a.m.
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
Gabe Black - Dec. 6, 2011, 2:04 a.m.
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
Graeme Russ - Dec. 6, 2011, 2:07 a.m.
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
Gabe Black - Dec. 6, 2011, 5:45 a.m.
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
>
Graeme Russ - Dec. 12, 2011, 9:08 a.m.
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,
> 
>     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?

> 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

Patch

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;