This patch adds minimal support for device tree support on x86. It will
be passed to the kernel via setup_data which requires atleast boot
protocol 2.09.
Memory size, restricted memory regions, boot arguments are gathered the
traditional way so things like cmd_line are just here to let the code
On 12/30/2010 12:58 PM, Grant Likely wrote:
Right, but in all of those cases a boot wrapper provides the same
functionality with better flexability, such as being able to provided
the dtb image(s) at install time instead of compile time.
Assuming the boot wrapper is written correctly. I
On 01/03/2011 08:05 AM, H. Peter Anvin wrote:
On 12/30/2010 12:58 PM, Grant Likely wrote:
Right, but in all of those cases a boot wrapper provides the same
functionality with better flexability, such as being able to provided
the dtb image(s) at install time instead of compile time.
On Mon, Jan 03, 2011 at 08:19:36AM -0800, H. Peter Anvin wrote:
On 01/03/2011 08:05 AM, H. Peter Anvin wrote:
On 12/30/2010 12:58 PM, Grant Likely wrote:
Right, but in all of those cases a boot wrapper provides the same
functionality with better flexability, such as being able to provided
On 01/03/2011 10:06 AM, H. Peter Anvin wrote:
The problem with that kind of boot wrapper is that they are
per-architecture, increasing the differences between architectures
needlessly, and they are often implemented very poorly.
As such, it's nice to have an ultimate fallback that doesn't
On Thu, Dec 30, 2010 at 2:26 AM, Grant Likely grant.lik...@secretlab.ca wrote:
What is the boot sequence for the embedded x86 platforms? Is there
still a bootloader?
There's no one embedded setup on any platform, but one of the few
constants of embedded development is trying to eliminate
On Thu, Dec 30, 2010 at 1:26 AM, Grant Likely grant.lik...@secretlab.ca wrote:
On Sun, Nov 28, 2010 at 02:49:07PM +0100, Sebastian Andrzej Siewior wrote:
The reason why you have multiple .o wrapper files is because the specific
platform code is not simply passing the device tree but also adding
On Thu, Dec 30, 2010 at 1:45 AM, Rob Landley r...@landley.net wrote:
On Thu, Dec 30, 2010 at 2:26 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
What is the boot sequence for the embedded x86 platforms? Is there
still a bootloader?
There's no one embedded setup on any platform, but one
On 12/30/2010 12:26 AM, Grant Likely wrote:
Since Linux on x86 has pretty much always depended on a two stage boot
(firmware boots a bootloader like grub which in turn boots the
kernel), then what is the use case for pursuing an in-kernel dtb
linkage? simpleimage was used on powerpc for the
On Sun, 2010-11-28 at 14:49 +0100, Sebastian Andrzej Siewior wrote:
(*) That brings a separate topic we shall discuss: A consistent way for
versionning the device-tree would be really useful.
This isn't a problem unless you move nodes or deprecate them, right? Or
do you think about another
Sam Ravnborg wrote:
+++ b/arch/x86/include/asm/prom.h
+#ifdef __KERNEL__
This file is not exported to userspace - so no need to guard with __KERNEL__
Removed.
Sam
Sebastian
___
devicetree-discuss mailing list
On Thu, 2010-11-25 at 18:39 +0100, Sebastian Andrzej Siewior wrote:
This patch adds minimal support for device tree support on x86. It will
be passed to the kernel via setup_data which requires atleast boot
protocol 2.09.
Memory size, restricted memory regions, boot arguments are gathered the
This patch adds minimal support for device tree support on x86. It will
be passed to the kernel via setup_data which requires atleast boot
protocol 2.09.
Memory size, restricted memory regions, boot arguments are gathered the
traditional way so things like cmd_line are just here to let the code
diff --git a/arch/x86/include/asm/prom.h b/arch/x86/include/asm/prom.h
new file mode 100644
index 000..8fdb0d2
--- /dev/null
+++ b/arch/x86/include/asm/prom.h
@@ -0,0 +1,60 @@
+/*
+ * Definitions for Device tree / OpenFirmware handling on X86
+ *
+ * based on
14 matches
Mail list logo
