* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-12 23:26 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B1EEA8.4040904@freescale.com>
[snip]
On Tue, Feb 12, 2008 at 01:08:24PM -0600, Timur Tabi wrote:
> Grant Likely wrote:
> > On Feb 12, 2008 8:44 AM, Timur Tabi <timur@freescale.com> wrote:
> >> Arnd Bergmann wrote:
> > I think it
> > is a slippery slope to try and encode conditionals into the structure;
>
> Perhaps, which is why I said it should be simple conditionals - two
> values and a comparison.
I can pretty much guarantee you that someone will find that
insufficient and want to expand the conditional representation. This
way madness lies.
> > but it is entirely reasonable to encode *data* into the dt that helps
> > make those conditional decisions.
>
> That's okay too, except that if we just add additional nodes that
> describe conditions, then we need to make sure that whatever parses
> that DTB must also parse those additional nodes. The only way to do
> that is create a new version number, like 18, which is marked as
> being incompatible with the current version (17). Otherwise, a
> person could pass that DTB to an old version of U-Boot, and U-boot
> will just pass it on to the kernel as-is.
No. As Grant says, that's not what the version number is for. It
represents the version of the encoding, not the content. If you must
version the content (which you should try really hard to avoid) the
correct way is to add versioning properties to the root node.
> > We've already got that issue. If you pass the device tree for the
> > wrong board it will still validate correctly, but the board is not
> > going to boot.
>
> There's nothing stopping U-Boot today from scanning the device tree
> and making sure the SOC's compatible node is correct. That's not
> currently done, but it could be.
>
> > The device tree must match what the bootloader
> > expects. Changing the version number will do nothing to help this.
> > The version number ensures that the tree is parsable. It does not
> > ensure that it is correct.
>
> I think you're missing the point. If we add conditional expressions
> to the device tree (whether attached to a node or as part of a
> separate node or whatever), we must also add a mechanism to ensure
> that these conditions are parsed by the boot loader. As far as I
> know, the only mechanism that can do this is the version identifier.
No. a) the version identifier is not a mechanism for doing that and b)
the conditional mechanism is inherently agent-specific, therefore in
any case you *must* match an input incomplete tree (by which I mean
*anything* that requires processing before it's ready for consumption
by the kernel) to the specific bootloader or agent that will process
it and pass to the kernel.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-12 23:21 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B1BEE7.4050808@freescale.com>
On Tue, Feb 12, 2008 at 09:44:39AM -0600, Timur Tabi wrote:
> Arnd Bergmann wrote:
>
> > On Tuesday 12 February 2008, David Gibson wrote:
> >> Or to expand. It's relatively easy now to just include multiple nodes
> >> in the tree and either delete or nop some of them out conditionally
> >> using libfdt.
>
> Yes, but what better place to store the conditions than in the
> device tree itself? How would libfdt know where the conditions are?
> Do you want to have two binary blobs?
libfdt wouldn't. The conditional logic must be in the agent using
libfdt.
> >> But the conditional logic should be in the manipulating
> >> agent (u-boot or bootwrapper or whatever), there's no way we're going
> >> to require a conditional expression parser to interpret the device
> >> tree blob itself.
>
> I think it's a great feature that solves a lot of problems, and it
> does so in an elegant and efficient manner. I look forward to
> trying to change your mind when I get around to implementing it.
>
> > How about making the logic to nop out nodes a little more generic
> > without changes to the binary format?
> > E.g. you could have a "linux,conditional-node" property in the device
> > tree whose value is compared to a HW configuration specific string.
>
> The problem with this is that if you use a version of libfdt that
> does not understand "linux,conditional-node", then your device tree
> will be wrong, because it could contain nodes that don't belong. We
> would need a new, incompatible version number for the device tree to
> make sure that this doesn't happen, even though nothing has changed
> in the binary layout of the tree.
Passing an incomplete device tree to an agent that doesn't expect it
is always going to cause trouble. This is nothing new. And as you've
said the interpretation of these variables in the conditionals is
already agent specific, so you'd still have to pass these
conditionalised trees to the correct agent in order for them to be
correctly interpreted.
No, this has to be agent-local logic. If you want to annotate your
agent's input device trees with information that will help it do this,
go for it, but don't expect it to be in any way a standardized aspect
of the device tree format.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-12 23:17 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi, Arnd Bergmann
In-Reply-To: <20080212185106.GA4042@loki.buserror.net>
On Tue, Feb 12, 2008 at 12:51:06PM -0600, Scott Wood wrote:
> On Tue, Feb 12, 2008 at 11:36:33AM +1100, David Gibson wrote:
> > On Tue, Feb 12, 2008 at 01:21:44AM +0100, Arnd Bergmann wrote:
> > > On Tuesday 12 February 2008, David Gibson wrote:
> > > > Or to expand. It's relatively easy now to just include multiple nodes
> > > > in the tree and either delete or nop some of them out conditionally
> > > > using libfdt. But the conditional logic should be in the manipulating
> > > > agent (u-boot or bootwrapper or whatever), there's no way we're going
> > > > to require a conditional expression parser to interpret the device
> > > > tree blob itself.
> > >
> > > How about making the logic to nop out nodes a little more generic
> > > without changes to the binary format?
> > > E.g. you could have a "linux,conditional-node" property in the device
> > > tree whose value is compared to a HW configuration specific string.
> > > In Sean's example, you can have linux,conditional-node="Rev.A" in
> > > some nodes and linux,conditional-node="Rev.B" in others, then
> > > knock out all devices that have a non-matching linux,conditional-node
> > > property, and finally remove the properties themselves before starting
> > > the kernel.
> >
> > Well, that's basically a u-boot issue. If they want to do their input
> > trees that way, and have helper functions that deal with it...
>
> The actual mechanism that we originially discussed, which Timur later
> morphed into conditions-on-nodes, was to have a separate hwoptions node,
> under which would be described various hwoptions (jumpers and such) whose
> state could be either detected by u-boot or set by environment variable.
> Each hwoption setting would contain a device tree fragment to be merged into
> the main device tree.
I'm not sure I'm entirely happy about storing the fragments under a
special node - but certainly u-boot could do that if it wants. What
would certainly be ok is to store various fragments as separate blobs
and fold them together as necessary. Which reminds me, I meant to
implement a "graft" function in libfdt.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: DTS question - MPC5200b
From: David Gibson @ 2008-02-12 22:49 UTC (permalink / raw)
To: Nick; +Cc: linuxppc-dev
In-Reply-To: <47B1D943.6020708@rogers.com>
On Tue, Feb 12, 2008 at 12:37:07PM -0500, Nick wrote:
> Hi,
>
> I need some help. I am trying to access timer 7 on the MPC5200B
> processor. I have the DTS file setup like this
Others have addressed the most salient points, but some general
corrections for your device tree..
> gpt@670 { // General Purpose Timer
> device_type = "gpt";
device_type shouldn't be here.
> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> cell-index = <7>;
You probably don't want cell-index. cell-index should *only* be used
when there is some global register somewhere that's indexed by the
cell number.
> reg = <670 10>;
> interrupts = <1 10 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> I have timers 0 to 6 defined the same way except the cell-index reflects
> the timer number.
Presumably 'reg' is different for each, as well.
> In my platform file where I am doing my board setup, I tried the following.
>
> timer7 = mpc52xx_find_and_map ("mpc5200b-gpt");
>
> How do I specify the timer based on the cell-index?
You don't. As Grant explains, use reg instead.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
From: Benjamin Herrenschmidt @ 2008-02-12 22:00 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-ide, linux-kernel, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <20080212214137.47478e5e@core>
On Tue, 2008-02-12 at 21:41 +0000, Alan Cox wrote:
> On Wed, 13 Feb 2008 08:04:07 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> >
> > On Fri, 2008-02-08 at 19:40 +1100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > > - couple of fixes and preparatory patches
> > > >
> > > > - rework of PowerMac media-bay support ([un]register IDE devices instead of
> > > > [un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
> > >
> > > Interesting... I was thinking about doing a full remove of the device at
> > > a higher level instead but I suppose what you propose is easier.
> > >
> > > I'll have a look & test next week hopefully.
> >
> > Also, the above would have the advantage of not relying on drivers/ide
> > infrastructure, and thus working with libata (once somebody has ported
> > pmac ide to libata).
>
> Unfortunately you need a degree in dentistry to open a Macintosh up and
> fix it otherwise we would have support by now.
Heh :-)
Recent powermacs are trivial to open ! But yeah, I do need to produce a
driver for libata one of these days. On my todo list ...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
From: Alan Cox @ 2008-02-12 21:41 UTC (permalink / raw)
To: benh; +Cc: linux-ide, linux-kernel, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <1202850247.7410.24.camel@pasglop>
On Wed, 13 Feb 2008 08:04:07 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Fri, 2008-02-08 at 19:40 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > - couple of fixes and preparatory patches
> > >
> > > - rework of PowerMac media-bay support ([un]register IDE devices instead of
> > > [un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
> >
> > Interesting... I was thinking about doing a full remove of the device at
> > a higher level instead but I suppose what you propose is easier.
> >
> > I'll have a look & test next week hopefully.
>
> Also, the above would have the advantage of not relying on drivers/ide
> infrastructure, and thus working with libata (once somebody has ported
> pmac ide to libata).
Unfortunately you need a degree in dentistry to open a Macintosh up and
fix it otherwise we would have support by now.
Alan
^ permalink raw reply
* Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
From: Bartlomiej Zolnierkiewicz @ 2008-02-12 21:54 UTC (permalink / raw)
To: benh; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <1202850247.7410.24.camel@pasglop>
On Tuesday 12 February 2008, Benjamin Herrenschmidt wrote:
>
> On Fri, 2008-02-08 at 19:40 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > - couple of fixes and preparatory patches
> > >
> > > - rework of PowerMac media-bay support ([un]register IDE devices instead of
> > > [un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
> >
> > Interesting... I was thinking about doing a full remove of the device at
> > a higher level instead but I suppose what you propose is easier.
> >
> > I'll have a look & test next week hopefully.
>
> Also, the above would have the advantage of not relying on drivers/ide
> infrastructure, and thus working with libata (once somebody has ported
> pmac ide to libata).
Neither of these things exist at the moment so lets stick to the existing
code which is scheduled for 2.6.26 and which finally allows removal of ppc
specific ide hacks from arch/{powerpc,ppc} (500 LOC gone, patches to be
posted this week), not to mention other nice changes in the future...
Thanks,
Bart
^ permalink raw reply
* [PATCH] [RFC] Xilinx: Add generic configuration option to enable all xilinx drivers.
From: Stephen Neuendorffer @ 2008-02-12 21:31 UTC (permalink / raw)
To: linuxppc-dev, grant.likely, jacmet
In the future, this will be used to provide similar configuration for
PowerPC and Microblaze. It may also be convenient for those using
Xilinx cores as peripherals for external processors, rather than
explicitly having a dependance on the processor architecture.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
Grant,
This is the patch, updated for all of the drivers that I think are in
the tree. I think the problematic parts may be the ppc part, which is
required for backward compatibility. If this has to wait until ppc
dies, then that's fine with me, I guess.
It may also be better to clean up the Kconfig lines for Sysace and
framebuffer drivers by having PPC32 or PPC4xx select XILINX_DRIVERS.
My understanding is that those config options are there because of
people using external PPCs with those devices in the FPGA.
Steve
---
arch/powerpc/platforms/40x/Kconfig | 1 +
arch/ppc/platforms/4xx/Kconfig | 1 +
drivers/block/Kconfig | 2 +-
drivers/char/Kconfig | 2 +-
drivers/misc/Kconfig | 10 ++++++++++
drivers/serial/Kconfig | 2 +-
drivers/spi/Kconfig | 2 +-
drivers/video/Kconfig | 2 +-
8 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
index 8f6699f..03051bc 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -110,6 +110,7 @@ config 405GPR
config XILINX_VIRTEX
bool
+ select XILINX_DRIVERS
config XILINX_VIRTEX_II_PRO
bool
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
index 76551b6..d7db7e4 100644
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -228,6 +228,7 @@ config XILINX_VIRTEX_4_FX
config XILINX_VIRTEX
bool
+ select XILINX_DRIVERS
config STB03xxx
bool
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 4d0119e..0166560 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -412,7 +412,7 @@ source "drivers/s390/block/Kconfig"
config XILINX_SYSACE
tristate "Xilinx SystemACE support"
- depends on 4xx
+ depends on 4xx || XILINX_DRIVERS
help
Include support for the Xilinx SystemACE CompactFlash interface
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 157ae2a..8230ad1 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -833,7 +833,7 @@ config DTLK
config XILINX_HWICAP
tristate "Xilinx HWICAP Support"
- depends on XILINX_VIRTEX
+ depends on XILINX_DRIVERS
help
This option enables support for Xilinx Internal Configuration
Access Port (ICAP) driver.
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b5e67c0..e7b0bed 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -233,3 +233,13 @@ config ATMEL_SSC
If unsure, say N.
endif # MISC_DEVICES
+endmenu
+
+
+#
+# Xilinx devices and common device driver infrastructure
+#
+
+config XILINX_DRIVERS
+ bool
+
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index d7e1996..f922ec6 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -757,7 +757,7 @@ config SERIAL_IMX_CONSOLE
config SERIAL_UARTLITE
tristate "Xilinx uartlite serial port support"
- depends on PPC32
+ depends on PPC32 || XILINX_DRIVERS
select SERIAL_CORE
help
Say Y here if you want to use the Xilinx uartlite serial controller.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index abf0504..c66838f 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -183,7 +183,7 @@ config SPI_TXX9
config SPI_XILINX
tristate "Xilinx SPI controller"
- depends on SPI_MASTER && XILINX_VIRTEX && EXPERIMENTAL
+ depends on SPI_MASTER && XILINX_DRIVERS && EXPERIMENTAL
select SPI_BITBANG
help
This exposes the SPI controller IP from the Xilinx EDK.
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 5b3dbcf..a66ff4b 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1871,7 +1871,7 @@ config FB_PS3_DEFAULT_SIZE_M
config FB_XILINX
tristate "Xilinx frame buffer support"
- depends on FB && XILINX_VIRTEX
+ depends on FB && XILINX_DRIVERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
1.5.3.4-dirty
^ permalink raw reply related
* [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Manish Ahuja @ 2008-02-12 16:38 UTC (permalink / raw)
To: michael; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <1202806110.9738.15.camel@concordia.ozlabs.ibm.com>
Michael,
Fixed.
-Manish
----------
Initial patch for reserving memory in early boot, and freeing it later.
If the previous boot had ended with a crash, the reserved memory would contain
a copy of the crashed kernel data.
Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/kernel/prom.c | 50 ++++++++++++++++++++
arch/powerpc/kernel/rtas.c | 32 +++++++++++++
arch/powerpc/platforms/pseries/Makefile | 1
arch/powerpc/platforms/pseries/phyp_dump.c | 71 +++++++++++++++++++++++++++++
include/asm-powerpc/phyp_dump.h | 38 +++++++++++++++
include/asm-powerpc/rtas.h | 3 +
6 files changed, 195 insertions(+)
Index: 2.6.24-rc5/include/asm-powerpc/phyp_dump.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ 2.6.24-rc5/include/asm-powerpc/phyp_dump.h 2008-02-12 16:12:45.000000000 -0600
@@ -0,0 +1,38 @@
+/*
+ * Hypervisor-assisted dump
+ *
+ * Linas Vepstas, Manish Ahuja 2007
+ * Copyright (c) 2007 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _PPC64_PHYP_DUMP_H
+#define _PPC64_PHYP_DUMP_H
+
+#ifdef CONFIG_PHYP_DUMP
+
+/* The RMR region will be saved for later dumping
+ * whenever the kernel crashes. Set this to 256MB. */
+#define PHYP_DUMP_RMR_START 0x0
+#define PHYP_DUMP_RMR_END (1UL<<28)
+
+struct phyp_dump {
+ /* Memory that is reserved during very early boot. */
+ unsigned long init_reserve_start;
+ unsigned long init_reserve_size;
+ /* Check status during boot if dump supported, active & present*/
+ unsigned long phyp_dump_configured;
+ unsigned long phyp_dump_is_active;
+ /* store cpu & hpte size */
+ unsigned long cpu_state_size;
+ unsigned long hpte_region_size;
+};
+
+extern struct phyp_dump *phyp_dump_info;
+
+#endif /* CONFIG_PHYP_DUMP */
+#endif /* _PPC64_PHYP_DUMP_H */
Index: 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-12 16:12:45.000000000 -0600
@@ -0,0 +1,71 @@
+/*
+ * Hypervisor-assisted dump
+ *
+ * Linas Vepstas, Manish Ahuja 2007
+ * Copyrhgit (c) 2007 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/mm.h>
+#include <linux/pfn.h>
+#include <linux/swap.h>
+
+#include <asm/page.h>
+#include <asm/phyp_dump.h>
+
+/* Global, used to communicate data between early boot and late boot */
+static struct phyp_dump phyp_dump_global;
+struct phyp_dump *phyp_dump_info = &phyp_dump_global;
+
+/**
+ * release_memory_range -- release memory previously lmb_reserved
+ * @start_pfn: starting physical frame number
+ * @nr_pages: number of pages to free.
+ *
+ * This routine will release memory that had been previously
+ * lmb_reserved in early boot. The released memory becomes
+ * available for genreal use.
+ */
+static void
+release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
+{
+ struct page *rpage;
+ unsigned long end_pfn;
+ long i;
+
+ end_pfn = start_pfn + nr_pages;
+
+ for (i=start_pfn; i <= end_pfn; i++) {
+ rpage = pfn_to_page(i);
+ if (PageReserved(rpage)) {
+ ClearPageReserved(rpage);
+ init_page_count(rpage);
+ __free_page(rpage);
+ totalram_pages++;
+ }
+ }
+}
+
+static int __init phyp_dump_setup(void)
+{
+ unsigned long start_pfn, nr_pages;
+
+ /* If no memory was reserved in early boot, there is nothing to do */
+ if (phyp_dump_info->init_reserve_size == 0)
+ return 0;
+
+ /* Release memory that was reserved in early boot */
+ start_pfn = PFN_DOWN(phyp_dump_info->init_reserve_start);
+ nr_pages = PFN_DOWN(phyp_dump_info->init_reserve_size);
+ release_memory_range(start_pfn, nr_pages);
+
+ return 0;
+}
+
+subsys_initcall(phyp_dump_setup);
Index: 2.6.24-rc5/arch/powerpc/platforms/pseries/Makefile
===================================================================
--- 2.6.24-rc5.orig/arch/powerpc/platforms/pseries/Makefile 2008-02-12 16:11:44.000000000 -0600
+++ 2.6.24-rc5/arch/powerpc/platforms/pseries/Makefile 2008-02-12 16:12:45.000000000 -0600
@@ -18,3 +18,4 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug-cpu
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
obj-$(CONFIG_HVCS) += hvcserver.o
obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
+obj-$(CONFIG_PHYP_DUMP) += phyp_dump.o
Index: 2.6.24-rc5/arch/powerpc/kernel/prom.c
===================================================================
--- 2.6.24-rc5.orig/arch/powerpc/kernel/prom.c 2008-02-12 16:11:44.000000000 -0600
+++ 2.6.24-rc5/arch/powerpc/kernel/prom.c 2008-02-12 16:12:45.000000000 -0600
@@ -51,6 +51,7 @@
#include <asm/machdep.h>
#include <asm/pSeries_reconfig.h>
#include <asm/pci-bridge.h>
+#include <asm/phyp_dump.h>
#include <asm/kexec.h>
#ifdef DEBUG
@@ -1011,6 +1012,52 @@ static void __init early_reserve_mem(voi
#endif
}
+#ifdef CONFIG_PHYP_DUMP
+/**
+ * reserve_crashed_mem() - reserve all not-yet-dumped mmemory
+ *
+ * This routine may reserve memory regions in the kernel only
+ * if the system is supported and a dump was taken in last
+ * boot instance or if the hardware is supported and the
+ * scratch area needs to be setup. In other instances it returns
+ * without reserving anything. The memory in case of dump being
+ * active is freed when the dump is collected (by userland tools).
+ */
+static void __init reserve_crashed_mem(void)
+{
+ unsigned long base, size;
+ if (!phyp_dump_info->phyp_dump_configured) {
+ printk(KERN_ERR "Phyp-dump not supported on this hardware\n");
+ return;
+ }
+
+ if (phyp_dump_info->phyp_dump_is_active) {
+ /* Reserve *everything* above RMR.Area freed by userland tools*/
+ base = PHYP_DUMP_RMR_END;
+ size = lmb_end_of_DRAM() - base;
+
+ /* XXX crashed_ram_end is wrong, since it may be beyond
+ * the memory_limit, it will need to be adjusted. */
+ lmb_reserve(base, size);
+
+ phyp_dump_info->init_reserve_start = base;
+ phyp_dump_info->init_reserve_size = size;
+ }
+ else {
+ size = phyp_dump_info->cpu_state_size +
+ phyp_dump_info->hpte_region_size +
+ PHYP_DUMP_RMR_END;
+ base = lmb_end_of_DRAM() - size;
+ lmb_reserve(base, size);
+ phyp_dump_info->init_reserve_start = base;
+ phyp_dump_info->init_reserve_size = size;
+ }
+}
+#else
+static inline void __init reserve_crashed_mem(void) {}
+#endif /* CONFIG_PHYP_DUMP */
+
+
void __init early_init_devtree(void *params)
{
DBG(" -> early_init_devtree(%p)\n", params);
@@ -1022,6 +1069,8 @@ void __init early_init_devtree(void *par
/* Some machines might need RTAS info for debugging, grab it now. */
of_scan_flat_dt(early_init_dt_scan_rtas, NULL);
#endif
+ /* scan tree to see if dump occured during last boot */
+ of_scan_flat_dt(early_init_dt_scan_phyp_dump, NULL);
/* Retrieve various informations from the /chosen node of the
* device-tree, including the platform type, initrd location and
@@ -1043,6 +1092,7 @@ void __init early_init_devtree(void *par
reserve_kdump_trampoline();
reserve_crashkernel();
early_reserve_mem();
+ reserve_crashed_mem();
lmb_enforce_memory_limit(memory_limit);
lmb_analyze();
Index: 2.6.24-rc5/arch/powerpc/kernel/rtas.c
===================================================================
--- 2.6.24-rc5.orig/arch/powerpc/kernel/rtas.c 2008-02-12 16:11:44.000000000 -0600
+++ 2.6.24-rc5/arch/powerpc/kernel/rtas.c 2008-02-12 16:12:45.000000000 -0600
@@ -39,6 +39,7 @@
#include <asm/syscalls.h>
#include <asm/smp.h>
#include <asm/atomic.h>
+#include <asm/phyp_dump.h>
struct rtas_t rtas = {
.lock = SPIN_LOCK_UNLOCKED
@@ -883,6 +884,37 @@ void __init rtas_initialize(void)
#endif
}
+int __init early_init_dt_scan_phyp_dump(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+#ifdef CONFIG_PHYP_DUMP
+ const unsigned int *sizes;
+
+ phyp_dump_info->phyp_dump_configured = 0;
+ phyp_dump_info->phyp_dump_is_active = 0;
+
+ if (depth != 1 || strcmp(uname, "rtas") != 0)
+ return 0;
+
+ if (of_get_flat_dt_prop(node, "ibm,configure-kernel-dump", NULL))
+ phyp_dump_info->phyp_dump_configured++;
+
+ if (of_get_flat_dt_prop(node, "ibm,dump-kernel", NULL))
+ phyp_dump_info->phyp_dump_is_active++;
+
+ sizes = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes", NULL);
+ if (!sizes)
+ return 0;
+
+ if (sizes[0] == 1)
+ phyp_dump_info->cpu_state_size = *((unsigned long *)&sizes[1]);
+
+ if (sizes[3] == 2)
+ phyp_dump_info->hpte_region_size = *((unsigned long *)&sizes[4]);
+#endif
+ return 1;
+}
+
int __init early_init_dt_scan_rtas(unsigned long node,
const char *uname, int depth, void *data)
{
Index: 2.6.24-rc5/include/asm-powerpc/rtas.h
===================================================================
--- 2.6.24-rc5.orig/include/asm-powerpc/rtas.h 2008-02-12 16:09:48.000000000 -0600
+++ 2.6.24-rc5/include/asm-powerpc/rtas.h 2008-02-12 16:12:45.000000000 -0600
@@ -183,6 +183,9 @@ extern unsigned int rtas_busy_delay(int
extern int early_init_dt_scan_rtas(unsigned long node,
const char *uname, int depth, void *data);
+int early_init_dt_scan_phyp_dump(unsigned long node,
+ const char *uname, int depth, void *data);
+
extern void pSeries_log_error(char *buf, unsigned int err_type, int fatal);
^ permalink raw reply
* Re: [PATCH 6/8] pseries: phyp dump: Invalidate and print dump areas.
From: Manish Ahuja @ 2008-02-12 16:32 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <20080212211820.439dad00.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi Manish,
>
> On Tue, 12 Feb 2008 01:18:22 -0600 Manish Ahuja <ahuja@austin.ibm.com> wrote:
>> -static void
>> -release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
>> +static
>> +void release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
>
> Cosmetic changes like this should normally be put in separate patch as
> they just distract from a real review (which this isn't :-))
>
Okay, will do from future.
^ permalink raw reply
* Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
From: Benjamin Herrenschmidt @ 2008-02-12 21:04 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <1202460043.7079.157.camel@pasglop>
On Fri, 2008-02-08 at 19:40 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > - couple of fixes and preparatory patches
> >
> > - rework of PowerMac media-bay support ([un]register IDE devices instead of
> > [un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
>
> Interesting... I was thinking about doing a full remove of the device at
> a higher level instead but I suppose what you propose is easier.
>
> I'll have a look & test next week hopefully.
Also, the above would have the advantage of not relying on drivers/ide
infrastructure, and thus working with libata (once somebody has ported
pmac ide to libata).
Ben.
^ permalink raw reply
* Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
From: Benjamin Herrenschmidt @ 2008-02-12 20:59 UTC (permalink / raw)
To: Gabriel Paubert
Cc: linux-ide, linux-kernel, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <20080212114905.GA9940@iram.es>
On Tue, 2008-02-12 at 12:49 +0100, Gabriel Paubert wrote:
> On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote:
> >
> > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > - couple of fixes and preparatory patches
> > >
> > > - rework of PowerMac media-bay support ([un]register IDE devices instead of
> > > [un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
> >
> > Interesting... I was thinking about doing a full remove of the device at
> > a higher level instead but I suppose what you propose is easier.
>
> Well, I have serious problem on a Pegasos which appeared some time
> between 2.6.24 and 2.6.25-rc1: at boot I get an infinite string of
>
> hdb: empty DMA table?
>
> I'm trying to bisect it right now.
Pegasos doesn't use the pmac ide which is what we were discussing. It
uses a VIA IDE which uses a normal PRD table. So something else must
have broken...
Ben.
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Grant Likely @ 2008-02-12 20:43 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann, David Gibson
In-Reply-To: <47B1F763.9000404@freescale.com>
On Feb 12, 2008 12:45 PM, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
> > Then use a local version in the data; don't overload the purpose of
> > the dtb version.
>
> I don't know what you mean by that.
I'm saying that the dtb version is to describe the binary format of
the dtb; not the content. Using it to say "this dtb contains data
that needs to be massaged in a particular way" is using (overloading)
the dtb version for a different and orthogonal purpose.
> > And when something comes along that doesn't fit into that model? Add
> > more constructs?
>
> If necessary, yes. What's wrong with expanding the power of the device tree
> format when it solves more problems?
Nothing at all; but the flipside of that is it should only be done
when it is the appropriate place to do so.
> > I say better to handle that within the existing data
> > format.
>
> And the point I've been trying to make is that we have real problems today that
> cannot be solved elegantly with the current device tree problem. Having
> board-specific code in U-Boot that is hard-coded to look for specific nodes in
> the device tree, and making hard-coded edits on that tree, is *not* elegant.
>
> > If we get it wrong, then we just change the affected device
> > trees and boot loaders. We don't have to upgrade every platform that
> > uses dt blobs.
>
> Only the platforms that need to take advantage of conditional nodes need to be
> upgraded in the first place. Most platforms are happy with just one device tree.
>
> >> That's okay too, except that if we just add additional nodes that describe
> >> conditions, then we need to make sure that whatever parses that DTB must also
> >> parse those additional nodes. The only way to do that is create a new version
> >> number, like 18, which is marked as being incompatible with the current version
> >> (17). Otherwise, a person could pass that DTB to an old version of U-Boot, and
> >> U-boot will just pass it on to the kernel as-is.
> >
> > That's not a dtb version issue. That is a dtb content issue.
>
> Technically, that's true, but ...
>
> > It does
> > not warrant changing the dtb version number.
>
> Then how do you solve the problem of passing a device tree to a boot loader that
> does not know how to parse it properly? A device tree with these additional
> nodes *must* be parsed by a boot loader that is aware of them. Otherwise, it
> will pass the device tree as-is to the kernel without warning. This is a bad
> thing, and steps should be taken to prevent that. If you can think of a way to
> make this happen without changing the version number, I'd love to hear. All I'm
> hearing from you now is denial that this is a problem.
I do not deny that it is a problem. I assert that the proposed
solution does not at all solve the greater problem. Changing the DTB
version solves the specific problem of a dtb that needs to be modified
being passed into to an older version of u-boot. This is a very
narrow use case and it is not the greater problem. The greater
problem is passing the wrong device tree either because of a
u-boot/dtb mismatch or the dtb is for an entirely different board.
Changing the dtb version is just a bandaid fix that makes things more
complex and only provides the illusion of a solution.
Your suggestion of checking for specific property values is a far more
reliable and workable solution.
> > Fair enough, and it is also reasonable for the boot loader to look for
> > a specific property name to decide how to massage the data structure.
> > This alone does not require a dtb version change.
>
> Current versions of U-Boot do not know how to do this. So again, I'm asking
> you: how do you solve the problem of passing a device tree with additional nodes
> to a boot loader that does not know how to parse them properly? How do you
> prevent that old U-Boot from ignoring those nodes?
We don't. We've got no sane way to do so (except perhaps going ahead
and renaming the soc nodes from soc<chip>@addr to soc@addr. That will
break almost all existing ports. :-). I do not agree that changing
the dtb version is a sane change.
For older u-boots, this is a configuration management problem. Just
like for current platforms we need to make sure that the kernel is
compiled for the correct platform before trying to boot. There are no
protections in u-boot to make sure the kernel image matches the arch
yet it all works just fine.
> > I'm not missing the point because I disagree entirely with the
> > addition of conditional expressions to the device tree. Instead, I
> > think properties can be added to the device tree that a bootloader can
> > look for and decide to apply conditions against them which means the
> > conditions are encoded in the boot loader, not the device tree. (the
> > device tree simply contains data which supports the boot loaders
> > decision; a rather different thing).
>
> Then why bother passing a DTB to the boot loader at all? Why not just have the
> boot loader create the device tree from scratch?
There is absolutely no reason for the boot loader not to create the
device tree from scratch. dtbs are just more convenient to get up and
running with. OpenFirmware has been doing that from day one and it
works quite well.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* ROOTFS on NAND FLASH is too slow?
From: DI BACCO ANTONIO - technolabs @ 2008-02-12 19:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
Hi,
I have board with a nand flash. It is connected to the micro (ATMEL L9260) via a serial bus and not a parallel one as with NOR flash.
Is feasible to have the rootfs on the nand flash? Is not too slow? What is usually done in this case? Is not better to copy the whole filesystem in RAM?
Thank you,
Antonio.
[-- Attachment #2: Type: text/html, Size: 729 bytes --]
^ permalink raw reply
* Re: DTS question - MPC5200b
From: Grant Likely @ 2008-02-12 19:47 UTC (permalink / raw)
To: Jarno Manninen; +Cc: linuxppc-dev
In-Reply-To: <200802122007.41259.jarno.manninen@tut.fi>
On Feb 12, 2008 11:07 AM, Jarno Manninen <jarno.manninen@tut.fi> wrote:
> On Tuesday 12 February 2008 19:37:07 Nick wrote:
>
> > How do I specify the timer based on the cell-index?
>
> I don't know if that is possible to do in a one call, but maybe using the
> approach from mpc52xx_uart might help?
>
> --clip--
> for_each_node_by_type(np, "serial") {
> if (!of_match_node(mpc52xx_uart_of_match, np))
> continue;
>
> /* Is a particular device number requested? */
> devno = of_get_property(np, "port-number", NULL);
> mpc52xx_uart_of_assign(of_node_get(np), devno ? *devno : -1);
> }
> --clip--
This code has actually changed in 2.6.25-rc1. It is now
for_each_matching_node() and the call to of_match_node is no longer
necessary.
>
> And change serial->gpt, port-number to cell-index and add some logic to
> select the devices you want.
use 'reg' instead. cell-index (and port-number for that matter) will
probably be going away in the near future.
> Or if you wan't to do it a bit differently you
> could add a pseudo device outside the main tree like
>
> mydev {
> gpt-dev = <&the_gpt_dev>:
> };
>
> And get it that way. However I don't know if this is recommended approach, but
> I've used it for some simple stuff like binding gpt in PWM mode to
> framebuffer backlight, along with power-pin.
Yes, this is a good approach too.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Timur Tabi @ 2008-02-12 19:45 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Arnd Bergmann, David Gibson
In-Reply-To: <fa686aa40802121134i4bc0c9bep30920a5afdeb240c@mail.gmail.com>
Grant Likely wrote:
> Then use a local version in the data; don't overload the purpose of
> the dtb version.
I don't know what you mean by that.
> I don't think it is yet possible to define a reasonable 'standard
> manner' for massaging device trees. There are going to be a lot of
> experiments and false starts before we come to consensus on common
> manipulations which everyone will want to have access too. Therefore
> for the time being dtb fixups and manipulations will remain a board
> specific thing.
That's okay with me. I'm just proposing one method that I like, and Scott
proposed another.
> And when something comes along that doesn't fit into that model? Add
> more constructs?
If necessary, yes. What's wrong with expanding the power of the device tree
format when it solves more problems?
> I say better to handle that within the existing data
> format.
And the point I've been trying to make is that we have real problems today that
cannot be solved elegantly with the current device tree problem. Having
board-specific code in U-Boot that is hard-coded to look for specific nodes in
the device tree, and making hard-coded edits on that tree, is *not* elegant.
> If we get it wrong, then we just change the affected device
> trees and boot loaders. We don't have to upgrade every platform that
> uses dt blobs.
Only the platforms that need to take advantage of conditional nodes need to be
upgraded in the first place. Most platforms are happy with just one device tree.
>> That's okay too, except that if we just add additional nodes that describe
>> conditions, then we need to make sure that whatever parses that DTB must also
>> parse those additional nodes. The only way to do that is create a new version
>> number, like 18, which is marked as being incompatible with the current version
>> (17). Otherwise, a person could pass that DTB to an old version of U-Boot, and
>> U-boot will just pass it on to the kernel as-is.
>
> That's not a dtb version issue. That is a dtb content issue.
Technically, that's true, but ...
> It does
> not warrant changing the dtb version number.
Then how do you solve the problem of passing a device tree to a boot loader that
does not know how to parse it properly? A device tree with these additional
nodes *must* be parsed by a boot loader that is aware of them. Otherwise, it
will pass the device tree as-is to the kernel without warning. This is a bad
thing, and steps should be taken to prevent that. If you can think of a way to
make this happen without changing the version number, I'd love to hear. All I'm
hearing from you now is denial that this is a problem.
>>> We've already got that issue. If you pass the device tree for the
>>> wrong board it will still validate correctly, but the board is not
>>> going to boot.
>> There's nothing stopping U-Boot today from scanning the device tree and making
>> sure the SOC's compatible node is correct. That's not currently done, but it
>> could be.
>
> Fair enough, and it is also reasonable for the boot loader to look for
> a specific property name to decide how to massage the data structure.
> This alone does not require a dtb version change.
Current versions of U-Boot do not know how to do this. So again, I'm asking
you: how do you solve the problem of passing a device tree with additional nodes
to a boot loader that does not know how to parse them properly? How do you
prevent that old U-Boot from ignoring those nodes?
> I'm not missing the point because I disagree entirely with the
> addition of conditional expressions to the device tree. Instead, I
> think properties can be added to the device tree that a bootloader can
> look for and decide to apply conditions against them which means the
> conditions are encoded in the boot loader, not the device tree. (the
> device tree simply contains data which supports the boot loaders
> decision; a rather different thing).
Then why bother passing a DTB to the boot loader at all? Why not just have the
boot loader create the device tree from scratch?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Howto get __log_buf on a Xilinx FPGA
From: Ricardo Ayres Severo @ 2008-02-12 19:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40802121136k57a2ea20n446cfe6183ca7909@mail.gmail.com>
Grant,
thanks, I'll do this.
On Feb 12, 2008 5:36 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Feb 12, 2008 12:30 PM, Ricardo Ayres Severo <severo.ricardo@gmail.com> wrote:
> >
> > Linux/PPC load: console=ttyS0,9600
> >
> > Uncompressing Linux...done.
> >
> > Now booting the kernel
> > ---output end---
> >
> > after a while I stop the debugger and type rst in xmd.
> > then I ask gdb to dump the memory from position 0x1f3d5c to 0x1f3fff
> > and only trash is returned.
> >
> > What am I doing wrong? Or the kernel really isn't being executed?
>
> In this case it seems like the kernel isn't even booting. You can try
> inserting progress markers into the kernel boot path to spit single
> characters out of the uartlite port.
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Ricardo Ayres Severo <severo.ricardo@gmail.com>
^ permalink raw reply
* Re: Howto get __log_buf on a Xilinx FPGA
From: Grant Likely @ 2008-02-12 19:36 UTC (permalink / raw)
To: Ricardo Ayres Severo; +Cc: linuxppc-embedded
In-Reply-To: <5ee408090802121130m2a641637s4b75a8a144ec2efc@mail.gmail.com>
On Feb 12, 2008 12:30 PM, Ricardo Ayres Severo <severo.ricardo@gmail.com> wrote:
>
> Linux/PPC load: console=ttyS0,9600
>
> Uncompressing Linux...done.
>
> Now booting the kernel
> ---output end---
>
> after a while I stop the debugger and type rst in xmd.
> then I ask gdb to dump the memory from position 0x1f3d5c to 0x1f3fff
> and only trash is returned.
>
> What am I doing wrong? Or the kernel really isn't being executed?
In this case it seems like the kernel isn't even booting. You can try
inserting progress markers into the kernel boot path to spit single
characters out of the uartlite port.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Grant Likely @ 2008-02-12 19:34 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann, David Gibson
In-Reply-To: <47B1EEA8.4040904@freescale.com>
On Feb 12, 2008 12:08 PM, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
> > On Feb 12, 2008 8:44 AM, Timur Tabi <timur@freescale.com> wrote:
> > This requires coordination and
> > documentation, but id does not requires special formatting or
> > versioning of the device tree blob.
>
> Unless the mechanism by which the designer ensures that the boot loader presents
> a proper device tree to the kernel requires special versioning.
Then use a local version in the data; don't overload the purpose of
the dtb version.
> > The dtb is a data structure, not a programming language.
>
> But we have a problem with the current device tree definition that makes it
> difficult to use in real-world situations. The current "solution" is to have
> multiple DTBs, each one covering a different variant of the hardware. My
> proposal is to expand the definition of the DTB to allow the boot loader to
> modify it in a standard manner. I believe that such a change would be both
> useful and not problematic.
I don't think it is yet possible to define a reasonable 'standard
manner' for massaging device trees. There are going to be a lot of
experiments and false starts before we come to consensus on common
manipulations which everyone will want to have access too. Therefore
for the time being dtb fixups and manipulations will remain a board
specific thing.
Plus, even when we do have a common set of manipulations, they can be
implemented with property values. It is not something that needs to
change the dtb version.
> > I think it
> > is a slippery slope to try and encode conditionals into the structure;
>
> Perhaps, which is why I said it should be simple conditionals - two values and a
> comparison.
And when something comes along that doesn't fit into that model? Add
more constructs? I say better to handle that within the existing data
format. If we get it wrong, then we just change the affected device
trees and boot loaders. We don't have to upgrade every platform that
uses dt blobs.
> > but it is entirely reasonable to encode *data* into the dt that helps
> > make those conditional decisions.
>
> That's okay too, except that if we just add additional nodes that describe
> conditions, then we need to make sure that whatever parses that DTB must also
> parse those additional nodes. The only way to do that is create a new version
> number, like 18, which is marked as being incompatible with the current version
> (17). Otherwise, a person could pass that DTB to an old version of U-Boot, and
> U-boot will just pass it on to the kernel as-is.
That's not a dtb version issue. That is a dtb content issue. It does
not warrant changing the dtb version number.
> > We've already got that issue. If you pass the device tree for the
> > wrong board it will still validate correctly, but the board is not
> > going to boot.
>
> There's nothing stopping U-Boot today from scanning the device tree and making
> sure the SOC's compatible node is correct. That's not currently done, but it
> could be.
Fair enough, and it is also reasonable for the boot loader to look for
a specific property name to decide how to massage the data structure.
This alone does not require a dtb version change.
> > The device tree must match what the bootloader
> > expects. Changing the version number will do nothing to help this.
> > The version number ensures that the tree is parsable. It does not
> > ensure that it is correct.
>
> I think you're missing the point. If we add conditional expressions to the
> device tree (whether attached to a node or as part of a separate node or
> whatever), we must also add a mechanism to ensure that these conditions are
> parsed by the boot loader. As far as I know, the only mechanism that can do
> this is the version identifier.
I'm not missing the point because I disagree entirely with the
addition of conditional expressions to the device tree. Instead, I
think properties can be added to the device tree that a bootloader can
look for and decide to apply conditions against them which means the
conditions are encoded in the boot loader, not the device tree. (the
device tree simply contains data which supports the boot loaders
decision; a rather different thing).
Finally, it is *always* required that the user (or installer) know
enough to pass the correct device tree to the correct board. No
amount of versioning at the dtb level is going to change this
situation.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Howto get __log_buf on a Xilinx FPGA
From: Ricardo Ayres Severo @ 2008-02-12 19:30 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm trying to boot linux 2.6.24 on a XUP Virtex II Pro evaluation
board. It uncompresses ok but doesn't show nothing more on the
console. I tried to change the console to ttyS0 and ttyUL0. Now I want
to see the __log_buf but I don't if I am doing it the right way, it
only returns trash. What I'm doing is the following:
$ grep __log_buf System.map
c01f3d5c b __log_buf
$ xmd -xmp system.xmp -opt etc/xmd_ppc405_0.opt
(xmd starts ok, mdm is not enabled)
$ powerpc-eabi-gdb arch/ppc/boot/images/zImage.elf
(click on run, the image is loaded and started)
this is the output on the terminal:
---output start---
loaded at: 00400000 004F119C
board data at: 00000000 0000007C
relocated to: 00404048 004040C4
zimage at: 00404E34 004EE12C
avail ram: 004F2000 7C9E2378
Linux/PPC load: console=ttyS0,9600
Uncompressing Linux...done.
Now booting the kernel
---output end---
after a while I stop the debugger and type rst in xmd.
then I ask gdb to dump the memory from position 0x1f3d5c to 0x1f3fff
and only trash is returned.
What am I doing wrong? Or the kernel really isn't being executed?
Thanks,
--
Ricardo Ayres Severo <severo.ricardo@gmail.com>
^ permalink raw reply
* Re: DTS question - MPC5200b
From: Jarno Manninen @ 2008-02-12 18:07 UTC (permalink / raw)
To: Nick; +Cc: linuxppc-dev
In-Reply-To: <47B1D943.6020708@rogers.com>
On Tuesday 12 February 2008 19:37:07 Nick wrote:
> How do I specify the timer based on the cell-index?
I don't know if that is possible to do in a one call, but maybe using the
approach from mpc52xx_uart might help?
--clip--
for_each_node_by_type(np, "serial") {
if (!of_match_node(mpc52xx_uart_of_match, np))
continue;
/* Is a particular device number requested? */
devno = of_get_property(np, "port-number", NULL);
mpc52xx_uart_of_assign(of_node_get(np), devno ? *devno : -1);
}
--clip--
And change serial->gpt, port-number to cell-index and add some logic to
select the devices you want. Or if you wan't to do it a bit differently you
could add a pseudo device outside the main tree like
mydev {
gpt-dev = <&the_gpt_dev>:
};
And get it that way. However I don't know if this is recommended approach, but
I've used it for some simple stuff like binding gpt in PWM mode to
framebuffer backlight, along with power-pin.
Please correct any mistakes you who know better.
- Jarno
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Scott Wood @ 2008-02-12 19:10 UTC (permalink / raw)
To: Grant Likely; +Cc: LinuxPPC-dev, Sean MacLennan
In-Reply-To: <fa686aa40802121103s650fc10by197e9d5b65f09ceb@mail.gmail.com>
Grant Likely wrote:
> On Feb 12, 2008 11:52 AM, Scott Wood <scottwood@freescale.com> wrote:
>> It'd be nice if we could pass in a flag to tell it not to try to find
>> additional consecutive chips in the mapping... It's a shame to have
>> probable chips, and still have to know how big they are anyway.
>
> That is the job of the boot loader or wrapper.
Hmm? All I meant was that it'd be nice if there were an option in the
Linux mtd code to disable the "look for another chip and cause a machine
check if it isn't there" functionality. It was an aside from the
dts-variant issue.
> The whole concept of
> the device tree is that by the time it gets to the kernel it is an
> accurate representation of the hardware; not a list of things which
> might or might not be present.
But we don't generally include things which can be probed in a standard
manner... which includes flash size.
-Scott
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Timur Tabi @ 2008-02-12 19:08 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Arnd Bergmann, David Gibson
In-Reply-To: <fa686aa40802121058u6c6e4ba9s3ced2e35950745ea@mail.gmail.com>
Grant Likely wrote:
> On Feb 12, 2008 8:44 AM, Timur Tabi <timur@freescale.com> wrote:
>> Arnd Bergmann wrote:
>>
>>> On Tuesday 12 February 2008, David Gibson wrote:
>>>> Or to expand. It's relatively easy now to just include multiple nodes
>>>> in the tree and either delete or nop some of them out conditionally
>>>> using libfdt.
>> Yes, but what better place to store the conditions than in the device tree
>> itself? How would libfdt know where the conditions are? Do you want to have
>> two binary blobs?
>
> The transient state of the dts before it is handed to the kernel
> proper is almost irrelevant. It is totally reasonable to add in
> whatever properties/nodes that are needed to *eventually* describe the
> hardware correctly. Heck, we already do this will all dts files that
> go through u-boot is a simple sense. We put placeholder properties
> for mac addresses and bus frequencies, but u-boot fills them in.
I agree with that.
> However, if a designer does write a device tree containing more nodes
> than is needed, then it is also the responsibility of that designer to
> make sure the boot loader can use that tree to generate a real
> description of hardware.
No problem here.
> This requires coordination and
> documentation, but id does not requires special formatting or
> versioning of the device tree blob.
Unless the mechanism by which the designer ensures that the boot loader presents
a proper device tree to the kernel requires special versioning.
> The dtb is a data structure, not a programming language.
But we have a problem with the current device tree definition that makes it
difficult to use in real-world situations. The current "solution" is to have
multiple DTBs, each one covering a different variant of the hardware. My
proposal is to expand the definition of the DTB to allow the boot loader to
modify it in a standard manner. I believe that such a change would be both
useful and not problematic.
> I think it
> is a slippery slope to try and encode conditionals into the structure;
Perhaps, which is why I said it should be simple conditionals - two values and a
comparison.
> but it is entirely reasonable to encode *data* into the dt that helps
> make those conditional decisions.
That's okay too, except that if we just add additional nodes that describe
conditions, then we need to make sure that whatever parses that DTB must also
parse those additional nodes. The only way to do that is create a new version
number, like 18, which is marked as being incompatible with the current version
(17). Otherwise, a person could pass that DTB to an old version of U-Boot, and
U-boot will just pass it on to the kernel as-is.
> We've already got that issue. If you pass the device tree for the
> wrong board it will still validate correctly, but the board is not
> going to boot.
There's nothing stopping U-Boot today from scanning the device tree and making
sure the SOC's compatible node is correct. That's not currently done, but it
could be.
> The device tree must match what the bootloader
> expects. Changing the version number will do nothing to help this.
> The version number ensures that the tree is parsable. It does not
> ensure that it is correct.
I think you're missing the point. If we add conditional expressions to the
device tree (whether attached to a node or as part of a separate node or
whatever), we must also add a mechanism to ensure that these conditions are
parsed by the boot loader. As far as I know, the only mechanism that can do
this is the version identifier.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Grant Likely @ 2008-02-12 19:03 UTC (permalink / raw)
To: Scott Wood; +Cc: LinuxPPC-dev, Sean MacLennan
In-Reply-To: <20080212185251.GB4042@loki.buserror.net>
On Feb 12, 2008 11:52 AM, Scott Wood <scottwood@freescale.com> wrote:
> On Mon, Feb 11, 2008 at 07:41:07PM -0500, Sean MacLennan wrote:
> > David Gibson wrote:
> > > Err.. now I'm doubly confused. Initially I thought you'd need to
> > > change the size part of reg somewhere, but your description above just
> > > convinced me you didn't (because you were essentially just shifting a
> > > 4M map up into the high rather than low 4M of the 64M space). Now
> > > you're saying you do..
> > >
> > If you tell the mtd driver that the flash is 64M, when it is really 4M,
> > it goes oops. So you do have to get the size right in the reg field.
>
> It'd be nice if we could pass in a flag to tell it not to try to find
> additional consecutive chips in the mapping... It's a shame to have
> probable chips, and still have to know how big they are anyway.
That is the job of the boot loader or wrapper. The whole concept of
the device tree is that by the time it gets to the kernel it is an
accurate representation of the hardware; not a list of things which
might or might not be present.
I see two choices here;
1. have a different .dts variant for each board config (or a .dts with
macros that can generate different .dtb variants)
2. make the boot code massage the tree so it is accurate before it
gets to the kernel.
Either way, the mtd driver must be able to trust that the dt is
correct and complete.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Grant Likely @ 2008-02-12 18:58 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann, David Gibson
In-Reply-To: <47B1BEE7.4050808@freescale.com>
On Feb 12, 2008 8:44 AM, Timur Tabi <timur@freescale.com> wrote:
> Arnd Bergmann wrote:
>
> > On Tuesday 12 February 2008, David Gibson wrote:
> >> Or to expand. It's relatively easy now to just include multiple nodes
> >> in the tree and either delete or nop some of them out conditionally
> >> using libfdt.
>
> Yes, but what better place to store the conditions than in the device tree
> itself? How would libfdt know where the conditions are? Do you want to have
> two binary blobs?
The transient state of the dts before it is handed to the kernel
proper is almost irrelevant. It is totally reasonable to add in
whatever properties/nodes that are needed to *eventually* describe the
hardware correctly. Heck, we already do this will all dts files that
go through u-boot is a simple sense. We put placeholder properties
for mac addresses and bus frequencies, but u-boot fills them in.
However, if a designer does write a device tree containing more nodes
than is needed, then it is also the responsibility of that designer to
make sure the boot loader can use that tree to generate a real
description of hardware. This requires coordination and
documentation, but id does not requires special formatting or
versioning of the device tree blob.
The dtb is a data structure, not a programming language. I think it
is a slippery slope to try and encode conditionals into the structure;
but it is entirely reasonable to encode *data* into the dt that helps
make those conditional decisions.
> >> But the conditional logic should be in the manipulating
> >> agent (u-boot or bootwrapper or whatever), there's no way we're going
> >> to require a conditional expression parser to interpret the device
> >> tree blob itself.
>
> I think it's a great feature that solves a lot of problems, and it does so in an
> elegant and efficient manner. I look forward to trying to change your mind when
> I get around to implementing it.
I agree with David here; logic belongs in the agent code, not the data
structure.
> > How about making the logic to nop out nodes a little more generic
> > without changes to the binary format?
> > E.g. you could have a "linux,conditional-node" property in the device
> > tree whose value is compared to a HW configuration specific string.
>
> The problem with this is that if you use a version of libfdt that does not
> understand "linux,conditional-node", then your device tree will be wrong,
> because it could contain nodes that don't belong. We would need a new,
> incompatible version number for the device tree to make sure that this doesn't
> happen, even though nothing has changed in the binary layout of the tree.
We've already got that issue. If you pass the device tree for the
wrong board it will still validate correctly, but the board is not
going to boot. The device tree must match what the bootloader
expects. Changing the version number will do nothing to help this.
The version number ensures that the tree is parsable. It does not
ensure that it is correct.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox