* Re: What is this "flat device tree"
From: Josh Boyer @ 2006-09-07 14:49 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <45002E72.8080608@cambridgebroadband.com>
On Thu, 2006-09-07 at 15:36 +0100, Alex Zeffertt wrote:
> Can anybody explain to me what the "flat device tree" is? The phrase comes up
> often but I can't find a definition for it anywhere on the web.
See Documentation/powerpc/booting-without-of.txt in the kernel tree.
It's basically a representation of an Open Firmware device tree that has
been flattened and given to the kernel when it boots. For platforms
without Open Firmware, it needs to be constructed by the boot loader, or
using the Device Tree Compiler (DTC).
josh
^ permalink raw reply
* Re: [PATCH] [v3] PPC 4xx: Enable XMON on PPC 4xx boards
From: Matt Porter @ 2006-09-07 17:20 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <1157639720.6098.49.camel@zod.rchland.ibm.com>
On Thu, Sep 07, 2006 at 09:35:20AM -0500, Josh Boyer wrote:
> The following patch allows XMON to run on the 4xx platform. Tested on
> Walnut, Ebony, and Nova (440GX based) eval boards. 440EP and 440SP boards
> should work as well. Patch is against 2.6.18-rc6.
>
> Signed-off-by: Josh Boyer <jdub@us.ibm.com>
ACK
Thanks for pointing out that 440SP needed a different case as well.
-Matt
^ permalink raw reply
* Re: [PATCH] [v3] PPC 4xx: Enable XMON on PPC 4xx boards
From: Eugene Surovegin @ 2006-09-07 17:19 UTC (permalink / raw)
To: Josh Boyer; +Cc: paulus, mporter, linuxppc-dev
In-Reply-To: <1157639720.6098.49.camel@zod.rchland.ibm.com>
On Thu, Sep 07, 2006 at 09:35:20AM -0500, Josh Boyer wrote:
[snip]
> --- linux-2.6.orig/arch/ppc/xmon/start.c
> +++ linux-2.6/arch/ppc/xmon/start.c
> @@ -73,6 +73,27 @@ xmon_map_scc(void)
> TXRDY = 0x20;
> RXRDY = 1;
> DLAB = 0x80;
> +#elif defined(CONFIG_440EP)
> + sccd = (volatile unsigned char *) ioremap(0xef600300, 8);
> + sccc = sccd + 5;
> + TXRDY = 0x20;
> + RXRDY = 1;
> + DLAB = 0x80;
> +#elif defined(CONFIG_440SP)
> + sccd = (volatile unsigned char *) ioremap64(0x00000001f0000200ULL, 8);
> + sccc = sccd + 5;
> + TXRDY = 0x20;
> + RXRDY = 1;
> + DLAB = 0x80;
> +#elif defined(CONFIG_44x)
> + /* This is the default for 44x platforms. Any boards that have a
> + different UART address need to be put in cases before this or the
> + port will be mapped incorrectly */
> + sccd = (volatile unsigned char *) ioremap64(0x0000000140000200ULL, 8);
> + sccc = sccd + 5;
> + TXRDY = 0x20;
> + RXRDY = 1;
> + DLAB = 0x80;
There is only one line which is different, why did you put all other
under #ifdef?
Also, all these hardcoded addresses are already available as defines,
why just not use them?
--
Eugene
^ permalink raw reply
* Re: [PATCH] [v3] PPC 4xx: Enable XMON on PPC 4xx boards
From: Josh Boyer @ 2006-09-07 18:08 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: paulus, mporter, linuxppc-dev
In-Reply-To: <20060907171916.GB18929@gate.ebshome.net>
On Thu, 2006-09-07 at 10:19 -0700, Eugene Surovegin wrote:
> On Thu, Sep 07, 2006 at 09:35:20AM -0500, Josh Boyer wrote:
>
> [snip]
>
> > --- linux-2.6.orig/arch/ppc/xmon/start.c
> > +++ linux-2.6/arch/ppc/xmon/start.c
> > @@ -73,6 +73,27 @@ xmon_map_scc(void)
> > TXRDY = 0x20;
> > RXRDY = 1;
> > DLAB = 0x80;
> > +#elif defined(CONFIG_440EP)
> > + sccd = (volatile unsigned char *) ioremap(0xef600300, 8);
> > + sccc = sccd + 5;
> > + TXRDY = 0x20;
> > + RXRDY = 1;
> > + DLAB = 0x80;
> > +#elif defined(CONFIG_440SP)
> > + sccd = (volatile unsigned char *) ioremap64(0x00000001f0000200ULL, 8);
> > + sccc = sccd + 5;
> > + TXRDY = 0x20;
> > + RXRDY = 1;
> > + DLAB = 0x80;
> > +#elif defined(CONFIG_44x)
> > + /* This is the default for 44x platforms. Any boards that have a
> > + different UART address need to be put in cases before this or the
> > + port will be mapped incorrectly */
> > + sccd = (volatile unsigned char *) ioremap64(0x0000000140000200ULL, 8);
> > + sccc = sccd + 5;
> > + TXRDY = 0x20;
> > + RXRDY = 1;
> > + DLAB = 0x80;
>
> There is only one line which is different, why did you put all other
> under #ifdef?
>
> Also, all these hardcoded addresses are already available as defines,
> why just not use them?
Blindly following the existing convention. I agree it's ugly. I'll fix
it up shortly and send out another patch. It'll also fix 440SPE, which
also has a different UART address.
josh
^ permalink raw reply
* [PATCH] [v4] PPC 4xx: Enable XMON on PPC 4xx boards
From: Josh Boyer @ 2006-09-07 18:27 UTC (permalink / raw)
To: mporter, paulus; +Cc: linuxppc-dev
The following patch allows XMON to run on the 4xx platform. Tested on
Walnut, Ebony, and Nova (440GX based) eval boards. 440EP, 440SP, and
440SPE boards should work as well. Patch is against 2.6.18-rc6.
Signed-off-by: Josh Boyer <jdub@us.ibm.com>
---
arch/ppc/xmon/start.c | 28 ++++++++++++++++++----------
arch/ppc/xmon/xmon.c | 26 ++++++++++++++++++++------
2 files changed, 38 insertions(+), 16 deletions(-)
--- linux-2.6.orig/arch/ppc/xmon/xmon.c
+++ linux-2.6/arch/ppc/xmon/xmon.c
@@ -153,6 +153,12 @@ static int xmon_trace[NR_CPUS];
#define SSTEP 1 /* stepping because of 's' command */
#define BRSTEP 2 /* stepping over breakpoint */
+#ifdef CONFIG_4xx
+#define MSR_SSTEP_ENABLE 0x200
+#else
+#define MSR_SSTEP_ENABLE 0x400
+#endif
+
static struct pt_regs *xmon_regs[NR_CPUS];
extern inline void sync(void)
@@ -211,6 +217,14 @@ static void get_tb(unsigned *p)
p[1] = lo;
}
+static inline void xmon_enable_sstep(struct pt_regs *regs)
+{
+ regs->msr |= MSR_SSTEP_ENABLE;
+#ifdef CONFIG_4xx
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM);
+#endif
+}
+
int xmon(struct pt_regs *excp)
{
struct pt_regs regs;
@@ -254,10 +268,10 @@ int xmon(struct pt_regs *excp)
cmd = cmds(excp);
if (cmd == 's') {
xmon_trace[smp_processor_id()] = SSTEP;
- excp->msr |= 0x400;
+ xmon_enable_sstep(excp);
} else if (at_breakpoint(excp->nip)) {
xmon_trace[smp_processor_id()] = BRSTEP;
- excp->msr |= 0x400;
+ xmon_enable_sstep(excp);
} else {
xmon_trace[smp_processor_id()] = 0;
insert_bpts();
@@ -298,7 +312,7 @@ xmon_bpt(struct pt_regs *regs)
remove_bpts();
excprint(regs);
xmon_trace[smp_processor_id()] = BRSTEP;
- regs->msr |= 0x400;
+ xmon_enable_sstep(regs);
} else {
xmon(regs);
}
@@ -385,7 +399,7 @@ insert_bpts(void)
}
store_inst((void *) bp->address);
}
-#if !defined(CONFIG_8xx)
+#if ! (defined(CONFIG_8xx) || defined(CONFIG_4xx))
if (dabr.enabled)
set_dabr(dabr.address);
if (iabr.enabled)
@@ -400,7 +414,7 @@ remove_bpts(void)
struct bpt *bp;
unsigned instr;
-#if !defined(CONFIG_8xx)
+#if ! (defined(CONFIG_8xx) || defined(CONFIG_4xx))
set_dabr(0);
set_iabr(0);
#endif
@@ -677,7 +691,7 @@ bpt_cmds(void)
cmd = inchar();
switch (cmd) {
-#if !defined(CONFIG_8xx)
+#if ! (defined(CONFIG_8xx) || defined(CONFIG_4xx))
case 'd':
mode = 7;
cmd = inchar();
--- linux-2.6.orig/arch/ppc/xmon/start.c
+++ linux-2.6/arch/ppc/xmon/start.c
@@ -15,6 +15,7 @@
#include <asm/processor.h>
#include <asm/delay.h>
#include <asm/btext.h>
+#include <asm/ibm4xx.h>
static volatile unsigned char *sccc, *sccd;
unsigned int TXRDY, RXRDY, DLAB;
@@ -57,23 +58,30 @@ static struct sysrq_key_op sysrq_xmon_op
void
xmon_map_scc(void)
{
-#ifdef CONFIG_PPC_PREP
- volatile unsigned char *base;
-
-#elif defined(CONFIG_GEMINI)
+#if defined(CONFIG_GEMINI)
/* should already be mapped by the kernel boot */
- sccc = (volatile unsigned char *) 0xffeffb0d;
sccd = (volatile unsigned char *) 0xffeffb08;
- TXRDY = 0x20;
- RXRDY = 1;
- DLAB = 0x80;
#elif defined(CONFIG_405GP)
- sccc = (volatile unsigned char *)0xef600305;
sccd = (volatile unsigned char *)0xef600300;
+#elif defined(CONFIG_440EP)
+ sccd = (volatile unsigned char *) ioremap(PPC440EP_UART0_ADDR, 8);
+#elif defined(CONFIG_440SP)
+ sccd = (volatile unsigned char *) ioremap64(PPC440SP_UART0_ADDR, 8);
+#elif defined(CONFIG_440SPE)
+ sccd = (volatile unsigned char *) ioremap64(PPC440SPE_UART0_ADDR, 8);
+#elif defined(CONFIG_44x)
+ /* This is the default for 44x platforms. Any boards that have a
+ different UART address need to be put in cases before this or the
+ port will be mapped incorrectly */
+ sccd = (volatile unsigned char *) ioremap64(PPC440GP_UART0_ADDR, 8);
+#endif /* platform */
+
+#ifndef CONFIG_PPC_PREP
+ sccc = sccd + 5;
TXRDY = 0x20;
RXRDY = 1;
DLAB = 0x80;
-#endif /* platform */
+#endif
register_sysrq_key('x', &sysrq_xmon_op);
}
^ permalink raw reply
* Re: common flatdevtree code
From: Mark A. Greer @ 2006-09-07 18:27 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1157615011.18137.14.camel@diesel>
Hi Hollis.
On Thu, Sep 07, 2006 at 02:43:31AM -0500, Hollis Blanchard wrote:
> Thanks Mark!
>
> On Wed, 2006-09-06 at 17:36 -0700, Mark A. Greer wrote:
> > void *ft_find_device(const void *bphp, const char *srch_path)
>
> How about "ft_find_node"?
Sure.
> I renamed that and made a couple other small
> changes. In particular:
> - u8->int
OK.
> - exit and free -> ft_exit and ft_free (so they can be wrapped in
> flatdevtree_env.h)
Makes sense.
> - moved those inlines out of flatdevtree.h, since they don't need to be
> exported
ft_parentize is also used in flatdevtree_misc.c so I think they
should stay in flatdevtree.h.
> I just put up a Mercurial tree. I didn't include your flatdevtree_misc.c
> since it's kernel-specific, and I added a userspace flatdevtree_env.h.
>
> To get the source:
> hg clone http://unsanctioned.org/flatdevtree/hgweb.py flatdevtree
Oh, cool.
> I'd like to add some unit tests in the near future (e.g. comparing with
> dtc output), but I wasted a couple hours screwing with a makefile
> instead. :(
>
> By the way, could you send a patch adding your copyright info?
Yeah, I'm still cleaning up & testing a bit. I should have them out
today unless something comes up (well in addition to a scheduled hour
long network outtage :( .
Mark
^ permalink raw reply
* Re: MPC8360E USB Host Controller Driver
From: Li Yang @ 2006-09-07 18:37 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: n.balaji, linuxppc-embedded
In-Reply-To: <450029E3.2030303@cambridgebroadband.com>
On 9/7/06, Alex Zeffertt <ajz@cambridgebroadband.com> wrote:
> Li Yang-r58472 wrote:
> >> i have a MPC8347E running with the Freescale E(F)HCI driver
> >> and Kernel 2.6.17 (Freescale LTIB).
> >>
> >> Because of this mail, i checked, if there are any periodical
> >> interrupts, without real USB payload.
> >>
> >> The result is: NO
> >>
> >> If i attach a USB-mouse, i get 5 interrupts.
> >> If i remove it again, 1 additional.
> >>
> >> Nothing else, silence !
> >>
> >> USB works well with USB 1.1 and 2.0 devices (This was not the
> >> case with earlier Kernels, e.g. 2.6.13, because for the
> >> switching between 1.1 and 2.0 you need a transaction
> >> translator driver).
> >
> > MPC834x USB is very different from the USB of CPM/QE. It is an
> > integrated EHCI controller.
> >
>
>
> So, the question is still open, does the QuiccEngine HCI (a.k.a. FHCI)
> generate loading on the PPC core when there is no traffic on the USB?
Yes, but no. If the bus is idle for some time, you can put the bus
into suspend state. Then there will be no extra load to the core.
- Leo
^ permalink raw reply
* Re: [Fwd: Re: ohci1394: steps to implement suspend/resume]
From: Stefan Richter @ 2006-09-07 19:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, linux1394-devel, Bernhard Kaindl, Pavel Machek
In-Reply-To: <1157590416.22705.269.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Wed, 2006-09-06 at 16:46 +0200, Stefan Richter wrote:
[...]
>> We already broke your platform code once by what was meant as a bugfix
>> for non-PMacs. It'd be good to know enough to not repeat such mistakes...
>
> The PowerMac code will stop the chip clocks. It should be used as the
> last step of the suspend sequence and first step of the return sequence,
> in _addition_ to your new code.
Thanks for the help.
> Note also that the code you posted lacks calls to pci_set_power_state()...
Pavel submitted a respective patch on 2006-09-05; I will integrate them
both.
--
Stefan Richter
-=====-=-==- =--= --===
http://arcgraph.de/sr/
^ permalink raw reply
* [PATCH] powerpc: Quiet hvc_console console output on failed opens
From: Olof Johansson @ 2006-09-07 20:18 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi,
Please consider for the 2.6.19 queue:
No other tty driver will print on the console when the open of it fails.
On systems that happen to be configured for both ttyS0 and hvc0 console,
this will keep flooding the console output. This is most likely to
happen with systems booted between with and without hypervisor from the
same filesystem.
Let's just remove it. When it's really needed (i.e. when the open fails
and someone is trying to debug it), noone will see the output anyway. And
init will report the opens failing in due time through the syslog.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: merge/drivers/char/hvc_console.c
===================================================================
--- merge.orig/drivers/char/hvc_console.c
+++ merge/drivers/char/hvc_console.c
@@ -320,10 +320,8 @@ static int hvc_open(struct tty_struct *t
struct kobject *kobjp;
/* Auto increments kobject reference if found. */
- if (!(hp = hvc_get_by_index(tty->index))) {
- printk(KERN_WARNING "hvc_console: tty open failed, no vty associated with tty.\n");
+ if (!(hp = hvc_get_by_index(tty->index)))
return -ENODEV;
- }
spin_lock_irqsave(&hp->lock, flags);
/* Check and then increment for fast path open. */
^ permalink raw reply
* Re: [PATCH] powerpc: Quiet hvc_console console output on failed opens
From: Ryan Arnold @ 2006-09-07 20:38 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060907151808.2295ad9a@localhost.localdomain>
On Thu, 2006-09-07 at 15:18 -0500, Olof Johansson wrote:
> Hi,
>
> Please consider for the 2.6.19 queue:
>
>
>
> No other tty driver will print on the console when the open of it fails.
>
> On systems that happen to be configured for both ttyS0 and hvc0 console,
> this will keep flooding the console output. This is most likely to
> happen with systems booted between with and without hypervisor from the
> same filesystem.
>
> Let's just remove it. When it's really needed (i.e. when the open fails
> and someone is trying to debug it), noone will see the output anyway. And
> init will report the opens failing in due time through the syslog.
>
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
> Index: merge/drivers/char/hvc_console.c
> ===================================================================
> --- merge.orig/drivers/char/hvc_console.c
> +++ merge/drivers/char/hvc_console.c
> @@ -320,10 +320,8 @@ static int hvc_open(struct tty_struct *t
> struct kobject *kobjp;
>
> /* Auto increments kobject reference if found. */
> - if (!(hp = hvc_get_by_index(tty->index))) {
> - printk(KERN_WARNING "hvc_console: tty open failed, no vty associated with tty.\n");
> + if (!(hp = hvc_get_by_index(tty->index)))
> return -ENODEV;
> - }
>
> spin_lock_irqsave(&hp->lock, flags);
> /* Check and then increment for fast path open. */
This seems like a good fix to me. I think it is a debug artifact
anyway.
--
Ryan S. Arnold <rsa@us.ibm.com>
IBM Linux Technology Center
Linux on Power Toolchain
^ permalink raw reply
* Re: common flatdevtree code
From: Hollis Blanchard @ 2006-09-07 22:23 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060907182717.GC4398@mag.az.mvista.com>
On Thu, 2006-09-07 at 11:27 -0700, Mark A. Greer wrote:
>
> On Thu, Sep 07, 2006 at 02:43:31AM -0500, Hollis Blanchard wrote:
> >
> > On Wed, 2006-09-06 at 17:36 -0700, Mark A. Greer wrote:
> > > void *ft_find_device(const void *bphp, const char *srch_path)
> >
> > How about "ft_find_node"?
>
> Sure.
>
> > I renamed that and made a couple other small
> > changes. In particular:
> > - u8->int
>
> OK.
>
> > - exit and free -> ft_exit and ft_free (so they can be wrapped in
> > flatdevtree_env.h)
>
> Makes sense.
>
> > - moved those inlines out of flatdevtree.h, since they don't need to be
> > exported
>
> ft_parentize is also used in flatdevtree_misc.c so I think they
> should stay in flatdevtree.h.
OK.
I've pushed these changes and a couple more (run hg pull -u to update).
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [4/5] powerpc: PA Semi PWRficient platform support
From: Benjamin Herrenschmidt @ 2006-09-07 22:33 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Olof Johansson, linuxppc-dev, paulus, anton
In-Reply-To: <86FCADAC-25CF-42B1-8FFB-06889AF6C90E@kernel.crashing.org>
On Thu, 2006-09-07 at 13:28 +0200, Segher Boessenkool wrote:
> >> How about I keep it this way until Maple is fixed then? It's
> >> better to keep it
> >> fairly common anyway. Functionally there's no difference.
> >
> > Well, the platform-open-pic thingy comes from the CHRP spec.
>
> I can't find it there. I'm looking at version 1.0; maybe it's
> in a newer version that I don't have? It's not in the PAPR
> either (the "open" version, anyway).
It's in the old RPAs
> > I'm no fan
> > of it but it looks like we do need it on pseries and I haven't
> > completely given up with having common mpic discovery routine...
>
> Sure. "Just look for the MPIC node and use it with one ISU" won't
> work on an actual Maple anyway afaics, it won't find the right
> base address for it in its device tree.
>
> I'll make something nice that maybe even you will like ;-)
>
> >>> Very nice, I'll convert maple to do the same (unless someone beats
> >>> me to it, heh).
> >>
> >> Maple isn't that different there. It just has to deal with
> >> multiple ISUs,
> >> while we currently only have one.
> >
> > Maple doesn't have multiple ISUs
>
> Exactly. All "real" OpenPICs don't; let's just recognise that fact.
>
>
> Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Quiet hvc_console console output on failed opens
From: Paul Mackerras @ 2006-09-07 23:20 UTC (permalink / raw)
To: Ryan Arnold; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <1157661538.25088.235.camel@localhost.localdomain>
Ryan Arnold writes:
> This seems like a good fix to me. I think it is a debug artifact
> anyway.
So, does that amount to an Acked-by?
Paul.
^ permalink raw reply
* Re: [Fwd: Re: ohci1394: steps to implement suspend/resume]
From: Benjamin Herrenschmidt @ 2006-09-07 23:30 UTC (permalink / raw)
To: Stefan Richter
Cc: linuxppc-dev, linux1394-devel, Bernhard Kaindl, Pavel Machek
In-Reply-To: <4500743D.9000403@s5r6.in-berlin.de>
On Thu, 2006-09-07 at 21:34 +0200, Stefan Richter wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2006-09-06 at 16:46 +0200, Stefan Richter wrote:
> [...]
> >> We already broke your platform code once by what was meant as a bugfix
> >> for non-PMacs. It'd be good to know enough to not repeat such mistakes...
> >
> > The PowerMac code will stop the chip clocks. It should be used as the
> > last step of the suspend sequence and first step of the return sequence,
> > in _addition_ to your new code.
>
> Thanks for the help.
np. I'll try to test if I find some time :)
Ben.
^ permalink raw reply
* Re: oops in snd-powermac due to snd-aoa
From: Benjamin Herrenschmidt @ 2006-09-08 0:13 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20060907124256.GA22928@aepfle.de>
On Thu, 2006-09-07 at 14:42 +0200, Olaf Hering wrote:
> I was playing with snd-aoa, maybe the driver would work on a G4/466.
> mv /lib/modules/*/kernel/sound/ppc/snd-powermac.ko .
> reboot
> $insmod /lib/modules/*/kernel/sound/aoa/*/*.ko
> alsamixer finds nothing.
> mv snd-powermac.ko /lib/modules/*/kernel/sound/ppc/
> $insmod snd-powermac.ko -> oops
I don't think it's due to snd-aoa ... looks like an old bogon of
snd-powermac related to the order in which snd-powermac and i2c-powermac
are loaded ....
Ben
^ permalink raw reply
* Re: common flatdevtree code
From: Mark A. Greer @ 2006-09-08 0:56 UTC (permalink / raw)
To: Hollis Blanchard, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1157667816.5220.30.camel@basalt.austin.ibm.com>
Hollis, Paul,
I made some more changes that I hope you approve of:
- Added a hdr to the file to try to make it clear that people should
not hack the local copy of the file.
- Fixed a booboo (typo) in my last patch
- Change the interface to ft_next() to pass a struct that contains the
pointers that it sets up. Also moved the p_strings & version code
from the caller to ft_next(). Now, just pass in a NULL value to the
'p' param to start at the top of the tree.
- Cleaned up the callers to ft_next(). I think its much cleaner now.
Mark
--
--- flatdevtree.c 2006-09-07 15:34:39.000000000 -0700
+++ flatdevtree.c.new 2006-09-07 17:40:24.000000000 -0700
@@ -1,4 +1,11 @@
/*
+ * DO NOT EDIT THIS FILE!!
+ *
+ * The master copy is kept in a mercurial repository that you can clone:
+ * "hg clone http://unsanctioned.org/flatdevtree/hgweb.py flatdevtree"
+ * Please send patches to Hollis Blanchard <hollisb@us.ibm.com> and
+ * CC: <Linuxppc-dev@ozlabs.org>
+ *
* 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
@@ -15,7 +22,7 @@
*
* Copyright Pantelis Antoniou 2006
* Copyright (C) IBM Corporation 2006
- * 2006 (c) MontaVista, Software, Inc.
+ * 2006 (c) MontaVista Software, Inc.
*
* Authors: Pantelis Antoniou <pantelis@embeddedalley.com>
* Hollis Blanchard <hollisb@us.ibm.com>
@@ -24,29 +31,42 @@
#include "flatdevtree.h"
+struct ft_entity {
+ u32 *tagp; /* Ptr to tag field */
+ char *name; /* Name of node or property; else NULL */
+ char *datap; /* Ptr to data, if property; else NULL */
+ u32 *sizep; /* Ptr to propery size; else NULL */
+};
+
/* Set ptrs to current one's info; return addr of next one */
-static u32 *ft_next(u32 *p, const u32 *p_strings, const u32 version,
- u32 **tagpp, char **namepp, char **datapp, u32 **sizepp)
+static u32 *ft_next(u32 *p, const void *bphp, struct ft_entity *ftep)
{
+ const struct boot_param_header *bph = bphp;
+ const u32 *p_strings = (const u32 *)
+ ((const char *)bph + be32_to_cpu(bph->off_dt_strings));
+ const u32 version = be32_to_cpu(bph->version);
u32 sz;
- *namepp = NULL;
- *datapp = NULL;
- *sizepp = NULL;
- *tagpp = p;
+ if (p == NULL) /* Start at top of tree */
+ p = (u32 *)((char *)bph + be32_to_cpu(bph->off_dt_struct));
+
+ ftep->name = NULL;
+ ftep->datap = NULL;
+ ftep->sizep = NULL;
+ ftep->tagp = p;
switch (be32_to_cpu(*p++)) { /* Tag */
case OF_DT_BEGIN_NODE:
- *namepp = (char *)p;
+ ftep->name = (char *)p;
p = (u32 *)_ALIGN((unsigned long)p + strlen((char *)p) + 1, 4);
break;
case OF_DT_PROP:
sz = be32_to_cpu(*p);
- *sizepp = p++;
- *namepp = (char *)p_strings + be32_to_cpu(*p++);
+ ftep->sizep = p++;
+ ftep->name = (char *)p_strings + be32_to_cpu(*p++);
if ((version < 0x10) && (sz >= 8))
p = (u32 *)_ALIGN((unsigned long)p, 8);
- *datapp = (char *)p;
+ ftep->datap = (char *)p;
p = (u32 *)_ALIGN((unsigned long)p + sz, 4);
break;
case OF_DT_END_NODE:
@@ -371,13 +391,8 @@ void ft_dump_blob(const void *bphp)
const struct boot_param_header *bph = bphp;
const u64 *p_rsvmap = (const u64 *)
((const char *)bph + be32_to_cpu(bph->off_mem_rsvmap));
- const u32 *p_struct = (const u32 *)
- ((const char *)bph + be32_to_cpu(bph->off_dt_struct));
- const u32 *p_strings = (const u32 *)
- ((const char *)bph + be32_to_cpu(bph->off_dt_strings));
- const u32 version = be32_to_cpu(bph->version);
- u32 i, *p, *tagp, *sizep;
- char *namep, *datap;
+ struct ft_entity fte;
+ u32 i, *p;
int depth, shift;
u64 addr, size;
@@ -399,12 +414,11 @@ void ft_dump_blob(const void *bphp)
printf("/memreserve/ 0x%llx 0x%llx;\n", addr, size);
}
- p = (u32 *)p_struct;
- while ((p = ft_next(p, p_strings, version, &tagp, &namep, &datap,
- &sizep)) != NULL)
- switch (be32_to_cpu(*tagp)) {
+ p = NULL;
+ while ((p = ft_next(p, bphp, &fte)) != NULL)
+ switch (be32_to_cpu(*fte.tagp)) {
case OF_DT_BEGIN_NODE:
- printf("%*s%s {\n", depth * shift, "", namep);
+ printf("%*s%s {\n", depth * shift, "", fte.name);
depth++;
break;
case OF_DT_END_NODE:
@@ -417,13 +431,13 @@ void ft_dump_blob(const void *bphp)
case OF_DT_END:
break;
case OF_DT_PROP:
- printf("%*s%s", depth * shift, "", namep);
- print_data(datap, *sizep);
+ printf("%*s%s", depth * shift, "", fte.name);
+ print_data(fte.datap, *fte.sizep);
printf(";\n");
break;
default:
fprintf(stderr, "%*s ** Unknown tag 0x%08x\n",
- depth * shift, "", *tagp);
+ depth * shift, "", *fte.tagp);
return;
}
}
@@ -439,13 +453,8 @@ void ft_backtrack_node(struct ft_cxt *cx
/* note that the root node of the blob is "peeled" off */
void ft_merge_blob(struct ft_cxt *cxt, void *blob)
{
- struct boot_param_header *bph = (struct boot_param_header *)blob;
- u32 *p_struct = (u32 *) ((char *)bph + be32_to_cpu(bph->off_dt_struct));
- u32 *p_strings =
- (u32 *) ((char *)bph + be32_to_cpu(bph->off_dt_strings));
- const u32 version = be32_to_cpu(bph->version);
- u32 *p, *tagp, *sizep;
- char *namep, *datap;
+ struct ft_entity fte;
+ u32 *p;
int depth;
if (be32_to_cpu(*(u32 *) (cxt->p - 4)) != OF_DT_END_NODE)
@@ -454,13 +463,12 @@ void ft_merge_blob(struct ft_cxt *cxt, v
cxt->p -= 4;
depth = 0;
- p = p_struct;
- while ((p = ft_next(p, p_strings, version, &tagp, &namep, &datap,
- &sizep)) != NULL)
- switch (be32_to_cpu(*tagp)) {
+ p = NULL;
+ while ((p = ft_next(p, blob, &fte)) != NULL)
+ switch (be32_to_cpu(*fte.tagp)) {
case OF_DT_BEGIN_NODE:
if (depth++ > 0)
- ft_begin_node(cxt, namep);
+ ft_begin_node(cxt, fte.name);
break;
case OF_DT_END_NODE:
ft_end_node(cxt);
@@ -468,7 +476,7 @@ void ft_merge_blob(struct ft_cxt *cxt, v
return;
break;
case OF_DT_PROP:
- ft_prop(cxt, namep, datap, *sizep);
+ ft_prop(cxt, fte.name, fte.datap, *fte.sizep);
break;
}
}
@@ -477,24 +485,18 @@ void ft_merge_blob(struct ft_cxt *cxt, v
void *ft_find_node(const void *bphp, const char *srch_path)
{
- const struct boot_param_header *bph = bphp;
- u32 *p_struct = (u32 *)((char *)bph + be32_to_cpu(bph->off_dt_struct));
- u32 *p_strings= (u32 *)((char *)bph + be32_to_cpu(bph->off_dt_strings));
- u32 version = be32_to_cpu(bph->version);
- u32 *p, *tagp, *sizep;
- char *namep, *datap;
+ struct ft_entity fte;
+ u32 *p;
static char path[MAX_PATH_LEN];
path[0] = '\0';
- p = p_struct;
-
- while ((p = ft_next(p, p_strings, version, &tagp, &namep, &datap,
- &sizep)) != NULL)
- switch (be32_to_cpu(*tagp)) {
+ p = NULL;
+ while ((p = ft_next(p, bphp, &fte)) != NULL)
+ switch (be32_to_cpu(*fte.tagp)) {
case OF_DT_BEGIN_NODE:
- strcat(path, namep);
+ strcat(path, fte.name);
if (!strcmp(path, srch_path))
- return tagp;
+ return fte.tagp;
strcat(path, "/");
break;
case OF_DT_END_NODE:
@@ -507,26 +509,21 @@ void *ft_find_node(const void *bphp, con
int ft_get_prop(const void *bphp, const void *node, const char *propname,
void *buf, const unsigned int buflen)
{
- const struct boot_param_header *bph = bphp;
- u32 *p_strings= (u32 *)((char *)bph + be32_to_cpu(bph->off_dt_strings));
- u32 version = be32_to_cpu(bph->version);
- u32 *p, *tagp, *sizep, size;
- char *namep, *datap;
+ struct ft_entity fte;
+ u32 *p, size;
int depth;
depth = 0;
p = (u32 *)node;
-
- while ((p = ft_next(p, p_strings, version, &tagp, &namep, &datap,
- &sizep)) != NULL)
- switch (be32_to_cpu(*tagp)) {
+ while ((p = ft_next(p, bphp, &fte)) != NULL)
+ switch (be32_to_cpu(*fte.tagp)) {
case OF_DT_BEGIN_NODE:
depth++;
break;
case OF_DT_PROP:
- if ((depth == 1) && !strcmp(namep, propname)) {
- size = min(be32_to_cpu(*sizep), (u32)buflen);
- memcpy(buf, datap, size);
+ if ((depth == 1) && !strcmp(fte.name, propname)) {
+ size = min(be32_to_cpu(*fte.sizep),(u32)buflen);
+ memcpy(buf, fte.datap, size);
return size;
}
break;
@@ -562,7 +559,7 @@ static void ft_modify_prop(void **bphpp,
old_tailp = (u32 *)(datap + old_prop_data_len);
new_total_size = head_len + new_prop_data_len + tail_len;
- if (!(new_bph = malloc(new_total_size))) {
+ if (!(new_bph = ft_malloc(new_total_size))) {
printf("Can't alloc space for new ft\n");
ft_exit(-ENOSPC);
}
@@ -604,27 +601,22 @@ static void ft_modify_prop(void **bphpp,
int ft_set_prop(void **bphpp, const void *node, const char *propname,
const void *buf, const unsigned int buflen)
{
- struct boot_param_header *bph = *bphpp;
- u32 *p_strings= (u32 *)((char *)bph + be32_to_cpu(bph->off_dt_strings));
- u32 version = be32_to_cpu(bph->version);
- u32 *p, *tagp, *sizep;
- char *namep, *datap;
+ struct ft_entity fte;
+ u32 *p;
int depth;
depth = 0;
p = (u32 *)node;
-
- while ((p = ft_next(p, p_strings, version, &tagp, &namep, &datap,
- &sizep)) != NULL)
- switch (be32_to_cpu(*tagp)) {
+ while ((p = ft_next(p, *bphpp, &fte)) != NULL)
+ switch (be32_to_cpu(*fte.tagp)) {
case OF_DT_BEGIN_NODE:
depth++;
break;
case OF_DT_PROP:
- if ((depth == 1) && !strcmp(namep, propname)) {
- ft_modify_prop(bphpp, datap, sizep, buf,
+ if ((depth == 1) && !strcmp(fte.name, propname)) {
+ ft_modify_prop(bphpp, fte.datap, fte.sizep, buf,
buflen);
- return be32_to_cpu(*sizep);
+ return be32_to_cpu(*fte.sizep);
}
break;
case OF_DT_END_NODE:
^ permalink raw reply
* Re: [PATCH] kdump : Support kernels having 64k page size.
From: Sachin P. Sant @ 2006-09-08 1:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1157590304.22705.267.camel@localhost.localdomain>
> You should always do 64k regardless of the page size. I think we have
> some ABI requirements here for ELF sections to be 64k aligned anyway
> no ?
>
>
Ben are you aware of any doc where i can find more information. I
checked the
64Bit PowerPC ELF ABI doc but couldn't find any specific information about
this.
Also other question is If we create a 64k segment irrespective of page size
[ as compared to 32k currently ] we would be writing extra 32k even for
page size of 4K. Which means we have 32k less memory for the kdump
kernel. Wouldn't that be an issue ?
Thanks
-Sachin
^ permalink raw reply
* Re: [PATCH] [v3] PPC 4xx: Enable XMON on PPC 4xx boards
From: Benjamin Herrenschmidt @ 2006-09-08 1:03 UTC (permalink / raw)
To: Josh Boyer; +Cc: mporter, paulus, linuxppc-dev
In-Reply-To: <1157652525.6098.61.camel@zod.rchland.ibm.com>
> Blindly following the existing convention. I agree it's ugly. I'll fix
> it up shortly and send out another patch. It'll also fix 440SPE, which
> also has a different UART address.
It should all move to udbg anyway
Ben.
^ permalink raw reply
* Re: [PATCH] kdump : Support kernels having 64k page size.
From: Benjamin Herrenschmidt @ 2006-09-08 1:08 UTC (permalink / raw)
To: Sachin P. Sant; +Cc: linuxppc-dev
In-Reply-To: <4500C0BA.8060408@in.ibm.com>
On Fri, 2006-09-08 at 06:30 +0530, Sachin P. Sant wrote:
> > You should always do 64k regardless of the page size. I think we have
> > some ABI requirements here for ELF sections to be 64k aligned anyway
> > no ?
> >
> >
> Ben are you aware of any doc where i can find more information. I
> checked the
> 64Bit PowerPC ELF ABI doc but couldn't find any specific information about
> this.
>
> Also other question is If we create a 64k segment irrespective of page size
> [ as compared to 32k currently ] we would be writing extra 32k even for
> page size of 4K. Which means we have 32k less memory for the kdump
> kernel. Wouldn't that be an issue ?
32k sounds like a drop of water in the kdump pool ...
Ben.
^ permalink raw reply
* Re: [PATCH] [v3] PPC 4xx: Enable XMON on PPC 4xx boards
From: Josh Boyer @ 2006-09-08 1:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, mporter
In-Reply-To: <1157677403.22705.360.camel@localhost.localdomain>
On Fri, 2006-09-08 at 11:03 +1000, Benjamin Herrenschmidt wrote:
> > Blindly following the existing convention. I agree it's ugly. I'll fix
> > it up shortly and send out another patch. It'll also fix 440SPE, which
> > also has a different UART address.
>
> It should all move to udbg anyway
udbg is arch/powerpc. This is arch/ppc. I have every intention of
porting this to arch/powerpc when 4xx itself moves over and I'll gladly
use udbg then.
Until then, I'd still like to get this patch (v4) into the kernel since
it's quite useful now.
josh
^ permalink raw reply
* Re: common flatdevtree code
From: Mark A. Greer @ 2006-09-08 1:11 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras, Hollis Blanchard
In-Reply-To: <20060908005630.GA9823@mag.az.mvista.com>
On Thu, Sep 07, 2006 at 05:56:31PM -0700, Mark A. Greer wrote:
> Hollis, Paul,
>
> I made some more changes that I hope you approve of:
> - Added a hdr to the file to try to make it clear that people should
> not hack the local copy of the file.
> - Fixed a booboo (typo) in my last patch
> - Change the interface to ft_next() to pass a struct that contains the
> pointers that it sets up. Also moved the p_strings & version code
> from the caller to ft_next(). Now, just pass in a NULL value to the
> 'p' param to start at the top of the tree.
> - Cleaned up the callers to ft_next(). I think its much cleaner now.
Forgot to add:
- Change malloc() call to ft_malloc() to be consistent with the changes
made to exit() -> ft_exit() and free -> ft_free().
Mark
^ permalink raw reply
* powerpc power management
From: John Rigby @ 2006-09-08 2:05 UTC (permalink / raw)
To: linuxppc
I need to implement suspend to ram (sleep mode) on an embedded powerpc
processor. I have googled generally and searched the lkml, this list
and the linux power management mailing list. It seems after all this
searching that the only existing code is for the powermac in
drivers/macintosh/(variousfiles) and
arch/powerpc/platforms/powermac/(variousfiles). Is this true or am I
missing something?
Thanks
John
^ permalink raw reply
* [PATCH] kdump : Support kernels having 64k page size.
From: Sachin P. Sant @ 2006-09-08 2:29 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <1157677687.22705.364.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]
Benjamin Herrenschmidt wrote:
> On Fri, 2006-09-08 at 06:30 +0530, Sachin P. Sant wrote:
>
>>> You should always do 64k regardless of the page size. I think we have
>>> some ABI requirements here for ELF sections to be 64k aligned anyway
>>> no ?
>>>
>>>
>>>
>> Ben are you aware of any doc where i can find more information. I
>> checked the
>> 64Bit PowerPC ELF ABI doc but couldn't find any specific information about
>> this.
>>
>> Also other question is If we create a 64k segment irrespective of page size
>> [ as compared to 32k currently ] we would be writing extra 32k even for
>> page size of 4K. Which means we have 32k less memory for the kdump
>> kernel. Wouldn't that be an issue ?
>>
>
> 32k sounds like a drop of water in the kdump pool ...
>
> Ben.
>
>
The following kernel patch [ along with a patch to kexec tools posted
seperately ]is required to generate proper core files using kdump on ppc64.
* Create a backup region of 64K size irrespective of the PAGE SIZE.
At present 32K was used as backup size. In the case of 64K page size,
second
PT_LOAD segments starts at 32K and the first one is not page aligned.
__ioremap() (crash_dump.c) fails if pfn = 0 which is the case for the
second
PT_LOAD segment. This is not an issue for 4K page size because the the
first
page (32K backup) is copied to second kernel memory and thus referencing
with the second kernel pfn.
Signed-off-by: Sachin Sant <sachinp@in.ibm.com>
Thanks
-Sachin
[-- Attachment #2: 64k-backup-size-for-kdump --]
[-- Type: text/plain, Size: 1073 bytes --]
* Create a backup region of 64K size irrespective of the PAGE SIZE.
At present 32K was used as backup size. In the case of 64K page size, second
PT_LOAD segments starts at 32K and the first one is not page aligned.
__ioremap() (crash_dump.c) fails if pfn = 0 which is the case for the second
PT_LOAD segment. This is not an issue for 4K page size because the the first
page (32K backup) is copied to second kernel memory and thus referencing
with the second kernel pfn.
Signed-off-by: Sachin Sant <sachinp@in.ibm.com>
---
diff -Naurp a/include/asm-powerpc/kdump.h b/include/asm-powerpc/kdump.h
--- a/include/asm-powerpc/kdump.h 2006-09-01 00:40:10.000000000 +0530
+++ b/include/asm-powerpc/kdump.h 2006-09-08 07:12:18.000000000 +0530
@@ -7,7 +7,7 @@
/* How many bytes to reserve at zero for kdump. The reserve limit should
* be greater or equal to the trampoline's end address.
* Reserve to the end of the FWNMI area, see head_64.S */
-#define KDUMP_RESERVE_LIMIT 0x8000
+#define KDUMP_RESERVE_LIMIT 0x10000 /* 64K */
#ifdef CONFIG_CRASH_DUMP
^ permalink raw reply
* RE: MPC8360E USB Host Controller Driver
From: Li Yang-r58472 @ 2006-09-08 3:27 UTC (permalink / raw)
To: Laurent Pinchart, linuxppc-embedded; +Cc: n.balaji
In-Reply-To: <200609071324.30930.laurent.pinchart@tbox.biz>
> Could you give a direct link ? I've been browsing around the=20
> Freescale website for an hour, downloaded hundreds of=20
> megabytes of archives but haven't been able to find the=20
> MPC8360E USB Linux driver.
>=20
> Laurent Pinchart
>=20
> PS: Am I the only one to get lost almost every time when I=20
> look for information on www.freescale.com ?
PS: Contacting local FAE is always a good way and recommended way to get
the latest information.
- Leo
^ permalink raw reply
* Re: [PATCH 0/6] bootwrapper: arch/powerpc/boot code reorg patches
From: Mark A. Greer @ 2006-09-08 3:32 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060719225356.GA3887@mag.az.mvista.com>
Hi,
I have respun all the patches in this series and will be submitting them
shortly.
Some things have changed from the previous patches. In particular, the
guts of the flat dev tree code are now in
<file:arch/powerpc/boot/flatdevtree.[ch]>. These files are only *copies*
of the files Hollis Blanchard is maintaining so please do not edit them
in the bootwrapper. The code in those files is still being worked on
so I'm will not submit them in this patch series. However, I will
start a separate email thread with the current copies so you can
build and so those changes don't hold up the acceptance of these patches.
Just don't surprised if the master code has changed by the time you read
this.
Also changed:
- The 'ops' struct & ptr are gone, now uses
platform_ops/dt_ops/console_ops directly.
- There are a couple new files. flatdevtree_env.h has header file
glue so that flatdevtree.[ch] will compile/work.
flatdevtree_misc.c contains interface glue between bootwrapper dt
calls and the implementation in flatdevtree.c, and some functionality
not provided by flatdevtree.c
- dink.c is renamed to simple_alloc.c because the code isn't dink specific.
- I'm submitting the kernel sandpoint code along with the dts (which I
didn't do before) because people have asked for it.
- I changed the name of the section that holds the dtb from
__builtin_fdt to __builtin_ft to match the prefixes used in the
flatdevtree*.[ch] files. If you made a script to attach a dtb to a
zImage like what I emailed before, you'll have to edit it to change
the section name.
Mark
^ 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