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

Graeme Russ graeme.russ at gmail.com
Mon Dec 12 10:08:25 CET 2011


Hi Gabe,

On 06/12/11 13:04, Gabe Black wrote:
> 
> 
> On Mon, Dec 5, 2011 at 5:49 PM, Graeme Russ <graeme.russ at gmail.com
> <mailto:graeme.russ at gmail.com>> wrote:
> 
>     Hi Gabe,
> 
>     On Tue, Dec 6, 2011 at 12:43 PM, Gabe Black <gabeblack at chromium.org
>     <mailto:gabeblack at 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


More information about the U-Boot mailing list