* [PATCH 3/3] powerpc: Update cell_defconfig for xmon & early debugging
From: Michael Ellerman @ 2006-05-02 9:54 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
Update cell_defconfig for xmon & early debugging options. There's probably
no point merging this yet, there'll be lots of new stuff before 2.6.18, just
a heads up.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/configs/cell_defconfig | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
Index: cell/arch/powerpc/configs/cell_defconfig
===================================================================
--- cell.orig/arch/powerpc/configs/cell_defconfig
+++ cell/arch/powerpc/configs/cell_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.17-rc1
-# Wed Apr 12 15:40:32 2006
+# Linux kernel version: 2.6.17-rc2
+# Mon May 1 17:04:39 2006
#
CONFIG_PPC64=y
CONFIG_64BIT=y
@@ -61,7 +61,7 @@ CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
-# CONFIG_KALLSYMS_ALL is not set
+CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
@@ -125,6 +125,7 @@ CONFIG_RTAS_FLASH=y
CONFIG_MMIO_NVRAM=y
CONFIG_CELL_IIC=y
# CONFIG_PPC_MPC106 is not set
+# CONFIG_PPC_970_NAP is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_WANT_EARLY_SERIAL is not set
@@ -154,6 +155,7 @@ CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_IRQ_ALL_CPUS=y
CONFIG_NUMA=y
+CONFIG_NODES_SHIFT=4
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_SELECT_MEMORY_MODEL=y
@@ -823,6 +825,14 @@ CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_NEW_LEDS is not set
#
+# LED drivers
+#
+
+#
+# LED Triggers
+#
+
+#
# InfiniBand support
#
CONFIG_INFINIBAND=y
@@ -1050,11 +1060,13 @@ CONFIG_DEBUG_FS=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUGGER=y
-# CONFIG_XMON is not set
+CONFIG_XMON=y
+# CONFIG_XMON_DEFAULT is not set
CONFIG_IRQSTACKS=y
# CONFIG_BOOTX_TEXT is not set
# CONFIG_PPC_EARLY_DEBUG_LPAR is not set
# CONFIG_PPC_EARLY_DEBUG_G5 is not set
+# CONFIG_PPC_EARLY_DEBUG_CELL is not set
# CONFIG_PPC_EARLY_DEBUG_RTAS is not set
# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set
# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set
^ permalink raw reply
* [PATCH 2/3] powerpc: Add early debugging / xmon support for Cell
From: Michael Ellerman @ 2006-05-02 9:54 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
This patch adds udbg routines for cell, and hooks them up for use as an early
debugging console or for xmon.
With this patch xmon seems to work. On one occasion after sitting in xmon
for a while I lost hard disk interrupts and had to power off, not sure what
the story was there.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/Kconfig.debug | 6 ++
arch/powerpc/kernel/udbg.c | 3 +
arch/powerpc/platforms/cell/Makefile | 2
arch/powerpc/platforms/cell/setup.c | 3 +
arch/powerpc/platforms/cell/udbg.c | 86 +++++++++++++++++++++++++++++++++++
include/asm-powerpc/udbg.h | 1
6 files changed, 100 insertions(+), 1 deletion(-)
Index: cell/arch/powerpc/Kconfig.debug
===================================================================
--- cell.orig/arch/powerpc/Kconfig.debug
+++ cell/arch/powerpc/Kconfig.debug
@@ -131,6 +131,12 @@ config PPC_EARLY_DEBUG_G5
help
Select this to enable early debugging for Apple G5 machines.
+config PPC_EARLY_DEBUG_CELL
+ bool "Cell RTAS console"
+ depends on PPC_CELL
+ help
+ Select this to enable early debugging for Cell systems.
+
config PPC_EARLY_DEBUG_RTAS
bool "RTAS Panel"
depends on PPC_RTAS
Index: cell/arch/powerpc/kernel/udbg.c
===================================================================
--- cell.orig/arch/powerpc/kernel/udbg.c
+++ cell/arch/powerpc/kernel/udbg.c
@@ -42,6 +42,9 @@ void __init udbg_early_init(void)
#elif defined(CONFIG_PPC_EARLY_DEBUG_ISERIES)
/* For iSeries - hit Ctrl-x Ctrl-x to see the output */
udbg_init_iseries();
+#elif defined(CONFIG_PPC_EARLY_DEBUG_CELL)
+ /* Cell RTAS console */
+ udbg_init_cell();
#endif
}
Index: cell/arch/powerpc/platforms/cell/Makefile
===================================================================
--- cell.orig/arch/powerpc/platforms/cell/Makefile
+++ cell/arch/powerpc/platforms/cell/Makefile
@@ -1,5 +1,5 @@
obj-y += interrupt.o iommu.o setup.o spider-pic.o
-obj-y += pervasive.o pci.o
+obj-y += pervasive.o pci.o udbg.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_SPU_FS) += spufs/
Index: cell/arch/powerpc/platforms/cell/setup.c
===================================================================
--- cell.orig/arch/powerpc/platforms/cell/setup.c
+++ cell/arch/powerpc/platforms/cell/setup.c
@@ -49,6 +49,7 @@
#include <asm/ppc-pci.h>
#include <asm/irq.h>
#include <asm/spu.h>
+#include <asm/udbg.h>
#include "interrupt.h"
#include "iommu.h"
@@ -145,6 +146,8 @@ static void __init cell_init_early(void)
{
DBG(" -> cell_init_early()\n");
+ udbg_init_cell();
+
hpte_init_native();
cell_init_iommu();
Index: cell/arch/powerpc/platforms/cell/udbg.c
===================================================================
--- /dev/null
+++ cell/arch/powerpc/platforms/cell/udbg.c
@@ -0,0 +1,86 @@
+#ifndef _CELL_UDBG_H
+#define _CELL_UDBG_H
+
+/*
+ * Copyright (C) 2006 Michael Ellerman, IBM Corporation
+ *
+ * Early debugging and xmon console support.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <asm/rtas.h>
+#include <asm/udbg.h>
+
+/*
+ * For early debugging it's too early to get these out of the device tree,
+ * so we use hard coded values. These may change in future, check that they
+ * match your firmware!
+ * For normal use we get the values from the device tree, so that should
+ * always work ok.
+ */
+static int put_char_token = 0x27;
+static int get_char_token = 0x28;
+
+/*
+ * If firmware won't accept a character, try this many times before
+ * giving up and just throwing the chracter away.
+ */
+#define PUT_ATTEMPTS 16
+
+static void udbg_putc_cell(char c)
+{
+ int i;
+
+ if (c == '\n')
+ udbg_putc_cell('\r');
+
+ for (i = 0; i < PUT_ATTEMPTS; i++) {
+ if (rtas_call(put_char_token, 1, 1, NULL, c) == 0)
+ break;
+ udelay(100);
+ }
+}
+
+static int udbg_getc_poll_cell(void)
+{
+ int c;
+
+ if (rtas_call(get_char_token, 0, 2, &c))
+ c = -1;
+
+ return c;
+}
+
+static int udbg_getc_cell(void)
+{
+ int c;
+
+ while (1) {
+ c = udbg_getc_poll_cell();
+ if (c != -1)
+ return c;
+ }
+}
+
+void __init udbg_init_cell(void)
+{
+ int token;
+
+ token = rtas_token("put-term-char");
+ if (token != RTAS_UNKNOWN_SERVICE)
+ put_char_token = token;
+
+ token = rtas_token("get-term-char");
+ if (token != RTAS_UNKNOWN_SERVICE)
+ get_char_token = token;
+
+ udbg_putc = udbg_putc_cell;
+ udbg_getc = udbg_getc_cell;
+ udbg_getc_poll = udbg_getc_poll_cell;
+}
+
+#endif /* _CELL_UDBG_H */
Index: cell/include/asm-powerpc/udbg.h
===================================================================
--- cell.orig/include/asm-powerpc/udbg.h
+++ cell/include/asm-powerpc/udbg.h
@@ -42,6 +42,7 @@ extern void __init udbg_init_pmac_realmo
extern void __init udbg_init_maple_realmode(void);
extern void __init udbg_init_iseries(void);
extern void __init udbg_init_rtas(void);
+extern void __init udbg_init_cell(void);
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_UDBG_H */
^ permalink raw reply
* [PATCH 1/3] powerpc: Cleanup hvc_rtas.c a little
From: Michael Ellerman @ 2006-05-02 9:54 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
A few cleanups in hvc_rtas.c:
1. Remove unused RTASCONS_PUT_ATTEMPTS
2. Remove unused rtascons_put_delay.
3. Use i as a loop counter like everyone else on earth.
4. Remove pointless variables, eg. x = foo; if (x) return something_else;
5. Whitespace.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
drivers/char/hvc_rtas.c | 43 ++++++++++++++++++-------------------------
1 file changed, 18 insertions(+), 25 deletions(-)
Index: cell/drivers/char/hvc_rtas.c
===================================================================
--- cell.orig/drivers/char/hvc_rtas.c
+++ cell/drivers/char/hvc_rtas.c
@@ -41,37 +41,28 @@
#define hvc_rtas_cookie 0x67781e15
struct hvc_struct *hvc_rtas_dev;
-#define RTASCONS_PUT_ATTEMPTS 16
-
static int rtascons_put_char_token = RTAS_UNKNOWN_SERVICE;
static int rtascons_get_char_token = RTAS_UNKNOWN_SERVICE;
-static int rtascons_put_delay = 100;
-module_param_named(put_delay, rtascons_put_delay, int, 0644);
-static inline int hvc_rtas_write_console(uint32_t vtermno, const char *buf, int count)
+static inline int hvc_rtas_write_console(uint32_t vtermno, const char *buf,
+ int count)
{
- int done;
+ int i;
- /* if there is more than one character to be displayed, wait a bit */
- for (done = 0; done < count; done++) {
- int result;
- result = rtas_call(rtascons_put_char_token, 1, 1, NULL, buf[done]);
- if (result)
+ for (i = 0; i < count; i++) {
+ if (rtas_call(rtascons_put_char_token, 1, 1, NULL, buf[i]))
break;
}
- /* the calling routine expects to receive the number of bytes sent */
- return done;
+
+ return i;
}
static int hvc_rtas_read_console(uint32_t vtermno, char *buf, int count)
{
- int i;
+ int i, c;
for (i = 0; i < count; i++) {
- int c, err;
-
- err = rtas_call(rtascons_get_char_token, 0, 2, &c);
- if (err)
+ if (rtas_call(rtascons_get_char_token, 0, 2, &c))
break;
buf[i] = c;
@@ -89,13 +80,11 @@ static int hvc_rtas_init(void)
{
struct hvc_struct *hp;
- if (rtascons_put_char_token == RTAS_UNKNOWN_SERVICE)
- rtascons_put_char_token = rtas_token("put-term-char");
+ rtascons_put_char_token = rtas_token("put-term-char");
if (rtascons_put_char_token == RTAS_UNKNOWN_SERVICE)
return -EIO;
- if (rtascons_get_char_token == RTAS_UNKNOWN_SERVICE)
- rtascons_get_char_token = rtas_token("get-term-char");
+ rtascons_get_char_token = rtas_token("get-term-char");
if (rtascons_get_char_token == RTAS_UNKNOWN_SERVICE)
return -EIO;
@@ -106,7 +95,9 @@ static int hvc_rtas_init(void)
hp = hvc_alloc(hvc_rtas_cookie, NO_IRQ, &hvc_rtas_get_put_ops);
if (IS_ERR(hp))
return PTR_ERR(hp);
+
hvc_rtas_dev = hp;
+
return 0;
}
module_init(hvc_rtas_init);
@@ -114,8 +105,8 @@ module_init(hvc_rtas_init);
/* This will tear down the tty portion of the driver */
static void __exit hvc_rtas_exit(void)
{
- /* Really the fun isn't over until the worker thread breaks down and the
- * tty cleans up */
+ /* Really the fun isn't over until the worker thread breaks down and
+ * the tty cleans up */
if (hvc_rtas_dev)
hvc_remove(hvc_rtas_dev);
}
@@ -127,12 +118,14 @@ static int hvc_rtas_console_init(void)
rtascons_put_char_token = rtas_token("put-term-char");
if (rtascons_put_char_token == RTAS_UNKNOWN_SERVICE)
return -EIO;
+
rtascons_get_char_token = rtas_token("get-term-char");
if (rtascons_get_char_token == RTAS_UNKNOWN_SERVICE)
return -EIO;
- hvc_instantiate(hvc_rtas_cookie, 0, &hvc_rtas_get_put_ops );
+ hvc_instantiate(hvc_rtas_cookie, 0, &hvc_rtas_get_put_ops);
add_preferred_console("hvc", 0, NULL);
+
return 0;
}
console_initcall(hvc_rtas_console_init);
^ permalink raw reply
* PowerMac: force only suspend-to-disk to be valid
From: Johannes Berg @ 2006-05-02 9:31 UTC (permalink / raw)
To: linuxppc-dev list
This patch adds the .valid callback to pm_ops on PowerMac so that only the
suspend to disk state can be entered. Note that just returning 0 would
suffice since the upper layers don't pass PM_SUSPEND_DISK down, but I think
they ought to be passing it down since they do really need support (or
am I mistaken again?) so we handle it there regardless.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
--- wireless-dev.orig/arch/powerpc/platforms/powermac/setup.c 2006-05-02 10:57:32.101509438 +0200
+++ wireless-dev/arch/powerpc/platforms/powermac/setup.c 2006-05-02 10:58:44.491509438 +0200
@@ -463,11 +463,23 @@ static int pmac_pm_finish(suspend_state_
return 0;
}
+static int pmac_pm_valid(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_DISK:
+ return 1;
+ /* can't do any other states via generic mechanism yet */
+ default:
+ return 0;
+ }
+}
+
static struct pm_ops pmac_pm_ops = {
.pm_disk_mode = PM_DISK_SHUTDOWN,
.prepare = pmac_pm_prepare,
.enter = pmac_pm_enter,
.finish = pmac_pm_finish,
+ .valid = pmac_pm_valid,
};
#endif /* CONFIG_SOFTWARE_SUSPEND */
^ permalink raw reply
* [RFC/PATCH] powerpc: Remove remaining iSeries debugger cruft
From: Michael Ellerman @ 2006-05-02 5:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060502040557.DE09667C13@ozlabs.org>
None of this seems to be necessary, so let's see if can remove it and not
break anything. Booted on iSeries & pSeries here.
NB. we don't remove the hvReleaseData, we just move it down so that the file
reads more clearly.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/head_64.S | 37 ++++++++-------------------------
arch/powerpc/platforms/iseries/setup.c | 12 ----------
2 files changed, 9 insertions(+), 40 deletions(-)
Index: to-merge/arch/powerpc/kernel/head_64.S
===================================================================
--- to-merge.orig/arch/powerpc/kernel/head_64.S
+++ to-merge/arch/powerpc/kernel/head_64.S
@@ -85,34 +85,6 @@ END_FTR_SECTION(0, 1)
/* Catch branch to 0 in real mode */
trap
-#ifdef CONFIG_PPC_ISERIES
- /*
- * At offset 0x20, there is a pointer to iSeries LPAR data.
- * This is required by the hypervisor
- */
- . = 0x20
- .llong hvReleaseData-KERNELBASE
-
- /*
- * At offset 0x28 and 0x30 are offsets to the mschunks_map
- * array (used by the iSeries LPAR debugger to do translation
- * between physical addresses and absolute addresses) and
- * to the pidhash table (also used by the debugger)
- */
- .llong mschunks_map-KERNELBASE
- .llong 0 /* pidhash-KERNELBASE SFRXXX */
-
- /* Offset 0x38 - Pointer to start of embedded System.map */
- .globl embedded_sysmap_start
-embedded_sysmap_start:
- .llong 0
- /* Offset 0x40 - Pointer to end of embedded System.map */
- .globl embedded_sysmap_end
-embedded_sysmap_end:
- .llong 0
-
-#endif /* CONFIG_PPC_ISERIES */
-
/* Secondary processors spin on this value until it goes to 1. */
.globl __secondary_hold_spinloop
__secondary_hold_spinloop:
@@ -124,6 +96,15 @@ __secondary_hold_spinloop:
__secondary_hold_acknowledge:
.llong 0x0
+#ifdef CONFIG_PPC_ISERIES
+ /*
+ * At offset 0x20, there is a pointer to iSeries LPAR data.
+ * This is required by the hypervisor
+ */
+ . = 0x20
+ .llong hvReleaseData-KERNELBASE
+#endif /* CONFIG_PPC_ISERIES */
+
. = 0x60
/*
* The following code is used on pSeries to hold secondary processors
Index: to-merge/arch/powerpc/platforms/iseries/setup.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/setup.c
+++ to-merge/arch/powerpc/platforms/iseries/setup.c
@@ -84,8 +84,6 @@ static void iSeries_pci_final_fixup(void
#endif
extern int rd_size; /* Defined in drivers/block/rd.c */
-extern unsigned long embedded_sysmap_start;
-extern unsigned long embedded_sysmap_end;
extern unsigned long iSeries_recal_tb;
extern unsigned long iSeries_recal_titan;
@@ -568,16 +566,6 @@ static void __init iSeries_fixup_klimit(
if (naca.xRamDisk)
klimit = KERNELBASE + (u64)naca.xRamDisk +
(naca.xRamDiskSize * HW_PAGE_SIZE);
- else {
- /*
- * No ram disk was included - check and see if there
- * was an embedded system map. Change klimit to take
- * into account any embedded system map
- */
- if (embedded_sysmap_end)
- klimit = KERNELBASE + ((embedded_sysmap_end + 4095) &
- 0xfffffffffffff000);
- }
}
static int __init iSeries_src_init(void)
^ permalink raw reply
* Re: [PATCH] powerpc: Export flat device tree via debugfs for debugging
From: Kumar Gala @ 2006-05-02 5:53 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1146529200.27495.23.camel@localhost.localdomain>
On May 1, 2006, at 7:20 PM, Michael Ellerman wrote:
> On Mon, 2006-05-01 at 12:54 -0500, Kumar Gala wrote:
>> On May 1, 2006, at 2:40 AM, Michael Ellerman wrote:
>>
>>> If DEBUG is turned on in prom.c, export the flat device tree via
>>> debugfs.
>>> This has been handy on several occasions.
>>>
>>> To look at it:
>>> # mount -t debugfs none /sys/kernel/debug
>>> # od -a /sys/kernel/debug/powerpc/flat-device-tree
>>> and/or
>>> # dtc -fI dtb /sys/kernel/debug/powerpc/flat-device-tree -O dts
>>>
>>> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
>>> ---
>>>
>>> arch/powerpc/kernel/prom.c | 25 +++++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>>
>>> Index: to-merge/arch/powerpc/kernel/prom.c
>>> ===================================================================
>>> --- to-merge.orig/arch/powerpc/kernel/prom.c
>>> +++ to-merge/arch/powerpc/kernel/prom.c
>>> @@ -30,6 +30,7 @@
>>> #include <linux/bitops.h>
>>> #include <linux/module.h>
>>> #include <linux/kexec.h>
>>> +#include <linux/debugfs.h>
>>>
>>> #include <asm/prom.h>
>>> #include <asm/rtas.h>
>>> @@ -2009,3 +2010,27 @@ void kdump_move_device_tree(void)
>>> /* XXX should we unreserve the old DT? */
>>> }
>>> #endif /* CONFIG_KEXEC */
>>> +
>>> +#ifdef DEBUG
>>
>> Shouldn't this also depend on DEBUGFS being built in.
>
> It could, but DEBUG_FS is written so that you don't have to care, so I
> didn't :)
Cool. Haven't messed with DEBUG_FS.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Remove remaining iSeries debugger cruft
From: Michael Ellerman @ 2006-05-02 4:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060502040557.DE09667C13@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
On Tue, 2006-05-02 at 14:05 +1000, Michael Ellerman wrote:
> This isn't needed anymore, as no one is using this debugger. Doesn't have
> any effect on early debug output etc.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
This is bogus, it moves the embedded_sysmap variables, new patch coming.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: question about Linux 2.6 with Xilinx ML-403
From: Grant Likely @ 2006-05-02 4:09 UTC (permalink / raw)
To: yding; +Cc: linuxppc-embedded list
In-Reply-To: <445696A9.5070200@lnxw.com>
On 5/1/06, yding <yding@lnxw.com> wrote:
> HI, Grant,
>
> It looks like that the patch for ML-403 in Linux 2.6.17 kernel(I downloa=
ded
> from Linus git tree) does not have the directory :
> ./arch/ppc/platform/4xx/xilinx_ocp like the one in the
> 2.4.30 kernel.
That's right. AFAIK, The 2.6 kernel is not yet supported by the
Xilinx EDK tools; and so it cannot generate a 2.6 BSP. If you want to
use the generated BSP; use the montavista 2.4 kernel.
> And also, I saw this thread: "Migrate Xilinx Vertex support from the OCP
> bus to the platfom bus"
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=3D3933
> Does it mean all of onchip peripherals for Virtex-4 FX must reside on th=
e
> PLB bus instead of OPB (OCB) bus ?
No. Platform bus is a Linux construct to make it simpler to handle
"directly attached" devices. ie. Anything that the processor can
access directly w/o PCI et all. OPB and PLB devices are both
'platform' devices in Linux 2.6 terminology.
> (i.e. during the process of creating the ref design for Linux using Xili=
nx
> Platform studio, I have to select PLB peripherals instead of OPB
> peripherals. Is is correct ?)
No, use whatever peripherals you want (either PLB, or OPB). Just be
prepared to port device drivers for anything beyond a serial port.
>
> BTW, do you have a sample ref design for ML-403 board for Xilinx Platfor=
m
> studio ?
Why not use the ref design that Xilinx provides? (I have a number of
designs that work; but most of the time I use the ML403 ref design
because I know it's proven)
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
* [PATCH] powerpc: Remove remaining iSeries debugger cruft
From: Michael Ellerman @ 2006-05-02 4:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1145386937.20493.33.camel@localhost.localdomain>
This isn't needed anymore, as no one is using this debugger. Doesn't have
any effect on early debug output etc.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/head_64.S | 9 ---------
1 file changed, 9 deletions(-)
Index: to-merge/arch/powerpc/kernel/head_64.S
===================================================================
--- to-merge.orig/arch/powerpc/kernel/head_64.S
+++ to-merge/arch/powerpc/kernel/head_64.S
@@ -93,15 +93,6 @@ END_FTR_SECTION(0, 1)
. = 0x20
.llong hvReleaseData-KERNELBASE
- /*
- * At offset 0x28 and 0x30 are offsets to the mschunks_map
- * array (used by the iSeries LPAR debugger to do translation
- * between physical addresses and absolute addresses) and
- * to the pidhash table (also used by the debugger)
- */
- .llong mschunks_map-KERNELBASE
- .llong 0 /* pidhash-KERNELBASE SFRXXX */
-
/* Offset 0x38 - Pointer to start of embedded System.map */
.globl embedded_sysmap_start
embedded_sysmap_start:
^ permalink raw reply
* Re: alignment exceptionhandler sleeps in invalid context
From: Paul Mackerras @ 2006-05-02 4:00 UTC (permalink / raw)
To: Olaf Hering, linuxppc-dev
In-Reply-To: <17489.63055.968862.256370@cargo.ozlabs.ibm.com>
I wrote:
> This patch should fix it, I hope. If you can verify that it fixes it
> I'll send it to Linus.
but init barfs at startup with that patch, due to the double
evaluation of `ptr'. This one runs a bit better...
Paul.
diff --git a/include/asm-powerpc/uaccess.h b/include/asm-powerpc/uaccess.h
index 3872e92..d83fc29 100644
--- a/include/asm-powerpc/uaccess.h
+++ b/include/asm-powerpc/uaccess.h
@@ -7,6 +7,7 @@ #ifndef __ASSEMBLY__
#include <linux/sched.h>
#include <linux/errno.h>
#include <asm/processor.h>
+#include <asm/page.h>
#define VERIFY_READ 0
#define VERIFY_WRITE 1
@@ -179,9 +180,11 @@ do { \
#define __put_user_nocheck(x, ptr, size) \
({ \
long __pu_err; \
- might_sleep(); \
- __chk_user_ptr(ptr); \
- __put_user_size((x), (ptr), (size), __pu_err); \
+ __typeof__(*(ptr)) __user *__pu_addr = (ptr); \
+ if (!is_kernel_addr((unsigned long)__pu_addr)) \
+ might_sleep(); \
+ __chk_user_ptr(ptr); \
+ __put_user_size((x), __pu_addr, (size), __pu_err); \
__pu_err; \
})
@@ -258,9 +261,11 @@ #define __get_user_nocheck(x, ptr, size)
({ \
long __gu_err; \
unsigned long __gu_val; \
+ const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
__chk_user_ptr(ptr); \
- might_sleep(); \
- __get_user_size(__gu_val, (ptr), (size), __gu_err); \
+ if (!is_kernel_addr((unsigned long)__gu_addr)) \
+ might_sleep(); \
+ __get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err; \
})
@@ -270,9 +275,11 @@ #define __get_user64_nocheck(x, ptr, siz
({ \
long __gu_err; \
long long __gu_val; \
- __chk_user_ptr(ptr); \
- might_sleep(); \
- __get_user_size(__gu_val, (ptr), (size), __gu_err); \
+ const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
+ __chk_user_ptr(ptr); \
+ if (!is_kernel_addr((unsigned long)__gu_addr)) \
+ might_sleep(); \
+ __get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err; \
})
^ permalink raw reply related
* [PATCH] powerpc: move _etext out of the text section
From: Stephen Rothwell @ 2006-05-02 3:25 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
The readprofile program stops when it hits the first non-text symbol
after _stext. By moving _etext, it will become an absolute symbol and
so stop the readprofile output. This is a safety measure in case more
text symbols are placed directly after the text section.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/vmlinux.lds.S | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
It would be nice if this was in 2.6.17, but 2.6.18 would also do.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
77a86e7cdbf5eaa5810109f7632e5bff69e1a7e6
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index fe79c25..9055f5a 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -46,12 +46,12 @@ #ifdef CONFIG_PPC32
*(.got2)
__got2_end = .;
#endif /* CONFIG_PPC32 */
-
- . = ALIGN(PAGE_SIZE);
- _etext = .;
- PROVIDE32 (etext = .);
}
+ . = ALIGN(PAGE_SIZE);
+ _etext = .;
+ PROVIDE32 (etext = .);
+
/* Read-only data */
RODATA
--
1.3.1.gaa6b
^ permalink raw reply related
* Re: [PATCH 0/5] powerpc: Cleanup htab code a little
From: Michael Ellerman @ 2006-05-02 1:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1143699173.339118.857634197021.qpush@concordia>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
On Thu, 2006-03-30 at 17:12 +1100, Michael Ellerman wrote:
> A few cleanups to the htab. Built for pSeries, iSeries, pmac, pmac32
> and maple. Booted on P5 LPAR and iSeries.
This series still applies cleanly, so consider this a resend for 2.6.18
if you will.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Export flat device tree via debugfs for debugging
From: Michael Ellerman @ 2006-05-02 0:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <7C163A77-FF5F-49E7-87CF-0EA0411FE7A6@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]
On Mon, 2006-05-01 at 12:54 -0500, Kumar Gala wrote:
> On May 1, 2006, at 2:40 AM, Michael Ellerman wrote:
>
> > If DEBUG is turned on in prom.c, export the flat device tree via
> > debugfs.
> > This has been handy on several occasions.
> >
> > To look at it:
> > # mount -t debugfs none /sys/kernel/debug
> > # od -a /sys/kernel/debug/powerpc/flat-device-tree
> > and/or
> > # dtc -fI dtb /sys/kernel/debug/powerpc/flat-device-tree -O dts
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> > ---
> >
> > arch/powerpc/kernel/prom.c | 25 +++++++++++++++++++++++++
> > 1 file changed, 25 insertions(+)
> >
> > Index: to-merge/arch/powerpc/kernel/prom.c
> > ===================================================================
> > --- to-merge.orig/arch/powerpc/kernel/prom.c
> > +++ to-merge/arch/powerpc/kernel/prom.c
> > @@ -30,6 +30,7 @@
> > #include <linux/bitops.h>
> > #include <linux/module.h>
> > #include <linux/kexec.h>
> > +#include <linux/debugfs.h>
> >
> > #include <asm/prom.h>
> > #include <asm/rtas.h>
> > @@ -2009,3 +2010,27 @@ void kdump_move_device_tree(void)
> > /* XXX should we unreserve the old DT? */
> > }
> > #endif /* CONFIG_KEXEC */
> > +
> > +#ifdef DEBUG
>
> Shouldn't this also depend on DEBUGFS being built in.
It could, but DEBUG_FS is written so that you don't have to care, so I
didn't :)
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: DTC/dts modifications
From: Segher Boessenkool @ 2006-05-02 0:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org list, Jon Loeliger
In-Reply-To: <1146526448.30710.70.camel@localhost.localdomain>
>> By what book? It would seem to me that BNF for dtc is completely
>> under our control and if we want to change it we can. I understand
>> that there is some correspondence to Open Firmware, but it seems that
>> if its people are ok with the dts format changing that's a lot easier
>> than implementing tons of support in dtc for features that cpp
>> gives us.
>
> What about just providing a way to escape them ? Something like \#
> would
> do the trick
Nope, cpp won't eat that.
\#Segher
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Michael Ellerman @ 2006-05-02 0:13 UTC (permalink / raw)
To: Geoff Levand
Cc: Arnd Bergmann, Arnd Bergmann, linux-kernel, linuxppc-dev,
cbe-oss-dev
In-Reply-To: <445690F7.5050605@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]
On Mon, 2006-05-01 at 15:51 -0700, Geoff Levand wrote:
> Segher, a problem with your suggestion is that our
> makefiles don't have as rich a set of logical ops as the
> config files. Its easy to express 'build A if B', but not
> so easy to do 'build A if not C'. To make this work
> cleanly I made PPC_CELL denote !SOME_HYPERVISOR_THING,
> so I can have constructions like this in the makefile:
>
> obj-$(CONFIG_PPC_CELL) += ...
Hi Geoff,
I've been ignoring this discussion, but now that I read it I think this
is all kinda backwards.
PPC_CELL should not denote !SOME_HYPERVISOR, it should just mean "basic
cell support", ie. PPC_CELL gets you platforms/cell built in.
Then we can have SOME_HYPERVISOR which _adds_ support for that
hypervisor. And PPC_CELL_BLADE which selects things which are actually
specific to that hardware, like SPIDERNET etc.
But SOME_HYPERVISOR should not remove support for running on bare metal,
it should just give you the option of running on the hypervisor. Yes
that may require testing things at runtime, that's what
firmware_has_feature() is for.
The goal should be that we have one kernel which can boot on all Cell
implementations. In fact the ultimate goal is to have one kernel that
can boot any platform under powerpc, that's a way off still, but we
don't want to start going backwards.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: windfarm for PM72/PM73/RM31
From: Robin H. Johnson @ 2006-05-02 0:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <A2D81A03-8CD5-41CD-BD49-3EDB1CDE53FD@laposte.net>
[-- Attachment #1: Type: text/plain, Size: 647 bytes --]
On Mon, May 01, 2006 at 06:53:09AM +0200, ?tienne Bersac wrote:
> I own an iMac G5 rev C (iSight) with a PowerMac 12,1 included. Do you
> intend to make support for it ? I will be happy to help you :)
Thanks for sending it to me.
The sensor portion of yours is done, it fit right into my existing code
(three lm75 and two max6690, with the dual temps on max6690 being very
important).
The PID params portion will come together a bit later, please bug me by
Wednesday next week if I haven't posted anything.
--
Robin Hugh Johnson
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Segher Boessenkool @ 2006-05-02 0:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <200605020150.14152.arnd@arndb.de>
>> config SPIDER_NET
>> tristate "Spider Gigabit Ethernet driver"
>> - depends on PCI && PPC_CELL
>> + depends on PCI && PPC_IBM_CELL_BLADE
>> select FW_LOADER
>> help
>> This driver supports the Gigabit Ethernet chips present on the
>
> Hmm, I'm also no longer sure if this is right. In theory, spidernet
> could be used in all sorts of products, wether they are using the
> same bridge chip or just the gigabit ethernet macro from it.
>
> For now, I guess you can just leave this one alone if you respin
> the patch another time. It's disabled by default, so the dependency
> can be updated the next time we get a user in _addition_ to PPC_CELL.
Is there any reason the driver wouldn't build and/or run on other
platforms? If so, fix it. If not, just make it
depends on PCI
?
Segher
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Arnd Bergmann @ 2006-05-01 23:50 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <445690F7.5050605@am.sony.com>
On Tuesday 02 May 2006 00:51, Geoff Levand wrote:
> Seems CELL_IIC is never used. Must be some stale variable,
> so I removed it. Arnd, could you ack this.
Yes, I used it before when there was more code shared between
Cell and pSeries, but that is no longer the case.
> Segher, a problem with your suggestion is that our
> makefiles don't have as rich a set of logical ops as the
> config files. Its easy to express 'build A if B', but not
> so easy to do 'build A if not C'. To make this work
> cleanly I made PPC_CELL denote !SOME_HYPERVISOR_THING,
> so I can have constructions like this in the makefile:
>
> obj-$(CONFIG_PPC_CELL) += ...
>
> I also got rid of SPUFS_PRIV1_MMIO, since SPUFS_PRIV1_MMIO
> just meant spufs with !SOME_HYPERVISOR_THING.
>
I guess that one should really be (SPU_FS && CELL_NATIVE),
using the option Segher suggested now.
> ===================================================================
> --- cell--alp--2.orig/arch/powerpc/Kconfig 2006-05-01 15:13:22.000000000 -0700
> +++ cell--alp--2/arch/powerpc/Kconfig 2006-05-01 15:16:38.000000000 -0700
> @@ -391,15 +391,20 @@
> For more informations, refer to <http://www.970eval.com>
>
> config PPC_CELL
> - bool " Cell Broadband Processor Architecture"
> + bool
> + default n
> +
> +config PPC_IBM_CELL_BLADE
> + bool " IBM Cell Blade"
> depends on PPC_MULTIPLATFORM && PPC64
> + select PPC_CELL
> select PPC_RTAS
> select MMIO_NVRAM
> select PPC_UDBG_16550
>
> config PPC_SYSTEMSIM
> bool " IBM Full System Simulator (systemsim) support"
> - depends on PPC_CELL || PPC_PSERIES || PPC_MAPLE
> + depends on PPC_IBM_CELL_BLADE || PPC_PSERIES || PPC_MAPLE
> help
> Support booting resulting image under IBMs Full System Simulator.
> If you enable this option, you are able to select device
whoops, this one should not be there at all. Note that I updated
your previous patch as well to fit into the series for submission,
and that did not include systemsim.
> Index: cell--alp--2/arch/powerpc/platforms/cell/Kconfig
> ===================================================================
> --- cell--alp--2.orig/arch/powerpc/platforms/cell/Kconfig 2006-05-01 15:13:22.000000000 -0700
> +++ cell--alp--2/arch/powerpc/platforms/cell/Kconfig 2006-05-01 15:13:23.000000000 -0700
> @@ -11,10 +11,15 @@
> or may crash other CPUs.
> Say 'n' here unless you expect to run on DD2.0 only.
>
> +config SPU_BASE
> + bool
> + default n
> +
> config SPU_FS
> tristate "SPU file system"
> default m
> depends on PPC_CELL
> + select SPU_BASE
> help
> The SPU file system is used to access Synergistic Processing
> Units on machines implementing the Broadband Processor
> Index: cell--alp--2/arch/powerpc/platforms/cell/Makefile
> ===================================================================
> --- cell--alp--2.orig/arch/powerpc/platforms/cell/Makefile 2006-05-01 15:13:22.000000000 -0700
> +++ cell--alp--2/arch/powerpc/platforms/cell/Makefile 2006-05-01 15:17:58.000000000 -0700
> @@ -1,14 +1,14 @@
> -obj-y += interrupt.o iommu.o setup.o spider-pic.o
> -obj-y += pervasive.o pci.o
> -
> -obj-$(CONFIG_SMP) += smp.o
> +obj-$(CONFIG_PPC_CELL) += interrupt.o iommu.o setup.o \
> + spider-pic.o pervasive.o pci.o
> +ifeq ($(CONFIG_SMP),y)
> +obj-$(CONFIG_PPC_CELL) += smp.o
> +endif
>
> # needed only when building loadable spufs.ko
> -spufs-modular-$(CONFIG_SPU_FS) += spu_syscalls.o
> -obj-y += $(spufs-modular-m)
> -
> -# always needed in kernel
> -spufs-builtin-$(CONFIG_SPU_FS) += spu_callbacks.o spu_base.o spu_priv1.o
> -obj-y += $(spufs-builtin-y) $(spufs-builtin-m)
> -
> -obj-$(CONFIG_SPU_FS) += spufs/
> +spufs-modular-$(CONFIG_SPU_FS) += spu_syscalls.o
> +obj-$(CONFIG_SPU_BASE) += spu_callbacks.o spu_base.o \
> + $(spufs-modular-m)
> +ifdef CONFIG_SPU_FS
> +obj-$(CONFIG_PPC_CELL) += spu_priv1_mmio.o
> +endif
I guess this could then become something like
spu-priv1-$(CONFIG_PPC_CELL_NATIVE) += spu_priv1_mmio.o
spufs-modular-$(CONFIG_SPU_FS) += spu_syscalls.o
obj-$(CONFIG_SPU_BASE) += spu_callbacks.o spu_base.o \
$(spufs-modular-m) \
$(spu-priv1-y)
> Index: cell--alp--2/drivers/net/Kconfig
> ===================================================================
> --- cell--alp--2.orig/drivers/net/Kconfig 2006-05-01 15:13:22.000000000 -0700
> +++ cell--alp--2/drivers/net/Kconfig 2006-05-01 15:13:23.000000000 -0700
> @@ -2179,7 +2179,7 @@
>
> config SPIDER_NET
> tristate "Spider Gigabit Ethernet driver"
> - depends on PCI && PPC_CELL
> + depends on PCI && PPC_IBM_CELL_BLADE
> select FW_LOADER
> help
> This driver supports the Gigabit Ethernet chips present on the
Hmm, I'm also no longer sure if this is right. In theory, spidernet
could be used in all sorts of products, wether they are using the
same bridge chip or just the gigabit ethernet macro from it.
For now, I guess you can just leave this one alone if you respin
the patch another time. It's disabled by default, so the dependency
can be updated the next time we get a user in _addition_ to PPC_CELL.
Arnd <><
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Arnd Bergmann @ 2006-05-01 23:49 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <FE7E70B5-F0CD-4254-8555-27EC2A70C316@kernel.crashing.org>
On Tuesday 02 May 2006 01:09, Segher Boessenkool wrote:
> So it really should be
>
> depends on PPC_CELL_NATIVE
>
> or similar. Having PPC_CELL mean "native" / "raw" is not the
> way to go, there will be many many hypervisors in the future,
> it would be nice to have PPC_CELL mean just that, "support for
> the Cell architecture" in general, kernels running on various
> hypervisors will see the hardware virtualised to varying degrees.
>
Yes, good point.
Arnd <><
^ permalink raw reply
* Re: DTC/dts modifications
From: Benjamin Herrenschmidt @ 2006-05-01 23:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, Jon Loeliger
In-Reply-To: <55FD11DB-54AF-4284-9E9A-C313F4232105@kernel.crashing.org>
> By what book? It would seem to me that BNF for dtc is completely
> under our control and if we want to change it we can. I understand
> that there is some correspondence to Open Firmware, but it seems that
> if its people are ok with the dts format changing that's a lot easier
> than implementing tons of support in dtc for features that cpp gives us.
What about just providing a way to escape them ? Something like \# would
do the trick
Ben
^ permalink raw reply
* Re: ioremap
From: Josh Boyer @ 2006-05-01 22:45 UTC (permalink / raw)
To: Srinivas Murthy; +Cc: linuxppc-dev
In-Reply-To: <7cb1293c0605011425w1cc34197h4d5fa73ad1077d5a@mail.gmail.com>
On Mon, 2006-05-01 at 14:25 -0700, Srinivas Murthy wrote:
> Hi,
> Why does ioremap() not allow normal system RAM to be mapped in using
> ioremap().
>
> We have a need to access a portion of the normal system RAM to be
> mapped in non-cached.
>
> To simulate, I used kmalloc() to allocate the memory and then passed
> the virt_to_phys() of the memory to ioremap() but then noticed that
> ioremap() wont allow it.
>
> Is there another way to access this memory non-cached?
Limit the amount of memory the kernel consumes using mem=XXM. Then you
should be able to use ioremap on the remainder.
josh
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Badari Pulavarty @ 2006-05-01 23:29 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andrew Morton, linuxppc64-dev, lkml, Martin Bligh, ak
In-Reply-To: <44565443.3020000@shadowen.org>
Andy Whitcroft wrote:
>Martin Bligh wrote:
>
>>Badari Pulavarty wrote:
>>
>>>On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
>>>
>>>>>I ran mtest01 multiple times with various options on my 4-way AMD64
>>>>>box.
>>>>>So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>>>
>>>>>Are there any special config or test options you are testing with ?
>>>>>
>>>>
>>>>Config is here:
>>>>
>>>>http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>>>
>>>>It's just doing "runalltests", I think.
>>>>
>>>
>>>
>>>FWIW, I tried your config file on my 4-way AMD64 (melody) box and ran
>>>latest "mtest01" fine.
>>>
>>>I am now trying runalltests. I guess, its time to bi-sect :(
>>>
>>
>>There was a panic on PPC64 during LTP too, but it seems to have gone
>>away with rc3-mm1. Not sure if it was really fixed, or just intermittent.
>>
>>http://test.kernel.org/abat/29675/debug/console.log
>>
>
>I think its more intermittant than gone. I've got another machine which
>runs the same tests, and she threw a very similar failure on 2.6.18-rc3-mm1.
>
I ran whole LTP with 2.6.17-rc3-mm1 on my (2-way P710) Power box and
didn't see any crashes. I also ran LTP on AMD64 box without any crashes.
Thanks,
Badari
^ permalink raw reply
* Re: question about Linux 2.6 with Xilinx ML-403
From: yding @ 2006-05-01 23:15 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded list
In-Reply-To: <528646bc0604071518i5f95b4dbtd232d8cb92ef4fb9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
HI, Grant,
It looks like that the patch for ML-403 in Linux 2.6.17 kernel(I
downloaded from Linus git tree) does not have the directory :
./arch/ppc/platform/4xx/xilinx_ocp like the one in the 2.4.30 kernel.
And also, I saw this thread: "Migrate Xilinx Vertex support from the OCP
bus to the platfom bus"
http://patchwork.ozlabs.org/linuxppc/patch?id=3933
Does it mean all of onchip peripherals for Virtex-4 FX must reside on
the PLB bus instead of OPB (OCB) bus ?
(i.e. during the process of creating the ref design for Linux using
Xilinx Platform studio, I have to select PLB peripherals instead of OPB
peripherals. Is is correct ?)
BTW, do you have a sample ref design for ML-403 board for Xilinx
Platform studio ?
Thanks for the help.
--
Ying Ding
Grant Likely wrote:
>On 4/7/06, yding <yding@lnxw.com> wrote:
>
>
>> HI, Grant,
>>
>> I found this message :
>>http://patchwork.ozlabs.org/linuxppc/patch?id=3841 on
>>Internet.
>> It looks like you created some patch files for supporting Linux 2.6 with
>>Xilinx ML-403.
>>
>>how can download the whole kernel source tree with your patched files (via
>>cvs or bitkeeper) ?
>>
>>
>
>I believe they are now in Linus' mainline git tree. If not, they are
>in Paul's powerpc git tree.
>
>BTW, please CC the linuxppc-embedded mailing list when emailing me directly.
>
>Cheers,
>g.
>--
>Grant Likely, B.Sc. P.Eng.
>Secret Lab Technologies Ltd.
>(403) 399-0195
>
>
>
[-- Attachment #2: Type: text/html, Size: 2165 bytes --]
^ permalink raw reply
* Re: [PATCH 11/13] cell: split out board specific files
From: Segher Boessenkool @ 2006-05-01 23:09 UTC (permalink / raw)
To: Geoff Levand
Cc: Arnd Bergmann, Arnd Bergmann, linux-kernel, linuxppc-dev, paulus,
cbe-oss-dev
In-Reply-To: <445690F7.5050605@am.sony.com>
> Segher, a problem with your suggestion is that our
> makefiles don't have as rich a set of logical ops as the
> config files. Its easy to express 'build A if B', but not
> so easy to do 'build A if not C'. To make this work
> cleanly I made PPC_CELL denote !SOME_HYPERVISOR_THING,
> so I can have constructions like this in the makefile:
Not just that, but we can have a kernel image supporting both
the "raw" hardware _and_ stuff with a hypervisor underneath.
All CONFIG_<whatever> should always be used as a positive,
never a negative. My bad :-)
So it really should be
depends on PPC_CELL_NATIVE
or similar. Having PPC_CELL mean "native" / "raw" is not the
way to go, there will be many many hypervisors in the future,
it would be nice to have PPC_CELL mean just that, "support for
the Cell architecture" in general, kernels running on various
hypervisors will see the hardware virtualised to varying degrees.
Segher
^ permalink raw reply
* Re: DTC/dts modifications
From: Andreas Schwab @ 2006-05-01 22:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, jdl
In-Reply-To: <00CD15B8-F448-4985-8EEC-3BBF61C0110B@kernel.crashing.org>
Kumar Gala <galak@kernel.crashing.org> writes:
> Cool, here's an invocation that seems to work well. Not sure what
> causes linux = 1 (thus I need the -U linux). Also address the line
> information that is normally spit out.
>
> cpp -U linux -P -x assembler-with-cpp foo.dts
Try -undef, that removes all pre-defined macros.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ 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