* Re: Question : about difference with bdnz and bdnz+
From: Benjamin Herrenschmidt @ 2009-08-27 9:30 UTC (permalink / raw)
To: HongWoo Lee; +Cc: linuxppc-dev
In-Reply-To: <4A9613E3.8020700@gmail.com>
On Thu, 2009-08-27 at 14:04 +0900, HongWoo Lee wrote:
> And I have a question about bdnz+ instruction.
> Through googling, I learned that bdnz does decrement count register
> and
> branch if it is still nonzero.
> But I couldn't find what "bdnz+" is.
> Can anybody explain to me what it is ??
On PowerPC, branch instructions can have a "hint" (+ or - added to the
mnemonic) which indicates to the processor whether the branch is likely
to be taken or not, and overrides the dynamic branch prediction.
In most case, it's not necessary though I suppose in the case at hand,
we are pretty confident that we're going to loop a lot more times than
exit from the loop so it won't hurt to put the hint in there.
Note that there have been subtle changes in the way those hints work
between earlier and modern PowerPC processors and the way they are
encoded will be different depending on what CPU you are building for,
but that's an entirely different headache :-)
Cheers,
Ben.
^ permalink raw reply
* Re: spin_is_locked() broken for uniprocessor?
From: Benjamin Herrenschmidt @ 2009-08-27 9:32 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Linux-Kernel List, Steven Rostedt, linuxppc-dev list,
Thomas Gleixner, Ingo Molnar
In-Reply-To: <1250674870.7583.334.camel@twins>
On Wed, 2009-08-19 at 11:41 +0200, Peter Zijlstra wrote:
> > > > which implies to me that spin_is_locked() will always return
> false. Is this
> > > > expected behavior.
> > >
> > > That's wrong. spin_is_locked should always return true on UP.
> >
> > Surely it's not that simple? Maybe spin_is_lock() should be
> undefined on UP.
>
> #define spin_is_locked(l) panic()
>
> should sort things out quickly ;-)
Not defining it would sort things out even faster and avoid nasty case
of system panic'ing when a module is loaded :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [ewg] [PATCH] IB/ehca: Construct MAD redirect replies from request MAD
From: Joachim Fenkes @ 2009-08-27 9:44 UTC (permalink / raw)
To: Hal Rosenstock
Cc: Hal Rosenstock, OF-EWG, LKML, Jason Gunthorpe, LinuxPPC-Dev,
Christoph Raisch, OF-General, Stefan Roscher
In-Reply-To: <f0e08f230908260815g70de3002pfd0b34f1b17abd6@mail.gmail.com>
Hal Rosenstock <hal.rosenstock@gmail.com> wrote on 26.08.2009 17:15:03:
> Thanks for doing this. It looks sane to me. The only issue I recall that
> appears to be remaining is a better setting of
ClassPortInfo:RespTimeValue
> rather than hardcoding. Perhaps using the value from PortInfo is the way
to go
> (ideally it would be that value from the port to which the the requester
is
> being redirected to but that might not be so easy to get from this port.
I don't think that effort will be necessary or even legal. The requestor
will react to the redirection with another Get(ClassPortInfo) to the
redirection target, which will reply with its own RespTimeValue, so our
driver should speak for itself. Since we don't know when our MAD
processing and sending of the response is going to be scheduled (we're not
running on real-time constraints here), we play it safe and return 18,
which amounts to roughly a second.
Make sense?
Regards
Joachim
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Josh Boyer @ 2009-08-27 11:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1251344028.20467.8.camel@pasglop>
On Thu, Aug 27, 2009 at 01:33:48PM +1000, Benjamin Herrenschmidt wrote:
>Hi Linus !
>
>Here are a couple of last minute patches for 2.6.31. One is a regression fix
>(afaik) where a PS3 driver gets incorrectly loaded on other platforms and
>crashes, along with a PS3 defconfig update.
>The following changes since commit f415c413f458837bd0c27086b79aca889f9435e4:
> Linus Torvalds (1):
> Merge git://git.kernel.org/.../davem/net-2.6
>
>are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
>
>Geert Uytterhoeven (1):
> powerpc/ps3: Add missing check for PS3 to rtc-ps3 platform device registration
>
>Geoff Levand (1):
> powerpc/ps3: Update ps3_defconfig
Hm. No 44x flush_icache_range patch?
josh
^ permalink raw reply
* Re: [PATCH] fix book E watchdog to take WDIOC_SETTIMEOUT arg in seconds
From: Wim Van Sebroeck @ 2009-08-27 11:14 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev, Linux kernel
In-Reply-To: <4A8303C6.7070705@nortel.com>
Hi Chris,
> The WDIOC_SETTIMEOUT argument is supposed to be a "seconds" value.
> However, the book E wdt currently treats it as a "period" which is
> interpreted in a board-specific way.
>
> This patch allows the user to pass in a "seconds" value and the driver
> will set the smallest timeout that is at least as large as specified
> by the user. It's been tested on e500 hardware and works as
> expected.
>
> The patch only modifies the CONFIG_FSL_BOOKE case, the CONFIG_4xx case
> is left unmodified as I don't have any hardware to test it on.
>
> Signed-off-by: Chris Friesen <cfriesen@nortel.com>
Added with some small changes to keep checkpatch happy. (removed trailing spaces + changed sizeof(struct watchdog_info) to sizeof(ident) and changed some spaces in tabs).
Now we only need someone that can look at the CONFIG_4xx cases still :-)
Kind regards,
Wim.
^ permalink raw reply
* [PATCH] hvc_console: provide (un)locked version for hvc_resize()
From: Hendrik Brueckner @ 2009-08-27 11:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Carsten Otte, kvm, linuxppc-dev, linux-kernel, Heiko Carstens,
qemu-devel, miltonm, virtualization, borntraeger, brueckner,
Amit Shah, Martin Schwidefsky, Alan Cox
In-Reply-To: <1251365243.20467.47.camel@pasglop>
On Thu, Aug 27, 2009 at 07:27:23PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-08-27 at 10:08 +0100, Alan Cox wrote:
> So at this stage, I think the reasonably thing to do is to stick to the
> spinlock, but we can try to make it a bit smarter, and we can definitely
> attempt to fix the case Amit pointed out where we call resize without a
> lock while it seems to expect it (though we also need to be careful
> about re-entrancy I believe).
I have worked on a patch for providing a locked hvc_resize() function.
Since only two back-ends (virtio_console and hvc_iucv) use the function,
I decided to update my hvc_iucv back-end through renaming the function
call as follows:
Rename the locking free hvc_resize() function to __hvc_resize() and
provide an inline function that locks the hvc_struct and calls
__hvc_resize().
The rationale for this patch is that virtio_console calls the hvc_resize()
function without locking the hvc_struct.
According to naming rules, the unlocked version is renamed and
prefixed with "__".
References to unlocked function calls in hvc back-ends has been updated.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
drivers/char/hvc_console.c | 6 +++---
drivers/char/hvc_console.h | 12 +++++++++++-
drivers/char/hvc_iucv.c | 4 +++-
3 files changed, 17 insertions(+), 5 deletions(-)
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -680,7 +680,7 @@ int hvc_poll(struct hvc_struct *hp)
EXPORT_SYMBOL_GPL(hvc_poll);
/**
- * hvc_resize() - Update terminal window size information.
+ * __hvc_resize() - Update terminal window size information.
* @hp: HVC console pointer
* @ws: Terminal window size structure
*
@@ -689,12 +689,12 @@ EXPORT_SYMBOL_GPL(hvc_poll);
*
* Locking: Locking free; the function MUST be called holding hp->lock
*/
-void hvc_resize(struct hvc_struct *hp, struct winsize ws)
+void __hvc_resize(struct hvc_struct *hp, struct winsize ws)
{
hp->ws = ws;
schedule_work(&hp->tty_resize);
}
-EXPORT_SYMBOL_GPL(hvc_resize);
+EXPORT_SYMBOL_GPL(__hvc_resize);
/*
* This kthread is either polling or interrupt driven. This is determined by
--- a/drivers/char/hvc_console.h
+++ b/drivers/char/hvc_console.h
@@ -28,6 +28,7 @@
#define HVC_CONSOLE_H
#include <linux/kref.h>
#include <linux/tty.h>
+#include <linux/spinlock.h>
/*
* This is the max number of console adapters that can/will be found as
@@ -88,7 +89,16 @@ int hvc_poll(struct hvc_struct *hp);
void hvc_kick(void);
/* Resize hvc tty terminal window */
-extern void hvc_resize(struct hvc_struct *hp, struct winsize ws);
+extern void __hvc_resize(struct hvc_struct *hp, struct winsize ws);
+
+static inline void hvc_resize(struct hvc_struct *hp, struct winsize ws)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&hp->lock, flags);
+ __hvc_resize(hp, ws);
+ spin_unlock_irqrestore(&hp->lock, flags);
+}
/* default notifier for irq based notification */
extern int notifier_add_irq(struct hvc_struct *hp, int data);
--- a/drivers/char/hvc_iucv.c
+++ b/drivers/char/hvc_iucv.c
@@ -273,7 +273,9 @@ static int hvc_iucv_write(struct hvc_iuc
case MSG_TYPE_WINSIZE:
if (rb->mbuf->datalen != sizeof(struct winsize))
break;
- hvc_resize(priv->hvc, *((struct winsize *) rb->mbuf->data));
+ /* The caller must ensure that the hvc is locked, which
+ * is the case when called from hvc_iucv_get_chars() */
+ __hvc_resize(priv->hvc, *((struct winsize *) rb->mbuf->data));
break;
case MSG_TYPE_ERROR: /* ignored ... */
^ permalink raw reply
* [v3 PATCH 0/4]: CPUIDLE/POWER: Introducing cpuidle infrastructure to POWER
From: Arun R Bharadwaj @ 2009-08-27 11:49 UTC (permalink / raw)
To: oel Schopp, Benjamin Herrenschmidt, Paul Mackerras,
Peter Zijlstra, Ingo Molnar, Vaidyanathan Srinivasan,
Dipankar Sarma, Balbir Singh, Gautham R Shenoy,
Pallipadi, Venkatesh, Arun R Bharadwaj
Cc: linuxppc-dev, linux-kernel
Hi,
Changes from previous iteration:
--------------------------------
* Remove the EXPORT_SYMBOL(pm_idle) from
arch/powerpc/platform/pseries/processor_idle.c and introduce a
generic cpuidle_pm_idle in cpuidle.c which was earlier assuming pm_idle
to be the default idle routine. (As suggested by Peter and Ben).
* Move the cpu_idle_wait function from arch/powerpc/platforms/pseries/setup.c
to arch/powerpc/kernel/idle.c which would prevent breaking the build of
other platforms. (As suggested by Ben).
---------------------------------------
"Cpuidle" is a CPU Power Management infrastrusture which helps manage
idle CPUs in a clean and efficient manner. The architecture can register
its driver (in this case, pseries_idle driver) so that it subscribes for
cpuidle feature. Cpuidle has a set of governors (ladder and menu),
which will decide the best idle state to be chosen for the current situation,
based on heuristics, and calculates the expected residency time
for the current idle state. So based on this, the cpu is put into
the right idle state.
Currently, cpuidle infrasture is exploited by ACPI to choose between
the available ACPI C-states. This patch-set is aimed at enabling
cpuidle for powerpc and provides a sample implementation for pseries.
Currently, in the pseries_dedicated_idle_sleep(), the processor would
poll for a time period, which is called the snooze, and only then it
is ceded, which would put the processor in nap state. Cpuidle aims at
separating this into 2 different idle states. Based on the expected
residency time predicted by the cpuidle governor, the idle state is
chosen directly. So, choosing to enter the nap state directly based on
the decision made by cpuidle would avoid unnecessary snoozing before
entering nap.
This patch-set tries to achieve the above objective by introducing a
pseries processor idle driver called pseries_idle_driver in
arch/powerpc/platform/pseries/processor_idle.c, which implements the
idle loop which would replace the pseries_dedicated_idle_sleep()
when cpuidle is enabled.
Experiment conducted:
----------------------
The following experiment was conducted on a completely idle JS22 blade,
to prove that using cpuidle infrastructure, the amount of nap time increases.
Nap and snooze times were sampled for all the cpus.
For a window of 1000 samples, When cpuidle was enabled,
the total nap time was of the order of a few seconds (5-10s), whereas
the total snooze time was of the order of a few milliseconds(10-30 ms).
When cpuidle infrastructure was disabled and the regular
pseries_dedicated_idle_sleep() idle loop was used, the snooze time itself
was of the order of hundreds of milliseconds. (100 - 500 ms).
This is clearly due to unnecessary snoozing before napping even on a
completely idle system.
The previous post in this area can be found at
http://lkml.org/lkml/2009/8/26/233
Patches included in this set:
------------------------------
PATCH 1/4 - Enable cpuidle for pSeries.
PATCH 2/4 - Introduce architecture independent cpuidle_pm_idle in
drivers/cpuidle/cpuidle.c
PATCH 3/4 - Register for cpuidle_pm_idle in drivers/acpi/processor_idle.c
and arch/arm/mach-kirkwood/cpuidle.c
PATCH 4/4 - Implement Pseries Processor Idle idle module
--arun
^ permalink raw reply
* [PATCH 1/4]: CPUIDLE/POWER: Enable cpuidle for pSeries.
From: Arun R Bharadwaj @ 2009-08-27 11:51 UTC (permalink / raw)
To: Joel Schopp, Benjamin Herrenschmidt, Paul Mackerras,
Peter Zijlstra, Ingo Molnar, Vaidyanathan Srinivasan,
Dipankar Sarma, Balbir Singh, Gautham R Shenoy,
Pallipadi, Venkatesh, Arun Bharadwaj
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090827114908.GA24986@linux.vnet.ibm.com>
* Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-08-27 17:19:08]:
This patch enables the cpuidle option in Kconfig for pSeries.
Currently cpuidle infrastructure is enabled only for x86 and ARM.
This code is almost completely borrowed from x86 to enable
cpuidle for pSeries.
Signed-off-by: Arun R Bharadwaj <arun@linux.vnet.ibm.com>
---
arch/powerpc/Kconfig | 17 +++++++++++++++++
arch/powerpc/include/asm/system.h | 2 ++
arch/powerpc/kernel/idle.c | 19 +++++++++++++++++++
3 files changed, 38 insertions(+)
Index: linux.trees.git/arch/powerpc/Kconfig
===================================================================
--- linux.trees.git.orig/arch/powerpc/Kconfig
+++ linux.trees.git/arch/powerpc/Kconfig
@@ -88,6 +88,9 @@ config ARCH_HAS_ILOG2_U64
bool
default y if 64BIT
+config ARCH_HAS_CPU_IDLE_WAIT
+ def_bool y
+
config GENERIC_HWEIGHT
bool
default y
@@ -243,6 +246,20 @@ source "kernel/Kconfig.freezer"
source "arch/powerpc/sysdev/Kconfig"
source "arch/powerpc/platforms/Kconfig"
+menu "Power management options"
+
+source "drivers/cpuidle/Kconfig"
+
+config PSERIES_PROCESSOR_IDLE
+ bool "Idle Power Management Support for pSeries"
+ depends on PPC_PSERIES && CPU_IDLE
+ default y
+ help
+ Idle Power Management Support for pSeries. This hooks onto cpuidle
+ infrastructure to help in idle cpu power management.
+
+endmenu
+
menu "Kernel options"
config HIGHMEM
Index: linux.trees.git/arch/powerpc/include/asm/system.h
===================================================================
--- linux.trees.git.orig/arch/powerpc/include/asm/system.h
+++ linux.trees.git/arch/powerpc/include/asm/system.h
@@ -546,5 +546,7 @@ extern void account_system_vtime(struct
extern struct dentry *powerpc_debugfs_root;
+void cpu_idle_wait(void);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_SYSTEM_H */
Index: linux.trees.git/arch/powerpc/kernel/idle.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/idle.c
+++ linux.trees.git/arch/powerpc/kernel/idle.c
@@ -102,6 +102,25 @@ void cpu_idle(void)
}
}
+static void do_nothing(void *unused)
+{
+}
+
+/*
+ * cpu_idle_wait - Used to ensure that all the CPUs discard old value of
+ * ppc_md.power_save and update to new value.
+ * Required while changing ppc_md.power_save handler on SMP systems.
+ * Caller must have changed ppc_md.power_save to the new value before the call.
+ */
+void cpu_idle_wait(void)
+{
+ /* Ensure that new value of ppc_md.power_save is set */
+ smp_mb();
+ /* kick all the CPUs so that they exit out of ppc_md.power_save */
+ smp_call_function(do_nothing, NULL, 1);
+}
+EXPORT_SYMBOL_GPL(cpu_idle_wait);
+
int powersave_nap;
#ifdef CONFIG_SYSCTL
^ permalink raw reply
* [PATCH 2/4]: CPUIDLE: Introduce architecture independent cpuidle_pm_idle in drivers/cpuidle/cpuidle.c
From: Arun R Bharadwaj @ 2009-08-27 11:53 UTC (permalink / raw)
To: Joel Schopp, Benjamin Herrenschmidt, Paul Mackerras,
Peter Zijlstra, Ingo Molnar, Vaidyanathan Srinivasan,
Dipankar Sarma, Balbir Singh, Gautham R Shenoy,
Pallipadi, Venkatesh, Arun Bharadwaj
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090827114908.GA24986@linux.vnet.ibm.com>
* Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-08-27 17:19:08]:
Cpuidle infrastructure assumes pm_idle as the default idle routine.
But, ppc_md.power_save is the default idle callback in case of pSeries.
So, create a more generic, architecture independent cpuidle_pm_idle
function pointer in driver/cpuidle/cpuidle.c and allow the idle routines
of architectures to be set to cpuidle_pm_idle.
Signed-off-by: Arun R Bharadwaj <arun@linux.vnet.ibm.com>
---
drivers/cpuidle/cpuidle.c | 12 +++++++-----
include/linux/cpuidle.h | 7 +++++++
2 files changed, 14 insertions(+), 5 deletions(-)
Index: linux.trees.git/drivers/cpuidle/cpuidle.c
===================================================================
--- linux.trees.git.orig/drivers/cpuidle/cpuidle.c
+++ linux.trees.git/drivers/cpuidle/cpuidle.c
@@ -25,6 +25,7 @@ DEFINE_PER_CPU(struct cpuidle_device *,
DEFINE_MUTEX(cpuidle_lock);
LIST_HEAD(cpuidle_detected_devices);
static void (*pm_idle_old)(void);
+void (*cpuidle_pm_idle)(void);
static int enabled_devices;
@@ -98,10 +99,10 @@ static void cpuidle_idle_call(void)
*/
void cpuidle_install_idle_handler(void)
{
- if (enabled_devices && (pm_idle != cpuidle_idle_call)) {
+ if (enabled_devices && (cpuidle_pm_idle != cpuidle_idle_call)) {
/* Make sure all changes finished before we switch to new idle */
smp_wmb();
- pm_idle = cpuidle_idle_call;
+ cpuidle_pm_idle = cpuidle_idle_call;
}
}
@@ -110,8 +111,9 @@ void cpuidle_install_idle_handler(void)
*/
void cpuidle_uninstall_idle_handler(void)
{
- if (enabled_devices && pm_idle_old && (pm_idle != pm_idle_old)) {
- pm_idle = pm_idle_old;
+ if (enabled_devices && pm_idle_old &&
+ (cpuidle_pm_idle != pm_idle_old)) {
+ cpuidle_pm_idle = pm_idle_old;
cpuidle_kick_cpus();
}
}
@@ -382,7 +384,7 @@ static int __init cpuidle_init(void)
{
int ret;
- pm_idle_old = pm_idle;
+ pm_idle_old = cpuidle_pm_idle;
ret = cpuidle_add_class_sysfs(&cpu_sysdev_class);
if (ret)
Index: linux.trees.git/include/linux/cpuidle.h
===================================================================
--- linux.trees.git.orig/include/linux/cpuidle.h
+++ linux.trees.git/include/linux/cpuidle.h
@@ -188,4 +188,11 @@ static inline void cpuidle_unregister_go
#define CPUIDLE_DRIVER_STATE_START 0
#endif
+/*
+ * Idle callback used by cpuidle to call the cpuidle_idle_call().
+ * Platform drivers can use this to register to cpuidle's idle loop.
+ */
+
+extern void (*cpuidle_pm_idle)(void);
+
#endif /* _LINUX_CPUIDLE_H */
^ permalink raw reply
* [PATCH 3/4]: ACPI/ARM: Register for cpuidle_pm_idle in drivers/acpi/processor_idle.c and arch/arm/mach-kirkwood/cpuidle.c
From: Arun R Bharadwaj @ 2009-08-27 11:55 UTC (permalink / raw)
To: Joel Schopp, Benjamin Herrenschmidt, Paul Mackerras,
Peter Zijlstra, Ingo Molnar, Vaidyanathan Srinivasan,
Dipankar Sarma, Balbir Singh, Gautham R Shenoy,
Pallipadi, Venkatesh, Arun Bharadwaj
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090827114908.GA24986@linux.vnet.ibm.com>
* Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-08-27 17:19:08]:
Set the idle routine to cpuidle_pm_idle after registering cpuidle
devices. Earlier pm_idle was assumed as the defualt idle loop by
cpuidle infrastructure. This is changed to an architecture independent
cpuidle_pm_idle.
There are 2 instances which are using cpuidle infrastructure currently.
This patch makes the change in both the places.
Signed-off-by: Arun R Bharadwaj <arun@linux.vnet.ibm.com>
---
arch/arm/mach-kirkwood/cpuidle.c | 6 ++++++
drivers/acpi/processor_idle.c | 5 +++++
2 files changed, 11 insertions(+)
Index: linux.trees.git/arch/arm/mach-kirkwood/cpuidle.c
===================================================================
--- linux.trees.git.orig/arch/arm/mach-kirkwood/cpuidle.c
+++ linux.trees.git/arch/arm/mach-kirkwood/cpuidle.c
@@ -90,6 +90,12 @@ static int kirkwood_init_cpuidle(void)
printk(KERN_ERR "kirkwood_init_cpuidle: Failed registering\n");
return -EIO;
}
+
+ if (pm_idle != cpuidle_pm_idle) {
+ printk(KERN_INFO "using cpuidle idle loop\n");
+ pm_idle = cpuidle_pm_idle;
+ }
+
return 0;
}
Index: linux.trees.git/drivers/acpi/processor_idle.c
===================================================================
--- linux.trees.git.orig/drivers/acpi/processor_idle.c
+++ linux.trees.git/drivers/acpi/processor_idle.c
@@ -1216,6 +1216,11 @@ int __cpuinit acpi_processor_power_init(
printk(" C%d[C%d]", i,
pr->power.states[i].type);
printk(")\n");
+
+ if (pm_idle != cpuidle_pm_idle) {
+ printk(KERN_INFO "using cpuidle idle loop\n");
+ pm_idle = cpuidle_pm_idle;
+ }
}
/* 'power' [R] */
^ permalink raw reply
* [PATCH 4/4]: CPUIDLE/POWER: Implement Pseries Processor Idle module
From: Arun R Bharadwaj @ 2009-08-27 11:57 UTC (permalink / raw)
To: Joel Schopp, Benjamin Herrenschmidt, Paul Mackerras,
Peter Zijlstra, Ingo Molnar, Vaidyanathan Srinivasan,
Dipankar Sarma, Balbir Singh, Gautham R Shenoy,
Pallipadi, Venkatesh, Arun Bharadwaj
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090827114908.GA24986@linux.vnet.ibm.com>
* Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-08-27 17:19:08]:
This patch creates arch/powerpc/platforms/pseries/processor_idle.c,
which implements the cpuidle infrastructure for pseries.
It implements a pseries_cpuidle_loop() which would be the main idle loop
called from cpu_idle(). It makes decision of entering either snooze or nap
state based on the decision taken by the cpuidle governor.
Signed-off-by: Arun R Bharadwaj <arun@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/Makefile | 1
arch/powerpc/platforms/pseries/processor_idle.c | 178 ++++++++++++++++++++++++
arch/powerpc/platforms/pseries/pseries.h | 14 +
arch/powerpc/platforms/pseries/setup.c | 3
4 files changed, 193 insertions(+), 3 deletions(-)
Index: linux.trees.git/arch/powerpc/platforms/pseries/Makefile
===================================================================
--- linux.trees.git.orig/arch/powerpc/platforms/pseries/Makefile
+++ linux.trees.git/arch/powerpc/platforms/pseries/Makefile
@@ -26,3 +26,4 @@ obj-$(CONFIG_HCALL_STATS) += hvCall_inst
obj-$(CONFIG_PHYP_DUMP) += phyp_dump.o
obj-$(CONFIG_CMM) += cmm.o
obj-$(CONFIG_DTL) += dtl.o
+obj-$(CONFIG_PSERIES_PROCESSOR_IDLE) += processor_idle.o
Index: linux.trees.git/arch/powerpc/platforms/pseries/pseries.h
===================================================================
--- linux.trees.git.orig/arch/powerpc/platforms/pseries/pseries.h
+++ linux.trees.git/arch/powerpc/platforms/pseries/pseries.h
@@ -10,6 +10,8 @@
#ifndef _PSERIES_PSERIES_H
#define _PSERIES_PSERIES_H
+#include <linux/cpuidle.h>
+
extern void __init fw_feature_init(const char *hypertas, unsigned long len);
struct pt_regs;
@@ -40,4 +42,16 @@ extern unsigned long rtas_poweron_auto;
extern void find_udbg_vterm(void);
+DECLARE_PER_CPU(unsigned long, smt_snooze_delay);
+
+#ifdef CONFIG_PSERIES_PROCESSOR_IDLE
+struct pseries_processor_power {
+ struct cpuidle_device dev;
+ int count;
+ int id;
+};
+
+extern struct cpuidle_driver pseries_idle_driver;
+#endif
+
#endif /* _PSERIES_PSERIES_H */
Index: linux.trees.git/arch/powerpc/platforms/pseries/processor_idle.c
===================================================================
--- /dev/null
+++ linux.trees.git/arch/powerpc/platforms/pseries/processor_idle.c
@@ -0,0 +1,178 @@
+/*
+ * processor_idle - idle state cpuidle driver.
+ * Adapted from drivers/acpi/processor_idle.c
+ *
+ * Arun R Bharadwaj <arun@linux.vnet.ibm.com>
+ *
+ * Copyright (C) 2009 IBM Corporation.
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/moduleparam.h>
+#include <linux/cpuidle.h>
+
+#include <asm/paca.h>
+#include <asm/reg.h>
+#include <asm/machdep.h>
+
+#include "plpar_wrappers.h"
+#include "pseries.h"
+
+MODULE_AUTHOR("Arun R Bharadwaj");
+MODULE_DESCRIPTION("pSeries Idle State Driver");
+MODULE_LICENSE("GPL");
+
+struct cpuidle_driver pseries_idle_driver = {
+ .name = "pseries_idle",
+ .owner = THIS_MODULE,
+};
+
+DEFINE_PER_CPU(struct pseries_processor_power, power);
+
+#define IDLE_STATE_COUNT 2
+
+static int pseries_idle_init(struct pseries_processor_power *power)
+{
+ return cpuidle_register_device(&power->dev);
+}
+
+static void snooze(void)
+{
+ local_irq_enable();
+ set_thread_flag(TIF_POLLING_NRFLAG);
+ while (!need_resched()) {
+ ppc64_runlatch_off();
+ HMT_low();
+ HMT_very_low();
+ }
+ HMT_medium();
+ clear_thread_flag(TIF_POLLING_NRFLAG);
+ smp_mb();
+ local_irq_disable();
+}
+
+static void nap(void)
+{
+ ppc64_runlatch_off();
+ HMT_medium();
+ cede_processor();
+}
+
+static int pseries_cpuidle_loop(struct cpuidle_device *dev,
+ struct cpuidle_state *st)
+{
+ ktime_t t1, t2;
+ s64 diff;
+ int ret;
+ unsigned long in_purr, out_purr;
+
+ get_lppaca()->idle = 1;
+ get_lppaca()->donate_dedicated_cpu = 1;
+ in_purr = mfspr(SPRN_PURR);
+
+ t1 = ktime_get();
+
+ if (strcmp(st->desc, "snooze") == 0)
+ snooze();
+ else
+ nap();
+
+ t2 = ktime_get();
+ diff = ktime_to_us(ktime_sub(t2, t1));
+ if (diff > INT_MAX)
+ diff = INT_MAX;
+
+ ret = (int) diff;
+
+ out_purr = mfspr(SPRN_PURR);
+ get_lppaca()->wait_state_cycles += out_purr - in_purr;
+ get_lppaca()->donate_dedicated_cpu = 0;
+ get_lppaca()->idle = 0;
+
+ return ret;
+}
+
+static int pseries_setup_cpuidle(struct pseries_processor_power *power)
+{
+ int i;
+ struct cpuidle_state *state;
+ struct cpuidle_device *dev = &power->dev;
+
+ dev->cpu = power->id;
+
+ dev->enabled = 0;
+ for (i = 0; i < IDLE_STATE_COUNT; i++) {
+ state = &dev->states[i];
+
+ snprintf(state->name, CPUIDLE_NAME_LEN, "IDLE%d", i);
+ state->enter = pseries_cpuidle_loop;
+
+ switch (i) {
+ case 0:
+ strncpy(state->desc, "snooze", CPUIDLE_DESC_LEN);
+ state->exit_latency = 0;
+ state->target_residency = 0;
+ break;
+
+ case 1:
+ strncpy(state->desc, "nap", CPUIDLE_DESC_LEN);
+ state->exit_latency = 1;
+ state->target_residency =
+ __get_cpu_var(smt_snooze_delay);
+ break;
+ }
+ }
+
+ power->dev.state_count = i;
+ return 0;
+}
+
+static int pseries_get_power_info(struct pseries_processor_power *power,
+ int cpu)
+{
+ power->id = cpu;
+ power->count = IDLE_STATE_COUNT;
+ return 0;
+}
+
+static int __init pseries_processor_idle_init(void)
+{
+ int cpu;
+ int result = cpuidle_register_driver(&pseries_idle_driver);
+
+ if (result < 0)
+ return result;
+
+ printk(KERN_DEBUG "pSeries idle driver registered\n");
+
+ for_each_online_cpu(cpu) {
+ pseries_get_power_info(&per_cpu(power, cpu), cpu);
+ pseries_setup_cpuidle(&per_cpu(power, cpu));
+ pseries_idle_init(&per_cpu(power, cpu));
+ }
+
+ printk(KERN_DEBUG "Using cpuidle idle loop\n");
+ ppc_md.power_save = cpuidle_pm_idle;
+ return 0;
+}
+
+late_initcall(pseries_processor_idle_init);
Index: linux.trees.git/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/platforms/pseries/setup.c
+++ linux.trees.git/arch/powerpc/platforms/pseries/setup.c
@@ -500,9 +500,6 @@ static int __init pSeries_probe(void)
return 1;
}
-
-DECLARE_PER_CPU(unsigned long, smt_snooze_delay);
-
static void pseries_dedicated_idle_sleep(void)
{
unsigned int cpu = smp_processor_id();
^ permalink raw reply
* Re: [PATCH] fix book E watchdog to take WDIOC_SETTIMEOUT arg in seconds
From: Josh Boyer @ 2009-08-27 12:08 UTC (permalink / raw)
To: Wim Van Sebroeck; +Cc: Linux kernel, linuxppc-dev
In-Reply-To: <20090827111458.GB29382@infomag.iguana.be>
On Thu, Aug 27, 2009 at 01:14:58PM +0200, Wim Van Sebroeck wrote:
>Hi Chris,
>
>> The WDIOC_SETTIMEOUT argument is supposed to be a "seconds" value.
>> However, the book E wdt currently treats it as a "period" which is
>> interpreted in a board-specific way.
>>
>> This patch allows the user to pass in a "seconds" value and the driver
>> will set the smallest timeout that is at least as large as specified
>> by the user. It's been tested on e500 hardware and works as
>> expected.
>>
>> The patch only modifies the CONFIG_FSL_BOOKE case, the CONFIG_4xx case
>> is left unmodified as I don't have any hardware to test it on.
>>
>> Signed-off-by: Chris Friesen <cfriesen@nortel.com>
>
>Added with some small changes to keep checkpatch happy. (removed trailing spaces + changed sizeof(struct watchdog_info) to sizeof(ident) and changed some spaces in tabs).
>
>Now we only need someone that can look at the CONFIG_4xx cases still :-)
It seems the FSL watchdog is much more flexible than the one found in 4xx
cores. On 4xx, you basically have 4 static choices that represent specific
times determined by the clock frequency. I'm concerned that the lack of
granularity here will result in less than desirable behavior.
For example, with a 400MHz clock you would get choices of roughly:
5.2 ms
83.9 ms
1.34 s
21.47 s
Personally, I consider the first two options basically unusable. Considering
the second two, if a user were to say "Set the timeout for 2 seconds" they
would then get a timeout of 21 seconds with the framework Chris' patch has
set up. That doesn't really seem to be ideal to me.
josh
^ permalink raw reply
* Re: [PATCH 2/4]: CPUIDLE: Introduce architecture independent cpuidle_pm_idle in drivers/cpuidle/cpuidle.c
From: Peter Zijlstra @ 2009-08-27 12:53 UTC (permalink / raw)
To: arun
Cc: Gautham R Shenoy, Pallipadi, Venkatesh, linux-kernel,
Paul Mackerras, Ingo Molnar, linuxppc-dev, Balbir Singh
In-Reply-To: <20090827115354.GC24986@linux.vnet.ibm.com>
On Thu, 2009-08-27 at 17:23 +0530, Arun R Bharadwaj wrote:
> * Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-08-27 17:19:08]:
>
> Cpuidle infrastructure assumes pm_idle as the default idle routine.
> But, ppc_md.power_save is the default idle callback in case of pSeries.
>
> So, create a more generic, architecture independent cpuidle_pm_idle
> function pointer in driver/cpuidle/cpuidle.c and allow the idle routines
> of architectures to be set to cpuidle_pm_idle.
>
> Signed-off-by: Arun R Bharadwaj <arun@linux.vnet.ibm.com>
> ---
> drivers/cpuidle/cpuidle.c | 12 +++++++-----
> include/linux/cpuidle.h | 7 +++++++
> 2 files changed, 14 insertions(+), 5 deletions(-)
>
> Index: linux.trees.git/drivers/cpuidle/cpuidle.c
> ===================================================================
> --- linux.trees.git.orig/drivers/cpuidle/cpuidle.c
> +++ linux.trees.git/drivers/cpuidle/cpuidle.c
> @@ -25,6 +25,7 @@ DEFINE_PER_CPU(struct cpuidle_device *,
> DEFINE_MUTEX(cpuidle_lock);
> LIST_HEAD(cpuidle_detected_devices);
> static void (*pm_idle_old)(void);
> +void (*cpuidle_pm_idle)(void);
>
> static int enabled_devices;
>
> @@ -98,10 +99,10 @@ static void cpuidle_idle_call(void)
> */
> void cpuidle_install_idle_handler(void)
> {
> - if (enabled_devices && (pm_idle != cpuidle_idle_call)) {
> + if (enabled_devices && (cpuidle_pm_idle != cpuidle_idle_call)) {
> /* Make sure all changes finished before we switch to new idle */
> smp_wmb();
> - pm_idle = cpuidle_idle_call;
> + cpuidle_pm_idle = cpuidle_idle_call;
> }
> }
>
> @@ -110,8 +111,9 @@ void cpuidle_install_idle_handler(void)
> */
> void cpuidle_uninstall_idle_handler(void)
> {
> - if (enabled_devices && pm_idle_old && (pm_idle != pm_idle_old)) {
> - pm_idle = pm_idle_old;
> + if (enabled_devices && pm_idle_old &&
> + (cpuidle_pm_idle != pm_idle_old)) {
> + cpuidle_pm_idle = pm_idle_old;
> cpuidle_kick_cpus();
> }
> }
> @@ -382,7 +384,7 @@ static int __init cpuidle_init(void)
> {
> int ret;
>
> - pm_idle_old = pm_idle;
> + pm_idle_old = cpuidle_pm_idle;
>
> ret = cpuidle_add_class_sysfs(&cpu_sysdev_class);
> if (ret)
> Index: linux.trees.git/include/linux/cpuidle.h
> ===================================================================
> --- linux.trees.git.orig/include/linux/cpuidle.h
> +++ linux.trees.git/include/linux/cpuidle.h
> @@ -188,4 +188,11 @@ static inline void cpuidle_unregister_go
> #define CPUIDLE_DRIVER_STATE_START 0
> #endif
>
> +/*
> + * Idle callback used by cpuidle to call the cpuidle_idle_call().
> + * Platform drivers can use this to register to cpuidle's idle loop.
> + */
> +
> +extern void (*cpuidle_pm_idle)(void);
> +
> #endif /* _LINUX_CPUIDLE_H */
I'm not quite seeing how this makes anything any better. Not we have 3
function pointers, where 1 should suffice.
/me wonders what's wrong with something like:
struct idle_func_desc {
int power;
int latency;
void (*idle)(void);
struct list_head list;
};
static void spin_idle(void)
{
for (;;)
cpu_relax();
}
static idle_func_desc default_idle_func = {
power = 0, /* doesn't safe any power */
latency = INT_MAX, /* has max latency */
idle = spin_idle,
list = INIT_LIST_HEAD(default_idle_func.list),
};
void (*idle_func)(void);
static struct list_head idle_func_list;
static void pick_idle_func(void)
{
struct idle_func_desc *desc, *idle = &default_idle_desc;
list_for_each_entry(desc, &idle_func_list, list) {
if (desc->power < idle->power)
continue;
if (desc->latency > target_latency);
continue;
idle = desc;
}
pm_idle = idle->idle;
}
void register_idle_func(struct idle_func_desc *desc)
{
WARN_ON_ONCE(!list_empty(&desc->list));
list_add_tail(&idle_func_list, &desc->list);
pick_idle_func();
}
void unregister_idle_func(struct idle_func_desc *desc)
{
WARN_ON_ONCE(list_empty(&desc->list));
list_del_init(&desc->list);
if (idle_func == desc->idle)
pick_idle_func();
}
^ permalink raw reply
* Re: LITE5200 configuration
From: Wolfgang Denk @ 2009-08-27 13:11 UTC (permalink / raw)
To: FIXED-TERM Seeh Thomas (BEG/EMS1); +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6E9D235B18CE694399D781F05D9C42E79F0C2C12@SI-MBX11.de.bosch.com>
Dear "FIXED-TERM Seeh Thomas (BEG/EMS1)",
In message <6E9D235B18CE694399D781F05D9C42E79F0C2C12@SI-MBX11.de.bosch.com> you wrote:
>
> I'll try to run a 2.6.31-rc7 kernel on my Lite5200 board.
Is this really a Lite5200, or is it a Lite5200B?
Hint: if U-Boot prints something like "CPU: MPC5200B v2.2, Core v1.4"
then its a 5200B, and thus a Lite5200 board.
> For the device tree I use lite5200.dts and compiled it simply with
>
> make ARCH=powerpc CROSS_COMPILE=ppc_6xx- lite5200.dtb
For a Lite5200B you should use the lite5200b device tree.
> But I'm not sure what configuration for the kernel I should choose. There is no
> lite5200_defconfig only one for the lite5200b.
Rigth. Because there are virtually no lite5200 boards out there.
> I tried it with mpc5200_defconfig and lite5200b_defconfig, but I'm not sure which
> is the right way.
Both will work. On a Lite5200 board I would use lite5200b_defconfig,
though.
> For compiling the kernel I use:
>
> make ARCH=powerpc CROSS_COMPILE=ppc_6xx- "CONFIG_FILE"
That's:
make ARCH=powerpc CROSS_COMPILE=ppc_6xx- mrproper
make ARCH=powerpc CROSS_COMPILE=ppc_6xx- 52xx/lite5200b_defconfig
> make ARCH=powerpc CROSS_COMPILE=ppc_6xx- uImage
> make ARCH=powerpc CROSS_COMPILE=ppc_6xx- modules
> make ARCH=powerpc CROSS_COMPILE=ppc_6xx- modules_install
> I use U-Boot 2009.06, with the following settings for bootup:
Looks as if you have a Rev. B CPU with the wrong device tree.
Unfortunaltey you omit the interesting part (i. e. the U-Boot boot
message) which would contain this important piece of information.
> --_000_6E9D235B18CE694399D781F05D9C42E79F0C2C12SIMBX11deboschc_
> Content-Type: text/html; charset"iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
And *please* do not post HTML to mailing lists. Never ever do that.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If I ever needed a brain transplant, I'd choose a teenager's because
I'd want a brain that had never been used.
^ permalink raw reply
* Re: [ewg] [PATCH] IB/ehca: Construct MAD redirect replies from request MAD
From: Hal Rosenstock @ 2009-08-27 13:31 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Hal Rosenstock, OF-EWG, LKML, Jason Gunthorpe, LinuxPPC-Dev,
Christoph Raisch, OF-General, Stefan Roscher
In-Reply-To: <OFF2257478.FF0FEABE-ONC125761F.00344884-C125761F.00358310@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]
On 8/27/09, Joachim Fenkes <FENKES@de.ibm.com> wrote:
>
> Hal Rosenstock <hal.rosenstock@gmail.com> wrote on 26.08.2009 17:15:03:
>
> > Thanks for doing this. It looks sane to me. The only issue I recall that
>
> > appears to be remaining is a better setting of
> ClassPortInfo:RespTimeValue
> > rather than hardcoding. Perhaps using the value from PortInfo is the way
> to go
> > (ideally it would be that value from the port to which the the requester
> is
> > being redirected to but that might not be so easy to get from this port.
>
> I don't think that effort will be necessary or even legal. The requestor
> will react to the redirection with another Get(ClassPortInfo) to the
> redirection target, which will reply with its own RespTimeValue, so our
> driver should speak for itself.
I overreached with my comment on how this works.
Since we don't know when our MAD
> processing and sending of the response is going to be scheduled (we're not
> running on real-time constraints here), we play it safe and return 18,
> which amounts to roughly a second.
>
> Make sense?
I don't think it should be hard coded. IMO it would be better to default to
18 and somehow able to be adjusted (via a (dynamic) module parameter ?).
-- Hal
> Regards
> Joachim
>
[-- Attachment #2: Type: text/html, Size: 2122 bytes --]
^ permalink raw reply
* Re: Extending virtio_console to support multiple ports
From: Ryan Arnold @ 2009-08-27 14:13 UTC (permalink / raw)
To: Amit Shah
Cc: kvm, linuxppc-dev, linux-kernel, miltonm, qemu-devel, borntraeger,
brueckner, virtualization, alan
In-Reply-To: <20090827065251.GB3218@amit-x200.redhat.com>
On Thu, 2009-08-27 at 12:22 +0530, Amit Shah wrote:
> On (Thu) Aug 27 2009 [15:04:45], Michael Ellerman wrote:
> Ryan you called his code "pure legacy baggage" if you
> > don't ;)
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commitdiff;h=d450b4ae023fb4be175389c18f4f87677da03020
>
> Thanks for the link!
>
> (and this general area might be the one that doesn't get major upheavals
> in 5-yr spans :-)
Actually, quite the opposite... too many cooks in the kitchen in the
last 6 years have left this code with some historical oddities. When I
added the interrupt context code in the first place I made sure that the
driver did NOTHING in the interrupt handler except awaken the working
thread. Someone in the subsequent years thought it'd be a good idea to
have the interrupt handler actually do the work.
Furthermore the front and backends were separated so that new front ends
can be used. This was sometime in the last 5 years as well.
Let's just say I'm happy to pass the torch on this one.
I would suggest that someone perform throughput tests on this driver at
some point. At the point where I stopped maintaining it I'd gotten the
driver to the point where there was no jerking output or lost data under
heavy I/O load. I'm not sure where the driver's at now.
Ryan S. Arnold
^ permalink raw reply
* AW: LITE5200 configuration
From: FIXED-TERM Seeh Thomas (BEG/EMS1) @ 2009-08-27 14:14 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20090827131151.537EC833DBD2@gemini.denx.de>
Dear Mr Denk,
thanks for your reply. I checked out kernel 2.6.30.3 stable for testing too=
.
I mean it's really a Lite5200. That is the U-boot boot message:
U-Boot 2009.06 (Aug 26 2009 - 08:23:36)
CPU: MPC5200 v1.2, Core v1.1 at 231 MHz
Bus 66 MHz, IPB 33 MHz, PCI 16.500 MHz
Board: Motorola MPC5200 (IceCube)
I2C: 85 kHz, ready
DRAM: 64 MB
FLASH: 16 MB
PCI: Bus Dev VenId DevId Class Int
00 1a 1057 5803 0680 00
In: serial
Out: serial
Err: serial
Net: FEC ETHERNET
IDE: Bus 0: not available
For kernel I use:
make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- mrproper
make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- 52xx/lite5200b_defconf=
ig
make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- uImage
make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- modules
make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- modules_install
And the device tree lite5200.dts
make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- lite5200.dtb
And the U-boot configuration:
=3D> print kernel_addr fdt_addr bootargs
kernel_addr=3D900000
fdt_addr=3Db00000
bootargs=3Dconsole=3DttyPSC0,115200 root=3D/dev/nfs rw nfsroot=3D10.10.0.2:=
/opt/eldk/ppc
_82xx ip=3D10.10.0.99:10.10.0.2::255.255.255.0:icecube::off panic=3D1
=3D> print bootfile dtbfile
bootfile=3D/tftpboot/uImage
dtbfile=3D/tftpboot/lite5200.dtb
=3D> tftp ${kernel_addr} ${boofile}; tftp ${fdt_addr} ${dtbfile}
Using FEC ETHERNET device
TFTP from server 10.10.0.2; our IP address is 10.10.0.99
Filename '/tftpboot/uImage'.
Load address: 0x900000
Loading: #################################################################
#################################################################
#################################################################
################################################################=
#
#############################
done
Bytes transferred =3D 1478573 (168fad hex)
Using FEC ETHERNET device
TFTP from server 10.10.0.2; our IP address is 10.10.0.99
Filename '/tftpboot/lite5200.dtb'.
Load address: 0xb00000
Loading: ##
done
Bytes transferred =3D 5375 (14ff hex)
=3D> bootm ${kernel_addr} - ${fdt_addr}
## Booting kernel from Legacy Image at 00900000 ...
Image Name: Linux-2.6.30.3-00002-gdae6b8c
Created: 2009-08-27 13:55:57 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1478509 Bytes =3D 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 00b00000
Booting using the fdt blob at 0xb00000
Uncompressing Kernel Image ... OK
Loading Device Tree to 007fb000, end 007ff4fe ... OK
[ 0.000000] Using lite5200 machine description
[ 0.000000] Linux version 2.6.30.3-00002-gdae6b8c (root@user-laptop) (gc=
c ver
sion 4.2.2) #1 Thu Aug 27 15:55:37 CEST 2009
------snip---------
[ 2346.499181] VFS: Mounted root (nfs filesystem) on device 0:11.
[ 2346.505748] Freeing unused kernel memory: 160k init
[ 2346.865420] net eth0: FEC_IEVENT_RFIFO_ERROR
[ 2346.871668] ------------[ cut here ]------------
[ 2346.876434] Kernel BUG at c01ae1d0 [verbose debug info unavailable]
[ 2346.882852] Oops: Exception in kernel mode, sig: 5 [#1]
[ 2346.888184] lite5200
[ 2346.890416] Modules linked in:
[ 2346.893544] NIP: c01ae1d0 LR: c01af504 CTR: c0011190
[ 2346.898622] REGS: c02ff9e0 TRAP: 0700 Not tainted (2.6.30.3-00002-gda=
e6b8
[ 2346.905991] MSR: 00029032 <EE,ME,CE,IR,DR> CR: 24000024 XER: 00000000
[ 2346.912796] TASK =3D c02dc588[0] 'swapper' THREAD: c02fe000
[ 2346.918127] GPR00: 00010200 c02ffa90 c02dc588 c3954e00 00000001 00000000=
0000
8000 00000000
[ 2346.926693] GPR08: 000000a2 c02fe000 c0327000 c5036000 84000022 ffcf5fff=
03fb
8000 03fa8878
[ 2346.935261] GPR16: 03f81ae8 03fa8854 03f45dcc 03f45ccc 03f45bee c031a138=
c389
be00 0a0a0063
[ 2346.943830] GPR24: c03191a8 00008000 00000000 00000001 c3835b20 c3954e00=
c383
5800 08820000
[ 2346.952582] Call Trace:
[ 2346.955088] [c02ffa90] [c01aefac] 0xc01aefac (unreliable)
[ 2346.960611] [c02ffac0] [c01af504] 0xc01af504
[ 2346.964977] [c02ffae0] [c01af8a4] 0xc01af8a4
[ 2346.969344] --- Exception: c38eb0f0 at 0xc38eb0c0
[ 2346.969361] LR =3D 0xc02ddfc0
[ 2346.977347] [c02ffb00] [c004e6c0] 0xc004e6c0 (unreliable)
[ 2346.982869] [c02ffb20] [c0050a7c] 0xc0050a7c
[ 2346.987232] [c02ffb30] [c0006514] 0xc0006514
[ 2346.991595] [c02ffb50] [c0012014] 0xc0012014
[ 2346.995962] --- Exception: 501 at 0xc0035db8
[ 2346.995978] LR =3D 0xc0035db0
[ 2347.003522] [c02ffc30] [c0035e70] 0xc0035e70
[ 2347.007889] [c02ffc40] [c02322e4] 0xc02322e4
[ 2347.012255] [c02ffc70] [c0232ddc] 0xc0232ddc
[ 2347.016621] [c02ffc80] [c022d0b8] 0xc022d0b8
[ 2347.020985] [c02ffca0] [c0231250] 0xc0231250
[ 2347.025351] [c02ffcd0] [c01bb904] 0xc01bb904
[ 2347.029715] [c02ffcf0] [c0203cbc] 0xc0203cbc
[ 2347.034082] [c02ffd10] [c02052cc] 0xc02052cc
[ 2347.038447] [c02ffd60] [c01e2f78] 0xc01e2f78
[ 2347.042811] [c02ffd80] [c01e3360] 0xc01e3360
[ 2347.047176] [c02ffdb0] [c01c7688] 0xc01c7688
[ 2347.051541] [c02ffde0] [c01c9ec8] 0xc01c9ec8
[ 2347.055905] [c02ffe10] [c01ca200] 0xc01ca200
[ 2347.060273] [c02ffe40] [c00296c0] 0xc00296c0
[ 2347.064640] [c02ffe70] [c0006474] 0xc0006474
[ 2347.069005] [c02ffe80] [c0029538] 0xc0029538
[ 2347.073368] [c02ffe90] [c0006518] 0xc0006518
[ 2347.077733] [c02ffeb0] [c0012014] 0xc0012014
[ 2347.082097] --- Exception: 501 at 0xc001fa98
[ 2347.082113] LR =3D 0xc024af4c
[ 2347.089655] [c02fff70] [c030648c] 0xc030648c (unreliable)
[ 2347.095178] [c02fff80] [c024af4c] 0xc024af4c
[ 2347.099544] [c02fff90] [c0009360] 0xc0009360
[ 2347.103912] [c02fffb0] [c0003e04] 0xc0003e04
[ 2347.108280] [c02fffc0] [c02b280c] 0xc02b280c
[ 2347.112644] [c02ffff0] [00003438] 0x003438
[ 2347.116829] Instruction dump:
[ 2347.119865] 4e800020 9421ffd0 7c0802a6 bf210014 54290024 7c7d1b78 900100=
34 7c
9b2378
[ 2347.127818] 7cba2b78 7cd93378 8009000c 5400016e <0f000000> 3b830028 7f83=
e378
4809d545
[ 2347.135966] Kernel panic - not syncing: Fatal exception in interrupt
[ 2347.142459] Rebooting in 1 seconds..
Then I enabled "Verbose debug info" in the kernel:
------snip---------
[ 0.000000] Kernel command line: console=3DttyPSC0,115200 root=3D/dev/nf=
s rw nfsr
oot=3D10.10.0.2:/opt/eldk/ppc_82xx ip=3D10.10.0.99:10.10.0.2::255.255.255.0=
:icecube:
:off panic=3D1
[ 0.000000] NR_IRQS:512
[ 0.000000] MPC52xx PIC is up and running!
[ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
[ 0.000000] clocksource: timebase mult[f26c9b2] shift[22] registered
[ 0.000713] console [ttyPSC0] enabled
[ 0.117286] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes=
)
[ 0.125426] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.152478] Memory: 61656k/65536k available (2924k kernel code, 3816k re=
serve
d, 144k data, 108k bss, 160k init)
[ 0.162876] Kernel virtual memory layout:
[ 0.167060] * 0xffffe000..0xfffff000 : fixmap
[ 0.171855] * 0xfcff7000..0xfe000000 : early ioremap
[ 0.177269] * 0xc5000000..0xfcff7000 : vmalloc & ioremap
[ 0.183361] SLUB: Genslabs=3D13, HWalign=3D32, Order=3D0-3, MinObjects=
=3D0, CPUs=3D1, N
odes=3D1
[ 0.191369] Calibrating delay loop... 32.89 BogoMIPS (lpj=3D65792)
[ 0.282554] Mount-cache hash table entries: 512
[ 0.296476] net_namespace: 520 bytes
[ 0.302403] NET: Registered protocol family 16
[ 0.358376] PCI: Probing PCI hardware
[ 0.366037] DMA: MPC52xx BestComm driver
[ 0.370969] DMA: MPC52xx BestComm engine @f0001200 ok !
[ 0.426505] bio: create slab <bio-0> at 0
[ 0.437399] SCSI subsystem initialized
[ 0.462352] NET: Registered protocol family 2
[ 0.467454] IP route cache hash table entries: 1024 (order: 0, 4096 byte=
s)
[ 0.476064] TCP established hash table entries: 2048 (order: 2, 16384 by=
tes)
[ 0.483852] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.490731] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.497361] TCP reno registered
[ 0.501444] NET: Registered protocol family 1
[ 0.611975] msgmni has been set to 120
[ 0.620172] alg: No test for stdrng (krng)
[ 0.624938] io scheduler noop registered
[ 0.629262] io scheduler anticipatory registered (default)
[ 0.635048] io scheduler deadline registered
[ 0.640058] io scheduler cfq registered
[ 1.812580] Generic RTC Driver v1.07
[ 1.819176] Serial: MPC52xx PSC UART driver
[ 1.824364] f0002000.serial: ttyPSC0 at MMIO 0xf0002000 (irq =3D 129) is=
a MPC5
2xx PSC
[ 1.882486] brd: module loaded
[ 1.909250] loop: module loaded
[ 1.914148] Driver 'sd' needs updating - please use bus_type methods
[ 1.922284] ata: MPC52xx IDE/ATA libata driver
[ 1.929082] scsi0 : mpc52xx_ata
[ 1.934723] ata1: PATA max PIO4 ata_regs 0xf0003a00 irq 135
[ 1.994561] mpc52xx MII bus: probed
[ 2.003553] net eth0: Using PHY at MDIO address 1
[ 2.010075] i2c /dev entries driver
[ 2.029480] TCP cubic registered
[ 2.033132] NET: Registered protocol family 17
[ 2.040730] RPC: Registered udp transport module.
[ 2.045776] RPC: Registered tcp transport module.
[ 2.574473] net eth0: attached phy 1 to driver Generic PHY
[ 3.582953] IP-Config: Complete:
[ 3.586267] device=3Deth0, addr=3D10.10.0.99, mask=3D255.255.255.0,=
gw=3D255.255
.255.255,
[ 3.594532] host=3Dicecube, domain=3D, nis-domain=3D(none),
[ 3.600258] bootserver=3D10.10.0.2, rootserver=3D10.10.0.2, rootpat=
h=3D
[ 3.608107] Looking up port of RPC 100003/2 on 10.10.0.2
[ 3.619215] Looking up port of RPC 100005/1 on 10.10.0.2
[ 3.714264] VFS: Mounted root (nfs filesystem) on device 0:11.
[ 3.720825] Freeing unused kernel memory: 160k init
[ 3.871314] net eth0: FEC_IEVENT_RFIFO_ERROR
[ 3.877660] ------------[ cut here ]------------
[ 3.882425] kernel BUG at drivers/net/phy/mdio_bus.c:263!
[ 3.887951] Oops: Exception in kernel mode, sig: 5 [#1]
[ 3.893276] lite5200
[ 3.895502] Modules linked in:
[ 3.898630] NIP: c01ae268 LR: c01af59c CTR: c0011190
[ 3.903707] REGS: c38253a0 TRAP: 0700 Not tainted (2.6.30.3-00002-gda=
e6b8c
)
[ 3.911070] MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22002024 XER: 00000000
[ 3.917871] TASK =3D c3820000[1] 'init' THREAD: c3824000
[ 3.922933] GPR00: 00010100 c3825450 c3820000 c3922e00 00000001 00000000=
0000
8000 00000000
[ 3.931497] GPR08: 00000035 c3824000 c0329000 c5036000 22002022 ffcf5fff=
c031
b1a8 0a0a0002
[ 3.940061] GPR16: 00000000 00000000 00000000 00000801 00000000 c39366c0=
0000
0000 c39f6930
[ 3.948626] GPR24: 00000000 00008000 00000000 00000001 c383fb20 c3922e00=
c383
f800 08820000
[ 3.957367] Call Trace:
[ 3.959867] [c3825450] [c01af044] 0xc01af044 (unreliable)
[ 3.965382] [c3825480] [c01af59c] 0xc01af59c
[ 3.969745] [c38254a0] [c01af93c] 0xc01af93c
[ 3.974108] [c38254c0] [c004e6c4] 0xc004e6c4
[ 3.978471] [c38254e0] [c0050a80] 0xc0050a80
[ 3.982830] [c38254f0] [c0006514] 0xc0006514
[ 3.987189] [c3825510] [c0012014] 0xc0012014
[ 3.991552] --- Exception: 501 at 0xc0016540
[ 3.991566] LR =3D 0xc01bed30
[ 3.999106] [c38255d0] [c01c9f60] 0xc01c9f60 (unreliable)
[ 4.004625] [c3825610] [c022eca8] 0xc022eca8
[ 4.008987] [c3825630] [c022ea20] 0xc022ea20
[ 4.013349] [c3825670] [c022eae0] 0xc022eae0
[ 4.017709] [c3825690] [c0231234] 0xc0231234
[ 4.022072] [c38256c0] [c01bb99c] 0xc01bb99c
[ 4.026434] [c38256e0] [c0203d54] 0xc0203d54
[ 4.030795] [c3825700] [c01ba4f4] 0xc01ba4f4
[ 4.035155] [c3825720] [c02059fc] 0xc02059fc
[ 4.039518] [c38257d0] [c020cdf0] 0xc020cdf0
[ 4.043878] [c38257f0] [c01b8a78] 0xc01b8a78
[ 4.048242] [c38258d0] [c01b8e5c] 0xc01b8e5c
[ 4.052605] [c38258f0] [c022f448] 0xc022f448
[ 4.056967] [c3825930] [c022f4f8] 0xc022f4f8
[ 4.061329] [c3825960] [c0231044] 0xc0231044
[ 4.065690] [c3825980] [c022defc] 0xc022defc
[ 4.070052] [c38259b0] [c022c064] 0xc022c064
[ 4.074413] [c38259d0] [c02327b0] 0xc02327b0
[ 4.078774] [c3825a10] [c022b200] 0xc022b200
[ 4.083136] [c3825a20] [c0101b38] 0xc0101b38
[ 4.087499] [c3825a90] [c00ff5c4] 0xc00ff5c4
[ 4.091861] [c3825aa0] [c00ff658] 0xc00ff658
[ 4.096221] [c3825ab0] [c0101624] 0xc0101624
[ 4.100581] [c3825ad0] [c005bcdc] 0xc005bcdc
[ 4.104943] [c3825b00] [c01012a4] 0xc01012a4
[ 4.109307] [c3825b60] [c005b77c] 0xc005b77c
[ 4.113667] [c3825bb0] [c0055454] 0xc0055454
[ 4.118029] [c3825bf0] [c0066ac0] 0xc0066ac0
[ 4.122392] [c3825c40] [c00147e8] 0xc00147e8
[ 4.126754] [c3825cf0] [c0011dac] 0xc0011dac
[ 4.131116] --- Exception: 301 at 0xc0016300
[ 4.131130] LR =3D 0xc00b6f18
[ 4.138667] [c3825db0] [c396b9b4] 0xc396b9b4 (unreliable)
[ 4.144186] [c3825dd0] [c00b8454] 0xc00b8454
[ 4.148548] [c3825e60] [c00841b4] 0xc00841b4
[ 4.152911] [c3825e90] [c00851d4] 0xc00851d4
[ 4.157272] [c3825ed0] [c0008c28] 0xc0008c28
[ 4.161634] [c3825ef0] [c001197c] 0xc001197c
[ 4.165998] --- Exception: c01 at 0xc0010d54
[ 4.166012] LR =3D 0xc0003a18
[ 4.173550] [c3825fb0] [c008c634] 0xc008c634 (unreliable)
[ 4.179068] [c3825fc0] [c0003adc] 0xc0003adc
[ 4.183431] [c3825fd0] [c02b31f0] 0xc02b31f0
[ 4.187792] [c3825ff0] [c00117a0] 0xc00117a0
[ 4.192147] Instruction dump:
[ 4.195178] 4e800020 9421ffd0 7c0802a6 bf210014 54290024 7c7d1b78 900100=
34 7c
9b2378
[ 4.203121] 7cba2b78 7cd93378 8009000c 5400016e <0f000000> 3b830028 7f83=
e378
4809d555
[ 4.211252] Kernel panic - not syncing: Fatal exception in interrupt
[ 4.217731] Call Trace:
[ 4.220227] [c38251f0] [c0008274] 0xc0008274 (unreliable)
[ 4.225743] [c3825230] [c0023b4c] 0xc0023b4c
[ 4.230103] [c3825280] [c000f678] 0xc000f678
[ 4.234463] [c38252a0] [c000f900] 0xc000f900
[ 4.238828] [c3825390] [c0011fc8] 0xc0011fc8
[ 4.243188] --- Exception: 700 at 0xc01ae268
[ 4.243202] LR =3D 0xc01af59c
[ 4.250742] [c3825450] [c01af044] 0xc01af044 (unreliable)
[ 4.256259] [c3825480] [c01af59c] 0xc01af59c
[ 4.260618] [c38254a0] [c01af93c] 0xc01af93c
[ 4.264979] [c38254c0] [c004e6c4] 0xc004e6c4
[ 4.269338] [c38254e0] [c0050a80] 0xc0050a80
[ 4.273701] [c38254f0] [c0006514] 0xc0006514
[ 4.278062] [c3825510] [c0012014] 0xc0012014
[ 4.282421] --- Exception: 501 at 0xc0016540
[ 4.282435] LR =3D 0xc01bed30
[ 4.289973] [c38255d0] [c01c9f60] 0xc01c9f60 (unreliable)
[ 4.295492] [c3825610] [c022eca8] 0xc022eca8
[ 4.299858] [c3825630] [c022ea20] 0xc022ea20
[ 4.304217] [c3825670] [c022eae0] 0xc022eae0
[ 4.308580] [c3825690] [c0231234] 0xc0231234
[ 4.312941] [c38256c0] [c01bb99c] 0xc01bb99c
[ 4.317304] [c38256e0] [c0203d54] 0xc0203d54
[ 4.321666] [c3825700] [c01ba4f4] 0xc01ba4f4
[ 4.326027] [c3825720] [c02059fc] 0xc02059fc
[ 4.330388] [c38257d0] [c020cdf0] 0xc020cdf0
[ 4.334749] [c38257f0] [c01b8a78] 0xc01b8a78
[ 4.339111] [c38258d0] [c01b8e5c] 0xc01b8e5c
[ 4.343472] [c38258f0] [c022f448] 0xc022f448
[ 4.347833] [c3825930] [c022f4f8] 0xc022f4f8
[ 4.352195] [c3825960] [c0231044] 0xc0231044
[ 4.356557] [c3825980] [c022defc] 0xc022defc
[ 4.360920] [c38259b0] [c022c064] 0xc022c064
[ 4.365282] [c38259d0] [c02327b0] 0xc02327b0
[ 4.369641] [c3825a10] [c022b200] 0xc022b200
[ 4.374003] [c3825a20] [c0101b38] 0xc0101b38
[ 4.378364] [c3825a90] [c00ff5c4] 0xc00ff5c4
[ 4.382726] [c3825aa0] [c00ff658] 0xc00ff658
[ 4.387087] [c3825ab0] [c0101624] 0xc0101624
[ 4.391448] [c3825ad0] [c005bcdc] 0xc005bcdc
[ 4.395810] [c3825b00] [c01012a4] 0xc01012a4
[ 4.400171] [c3825b60] [c005b77c] 0xc005b77c
[ 4.404533] [c3825bb0] [c0055454] 0xc0055454
[ 4.408894] [c3825bf0] [c0066ac0] 0xc0066ac0
[ 4.413254] [c3825c40] [c00147e8] 0xc00147e8
[ 4.417616] [c3825cf0] [c0011dac] 0xc0011dac
[ 4.421977] --- Exception: 301 at 0xc0016300
[ 4.421991] LR =3D 0xc00b6f18
[ 4.429529] [c3825db0] [c396b9b4] 0xc396b9b4 (unreliable)
[ 4.435045] [c3825dd0] [c00b8454] 0xc00b8454
[ 4.439409] [c3825e60] [c00841b4] 0xc00841b4
[ 4.443770] [c3825e90] [c00851d4] 0xc00851d4
[ 4.448131] [c3825ed0] [c0008c28] 0xc0008c28
[ 4.452492] [c3825ef0] [c001197c] 0xc001197c
[ 4.456850] --- Exception: c01 at 0xc0010d54
[ 4.456865] LR =3D 0xc0003a18
[ 4.464401] [c3825fb0] [c008c634] 0xc008c634 (unreliable)
[ 4.469920] [c3825fc0] [c0003adc] 0xc0003adc
[ 4.474281] [c3825fd0] [c02b31f0] 0xc02b31f0
[ 4.478643] [c3825ff0] [c00117a0] 0xc00117a0
[ 4.483009] Rebooting in 1 seconds..
Anyone an idea, what I do wrong?
Best regards,
Thomas.
Dear "FIXED-TERM Seeh Thomas (BEG/EMS1)",
In message <6E9D235B18CE694399D781F05D9C42E79F0C2C12@SI-MBX11.de.bosch.com>=
you wrote:
>
> I'll try to run a 2.6.31-rc7 kernel on my Lite5200 board.
Is this really a Lite5200, or is it a Lite5200B?
Hint: if U-Boot prints something like "CPU: MPC5200B v2.2, Core v1.4"
then its a 5200B, and thus a Lite5200 board.
> For the device tree I use lite5200.dts and compiled it simply with
>
> make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- lite5200.dtb
For a Lite5200B you should use the lite5200b device tree.
> But I'm not sure what configuration for the kernel I should choose. There=
is no
> lite5200_defconfig only one for the lite5200b.
Rigth. Because there are virtually no lite5200 boards out there.
> I tried it with mpc5200_defconfig and lite5200b_defconfig, but I'm not su=
re which
> is the right way.
Both will work. On a Lite5200 board I would use lite5200b_defconfig,
though.
> For compiling the kernel I use:
>
> make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- "CONFIG_FILE"
That's:
make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- mrproper
make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- 52xx/lite5200b_defconf=
ig
> make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- uImage
> make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- modules
> make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- modules_install
> I use U-Boot 2009.06, with the following settings for bootup:
Looks as if you have a Rev. B CPU with the wrong device tree.
Unfortunaltey you omit the interesting part (i. e. the U-Boot boot
message) which would contain this important piece of information.
> --_000_6E9D235B18CE694399D781F05D9C42E79F0C2C12SIMBX11deboschc_
> Content-Type: text/html; charset"iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
And *please* do not post HTML to mailing lists. Never ever do that.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If I ever needed a brain transplant, I'd choose a teenager's because
I'd want a brain that had never been used.
^ permalink raw reply
* Re: Can't write value into memory ?(E500 V2)
From: wilbur.chan @ 2009-08-27 15:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20090826192030.GA17027@b07421-ec1.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]
2009/8/27 Scott Wood <scottwood@freescale.com>
>
> > //check if we successfully store value at 0x400,0000
> >
> > lis r22, 0x400
> > ori r22,r22,0x0
> > lwz r23,0(r22)
> > cmpw r23, 30
>
> The values should not be equal, since you wrote a byte and read back a
> word.
>
> Furthermore, you are storing the constant 30, but are comparing r23 with
> the register r30 (I never liked that aspect of ppc asm syntax -- too
> error prone). If you want to compare with the constant 30, use "cmpwi".
>
> > beq print_equal
> >
> > 1: b 1b
> >
> > print_equal:
> > ...
> > //code end
> >
> > I found that, print_equal was not called ,the whole code seemed to
> > enter an infinite loop.
>
> That's because you have an infinite loop in your code, right after "beq
> print_equal".
>
> -Scott
>
Thank you very much.
I am using a SMP E500 v2, and I want CPU0 to write some value to a physical
address, and
wait for CPU1 to read from it.
However, it seemed failed to communicate between CPUs by DRAM.. CPU1 can
not read
the correct value from the address where CPU1 wrote to.
BTW: the physical address is at 16M .
[-- Attachment #2: Type: text/html, Size: 1746 bytes --]
^ permalink raw reply
* Does kexec support SMP on powerpc? E500 V2
From: wilbur.chan @ 2009-08-27 15:56 UTC (permalink / raw)
To: linuxppc-dev
There was a patch of kexec on SMP mips 64 , and I attempt to implement
kexec on SMP powerpc .
I found that , it was a little different with mips when booting a
kernel. We know that, every CPU jumped directly into kernel on
mips, but on powerpc , E500 SMP, the 'master' CPU was in charge of
'slave' CPUs , so 'slave' CPU could do nothing
but to wait for 'master' to wake him up in Init function.
How to implement kexec on SMP powerpc?
Any suggestions would be appreciate
regards,
^ permalink raw reply
* Re: Can't write value into memory ?(E500 V2)
From: Scott Wood @ 2009-08-27 15:59 UTC (permalink / raw)
To: wilbur.chan; +Cc: linuxppc-dev
In-Reply-To: <e997b7420908270853i7d4058e1p8ddcfcf8df18486e@mail.gmail.com>
wilbur.chan wrote:
> I am using a SMP E500 v2, and I want CPU0 to write some value to a
> physical address, and wait for CPU1 to read from it.
Is this under Linux (it is a Linux mailing list...)? If so, there are
better ways of communicating that don't involve clobbering random memory
and overlapping userspace TLB mappings.
> However, it seemed failed to communicate between CPUs by DRAM.. CPU1
> can not read
>
> the correct value from the address where CPU1 wrote to.
Do both cores have a mapping with the M bit (memory coherence required) set?
-Scott
^ permalink raw reply
* Re: AW: LITE5200 configuration
From: Wolfgang Grandegger @ 2009-08-27 16:02 UTC (permalink / raw)
To: FIXED-TERM Seeh Thomas (BEG/EMS1)
Cc: linuxppc-dev@lists.ozlabs.org, Wolfgang Denk
In-Reply-To: <6E9D235B18CE694399D781F05D9C42E79F0C2F04@SI-MBX11.de.bosch.com>
FIXED-TERM Seeh Thomas (BEG/EMS1) wrote:
> Dear Mr Denk,
>
> thanks for your reply. I checked out kernel 2.6.30.3 stable for testing too.
> I mean it's really a Lite5200. That is the U-boot boot message:
Just to be sure. The old Lite5200 eval board has *one* PCI slot, while
the new Lite5200B has *two* slots. IIRC, there are also early Lite5200B
boards using MPC5200 v1.2 chips.
Wolfgang (Grandegger)
^ permalink raw reply
* Re: Can't write value into memory ?(E500 V2)
From: wilbur.chan @ 2009-08-27 16:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4A96AD4B.1010204@freescale.com>
2009/8/27 Scott Wood <scottwood@freescale.com>:
>
> Is this under Linux (it is a Linux mailing list...)? =A0If so, there are
> better ways of communicating that don't involve clobbering random memory =
and
> overlapping userspace TLB mappings.
Yes, I'm doing this under linux in kernel mode.
I've used interrupt between cores, to make:
1) cpu0 carrys some data to a place (As a matter of fact ,the 'data'
is a kernel, the 'place' is at 0, and I'm using kexec..)
2) cpu0 writes a 'flag' to a physical address(16M), to indicate that ,
it has finished the carrying in step 1. And jump to new kernel directly.
3) cpu1 enters the loop by IRQ , checking the 'flag' from time to
time. If the 'flag' is true, it
breaks the loop and jumps to the instruction in new kernel.
> Do both cores have a mapping with the M bit (memory coherence required) s=
et?
What do you mean by M bit set?
I setup a 1:1 mapping in both cpu0 and cpu1, and invalidate all the
other entries in TLB1 and
TLB0
^ permalink raw reply
* Re: Can't write value into memory ?(E500 V2)
From: Scott Wood @ 2009-08-27 16:34 UTC (permalink / raw)
To: wilbur.chan; +Cc: linuxppc-dev
In-Reply-To: <e997b7420908270927m1ec1dbcbq51781e3b1e4db061@mail.gmail.com>
wilbur.chan wrote:
> 2009/8/27 Scott Wood <scottwood@freescale.com>:
>> Is this under Linux (it is a Linux mailing list...)? If so, there are
>> better ways of communicating that don't involve clobbering random memory and
>> overlapping userspace TLB mappings.
>
> Yes, I'm doing this under linux in kernel mode.
>
> I've used interrupt between cores, to make:
>
> 1) cpu0 carrys some data to a place (As a matter of fact ,the 'data'
> is a kernel, the 'place' is at 0, and I'm using kexec..)
>
> 2) cpu0 writes a 'flag' to a physical address(16M), to indicate that ,
>
> it has finished the carrying in step 1. And jump to new kernel directly.
OK, so it's not really "under Linux" but "between Linuxes". :-)
Don't forget to clean the cache out on the destination core -- icache is
not coherent with dcache.
> 3) cpu1 enters the loop by IRQ , checking the 'flag' from time to
> time. If the 'flag' is true, it
>
> breaks the loop and jumps to the instruction in new kernel.
>
>
>> Do both cores have a mapping with the M bit (memory coherence required) set?
>
>
> What do you mean by M bit set?
There is a bit in MAS2, labelled "M", that you must set when writing the
TLB entry for the mapping to be coherent across cores.
-Scott
^ permalink raw reply
* SPI child devices reg property misused?
From: EXTERNAL Lange Matthias (AA-DGW/ENG1) @ 2009-08-27 16:53 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Hi,
I have a custom spi device connected to a Xilinx spi controller. To map the=
register space of the controller a reg property is defined in the device t=
ree. Because my custom device also has register space which I want to map i=
n my driver, I also defined a reg property. Because things weren't running =
smooth I started debugging and found in of_spi.c in the function
void of_register_spi_devices(struct spi_master *master, struct device_node =
*np)
the following piece of code (2.6.31)
...
/* Device address */
prop =3D of_get_property(nc, "reg", &len);
if (!prop || len < sizeof(*prop)) {
dev_err(&master->dev, "%s has no 'reg' property\n",
nc->full_name);
spi_dev_put(spi);
continue;
}
spi->chip_select =3D *prop;
Why does the reg property value of spi child devices is assigned to the chi=
p_select? Is there another way for spi devices to propagate their register =
space?
The related device tree snippet is as follows
xps-spi@83440000 {
compatible =3D "xlnx,xps-spi-2.00.b";
interrupt-parent =3D <&int_ctrl>;
interrupts =3D < 1 2 >;
reg =3D < 0x83440000 0x10000 >;
xlnx,family =3D "virtex4";
xlnx,fifo-exist =3D <0x0>;
xlnx,num-offchip-ss-bits =3D <0x0>;
xlnx,num-ss-bits =3D <0x1>;
xlnx,sck-ratio =3D <0x40>;
#address-cells =3D <1>;
#size-cells =3D <1>;
device@0,0 {
compatible =3D "beissbarth,orion_cam";
reg =3D <0x48 0x8>;
spi-max-frequency =3D <25000000>;
interrupt-parent =3D <&int_ctrl>;
interrupts =3D < 8 2 >;
};
};
Cheers,
Matthias.
^ permalink raw reply
* [PATCH 1/5] powerpc/qe: Increase MAX_QE_RISC to 4
From: Anton Vorontsov @ 2009-08-27 17:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
MPC8569 CPUs have four QE RISCs, so we need to increase MAX_QE_RISC
constant, otherwise qe_upload_firmware() fails at sanity checking.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/qe_lib/qe.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 237e365..b06564f 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -336,7 +336,7 @@ static int qe_sdma_init(void)
}
/* The maximum number of RISCs we support */
-#define MAX_QE_RISC 2
+#define MAX_QE_RISC 4
/* Firmware information stored here for qe_get_firmware_info() */
static struct qe_firmware_info qe_firmware_info;
--
1.6.3.3
^ permalink raw reply related
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