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

2011-12-12 Thread Graeme Russ 
Hi Gabe,

On 06/12/11 13:04, Gabe Black wrote:
 
 
 On Mon, Dec 5, 2011 at 5:49 PM, Graeme Russ graeme.r...@gmail.com
 mailto:graeme.r...@gmail.com wrote:
 
 Hi Gabe,
 
 On Tue, Dec 6, 2011 at 12:43 PM, Gabe Black gabebl...@chromium.org
 mailto:gabebl...@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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2011-12-05 Thread Gabe Black 
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 gabebl...@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 */
void**jt;   /* jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
 } gd_t;
-- 
1.7.3.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2011-12-05 Thread Simon Glass 
Hi Gabe,

On Mon, Dec 5, 2011 at 5:43 PM, Gabe Black gabebl...@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 gabebl...@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

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2011-12-05 Thread Graeme Russ 
Hi Gabe,

On Tue, Dec 6, 2011 at 12:43 PM, Gabe Black gabebl...@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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2011-12-05 Thread Gabe Black 
On Mon, Dec 5, 2011 at 5:49 PM, Graeme Russ graeme.r...@gmail.com wrote:

 Hi Gabe,

 On Tue, Dec 6, 2011 at 12:43 PM, Gabe Black gabebl...@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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2011-12-05 Thread Graeme Russ 
Hi Gabe,

On Tue, Dec 6, 2011 at 1:04 PM, Gabe Black gabebl...@chromium.org wrote:


 On Mon, Dec 5, 2011 at 5:49 PM, Graeme Russ graeme.r...@gmail.com wrote:

 Hi Gabe,

 On Tue, Dec 6, 2011 at 12:43 PM, Gabe Black gabebl...@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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2011-12-05 Thread Gabe Black 
On Mon, Dec 5, 2011 at 9:07 PM, Graeme Russ graeme.r...@gmail.com wrote:

 Hi Gabe,

 On Tue, Dec 6, 2011 at 1:04 PM, Gabe Black gabebl...@chromium.org wrote:
 
 
  On Mon, Dec 5, 2011 at 5:49 PM, Graeme Russ graeme.r...@gmail.com
 wrote:
 
  Hi Gabe,
 
  On Tue, Dec 6, 2011 at 12:43 PM, Gabe Black gabebl...@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

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot