From: Graeme Russ <graeme.russ@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] x86: Add a pointer to the global data structure to point to the device tree
Date: Mon, 12 Dec 2011 20:08:25 +1100 [thread overview]
Message-ID: <4EE5C489.9000308@gmail.com> (raw)
In-Reply-To: <CAPPXG1msMvuMiuVBaeY0eYZ9iVZbmySi4GEnEWjTpZCVDOr=fQ@mail.gmail.com>
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
prev parent reply other threads:[~2011-12-12 9:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-06 1:43 [U-Boot] [PATCH] x86: Add a pointer to the global data structure to point to the device tree Gabe Black
2011-12-06 1:47 ` Simon Glass
2011-12-06 1:58 ` [U-Boot] [PATCH v2] " Gabe Black
2011-12-06 1:49 ` [U-Boot] [PATCH] " Graeme Russ
2011-12-06 2:04 ` Gabe Black
2011-12-06 2:07 ` Graeme Russ
2011-12-06 5:45 ` Gabe Black
2011-12-12 9:08 ` Graeme Russ [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EE5C489.9000308@gmail.com \
--to=graeme.russ@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox