| Message ID | 1323135833-20191-1-git-send-email-gabeblack@chromium.org |
|---|---|
| State | Superseded |
| Delegated to: | Graeme Russ |
| Headers | show |
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 >
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, > > 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
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;
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(-)