* Re: [RFC] Debugging with a HW probe.
From: Olof Johansson @ 2006-08-07 23:06 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <E1G9jpY-0004Nv-2d@kmac.watson.ibm.com>
Hi,
On Sun, Aug 06, 2006 at 10:42:16AM -0400, Jimi Xenidis wrote:
> On IBM POWER4 and greater processors (and possibly POWER3 and *Star)
> there is an instruction called ATTN (asm (".long 0x200")) that will
> have the process call out to the HW probe. This instruction is used
> by RiscWatch software to set "soft breakpoints".
>
> We have found it useful to teach xmon to make this call so we can then
> debug the SW thru the probe. Is this useful to anyone else?
Being able to correlate software events with the hardware debugger looks
quite useful, yes.
> Below is a quick attempt at a formalized patch, tho' I am torn between
> making it ATTN specific or just making a generic HW Probe Service.
I would say make it generic, maybe with cputables entry or ppc_md
member, especially with the powerpc merge and other platforms coming in,
having it more generic could be useful.
Also, that way you could get rid of the PVR check within xmon.
> All comments welcome.
A couple below.
> +static void xmon_en_hw_probe(int enable)
> +{
> + ulong hid0;
> + int threaded = 0;
> +
> + /* hopefully the hypervisor has set us up */
> + if (firmware_has_feature(FW_FEATURE_LPAR))
> + return;
> + /* should this be a feature? */
> + switch (PVR_VER(mfspr(SPRN_PVR))) {
> + default:
> + return;
> +
> + case PV_POWER4:
> + case PV_POWER4p:
> + case PV_POWER5:
> + case PV_POWER5p:
> + case PV_BE:
> + /* stop both threads */
> + threaded = 1;
POWER4 multithreaded? I don't think so?
> + case PV_SSTAR:
Trailing whitespace. Also, doesn't sstar have HMT?
> + case PV_970:
> + case PV_970FX:
> + case PV_970MP:
> + break;
> + }
> + hid0 = mfspr(SPRN_HID0);
> + if (enable) {
> + /* make sure that on threaded processors we stop both
> + * threads */
> + hid0 |= HID0_ATTN | (threaded ? HID0_QATTN : 0);
> + xmon_hw_probe_enabled = 1;
> + } else {
> + /* only turn the feature off */
> + hid0 &= ~HID0_ATTN;
> + xmon_hw_probe_enabled = 0;
> + }
> + /* many processors require the following sequence */
> + asm volatile(
> + "sync\n"
> + "mtspr %1, %0\n"
> + "mfspr %0, %1\n"
> + "mfspr %0, %1\n"
> + "mfspr %0, %1\n"
> + "mfspr %0, %1\n"
> + "mfspr %0, %1\n"
> + "mfspr %0, %1\n"
> + "isync" : "=&r" (hid0) : "i" (SPRN_HID0), "0" (hid0):
> + "memory");
> +}
> +#else
> +#define xmon_en_hw_probe(x)
> +#endif
> +
> static inline void sync(void)
> {
> asm volatile("sync; isync");
> @@ -834,6 +904,11 @@ #ifdef CONFIG_PPC_STD_MMU
> dump_segments();
> break;
> #endif
> +#ifdef CONFIG_XMON_ATTN
> + case 'A':
> + xmon_hw_probe();
> + break;
> +#endif
> default:
> printf("Unrecognized command: ");
> do {
> @@ -2565,6 +2640,7 @@ void xmon_init(int enable)
> __debugger_dabr_match = NULL;
> __debugger_fault_handler = NULL;
> }
> + xmon_en_hw_probe(enable);
Please only enable this right before the call.
> xmon_map_scc();
> }
>
> diff --git a/drivers/net/pcmcia/axnet_cs.c b/drivers/net/pcmcia/axnet_cs.c
> index 2ea66ac..33a7922 100644
> diff --git a/include/asm-powerpc/reg.h b/include/asm-powerpc/reg.h
> index bd467bf..ce82965 100644
> --- a/include/asm-powerpc/reg.h
> +++ b/include/asm-powerpc/reg.h
> @@ -207,6 +207,8 @@ #define SPRN_EAR 0x11A /* External Addr
> #define SPRN_HASH1 0x3D2 /* Primary Hash Address Register */
> #define SPRN_HASH2 0x3D3 /* Secondary Hash Address Resgister */
> #define SPRN_HID0 0x3F0 /* Hardware Implementation Register 0 */
> +#define HID0_QATTN (1UL<<35) /* Sup. Proc. attn insn all threads */
> +#define HID0_ATTN (1UL<<32) /* Sup. Proc. attn insn */
> #define HID0_EMCP (1<<31) /* Enable Machine Check pin */
> #define HID0_EBA (1<<29) /* Enable Bus Address Parity */
> #define HID0_EBD (1<<28) /* Enable Bus Data Parity */
> diff --git a/include/asm-powerpc/xmon.h b/include/asm-powerpc/xmon.h
> index 43f7129..cd8f48e 100644
> --- a/include/asm-powerpc/xmon.h
> +++ b/include/asm-powerpc/xmon.h
> @@ -8,5 +8,12 @@ extern int xmon(struct pt_regs *excp);
> extern void xmon_printf(const char *fmt, ...);
> extern void xmon_init(int);
>
> +/*
> + * Support Processor Attention Instruction introduced in POWER
> + * architecture processors as of RS64, tho may not be supported by
> + * POWER 3.
> + */
> +#define ATTN() asm volatile(".long 0x00000200; nop")
At least my toolchain understands "attn ; nop"?
-Olof
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Mark A. Greer @ 2006-08-08 0:16 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, xen-ppc-devel@lists.xensource.com
In-Reply-To: <1154910111.27074.87.camel@diesel>
On Sun, Aug 06, 2006 at 07:21:51PM -0500, Hollis Blanchard wrote:
> On Wed, 2006-07-19 at 16:00 -0700, an unknown sender wrote:
> > diff --git a/arch/powerpc/boot/types.h b/arch/powerpc/boot/types.h
> > new file mode 100644
> > index 0000000..2a2fa2b
> > --- /dev/null
> > +++ b/arch/powerpc/boot/types.h
> > @@ -0,0 +1,29 @@
> > +#ifndef _TYPES_H_
> > +#define _TYPES_H_
> > +
> > +#define COMMAND_LINE_SIZE 512
> > +#define MAX_PATH_LEN 256
> > +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
> > +
> > +typedef unsigned char u8;
> > +typedef unsigned short u16;
> > +typedef unsigned int u32;
> > +#ifdef __powerpc64__
> > +typedef unsigned long u64;
> > +#else
> > +typedef unsigned long long u64;
> > +#endif
>
> As long as we're adding new typedefs, could we please use the stdint.h
> ones (e.g. uint32_t)? For Xen, I need to do flat tree munging in
> userspace, so using real types would help with code reuse.
Sure, I can do that unless someone objects.
Mark
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Mark A. Greer @ 2006-08-08 0:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17622.57931.631871.287907@cargo.ozlabs.ibm.com>
On Mon, Aug 07, 2006 at 04:48:43PM +1000, Paul Mackerras wrote:
> Mark A. Greer writes:
>
> > I realize that I didn't really answer your question. Its at least
> > possible that the console driver could not be known at link time.
> >
> > An example I used in another email is a platform that has 4 serial
> > ports, 2-16550 and 2-mpsc, say. The /chosen/linux,stdout-path could
> > pick any of the four so you would need to compile in a low-level
> > serial driver for both and hook the correct one up at runtime.
> >
> > Same could be said for a serial vs. video console.
>
> OK, that's reasonable. Still would be nice not to have to do the
> double dereference though.
Yep, I'll get rid of the double dereference.
> I think that the platform_ops and the
> fw_ops could probably be combined.
Okay.
> Also, an init method for the
> platform/fw_ops would be useful
Hm, I don't understand what you mean here. I already have
'platform_init()' called from start(). Is that not sufficient?
> - it would let us remove the kludge
> you have in the OF malloc implementation.
The OF malloc routine was a straight copy of what was already
in try_claim() in main.c. As I look at try_claim() now, though,
I see that its changed. I can get rid of that code inside the
"#if defined(PROG_START)". Is that the kludge you were referring to?
> The OF malloc is currently applying a minimum address constraint for
> all platforms, where it used to apply it only for 64-bit platforms.
> We need to fix that up somehow too.
Okay.
Mark
^ permalink raw reply
* Re: [PATCH 3/6] bootwrapper: Add device tree ops for flattened device tree
From: Mark A. Greer @ 2006-08-08 0:30 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, xen-ppc-devel@lists.xensource.com
In-Reply-To: <1154911082.27074.104.camel@diesel>
On Sun, Aug 06, 2006 at 07:38:02PM -0500, Hollis Blanchard wrote:
> On Wed, 2006-07-19 at 16:05 -0700, an unknown sender wrote:
> > --- /dev/null
> > +++ b/arch/powerpc/boot/fdt.c
> > @@ -0,0 +1,525 @@
> > +/*
> > + * Simple dtb (binary flattened device tree) search/manipulation routines.
> > + *
> > + * Author: Mark A. Greer <mgreer at mvista.com>
> > + * - The code for strrchr() was copied from lib/string.c and is
> > + * copyrighted by Linus Torvalds.
> > + * - The smarts for fdt_finddevice() were copied with the author's
> > + * permission from u-boot:common/ft_build.c which was written by
> > + * Pantelis Antoniou <pantelis at embeddedalley.com>.
>
> Hmm, so we'll have at least three copies of this code: uboot, kernel,
> and Xen. Would it make sense to put this stuff into a libdt.a?
Yes, it would.
> Technically, dtc has a "libdt" already, but it's absurdly incomplete (I
> don't even know why it's there), so we could just replace it.
Sounds like a plan!
> Xen needs all the finddevice and setprop functionality here, which looks
> like it's about 2/3rds of this code.
Yeah, pretty much.
> > +static void *dtb_start;
> > +static void *dtb_end;
>
> I'd like to avoid the use of globals here. I know it's fine when you're
> running in early boot, but as I mentioned I'd like to copy this code
> elsewhere. Could these be moved into a structure that's passed as a
> function parameter?
Sure.
> > +static void
> > +fdt_modify_prop(u32 *dp, char *datap, u32 *old_prop_sizep, char *buf,
> > + int buflen)
> > +{
> > + u32 old_prop_data_len, new_prop_data_len;
> > +
> > + old_prop_data_len = _ALIGN_UP(*old_prop_sizep, 4);
> > + new_prop_data_len = _ALIGN_UP(buflen, 4);
> > +
> > + /* Check if new prop data fits in old prop data area */
> > + if (new_prop_data_len == old_prop_data_len) {
> > + memcpy(datap, buf, buflen);
> > + *old_prop_sizep = buflen;
> > + }
> > + else { /* Need to alloc new area to put larger or smaller fdt */
> > + struct boot_param_header *old_bph, *new_bph;
> > + u32 *old_tailp, *new_tailp, *new_datap;
> > + u32 old_total_size, new_total_size, head_len, tail_len, diff;
> > + void *new_dtb_start, *new_dtb_end;
> > +
> > + old_bph = fdt_get_bph(dtb_start),
> > + old_total_size = old_bph->totalsize;
> > + head_len = (u32)datap - (u32)dtb_start;
> > + tail_len = old_total_size - (head_len + old_prop_data_len);
> > + old_tailp = (u32 *)((u32)dtb_end - tail_len);
> > + new_total_size = head_len + new_prop_data_len + tail_len;
> > +
> > + if (!(new_dtb_start = malloc(new_total_size))) {
> > + printf("Can't alloc space for new fdt\n\r");
> > + exit();
> > + }
> > +
> > + new_dtb_end = (void *)((u32)new_dtb_start + new_total_size);
> > + new_datap = (u32 *)((u32)new_dtb_start + head_len);
> > + new_tailp = (u32 *)((u32)new_dtb_end - tail_len);
> > +
> > + memcpy(new_dtb_start, dtb_start, head_len);
> > + memcpy(new_datap, buf, buflen);
> > + memcpy(new_tailp, old_tailp, tail_len);
> > + *(new_datap - 2) = buflen;
> > +
> > + new_bph = fdt_get_bph(new_dtb_start),
> > + new_bph->totalsize = new_total_size;
> > +
> > + diff = new_prop_data_len - old_prop_data_len;
> > +
> > + /* Adjust offsets of other sections, if necessary */
> > + if (new_bph->off_dt_strings > new_bph->off_dt_struct)
> > + new_bph->off_dt_strings += diff;
> > +
> > + if (new_bph->off_mem_rsvmap > new_bph->off_dt_struct)
> > + new_bph->off_mem_rsvmap += diff;
> > +
> > + free(dtb_start, old_total_size);
> > +
> > + dtb_start = new_dtb_start;
> > + dtb_end = new_dtb_end;
> > + }
> > +}
>
> I didn't realize the boot wrapper had a full malloc() to work with.
It doesn't (really). I made a standard interface to what may
someday be a real memory allocator. If you look in dink.c,
you'll see I just have a hack malloc() and no free() at all.
Its one of those things that I was hoping someone would chip in
and help with. IIRC, Matt McClintock was looking at that but I'm
not sure how far he got.
> I
> was actually planning to only allow overwriting properties with values
> of the same size, since for the most part I just need to modify some
> small fixed-size data. Do you need more? I guess if the code already
> works...
I know that we need to extend the size of a property because
/chosen/bootargs can be edited and potentially extended.
Mark
^ permalink raw reply
* Re: [PATCH] SLB shadow buffer
From: Milton Miller @ 2006-08-08 1:15 UTC (permalink / raw)
To: mikey, linuxppc-dev; +Cc: paulus, anton, miltonm
On Mon Aug 7 2006 01:19:19 AM CDT, Michael Neuling wrote:
> Updated with comments from Milton.
Better
> +#define SHADOW_SLB_BOLTED_STACK_ESID \
> + (SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1))
> +#define SHADOW_SLB_BOLTED_STACK_VSID \
> + (SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1) + 8)
> +
Still a bit of magic size, but not likely to change.
Maybe an expicit define for the slot?
> + /* Update the last bolted SLB */
> + ld r9,PACA_SLBSHADOWPTR(r13)
> + li r12,0
> + std r12,SHADOW_SLB_BOLTED_STACK_ESID(r9) /* Clear ESID */
> + std r7,SHADOW_SLB_BOLTED_STACK_VSID(r9) /* Save VSID */
> + std r0,SHADOW_SLB_BOLTED_STACK_ESID(r9) /* Save ESID */
> +
Still some leading spaces hiding
> Index: linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
> @@ -133,5 +135,22 @@ struct > > > lppaca {
>
> extern struct lppaca lppaca[];
>
> +/*
> + * SLB shadow buffer structure as defined in the PAPR. The save_area
> + * contains adjacent ESID and VSID pairs for each shadowed SLB. The
> + * ESID is stored in the lower 64bits, then the VSID.
> + */
> +struct slb_shadow {
> + u32 persistent; // Number of persistent SLBs x00-x03
> + u32 buffer_length; // Total shadow buffer length x04-x07
> + u64 reserved; // Alignment x08-x0f
> + struct {
> + u64 esid;
> + u64 vsid;
> + } save_area[SLB_NUM_BOLTED]; // x10-x40
> +} ____cacheline_aligned;
> +
C comments ... or in the separate cleanup patch
> +extern struct slb_shadow slb_shadow[];
> +
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_LPPACA_H */
> Index: linux-2.6-ozlabs/include/asm-powerpc/paca.h
> ===================================================================
>
> /* accumulated system TB ticks */
> u64 startpurr; /* PURR/TB value snapshot */
> +
> + struct slb_shadow *slb_shadow_ptr;
> };
Do we need the extra line? (I haven't looked at the result)
milton
^ permalink raw reply
* Re: [PATCH] Update lppaca offset comments
From: Milton Miller @ 2006-08-08 1:22 UTC (permalink / raw)
To: mikey, paulus; +Cc: linuxppc-dev
On Mon Aug 7 2006 02:34:50 AM CDT, Michael Neuling wrote:
> Update offset comments. No functional change.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> include/asm-powerpc/lppaca.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
> ===================================================================
> --- linux-2.6-ozlabs.orig/include/asm-powerpc/lppaca.h
> +++ linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
> @@ -114,7 +114,7 @@ struct lppaca {
>
>
> //=============================================================================
> -// CACHE_LINE_3 0x0100 - 0x007F: This line is shared with other processors
> +// CACHE_LINE_3 0x0100 - 0x017F: This line is shared with other processors
> //=============================================================================
How about taking the opertunity to convert to C comments?
milton
^ permalink raw reply
* [PATCH] Change panic_on_oops message to "Fatal exception"
From: Horms @ 2006-08-08 3:46 UTC (permalink / raw)
To: Russell King, Tony Luck, Paul Mackerras, Anton Blanchard,
Andi Kleen, Chris Zankel, Andrew Morton
Cc: linuxppc-dev, linux-ia64, linux-kernel, discuss
Change panic_on_oops message to "Fatal exception"
Previously the message was "Fatal exception: panic_on_oops", as introduced
in a recent patch whith removed a somewhat dangerous call to ssleep() in
the panic_on_oops path. However, Paul Mackerras suggested that this was
somewhat confusing, leadind people to believe that it was panic_on_oops
that was the root cause of the fatal exception. On his suggestion, this
patch changes the message to simply "Fatal exception". A suitable oops
message should already have been displayed.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/kernel/traps.c | 2 +-
arch/i386/kernel/traps.c | 2 +-
arch/ia64/kernel/traps.c | 2 +-
arch/powerpc/kernel/traps.c | 2 +-
arch/x86_64/kernel/traps.c | 2 +-
arch/xtensa/kernel/traps.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 4e29dd0..aeeed80 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -233,7 +233,7 @@ NORET_TYPE void die(const char *str, str
spin_unlock_irq(&die_lock);
if (panic_on_oops)
- panic("Fatal exception: panic_on_oops");
+ panic("Fatal exception");
do_exit(SIGSEGV);
}
diff --git a/arch/i386/kernel/traps.c b/arch/i386/kernel/traps.c
index 0d4005d..82e0fd0 100644
--- a/arch/i386/kernel/traps.c
+++ b/arch/i386/kernel/traps.c
@@ -454,7 +454,7 @@ #endif
panic("Fatal exception in interrupt");
if (panic_on_oops)
- panic("Fatal exception: panic_on_oops");
+ panic("Fatal exception");
oops_exit();
do_exit(SIGSEGV);
diff --git a/arch/ia64/kernel/traps.c b/arch/ia64/kernel/traps.c
index 5a04204..fffa9e0 100644
--- a/arch/ia64/kernel/traps.c
+++ b/arch/ia64/kernel/traps.c
@@ -118,7 +118,7 @@ die (const char *str, struct pt_regs *re
spin_unlock_irq(&die.lock);
if (panic_on_oops)
- panic("Fatal exception: panic_on_oops");
+ panic("Fatal exception");
do_exit(SIGSEGV);
}
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 2105767..05682a2 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -151,7 +151,7 @@ #endif
panic("Fatal exception in interrupt");
if (panic_on_oops)
- panic("Fatal exception: panic_on_oops");
+ panic("Fatal exception");
do_exit(err);
diff --git a/arch/x86_64/kernel/traps.c b/arch/x86_64/kernel/traps.c
index 4e9938d..14052f0 100644
--- a/arch/x86_64/kernel/traps.c
+++ b/arch/x86_64/kernel/traps.c
@@ -529,7 +529,7 @@ void __kprobes oops_end(unsigned long fl
/* Nest count reaches zero, release the lock. */
spin_unlock_irqrestore(&die_lock, flags);
if (panic_on_oops)
- panic("Fatal exception: panic_on_oops");
+ panic("Fatal exception");
}
void __kprobes __die(const char * str, struct pt_regs * regs, long err)
diff --git a/arch/xtensa/kernel/traps.c b/arch/xtensa/kernel/traps.c
index 9734960..ce077d6 100644
--- a/arch/xtensa/kernel/traps.c
+++ b/arch/xtensa/kernel/traps.c
@@ -488,7 +488,7 @@ #endif
panic("Fatal exception in interrupt");
if (panic_on_oops)
- panic("Fatal exception: panic_on_oops");
+ panic("Fatal exception");
do_exit(err);
}
--
1.4.1.gd3ba6
^ permalink raw reply related
* Re: [PATCH] SLB shadow buffer
From: Michael Neuling @ 2006-08-08 4:21 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <11154999753625558ec1.596516649.miltonm@bga.com>
> > +#define SHADOW_SLB_BOLTED_STACK_ESID \
> > + (SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1))
> > +#define SHADOW_SLB_BOLTED_STACK_VSID \
> > + (SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1) + 8)
> > +
> Still a bit of magic size, but not likely to change.
>
> Maybe an expicit define for the slot?
Arrh nice, I can do this all in asm-offsets. Much less magic.
> > + /* Update the last bolted SLB */
> > + ld r9,PACA_SLBSHADOWPTR(r13)
> > + li r12,0
> > + std r12,SHADOW_SLB_BOLTED_STACK_ESID(r9) /* Clear ESID */
> > + std r7,SHADOW_SLB_BOLTED_STACK_VSID(r9) /* Save VSID */
> > + std r0,SHADOW_SLB_BOLTED_STACK_ESID(r9) /* Save ESID */
> > +
>
> Still some leading spaces hiding
Yep... oops.
>
> > Index: linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
>
> > @@ -133,5 +135,22 @@ struct > > > lppaca {
> >
> > extern struct lppaca lppaca[];
> >
> > +/*
> > + * SLB shadow buffer structure as defined in the PAPR. The save_area
> > + * contains adjacent ESID and VSID pairs for each shadowed SLB. The
> > + * ESID is stored in the lower 64bits, then the VSID.
> > + */
> > +struct slb_shadow {
> > + u32 persistent; // Number of persistent SLBs x00-x03
> > + u32 buffer_length; // Total shadow buffer length x04-x07
> > + u64 reserved; // Alignment x08-x0f
> > + struct {
> > + u64 esid;
> > + u64 vsid;
> > + } save_area[SLB_NUM_BOLTED]; // x10-x40
> > +} ____cacheline_aligned;
> > +
>
> C comments ... or in the separate cleanup patch
I think I'll post a full lppaca cleanup patch in a bit.
> > +extern struct slb_shadow slb_shadow[];
> > +
> > #endif /* __KERNEL__ */
> > #endif /* _ASM_POWERPC_LPPACA_H */
> > Index: linux-2.6-ozlabs/include/asm-powerpc/paca.h
> > ===================================================================
> >
> > /* accumulated system TB ticks */
> > u64 startpurr; /* PURR/TB value snapshot */
> > +
> > + struct slb_shadow *slb_shadow_ptr;
> > };
>
> Do we need the extra line? (I haven't looked at the result)
They are broken into logical groups, so no.
Updated patch to come.
Michael
^ permalink raw reply
* [PATCH] SLB shadow buffer
From: Michael Neuling @ 2006-08-08 4:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, anton, miltonm
This adds a shadow buffer for the SLBs and regsiters it with PHYP.
Only the bolted SLB entries (top 3) are shadowed.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Updated with more comments from Milton
arch/powerpc/kernel/asm-offsets.c | 7 ++++
arch/powerpc/kernel/entry_64.S | 8 +++++
arch/powerpc/kernel/paca.c | 15 +++++++++
arch/powerpc/mm/slb.c | 37 +++++++++++++++++++++---
arch/powerpc/platforms/pseries/lpar.c | 24 ++++++++++++---
arch/powerpc/platforms/pseries/plpar_wrappers.h | 10 ++++++
arch/powerpc/platforms/pseries/setup.c | 12 ++++++-
include/asm-powerpc/lppaca.h | 19 ++++++++++++
include/asm-powerpc/paca.h | 3 +
9 files changed, 124 insertions(+), 11 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/asm-offsets.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/asm-offsets.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/asm-offsets.c
@@ -42,6 +42,7 @@
#include <asm/lppaca.h>
#include <asm/cache.h>
#include <asm/compat.h>
+#include <asm/mmu.h>
#endif
#define DEFINE(sym, val) \
@@ -135,11 +136,17 @@ int main(void)
DEFINE(PACA_STARTPURR, offsetof(struct paca_struct, startpurr));
DEFINE(PACA_USER_TIME, offsetof(struct paca_struct, user_time));
DEFINE(PACA_SYSTEM_TIME, offsetof(struct paca_struct, system_time));
+ DEFINE(PACA_SLBSHADOWPTR, offsetof(struct paca_struct, slb_shadow_ptr));
DEFINE(LPPACASRR0, offsetof(struct lppaca, saved_srr0));
DEFINE(LPPACASRR1, offsetof(struct lppaca, saved_srr1));
DEFINE(LPPACAANYINT, offsetof(struct lppaca, int_dword.any_int));
DEFINE(LPPACADECRINT, offsetof(struct lppaca, int_dword.fields.decr_int));
+
+ DEFINE(SLBSHADOW_STACKVSID,
+ offsetof(struct slb_shadow, save_area[SLB_NUM_BOLTED - 1].vsid));
+ DEFINE(SLBSHADOW_STACKESID,
+ offsetof(struct slb_shadow, save_area[SLB_NUM_BOLTED - 1].esid));
#endif /* CONFIG_PPC64 */
/* RTAS */
Index: linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/entry_64.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
@@ -375,6 +375,14 @@ BEGIN_FTR_SECTION
ld r7,KSP_VSID(r4) /* Get new stack's VSID */
oris r0,r6,(SLB_ESID_V)@h
ori r0,r0,(SLB_NUM_BOLTED-1)@l
+
+ /* Update the last bolted SLB */
+ ld r9,PACA_SLBSHADOWPTR(r13)
+ li r12,0
+ std r12,SLBSHADOW_STACKESID(r9) /* Clear ESID */
+ std r7,SLBSHADOW_STACKVSID(r9) /* Save VSID */
+ std r0,SLBSHADOW_STACKESID(r9) /* Save ESID */
+
slbie r6
slbie r6 /* Workaround POWER5 < DD2.1 issue */
slbmte r7,r0
Index: linux-2.6-ozlabs/arch/powerpc/kernel/paca.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/paca.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/paca.c
@@ -17,6 +17,7 @@
#include <asm/lppaca.h>
#include <asm/iseries/it_lp_reg_save.h>
#include <asm/paca.h>
+#include <asm/mmu.h>
/* This symbol is provided by the linker - let it fill in the paca
@@ -45,6 +46,17 @@ struct lppaca lppaca[] = {
},
};
+/*
+ * 3 persistent SLBs are registered here. The buffer will be zero
+ * initially, hence will all be invaild until we actually write them.
+ */
+struct slb_shadow slb_shadow[] __cacheline_aligned = {
+ [0 ... (NR_CPUS-1)] = {
+ .persistent = SLB_NUM_BOLTED,
+ .buffer_length = sizeof(struct slb_shadow),
+ },
+};
+
/* The Paca is an array with one entry per processor. Each contains an
* lppaca, which contains the information shared between the
* hypervisor and Linux.
@@ -59,7 +71,8 @@ struct lppaca lppaca[] = {
.lock_token = 0x8000, \
.paca_index = (number), /* Paca Index */ \
.kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL, \
- .hw_cpu_id = 0xffff,
+ .hw_cpu_id = 0xffff, \
+ .slb_shadow_ptr = &slb_shadow[number],
#ifdef CONFIG_PPC_ISERIES
#define PACA_INIT_ISERIES(number) \
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -22,6 +22,8 @@
#include <asm/paca.h>
#include <asm/cputable.h>
#include <asm/cacheflush.h>
+#include <asm/smp.h>
+#include <linux/compiler.h>
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
@@ -50,9 +52,32 @@ static inline unsigned long mk_vsid_data
return (get_kernel_vsid(ea) << SLB_VSID_SHIFT) | flags;
}
-static inline void create_slbe(unsigned long ea, unsigned long flags,
- unsigned long entry)
+static inline void slb_shadow_update(unsigned long esid, unsigned long vsid,
+ unsigned long entry)
{
+ /*
+ * Clear the ESID first so the entry is not valid while we are
+ * updating it.
+ */
+ get_slb_shadow()->save_area[entry].esid = 0;
+ barrier();
+ get_slb_shadow()->save_area[entry].vsid = vsid;
+ barrier();
+ get_slb_shadow()->save_area[entry].esid = esid;
+
+}
+
+static inline void create_shadowed_slbe(unsigned long ea, unsigned long flags,
+ unsigned long entry)
+{
+ /*
+ * Updating the shadow buffer before writing the SLB ensures
+ * we don't get a stale entry here if we get preempted by PHYP
+ * between these two statements.
+ */
+ slb_shadow_update(mk_esid_data(ea, entry), mk_vsid_data(ea, flags),
+ entry);
+
asm volatile("slbmte %0,%1" :
: "r" (mk_vsid_data(ea, flags)),
"r" (mk_esid_data(ea, entry))
@@ -77,6 +102,10 @@ void slb_flush_and_rebolt(void)
if ((ksp_esid_data & ESID_MASK) == PAGE_OFFSET)
ksp_esid_data &= ~SLB_ESID_V;
+ /* Only third entry (stack) may change here so only resave that */
+ slb_shadow_update(ksp_esid_data,
+ mk_vsid_data(ksp_esid_data, lflags), 2);
+
/* We need to do this all in asm, so we're sure we don't touch
* the stack between the slbia and rebolting it. */
asm volatile("isync\n"
@@ -209,9 +238,9 @@ void slb_initialize(void)
asm volatile("isync":::"memory");
asm volatile("slbmte %0,%0"::"r" (0) : "memory");
asm volatile("isync; slbia; isync":::"memory");
- create_slbe(PAGE_OFFSET, lflags, 0);
+ create_shadowed_slbe(PAGE_OFFSET, lflags, 0);
- create_slbe(VMALLOC_START, vflags, 1);
+ create_shadowed_slbe(VMALLOC_START, vflags, 1);
/* We don't bolt the stack for the time being - we're in boot,
* so the stack is in the bolted segment. By the time it goes
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/lpar.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
@@ -254,18 +254,34 @@ out:
void vpa_init(int cpu)
{
int hwcpu = get_hard_smp_processor_id(cpu);
- unsigned long vpa = __pa(&lppaca[cpu]);
+ unsigned long addr;
long ret;
if (cpu_has_feature(CPU_FTR_ALTIVEC))
lppaca[cpu].vmxregs_in_use = 1;
- ret = register_vpa(hwcpu, vpa);
+ addr = __pa(&lppaca[cpu]);
+ ret = register_vpa(hwcpu, addr);
- if (ret)
+ if (ret) {
printk(KERN_ERR "WARNING: vpa_init: VPA registration for "
"cpu %d (hw %d) of area %lx returns %ld\n",
- cpu, hwcpu, vpa, ret);
+ cpu, hwcpu, addr, ret);
+ return;
+ }
+ /*
+ * PAPR says this feature is SLB-Buffer but firmware never
+ * reports that. All SPLPAR support SLB shadow buffer.
+ */
+ addr = __pa(&slb_shadow[cpu]);
+ if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
+ ret = register_slb_shadow(hwcpu, addr);
+ if (ret)
+ printk(KERN_ERR
+ "WARNING: vpa_init: SLB shadow buffer "
+ "registration for cpu %d (hw %d) of area %lx "
+ "returns %ld\n", cpu, hwcpu, addr, ret);
+ }
}
long pSeries_lpar_hpte_insert(unsigned long hpte_group,
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/plpar_wrappers.h
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/plpar_wrappers.h
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/plpar_wrappers.h
@@ -40,6 +40,16 @@ static inline long register_vpa(unsigned
return vpa_call(0x1, cpu, vpa);
}
+static inline long unregister_slb_shadow(unsigned long cpu, unsigned long vpa)
+{
+ return vpa_call(0x7, cpu, vpa);
+}
+
+static inline long register_slb_shadow(unsigned long cpu, unsigned long vpa)
+{
+ return vpa_call(0x3, cpu, vpa);
+}
+
extern void vpa_init(int cpu);
static inline long plpar_pte_remove(unsigned long flags, unsigned long ptex,
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/setup.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/setup.c
@@ -234,9 +234,17 @@ static void pseries_kexec_cpu_down_xics(
{
/* Don't risk a hypervisor call if we're crashing */
if (firmware_has_feature(FW_FEATURE_SPLPAR) && !crash_shutdown) {
- unsigned long vpa = __pa(get_lppaca());
+ unsigned long addr;
- if (unregister_vpa(hard_smp_processor_id(), vpa)) {
+ addr = __pa(get_slb_shadow());
+ if (unregister_slb_shadow(hard_smp_processor_id(), addr))
+ printk("SLB shadow buffer deregistration of "
+ "cpu %u (hw_cpu_id %d) failed\n",
+ smp_processor_id(),
+ hard_smp_processor_id());
+
+ addr = __pa(get_lppaca());
+ if (unregister_vpa(hard_smp_processor_id(), addr)) {
printk("VPA deregistration of cpu %u (hw_cpu_id %d) "
"failed\n", smp_processor_id(),
hard_smp_processor_id());
Index: linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/lppaca.h
+++ linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
@@ -27,7 +27,9 @@
//
//
//----------------------------------------------------------------------------
+#include <linux/cache.h>
#include <asm/types.h>
+#include <asm/mmu.h>
/* The Hypervisor barfs if the lppaca crosses a page boundary. A 1k
* alignment is sufficient to prevent this */
@@ -133,5 +135,22 @@ struct lppaca {
extern struct lppaca lppaca[];
+/*
+ * SLB shadow buffer structure as defined in the PAPR. The save_area
+ * contains adjacent ESID and VSID pairs for each shadowed SLB. The
+ * ESID is stored in the lower 64bits, then the VSID.
+ */
+struct slb_shadow {
+ u32 persistent; /* Number of persistent SLBs x00-x03 */
+ u32 buffer_length; /* Total shadow buffer length x04-x07 */
+ u64 reserved; /* Alignment x08-x0f */
+ struct {
+ u64 esid;
+ u64 vsid;
+ } save_area[SLB_NUM_BOLTED]; /* Actual SLB Save buffer x10-x40 */
+} ____cacheline_aligned;
+
+extern struct slb_shadow slb_shadow[];
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_LPPACA_H */
Index: linux-2.6-ozlabs/include/asm-powerpc/paca.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/paca.h
+++ linux-2.6-ozlabs/include/asm-powerpc/paca.h
@@ -23,6 +23,7 @@
register struct paca_struct *local_paca asm("r13");
#define get_paca() local_paca
#define get_lppaca() (get_paca()->lppaca_ptr)
+#define get_slb_shadow() (get_paca()->slb_shadow_ptr)
struct task_struct;
@@ -98,6 +99,8 @@ struct paca_struct {
u64 user_time; /* accumulated usermode TB ticks */
u64 system_time; /* accumulated system TB ticks */
u64 startpurr; /* PURR/TB value snapshot */
+
+ struct slb_shadow *slb_shadow_ptr;
};
extern struct paca_struct paca[];
^ permalink raw reply
* Re: [RFC] Debugging with a HW probe.
From: Paul Mackerras @ 2006-08-08 4:48 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <E1G9jpY-0004Nv-2d@kmac.watson.ibm.com>
Jimi Xenidis writes:
> +static noinline void xmon_hw_probe(void)
> +{
> + if (!xmon_hw_probe_enabled)
> + return;
> + ATTN();
> +}
I can't see how we can get to call this routine with
xmon_hw_probe_enabled equal to 0... What am I missing?
Paul.
^ permalink raw reply
* Re: [PATCH] fix for firewire patch added in 2.6.17.2 that breaks things on ppc
From: Paul Mackerras @ 2006-08-08 5:05 UTC (permalink / raw)
To: danny; +Cc: linuxppc-dev
In-Reply-To: <20060807063854.B641@luna.ellen.dexterslabs.com>
danny@mailmij.org writes:
> -#endif
> -
> +#else
> pci_save_state(pdev);
> -
> +#endif /* CONFIG_PPC_PMAC */
Shouldn't we just move the pci_save_state call up before the
pmac_call_feature() call?
Paul.
^ permalink raw reply
* Re: [PATCH] fix for firewire patch added in 2.6.17.2 that breaks things on ppc
From: danny @ 2006-08-08 5:37 UTC (permalink / raw)
To: Paul Mackerras; +Cc: danny, linuxppc-dev
In-Reply-To: <17624.7051.905145.470927@cargo.ozlabs.ibm.com>
On Tue, Aug 08, 2006 at 03:05:15PM +1000, Paul Mackerras wrote:
> danny@mailmij.org writes:
>
> > -#endif
> > -
> > +#else
> > pci_save_state(pdev);
> > -
> > +#endif /* CONFIG_PPC_PMAC */
>
> Shouldn't we just move the pci_save_state call up before the
> pmac_call_feature() call?
>
I can do a rebuild tonight or so to test this. But since it was working perfectly before I did not see
any reason to keep it.
Danny
^ permalink raw reply
* Re: [RFC] consolidated libdt proposal
From: Haren Myneni @ 2006-08-08 5:37 UTC (permalink / raw)
To: Hollis Blanchard
Cc: Pantelis Antoniou, xen-ppc-devel@lists.xensource.com,
Milton Miller, linuxppc-dev, Sachin P. Sant, linuxppc-embedded
In-Reply-To: <1154987921.24455.32.camel@basalt.austin.ibm.com>
Hollis Blanchard wrote:
>On Sun, 2006-08-06 at 19:38 -0500, Hollis Blanchard wrote:
>
>
>>Hmm, so we'll have at least three copies of this code: uboot, kernel,
>>and Xen. Would it make sense to put this stuff into a libdt.a?
>>Technically, dtc has a "libdt" already, but it's absurdly incomplete
>>(I don't even know why it's there), so we could just replace it.
>>
>>
>
>Mark, I had a look at the code Pantelis wrote for u-boot, and it was
>pretty easy to adapt to meet Xen's (userspace-based) needs. I've
>attached my version below (and see ft_setup() at the bottom of the
>file). Does it meet your requirements for the kernel bootwrapper?
>
>One limitation of the attached code is that it doesn't support changing
>the *size* of properties, though I don't think that would be too
>difficult to add if needed.
>
>Haren, what about using this in kexec-tools?
>
Hollis,
Good idea to have this lib. Based on brief look, some of these funcs
are also useful for kexec-tools. Yes, as you mentioned, changing the
size of properties is important for kexec/kdump.
Present flattened device-tree process in kexec-tools:
- Kexec-tool reads the /proc/device-tree and sort these entries since we
get the different order than the first kernel uses.
- creates linux,usable-memory property under /proc/device-tree/memory@*
as appropriate. (for kdump)
- Modify the reserve map for RTAS, initrd, TCE and (0- crashkernel-start)
- Create initrd properties if not exist in the first kernel as needed
- Modify bootargs property
Thanks
Haren
>If everybody can use this (I expect small modifications would be
>needed), I think we should turn it into a library in the dtc source
>tree. The various projects using it could then include snapshots (to
>avoid dependencies). In general I'd like to avoid everybody writing and
>maintaining their own version of this stuff (myself included).
>
>
>
>------------------------------------------------------------------------
>
>/
>
^ permalink raw reply
* Re: [PATCH] update {g5,iseries,pseries}_defconfigs
From: Paul Mackerras @ 2006-08-08 5:55 UTC (permalink / raw)
To: will_schmidt; +Cc: linuxppc-dev
In-Reply-To: <1154718328.5748.13.camel@farscape.rchland.ibm.com>
Will Schmidt writes:
> +CONFIG_HW_RANDOM=y
This doesn't do us any good. It's annoying that it defaults to Y on
all architectures.
> +# CONFIG_SND_AOA is not set
> +# CONFIG_SND_AOA_SOUNDBUS is not set
We want these on for G5s.
> +# CONFIG_USB_APPLEDISPLAY is not set
And probably this too.
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: fix udbg warning
From: Paul Mackerras @ 2006-08-08 5:57 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev
In-Reply-To: <44D68EAE.5010308@am.sony.com>
Geoff Levand writes:
> Here's an updated version that fixes a few more warnings.
I get:
fatal: corrupt patch at line 12
* Patch failed.
from git-applymbox when I try to apply it. It looks like your mailer
turns lines that contain only whitespace into empty lines. Please fix
it or use a different mailer.
Paul.
^ permalink raw reply
* Umount reiserfs partition caused crash on 2.6.18-rc3-mm2
From: Lei CL Cheng @ 2006-08-08 5:57 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3100 bytes --]
Hi,
I installed latest mm kernel 2.6.18-rc3-mm2 on ppc64 with RHEL4-U3.
And I made a reiserfs partition by mkfs command in this kernel.
But when I tried to umount this reiserfs partition, the kernel
crashed and xmon will be entered.
the steps:
1. mkfs -t reiserfs -f --format 3.6 /dev/sdb
2. mount /dev/sdb /mnt/tmp
3. umount /mnt/tmp
Additional information:
./mkreiserfs -V
mkreiserfs 3.6.19 (2003 www.namesys.com)
The error message printed by xmon is like:
---------------------------------------------
BUG: Dentry c0000000718178a0{i=3,n=.reiserfs_priv} still in use (1)
[unmount
of reiserfs sdb]
kernel BUG in shrink_dcache_for_umount_subtree at fs/dcache.c:611!
cpu 0x3: Vector: 700 (Program Check) at [c0000001667ef690]
pc: c0000000000e06cc: .shrink_dcache_for_umount_subtree+0x214/0x364
lr: c0000000000e06c8: .shrink_dcache_for_umount_subtree+0x210/0x364
sp: c0000001667ef910
msr: 8000000000029032
current = 0xc00000007180b040
paca = 0xc000000000567800
pid = 5220, comm = umount
kernel BUG in shrink_dcache_for_umount_subtree at fs/dcache.c:611!
enter ? for help
2:mon> t
[c0000001667ef9a0] c0000000000e086c .shrink_dcache_for_umount+0x50/0x78
[c0000001667efa20] c0000000000c9c74 .generic_shutdown_super+0x40/0x230
[c0000001667efab0] c0000000000cb07c .kill_block_super+0x30/0x60
[c0000001667efb40] c0000000000c9be0 .deactivate_super+0x8c/0xe0
[c0000001667efbd0] c0000000000e69e8 .mntput_no_expire+0x84/0xcc
[c0000001667efc60] c0000000000d36c4 .path_release_on_umount+0x30/0x48
[c0000001667efcf0] c0000000000e75dc .sys_umount+0x264/0x294
[c0000001667efe30] c00000000000861c syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000ff31f84
SP (ffca1750) is in userspace
2:mon> r
R00 = c0000000000e06c8 R16 = 00000000ffffffff
R01 = c0000001667ef910 R17 = 0000000010020000
R02 = c000000000748448 R18 = 0000000000000000
R03 = 0000000000000061 R19 = 00000000ffca1df8
R04 = 8000000000001032 R20 = 0000000000000000
R05 = 0000000000000000 R21 = 0000000000000000
R06 = 8000000000b10393 R22 = 00000000100c0000
R07 = 0000000000000000 R23 = 0000000000000000
R08 = 0000000000000001 R24 = 0000000000000000
R09 = c000000000594660 R25 = 0000000000000000
R10 = c00000016763bbd8 R26 = c0000001667efdf0
R11 = c000000000594660 R27 = 0000000000000000
R12 = 0000000000004000 R28 = c000000169e0f800
R13 = c000000000567800 R29 = c000000071817980
R14 = 00000000ffca18d0 R30 = c0000000005bd348
R15 = 0000000010020000 R31 = c0000000718178a0
pc = c0000000000e06cc .shrink_dcache_for_umount_subtree+0x214/0x364
lr = c0000000000e06c8 .shrink_dcache_for_umount_subtree+0x210/0x364
msr = 8000000000029032 cr = 24004424
ctr = 8000000000132d10 xer = 000000000000000f trap = 700
2:mon> S
msr = 8000000000001032 sprg0= 0000000000000000
pvr = 00000000003a0201 sprg1= c000000000567600
dec = 00000000ad4830a1 sprg2= c000000000567600
sp = c00000016691ad50 sprg3= c000000000567600
toc = c000000000748448 dar = c000000071794010
-Thanks
[-- Attachment #2: Type: text/html, Size: 5424 bytes --]
^ permalink raw reply
* Re: PATCH: Enable PCI by default on PPC_86xx boards
From: Paul Mackerras @ 2006-08-08 6:17 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154378023.5107.39.camel@cashmere.sps.mot.com>
Jon Loeliger writes:
> config PCI
> - bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx ||
> PPC_MPC52xx || (EMBEDDED && PPC_ISERIES) \
> - || MPC7448HPC2
> - default y if !40x && !CPM2 && !8xx && !APUS && !PPC_83xx && !PPC_85xx
> && !PPC_86xx
> + bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx
> \
> + || PPC_MPC52xx || (EMBEDDED && PPC_ISERIES) || MPC7448HPC2
> + default y if !40x && !CPM2 && !8xx && !APUS && !PPC_83xx \
> + && !PPC_85xx && !PPC_86xx
I see how that means we offer PCI if PPC_86xx, but I don't see how
that enables it by default... All you've done to the default y line
is to stick backslash-newline-whitespace in the middle.
(Patch is linewrapped, by the way.)
Paul.
^ permalink raw reply
* Re: [PATCH] cputable: Correct IBM/750CXe rev3.x setup
From: Paul Mackerras @ 2006-08-08 7:03 UTC (permalink / raw)
To: Nicolas DET; +Cc: akpm, linuxppc-dev
In-Reply-To: <20060806104200.49c5f6bf.nicolas@det-net.org>
Nicolas DET writes:
> This patch simply add an entry in the cputable to recognize
> correctly the IBM750CXe rev3.1. Only rev 2.x was correctly detected
> before.
[Patch annoyingly as an attachment...]
+ { /* 750CXe rev 3.1 (0008x311) */
+ .pvr_mask = 0xffff0fff,
+ .pvr_value = 0x00080311,
+ .cpu_name = "750CXe",
Any reason to make this so specific? The rest of the entry is
identical to the ones we have for PVR values 0x0008221x and
0x00083214 (except that you missed out PPC_FEATURE_PPC_LE).
It looks to me like we could collapse all three into a single entry
with a suitable pvr_mask value (say 0xffff0e00?).
(akpm - consider this a nack)
Paul.
^ permalink raw reply
* RE: [PATCH] powerpc: Add tsi108/9 and new hardware interface to mpic
From: Zang Roy-r61911 @ 2006-08-08 7:06 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt
Cc: linuxppc-dev list, Stewart Katherine-ra4863, Alexandre.Bounine,
Yang Xin-Xin-r48390
In-Reply-To: <7EA18FDD2DC2154AA3BD6D2F22A62A0E0456D0@zch01exm23.fsl.freescale.net>
> The patch add new hardware information table for mpic. This=20
> enables mpic
> code=20
> to deal with OpenPIC controller with hardware behavior difference.
> Add TSI108/109 PIC hardware information table. The=20
> Tsi108/109 PIC looks
> like=20
> standard OpenPIC but, in fact, is different in registers mapping and
> behavior.
Hi, Paul
How about the status of this patch?
How about a new hardware entry for mpic?
Where is Ben?
I am still waiting for the feedback.
Roy
^ permalink raw reply
* Re: [PATCH] update {g5,iseries,pseries}_defconfigs
From: Johannes Berg @ 2006-08-08 7:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17624.10083.56514.758904@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
>> +# CONFIG_SND_AOA is not set
>> +# CONFIG_SND_AOA_SOUNDBUS is not set
>>
>
> We want these on for G5s.
>
newer PowerBooks/iBooks as well, and we'll want the new options these
open up, i.e. all the codecs.
Apologies for not updating the defconfigs myself, I just didn't think of
it :/
johannes
^ permalink raw reply
* crosslink build script --- can't find any option for 8241 PPC, what option ought to be choosed
From: alva @ 2006-08-08 7:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
Dear friends,
I recently bought a Synology Network Attached Server DS-106e, run using
a "Linux 2. 4.22-uc-0" Kernel, under 8041 PPC, no "gcc" installed. I
want to build a crosslink gcc compiler for it in another "debian 2.6
kernel" linux. I find many options in the crosslink build script on ppc,
but can't find any option for 8041 PPC. So what option should I choose?
And further can I put the artifacts just compiled in my Network Attached
Server? So that I can compile anything directly in my NAS.
Many Thanks,
Roy
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.7/411 - Release Date: 2006/8/7
[-- Attachment #2: Type: text/html, Size: 1615 bytes --]
^ permalink raw reply
* Re: [RFC] consolidated libdt proposal
From: Pantelis Antoniou @ 2006-08-08 9:34 UTC (permalink / raw)
To: Haren Myneni
Cc: Hollis Blanchard, xen-ppc-devel@lists.xensource.com,
Milton Miller, linuxppc-dev, Sachin P. Sant, linuxppc-embedded
In-Reply-To: <44D8230F.4020202@us.ibm.com>
On 08 =CE=91=CF=85=CE=B3 2006, at 8:37 =CE=A0=CE=9C, Haren Myneni wrote:
> Hollis Blanchard wrote:
>
>> On Sun, 2006-08-06 at 19:38 -0500, Hollis Blanchard wrote:
>>
>>> Hmm, so we'll have at least three copies of this code: uboot, =20
>>> kernel,
>>> and Xen. Would it make sense to put this stuff into a libdt.a?
>>> Technically, dtc has a "libdt" already, but it's absurdly incomplete
>>> (I don't even know why it's there), so we could just replace it.
>>
>> Mark, I had a look at the code Pantelis wrote for u-boot, and it was
>> pretty easy to adapt to meet Xen's (userspace-based) needs. I've
>> attached my version below (and see ft_setup() at the bottom of the
>> file). Does it meet your requirements for the kernel bootwrapper?
>>
>> One limitation of the attached code is that it doesn't support =20
>> changing
>> the *size* of properties, though I don't think that would be too
>> difficult to add if needed.
>>
>> Haren, what about using this in kexec-tools?
>>
>
> Hollis,
> Good idea to have this lib. Based on brief look, some of these =20
> funcs are also useful for kexec-tools. Yes, as you mentioned, =20
> changing the size of properties is important for kexec/kdump.
>
> Present flattened device-tree process in kexec-tools:
>
> - Kexec-tool reads the /proc/device-tree and sort these entries =20
> since we get the different order than the first kernel uses.
> - creates linux,usable-memory property under /proc/device-tree/=20
> memory@* as appropriate. (for kdump)
> - Modify the reserve map for RTAS, initrd, TCE and (0- crashkernel-=20
> start)
> - Create initrd properties if not exist in the first kernel as needed
> - Modify bootargs property
>
> Thanks
> Haren
>
Hi Haren,
Mind writing down what your requirements are? Just modifying the size =20=
of the properties?
Note that my functions work in a two phases.
In the first phase the tree is build with the string table being put =20
at the end
of the allocated memory area in a downward motion.
When the tree is finalized the string table is memmov'ed to be =20
adjacent to the structure
proper.
Could you use this two phased approach for you uses? I.e. first work =20
with maximum sized
properties and perform a move & fixup stage when finalizing?
Regards
Pantelis
>> If everybody can use this (I expect small modifications would be
>> needed), I think we should turn it into a library in the dtc source
>> tree. The various projects using it could then include snapshots (to
>> avoid dependencies). In general I'd like to avoid everybody =20
>> writing and
>> maintaining their own version of this stuff (myself included).
>>
>>
>> ---------------------------------------------------------------------=20=
>> ---
>>
>> /
>>
>
^ permalink raw reply
* 852T: Problem getting traffic out FEC interface using vlan
From: Keith Redfern @ 2006-08-08 12:34 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 5982 bytes --]
The system that I am using is as follows.....
Embedded Linux on a Motorola 852T processor with FEC support. Embedded
Planet BSP
Software that runs on the embedded processor to send UDP packets, via
the FEC port (eth1), to a PC.
This PC is directly linked to the FEC port with a cable and is running
etherpeek.
Software that runs on the embedded processor to listen to all received
traffic at the FEC (uses RAW packet socket).
802.1q Support has been enabled in the kernel. 802.1Q VLAN Support v1.8
Ben Greear <greearb@candelatech.com>
The vlan configuration that I am applying is ......
> ifconfig eth1 down
> ifconfig eth1 0.0.0.0 up
> vconfig add eth1 2
> ifconfig eth1.2 192.168.2.2 up
After this is done ifconfig returns the following .....
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:EC:00:52:FC
inet addr:10.226.210.86 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:210599 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:20804624 (19.8 MiB) TX bytes:0 (0.0 B)
Base address:0x3e00
eth1 Link encap:Ethernet HWaddr 00:10:EC:80:52:FC
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:64 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:9055 (8.8 KiB) TX bytes:365 (365.0 B)
Base address:0xe00
eth1.2 Link encap:Ethernet HWaddr 00:10:EC:80:52:FC
inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:276 (276.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:122 (122.0 B) TX bytes:122 (122.0 B)
Running the raw packet analyzing program in the background (dumps bytes
to screen) and then invoking the UDP send program (INET, SOCK_DGRAM
socket) to send UDP packets to the pc running etherpeek, I see the
following ........
# udpSend 192.168.2.1 jjjj
udpSend: sending data to '192.168.2.1' (IP : 192.168.2.1)
# ff ff ff ff ff ff 00 10 ec 80
52 fc 08 06 00 01 08 00 06 04
00 01 00 10 ec 80 52 fc c0 a8
02 02 00 00 00 00 00 00 c0 a8
02 01
Waiting for packets
Pkt Received of length 46:
ff ff ff ff ff ff 00 10 ec 80
52 fc 81 00 00 02 08 06 00 01
08 00 06 04 00 01 00 10 ec 80
52 fc c0 a8 02 02 00 00 00 00
00 00 c0 a8 02 01
Waiting for packets
ff ff ff ff ff ff 00 10 ec 80
52 fc 08 06 00 01 08 00 06 04
00 01 00 10 ec 80 52 fc c0 a8
02 02 00 00 00 00 00 00 c0 a8
02 01
Waiting for packets
Pkt Received of length 46:
ff ff ff ff ff ff 00 10 ec 80
52 fc 81 00 00 02 08 06 00 01
08 00 06 04 00 01 00 10 ec 80
52 fc c0 a8 02 02 00 00 00 00
00 00 c0 a8 02 01
Waiting for packets
ff ff ff ff ff ff 00 10 ec 80
52 fc 08 06 00 01 08 00 06 04
00 01 00 10 ec 80 52 fc c0 a8
02 02 00 00 00 00 00 00 c0 a8
02 01
Waiting for packets
Pkt Received of length 46:
ff ff ff ff ff ff 00 10 ec 80
52 fc 81 00 00 02 08 06 00 01
08 00 06 04 00 01 00 10 ec 80
52 fc c0 a8 02 02 00 00 00 00
00 00 c0 a8 02 01
Waiting for packets
Etherpeek doesn't show any info being received and the raw packet
analyzing program shows that the ARP and Vlan tagged ARP packets are
being seen on the receive side of the raw socket.
The stats show that info is being transmitted out eth1.2 and the lo
stats increase in the rx and tx counts. The eth1 stats stay constant.
The counts you see in eth1 are from being previously configured and
sending/receiving data.
I expect VLAN tagged ARP packets to be seen at etherpeek but understand
that the UDP packet will not be seen as the pc interface has not setup
to be vlan tagged. Can anyone shed some light on what is going on here?
Are there problems with my vconfig/ifconfig settings? Are there hardware
problems that mean this can't be done?
......... Keith R
Legal Disclaimer:
The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message
[-- Attachment #2: Type: text/html, Size: 31515 bytes --]
^ permalink raw reply
* Re: crosslink build script --- can't find any option for 8241 PPC, what option ought to be choosed
From: Kumar Gala @ 2006-08-08 13:04 UTC (permalink / raw)
To: alva; +Cc: linuxppc-embedded
In-Reply-To: <000001c6babc$0e795b10$8500a8c0@dc.roysiu.servebbs.com>
On Aug 8, 2006, at 2:26 AM, alva wrote:
> Dear friends,
>
> I recently bought a Synology Network Attached Server DS-106e, run
> using a "Linux 2. 4.22-uc-0" Kernel, under 8041 PPC, no "gcc"
> installed. I want to build a crosslink gcc compiler for it in
> another "debian 2.6 kernel" linux. I find many options in the
> crosslink build script on ppc, but can't find any option for 8041
> PPC. So what option should I choose? And further can I put the
> artifacts just compiled in my Network Attached Server? So that I
> can compile anything directly in my NAS.
>
I assume you mean 8241 like the subject says since there is no 8041
PPC. If so you want an 603 toolchain.
- k
^ permalink raw reply
* "Function not implemented" error with syslogd
From: Christopher Dumoulin @ 2006-08-08 13:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I've got an embedded linux system running on a V2Pro-based devlopment
board, using a 2.6 kernel and ramdisk based on ELDK 4.0.
I'm trying to get syslogd running so I can log printk output to
/var/log/messages. I'm using a Busybox syslogd that was included in the
ELDK 4.0 ramdisk image. When I try to start syslogd, I get the following
error:
syslogd: Couldn't get file descriptor for socket /dev/log: Function not
implemented
The file /dev/log didn't exist, so I tried to create it with the
following command, but that doesn't seem to make a difference:
mknod -m 660 /dev/log p
I'm assuming that syslogd does a 'socket' call, which is returning
ENOSYS. Any ideas about what is going on, or how I can get it working,
would be appreciated.
Regards,
Chris Dumoulin
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ 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