* Re: [PATCH] pseries: phyp dump: Variable size reserve space.
From: Manish Ahuja @ 2008-04-09 18:43 UTC (permalink / raw)
To: Olof Johansson; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <20080409183032.GA2360@lixom.net>
Hmmm,
You are possibly right.
Okay I can check and fix that.
-Manish
Olof Johansson wrote:
>>> That's 512MB, isn't it?
>> My calculations in the example I gave in the last email were wrong.
>>
>> In mentally did 10% instead of 5%. But the premise is same.
>>
>> So assuming 5% of some memory is 400 MB, it rounds it down to 256MB etc.
>
> But 0x1fffffff is 512MB, not 256MB. So you're rounding it down to a
> multiple of 512MB.
>
>
> -Olof
^ permalink raw reply
* Re: [PATCH] pseries: phyp dump: Variable size reserve space.
From: Olof Johansson @ 2008-04-09 18:59 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47FD0E67.1090802@austin.ibm.com>
On Wed, Apr 09, 2008 at 01:43:51PM -0500, Manish Ahuja wrote:
> Hmmm,
>
> You are possibly right.
>
> Okay I can check and fix that.
Well, fix the comments if you prefer, I just pointed out the
discreptancy.
-Olof
^ permalink raw reply
* Re: MPC8343 - "unable to handle paging request @ 0"
From: Scott Wood @ 2008-04-09 18:57 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linuxppc-dev
In-Reply-To: <47FCBC73.40703@matrix-vision.de>
Andre Schwarz wrote:
> -> find_legacy_serial_port()
> stdout is /soc8343@e0000000/serial@4500
It looks like you have some memory corruption between here...
> clocksource: timebase mult[3c00001] shift[22] registered
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> -> check_legacy_serial_console()
> can't find stdout package /soc8343@e0000000/serial@4500 !
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
...and here.
-Scott
^ permalink raw reply
* Re: MPC8343 - "unable to handle paging request @ 0"
From: Andre Schwarz @ 2008-04-09 19:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47FD118F.8050407@freescale.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8; format=flowed, Size: 1355 bytes --]
Scott Wood schrieb:
> Andre Schwarz wrote:
>> -> find_legacy_serial_port()
>> stdout is /soc8343@e0000000/serial@4500
>
> It looks like you have some memory corruption between here...
>
>> clocksource: timebase mult[3c00001] shift[22] registered
>>
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> -> check_legacy_serial_console()
>> can't find stdout package /soc8343@e0000000/serial@4500 !
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> ...and here.
>
> -Scott
Scott,
are you talking about a possible hardware problem or misbehaving code ?
Does it look like something gets overwritten during initrd
extraction/movement ?
The system has 512MB RAM which means that we need 2 BAT regs to map the
memory. I've found comments in Freescale u-boot header files that
currently a max of 256MB is supported. I never understood why ? Could
this problem be related to this ?
Do I need to supply reserved memory regions ? I thought u-boot is doing
so for initrd and the kernel don't need it ...
I'll rebuild u-boot with 256MB memory size and do an extra run with
memory test - just to make sure.
Any hints where to look else ?
regards,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: MPC8343 - "unable to handle paging request @ 0"
From: Scott Wood @ 2008-04-09 19:15 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linuxppc-dev
In-Reply-To: <47FD1485.6070209@matrix-vision.de>
Andre Schwarz wrote:
> Scott Wood schrieb:
>> Andre Schwarz wrote:
>>> -> find_legacy_serial_port()
>>> stdout is /soc8343@e0000000/serial@4500
>>
>> It looks like you have some memory corruption between here...
>>
>>> clocksource: timebase mult[3c00001] shift[22] registered
>>>
>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>> -> check_legacy_serial_console()
>>> can't find stdout package /soc8343@e0000000/serial@4500 !
>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>
>> ...and here.
>>
>> -Scott
>
> Scott,
>
> are you talking about a possible hardware problem or misbehaving code ?
Either. The same OF call is done in both places with the same argument,
but is getting different results.
> Does it look like something gets overwritten during initrd
> extraction/movement ?
Don't know.
> The system has 512MB RAM which means that we need 2 BAT regs to map the
> memory. I've found comments in Freescale u-boot header files that
> currently a max of 256MB is supported. I never understood why ? Could
> this problem be related to this ?
Kim's probably be the best one to answer u-boot questions.
-Scott
^ permalink raw reply
* Re: [PATCH] pseries: phyp dump: Variable size reserve space.
From: Segher Boessenkool @ 2008-04-09 19:39 UTC (permalink / raw)
To: Manish Ahuja; +Cc: Olof Johansson, mahuja, linasvepstas, paulus, linuxppc-dev
In-Reply-To: <47FCFDA4.10709@austin.ibm.com>
>>> + tmp = tmp & ~0x000000001FFFFFFF;
Note that this only works as you expect because the constant is
signed here -- the extra zeroes do not magically make it a 64-bit
number. So it goes 32-bit 0x1fffffff -> 32-bit -0x20000000 ->
64-bit -0x20000000.
Please consider writing it with an "L" suffix, or "UL" even, to
reduce trickiness and surprises if ever that number is changed.
Segher
^ permalink raw reply
* Re: ppc440 caches - change proposal [RFC]
From: Grant Likely @ 2008-04-09 19:50 UTC (permalink / raw)
To: John Bonesio; +Cc: Linuxppc-dev
In-Reply-To: <20080409180042.511531370055@mail134-sin.bigfish.com>
On Wed, Apr 9, 2008 at 12:00 PM, John Bonesio <john.bonesio@xilinx.com> wrote:
> Hi Grant,
>
> I have a question about your patch. It appears as if the cache setup code is
> in a file that would be used only on Xilinx FPGA devices.
That is correct.
>
> I understand that many people are using a bootloader that already sets up the
> cache for the kernel, but I'm wondering if Xilinx boards are really a special
> case, or if there may be other non-Xilinx related systems that would also not
> be using a bootloader.
I think there are very few cases of platforms not using some form of firmware.
>
> I also understand the desire to avoid code that does the same work more than
> once, but I wonder if in this case, it's creating too strong a dependence on
> the specific behavior of a certain bootloader.
> I also wonder if arch/powerpc is being made more complex by trying to split
> out this code change into a Xilinx specific area, when the change could just
> be rolled into head_40x.S and we could do away with virtex405-head.S.
In general, I think that the wrapper does not want to touch the cache
settings. In the common case where firmware exists and sets up the
cache then to turn off the cache again would throw away what firmware
already had in cache and slow down the boot.
That being said, I'm not the bootwrapper expert. If other think that
it belongs in head_40x.S then I have no objections.
Josh, any thoughts?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Kernel 2.6.23 Error with make bzImage
From: Sam Karp @ 2008-04-09 20:10 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <800687fe0804071536t1f94e1a0x793bd39836dc09d2@mail.gmail.com>
Hey all,
I've been looking through the archives for a ramdisk.image.gz for a
ppc (ml403) but most of the links are broken. Does anyone have a
working link to one that I could use?
Thanks,
Sam
On 4/7/08, Sam Karp <sam.d.karp@gmail.com> wrote:
> I've been trying to build the linux 2.6.23 kernel for the PPC405 on the
> xilinx ml403. I copied over my xparameters.h and xparameters_ml40x.h files
> and added the following options through menuconfig.
> Enable loadable module support: DISABLE
> Processor:
>
> - Type 40x
> - Math emulation: ENABLE
> - IBM 40x options:
> - Machine Type: "Xilinx-ML403"
>
> Platform options:
>
> - Kernel command line: "console=ttyUL0 root=/dev/ram"
>
> Bus options:
>
> - PCI support: DISABLE
> - PCCARD (PCMCIA/CardBus) support:
> - PCCARD (PCMCIA/CardBus) support: DISABLE
>
> Drivers
>
> - Block Devices:
> - Xilinx SystemACE support: ENABLE
> - Character devices:
> - Serial drivers:
> - Xilinx uartlite serial port support: ENABLE
> - Support for console on Xilinx uartlite serial port:
> ENABLE
>
> I then ran make bzImage and got the following errors. I'm guessing there
> are two options I chose that conflict. Any insight?
>
> CC arch/powerpc/kernel/swsusp.o
> arch/powerpc/kernel/swsusp.c 19 error: redefinition of
> 'save_processor_state'
> include/asm/suspend.h 7 : previous definition of 'save_processor_state' was
> here
> arch/powerpc/kernel/swsusp.c 35 error: redefinition of
> 'restore_processor_state'
> include/asm/suspend.h 11 : previous definition of 'restore_processor_state'
> was here
>
> Thanks,
> Sam
>
^ permalink raw reply
* [patch] PS3: Fix gelic net module dependency
From: Geoff Levand @ 2008-04-09 21:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org, Jeff Garzik
The PS3 gelic network driver depends on the wake-on-lan support
provided by the PS3 sys manager driver. Add that dependency
to the GELIC_NET Kconfig option.
Prevents these build errors:
ps3_gelic_net.c:1277: undefined reference to `.ps3_sys_manager_get_wol'
ps3_gelic_net.c:1337: undefined reference to `.ps3_sys_manager_set_wol'
CC: Masakazu Mokuno <mokuno@sm.sony.co.jp>
CC: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Hi Paul,
This fixes an error introduced in my 2.6.26 WOL patches now
queued in your powerpc tree. Please apply.
-Geoff
drivers/net/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2358,6 +2358,7 @@ config TSI108_ETH
config GELIC_NET
tristate "PS3 Gigabit Ethernet driver"
depends on PPC_PS3
+ select PS3_SYS_MANAGER
help
This driver supports the network device on the PS3 game
console. This driver has built-in support for Ethernet.
^ permalink raw reply
* Re: [PATCH 5/6] [POWERPC] properly declare onstack completion in iseries veth
From: Benjamin Herrenschmidt @ 2008-04-09 21:03 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080409083616.GA24712@lst.de>
On Wed, 2008-04-09 at 10:36 +0200, Christoph Hellwig wrote:
> On Wed, Apr 09, 2008 at 05:21:34PM +1000, Benjamin Herrenschmidt wrote:
> > The iSeries veth driver uses an on-stack struct completion that
> > it initializes using the COMPLETION_INITIALIZER instead of
> > COMPLETION_INITIALIZER_ONSTACK macro, causing problems with
> > lockdep.
>
> should probably go in ASAP independent of the lockdep series.
I don't think there's any difference between the _ONSTACK variant
and the normal one without lockdep, is there ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH] [POWERPC] Make Book-E debug handling SMP safe
From: Kumar Gala @ 2008-04-09 21:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
global_dbcr0 needs to be a per cpu set of save areas instead of a single
global on all processors.
Also, we switch to using DBCR0_IDM to determine if the user space app is
being debugged as its a more consistent way. In the future we should
support features like hardware breakpoint and watchpoints which will
have DBCR0_IDM set but not necessarily DBCR0_IC (single step).
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Paul, you wrote the original code here so please take a look at this.
- k
arch/powerpc/kernel/entry_32.S | 30 +++++++++++++++++++++---------
1 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 69a91bd..84c8686 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -110,9 +110,9 @@ transfer_to_handler:
stw r11,PT_REGS(r12)
#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
/* Check to see if the dbcr0 register is set up to debug. Use the
- single-step bit to do this. */
+ internal debug mode bit to do this. */
lwz r12,THREAD_DBCR0(r12)
- andis. r12,r12,DBCR0_IC@h
+ andis. r12,r12,DBCR0_IDM@h
beq+ 3f
/* From user and task is ptraced - load up global dbcr0 */
li r12,-1 /* clear all pending debug events */
@@ -120,6 +120,12 @@ transfer_to_handler:
lis r11,global_dbcr0@ha
tophys(r11,r11)
addi r11,r11,global_dbcr0@l
+#ifdef CONFIG_SMP
+ rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
+ lwz r9,TI_CPU(r9)
+ slwi r9,r9,3
+ add r11,r11,r9
+#endif
lwz r12,0(r11)
mtspr SPRN_DBCR0,r12
lwz r12,4(r11)
@@ -238,10 +244,10 @@ ret_from_syscall:
stw r11,_CCR(r1)
syscall_exit_cont:
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
- /* If the process has its own DBCR0 value, load it up. The single
- step bit tells us that dbcr0 should be loaded. */
+ /* If the process has its own DBCR0 value, load it up. The internal
+ debug mode bit tells us that dbcr0 should be loaded. */
lwz r0,THREAD+THREAD_DBCR0(r2)
- andis. r10,r0,DBCR0_IC@h
+ andis. r10,r0,DBCR0_IDM@h
bnel- load_dbcr0
#endif
#ifdef CONFIG_44x
@@ -666,10 +672,10 @@ user_exc_return: /* r10 contains MSR_KERNEL here */
restore_user:
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
- /* Check whether this process has its own DBCR0 value. The single
- step bit tells us that dbcr0 should be loaded. */
+ /* Check whether this process has its own DBCR0 value. The internal
+ debug mode bit tells us that dbcr0 should be loaded. */
lwz r0,THREAD+THREAD_DBCR0(r2)
- andis. r10,r0,DBCR0_IC@h
+ andis. r10,r0,DBCR0_IDM@h
bnel- load_dbcr0
#endif
@@ -879,6 +885,12 @@ load_dbcr0:
mfspr r10,SPRN_DBCR0
lis r11,global_dbcr0@ha
addi r11,r11,global_dbcr0@l
+#ifdef CONFIG_SMP
+ rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
+ lwz r9,TI_CPU(r9)
+ slwi r9,r9,3
+ add r11,r11,r9
+#endif
stw r10,0(r11)
mtspr SPRN_DBCR0,r0
lwz r10,4(r11)
@@ -891,7 +903,7 @@ load_dbcr0:
.section .bss
.align 4
global_dbcr0:
- .space 8
+ .space 8*NR_CPUS
.previous
#endif /* !(CONFIG_4xx || CONFIG_BOOKE) */
--
1.5.4.1
^ permalink raw reply related
* Re: [patch] PS3: Fix gelic net module dependency
From: Jeff Garzik @ 2008-04-09 21:42 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <47FD2EC1.8030600@am.sony.com>
Geoff Levand wrote:
> The PS3 gelic network driver depends on the wake-on-lan support
> provided by the PS3 sys manager driver. Add that dependency
> to the GELIC_NET Kconfig option.
>
> Prevents these build errors:
>
> ps3_gelic_net.c:1277: undefined reference to `.ps3_sys_manager_get_wol'
> ps3_gelic_net.c:1337: undefined reference to `.ps3_sys_manager_set_wol'
>
> CC: Masakazu Mokuno <mokuno@sm.sony.co.jp>
> CC: Jeff Garzik <jgarzik@pobox.com>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> Hi Paul,
>
> This fixes an error introduced in my 2.6.26 WOL patches now
> queued in your powerpc tree. Please apply.
>
> -Geoff
>
> drivers/net/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2358,6 +2358,7 @@ config TSI108_ETH
> config GELIC_NET
> tristate "PS3 Gigabit Ethernet driver"
> depends on PPC_PS3
> + select PS3_SYS_MANAGER
> help
> This driver supports the network device on the PS3 game
> console. This driver has built-in support for Ethernet.
looks sane to me, but I do not have enough knowledge to ACK. Thanks for
the CC :)
^ permalink raw reply
* [PATCH] mpc8540 : Fix restart
From: Philippe De Muyter @ 2008-04-09 22:12 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody,
Previously, with the arch/ppc tree, mpc8540 boards could reboot.
Now with the arch/powerpc tree, they can not anymore.
Fix that.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.000000000 +0000
+++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.000000000 +0000
@@ -1428,13 +1433,17 @@
arch_initcall(setup_rstcr);
+extern void abort(void);
+
void fsl_rstcr_restart(char *cmd)
{
local_irq_disable();
if (rstcr)
/* set reset control register */
out_be32(rstcr, 0x2); /* HRESET_REQ */
-
+ else
+ abort();
while (1) ;
+
}
#endif
^ permalink raw reply
* [PATCH] fsl_soc : add support for m41t81 rtc chip
From: Philippe De Muyter @ 2008-04-09 22:22 UTC (permalink / raw)
To: linuxppc-dev
Hello everybody,
Here is small patch allowing to use a m41t81 rtc chip on a FSL_SOC based
board.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.000000000 +0000
+++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.000000000 +0000
@@ -405,7 +405,10 @@
{"dallas,ds1339", "rtc-ds1307", "ds1339",},
{"dallas,ds1340", "rtc-ds1307", "ds1340",},
{"stm,m41t00", "rtc-ds1307", "m41t00"},
+#ifdef CONFIG_RTC_DRV_M41T80
+ {"stm,m41t81", "rtc-m41t80", "m41t81"},
+#endif
{"dallas,ds1374", "rtc-ds1374", "rtc-ds1374",},
};
static int __init of_find_i2c_driver(struct device_node *node,
^ permalink raw reply
* Re: [PATCH] fsl_soc : add support for m41t81 rtc chip
From: Olof Johansson @ 2008-04-09 22:37 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080409222252.GA1006@frolo.macqel>
Hi,
On Thu, Apr 10, 2008 at 12:22:52AM +0200, Philippe De Muyter wrote:
> Hello everybody,
>
> Here is small patch allowing to use a m41t81 rtc chip on a FSL_SOC based
> board.
>
> Signed-off-by: Philippe De Muyter <phdm@macqel.be>
>
> --- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.000000000 +0000
> +++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.000000000 +0000
> @@ -405,7 +405,10 @@
> {"dallas,ds1339", "rtc-ds1307", "ds1339",},
> {"dallas,ds1340", "rtc-ds1307", "ds1340",},
> {"stm,m41t00", "rtc-ds1307", "m41t00"},
> +#ifdef CONFIG_RTC_DRV_M41T80
> + {"stm,m41t81", "rtc-m41t80", "m41t81"},
> +#endif
Don't add ifdef here. It doesn't hurt to have it in the table even if
the driver is not enabled.
-Olof
^ permalink raw reply
* Re: [PATCH 2/6] [POWERPC] lockdep stacktrace support
From: Benjamin Herrenschmidt @ 2008-04-09 22:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20080409072223.7DE7BDDE20@ozlabs.org>
On Wed, 2008-04-09 at 17:21 +1000, Benjamin Herrenschmidt wrote:
> From: Christoph Hellwig <hch@lst.de>
>
> I recently tried to work on lockdep for powerpc. I have preliminary
> version of the stacktrace code, but had to give up on trace irqflags
> support because I'm not that knowledgeable on lowlevel ppc details.
>
> Maybe someone more faimilar with the code wants to give it another try?
>
> My stacktrace code is below:
it's
BTW. I know this patch is still missing (c) boilerplate on the new file
and catch up with some other comments I got last week... I was busy
making the stuff actually work :-) I'll fix that up today.
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> ---
> arch/powerpc/Kconfig | 4 +++
> arch/powerpc/kernel/Makefile | 1
> arch/powerpc/kernel/stacktrace.c | 52 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 57 insertions(+)
>
> --- linux-work.orig/arch/powerpc/Kconfig 2008-04-02 15:46:07.000000000 +1100
> +++ linux-work/arch/powerpc/Kconfig 2008-04-02 16:47:46.000000000 +1100
> @@ -49,6 +49,10 @@ config IRQ_PER_CPU
> bool
> default y
>
> +config STACKTRACE_SUPPORT
> + bool
> + default y
> +
> config RWSEM_GENERIC_SPINLOCK
> bool
>
> Index: linux-work/arch/powerpc/kernel/Makefile
> ===================================================================
> --- linux-work.orig/arch/powerpc/kernel/Makefile 2008-04-02 15:46:07.000000000 +1100
> +++ linux-work/arch/powerpc/kernel/Makefile 2008-04-02 16:46:07.000000000 +1100
> @@ -67,6 +67,7 @@ obj-$(CONFIG_BOOTX_TEXT) += btext.o
> obj-$(CONFIG_SMP) += smp.o
> obj-$(CONFIG_KPROBES) += kprobes.o
> obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
> +obj-$(CONFIG_STACKTRACE) += stacktrace.o
>
> pci64-$(CONFIG_PPC64) += pci_dn.o isa-bridge.o
> obj-$(CONFIG_PCI) += pci_$(CONFIG_WORD_SIZE).o $(pci64-y) \
> Index: linux-work/arch/powerpc/kernel/stacktrace.c
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ linux-work/arch/powerpc/kernel/stacktrace.c 2008-04-02 16:46:07.000000000 +1100
> @@ -0,0 +1,52 @@
> +
> +#include <linux/sched.h>
> +#include <linux/stacktrace.h>
> +
> +
> +#ifdef CONFIG_PPC64
> +#define MIN_STACK_FRAME 112 /* same as STACK_FRAME_OVERHEAD, in fact */
> +#define FRAME_LR_SAVE 2
> +#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD + 288)
> +#define REGS_MARKER 0x7265677368657265ul
> +#define FRAME_MARKER 12
> +#else
> +#define MIN_STACK_FRAME 16
> +#define FRAME_LR_SAVE 1
> +#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD)
> +#define REGS_MARKER 0x72656773ul
> +#define FRAME_MARKER 2
> +#endif
> +
> +
> +/*
> + * Save stack-backtrace addresses into a stack_trace buffer.
> + * If all_contexts is set, all contexts (hardirq, softirq and process)
> + * are saved. If not set then only the current context is saved.
> + */
> +void save_stack_trace(struct stack_trace *trace)
> +{
> + unsigned long sp;
> +
> + asm("mr %0,1" : "=r" (sp));
> +
> + for (;;) {
> + unsigned long *stack = (unsigned long *) sp;
> + unsigned long newsp, ip;
> +
> + if (!validate_sp(sp, current, MIN_STACK_FRAME))
> + return;
> +
> + newsp = stack[0];
> + ip = stack[FRAME_LR_SAVE];
> +
> + if (!trace->skip)
> + trace->entries[trace->nr_entries++] = ip;
> + else
> + trace->skip--;
> +
> + if (trace->nr_entries >= trace->max_entries)
> + return;
> +
> + sp = newsp;
> + }
> +}
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] fsl_soc : add support for m41t81 rtc chip
From: Philippe De Muyter @ 2008-04-09 22:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080409222252.GA1006@frolo.macqel>
Hello everybody,
Here is small patch allowing to use a m41t81 rtc chip on a FSL_SOC based
board.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
--
I have removed the ifdef as pointed by Olof
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.000000000 +0000
+++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.000000000 +0000
@@ -405,7 +405,8 @@
{"dallas,ds1339", "rtc-ds1307", "ds1339",},
{"dallas,ds1340", "rtc-ds1307", "ds1340",},
{"stm,m41t00", "rtc-ds1307", "m41t00"},
+ {"stm,m41t81", "rtc-m41t80", "m41t81"},
{"dallas,ds1374", "rtc-ds1374", "rtc-ds1374",},
};
static int __init of_find_i2c_driver(struct device_node *node,
^ permalink raw reply
* Re: [PATCH] mpc8540 : Fix restart
From: Kumar Gala @ 2008-04-09 22:51 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080409221256.GA927@frolo.macqel>
On Apr 9, 2008, at 5:12 PM, Philippe De Muyter wrote:
> Hi everybody,
>
> Previously, with the arch/ppc tree, mpc8540 boards could reboot.
> Now with the arch/powerpc tree, they can not anymore.
> Fix that.
>
> Signed-off-by: Philippe De Muyter <phdm@macqel.be>
>
> --- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.000000000
> +0000
> +++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.000000000
> +0000
> @@ -1428,13 +1433,17 @@
>
> arch_initcall(setup_rstcr);
>
> +extern void abort(void);
> +
> void fsl_rstcr_restart(char *cmd)
> {
> local_irq_disable();
> if (rstcr)
> /* set reset control register */
> out_be32(rstcr, 0x2); /* HRESET_REQ */
> -
> + else
> + abort();
> while (1) ;
> +
> }
This was on purpose. abort() doesn't really do a restart and thus I
didn't want it to be used that way.
- k
^ permalink raw reply
* Re: [PATCH] mpc8540 : Fix restart
From: Philippe De Muyter @ 2008-04-09 23:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <64B092F9-7790-4655-AA12-B9010D87D0A4@kernel.crashing.org>
On Wed, Apr 09, 2008 at 05:51:40PM -0500, Kumar Gala wrote:
>
> On Apr 9, 2008, at 5:12 PM, Philippe De Muyter wrote:
>> Hi everybody,
>>
>> Previously, with the arch/ppc tree, mpc8540 boards could reboot.
>> Now with the arch/powerpc tree, they can not anymore.
>> Fix that.
>>
>> Signed-off-by: Philippe De Muyter <phdm@macqel.be>
>>
>> --- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.000000000 +0000
>> +++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.000000000 +0000
>> @@ -1428,13 +1433,17 @@
>>
>> arch_initcall(setup_rstcr);
>>
>> +extern void abort(void);
>> +
>> void fsl_rstcr_restart(char *cmd)
>> {
>> local_irq_disable();
>> if (rstcr)
>> /* set reset control register */
>> out_be32(rstcr, 0x2); /* HRESET_REQ */
>> -
>> + else
>> + abort();
>> while (1) ;
>> +
>> }
>
> This was on purpose. abort() doesn't really do a restart and thus I didn't
> want it to be used that way.
>
What do you propose then ? The ability to reboot without power-off is
really needed for embedded targets. And abort() from head_fsl.S seems
really close to reboot.
Philippe
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx/85xx: Reorganize defconfigs
From: Stephen Rothwell @ 2008-04-10 0:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804091017440.18753@blarg.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 535 bytes --]
Hi Kumar,
On Wed, 9 Apr 2008 10:18:06 -0500 (CDT) Kumar Gala <galak@kernel.crashing.org> wrote:
>
> Board specific defconfigs are useful, however with the ability to do
> multi-board defconfigs they aren't needed in the top level configs directory
>
> Move the 83xx/85xx board specific defconfigs to individual directories under
> arch/powerpc/configs.
So do we have multi-board defconfigs for 83xx and/or 85xx?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] pseries: phyp dump: Variable size reserve space.
From: Paul Mackerras @ 2008-04-10 1:36 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Olof Johansson, mahuja, linasvepstas, linuxppc-dev
In-Reply-To: <76b6f0069fd6d80f69620e39c8528e9d@kernel.crashing.org>
Segher Boessenkool writes:
> >>> + tmp = tmp & ~0x000000001FFFFFFF;
>
> Note that this only works as you expect because the constant is
> signed here -- the extra zeroes do not magically make it a 64-bit
> number. So it goes 32-bit 0x1fffffff -> 32-bit -0x20000000 ->
> 64-bit -0x20000000.
Huh? It's not big enough to be negative when considered as a 32-bit
number...
But yes, adding a UL would be a good idea.
Paul.
^ permalink raw reply
* Kernel Panic - not syncing: Attempted to kill init!
From: Sreen Tallam @ 2008-04-10 2:07 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
Has anyone seen this error?
I am running a 2.6.18 kernel on a PPC 405GP using a AMCC Walnut board.
I added some printf's within the kernel to debug more information, and
it pointed to
init/main.c
under init() routine
in run_init_process(execute_command);
where execute_command = /sbin/tallam_init
=> tftp 0x800000 /tftpboot/tallam/kernel_5_2
ENET Speed is 100 Mbps - FULL duplex connection
Filename '/tftpboot/tallam/kernel_5_2'.
Load address: 0x800000
Loading: #################################################################
#################################################################
#################################################################
#######################################
done
Bytes transferred = 1196495 (1241cf hex)
=> bootm 0x800000
## Booting image at 00800000 ...
Image Name: Linux-2.6.18_pro500
Created: 2008-04-09 23:13:11 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1196431 Bytes = 1.1 MB
Load Address: 00400000
Entry Point: 0040053c
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x03FAD548 => set upper limit to 0x00800000
## cmdline at 0x007FFC00 ... 0x007FFD14
gd address = 0x03FADF18
bd address = 0x03FADF48
memstart = 0x00000000
memsize = 0x04000000
flashstart = 0xFF000000
flashsize = 0x01000000
flashoffset = 0x00000000
sramstart = 0x00000000
sramsize = 0x00000000
bootflags = 0x0000A000
procfreq = 100 MHz
plb_busfreq = 100 MHz
pci_busfreq = 50 MHz
ethaddr = 00:xx:xx:04:4F:70
IP addr = 172.xx.xxx.177
baudrate = 9600 bps
No initrd
## Transferring control to Linux (at address 0040053c) ...
Memory <- <0x0 0x4000000> (64MB)
CPU clock-frequency <- 0x5f5e0ff (100MHz)
CPU timebase-frequency <- 0x5f5e0ff (100MHz)
/plb: clock-frequency <- 5f5e0ff (100MHz)
/plb/opb: clock-frequency <- 2faf07f (50MHz)
/plb/ebc: clock-frequency <- 2faf07f (50MHz)
/plb/opb/serial@ef600300: clock-frequency <- a98ac7 (11MHz)
/plb/opb/serial@ef600400: clock-frequency <- a98ac7 (11MHz)
ENET0: local-mac-address <- 00:xx:xx:04:4f:70
zImage starting: loaded at 0x00400000 (sp: 0x03fad3e8)
Allocating 0x299958 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x006a871c)...done 0x2740c0 bytes
Linux/PowerPC load:
mtdparts=phys_mapped_flash:64k@0k(envb),960k@64k(spare-log
s),6m@1m(jffs2b),768k@7m(kernelb),256k@7936k(u-bootb),64k@8m(envp),960k@8256k(
logs),6m@9m(jffs2p),768k@15m(kernelp),256k@16128k(u-bootp)
console=ttyS1,9600 rootfstype=jffs2 root=/dev/mtdblock7 ro
init=/sbin/tallam_init
Finalizing device tree... flat tree at 0x6b5420
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
Linux version 2.6.18_pro500 (gcc version 4.2. 0 ) #1 PREEMPT Wed
Apr 9 16:02:34 PDT 2008
Found legacy serial port 0 for /plb/opb/serial@ef600300
mem=ef600300, taddr=ef600300, irq=0, clk=11111111, speed=9600
Found legacy serial port 1 for /plb/opb/serial@e600400
mem=ef600400, taddr=ef600400, irq=0, clk=11111111, spHz
time_init: processor frequency = 99.999999 MHz
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 62228k/65536k available (2372k kernel code, 3248k reserved,
92k data, 146k bss, 156k init)
Calibrating delay loop... 198.65 BogoMIPS (lpj=397312)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
/plb/opb/gpio@ef600700: device found
PCI: Probing PCI hardware
NET: Registered protocol family 2
IP route cache hash table entries: 512 (order: -1, 2048 bytes)
TCP established hash table entries: 2048 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 2048 bind 1024)
TCP reno registered
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
/plb/opb/gpio@ef600700 character device (0) ready
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO map 0xef600300 mem 0xc5000300 (irq = 16)
is a 1655 0A
serial8250.0: ttyS1 at MMIO map 0xef600400 mem 0xc5002400 (irq = 17)
is a 1655 0A
console handover: boot [udbg0] -> real [ttyS1]
ef600300.serial: ttyS0 at MMIO map 0xef600300 mem 0xc5062300 (irq =
16) is a 1 6550A
ef600400.serial: ttyS1 at MMIO map 0xef600400 mem 0xc5064400 (irq =
17) is a 1 6550A
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
PPC 4xx OCP EMAC driver, version 3.54
MAL v1 /plb/mcmal, 1 TX channels, 1 RX channels
eth0: EMAC-0 /plb/opb/ethernet@ef600800, MAC 00:a0:xx:xx:4f:70
eth0: found Generic MII PHY (0x01)
i2c /dev entries driver
IBM IIC driver v2.1
ff000000.flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
ff000000.flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
Creating 10 MTD partitions on "ff000000.flash":
0x00000000-0x00010000 : "envb"
0x00010000-0x00100000 : "spare-logs"
0x00100000-0x00700000 : "jffs2b"
0x00700000-0x007c0000 : "kernelb"
0x007c0000-0x00800000 : "u-bootb"
0x00800000-0x00810000 : "envp"
0x00810000-0x00900000 : "logs"
0x00900000-0x00f00000 : "jffs2p"
0x00f00000-0x00fc0000 : "kernelp"
0x00fc0000-0x01000000 : "u-bootp"
ip_conntrack version 2.4 (512 buckets, 4096 max) - 172 bytes per conntrack
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Time: timebase clocksource has been installed.
eth0: link is up, 100 FDX
IP-Config: Incomplete network configuration information.
VFS: Mounted root (jffs2 filesystem) readonly.
Freeing unused kernel memory: 156k init
Warning: unable to open an initial console.
init/main.c -- 819
init/main.c -- 821
init/main.c -- 844
init/main.c -- 704 -- /sbin/tallam_init<0>Kernel panic - not syncing:
Attempted to kill init!
Call Trace:
[C3FE7E60] [C0006D98] (unreliable)
[C3FE7EA0] [C001F150]
[C3FE7EF0] [C0023630]
[C3FE7F30] [C0023734]
[C3FE7F40] [C000DBC0]
<0>Rebooting in 180 seconds..
Any help will be appreciated.
Thanks,
Sreen
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Paul Mackerras @ 2008-04-10 2:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <C91EF39E-9776-4D7C-883E-F560A671E221@kernel.crashing.org>
Kumar Gala writes:
> So now we can look at the vmlinux and determine the physical offset.
> The question is how best to do that. Here are the options I see:
> * readelf, grep and parse output
> * objdump grep and parse output
> * simple C program that read's the elf and reports back
Either readelf or objdump for now, and if that proves to be fragile we
can look at a C program. You could do:
readelf -l $vmlinux | grep -m 1 LOAD | awk '{print $4}'
or
objdump -p $vmlinux | grep -m 1 LOAD | awk '{print $7}'
There's not a lot of difference. Since the wrapper already uses
objdump, I think we should use objdump rather than making the wrapper
depend on an additional program (readelf).
> The other questions is if we'd ever have a vmlinux with more than one
> PT_LOAD PHDR. If so which one do we use (the one with the lowest
> physical address)?
I think we would take the first one.
Paul.
^ permalink raw reply
* Re: Status of patches (ppc32 mm init clean and 85xx kernel reloc)
From: Paul Mackerras @ 2008-04-10 2:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc-dev list
In-Reply-To: <88C63CCF-7ED6-486F-8E95-FABD6CEE92E0@kernel.crashing.org>
Kumar Gala writes:
> [POWERPC] bootwrapper: Allow specifying of image physical offset
>
> reworked to look at PHDR (needs linker script update patch). Still
> open question on how best to do that (objdump, readelf, C program,
> suggestions)
Just replied about that one.
> [POWERPC] Remove Kconfig option BOOT_LOAD
>
> should be acceptable.
Looks OK.
> [POWERPC] Provide access to arch/powerpc include path on ppc64
Looks OK.
> [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr
>
> You had some questions about _stext and the PAGE_OFFSET vs
> KERNELBASE. Not sure if you are satisfied with the answers.
The kdump guys don't seem to be concerned, so I guess it's OK.
> [POWERPC] Introduce lowmem_end_addr to distiguish from total_lowmem
OK.
> [POWERPC] 85xx: Cleanup TLB initialization
>
> Only effects 85xx and I don't have issues with it :)
Cool :)
> [POWERPC] Use lowmem_end_addr to limit lmb allocations on ppc32
Looks fine.
> [POWERPC] Rename __initial_memory_limit to __initial_memory_limit_addr
Looks OK, though it seems a tad unnecessary.
> [POWERPC] Clean up some linker and symbol usage
>
> No comments. Straight forward patch.
Well, it is changing behaviour. In particular, klimit is not
necessarily the same as _end. It starts out initialized to &_end but
then gets advanced by some allocations very early in the boot IIRC.
It might be true by now that nothing reserves memory by advancing
klimit any more, but if that is true then the patch description needs
to mention that klimit is no longer used and this patch makes it no
longer usable. In fact in that case you should remove all mention of
klimit.
Also, this patch means that the region from PHYSICAL_START to
__pa(stext) is no longer reserved, which is another behaviour change
that deserves to be mentioned.
> [POWERPC] Move phys_addr_t definition into asm/types.h
>
> I had an open question if the Kconfig for PHYS_64BIT should get set on
> PPC64 as well (has not effect).
>
> I reworked the asm/types.h bits to look like:
> +#if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT)
> +typedef __u64 phys_addr_t;
> +#else
> +typedef __u32 phys_addr_t;
> +#endif
That looks OK.
> [POWERPC] 85xx: Add support for relocatble kernel (and booting at non-
> zero
>
> Should probably get a bit more review.
>
> [POWERPC] Update linker script to properly set physical addresses
>
> You felt LOAD_OFFSET should be (CONFIG_PAGE_OFFSET -
> CONFIG_PHYSICAL_START). I disagreed. We need to resolve.
I think you're right, actually, now, assuming that
CONFIG_PHYSICAL_START is the physical address of the start of the
kernel (actually, why don't you use that instead of __pa(stext) in
your patch [9/11]?).
> I think we should be able to quickly resolve and get into powerpc-next
> all but the '85xx: Add support for relocatable kernel' and
> 'bootwrapper: Allow specifying of image..' patches. If we can close
> on the phys_addr_t and linker script patches that would be great.
I'll put in the ones that look OK, and wait for you to resend the
others.
Paul.
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx/85xx: Reorganize defconfigs
From: Kumar Gala @ 2008-04-10 3:11 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080410103131.f0dcf730.sfr@canb.auug.org.au>
On Apr 9, 2008, at 7:31 PM, Stephen Rothwell wrote:
> Hi Kumar,
>
> On Wed, 9 Apr 2008 10:18:06 -0500 (CDT) Kumar Gala <galak@kernel.crashing.org
> > wrote:
>>
>> Board specific defconfigs are useful, however with the ability to do
>> multi-board defconfigs they aren't needed in the top level configs
>> directory
>>
>> Move the 83xx/85xx board specific defconfigs to individual
>> directories under
>> arch/powerpc/configs.
>
> So do we have multi-board defconfigs for 83xx and/or 85xx?
Yeah the are mpc85xx_defconfig and mpc83xx_defconfig.
- k
^ 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