* Re: [PATCH dtc] Implement the -R option and add a -S option.
From: Jerry Van Baren @ 2007-04-14 16:43 UTC (permalink / raw)
To: Linuxppc-dev
In-Reply-To: <4620D009.1000800@gmail.com>
Jerry Van Baren wrote:
[snip]
> On an unrelated related note, I don't believe my -R additions are
> actually putting out additional reserve map slots (easiest to see using
> the asm format output). I'm still trying to understand why not, it
> seemed pretty straight-forward. When I implemented it, I was looking at
> hexdumps of the dtb binary format and looking at the header and thought
> I had it working... using it with my u-boot mods shows no extra reserved
> slots. I'm looking into where I went wrong.
OK, I didn't add a reserve additional slots output in the asm emission
code, so that was a pretty simple fix. I'll provide a patch after a bit
more testing.
gvb
^ permalink raw reply
* Re: [PATCH dtc] Implement the -R option and add a -S option.
From: Jerry Van Baren @ 2007-04-14 12:58 UTC (permalink / raw)
To: Linuxppc-dev
In-Reply-To: <20070412065152.GA26210@localhost.localdomain>
David Gibson wrote:
> On Thu, Apr 05, 2007 at 01:10:40PM -0400, Jerry Van Baren wrote:
>> Scott Wood wrote:
>>> On Wed, Apr 04, 2007 at 10:04:33PM -0400, Jerry Van Baren wrote:
>>>> Implement the -R <number> option to add memory reserve slots.
>>>> Add a -S <size> option makes the blob at least this number of bytes.
>>> Wouldn't it be better to just specify the amount of extra space, instead
>>> of the minimum total space? That way, you only need to know what you
>>> intend to add, not how much is already there.
>>>
>>> -Scott
>> I thought briefly about this, but decided to implement a fixed size so
>> that someone could allocate, say, 8K of memory in their memory map
>> (likely flash) and know their blob would fit.
>>
>> Maybe we need a little -s option to say "add -s bytes".
>
> I think having both options would be a good idea. It would also be
> nice to have options to do this from the dts file (something similar
> to /memreserve/).
>
>> Jon suggested a --stats option to print out the important statistics.
>> That would also be a good enhancement.
>
> Ok. How would you envisage this working?
>
> I've thought for some time that it would be a good idea to add an
> "info" output mode. In that mode instead of outputting a converted
> device tree, it would give various bits of info on the input tree.
> This would include things like the header field debugging information
> that's currently output as pseudo-error messages when using dtb input.
>
> I'm not sure to what extent your "--stats" idea would overlap with
> that.
Hi David,
Well, that was Jon's suggestion/idea so I have not thought about it
much. It would probably overlap 100% with your --info idea, with the
exception that Jon's suggestion would also put out the blob.
Since the dtc puts out the blob to sdtout, this actually is problematic.
I presume that is why you suggest inhibiting output. Using stderr
would sorta bypass that problem, but is not ideal (IMHO).
Is there any reason we don't have a -o option to direct the compiled
blob output to a file? Since the usual use is to write to a file, it
would free up stdout for (info/stats) outputs.
On an unrelated related note, I don't believe my -R additions are
actually putting out additional reserve map slots (easiest to see using
the asm format output). I'm still trying to understand why not, it
seemed pretty straight-forward. When I implemented it, I was looking at
hexdumps of the dtb binary format and looking at the header and thought
I had it working... using it with my u-boot mods shows no extra reserved
slots. I'm looking into where I went wrong.
Best regards,
gvb
^ permalink raw reply
* Re: Kernel Panic booting cdrom
From: Nathan Lynch @ 2007-04-14 4:45 UTC (permalink / raw)
To: David Huffman; +Cc: linuxppc-dev
In-Reply-To: <46202254.1090606@storix.com>
Hi David-
David Huffman wrote:
> I created a cdrom (using the same procedure that has been working for
> years), and received a kernel panic when booting a linux system on a
> System i p5 lpar. Here is a section of the boot messages, plus I added
> the output of .registers from OF. Anyone have an idea what could be the
> cause?
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=128 NUMA PSERIES LPAR
> NIP: C00000000012F210 XER: 0000000020000010 LR: C000000000476024
> REGS: c00000007ff5fab0 TRAP: 0380 Not tainted (2.6.5-7.244-pseries64
> SLES9_SP3_BRANCH-200512121832250000)
> MSR: 8000000000009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> DAR: 0000000000000010, DSISR: 0000000000200000
> TASK: c00000007ff5b440[1] 'swapper' THREAD: c00000007ff5c000 CPU: 0
> GPR00: C000000000476024 C00000007FF5FD30 C00000000071DCC8 C000000000723338
> GPR04: C0000000028CC080 C0000000028CC088 C000000000954C98 C000000002692888
> GPR08: 0000000000000002 0000000000000001 C000000000643160 0000000000000001
> GPR12: 0000000024000042 C000000000491000 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 0000000000000010 00000000001BB591 0000000001C00000
> GPR24: C000000000491000 C00000000071D008 C00000000048B5F0 C0000000028CC080
> GPR28: 0000000000000000 C000000000723338 C0000000006316D0 C0000000028CC088
> NIP [c00000000012f210] .sysfs_create_link+0x30/0x134
> LR [c000000000476024] .register_cpu+0xc8/0x104
> Call Trace:
> [c00000007ff5fd30] [c0000000002753cc] .sysdev_register+0x98/0x250
> (unreliable)
> [c00000007ff5fdd0] [c000000000476024] .register_cpu+0xc8/0x104
> [c00000007ff5fe70] [c0000000004621dc] .topology_init+0x1b4/0x290
> [c00000007ff5ff00] [c00000000000c654] .init+0x1a0/0x360
> [c00000007ff5ff90] [c000000000017d24] .kernel_thread+0x4c/0x68
> <0>Fatal exception: panic in 5 seconds
>From the full version at http://www.storix.com/p5panic.txt:
Linux version 2.6.5-7.244-pseries64 (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Mon Dec 12 18:32:25 UTC 2005
[boot]0012 Setup Arch
NUMA associativity depth for CPU/Memory: 3
cpu 0 maps to domain 5
cpu 1 maps to domain 5
memory region 0 to 8000000 maps to domain 5
memory region 8000000 to 9000000 maps to domain 5
memory region 9000000 to a000000 maps to domain 5
....
Could you see whether adding numa=off on the kernel command line
helps?
I think it's crashing because kernels this old assume that numa node
numbering as given by firmware begins with 0. This partition has a
single node numbered 5.
^ permalink raw reply
* Kernel Panic booting cdrom
From: David Huffman @ 2007-04-14 0:37 UTC (permalink / raw)
To: linuxppc-dev
I created a cdrom (using the same procedure that has been working for
years), and received a kernel panic when booting a linux system on a
System i p5 lpar. Here is a section of the boot messages, plus I added
the output of .registers from OF. Anyone have an idea what could be the
cause? This same CDROM works on a standalone System p 43p-170.
David Huffman
PPC Dev
Storix, Inc.
[boot]0015 Setup Done
Built 6 zonelists
Kernel command line: root=/dev/ram0 selinux=0 maxcpus=1 devfs=nomount
load_ramdisk=1 ramdisk_blocksize=1024 ramdisk_size=65536 rw
raid=noautodetect init=/linuxrc console=hvc0,9600
[boot]0020 XICS Init
xics: no ISA Interrupt Controller
[boot]0021 XICS Done
PID hash table entries: 16 (order 4: 256 bytes)
CKRM Initialization
...... Initializing ClassType<taskclass> ........
...... Initializing ClassType<socketclass> ........
CKRM Initialization done
time_init: decrementer frequency = 275.070000 MHz
time_init: processor frequency = 2197.800000 MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
freeing bootmem node 5
Memory: 2032640k available (0k kernel code, 0k data, 0k init)
[c000000000000000,c000000080000000]
kdb version 4.4 by Keith Owens, Scott Lurndal. Copyright SGI, All Rights
Reserved
kdb_cmd[0]: defcmd archkdb "" "First line arch debugging"
kdb_cmd[6]: defcmd archkdbcpu "" "archkdb with only tasks on cpus"
kdb_cmd[12]: defcmd archkdbshort "" "archkdb with less detailed backtrace"
Security Scaffold v1.0.0 initialized
SELinux: Disabled at boot.
Mount-cache hash table entries: 256 (order: 0, 4096 bytes)
Partition configured for 8 cpus.
Brought up 1 CPUs
checking if image is initramfs...it isn't (no cpio magic); looks like an
initrd
Freeing initrd memory: 1773k freed
khelper: max 64 concurrent processes
resid is -1 name is io <NULL>
CKRM .. create res clsobj for resouce <io>class <taskclass>
par=0000000000000000
NET: Registered protocol family 16
PCI: Probing PCI hardware
IOMMU table initialized, virtual merging disabled
PCI: Probing PCI hardware done
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA PSERIES LPAR
NIP: C00000000012F210 XER: 0000000020000010 LR: C000000000476024
REGS: c00000007ff5fab0 TRAP: 0380 Not tainted (2.6.5-7.244-pseries64
SLES9_SP3_BRANCH-200512121832250000)
MSR: 8000000000009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 0000000000000010, DSISR: 0000000000200000
TASK: c00000007ff5b440[1] 'swapper' THREAD: c00000007ff5c000 CPU: 0
GPR00: C000000000476024 C00000007FF5FD30 C00000000071DCC8 C000000000723338
GPR04: C0000000028CC080 C0000000028CC088 C000000000954C98 C000000002692888
GPR08: 0000000000000002 0000000000000001 C000000000643160 0000000000000001
GPR12: 0000000024000042 C000000000491000 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000010 00000000001BB591 0000000001C00000
GPR24: C000000000491000 C00000000071D008 C00000000048B5F0 C0000000028CC080
GPR28: 0000000000000000 C000000000723338 C0000000006316D0 C0000000028CC088
NIP [c00000000012f210] .sysfs_create_link+0x30/0x134
LR [c000000000476024] .register_cpu+0xc8/0x104
Call Trace:
[c00000007ff5fd30] [c0000000002753cc] .sysdev_register+0x98/0x250
(unreliable)
[c00000007ff5fdd0] [c000000000476024] .register_cpu+0xc8/0x104
[c00000007ff5fe70] [c0000000004621dc] .topology_init+0x1b4/0x290
[c00000007ff5ff00] [c00000000000c654] .init+0x1a0/0x360
[c00000007ff5ff90] [c000000000017d24] .kernel_thread+0x4c/0x68
<0>Fatal exception: panic in 5 seconds
Kernel panic: Fatal exception
###############################################################
Registers
###############################################################
0 > .registers
My Fix Pt Regs:
00 800000000000b002 0000000000000000 00000000deadbeef 0000000000000001
04 00000000ea28ef60 0000000000c4f0d8 0000000000000000 0000000000c03010
08 0000000008000000 80000000001f9ca0 80000000001f9ca0 80000000001af548
0c 0000000000004000 0000000000c17100 0000000000c18000 00000000000e86b0
10 0000000000e262e5 0000000000e262e5 0000000000c457c0 0000000000c45848
14 0000000000144078 0001f89aea28ef60 0000000000000000 0000000000000000
18 0000000000c13000 0000000000c38000 0000000000c14f80 0000000000c16fc0
1c 0000000000c20000 0000000000c3fdd0 0000000000c11fb0 0000000000c11000
Special Regs:
%IV: 00000900 %CR: 22808000 %XER: 20000001 %DSISR: 00000000
%SRR0: 0000000000c4580c %SRR1: 800000000000b002
%LR: 0000000000c46974 %CTR: 0000000000000004
%DAR: 0000000000000000
Virtual PID = 0
I posted the entire boot message output at:
http://www.storix.com/p5panic.txt
^ permalink raw reply
* Re: RFC: MPC52xx serial port configuration from DT blob
From: Dale Farnsworth @ 2007-04-13 23:24 UTC (permalink / raw)
To: tur, linuxppc-embedded
In-Reply-To: <461FF442.8090807@semihalf.com>
Bartlomiej wrote:
> We have a MPC5200B-based board running an arch/powerpc kernel and we
> need the ability to configure a non-console serial port for a particular
> baud rate during system start-up. It seems that the UART driver in
> drivers/serial/mpc52xx_uart.c does not support this. It only allows to
> set parameters for a port that is used as a console, and for which those
> parameters are passed in the kernel command line. We would like to
> extend the mpc52xx_uart.c driver to be able to retrieve port options
> from the DT blob and configure a given port accordingly. A new
> port-specific property called "options" would be used for this. It would
> have syntax following its namesake in "console" kernel parameter, as
> described in Documentation/kernel-parameters.txt.
>
> For example, the following settings in the .dts file would make UART5 to
> be configured at 115200 baud, no parity, 8 bits.
>
> serial@2800 { // PSC5
> device_type = "serial";
> compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
> port-number = <4>; // Logical port assignment
> options = "115200n8"
> cell-index = <4>;
> reg = <2800 100>;
> interrupts = <2 c 0>;
> interrupt-parent = <500>;
> };
>
>
> In case a console port has conflicting options given in the kernel
> command line and in the DT blob, the command line values would be used.
>
> Any comments on the above will be appreciated.
The device tree is intended to be an OS-independent description of the
state of the platform hardware as left by firmware (or bootwrapper).
It is not intended to contain kernel configuration parameters or options,
though there are a few exceptions.
So, this kind of change is unlikely to be accepted.
-Dale
^ permalink raw reply
* Re: [PATCH] powerpc: Add dt_xlate_addr() to bootwrapper
From: Mark A. Greer @ 2007-04-13 22:36 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070413222551.GA8258@ld0162-tx32.am.freescale.net>
On Fri, Apr 13, 2007 at 05:25:51PM -0500, Scott Wood wrote:
> On Fri, Apr 13, 2007 at 01:23:43PM -0700, Mark A. Greer wrote:
> > +int dt_xlate(void *node, u32 *buf, int buflen, int res, unsigned long *addr,
> > + unsigned long *size)
> > {
> > - u32 last_addr[MAX_ADDR_CELLS];
> > - u32 this_addr[MAX_ADDR_CELLS];
> > - u32 buf[MAX_ADDR_CELLS * MAX_RANGES * 3];
> > + u32 last_addr[DT_MAX_ADDR_CELLS];
> > + u32 this_addr[DT_MAX_ADDR_CELLS];
> > void *parent;
>
> This causes it to use the caller-provided buffer to read the ranges
> property, which may not be large enough in the case of dt_xlate_addr().
> Plus, buf being a pointer rather than an array will cause the sizeof(buf)
> that gets passed to getprop() to be only sizeof(u32 *).
>
> Instead, I'd declare "rangebuf" as a static array, and accept "regbuf" as
> a parameter (with a comment that regbuf can alias rangebuf). Then,
> dt_xlate_reg() can use rangebuf as regbuf, dt_xlate_addr()'s caller
> doesn't have to worry about its buffer being big enough to hold ranges,
> and we don't have to allocate two 384-byte buffers on the stack.
Okay, I'll look closer this time. Thanks for checking.
Mark
^ permalink raw reply
* Re: [PATCH] powerpc: Add dt_xlate_addr() to bootwrapper
From: Scott Wood @ 2007-04-13 22:25 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20070413202343.GA552@mag.az.mvista.com>
On Fri, Apr 13, 2007 at 01:23:43PM -0700, Mark A. Greer wrote:
> +int dt_xlate(void *node, u32 *buf, int buflen, int res, unsigned long *addr,
> + unsigned long *size)
> {
> - u32 last_addr[MAX_ADDR_CELLS];
> - u32 this_addr[MAX_ADDR_CELLS];
> - u32 buf[MAX_ADDR_CELLS * MAX_RANGES * 3];
> + u32 last_addr[DT_MAX_ADDR_CELLS];
> + u32 this_addr[DT_MAX_ADDR_CELLS];
> void *parent;
This causes it to use the caller-provided buffer to read the ranges
property, which may not be large enough in the case of dt_xlate_addr().
Plus, buf being a pointer rather than an array will cause the sizeof(buf)
that gets passed to getprop() to be only sizeof(u32 *).
Instead, I'd declare "rangebuf" as a static array, and accept "regbuf" as
a parameter (with a comment that regbuf can alias rangebuf). Then,
dt_xlate_reg() can use rangebuf as regbuf, dt_xlate_addr()'s caller
doesn't have to worry about its buffer being big enough to hold ranges,
and we don't have to allocate two 384-byte buffers on the stack.
-Scott
^ permalink raw reply
* [PATCH] remove kernel module option for booke wdt
From: Dave Jiang @ 2007-04-13 22:25 UTC (permalink / raw)
To: linuxppc-dev, paulus, galak
Remove option of making booke_wdt into a kernel module. This watchdog
cannot be disabled. No point being a kernel module.
Signed-off-by: Dave Jiang <djiang@mvista.com>
---
drivers/char/watchdog/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/watchdog/Kconfig b/drivers/char/watchdog/Kconfig
index e812aa1..60198a7 100644
--- a/drivers/char/watchdog/Kconfig
+++ b/drivers/char/watchdog/Kconfig
@@ -548,7 +548,7 @@ config MV64X60_WDT
depends on WATCHDOG && MV64X60
config BOOKE_WDT
- tristate "PowerPC Book-E Watchdog Timer"
+ bool "PowerPC Book-E Watchdog Timer"
depends on WATCHDOG && (BOOKE || 4xx)
---help---
Please see Documentation/watchdog/watchdog-api.txt for
^ permalink raw reply related
* Re: [PATCH] add reg and stack dump to booke WD handler
From: Dave Jiang @ 2007-04-13 22:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <B8CF9F53-9F51-4DD5-9CB6-16C69502A1CA@kernel.crashing.org>
Have the booke watchdog dump some useful information when triggered.
Hopefully that'll give the user some hint of what happened rather than just a
mysterious reboot.
Signed-off-by: Dave Jiang <djiang@mvista.com>
---
arch/powerpc/kernel/traps.c | 32 +++++++++++++++++++++++++++++++-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index f786222..e4d6186 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1108,9 +1108,39 @@ void unrecoverable_exception(struct pt_regs *regs)
*/
void __attribute__ ((weak)) WatchdogHandler(struct pt_regs *regs)
{
+ unsigned long flags;
+
/* Generic WatchdogHandler, implement your own */
mtspr(SPRN_TCR, mfspr(SPRN_TCR)&(~TCR_WIE));
- return;
+ oops_enter();
+
+ console_verbose();
+ bust_spinlocks(1);
+ local_save_flags(flags);
+
+#ifdef CONFIG_PREEMPT
+ printk("PREEMPT ");
+#endif
+#ifdef CONFIG_SMP
+ printk("SMP NR_CPUS=%d ", NR_CPUS);
+#endif
+#ifdef CONFIG_DEBUG_PAGEALLOC
+ printk("DEBUG_PAGEALLOC ");
+#endif
+#ifdef CONFIG_NUMA
+ printk("NUMA ");
+#endif
+ printk("%s\n", ppc_md.name ? ppc_md.name : "");
+
+ print_modules();
+ show_regs(regs);
+
+ bust_spinlocks(0);
+
+ printk(KERN_EMERG "Waiting for hardware watchdog reset...\n");
+ /* spin until hardware reset */
+ while(1)
+ cpu_relax();
}
void WatchdogException(struct pt_regs *regs)
^ permalink raw reply related
* RFC: MPC52xx serial port configuration from DT blob
From: Bartlomiej Sieka @ 2007-04-13 21:21 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
We have a MPC5200B-based board running an arch/powerpc kernel and we
need the ability to configure a non-console serial port for a particular
baud rate during system start-up. It seems that the UART driver in
drivers/serial/mpc52xx_uart.c does not support this. It only allows to
set parameters for a port that is used as a console, and for which those
parameters are passed in the kernel command line. We would like to
extend the mpc52xx_uart.c driver to be able to retrieve port options
from the DT blob and configure a given port accordingly. A new
port-specific property called "options" would be used for this. It would
have syntax following its namesake in "console" kernel parameter, as
described in Documentation/kernel-parameters.txt.
For example, the following settings in the .dts file would make UART5 to
be configured at 115200 baud, no parity, 8 bits.
serial@2800 { // PSC5
device_type = "serial";
compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
port-number = <4>; // Logical port assignment
options = "115200n8"
cell-index = <4>;
reg = <2800 100>;
interrupts = <2 c 0>;
interrupt-parent = <500>;
};
In case a console port has conflicting options given in the kernel
command line and in the DT blob, the command line values would be used.
Any comments on the above will be appreciated.
Thanks in advance,
Bartlomiej
^ permalink raw reply
* Re: [PATCH] add reg and stack dump to booke WD handler
From: Sergei Shtylyov @ 2007-04-13 20:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <B8CF9F53-9F51-4DD5-9CB6-16C69502A1CA@kernel.crashing.org>
Hello.
Kumar Gala wrote:
>> Have the booke watchdog dump some useful information when triggered.
>> Hopefully
>> that'll give the user some hint of what happened rather than just a
>> mysterious
>> reboot.
>> Ok here's try 2. Modified the watchdog driver instead per Sergei's
>> suggestion.
> I'm against having a WatchdogHandler in booke_wdt.c. The idea behind
> the weak symbol in traps.c is to allow platform code to override the
> behavior.
Hmm, to do what?
> I'm ok if we put the spew in the generic case.
Well, I was mostly against putting there while(1) cpu_relax();
> Also, how are you testing this?
By enabling the watchdog and not then pinging it, I guess...
>> drivers/char/watchdog/booke_wdt.c | 37 ++++++++++++++++++++++++++
>> +++++++++++
>> 1 files changed, 37 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/char/watchdog/booke_wdt.c b/drivers/char/
>> watchdog/booke_wdt.c
>> index 0e23f29..90e5301 100644
>> --- a/drivers/char/watchdog/booke_wdt.c
>> +++ b/drivers/char/watchdog/booke_wdt.c
>> @@ -23,6 +23,7 @@
>> #include <asm/reg_booke.h>
>> #include <asm/uaccess.h>
>> #include <asm/system.h>
>> +#include <asm/machdep.h>
>>
>> /* If the kernel parameter wdt_enable=1, the watchdog will be
>> enabled at boot.
>> * Also, the wdt_period sets the watchdog timer period timeout.
>> @@ -47,6 +48,42 @@ u32 booke_wdt_period = WDT_PERIOD_DEFAULT;
>> #define WDTP(x) (TCR_WP(x))
>> #endif
>>
>> +void WatchdogHandler(struct pt_regs *regs)
>> +{
>> + unsigned long flags;
>> +
>> + mtspr(SPRN_TCR, mfspr(SPRN_TCR) & ~TCR_WIE);
>> + oops_enter();
>> +
>> + console_verbose();
>> + bust_spinlocks(1);
>> + local_save_flags(flags);
>> +
>> +#ifdef CONFIG_PREEMPT
>> + printk("PREEMPT ");
>> +#endif
>> +#ifdef CONFIG_SMP
>> + printk("SMP NR_CPUS=%d ", NR_CPUS);
>> +#endif
>> +#ifdef CONFIG_DEBUG_PAGEALLOC
>> + printk("DEBUG_PAGEALLOC ");
>> +#endif
>> +#ifdef CONFIG_NUMA
>> + printk("NUMA ");
>> +#endif
>> + printk("%s\n", ppc_md.name ? ppc_md.name : "");
>> +
>> + print_modules();
>> + show_regs(regs);
>> +
>> + bust_spinlocks(0);
>> +
>> + printk(KERN_EMERG "Waiting for hardware watchdog reset...\n");
>> + /* spin until hardware reset */
>> + while(1)
>> + cpu_relax();
>> +}
>> +
>> /*
>> * booke_wdt_ping:
>> */
WBR, Sergei
^ permalink raw reply
* Re: booke_wdt being a kernel module
From: Dave Jiang @ 2007-04-13 20:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1A484369-13F5-49A0-8BFF-3DC290316BEF@kernel.crashing.org>
Kumar Gala wrote:
> On Apr 12, 2007, at 2:54 PM, Dave wrote:
>
>
>> Does it make sense for the booke_wdt driver to be a kernel module?
>> Since the watchdog cannot be stopped, unloading the module after the
>> watchdog has started basically garantees a reboot.... Should
>> CONFIG_BOOKE_WDT be changed to a bool from tristate?
>>
>
> I don't see any value in making the booke_wdt driver a module.
>
> - k
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
Ok, I will make a patch to change it to bool then.
^ permalink raw reply
* Re: [PATCH] add reg and stack dump to booke WD handler
From: Dave Jiang @ 2007-04-13 20:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <B8CF9F53-9F51-4DD5-9CB6-16C69502A1CA@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 13, 2007, at 3:06 PM, Dave Jiang wrote:
>
>> Have the booke watchdog dump some useful information when triggered.
>> Hopefully
>> that'll give the user some hint of what happened rather than just a
>> mysterious
>> reboot.
>
> Forgot the signed-off-by again (git-commit -s)
>
I need to stop doing that! Grrrrr....
>> --
>>
>> Ok here's try 2. Modified the watchdog driver instead per Sergei's
>> suggestion.
>
> I'm against having a WatchdogHandler in booke_wdt.c. The idea behind
> the weak symbol in traps.c is to allow platform code to override the
> behavior. I'm ok if we put the spew in the generic case.
>
Ok, I will put it back in the generic handler.
> Also, how are you testing this?
I just stop the userland watchdog daemon and the watchdog timeout kicks
in. Of course I could also write a kernel module that takes a spinlock
and spin.... I tested on the MPC8548 and seems to work as expected.
^ permalink raw reply
* RE: Linux 2.6 and uboot
From: Gary Kenaley @ 2007-04-13 20:25 UTC (permalink / raw)
To: Kumar Gala, Clint Thomas; +Cc: linuxppc-embedded
In-Reply-To: <56EADD43-F9B3-427E-9322-AAC708EF2CCC@kernel.crashing.org>
I found that when trying to build kernel 2.6.19.2 with the ELDK 4.1, and
run it on an MPC8349EMDS with u-boot 1.1.3, I had to use ARCH=3Dppc.
ARCH=3Dpowerpc would immediately hang. The different architectures use
different default kernel configuration files for the same board.
But now I am unable to get USB and MTD to work on the board, and am
wondering if ARC=3Dppc is still a viable choice on kernels newer than
about 2.6.15, or whether it lacks the best driver support. Could someone
please offer a recommendation on this issue?
> -----Original Message-----
> From: linuxppc-embedded-bounces+gkenaley=3Dechelon.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+gkenaley=3Dechelon.com@ozlabs.org] =
On
> Behalf Of Kumar Gala
> Sent: Friday, April 13, 2007 1:18 PM
> To: Clint Thomas
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux 2.6 and uboot
>=20
>=20
> On Apr 13, 2007, at 2:55 PM, Clint Thomas wrote:
>=20
> > Is there any correlation between the version of U-boot to use on a
> > board
> > and the version of the Linux kernel you plan to use? Current I'm
> > running
> > U-boot 1.1.2 with kernel 2.4.26 on my MPC85xx board, but i'm trying
to
> > migrate to the latest 2.6 kernel. I am getting a kernel hang at boot
> > when it registers socket family 17, so I was wondering if it might
> > have
> > to do with u-boot before exploring the debug route.
>=20
> That's an odd place to hang. Which 2.6 kernel are you using? Also
> are you using arch/ppc or arch/powerpc?
>=20
> - k
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: Linux 2.6 and uboot
From: Clint Thomas @ 2007-04-13 20:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <56EADD43-F9B3-427E-9322-AAC708EF2CCC@kernel.crashing.org>
Sorry, not quite the latest kernel. 2.6.19 as distributed in ELDK 4.1,
built for the MPC8555CDS, although the actual board is slightly
different.
Here is the boot time output. U-boot succesfully enables the ethernet to
get its kernel image from the TFTP server.
## Booting image at 01000000 ...
Image Name: Linux-2.6.19.2
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1475429 Bytes =3D 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory CAM mapping: CAM0=3D256Mb, CAM1=3D0Mb, CAM2=3D0Mb residual: 0Mb
Linux version 2.6.19.2 (cthomas@devbox) (gcc version 4.0.0 (DENX ELDK
4.1 4.0.0)) #3 Mon Apr
13:44:24 EDT 2007
mpc85xx_cds_setup_arch
CDS Version =3D 80 in PCI slot 1
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
early_node_map[1] active PFN ranges
0: 0 -> 65536
Built 1 zonelists. Total pages: 65024
Kernel command line: root=3D/dev/nfs
nfsaddrs=3D204.215.226.247:204.215.226.49:204.215.226.50:255.255.2
5.0 rw nfsroot=3D/opt/RFS_CAT console=3DttyS0,9600 doPci=3D1
OpenPIC Version 1.2 (1 CPUs and 60 IRQ sources) at fcf78000
PID hash table entries: 1024 (order: 10, 4096 bytes)
Warning: real time clock seems stuck!
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256640k available (2276k kernel code, 704k data, 136k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing
disabled
serial8250.0: ttyS0 at MMIO 0xfdf04500 (irq =3D 106) is a 16550A
serial8250.0: ttyS1 at MMIO 0xfdf04600 (irq =3D 106) is a 16550A
RAMDISK driver initialized: 8 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
nbd: registered device at major 43
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.2, 00:01:af:07:9b:8b
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.2, df:f7:bf:7d:72:6f
eth1: Running with NAPI enabled
eth1: 256/256 RX/TX BD ring size
Marvell 88E1101: Registered new driver
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=3Dxx
st: Version 20050830, fixed bufsize 32768, s/g segs 256
ehci_hcd 0000:01:06.2: EHCI Host Controller
ehci_hcd 0000:01:06.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:01:06.2: irq 130, io mem 0x9efbdf00
ehci_hcd 0000:01:06.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
ohci_hcd 0000:01:06.0: OHCI Host Controller
ohci_hcd 0000:01:06.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:01:06.0: irq 130, io mem 0x9efbf000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ohci_hcd 0000:01:06.1: OHCI Host Controller
ohci_hcd 0000:01:06.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:01:06.1: irq 130, io mem 0x9efbe000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
This is the point where it stops booting.
Clint Thomas
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Friday, April 13, 2007 4:18 PM
To: Clint Thomas
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Linux 2.6 and uboot
On Apr 13, 2007, at 2:55 PM, Clint Thomas wrote:
> Is there any correlation between the version of U-boot to use on a=20
> board and the version of the Linux kernel you plan to use? Current I'm
> running U-boot 1.1.2 with kernel 2.4.26 on my MPC85xx board, but i'm=20
> trying to migrate to the latest 2.6 kernel. I am getting a kernel hang
> at boot when it registers socket family 17, so I was wondering if it=20
> might have to do with u-boot before exploring the debug route.
That's an odd place to hang. Which 2.6 kernel are you using? Also are
you using arch/ppc or arch/powerpc?
- k
^ permalink raw reply
* [PATCH] powerpc: Add dt_xlate_addr() to bootwrapper
From: Mark A. Greer @ 2007-04-13 20:23 UTC (permalink / raw)
To: linuxppc-dev
dt_xlate_reg() looks up the 'reg' property in the specified node
to get the address and size to translate. Add dt_xlate_addr()
which is passed in the address and size to translate.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
Scott, would you please 'Acked-by:' or NACK this? Thanks.
devtree.c | 31 +++++++++++++------------------
ops.h | 23 +++++++++++++++++++++--
2 files changed, 34 insertions(+), 20 deletions(-)
---
diff --git a/arch/powerpc/boot/devtree.c b/arch/powerpc/boot/devtree.c
index 23492d7..11b542d 100644
--- a/arch/powerpc/boot/devtree.c
+++ b/arch/powerpc/boot/devtree.c
@@ -110,9 +110,6 @@ void __dt_fixup_mac_addresses(u32 startindex, ...)
va_end(ap);
}
-#define MAX_ADDR_CELLS 4
-#define MAX_RANGES 8
-
static void get_reg_format(void *node, u32 *naddr, u32 *nsize)
{
if (getprop(node, "#address-cells", naddr, 4) != 4)
@@ -123,7 +120,7 @@ static void get_reg_format(void *node, u32 *naddr, u32 *nsize)
static void copy_val(u32 *dest, u32 *src, int naddr)
{
- memset(dest, 0, (MAX_ADDR_CELLS - naddr) * 4);
+ memset(dest, 0, (DT_MAX_ADDR_CELLS - naddr) * 4);
memcpy(dest, src, naddr * 4);
}
@@ -131,7 +128,7 @@ static int sub_reg(u32 *reg, u32 *sub)
{
int i, borrow = 0;
- for (i = 0; i < MAX_ADDR_CELLS; i++) {
+ for (i = 0; i < DT_MAX_ADDR_CELLS; i++) {
int prev_borrow = borrow;
borrow = reg[i] < sub[i] + prev_borrow;
reg[i] -= sub[i] + prev_borrow;
@@ -144,7 +141,7 @@ static int add_reg(u32 *reg, u32 *add)
{
int i, carry = 0;
- for (i = 0; i < MAX_ADDR_CELLS; i++) {
+ for (i = 0; i < DT_MAX_ADDR_CELLS; i++) {
u64 tmp = (u64)reg[i] + add[i] + carry;
carry = tmp >> 32;
reg[i] = (u32)tmp;
@@ -161,14 +158,14 @@ static int compare_reg(u32 *reg, u32 *range, u32 *rangesize)
int i;
u32 end;
- for (i = 0; i < MAX_ADDR_CELLS; i++) {
+ for (i = 0; i < DT_MAX_ADDR_CELLS; i++) {
if (reg[i] < range[i])
return 0;
if (reg[i] > range[i])
break;
}
- for (i = 0; i < MAX_ADDR_CELLS; i++) {
+ for (i = 0; i < DT_MAX_ADDR_CELLS; i++) {
end = range[i] + rangesize[i];
if (reg[i] < end)
@@ -180,7 +177,7 @@ static int compare_reg(u32 *reg, u32 *range, u32 *rangesize)
return reg[i] != end;
}
-/* reg must be MAX_ADDR_CELLS */
+/* reg must be DT_MAX_ADDR_CELLS */
static int find_range(u32 *reg, u32 *ranges, int nregaddr,
int naddr, int nsize, int buflen)
{
@@ -188,8 +185,8 @@ static int find_range(u32 *reg, u32 *ranges, int nregaddr,
int i;
for (i = 0; i + nrange <= buflen; i += nrange) {
- u32 range_addr[MAX_ADDR_CELLS];
- u32 range_size[MAX_ADDR_CELLS];
+ u32 range_addr[DT_MAX_ADDR_CELLS];
+ u32 range_size[DT_MAX_ADDR_CELLS];
copy_val(range_addr, ranges + i, naddr);
copy_val(range_size, ranges + i + nregaddr + naddr, nsize);
@@ -205,16 +202,15 @@ static int find_range(u32 *reg, u32 *ranges, int nregaddr,
* In particular, PCI is not supported. Also, only the beginning of the
* reg block is tracked; size is ignored except in ranges.
*/
-int dt_xlate_reg(void *node, int res, unsigned long *addr,
- unsigned long *size)
+int dt_xlate(void *node, u32 *buf, int buflen, int res, unsigned long *addr,
+ unsigned long *size)
{
- u32 last_addr[MAX_ADDR_CELLS];
- u32 this_addr[MAX_ADDR_CELLS];
- u32 buf[MAX_ADDR_CELLS * MAX_RANGES * 3];
+ u32 last_addr[DT_MAX_ADDR_CELLS];
+ u32 this_addr[DT_MAX_ADDR_CELLS];
void *parent;
u64 ret_addr, ret_size;
u32 naddr, nsize, prev_naddr;
- int buflen, offset;
+ int offset;
parent = get_parent(node);
if (!parent)
@@ -225,7 +221,6 @@ int dt_xlate_reg(void *node, int res, unsigned long *addr,
if (nsize > 2)
return 0;
- buflen = getprop(node, "reg", buf, sizeof(buf)) / 4;
offset = (naddr + nsize) * res;
if (buflen < offset + naddr + nsize)
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index ee0f9c2..c499ee7 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -82,8 +82,8 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp);
void *simple_alloc_init(char *base, u32 heap_size, u32 granularity,
u32 max_allocs);
extern void flush_cache(void *, unsigned long);
-int dt_xlate_reg(void *node, int res, unsigned long *addr,
- unsigned long *size);
+int dt_xlate(void *node, u32 *buf, int buflen, int res, unsigned long *addr,
+ unsigned long *size);
static inline void *finddevice(const char *name)
{
@@ -183,6 +183,25 @@ static inline void exit(void)
}
#define fatal(args...) { printf(args); exit(); }
+#define DT_MAX_ADDR_CELLS 4
+#define DT_MAX_RANGES 8
+
+static inline int dt_xlate_reg(void *node, int res, unsigned long *addr,
+ unsigned long *size)
+{
+ u32 buf[DT_MAX_ADDR_CELLS * DT_MAX_RANGES * 3];
+ int buflen;
+
+ buflen = getprop(node, "reg", buf, sizeof(buf)) / 4;
+ return dt_xlate(node, buf, buflen, res, addr, size);
+}
+
+static inline int dt_xlate_addr(void *node, u32 *buf, int buflen,
+ unsigned long *xlated_addr)
+{
+ return dt_xlate(node, buf, buflen, 0, xlated_addr, NULL);
+}
+
#define BSS_STACK(size) \
static char _bss_stack[size]; \
^ permalink raw reply related
* Re: Linux 2.6 and uboot
From: Kumar Gala @ 2007-04-13 20:17 UTC (permalink / raw)
To: Clint Thomas; +Cc: linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA24095293284D7@bluefin.Soneticom.local>
On Apr 13, 2007, at 2:55 PM, Clint Thomas wrote:
> Is there any correlation between the version of U-boot to use on a
> board
> and the version of the Linux kernel you plan to use? Current I'm
> running
> U-boot 1.1.2 with kernel 2.4.26 on my MPC85xx board, but i'm trying to
> migrate to the latest 2.6 kernel. I am getting a kernel hang at boot
> when it registers socket family 17, so I was wondering if it might
> have
> to do with u-boot before exploring the debug route.
That's an odd place to hang. Which 2.6 kernel are you using? Also
are you using arch/ppc or arch/powerpc?
- k
^ permalink raw reply
* Re: booke_wdt being a kernel module
From: Kumar Gala @ 2007-04-13 20:12 UTC (permalink / raw)
To: Dave; +Cc: linuxppc-dev
In-Reply-To: <8746466a0704121254h205a8247u39587560991f07a4@mail.gmail.com>
On Apr 12, 2007, at 2:54 PM, Dave wrote:
> Does it make sense for the booke_wdt driver to be a kernel module?
> Since the watchdog cannot be stopped, unloading the module after the
> watchdog has started basically garantees a reboot.... Should
> CONFIG_BOOKE_WDT be changed to a bool from tristate?
I don't see any value in making the booke_wdt driver a module.
- k
^ permalink raw reply
* Re: [PATCH] add reg and stack dump to booke WD handler
From: Kumar Gala @ 2007-04-13 20:11 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070413200659.GA21588@blade.az.mvista.com>
On Apr 13, 2007, at 3:06 PM, Dave Jiang wrote:
> Have the booke watchdog dump some useful information when
> triggered. Hopefully
> that'll give the user some hint of what happened rather than just a
> mysterious
> reboot.
Forgot the signed-off-by again (git-commit -s)
> --
>
> Ok here's try 2. Modified the watchdog driver instead per Sergei's
> suggestion.
I'm against having a WatchdogHandler in booke_wdt.c. The idea behind
the weak symbol in traps.c is to allow platform code to override the
behavior. I'm ok if we put the spew in the generic case.
Also, how are you testing this?
- k
>
> drivers/char/watchdog/booke_wdt.c | 37 ++++++++++++++++++++++++++
> +++++++++++
> 1 files changed, 37 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/char/watchdog/booke_wdt.c b/drivers/char/
> watchdog/booke_wdt.c
> index 0e23f29..90e5301 100644
> --- a/drivers/char/watchdog/booke_wdt.c
> +++ b/drivers/char/watchdog/booke_wdt.c
> @@ -23,6 +23,7 @@
> #include <asm/reg_booke.h>
> #include <asm/uaccess.h>
> #include <asm/system.h>
> +#include <asm/machdep.h>
>
> /* If the kernel parameter wdt_enable=1, the watchdog will be
> enabled at boot.
> * Also, the wdt_period sets the watchdog timer period timeout.
> @@ -47,6 +48,42 @@ u32 booke_wdt_period = WDT_PERIOD_DEFAULT;
> #define WDTP(x) (TCR_WP(x))
> #endif
>
> +void WatchdogHandler(struct pt_regs *regs)
> +{
> + unsigned long flags;
> +
> + mtspr(SPRN_TCR, mfspr(SPRN_TCR) & ~TCR_WIE);
> + oops_enter();
> +
> + console_verbose();
> + bust_spinlocks(1);
> + local_save_flags(flags);
> +
> +#ifdef CONFIG_PREEMPT
> + printk("PREEMPT ");
> +#endif
> +#ifdef CONFIG_SMP
> + printk("SMP NR_CPUS=%d ", NR_CPUS);
> +#endif
> +#ifdef CONFIG_DEBUG_PAGEALLOC
> + printk("DEBUG_PAGEALLOC ");
> +#endif
> +#ifdef CONFIG_NUMA
> + printk("NUMA ");
> +#endif
> + printk("%s\n", ppc_md.name ? ppc_md.name : "");
> +
> + print_modules();
> + show_regs(regs);
> +
> + bust_spinlocks(0);
> +
> + printk(KERN_EMERG "Waiting for hardware watchdog reset...\n");
> + /* spin until hardware reset */
> + while(1)
> + cpu_relax();
> +}
> +
> /*
> * booke_wdt_ping:
> */
^ permalink raw reply
* Re: [PATCH] add reg and stack dump to booke WD handler
From: Dave Jiang @ 2007-04-13 20:06 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, paulus
In-Reply-To: <461FCB6F.7010504@ru.mvista.com>
Have the booke watchdog dump some useful information when triggered. Hopefully
that'll give the user some hint of what happened rather than just a mysterious
reboot.
--
Ok here's try 2. Modified the watchdog driver instead per Sergei's suggestion.
drivers/char/watchdog/booke_wdt.c | 37 +++++++++++++++++++++++++++++++++++++
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/drivers/char/watchdog/booke_wdt.c b/drivers/char/watchdog/booke_wdt.c
index 0e23f29..90e5301 100644
--- a/drivers/char/watchdog/booke_wdt.c
+++ b/drivers/char/watchdog/booke_wdt.c
@@ -23,6 +23,7 @@
#include <asm/reg_booke.h>
#include <asm/uaccess.h>
#include <asm/system.h>
+#include <asm/machdep.h>
/* If the kernel parameter wdt_enable=1, the watchdog will be enabled at boot.
* Also, the wdt_period sets the watchdog timer period timeout.
@@ -47,6 +48,42 @@ u32 booke_wdt_period = WDT_PERIOD_DEFAULT;
#define WDTP(x) (TCR_WP(x))
#endif
+void WatchdogHandler(struct pt_regs *regs)
+{
+ unsigned long flags;
+
+ mtspr(SPRN_TCR, mfspr(SPRN_TCR) & ~TCR_WIE);
+ oops_enter();
+
+ console_verbose();
+ bust_spinlocks(1);
+ local_save_flags(flags);
+
+#ifdef CONFIG_PREEMPT
+ printk("PREEMPT ");
+#endif
+#ifdef CONFIG_SMP
+ printk("SMP NR_CPUS=%d ", NR_CPUS);
+#endif
+#ifdef CONFIG_DEBUG_PAGEALLOC
+ printk("DEBUG_PAGEALLOC ");
+#endif
+#ifdef CONFIG_NUMA
+ printk("NUMA ");
+#endif
+ printk("%s\n", ppc_md.name ? ppc_md.name : "");
+
+ print_modules();
+ show_regs(regs);
+
+ bust_spinlocks(0);
+
+ printk(KERN_EMERG "Waiting for hardware watchdog reset...\n");
+ /* spin until hardware reset */
+ while(1)
+ cpu_relax();
+}
+
/*
* booke_wdt_ping:
*/
^ permalink raw reply related
* Linux 2.6 and uboot
From: Clint Thomas @ 2007-04-13 19:55 UTC (permalink / raw)
To: linuxppc-embedded
Is there any correlation between the version of U-boot to use on a board
and the version of the Linux kernel you plan to use? Current I'm running
U-boot 1.1.2 with kernel 2.4.26 on my MPC85xx board, but i'm trying to
migrate to the latest 2.6 kernel. I am getting a kernel hang at boot
when it registers socket family 17, so I was wondering if it might have
to do with u-boot before exploring the debug route.
=20
Clinton Thomas
^ permalink raw reply
* Re: [PATCH] hvc_console polling mode timer backoff
From: Will Schmidt @ 2007-04-13 19:11 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1176450459.4734.32.camel@concordia.ozlabs.ibm.com>
On Fri, 2007-13-04 at 17:47 +1000, Michael Ellerman wrote:
> Because this is a super tight performance critical inner loop I've
> changed it to use a shift instead of divide. So now it's more like 1.5%,
> but still the point is it increases faster as time passes.
Using a shift here is a good idea. I had considered accelerating the
backoff value, but it got more complex than I wanted quickly.. I didnt
consider a shift. :-)
> It'd be good if some more people can bang on this and see what they
> think of the interactivity.
Still works OK on my power4. I can see the delay on my console, but
I'm specifically looking for it, I don't think it's an issue.
> +#include <linux/debugfs.h>
> +static int hvc_debug_init(void)
> +{
> + debugfs_create_u32("hvc_timeout", 0400, NULL, &timeout);
> + return 0;
> +}
> +__initcall(hvc_debug_init);
> +
Is this part temporary for your graphing, or think it's something that
should go in?
I used /proc/timer_stats output for my graphing, just dont have a good
public spot to upload the pics..
-will
^ permalink raw reply
* Re: Re:
From: Segher Boessenkool @ 2007-04-13 19:10 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, Olaf Hering, Alan Cox, Milton Miller
In-Reply-To: <461FD318.4070102@ru.mvista.com>
>>> I think the proper test is ((cb & 5) == 5) but I can't remember for
>>> sure..
>> That is correct if you know for sure the controller
>> actually supports native mode, and doesn't have that
>> support turned off by some configuration setting;
>> otherwise, the test should be ((cb & 0xf) == 0xf).
>
> "I protest your honor". :-)
> Bits 1 and 3 only indicate that bits 0 and 2 are writeable.
Darn you're right. Sorry for the confusion.
Segher
^ permalink raw reply
* Re: [PATCH 1/4 v2] powerpc: document max-speed and interface-type properties
From: Segher Boessenkool @ 2007-04-13 19:02 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20070413012542.343eb848.kim.phillips@freescale.com>
> Since ucc_geth is being migrated to use the phylib, the existing
> (undocumented) 'interface' property is being deprecated in favour
> of unconjoined variations 'max-speed' and 'interface-type'.
Again, please explain why this information shouldn't
be in the PHY node instead?
Segher
^ permalink raw reply
* Re:
From: Sergei Shtylyov @ 2007-04-13 18:59 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Olaf Hering, Milton Miller, Alan Cox, ppcdev
In-Reply-To: <a6845fee0c7e5d306f93d0ed71d46b5a@kernel.crashing.org>
Hello.
Segher Boessenkool wrote:
>>>+ if (cb & 0x5) { /* if controller is configured for
>>>pci-native mode for both channels */
>>>The above expression allows 1, 4, or 5 for the masked bits. I'm
>>>guessing you
>>>wanted to test that equal to either 5 or 0.
>>I think the proper test is ((cb & 5) == 5) but I can't remember for
>>sure..
> That is correct if you know for sure the controller
> actually supports native mode, and doesn't have that
> support turned off by some configuration setting;
> otherwise, the test should be ((cb & 0xf) == 0xf).
"I protest your honor". :-)
Bits 1 and 3 only indicate that bits 0 and 2 are writeable.
MBR, Sergei
^ 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