* [PATCH/RFC] Add cmd_wrap_dts rules to arch/powerpc/boot/Makefile
From: Mark A. Greer @ 2006-10-19 0:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Paul, et. al.,
Currently, platforms that don't have a dt-aware firmware need to
manually run the wrapper script to wrap a dtb into the zImage that
was just built. This is a PITA and is guaranteed to mess up people
who just want to build a zImage and have it work.
To address this, I added a couple new rules to arch/powerpc/boot/Makefile
so that the dtb is automatically wrapped for "reference" platforms.
"reference" meaning a platform that has its dts in
arch/powerpc/boot/dts/<platform>.dts. It won't work for non-reference
platforms.
The patch is attached below with a header in case it is acceptable, as
is.
This would be used by the sandpoint, say, by adding the following rules
to the Makefile in the appropriate places:
$(obj)/zImage.sandpoint: vmlinux $(wrapperbits)
$(call cmd,wrap_dts,sandpoint)
$(obj)/zImage.initrd.sandpoint: vmlinux $(wrapperbits)
$(call cmd,wrap_dts_initrd,sandpoint)
and:
image-$(CONFIG_SANDPOINT) += zImage.sandpoint
Comments?
Mark
---
[PATCH] Add cmd_wrap_dts rules to arch/powerpc/boot/Makefile
Add cmd_wrap_dts rules to bootwrapper Makefile so "make zImage" and
"make zImage.initrd" will wrap the platform's dtb in the zImage.
This eliminates the need to manually run the wrapper script a
second time just to add the dtb to the zImage.
This only works for reference platforms that have their dts files
in arch/powerpc/boot/dts/<platform>.dts.
Depends-on: http://ozlabs.org/pipermail/linuxppc-dev/2006-October/027003.html
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
Makefile | 7 +++++++
1 files changed, 7 insertions(+)
---
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 4b2be61..3dc4e55 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -117,6 +117,13 @@ quiet_cmd_wrap = WRAP $@
quiet_cmd_wrap_initrd = WRAP $@
cmd_wrap_initrd =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
-i $(obj)/ramdisk.image.gz vmlinux
+quiet_cmd_wrap_dts = WRAP_DTS $@
+ cmd_wrap_dts =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
+ -s $(obj)/dts/$2.dts vmlinux
+quiet_cmd_wrap_dts_initrd = WRAP_DTS $@
+ cmd_wrap_dts_initrd =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 \
+ $(CROSSWRAP) -s $(obj)/dts/$2.dts \
+ -i $(obj)/ramdisk.image.gz vmlinux
$(obj)/zImage.chrp: vmlinux $(wrapperbits)
$(call cmd,wrap,chrp)
^ permalink raw reply related
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Benjamin Herrenschmidt @ 2006-10-18 22:39 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: akpm, linuxppc-dev, Sven Luther, tilmann
In-Reply-To: <200610180022.24631.arnd@arndb.de>
On Wed, 2006-10-18 at 00:22 +0200, Arnd Bergmann wrote:
> On Tuesday 17 October 2006 15:22, Christoph Hellwig wrote:
> > > rtas_node = of_find_node_by_name(NULL, "rtas");
> > > if (rtas_node == NULL)
> > > return -ENODEV;
> >
> > And given this check I wonder why we need the platform check at all. It
> > should be safe to just remove it.
> >
>
> One difference would be that it triggers on machines running SLOF (QS20,
> some JS20/JS21) and maybe some older Macs, which is probably a good
> thing.
Older macs may have bits of RTAS, but it doesn't work. I'd rather still
blacklist machine_is(powermac).
> I wonder if it should be a little stricter though:
>
> > rtas_node = of_find_node_by_path("/rtas");
> > if (!rtas_node)
> > return -ENODEV;
>
> In case there is a node called "rtas" somewhere else.
Yeah, just in case...
Ben.
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Benjamin Herrenschmidt @ 2006-10-18 22:38 UTC (permalink / raw)
To: Olaf Hering; +Cc: akpm, tilmann, Sven Luther, linuxppc-dev
In-Reply-To: <20061018073851.GA13083@aepfle.de>
On Wed, 2006-10-18 at 09:38 +0200, Olaf Hering wrote:
> On Wed, Oct 18, Michael Ellerman wrote:
>
> > But it's called '/proc/ppc64' right now on lots of machines, so you
> > can't go changing it.
>
> if test -d /proc/ppc64 .. is a quick way to check wether the system is
> 64bit or not. Similar to if test -d /proc/iSeries ..
That's really ugly ! You really do that ? Gack...
> You better leave that simple interface.
^ permalink raw reply
* Re: [PATCHES] Ubuntu trivial powerpc patches
From: Benjamin Herrenschmidt @ 2006-10-18 22:35 UTC (permalink / raw)
To: Ben Collins; +Cc: linuxppc-dev
In-Reply-To: <1161191250.5663.14.camel@gullible>
On Wed, 2006-10-18 at 13:07 -0400, Ben Collins wrote:
> +config EARLY_PROM_PRINT
> + bool "Support early messages from the kernel via the prom console"
> + depends PPC_OF
> + default y
> + help
> + Say Y here to see early messages from the kernel through the
> + prom console. These are usually only related to the prom init
> + and detection code.
> +
The help text should probably be a little bit less cryptic :) Something
like saying that those messages are displayed by the Open Firmware
wrapper.
Ben.
^ permalink raw reply
* [PATCH] Fix spelling errors in ucc_fast.c and ucc_slow.c
From: timur @ 2006-10-18 22:27 UTC (permalink / raw)
To: linuxppc-dev
From: Timur Tabi <timur@freescale.com>
In ucc_fast.c and ucc_slow.c, "illegal" is twice spelled "illagal".
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 2 +-
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index c2be734..75fa310 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -163,7 +163,7 @@ int ucc_fast_init(struct ucc_fast_info *
/* check if the UCC port number is in range. */
if ((uf_info->ucc_num < 0) || (uf_info->ucc_num > UCC_MAX_NUM - 1)) {
- uccf_err("ucc_fast_init: Illagal UCC number!");
+ uccf_err("ucc_fast_init: Illegal UCC number!");
return -EINVAL;
}
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_slow.c b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
index 1fb88ef..a49da6b 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_slow.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
@@ -152,7 +152,7 @@ int ucc_slow_init(struct ucc_slow_info *
/* check if the UCC port number is in range. */
if ((us_info->ucc_num < 0) || (us_info->ucc_num > UCC_MAX_NUM - 1)) {
- uccs_err("ucc_slow_init: Illagal UCC number!");
+ uccs_err("ucc_slow_init: Illegal UCC number!");
return -EINVAL;
}
--
1.4.2.1
^ permalink raw reply related
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-18 21:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linuxppc-dev, linux-kernel
In-Reply-To: <17718.39522.456361.987639@cargo.ozlabs.ibm.com>
Here is patch to add some printk to try to figure out what is going on.
Run with this and send me the console output leading up to the failure.
Index: linux-2.6.19-rc2-mm1/mm/slab.c
===================================================================
--- linux-2.6.19-rc2-mm1.orig/mm/slab.c 2006-10-17 18:43:47.000000000 -0500
+++ linux-2.6.19-rc2-mm1/mm/slab.c 2006-10-18 16:47:42.904912835 -0500
@@ -2005,6 +2005,7 @@ static int setup_cpu_cache(struct kmem_c
return enable_cpucache(cachep);
if (g_cpucache_up == NONE) {
+ printk(KERN_CRIT "setup_cpu_cache: NONE\n");
/*
* Note: the first kmem_cache_create must create the cache
* that's used by kmalloc(24), otherwise the creation of
@@ -2023,6 +2024,7 @@ static int setup_cpu_cache(struct kmem_c
else
g_cpucache_up = PARTIAL_AC;
} else {
+ printk(KERN_CRIT "setup_cpu_cache: PARTIAL\n");
cachep->array[smp_processor_id()] =
kmalloc(sizeof(struct arraycache_init), GFP_KERNEL);
@@ -2219,6 +2221,7 @@ kmem_cache_create (const char *name, siz
align = ralign;
/* Get cache's description obj. */
+ printk(KERN_CRIT "Get cache descritor\n");
cachep = kmem_cache_zalloc(&cache_cache, SLAB_KERNEL);
if (!cachep)
goto oops;
@@ -3082,6 +3085,7 @@ static inline void *____cache_alloc(stru
void *objp;
struct array_cache *ac;
+ printk(KERN_CRIT "__cache_alloc\n");
check_irq_off();
ac = cpu_cache_get(cachep);
if (likely(ac->avail)) {
@@ -3135,6 +3139,7 @@ static void *alternate_node_alloc(struct
{
int nid_alloc, nid_here;
+ printk(KERN_CRIT "alternate_node_alloc\n");
if (in_interrupt() || (flags & __GFP_THISNODE))
return NULL;
nid_alloc = nid_here = numa_node_id();
@@ -3160,6 +3165,7 @@ void *fallback_alloc(struct kmem_cache *
struct zone **z;
void *obj = NULL;
+ printk(KERN_CRIT "fallback_alloc\n");
for (z = zonelist->zones; *z && !obj; z++)
if (zone_idx(*z) <= ZONE_NORMAL &&
cpuset_zone_allowed(*z, flags))
@@ -3181,6 +3187,8 @@ static void *__cache_alloc_node(struct k
void *obj;
int x;
+ printk("__cache_alloc_node %d\n", nodeid);
+
l3 = cachep->nodelists[nodeid];
BUG_ON(!l3);
^ permalink raw reply
* [PATCH] powerpc: wrapper: don't require execute perms for zImage.initrd
From: Mark A. Greer @ 2006-10-18 21:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Don't require that the wrapper script be executable when building
zImage.initrds. This has already been fixed for zImages.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
Makefile | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
---
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 37ddfca..4b2be61 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -115,7 +115,7 @@ endif
quiet_cmd_wrap = WRAP $@
cmd_wrap =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 $(CROSSWRAP) vmlinux
quiet_cmd_wrap_initrd = WRAP $@
- cmd_wrap_initrd =$(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
+ cmd_wrap_initrd =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
-i $(obj)/ramdisk.image.gz vmlinux
$(obj)/zImage.chrp: vmlinux $(wrapperbits)
^ permalink raw reply related
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-18 21:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linuxppc-dev, linux-kernel
In-Reply-To: <17718.39522.456361.987639@cargo.ozlabs.ibm.com>
On Thu, 19 Oct 2006, Paul Mackerras wrote:
> > Have memory available for slab boot strap on node 0? Or modify the boot
> > code in such a way that it runs on node 1 or any other node that has
> > memory available.
>
> OK, then I don't understand. There is about 1GB of memory on node 0,
> which is about half of the partition's memory, and it is even in a
> contiguous chunk, but it doesn't start at pfn 0:
And the memory is available? In some messages it showed that all of node 0
memory was allocated on bootup! We end up in fallback_alloc which means
that an allocation attempt failed to obtain memory. Could you figure out
what exactly we are trying to allocate? Add some printk's? Why do we
fallback?
> So it's not that node 0 doesn't have any pages. Any other clues?
We are falling back. So something is going wrong. Either we request memory
from an overallocated node or the page allocator for some other reason is
not giving us the requested memory. If we figure out why then the fix is
probably very simple.
I have no way of investigating the issue except by conjecture and code
review since I have no ppc hardware.
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Paul Mackerras @ 2006-10-18 21:19 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610180811040.27096@schroedinger.engr.sgi.com>
Christoph Lameter writes:
> > Linus' tree is currently broken for us. Any suggestions for how to
> > fix it, since I am not very familiar with the NUMA code?
>
> Have memory available for slab boot strap on node 0? Or modify the boot
> code in such a way that it runs on node 1 or any other node that has
> memory available.
OK, then I don't understand. There is about 1GB of memory on node 0,
which is about half of the partition's memory, and it is even in a
contiguous chunk, but it doesn't start at pfn 0:
early_node_map[3] active PFN ranges
1: 0 -> 32768
0: 32768 -> 278528
1: 278528 -> 524288
So it's not that node 0 doesn't have any pages. Any other clues?
Thanks,
Paul.
^ permalink raw reply
* CPM2 (MPC8260) SMC problem. Please help.
From: Boris Shteinbock @ 2006-10-18 20:40 UTC (permalink / raw)
To: linuxppc-embedded
Hi ppl.
I have discovered very very odd problem with SMC2 on my 8260 board.
kernel version is 2.6.17.
The board is 8260 with serial ports on SMC1 and SMC 2 (SMC1 - console)
Now if I use SMC2 for communicating with remote device, ( some protocol)
I am sending packets and wait for a response.
However if the packet I send is SMALLER than 5 bytes, SMC goes
completely crazy.
write() doesn't return error, but the next read() hangs completely, and the
process moves to D state and it is impossible to kill it by any means.
It only happens when consequent writes of smaller than 5 bytes.
I tried to check the driver, but couldn't find any clues to what goes wrong.
I tried both compatibility and platform-based modes with the same results.
Any help on the issue would be highliy appreciated.
^ permalink raw reply
* Re: [PATCH -rt] powerpc update
From: Daniel Walker @ 2006-10-18 20:54 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linuxppc-dev, tglx, linux-kernel
In-Reply-To: <20061018143318.GB25141@elte.hu>
On Wed, 2006-10-18 at 16:33 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.com> wrote:
>
> > On Wed, 2006-10-18 at 09:28 +0200, Ingo Molnar wrote:
> > > * Daniel Walker <dwalker@mvista.com> wrote:
> > >
> > > > Pay close attention to the fasteoi interrupt threading. I added usage
> > > > of mask/unmask instead of using level handling, which worked well on
> > > > PPC.
> > >
> > > this is wrong - it should be doing mask+ack.
> >
> > The main reason I did it this way is cause the current threaded eoi
> > expected the line to be masked. So if you happen to have a eoi that's
> > threaded you get a warning then the interrupt hangs.
>
> does that in fact happen on -rt6? If yes, could you send the warning
> that is produced?
Here's the kernel messages (from Sergei who is CC'd)
---
Subject: 2.6.18-rt6 failure on MPC8540ADS
My PPC32 board doesn't boot with 2.6.18-rt6, I'm getting this nice trace:
Time: timebase clocksource has been installed.
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT
Modules linked in:
NIP: 00000000 LR: C0051AA8 CTR: 00000000
REGS: c0615cf0 TRAP: 0400 Not tainted (2.6.18_dev)
MSR: 00021000 <ME> CR: 42028088 XER: 20000000
TASK = cffea600[4] 'softirq-timer/0' THREAD: c0614000
GPR00: C0051A94 C0615DA0 CFFEA600 00000035 C0339CC0 00000035 00000013 00000003
GPR08: 00010000 00000000 FCFED080 C0480035 28028084 00000000 0FFFE700 FFFFFFFF
GPR16: FFFD7C1E FFFFFFFF FFFD7B78 C02E5930 00000000 00028488 00000000 FFFFFFFF
GPR24: C033FB1C C0699498 00008000 C0615DE0 C06BBCA0 C0614000 00000035 C0323AC0
NIP [00000000] _start+0x40000000/0x20
LR [C0051AA8] handle_fasteoi_irq+0x170/0x1b8
Call Trace:
[C0615DA0] [C0051A94] handle_fasteoi_irq+0x15c/0x1b8 (unreliable)
[C0615DC0] [C00045A4] do_IRQ+0x9c/0xbc
[C0615DD0] [C000E0C8] ret_from_except+0x0/0x18
[C0615E90] [C01B4A90] phy_write+0x2c/0x6c
[C0615EC0] [C01B6450] marvell_config_aneg+0x24/0xc8
[C0615ED0] [C01B48F8] phy_start_aneg+0x44/0xcc
[C0615EF0] [C01B50E8] phy_timer+0xd8/0x588
[C0615F10] [C0031EC4] run_timer_softirq+0x224/0x1048
[C0615F80] [C002D1EC] ksoftirqd+0x100/0x1ac
[C0615FC0] [C003F36C] kthread+0xc0/0xfc
[C0615FF0] [C000EC4C] original_kernel_thread+0x44/0x60
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
<0>Kernel panic - not syncing: Fatal exception in interrupt
Call Trace:
[C0615C30] [C0006DA8] show_stack+0x3c/0x1a0 (unreliable)
[C0615C60] [C0026484] panic+0x98/0x170
[C0615CB0] [C000BF60] die+0x120/0x130
[C0615CD0] [C0010D38] bad_page_fault+0xcc/0xe8
[C0615CE0] [C000DF24] handle_page_fault+0x7c/0x80
[C0615DA0] [C0051A94] handle_fasteoi_irq+0x15c/0x1b8
[C0615DC0] [C00045A4] do_IRQ+0x9c/0xbc
[C0615DD0] [C000E0C8] ret_from_except+0x0/0x18
[C0615E90] [C01B4A90] phy_write+0x2c/0x6c
[C0615EC0] [C01B6450] marvell_config_aneg+0x24/0xc8
[C0615ED0] [C01B48F8] phy_start_aneg+0x44/0xcc
[C0615EF0] [C01B50E8] phy_timer+0xd8/0x588
[C0615F10] [C0031EC4] run_timer_softirq+0x224/0x1048
[C0615F80] [C002D1EC] ksoftirqd+0x100/0x1ac
[C0615FC0] [C003F36C] kthread+0xc0/0xfc
[C0615FF0] [C000EC4C] original_kernel_thread+0x44/0x60
After looking into the source, I figured out that handle_fasteoi_irq() is
trying to call ack() handler for the irq_chip but arch/powerpc/sysdev/mpic.c
(driving OpenPIC-compatible chips) doesn't have it (and I suppose is not
obliged to since it's using the "fasteoi" flow)...
WBR, Sergei
^ permalink raw reply
* RE: ELDK 4.0 / GDB with mpc85xx
From: Steven Blakeslee @ 2006-10-18 18:00 UTC (permalink / raw)
To: Clint Thomas, linuxppc-embedded
=A0
>My real question however is, will this effect the use of the crossGDB =
>provided with the ELDK? I want to use it with a BDI2000, and the =
>documentation on the Denx website shows it working, but I have also =
read >about issues related to the version of GDB, the BDI firmware, and =
the e500 >c.ore not playing nicely together. Has anybody had good =
experience getting >this setup fully functional? I really need to be =
able to step through the >U-boot code and see where it is failing on our =
platform. Thanks for the >help!
=A0
When the GDB defaults to powerpc:e500 problems do occur. All you need =
to do is set it to powerpc:common and all works swell. I've used it =
plenty of times.
(gdb) show architecture
The target architecture is set automatically (currently
powerpc:e500)
(gdb) set architecture powerpc:common
^ permalink raw reply
* ELDK 4.0 / GDB with mpc85xx
From: Clint Thomas @ 2006-10-18 17:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]
Hey guys,
I am trying to use GDB to debug U-boot 1.1.2 on a system based loosely
off the MPC8540ADS platform. Right now, both Linux (2.4.27) and U-boot
compile perfectly using our in-house cross-compilers
(gcc-3.3.2-glibc-2.3.2), where with the cross-compilers provided in the
ELDK they will not compile.
My real question however is, will this effect the use of the crossGDB
provided with the ELDK? I want to use it with a BDI2000, and the
documentation on the Denx website shows it working, but I have also read
about issues related to the version of GDB, the BDI firmware, and the
e500 core not playing nicely together. Has anybody had good experience
getting this setup fully functional? I really need to be able to step
through the U-boot code and see where it is failing on our platform.
Thanks for the help!
Clinton Thomas
[-- Attachment #2: Type: text/html, Size: 1435 bytes --]
^ permalink raw reply
* [PATCHES] Ubuntu trivial powerpc patches
From: Ben Collins @ 2006-10-18 17:07 UTC (permalink / raw)
To: linuxppc-dev
Here's a couple of small patches I've got in the Ubuntu kernel tree for
powerpc. They can be synced from:
git.kernel.org:/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6#ubuntu-powerpc
The patch for prom init printf's disabling is just to make the boot a
little cleaner.
Ben Collins:
[powerpc] Allow disabling of prom init messages.
[powerpc] Make pSeries_init_panel message configurable.
arch/powerpc/Kconfig | 5 +++++
arch/powerpc/Kconfig.debug | 9 +++++++++
arch/powerpc/kernel/prom_init.c | 5 ++++-
arch/powerpc/platforms/pseries/setup.c | 2 +-
4 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8b69104..58b9ed9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -371,6 +371,11 @@ config PPC_PSERIES
select PPC_UDBG_16550
default y
+config PPC_PSERIES_PANEL_MSG
+ depends on PPC_PSERIES
+ string "Message for pSeries progress panel"
+ default "Linux ppc64"
+
config PPC_ISERIES
bool "IBM Legacy iSeries"
depends on PPC_MULTIPLATFORM && PPC64
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 5ad149b..0f7a26c 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -121,6 +121,15 @@ config BOOTX_TEXT
Say Y here to see progress messages from the boot firmware in text
mode. Requires either BootX or Open Firmware.
+config EARLY_PROM_PRINT
+ bool "Support early messages from the kernel via the prom console"
+ depends PPC_OF
+ default y
+ help
+ Say Y here to see early messages from the kernel through the
+ prom console. These are usually only related to the prom init
+ and detection code.
+
config SERIAL_TEXT_DEBUG
bool "Support for early boot texts over serial port"
depends on 4xx || LOPEC || MV64X60 || PPLUS || PRPMC800 || \
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index b917616..e95cd81 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -297,7 +297,7 @@ static void __init prom_print(const char
}
}
-
+#ifdef CONFIG_EARLY_PROM_PRINT
static void __init prom_print_hex(unsigned long val)
{
int i, nibbles = sizeof(val)*2;
@@ -356,6 +356,9 @@ #endif
}
}
}
+#else
+#define prom_printf(fmt, ...) do {} while(0)
+#endif
static unsigned int __init prom_claim(unsigned long virt, unsigned long size,
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 89a8119..c9fc362 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -340,7 +340,7 @@ static void __init pSeries_setup_arch(vo
static int __init pSeries_init_panel(void)
{
/* Manually leave the kernel version on the panel. */
- ppc_md.progress("Linux ppc64\n", 0);
+ ppc_md.progress(CONFIG_PPC_PSERIES_PANEL_MSG "\n", 0);
ppc_md.progress(init_utsname()->version, 0);
return 0;
^ permalink raw reply related
* Re: [PATCH] 970GX cputable entry
From: Olof Johansson @ 2006-10-18 16:54 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1161186443.28147.46.camel@goblue>
On Wed, 18 Oct 2006 10:47:22 -0500 Jake Moilanen <moilanen@austin.ibm.com> wrote:
> 970GX cputable entry from Steve Winiecki.
Does 970GX have deep nap? If so, you should use __setup_cpu_ppc970MP
instead.
Also, you need to add the PVR to head_64.S and call preinit as
expected. Maybe not as critical since I'm not sure it'll probably never
be in a machine with Apple firmware, but still good to do for
consistency.
-Olof
^ permalink raw reply
* Re: ibmveth and LIOBN field
From: Santiago Leon @ 2006-10-18 16:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, David Gibson, Paul Mackerras
In-Reply-To: <1161150069.23947.18.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> Hi Santiago !
>
> I'm a bit annoyed by a bit of code in the ibmveth driver:
>
> It accesses the iommu table pointer, to get the index and put it into
> it's own private adapter->liobn member. However, that is never used
> anywhere except in ibmveth_seq_show() for the /proc stuff to display
> th'is LIOBN value.
>
> Is this actually useful ? I'd like to just remove that code.
I'll gladly sign off a patch that removes that code. I think we used
liobn in the driver a long time ago to do the tce mappings before we
merged all the common virtual io code into arch/powerpc/vio.c.
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-18 16:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linuxppc-dev, linux-kernel
In-Reply-To: <17717.50596.248553.816155@cargo.ozlabs.ibm.com>
On Wed, 18 Oct 2006, Paul Mackerras wrote:
> Linus' tree is currently broken for us. Any suggestions for how to
> fix it, since I am not very familiar with the NUMA code?
I am not very familiar with the powerpc code and what I got here is
conjecture from various messages. It would help to get some clarification
on what is going on with node 0 memory. Is there really no memory
available from node 0 on bootup? Why is this?
If this is the case then you already have had issues for long time with
per node memory lists being contaminated on bootup.
Why would you attempt to boot linux on a memory node without
memory?
^ permalink raw reply
* RE: Looking For XILINX TEMAC Driver For linux 2.4 or 2.6
From: John Bonesio @ 2006-10-18 15:30 UTC (permalink / raw)
To: Sharon Feldman, linuxppc-embedded; +Cc: Rick Moleres
In-Reply-To: <8506C3905ED0764F889ADEB33E3A9E8062CECA@MAIA.scopus.net>
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]
Hi,
I could just send out one of these drivers and hope that it helps, but I thought it might be better to find out some more specifics on what is needed first. This way we can avoid lots thrashing and missed attempts at getting something to work.
What TEMAC core are you using? What version?
Is there a preference of linux kernels, 2.4 or 2.6?
If you prefer 2.6, do you already have the other kernel changes to support Virtex 4 (assuming that's the fpga you're using)?
Let me know what you're trying to accomplish so I can give you better specific help.
- John
________________________________
From: linuxppc-embedded-bounces+jbonesio=xilinx.com@ozlabs.org on behalf of Sharon Feldman
Sent: Wed 10/18/2006 8:01 AM
To: linuxppc-embedded@ozlabs.org
Subject: Looking For XILINX TEMAC Driver For linux 2.4 or 2.6
I Need XILINX ll_temac Or PLB_Temac Drivers For Linux 2.4 Or 2.6
I Understand There Is A Driver For MV That Can Be Used.
Best Regards/
[-- Attachment #2: Type: text/html, Size: 2211 bytes --]
^ permalink raw reply
* [PATCH] 970GX cputable entry
From: Jake Moilanen @ 2006-10-18 15:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
970GX cputable entry from Steve Winiecki.
Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
arch/powerpc/kernel/cputable.c | 15 +++++++++++++++
arch/powerpc/oprofile/op_model_power4.c | 2 +-
include/asm-powerpc/reg.h | 1 +
3 files changed, 17 insertions(+), 1 deletion(-)
Index: merge/arch/powerpc/kernel/cputable.c
===================================================================
--- merge.orig/arch/powerpc/kernel/cputable.c
+++ merge/arch/powerpc/kernel/cputable.c
@@ -227,6 +227,21 @@ struct cpu_spec cpu_specs[] = {
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "ppc970",
},
+ { /* PPC970GX */
+ .pvr_mask = 0xffff0000,
+ .pvr_value = 0x00450000,
+ .cpu_name = "PPC970GX",
+ .cpu_features = CPU_FTRS_PPC970,
+ .cpu_user_features = COMMON_USER_POWER4 |
+ PPC_FEATURE_HAS_ALTIVEC_COMP,
+ .icache_bsize = 128,
+ .dcache_bsize = 128,
+ .num_pmcs = 8,
+ .cpu_setup = __setup_cpu_ppc970,
+ .oprofile_cpu_type = "ppc64/970",
+ .oprofile_type = PPC_OPROFILE_POWER4,
+ .platform = "ppc970",
+ },
{ /* Power5 GR */
.pvr_mask = 0xffff0000,
.pvr_value = 0x003a0000,
Index: merge/arch/powerpc/oprofile/op_model_power4.c
===================================================================
--- merge.orig/arch/powerpc/oprofile/op_model_power4.c
+++ merge/arch/powerpc/oprofile/op_model_power4.c
@@ -76,7 +76,7 @@ static inline int mmcra_must_set_sample(
{
if (__is_processor(PV_POWER4) || __is_processor(PV_POWER4p) ||
__is_processor(PV_970) || __is_processor(PV_970FX) ||
- __is_processor(PV_970MP))
+ __is_processor(PV_970MP) || __is_processor(PV_970GX))
return 1;
return 0;
Index: merge/include/asm-powerpc/reg.h
===================================================================
--- merge.orig/include/asm-powerpc/reg.h
+++ merge/include/asm-powerpc/reg.h
@@ -591,6 +591,7 @@
#define PV_630 0x0040
#define PV_630p 0x0041
#define PV_970MP 0x0044
+#define PV_970GX 0x0045
#define PV_BE 0x0070
#define PV_PA6T 0x0090
^ permalink raw reply
* Looking For XILINX TEMAC Driver For linux 2.4 or 2.6
From: Sharon Feldman @ 2006-10-18 15:01 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 142 bytes --]
I Need XILINX ll_temac Or PLB_Temac Drivers For Linux 2.4 Or 2.6
I Understand There Is A Driver For MV That Can Be Used.
Best Regards/
[-- Attachment #2: Type: text/html, Size: 648 bytes --]
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-18 15:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linuxppc-dev, linux-kernel
In-Reply-To: <17717.50596.248553.816155@cargo.ozlabs.ibm.com>
On Wed, 18 Oct 2006, Paul Mackerras wrote:
> Since this is a virtualized system there is every possibility that the
> memory we get won't be divided into nodes in the nice neat manner you
> seem to be expecting. It just depends on what memory the hypervisor
> has free, and on what nodes, when the partition is booted.
The only expectation is that memory is available on the node that you are
bootstrapping the slab allocator from.
> In other words, the assumption that node pfn ranges won't overlap is
> completely untenable for us.
That does not matter for this problem.,
> Linus' tree is currently broken for us. Any suggestions for how to
> fix it, since I am not very familiar with the NUMA code?
Have memory available for slab boot strap on node 0? Or modify the boot
code in such a way that it runs on node 1 or any other node that has
memory available.
^ permalink raw reply
* Re: [PATCH -rt] powerpc update
From: Daniel Walker @ 2006-10-18 14:52 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linuxppc-dev, tglx, linux-kernel
In-Reply-To: <20061018143318.GB25141@elte.hu>
On Wed, 2006-10-18 at 16:33 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.com> wrote:
>
> > On Wed, 2006-10-18 at 09:28 +0200, Ingo Molnar wrote:
> > > * Daniel Walker <dwalker@mvista.com> wrote:
> > >
> > > > Pay close attention to the fasteoi interrupt threading. I added usage
> > > > of mask/unmask instead of using level handling, which worked well on
> > > > PPC.
> > >
> > > this is wrong - it should be doing mask+ack.
> >
> > The main reason I did it this way is cause the current threaded eoi
> > expected the line to be masked. So if you happen to have a eoi that's
> > threaded you get a warning then the interrupt hangs.
>
> does that in fact happen on -rt6? If yes, could you send the warning
> that is produced?
>
> Ingo
The warning was the WARN_ON_ONCE from the section below (which is gone
is -rt6)
if (redirect_hardirq(desc)) {
- WARN_ON_ONCE(1);
+ mask_ack_irq(desc, irq);
goto out_unlock;
}
+
I haven't tried it, but I'd think it will work. That's assuming you have
an "ack" which I hear some PowerPC don't (Benjamin Herrenschmidt talked
about having no "ack" when discussing fasteoi a few month back).
Daniel
^ permalink raw reply
* Re: [PATCH -rt] powerpc update
From: Ingo Molnar @ 2006-10-18 14:33 UTC (permalink / raw)
To: Daniel Walker; +Cc: linuxppc-dev, tglx, linux-kernel
In-Reply-To: <1161181941.23082.32.camel@c-67-180-230-165.hsd1.ca.comcast.net>
* Daniel Walker <dwalker@mvista.com> wrote:
> On Wed, 2006-10-18 at 09:28 +0200, Ingo Molnar wrote:
> > * Daniel Walker <dwalker@mvista.com> wrote:
> >
> > > Pay close attention to the fasteoi interrupt threading. I added usage
> > > of mask/unmask instead of using level handling, which worked well on
> > > PPC.
> >
> > this is wrong - it should be doing mask+ack.
>
> The main reason I did it this way is cause the current threaded eoi
> expected the line to be masked. So if you happen to have a eoi that's
> threaded you get a warning then the interrupt hangs.
does that in fact happen on -rt6? If yes, could you send the warning
that is produced?
Ingo
^ permalink raw reply
* Re: [PATCH -rt] powerpc update
From: Ingo Molnar @ 2006-10-18 14:32 UTC (permalink / raw)
To: Daniel Walker; +Cc: linuxppc-dev, tglx, linux-kernel
In-Reply-To: <1161181941.23082.32.camel@c-67-180-230-165.hsd1.ca.comcast.net>
* Daniel Walker <dwalker@mvista.com> wrote:
> > also note that you changed:
>
> > > - goto out_unlock;
> >
> > to:
> >
> > > + goto out;
> >
> > and you even tried to hide your tracks:
>
> hiding something? I made note of these changes specifically so you
> would review them.
hey, it was a joke:
> > :-)
Ingo
^ permalink raw reply
* Re: [PATCH -rt] powerpc update
From: Daniel Walker @ 2006-10-18 14:32 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linuxppc-dev, tglx, linux-kernel
In-Reply-To: <20061018072858.GA29576@elte.hu>
On Wed, 2006-10-18 at 09:28 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.com> wrote:
>
> > Pay close attention to the fasteoi interrupt threading. I added usage
> > of mask/unmask instead of using level handling, which worked well on
> > PPC.
>
> this is wrong - it should be doing mask+ack.
The main reason I did it this way is cause the current threaded eoi
expected the line to be masked. So if you happen to have a eoi that's
threaded you get a warning then the interrupt hangs.
> also note that you changed:
> > - goto out_unlock;
>
> to:
>
> > + goto out;
>
> and you even tried to hide your tracks:
hiding something? I made note of these changes specifically so you would
review them.
Daniel
^ 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