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