* Re: name created by rpmbuild
From: Wolfgang Denk @ 2005-11-14 9:38 UTC (permalink / raw)
To: debora liu; +Cc: Linuxppc-embedded
In-Reply-To: <200511141320468.SM01124@debora-liu>
In message <200511141320468.SM01124@debora-liu> you wrote:
>
> I'm using rpmbuild, but it creat rpm packet name is "NAME-ppc_8xx-VERSION-RELEASE.ppc.rpm",
> I think it should is "NAME-VERSION-RELEASE.ppc.rpm", true?
> I use native rpmbuild on my board with eldk-3.1.1 PPC8xx NFS root.
You asked the same question just two days ago. Why do you ask again?
I replied:
------- Forwarded Message
Date: Sat, 12 Nov 2005 13:52:56 +0100
From: Wolfgang Denk <wd@denx.de>
To: deboralh@fel.com.cn
Subject: Re: packet name created by rpmbuild
In message <200511121759781.SM00928@RavProxy> you wrote:
> >
> Sorry, this is text
Thanks.
> I'm using rpmbuild, but it creat rpm packet name is "NAME-ppc_8xx-VERSION-REL
EASE.ppc.rpm",
> I think it should is "NAME-VERSION-RELEASE.ppc.rpm", true?
No, wrong. "*.ppc.rpm" indicates a "standard" RPM from some Linux
distribution, like a Fedora Core PowerPC RPM. Such an RPM will NOT
run on your MPC8xx system, and your ppc_8xx created RPM will not run
on a Fedora Core PowerPC system. Differences are caused for example
by support for a FPU and adjustment for different cache line sizes.
To avoid confusion, MPC8xx specific RPMs are created using a special
name which makes clear that they are compatible with the ELDK RPMs,
but not with other PowerPC RPMs.
> I use native rpmbuild on my board with eldk-3.1.1 PPC8xx NFS root.
Native rpmbuild and cross rpmbuild are compatible with each other,
but not with RPMs from other PowerPC Linux distributions.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Where people stand is not as important as which way they face.
- Terry Pratchett & Stephen Briggs, _The Discworld Companion_
------- End of Forwarded Message
^ permalink raw reply
* Re: MPC8272 + kernel
From: Vitaly Bordug @ 2005-11-14 8:19 UTC (permalink / raw)
To: srideep.devireddy; +Cc: linuxppc-embedded
In-Reply-To: <6AD9F6A5F6E096408F0B703773355A07605E5D@CHN-SNR-MBX01.wipro.com>
srideep.devireddy@wipro.com wrote:
> Hi Sir ,
>
>
>
> With the help of mailing list I am able to get my u-boot 1.1.3
> version … right held up with kernel
>
> ….
>
> I am able to boot my MPC8272ADS with u-boot 1.1.3 version . how can
> build my uImaze(compressed linux image so that I can boot it ) ,what are
> the options .. I got the source from Montavista BSP for MPC 8272 .. so
> can you guide me in making a compressed image so that I can boot my
> Linux kernel .
>
>
>
> As of now I am getting and error of
>
>
>
> ## Booting image at 01000000 ...
>
>
>
> Image Name: Linux-2.4.22
>
>
>
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
>
>
>
> Data Size: 782360 Bytes = 764 kB
>
>
>
> Load Address: 00000000
>
>
>
> Entry Point: 00000000
>
>
>
> Verifying Checksum ... OK
>
>
>
> Uncompressing Kernel Image ... OK
>
>
>
>
>
> That’s it ... kernel hangs .. why is this ? can you kindly help me
> resolving in the issue
>
Do you have console=ttyCPM0,115200 in your bootargs? Anyway, what kernel
(version) is used, what config file?
The output of the u-boot printenv command will be helpful as well.
>
>
>
>
> Best Regards
>
>
>
>
>
> Confidentiality Notice
>
> The information contained in this electronic message and any attachments
> to this message are intended
> for the exclusive use of the addressee(s) and may contain confidential
> or privileged information. If
> you are not the intended recipient, please notify the sender at Wipro or
> Mailadmin@wipro.com immediately
> and destroy all copies of this message and any attachments.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Benjamin Herrenschmidt @ 2005-11-14 8:06 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: linuxppc-dev, debian-powerpc@lists.debian.org
In-Reply-To: <200511140819.42439.arekm@pld-linux.org>
On Mon, 2005-11-14 at 08:19 +0100, Arkadiusz Miskiewicz wrote:
> On Friday 11 November 2005 22:52, Benjamin Herrenschmidt wrote:
> > The latest patch that is candidate for upstream is:
>
> Oopsed for one pld user in a way shown in attachment after connecting usb
> device while laptop (recent ibook g4 afaik) was in sleep and then waking it
> up. That was with 2.6.14.2+your patch.
Ok, so there are still unresolved issues in the USB layer, which doesn't
surprise me. I'm trying to work with the USB folks to get those resolved
in 2.6.15 at least, we'll see if I succeed...
Ben.
^ permalink raw reply
* [PATCH] powerpc: Merge align.c
From: Benjamin Herrenschmidt @ 2005-11-14 8:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev list
Need testing !!!
This patch merges align.c, the result isn't quite what was in ppc64 nor
what was in ppc32 :) It should implement all the functionalities of both
though. Kumar, since you played with that in the past, I suppose you
have some test cases for verifying that it works properly before I dig
out the 601 machine ? :)
Since it's likely that I won't be able to test all scenario, code
inspection is much welcome.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/kernel/Makefile
===================================================================
--- linux-work.orig/arch/powerpc/kernel/Makefile 2005-11-14 15:17:57.000000000 +1100
+++ linux-work/arch/powerpc/kernel/Makefile 2005-11-14 17:18:14.000000000 +1100
@@ -12,7 +12,7 @@
endif
obj-y := semaphore.o cputable.o ptrace.o syscalls.o \
- irq.o signal_32.o pmc.o vdso.o
+ irq.o align.o signal_32.o pmc.o vdso.o
obj-y += vdso32/
obj-$(CONFIG_PPC64) += setup_64.o binfmt_elf32.o sys_ppc32.o \
signal_64.o ptrace32.o systbl.o \
Index: linux-work/arch/powerpc/kernel/align.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/kernel/align.c 2005-11-14 18:41:22.000000000 +1100
@@ -0,0 +1,513 @@
+/* align.c - handle alignment exceptions for the Power PC.
+ *
+ * Copyright (c) 1996 Paul Mackerras <paulus@cs.anu.edu.au>
+ * Copyright (c) 1998-1999 TiVo, Inc.
+ * PowerPC 403GCX modifications.
+ * Copyright (c) 1999 Grant Erickson <grant@lcse.umn.edu>
+ * PowerPC 403GCX/405GP modifications.
+ * Copyright (c) 2001-2002 PPC64 team, IBM Corp
+ * 64-bit and Power4 support
+ * Copyright (c) 2005 Benjamin Herrenschmidt, IBM Corp
+ * <benh@kernel.crashing.org>
+ * Merge ppc32 and ppc64 implementations
+ *
+ * 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 <linux/kernel.h>
+#include <linux/mm.h>
+#include <asm/processor.h>
+#include <asm/uaccess.h>
+#include <asm/system.h>
+#include <asm/cache.h>
+#include <asm/cputable.h>
+
+struct aligninfo {
+ unsigned char len;
+ unsigned char flags;
+};
+
+#define IS_XFORM(inst) (((inst) >> 26) == 31)
+#define IS_DSFORM(inst) (((inst) >> 26) >= 56)
+
+#define INVALID { 0, 0 }
+
+#define LD 1 /* load */
+#define ST 2 /* store */
+#define SE 4 /* sign-extend value */
+#define F 8 /* to/from fp regs */
+#define U 0x10 /* update index register */
+#define M 0x20 /* multiple load/store */
+#define SW 0x40 /* byte swap int or ... */
+#define S 0x40 /* ... single-precision fp */
+#define SX 0x40 /* byte count in XER */
+#define HARD 0x80 /* string, stwcx. */
+
+#define DCBZ 0x5f /* 8xx/82xx dcbz faults when cache not enabled */
+
+#define SWAP(a, b) (t = (a), (a) = (b), (b) = t)
+
+/*
+ * The PowerPC stores certain bits of the instruction that caused the
+ * alignment exception in the DSISR register. This array maps those
+ * bits to information about the operand length and what the
+ * instruction would do.
+ */
+static struct aligninfo aligninfo[128] = {
+ { 4, LD }, /* 00 0 0000: lwz / lwarx */
+ INVALID, /* 00 0 0001 */
+ { 4, ST }, /* 00 0 0010: stw */
+ INVALID, /* 00 0 0011 */
+ { 2, LD }, /* 00 0 0100: lhz */
+ { 2, LD+SE }, /* 00 0 0101: lha */
+ { 2, ST }, /* 00 0 0110: sth */
+ { 4, LD+M }, /* 00 0 0111: lmw */
+ { 4, LD+F+S }, /* 00 0 1000: lfs */
+ { 8, LD+F }, /* 00 0 1001: lfd */
+ { 4, ST+F+S }, /* 00 0 1010: stfs */
+ { 8, ST+F }, /* 00 0 1011: stfd */
+ INVALID, /* 00 0 1100 */
+ { 8, LD }, /* 00 0 1101: ld/ldu/lwa */
+ INVALID, /* 00 0 1110 */
+ { 8, ST }, /* 00 0 1111: std/stdu */
+ { 4, LD+U }, /* 00 1 0000: lwzu */
+ INVALID, /* 00 1 0001 */
+ { 4, ST+U }, /* 00 1 0010: stwu */
+ INVALID, /* 00 1 0011 */
+ { 2, LD+U }, /* 00 1 0100: lhzu */
+ { 2, LD+SE+U }, /* 00 1 0101: lhau */
+ { 2, ST+U }, /* 00 1 0110: sthu */
+ { 4, ST+M }, /* 00 1 0111: stmw */
+ { 4, LD+F+S+U }, /* 00 1 1000: lfsu */
+ { 8, LD+F+U }, /* 00 1 1001: lfdu */
+ { 4, ST+F+S+U }, /* 00 1 1010: stfsu */
+ { 8, ST+F+U }, /* 00 1 1011: stfdu */
+ INVALID, /* 00 1 1100 */
+ INVALID, /* 00 1 1101 */
+ INVALID, /* 00 1 1110 */
+ INVALID, /* 00 1 1111 */
+ { 8, LD }, /* 01 0 0000: ldx */
+ INVALID, /* 01 0 0001 */
+ { 8, ST }, /* 01 0 0010: stdx */
+ INVALID, /* 01 0 0011 */
+ INVALID, /* 01 0 0100 */
+ { 4, LD+SE }, /* 01 0 0101: lwax */
+ INVALID, /* 01 0 0110 */
+ INVALID, /* 01 0 0111 */
+ { 4, LD+M+HARD+SX }, /* 01 0 1000: lswx */
+ { 4, LD+M+HARD }, /* 01 0 1001: lswi */
+ { 4, ST+M+HARD+SX }, /* 01 0 1010: stswx */
+ { 4, ST+M+HARD }, /* 01 0 1011: stswi */
+ INVALID, /* 01 0 1100 */
+ { 8, LD+U }, /* 01 0 1101: ldu */
+ INVALID, /* 01 0 1110 */
+ { 8, ST+U }, /* 01 0 1111: stdu */
+ { 8, LD+U }, /* 01 1 0000: ldux */
+ INVALID, /* 01 1 0001 */
+ { 8, ST+U }, /* 01 1 0010: stdux */
+ INVALID, /* 01 1 0011 */
+ INVALID, /* 01 1 0100 */
+ { 4, LD+SE+U }, /* 01 1 0101: lwaux */
+ INVALID, /* 01 1 0110 */
+ INVALID, /* 01 1 0111 */
+ INVALID, /* 01 1 1000 */
+ INVALID, /* 01 1 1001 */
+ INVALID, /* 01 1 1010 */
+ INVALID, /* 01 1 1011 */
+ INVALID, /* 01 1 1100 */
+ INVALID, /* 01 1 1101 */
+ INVALID, /* 01 1 1110 */
+ INVALID, /* 01 1 1111 */
+ INVALID, /* 10 0 0000 */
+ INVALID, /* 10 0 0001 */
+ INVALID, /* 10 0 0010: stwcx. */
+ INVALID, /* 10 0 0011 */
+ INVALID, /* 10 0 0100 */
+ INVALID, /* 10 0 0101 */
+ INVALID, /* 10 0 0110 */
+ INVALID, /* 10 0 0111 */
+ { 4, LD+SW }, /* 10 0 1000: lwbrx */
+ INVALID, /* 10 0 1001 */
+ { 4, ST+SW }, /* 10 0 1010: stwbrx */
+ INVALID, /* 10 0 1011 */
+ { 2, LD+SW }, /* 10 0 1100: lhbrx */
+ { 4, LD+SE }, /* 10 0 1101 lwa */
+ { 2, ST+SW }, /* 10 0 1110: sthbrx */
+ INVALID, /* 10 0 1111 */
+ INVALID, /* 10 1 0000 */
+ INVALID, /* 10 1 0001 */
+ INVALID, /* 10 1 0010 */
+ INVALID, /* 10 1 0011 */
+ INVALID, /* 10 1 0100 */
+ INVALID, /* 10 1 0101 */
+ INVALID, /* 10 1 0110 */
+ INVALID, /* 10 1 0111 */
+ INVALID, /* 10 1 1000 */
+ INVALID, /* 10 1 1001 */
+ INVALID, /* 10 1 1010 */
+ INVALID, /* 10 1 1011 */
+ INVALID, /* 10 1 1100 */
+ INVALID, /* 10 1 1101 */
+ INVALID, /* 10 1 1110 */
+ { 0, ST+HARD }, /* 10 1 1111: dcbz */
+ { 4, LD }, /* 11 0 0000: lwzx */
+ INVALID, /* 11 0 0001 */
+ { 4, ST }, /* 11 0 0010: stwx */
+ INVALID, /* 11 0 0011 */
+ { 2, LD }, /* 11 0 0100: lhzx */
+ { 2, LD+SE }, /* 11 0 0101: lhax */
+ { 2, ST }, /* 11 0 0110: sthx */
+ INVALID, /* 11 0 0111 */
+ { 4, LD+F+S }, /* 11 0 1000: lfsx */
+ { 8, LD+F }, /* 11 0 1001: lfdx */
+ { 4, ST+F+S }, /* 11 0 1010: stfsx */
+ { 8, ST+F }, /* 11 0 1011: stfdx */
+ INVALID, /* 11 0 1100 */
+ { 8, LD+M }, /* 11 0 1101: lmd */
+ INVALID, /* 11 0 1110 */
+ { 8, ST+M }, /* 11 0 1111: stmd */
+ { 4, LD+U }, /* 11 1 0000: lwzux */
+ INVALID, /* 11 1 0001 */
+ { 4, ST+U }, /* 11 1 0010: stwux */
+ INVALID, /* 11 1 0011 */
+ { 2, LD+U }, /* 11 1 0100: lhzux */
+ { 2, LD+SE+U }, /* 11 1 0101: lhaux */
+ { 2, ST+U }, /* 11 1 0110: sthux */
+ INVALID, /* 11 1 0111 */
+ { 4, LD+F+S+U }, /* 11 1 1000: lfsux */
+ { 8, LD+F+U }, /* 11 1 1001: lfdux */
+ { 4, ST+F+S+U }, /* 11 1 1010: stfsux */
+ { 8, ST+F+U }, /* 11 1 1011: stfdux */
+ INVALID, /* 11 1 1100 */
+ INVALID, /* 11 1 1101 */
+ INVALID, /* 11 1 1110 */
+ INVALID, /* 11 1 1111 */
+};
+
+/*
+ * Create a DSISR value from the instruction
+ */
+static inline unsigned make_dsisr(unsigned instr)
+{
+ unsigned dsisr;
+
+
+ /* bits 6:15 --> 22:31 */
+ dsisr = (instr & 0x03ff0000) >> 16;
+
+ if ( IS_XFORM(instr) ) {
+ /* bits 29:30 --> 15:16 */
+ dsisr |= (instr & 0x00000006) << 14;
+ /* bit 25 --> 17 */
+ dsisr |= (instr & 0x00000040) << 8;
+ /* bits 21:24 --> 18:21 */
+ dsisr |= (instr & 0x00000780) << 3;
+ }
+ else {
+ /* bit 5 --> 17 */
+ dsisr |= (instr & 0x04000000) >> 12;
+ /* bits 1: 4 --> 18:21 */
+ dsisr |= (instr & 0x78000000) >> 17;
+ /* bits 30:31 --> 12:13 */
+ if ( IS_DSFORM(instr) )
+ dsisr |= (instr & 0x00000003) << 18;
+ }
+
+ return dsisr;
+}
+
+/*
+ * The dcbz (data cache block zero) instruction
+ * gives an alignment fault if used on non-cacheable
+ * memory. We handle the fault mainly for the
+ * case when we are running with the cache disabled
+ * for debugging.
+ */
+static int emulate_dcbz(struct pt_regs *regs, unsigned char __user *addr)
+{
+ long __user *p;
+ int i, size;
+
+#ifdef __powerpc64__
+ size = ppc64_caches.dline_size;
+#else
+ size = L1_CACHE_BYTES;
+#endif
+ p = (long __user *) (regs->dar & -size);
+ if (user_mode(regs) && !access_ok(VERIFY_WRITE, p, size))
+ return -EFAULT;
+ for (i = 0; i < size / sizeof(long); ++i)
+ if (__put_user(0, p+i))
+ return -EFAULT;
+ return 1;
+}
+
+/*
+ * Emulate load & store multiple instructions
+ */
+static int emulate_multiple(struct pt_regs *regs, unsigned char __user *addr,
+ unsigned int reg, unsigned int nb,
+ unsigned int flags, unsigned int instr)
+{
+ unsigned char *rptr;
+ int nb0, i;
+
+ /*
+ * We do not try to emulate 8 bytes multiple as they aren't really
+ * available in our operating environments and we don't try to
+ * emulate multiples operations in kernel land as they should never
+ * be used/generated there at least not on unaligned boundaries
+ */
+ if (unlikely((nb > 4) || !user_mode(regs)))
+ return 0;
+
+ /* lmw, stmw, lswi/x, stswi/x */
+ nb0 = 0;
+ if (flags & HARD) {
+ if (flags & SX) {
+ nb = regs->xer & 127;
+ if (nb == 0)
+ return 1;
+ } else {
+ if (__get_user(instr,
+ (unsigned int __user *)regs->nip))
+ return -EFAULT;
+ nb = (instr >> 11) & 0x1f;
+ if (nb == 0)
+ nb = 32;
+ }
+ if (nb + reg * 4 > 128) {
+ nb0 = nb + reg * 4 - 128;
+ nb = 128 - reg * 4;
+ }
+ } else {
+ /* lwm, stmw */
+ nb = (32 - reg) * 4;
+ }
+
+ if (!access_ok((flags & ST ? VERIFY_WRITE: VERIFY_READ), addr, nb+nb0))
+ return -EFAULT; /* bad address */
+
+ rptr = (unsigned char *) ®s->gpr[reg];
+ if (flags & LD) {
+ for (i = 0; i < nb; ++i)
+ if (__get_user(rptr[i], addr + i))
+ return -EFAULT;
+ if (nb0 > 0) {
+ rptr = (unsigned char *) ®s->gpr[0];
+ addr += nb;
+ for (i = 0; i < nb0; ++i)
+ if (__get_user(rptr[i], addr + i))
+ return -EFAULT;
+ }
+ for (; (i & 3) != 0; ++i)
+ rptr[i] = 0;
+ } else {
+ for (i = 0; i < nb; ++i)
+ if (__put_user(rptr[i], addr + i))
+ return -EFAULT;
+ if (nb0 > 0) {
+ rptr = (unsigned char *) ®s->gpr[0];
+ addr += nb;
+ for (i = 0; i < nb0; ++i)
+ if (__put_user(rptr[i], addr + i))
+ return -EFAULT;
+ }
+ }
+ return 1;
+}
+
+
+/*
+ * Called on alignment exception. Attempts to fixup
+ *
+ * Return 1 on success
+ * Return 0 if unable to handle the interrupt
+ * Return -EFAULT if data address is bad
+ */
+
+int fix_alignment(struct pt_regs *regs)
+{
+ unsigned int instr, nb, flags;
+ unsigned int reg, areg;
+ unsigned int dsisr;
+ unsigned char __user *addr;
+ unsigned char __user *p;
+ int ret, t;
+ union {
+ long ll;
+ double dd;
+ unsigned char v[8];
+ struct {
+ unsigned hi32;
+ int low32;
+ } x32;
+ struct {
+ unsigned char hi48[6];
+ short low16;
+ } x16;
+ } data;
+
+ /*
+ * We require a complete register set, if not, then our assembly
+ * is broken
+ */
+ CHECK_FULL_REGS(regs);
+
+ dsisr = regs->dsisr;
+
+ /* Some processors don't provide us with a DSISR we can use here,
+ * let's make one up from the instruction
+ */
+ if (cpu_has_feature(CPU_FTR_NODSISRALIGN)) {
+ unsigned int real_instr;
+ if (unlikely(__get_user(real_instr,
+ (unsigned int __user *)regs->nip)))
+ return -EFAULT;
+ dsisr = make_dsisr(real_instr);
+ }
+
+ /* extract the operation and registers from the dsisr */
+ reg = (dsisr >> 5) & 0x1f; /* source/dest register */
+ areg = dsisr & 0x1f; /* register to update */
+ instr = (dsisr >> 10) & 0x7f;
+ instr |= (dsisr >> 13) & 0x60;
+
+ /* Lookup the operation in our table */
+ nb = aligninfo[instr].len;
+ flags = aligninfo[instr].flags;
+
+ /* DAR has the operand effective address */
+ addr = (unsigned char __user *)regs->dar;
+
+ /* A size of 0 indicates an instruction we don't support, with
+ * the exception of DCBZ which is handled as a special case here
+ */
+ if (instr == DCBZ)
+ return emulate_dcbz(regs, addr);
+ if (unlikely(nb == 0))
+ return 0;
+
+ /* Load/Store Multiple instructions are handled in their own
+ * function
+ */
+ if (flags & M)
+ return emulate_multiple(regs, addr, reg, nb, flags, instr);
+
+ /* Verify the address of the operand */
+ if (unlikely(user_mode(regs) &&
+ !access_ok((flags & ST ? VERIFY_WRITE : VERIFY_READ),
+ addr, nb)))
+ return -EFAULT;
+
+ /* Force the fprs into the save area so we can reference them */
+ if (flags & F) {
+ /* userland only */
+ if (unlikely(!user_mode(regs)))
+ return 0;
+ flush_fp_to_thread(current);
+ }
+
+ /* If we are loading, get the data from user space, else
+ * get it from register values
+ */
+ if (flags & LD) {
+ data.ll = 0;
+ ret = 0;
+ p = addr;
+ switch (nb) {
+ case 8:
+ ret |= __get_user(data.v[0], p++);
+ ret |= __get_user(data.v[1], p++);
+ ret |= __get_user(data.v[2], p++);
+ ret |= __get_user(data.v[3], p++);
+ case 4:
+ ret |= __get_user(data.v[4], p++);
+ ret |= __get_user(data.v[5], p++);
+ case 2:
+ ret |= __get_user(data.v[6], p++);
+ ret |= __get_user(data.v[7], p++);
+ if (unlikely(ret))
+ return -EFAULT;
+ }
+ } else if (flags & F)
+ data.dd = current->thread.fpr[reg];
+ else
+ data.ll = regs->gpr[reg];
+
+ /* Perform other misc operations like sign extension, byteswap,
+ * or floating point single precision conversion
+ */
+ switch (flags & ~U) {
+ case LD+SE: /* sign extend */
+ if ( nb == 2 )
+ data.ll = data.x16.low16;
+ else /* nb must be 4 */
+ data.ll = data.x32.low32;
+ break;
+ case LD+S: /* byte-swap */
+ case ST+S:
+ if (nb == 2) {
+ SWAP(data.v[6], data.v[7]);
+ } else {
+ SWAP(data.v[4], data.v[7]);
+ SWAP(data.v[5], data.v[6]);
+ }
+ break;
+
+ /* Single-precision FP load and store require conversions... */
+ case LD+F+S:
+#ifdef CONFIG_PPC_FPU
+ preempt_disable();
+ enable_kernel_fp();
+ cvt_fd((float *)&data.v[4], &data.dd, ¤t->thread);
+ preempt_enable();
+#else
+ return 0;
+#endif
+ break;
+ case ST+F+S:
+#ifdef CONFIG_PPC_FPU
+ preempt_disable();
+ enable_kernel_fp();
+ cvt_df(&data.dd, (float *)&data.v[4], ¤t->thread);
+ preempt_enable();
+#else
+ return 0;
+#endif
+ break;
+ }
+
+ /* Store result to memory or update registers */
+ if (flags & ST) {
+ ret = 0;
+ p = addr;
+ switch (nb) {
+ case 8:
+ ret |= __put_user(data.v[0], p++);
+ ret |= __put_user(data.v[1], p++);
+ ret |= __put_user(data.v[2], p++);
+ ret |= __put_user(data.v[3], p++);
+ case 4:
+ ret |= __put_user(data.v[4], p++);
+ ret |= __put_user(data.v[5], p++);
+ case 2:
+ ret |= __put_user(data.v[6], p++);
+ ret |= __put_user(data.v[7], p++);
+ }
+ if (unlikely(ret))
+ return -EFAULT;
+ } else if (flags & F)
+ current->thread.fpr[reg] = data.dd;
+ else
+ regs->gpr[reg] = data.ll;
+
+ /* Update RA as needed */
+ if (flags & U)
+ regs->gpr[areg] = regs->dar;
+
+ return 1;
+}
Index: linux-work/arch/ppc/kernel/Makefile
===================================================================
--- linux-work.orig/arch/ppc/kernel/Makefile 2005-11-11 10:14:48.000000000 +1100
+++ linux-work/arch/ppc/kernel/Makefile 2005-11-14 18:42:30.000000000 +1100
@@ -13,7 +13,7 @@
extra-y += vmlinux.lds
obj-y := entry.o traps.o idle.o time.o misc.o \
- process.o align.o \
+ process.o \
setup.o \
ppc_htab.o
obj-$(CONFIG_6xx) += l2cr.o cpu_setup_6xx.o
Index: linux-work/arch/ppc64/kernel/Makefile
===================================================================
--- linux-work.orig/arch/ppc64/kernel/Makefile 2005-11-14 15:20:05.000000000 +1100
+++ linux-work/arch/ppc64/kernel/Makefile 2005-11-14 18:42:12.000000000 +1100
@@ -11,9 +11,7 @@
endif
-obj-y += idle.o dma.o \
- align.o \
- iommu.o
+obj-y += idle.o dma.o iommu.o
pci-obj-$(CONFIG_PPC_MULTIPLATFORM) += pci_dn.o pci_direct_iommu.o
Index: linux-work/include/asm-powerpc/cputable.h
===================================================================
--- linux-work.orig/include/asm-powerpc/cputable.h 2005-11-11 10:14:49.000000000 +1100
+++ linux-work/include/asm-powerpc/cputable.h 2005-11-14 18:33:42.000000000 +1100
@@ -90,6 +90,7 @@
#define CPU_FTR_NEED_COHERENT ASM_CONST(0x0000000000020000)
#define CPU_FTR_NO_BTIC ASM_CONST(0x0000000000040000)
#define CPU_FTR_BIG_PHYS ASM_CONST(0x0000000000080000)
+#define CPU_FTR_NODSISRALIGN ASM_CONST(0x0000000000100000)
#ifdef __powerpc64__
/* Add the 64b processor unique features in the top half of the word */
@@ -97,7 +98,6 @@
#define CPU_FTR_16M_PAGE ASM_CONST(0x0000000200000000)
#define CPU_FTR_TLBIEL ASM_CONST(0x0000000400000000)
#define CPU_FTR_NOEXECUTE ASM_CONST(0x0000000800000000)
-#define CPU_FTR_NODSISRALIGN ASM_CONST(0x0000001000000000)
#define CPU_FTR_IABR ASM_CONST(0x0000002000000000)
#define CPU_FTR_MMCRA ASM_CONST(0x0000004000000000)
#define CPU_FTR_CTRL ASM_CONST(0x0000008000000000)
@@ -113,7 +113,6 @@
#define CPU_FTR_16M_PAGE ASM_CONST(0x0)
#define CPU_FTR_TLBIEL ASM_CONST(0x0)
#define CPU_FTR_NOEXECUTE ASM_CONST(0x0)
-#define CPU_FTR_NODSISRALIGN ASM_CONST(0x0)
#define CPU_FTR_IABR ASM_CONST(0x0)
#define CPU_FTR_MMCRA ASM_CONST(0x0)
#define CPU_FTR_CTRL ASM_CONST(0x0)
@@ -273,18 +272,21 @@
CPU_FTRS_POWER3_32 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE,
CPU_FTRS_POWER4_32 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
- CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE,
+ CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE | CPU_FTR_NODSISRALIGN,
CPU_FTRS_970_32 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE | CPU_FTR_ALTIVEC_COMP |
- CPU_FTR_MAYBE_CAN_NAP,
+ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN,
CPU_FTRS_8XX = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB,
- CPU_FTRS_40X = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB,
- CPU_FTRS_44X = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB,
- CPU_FTRS_E200 = CPU_FTR_USE_TB,
- CPU_FTRS_E500 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB,
+ CPU_FTRS_40X = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
+ CPU_FTR_NODSISRALIGN,
+ CPU_FTRS_44X = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
+ CPU_FTR_NODSISRALIGN,
+ CPU_FTRS_E200 = CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN,
+ CPU_FTRS_E500 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
+ CPU_FTR_NODSISRALIGN,
CPU_FTRS_E500_2 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
- CPU_FTR_BIG_PHYS,
- CPU_FTRS_GENERIC_32 = CPU_FTR_COMMON,
+ CPU_FTR_BIG_PHYS | CPU_FTR_NODSISRALIGN,
+ CPU_FTRS_GENERIC_32 = CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN,
#ifdef __powerpc64__
CPU_FTRS_POWER3 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
CPU_FTR_HPTE_TABLE | CPU_FTR_IABR,
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Arkadiusz Miskiewicz @ 2005-11-14 7:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: debian-powerpc@lists.debian.org
In-Reply-To: <1131745946.24637.251.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
On Friday 11 November 2005 22:52, Benjamin Herrenschmidt wrote:
> The latest patch that is candidate for upstream is:
Oopsed for one pld user in a way shown in attachment after connecting usb
device while laptop (recent ibook g4 afaik) was in sleep and then waking it
up. That was with 2.6.14.2+your patch.
--
Arkadiusz Miśkiewicz PLD/Linux Team
http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/
[-- Attachment #2: suspend+usb=oops.png --]
[-- Type: image/png, Size: 57077 bytes --]
^ permalink raw reply
* name created by rpmbuild
From: debora liu @ 2005-11-14 5:30 UTC (permalink / raw)
To: denx; +Cc: Linuxppc-embedded
hello denx
I'm using rpmbuild, but it creat rpm packet name is "NAME-ppc_8xx-VERSION-RELEASE.ppc.rpm",
I think it should is "NAME-VERSION-RELEASE.ppc.rpm", true?
I use native rpmbuild on my board with eldk-3.1.1 PPC8xx NFS root.
debora liu
deboralh@sinovee.com
2005-11-14
^ permalink raw reply
* Re: [RFC] Attempt to clean up sigsuspend et al
From: Paul Mackerras @ 2005-11-14 4:43 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1131883101.27347.233.camel@baythorne.infradead.org>
David Woodhouse writes:
> But I think other things you mention are OK -- we'd still call
> do_signal() from *sigsuspend() just as we do at the moment, with the
> same loop. It's just that do_signal() would notice that the nvgprs
> aren't saved, and would set the TIF_SAVENVPGRS_TO_SIG_FRAME bit. ..
Ah ok, I see now, that sounds all right.
> (Actually in the case of swapcontext() we don't know that the nvgprs
> should be saved in a signal frame at the top of the userspace stack; the
> context will be elsewhere. We probably do need to store a pointer in the
> thread_info, but that's OK too)
True.
Paul.
^ permalink raw reply
* [PATCH] powerpc: vdso fixes (take #2)
From: Benjamin Herrenschmidt @ 2005-11-14 3:55 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev list, tom_gall@mac.com, David Woodhouse,
Steve Munroe, linuxppc64-dev
This fixes various errors in the new functions added in the vDSO's,
I've now verified all functions on both 32 and 64 bits vDSOs. It also
fix a sign extension bug getting the initial time of day at boot that
could cause the monotonic clock value to be completely on bogus for
64 bits applications (with either the vDSO or the syscall) on
powermacs.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/kernel/asm-offsets.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/asm-offsets.c 2005-11-14 11:06:58.000000000 +1100
+++ linux-work/arch/powerpc/kernel/asm-offsets.c 2005-11-14 13:09:57.000000000 +1100
@@ -270,13 +270,15 @@
DEFINE(TVAL64_TV_USEC, offsetof(struct timeval, tv_usec));
DEFINE(TVAL32_TV_SEC, offsetof(struct compat_timeval, tv_sec));
DEFINE(TVAL32_TV_USEC, offsetof(struct compat_timeval, tv_usec));
+ DEFINE(TSPC64_TV_SEC, offsetof(struct timespec, tv_sec));
+ DEFINE(TSPC64_TV_NSEC, offsetof(struct timespec, tv_nsec));
DEFINE(TSPC32_TV_SEC, offsetof(struct compat_timespec, tv_sec));
DEFINE(TSPC32_TV_NSEC, offsetof(struct compat_timespec, tv_nsec));
#else
DEFINE(TVAL32_TV_SEC, offsetof(struct timeval, tv_sec));
DEFINE(TVAL32_TV_USEC, offsetof(struct timeval, tv_usec));
- DEFINE(TSPEC32_TV_SEC, offsetof(struct timespec, tv_sec));
- DEFINE(TSPEC32_TV_NSEC, offsetof(struct timespec, tv_nsec));
+ DEFINE(TSPC32_TV_SEC, offsetof(struct timespec, tv_sec));
+ DEFINE(TSPC32_TV_NSEC, offsetof(struct timespec, tv_nsec));
#endif
/* timeval/timezone offsets for use by vdso */
DEFINE(TZONE_TZ_MINWEST, offsetof(struct timezone, tz_minuteswest));
Index: linux-work/arch/powerpc/kernel/vdso32/gettimeofday.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/vdso32/gettimeofday.S 2005-11-14 11:06:58.000000000 +1100
+++ linux-work/arch/powerpc/kernel/vdso32/gettimeofday.S 2005-11-14 12:06:27.000000000 +1100
@@ -83,7 +83,7 @@
/* Check for supported clock IDs */
cmpli cr0,r3,CLOCK_REALTIME
cmpli cr1,r3,CLOCK_MONOTONIC
- cror cr0,cr0,cr1
+ cror cr0*4+eq,cr0*4+eq,cr1*4+eq
bne cr0,99f
mflr r12 /* r12 saves lr */
@@ -91,7 +91,7 @@
mr r10,r3 /* r10 saves id */
mr r11,r4 /* r11 saves tp */
bl __get_datapage@local /* get data page */
- mr r9, r3 /* datapage ptr in r9 */
+ mr r9,r3 /* datapage ptr in r9 */
beq cr1,50f /* if monotonic -> jump there */
/*
@@ -173,10 +173,14 @@
add r4,r4,r7
lis r5,NSEC_PER_SEC@h
ori r5,r5,NSEC_PER_SEC@l
- cmpli cr0,r4,r5
+ cmpl cr0,r4,r5
+ cmpli cr1,r4,0
blt 1f
subf r4,r5,r4
addi r3,r3,1
+1: bge cr1,1f
+ addi r3,r3,-1
+ add r4,r4,r5
1: stw r3,TSPC32_TV_SEC(r11)
stw r4,TSPC32_TV_NSEC(r11)
@@ -210,7 +214,7 @@
/* Check for supported clock IDs */
cmpwi cr0,r3,CLOCK_REALTIME
cmpwi cr1,r3,CLOCK_MONOTONIC
- cror cr0,cr0,cr1
+ cror cr0*4+eq,cr0*4+eq,cr1*4+eq
bne cr0,99f
li r3,0
Index: linux-work/arch/powerpc/kernel/vdso64/gettimeofday.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/vdso64/gettimeofday.S 2005-11-14 11:06:58.000000000 +1100
+++ linux-work/arch/powerpc/kernel/vdso64/gettimeofday.S 2005-11-14 14:38:51.000000000 +1100
@@ -1,4 +1,5 @@
-/*
+
+ /*
* Userland implementation of gettimeofday() for 64 bits processes in a
* ppc64 kernel for use in the vDSO
*
@@ -68,7 +69,7 @@
/* Check for supported clock IDs */
cmpwi cr0,r3,CLOCK_REALTIME
cmpwi cr1,r3,CLOCK_MONOTONIC
- cror cr0,cr0,cr1
+ cror cr0*4+eq,cr0*4+eq,cr1*4+eq
bne cr0,99f
mflr r12 /* r12 saves lr */
@@ -84,16 +85,17 @@
bl V_LOCAL_FUNC(__do_get_xsec) /* get xsec from tb & kernel */
- lis r7,0x3b9a /* r7 = 1000000000 = NSEC_PER_SEC */
- ori r7,r7,0xca00
+ lis r7,15 /* r7 = 1000000 = USEC_PER_SEC */
+ ori r7,r7,16960
rldicl r5,r4,44,20 /* r5 = sec = xsec / XSEC_PER_SEC */
rldicr r6,r5,20,43 /* r6 = sec * XSEC_PER_SEC */
std r5,TSPC64_TV_SEC(r11) /* store sec in tv */
subf r0,r6,r4 /* r0 = xsec = (xsec - r6) */
- mulld r0,r0,r7 /* nsec = (xsec * NSEC_PER_SEC) /
+ mulld r0,r0,r7 /* usec = (xsec * USEC_PER_SEC) /
* XSEC_PER_SEC
*/
rldicl r0,r0,44,20
+ mulli r0,r0,1000 /* nsec = usec * 1000 */
std r0,TSPC64_TV_NSEC(r11) /* store nsec in tp */
mtlr r12
@@ -106,15 +108,16 @@
50: bl V_LOCAL_FUNC(__do_get_xsec) /* get xsec from tb & kernel */
- lis r7,0x3b9a /* r7 = 1000000000 = NSEC_PER_SEC */
- ori r7,r7,0xca00
+ lis r7,15 /* r7 = 1000000 = USEC_PER_SEC */
+ ori r7,r7,16960
rldicl r5,r4,44,20 /* r5 = sec = xsec / XSEC_PER_SEC */
rldicr r6,r5,20,43 /* r6 = sec * XSEC_PER_SEC */
subf r0,r6,r4 /* r0 = xsec = (xsec - r6) */
- mulld r0,r0,r7 /* nsec = (xsec * NSEC_PER_SEC) /
+ mulld r0,r0,r7 /* usec = (xsec * USEC_PER_SEC) /
* XSEC_PER_SEC
*/
rldicl r6,r0,44,20
+ mulli r6,r6,1000 /* nsec = usec * 1000 */
/* now we must fixup using wall to monotonic. We need to snapshot
* that value and do the counter trick again. Fortunately, we still
@@ -123,8 +126,8 @@
* can be used
*/
- lwz r4,WTOM_CLOCK_SEC(r9)
- lwz r7,WTOM_CLOCK_NSEC(r9)
+ lwa r4,WTOM_CLOCK_SEC(r3)
+ lwa r7,WTOM_CLOCK_NSEC(r3)
/* We now have our result in r4,r7. We create a fake dependency
* on that result and re-check the counter
@@ -144,10 +147,14 @@
add r7,r7,r6
lis r9,NSEC_PER_SEC@h
ori r9,r9,NSEC_PER_SEC@l
- cmpli cr0,r7,r9
+ cmpl cr0,r7,r9
+ cmpli cr1,r7,0
blt 1f
subf r7,r9,r7
addi r4,r4,1
+1: bge cr1,1f
+ addi r4,r4,-1
+ add r7,r7,r9
1: std r4,TSPC64_TV_SEC(r11)
std r7,TSPC64_TV_NSEC(r11)
@@ -181,7 +188,7 @@
/* Check for supported clock IDs */
cmpwi cr0,r3,CLOCK_REALTIME
cmpwi cr1,r3,CLOCK_MONOTONIC
- cror cr0,cr0,cr1
+ cror cr0*4+eq,cr0*4+eq,cr1*4+eq
bne cr0,99f
li r3,0
Index: linux-work/arch/powerpc/kernel/vdso32/datapage.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/vdso32/datapage.S 2005-11-14 11:06:58.000000000 +1100
+++ linux-work/arch/powerpc/kernel/vdso32/datapage.S 2005-11-14 11:07:11.000000000 +1100
@@ -77,8 +77,9 @@
mflr r12
.cfi_register lr,r12
bl __get_datapage@local
- lwz r3,CFG_TB_TICKS_PER_SEC(r3)
lwz r4,(CFG_TB_TICKS_PER_SEC + 4)(r3)
+ lwz r3,CFG_TB_TICKS_PER_SEC(r3)
mtlr r12
+ blr
.cfi_endproc
V_FUNCTION_END(__kernel_get_tbfreq)
Index: linux-work/arch/powerpc/kernel/vdso64/datapage.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/vdso64/datapage.S 2005-11-14 11:06:58.000000000 +1100
+++ linux-work/arch/powerpc/kernel/vdso64/datapage.S 2005-11-14 11:07:11.000000000 +1100
@@ -80,5 +80,6 @@
bl V_LOCAL_FUNC(__get_datapage)
ld r3,CFG_TB_TICKS_PER_SEC(r3)
mtlr r12
+ blr
.cfi_endproc
V_FUNCTION_END(__kernel_get_tbfreq)
Index: linux-work/include/asm-powerpc/vdso_datapage.h
===================================================================
--- linux-work.orig/include/asm-powerpc/vdso_datapage.h 2005-11-14 10:42:00.000000000 +1100
+++ linux-work/include/asm-powerpc/vdso_datapage.h 2005-11-14 11:52:12.000000000 +1100
@@ -73,7 +73,7 @@
/* those additional ones don't have to be located anywhere
* special as they were not part of the original systemcfg
*/
- __s64 wtom_clock_sec; /* Wall to monotonic clock */
+ __s32 wtom_clock_sec; /* Wall to monotonic clock */
__s32 wtom_clock_nsec;
__u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
__u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
Index: linux-work/arch/powerpc/platforms/powermac/time.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/time.c 2005-11-01 14:13:53.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/time.c 2005-11-14 14:28:10.000000000 +1100
@@ -102,7 +102,7 @@
static unsigned long cuda_get_time(void)
{
struct adb_request req;
- unsigned long now;
+ unsigned int now;
if (cuda_request(&req, NULL, 2, CUDA_PACKET, CUDA_GET_TIME) < 0)
return 0;
@@ -113,7 +113,7 @@
req.reply_len);
now = (req.reply[3] << 24) + (req.reply[4] << 16)
+ (req.reply[5] << 8) + req.reply[6];
- return now - RTC_OFFSET;
+ return ((unsigned long)now) - RTC_OFFSET;
}
#define cuda_get_rtc_time(tm) to_rtc_time(cuda_get_time(), (tm))
@@ -146,7 +146,7 @@
static unsigned long pmu_get_time(void)
{
struct adb_request req;
- unsigned long now;
+ unsigned int now;
if (pmu_request(&req, NULL, 1, PMU_READ_RTC) < 0)
return 0;
@@ -156,7 +156,7 @@
req.reply_len);
now = (req.reply[0] << 24) + (req.reply[1] << 16)
+ (req.reply[2] << 8) + req.reply[3];
- return now - RTC_OFFSET;
+ return ((unsigned long)now) - RTC_OFFSET;
}
#define pmu_get_rtc_time(tm) to_rtc_time(pmu_get_time(), (tm))
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Jesper Juhl @ 2005-11-14 1:04 UTC (permalink / raw)
To: Michael Buesch; +Cc: Linus Torvalds, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <200511122237.17157.mbuesch@freenet.de>
On 11/12/05, Michael Buesch <mbuesch@freenet.de> wrote:
> On Saturday 12 November 2005 22:00, you wrote:
> >
> > On Sat, 12 Nov 2005, Michael Buesch wrote:
> > >
> > > Latest GIT tree does not boot on my G4 PowerBook.
> >
> > What happens if you do
> >
> > make ARCH=3Dpowerpc
> >
> > and build everything that way (including the "config" phase)?
>
> I did
> make mrproper
> copy the .config over again
are you not missing a "make oldconfig" step here?
> make ARCH=3Dpowerpc menuconfig
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: [PATCH] ppc64: Thermal control for SMU based machines
From: Benjamin Herrenschmidt @ 2005-11-13 21:00 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development, Linux Kernel Development
In-Reply-To: <Pine.LNX.4.62.0511131845230.17491@numbat.sonytel.be>
> > --- a/drivers/macintosh/Kconfig
> > +++ b/drivers/macintosh/Kconfig
> > @@ -169,6 +169,25 @@ config THERM_PM72
> > This driver provides thermostat and fan control for the desktop
> > G5 machines.
> >
> > +config WINDFARM
> > + tristate "New PowerMac thermal control infrastructure"
>
> Shouldn't this depend on some PowerMac-related variables, to prevent it from
> showing up on m68k?
Well, the windfarm core is not really platform specific at all ...
Christoph even proposed to move it to some more "common" place, though
as I said, I want to work on it a bit more before that happens.
Ben.
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Benjamin Herrenschmidt @ 2005-11-13 20:59 UTC (permalink / raw)
To: Kumar Gala
Cc: ppc-dev list, Linus Torvalds, Michael Buesch,
Linux Kernel Mailing List
In-Reply-To: <71C11A0C-4FC8-4081-A890-A4FF7DA48752@kernel.crashing.org>
On Sun, 2005-11-13 at 10:37 -0600, Kumar Gala wrote:
> Can we please add some defconfigs for arch/powerpc to possibly help
> with this issue. I'm think a pmac32, pmac64, and whatever other 64
> bit configs would be a good start.
The 64 bits defconfigs are there already. I'll do a pmac one.
Ben.
^ permalink raw reply
* Re: [PATCH] ppc64: Thermal control for SMU based machines
From: Geert Uytterhoeven @ 2005-11-13 17:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras
Cc: Linux/PPC Development, Linux Kernel Development
In-Reply-To: <200511080502.jA852dWI011502@hera.kernel.org>
On Mon, 7 Nov 2005, Linux Kernel Mailing List wrote:
> tree d3f63b3ea80790c2f29ea435781c1331f17d269e
> parent 7d49697ef92bd2cf84ab53bd4cea82fefb197fb9
> author Benjamin Herrenschmidt <benh@kernel.crashing.org> Mon, 07 Nov 2005 16:08:17 +1100
> committer Paul Mackerras <paulus@samba.org> Tue, 08 Nov 2005 11:17:56 +1100
>
> [PATCH] ppc64: Thermal control for SMU based machines
>
> This adds a new thermal control framework for PowerMac, along with the
> implementation for PowerMac8,1, PowerMac8,2 (iMac G5 rev 1 and 2), and
> PowerMac9,1 (latest single CPU desktop). In the future, I expect to move
> the older G5 thermal control to the new framework as well.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> --- a/drivers/macintosh/Kconfig
> +++ b/drivers/macintosh/Kconfig
> @@ -169,6 +169,25 @@ config THERM_PM72
> This driver provides thermostat and fan control for the desktop
> G5 machines.
>
> +config WINDFARM
> + tristate "New PowerMac thermal control infrastructure"
Shouldn't this depend on some PowerMac-related variables, to prevent it from
showing up on m68k?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Kumar Gala @ 2005-11-13 16:37 UTC (permalink / raw)
To: Paul Mackerras
Cc: ppc-dev list, Linus Torvalds, Michael Buesch,
Linux Kernel Mailing List
In-Reply-To: <1131834336.7406.46.camel@gaston>
On Nov 12, 2005, at 4:25 PM, Benjamin Herrenschmidt wrote:
> On Sat, 2005-11-12 at 22:37 +0100, Michael Buesch wrote:
>> On Saturday 12 November 2005 22:00, you wrote:
>>>
>>> On Sat, 12 Nov 2005, Michael Buesch wrote:
>>>>
>>>> Latest GIT tree does not boot on my G4 PowerBook.
>>>
>>> What happens if you do
>>>
>>> make ARCH=powerpc
>>>
>>> and build everything that way (including the "config" phase)?
>>
>> I did
>> make mrproper
>> copy the .config over again
>> make ARCH=powerpc menuconfig
>> exit and save from menuconfig
>> make ARCH=powerpc
>
> You need to disable PREP support when building with ARCH=powerpc
> for 32
> bits, it doesn't build (yet). We should remove it from Kconfig...
>
> Also, there is an issue with the make clean stuff, make sure when
> switching archs to also remove arch/powerpc/include/asm symlink before
> trying to build.
Can we please add some defconfigs for arch/powerpc to possibly help
with this issue. I'm think a pmac32, pmac64, and whatever other 64
bit configs would be a good start.
- kumar
^ permalink raw reply
* Powerstack II (was: Re: Linuv 2.6.15-rc1)
From: Ulrich Teichert @ 2005-11-13 14:46 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <Pine.LNX.4.62.0511131014150.17491@numbat.sonytel.be>
Hi,
>On Sun, 13 Nov 2005, Ulrich Teichert wrote:
>> Especially the 43p-140 is quite easy to get via ebay, the Powerstack II
>> is a more rare machine nowadays, I think.
> ^^^^^^^^
>Probably because almost no one managed to buy one originally in the first
>place? :-)
I think they got sold more often in the project business, not to
"ordinary people", but I may be wrong ;-)
>I tried a long time ago, but the people at the Motorola PowerPC booth at CeBIT
>didn't even know about their own machines...
They show up on ebay from time to time, but spare parts are hard to
get. I'm searching for a hard disk tray since I got mine in 2003,
but I managed to find a tray for the floppy,
CU,
Uli
--
Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de
Stormweg 24 |listening to: Suicide Drive (The Deep Eynde)
24539 Neumuenster, Germany|Public Pervert (Interpol) Cauchemar (Opération S)
^ permalink raw reply
* RE: [PATCH 2.6.14] mm: 8xx MM fix for
From: Joakim Tjernlund @ 2005-11-13 12:47 UTC (permalink / raw)
To: 'Marcelo Tosatti'
Cc: 'Tom Rini', 'Dan Malek', gtolstolytkin,
linuxppc-embedded
In-Reply-To: <20051112192826.GB20537@logos.cnet>
> -----Original Message-----
> From: Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com]
> Sent: den 12 november 2005 20:28
> To: Joakim Tjernlund
> Cc: Tom Rini; Dan Malek; gtolstolytkin@ru.mvista.com;
> linuxppc-embedded@ozlabs.org
> Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
>
> On Mon, Nov 07, 2005 at 07:37:45PM +0100, Joakim Tjernlund wrote:
> > >
> > > On Mon, Nov 07, 2005 at 07:14:15PM +0100, Joakim Tjernlund wrote:
> > > > > -----Original Message-----
> > > > > From: Tom Rini [mailto:trini@kernel.crashing.org]
> > > > > Sent: 07 November 2005 16:52
> > > > > To: Marcelo Tosatti
> > > > > Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;
> > > > > linuxppc-embedded@ozlabs.org; gtolstolytkin@ru.mvista.com
> > > > > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> > > > >
> > > > > On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo
> Tosatti wrote:
> > > > > > Joakim!
> > > > > >
> > > > > > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim
> > > Tjernlund wrote:
> > > > > > > Hi Marcelo
> > > > > > >
> > > > > > > [SNIP]
> > > > > > > > The root of the problem are the changes against the 8xx
> > > > > > > > TLB handlers introduced during v2.6. What
> happens is the
> > > > > > > > TLBMiss handlers load the zeroed pte into the
> TLB, causing
> > > > > > > > the TLBError handler to be invoked (thats two
> TLB faults
> > > > > > > > per pagefault), which then jumps to the generic
> MM code to
> > > > > setup the pte.
> > > > > > > >
> > > > > > > > The bug is that the zeroed TLB is not invalidated (the
> > > > > same reason
> > > > > > > > for the "dcbst" misbehaviour), resulting in infinite
> > > > > TLBError faults.
> > > > > > > >
> > > > > > > > Dan, I wonder why we just don't go back to v2.4
> behaviour.
> > > > > > >
> > > > > > > This is one reason why it is the way it is:
> > > > > > >
> > > > >
> > >
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.ht
> > > ml
> > > > > > > This details are little fuzzy ATM, but I think the
> > > reason for the
> > > > > > > current
> > > > > > > impl. was only that it was less intrusive to impl.
> > > > > >
> > > > > > Ah, I see. I wonder if the bug is processor specific: we
> > > > > don't have such
> > > > > > changes in our v2.4 tree and never experienced such problem.
> > > > > >
> > > > > > It should be pretty easy to hit it right? (instruction
> > > > > pagefaults should
> > > > > > fail).
> > > > > >
> > > > > > Grigori, Tom, can you enlight us about the issue on the URL
> > > > > above. How
> > > > > > can it be triggered?
> > > > >
> > > > > So after looking at the code in 2.6.14 and current git, I
> > > think the
> > > > > above URL isn't relevant, unless there was a change I
> > > missed (which
> > > > > could totally be possible) that reverted the patch there and
> > > > > fixed that issue in a different manner. But since I didn't
> > > > > figure that out until I had finished researching it again:
> > > >
> > > > I wasn't clear enough. What I meant was that the above
> patch made
> > > > me think and the result was that I came up with a
> simpler fix, the
> > > > "two
> > > exception"
> > > > fix that
> > > > is in current kernels. See
> > > >
> > > http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/h
> > > ead_8xx.S@
> > > >
> > > 1.19?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/k
> > > ernel|hist
> > > > /arch/ppc/kernel/head_8xx.S
> > > > It appears this fix has some other issues :(
> > > >
> > > > How do the other ppc arches do? I am guessing that they don't
> > > > double fault, but bails out to do_page_fault from the TLB Miss
> > > > handler, like 8xx used to do.
> > >
> > > Assuming Dan doesn't come up with a more simple & better
> fix, maybe
> > > we should go back to the original patch I made?
> >
> > That was what I was thinking too(or some variation of your patch) I
> > wonder if that would solve the misbehaving dcbst problem
> Marcelo found
> > some time ago too?
>
> Hi Joakim,
>
> Yes, it would fix the "dcbst" issue. That problem was
> triggered by a zeroed TLB entry.
>
> In practice it seems that the "three exception" approach does
> not impose a significant overhead in comparison with the "two
> exception" version (as can be seen by the results of the
> latency tests).
>
> Anyway, if decided upon, the "two exception" version (no
> zeroed TLB entry state) needs the TLBMiss handler should to
> the present bit as Dan mentioned.
>
> I don't know what Dan is up to, he meant to be doing
> significant changes.
>
> I'll be playing with TLB preloading next week... how's your
> TLB handler shrinkage idea?
Hi Marcelo
Its still holding I think, it's a add on to whats in linuxppc-2.4:
http://ppc.bkbits.net:8080/linuxppc-2.4/diffs/arch/ppc/kernel/head_8xx.S@1.21?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/pp
c/kernel|hist/arch/ppc/kernel/head_8xx.S
If one could eliminate the test for a zero L1 entry you save an extra 4 instructions.
+ mfcr r20
+ cmplwi cr0, r21, 0x0fff /* Test page descriptor page address */
+ bng- 2f /* If zero, don't try to find a pte */
+ mtcr r20
If SPRG2 is free to use you can stash r21 there, then you don't need to use RAM to stash registers.
Maybe its possible to PIN some of the vmalloc space and use that for modules?
Jocke
^ permalink raw reply
* Re: [RFC] Attempt to clean up sigsuspend et al
From: David Woodhouse @ 2005-11-13 11:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17271.4290.486710.929502@cargo.ozlabs.ibm.com>
On Sun, 2005-11-13 at 21:09 +1100, Paul Mackerras wrote:
> > We don't need to do it on entry; we can do it on exit. If do_signal()
> > sees that the nvgprs weren't saved in the pt_regs it's playing with,
> > then it can set a new TIF_SAVENVPGRS_TO_SIG_FRAME bit. I don't think we
> > even need to store a pointer saying where to put them -- the signal
> > frame will always be at the top of the userspace stack.
>
> Two problems with that: (1) for *sigsuspend, if do_signal returns 0,
> then we need to go back and keep waiting, and (2) it doesn't handle
> the other syscalls that need the full register set, such as fork,
> clone etc. Also, for the *sigsuspend case, we need to pass the saved
> signal set to do_signal, not NULL (as the call from the exception exit
> path does).
It doesn't address fork/vfork/clone; certainly. I haven't really looked
at that code path at all yet. It was the *suspend() functions which
offended me, mostly because I need similar behaviour for pselect() and
ppoll() and I didn't want to add to the mess.
But I think other things you mention are OK -- we'd still call
do_signal() from *sigsuspend() just as we do at the moment, with the
same loop. It's just that do_signal() would notice that the nvgprs
aren't saved, and would set the TIF_SAVENVPGRS_TO_SIG_FRAME bit. ..
if (!regs->trap & 1)
set_thread_flag(TIF_SAVENVGPRS_SIG);
We end up returning to userspace via entry.S, and the code there notices
the SAVENVGPRS bit and saves _just_ r14-r31 into the signal frame. It
doesn't have to call do_signal() again, so doesn't have to get the right
saved signal mask when doing so.
(Actually in the case of swapcontext() we don't know that the nvgprs
should be saved in a signal frame at the top of the userspace stack; the
context will be elsewhere. We probably do need to store a pointer in the
thread_info, but that's OK too)
--
dwmw2
^ permalink raw reply
* Re: [RFC] Attempt to clean up sigsuspend et al
From: Paul Mackerras @ 2005-11-13 10:09 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1131874887.27347.221.camel@baythorne.infradead.org>
David Woodhouse writes:
> We don't need to do it on entry; we can do it on exit. If do_signal()
> sees that the nvgprs weren't saved in the pt_regs it's playing with,
> then it can set a new TIF_SAVENVPGRS_TO_SIG_FRAME bit. I don't think we
> even need to store a pointer saying where to put them -- the signal
> frame will always be at the top of the userspace stack.
Two problems with that: (1) for *sigsuspend, if do_signal returns 0,
then we need to go back and keep waiting, and (2) it doesn't handle
the other syscalls that need the full register set, such as fork,
clone etc. Also, for the *sigsuspend case, we need to pass the saved
signal set to do_signal, not NULL (as the call from the exception exit
path does).
Paul.
^ permalink raw reply
* Re: asm/delay.h missing on powerpc (was: Re: Linuv 2.6.15-rc1)
From: Michael Buesch @ 2005-11-13 9:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <1131841993.5504.13.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
On Sunday 13 November 2005 01:33, you wrote:
> On Sun, 2005-11-13 at 00:13 +0100, Michael Buesch wrote:
> > On Saturday 12 November 2005 23:24, you wrote:
> > > Ìt should still work. I'm running -rc1 with "powerpc" on mine so that at
> > > least works, it's possible that we broke "ppc", I'll have a look and
> > > send a fix.
> >
> > powerpc arch builds and runs now, but
> > I have problems compiling the bcm430x driver. It includes linux/delay.h.
> > linux/delay.h includes asm/delay.h, which does not exist.
> > What to do now?
>
> I suspect that building drivers out of tree doesn't work very well with
> the new "merged" architecture where includes are split between asm/ppc
> and asm-powerpc... You should make sure that you build the driver with
> the same ARCH as the kernel, that is ARCH=powerpc at least, if we got
> the Makefiles right, that should give you all the headers...
Call me an idiot ;)
doing make ARCH=powerpc in the driver works perfectly fine.
> (building glibc is definitely a pain :)
Try out the stable LFS book. It will guilde you trough it step by step. ;)
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Attempt to clean up sigsuspend et al
From: David Woodhouse @ 2005-11-13 9:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17270.58406.370195.733887@cargo.ozlabs.ibm.com>
On Sun, 2005-11-13 at 17:58 +1100, Paul Mackerras wrote:
> Or have a mark in the syscall table (e.g. set the bottom bit of the
> address) for the syscalls that need the full register set. That does
> mean an extra conditional branch in the syscall entry path for all
> syscalls, though.
We don't need to do it on entry; we can do it on exit. If do_signal()
sees that the nvgprs weren't saved in the pt_regs it's playing with,
then it can set a new TIF_SAVENVPGRS_TO_SIG_FRAME bit. I don't think we
even need to store a pointer saying where to put them -- the signal
frame will always be at the top of the userspace stack.
As long as we handle the new bit before TIF_SIGPENDING and before
another call to do_signal(), we don't need to worry about recursive
signals and having to fill in more than one signal frame.
--
dwmw2
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Geert Uytterhoeven @ 2005-11-13 9:17 UTC (permalink / raw)
To: Ulrich Teichert; +Cc: Linux/PPC Development
In-Reply-To: <200511122351.jACNpiG5016918@arbas.nms.ulrich-teichert.org>
On Sun, 13 Nov 2005, Ulrich Teichert wrote:
> Especially the 43p-140 is quite easy to get via ebay, the Powerstack II
> is a more rare machine nowadays, I think.
^^^^^^^^
Probably because almost no one managed to buy one originally in the first
place? :-)
I tried a long time ago, but the people at the Motorola PowerPC booth at CeBIT
didn't even know about their own machines...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC] Attempt to clean up sigsuspend et al
From: Paul Mackerras @ 2005-11-13 6:58 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1131756526.27347.212.camel@baythorne.infradead.org>
David Woodhouse writes:
> I suppose I could make a TIF_xxx flag make entry.S do that. It's not
> massively pretty, but then it wasn't pretty beforehand either. At least
> I'd have made the ppc32 and ppc64 code match, removed the assembly
> wrappers for a bunch of syscalls, and shortened the syscall exit fast
> path on ppc64.
>
> I'd probably still be removing more lines of code than I add, but I'm
> not entirely convinced by the whole plan. What do you think?
Or have a mark in the syscall table (e.g. set the bottom bit of the
address) for the syscalls that need the full register set. That does
mean an extra conditional branch in the syscall entry path for all
syscalls, though.
> Failing that, I'll just switch them both to do either what ppc32
> currently does with sigreturn_exit() or what ppc64 does with returning
> zero to take the ret_from_except path. Probably the former, since
> pselect() and ppoll() will sometimes want to return zero without
> invoking a signal handler. And we can probably shorten the ppc64
> syscall exit path anyway, either way.
I'll be upset if you can shorten it by a lot - I thought I had it
pretty tight already. :)
Paul.
^ permalink raw reply
* Re: [2.6 patch] PPC_PREP: remove unneeded exports
From: Benjamin Herrenschmidt @ 2005-11-13 3:23 UTC (permalink / raw)
To: Adrian Bunk
Cc: linuxppc-dev, Linus Torvalds, Michael Buesch,
Linux Kernel Mailing List
In-Reply-To: <20051113012608.GH21448@stusta.de>
On Sun, 2005-11-13 at 02:26 +0100, Adrian Bunk wrote:
> On Sun, Nov 13, 2005 at 09:31:06AM +1100, Benjamin Herrenschmidt wrote:
> >
> > > ucSystemType is a variable that is EXPORT_SYMBOL'ed but never used in
> > > any way.
> > >
> > > _prep_type is a variable that is needlessly EXPORT_SYMBOL'ed.
> >
> > Therse are old PREP stuffs
> >...
>
> Is the patch below OK?
The ucXXX variables should probably go (or at least be unexported) but I
would keep the _prep_type export for now, unless we are certain no
driver and no out of tree stuff neither uses it (hrm... might well be
the case).
In any case, the proper fix is probably to move the EXPORT_SYMBOL() out
of ppc_ksyms, and have it next to the declaration of the variable.
Ben.
^ permalink raw reply
* [2.6 patch] PPC_PREP: remove unneeded exports
From: Adrian Bunk @ 2005-11-13 1:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Linus Torvalds, Michael Buesch,
Linux Kernel Mailing List
In-Reply-To: <1131834667.7406.49.camel@gaston>
On Sun, Nov 13, 2005 at 09:31:06AM +1100, Benjamin Herrenschmidt wrote:
>
> > ucSystemType is a variable that is EXPORT_SYMBOL'ed but never used in
> > any way.
> >
> > _prep_type is a variable that is needlessly EXPORT_SYMBOL'ed.
>
> Therse are old PREP stuffs
>...
Is the patch below OK?
> Ben.
cu
Adrian
<-- snip -->
This patch removes the EXPORT_SYMBOL'ed but completely unused variable
ucSystemType and removes the unneeded EXPORT_SYMBOL(_prep_type).
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
arch/powerpc/kernel/ppc_ksyms.c | 5 -----
arch/ppc/kernel/ppc_ksyms.c | 4 ----
arch/ppc/platforms/prep_setup.c | 1 -
include/asm-powerpc/processor.h | 1 -
4 files changed, 11 deletions(-)
--- linux-2.6.15-rc1/include/asm-powerpc/processor.h.old 2005-11-13 01:44:12.000000000 +0100
+++ linux-2.6.15-rc1/include/asm-powerpc/processor.h 2005-11-13 01:44:25.000000000 +0100
@@ -68,7 +68,6 @@
* vendor. Board revision is also made available. This will be moved
* elsewhere soon
*/
-extern unsigned char ucSystemType;
extern unsigned char ucBoardRev;
extern unsigned char ucBoardRevMaj, ucBoardRevMin;
--- linux-2.6.15-rc1/arch/ppc/platforms/prep_setup.c.old 2005-11-13 01:44:36.000000000 +0100
+++ linux-2.6.15-rc1/arch/ppc/platforms/prep_setup.c 2005-11-13 01:44:40.000000000 +0100
@@ -72,7 +72,6 @@
TODC_ALLOC();
-unsigned char ucSystemType;
unsigned char ucBoardRev;
unsigned char ucBoardRevMaj, ucBoardRevMin;
--- linux-2.6.15-rc1/arch/ppc/kernel/ppc_ksyms.c.old 2005-11-13 01:44:49.000000000 +0100
+++ linux-2.6.15-rc1/arch/ppc/kernel/ppc_ksyms.c 2005-11-13 01:44:54.000000000 +0100
@@ -82,10 +82,6 @@
EXPORT_SYMBOL(ISA_DMA_THRESHOLD);
EXPORT_SYMBOL(DMA_MODE_READ);
EXPORT_SYMBOL(DMA_MODE_WRITE);
-#if defined(CONFIG_PPC_PREP)
-EXPORT_SYMBOL(_prep_type);
-EXPORT_SYMBOL(ucSystemType);
-#endif
#if !defined(__INLINE_BITOPS)
EXPORT_SYMBOL(set_bit);
--- linux-2.6.15-rc1/arch/powerpc/kernel/ppc_ksyms.c.old 2005-11-13 01:45:06.000000000 +0100
+++ linux-2.6.15-rc1/arch/powerpc/kernel/ppc_ksyms.c 2005-11-13 01:45:12.000000000 +0100
@@ -76,11 +76,6 @@
EXPORT_SYMBOL(sys_sigreturn);
#endif
-#if defined(CONFIG_PPC_PREP)
-EXPORT_SYMBOL(_prep_type);
-EXPORT_SYMBOL(ucSystemType);
-#endif
-
EXPORT_SYMBOL(strcpy);
EXPORT_SYMBOL(strncpy);
EXPORT_SYMBOL(strcat);
^ permalink raw reply
* Re: asm/delay.h missing on powerpc (was: Re: Linuv 2.6.15-rc1)
From: Benjamin Herrenschmidt @ 2005-11-13 0:33 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <200511130013.45610.mbuesch@freenet.de>
On Sun, 2005-11-13 at 00:13 +0100, Michael Buesch wrote:
> On Saturday 12 November 2005 23:24, you wrote:
> > Ìt should still work. I'm running -rc1 with "powerpc" on mine so that at
> > least works, it's possible that we broke "ppc", I'll have a look and
> > send a fix.
>
> powerpc arch builds and runs now, but
> I have problems compiling the bcm430x driver. It includes linux/delay.h.
> linux/delay.h includes asm/delay.h, which does not exist.
> What to do now?
I suspect that building drivers out of tree doesn't work very well with
the new "merged" architecture where includes are split between asm/ppc
and asm-powerpc... You should make sure that you build the driver with
the same ARCH as the kernel, that is ARCH=powerpc at least, if we got
the Makefiles right, that should give you all the headers...
(building glibc is definitely a pain :)
Ben.
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Marcelo Tosatti @ 2005-11-12 19:28 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Tom Rini, Dan Malek, gtolstolytkin, linuxppc-embedded
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D9393FD5C6@tmnt04.transmode.se>
On Mon, Nov 07, 2005 at 07:37:45PM +0100, Joakim Tjernlund wrote:
> >
> > On Mon, Nov 07, 2005 at 07:14:15PM +0100, Joakim Tjernlund wrote:
> > > > -----Original Message-----
> > > > From: Tom Rini [mailto:trini@kernel.crashing.org]
> > > > Sent: 07 November 2005 16:52
> > > > To: Marcelo Tosatti
> > > > Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;
> > > > linuxppc-embedded@ozlabs.org; gtolstolytkin@ru.mvista.com
> > > > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> > > >
> > > > On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:
> > > > > Joakim!
> > > > >
> > > > > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim
> > Tjernlund wrote:
> > > > > > Hi Marcelo
> > > > > >
> > > > > > [SNIP]
> > > > > > > The root of the problem are the changes against the 8xx TLB
> > > > > > > handlers introduced
> > > > > > > during v2.6. What happens is the TLBMiss handlers load the
> > > > > > > zeroed pte into
> > > > > > > the TLB, causing the TLBError handler to be invoked (thats
> > > > > > > two TLB faults per
> > > > > > > pagefault), which then jumps to the generic MM code to
> > > > setup the pte.
> > > > > > >
> > > > > > > The bug is that the zeroed TLB is not invalidated (the
> > > > same reason
> > > > > > > for the "dcbst" misbehaviour), resulting in infinite
> > > > TLBError faults.
> > > > > > >
> > > > > > > Dan, I wonder why we just don't go back to v2.4 behaviour.
> > > > > >
> > > > > > This is one reason why it is the way it is:
> > > > > >
> > > >
> > http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
> > > > > > This details are little fuzzy ATM, but I think the
> > reason for the
> > > > > > current
> > > > > > impl. was only that it was less intrusive to impl.
> > > > >
> > > > > Ah, I see. I wonder if the bug is processor specific: we
> > > > don't have such
> > > > > changes in our v2.4 tree and never experienced such problem.
> > > > >
> > > > > It should be pretty easy to hit it right? (instruction
> > > > pagefaults should
> > > > > fail).
> > > > >
> > > > > Grigori, Tom, can you enlight us about the issue on the URL
> > > > above. How
> > > > > can it be triggered?
> > > >
> > > > So after looking at the code in 2.6.14 and current git, I
> > think the
> > > > above URL isn't relevant, unless there was a change I
> > missed (which
> > > > could totally be possible) that reverted the patch there and
> > > > fixed that
> > > > issue in a different manner. But since I didn't figure that
> > > > out until I
> > > > had finished researching it again:
> > >
> > > I wasn't clear enough. What I meant was that the above patch made me
> > > think and
> > > the result was that I came up with a simpler fix, the "two
> > exception"
> > > fix that
> > > is in current kernels. See
> > >
> > http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/h
> > ead_8xx.S@
> > >
> > 1.19?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/k
> > ernel|hist
> > > /arch/ppc/kernel/head_8xx.S
> > > It appears this fix has some other issues :(
> > >
> > > How do the other ppc arches do? I am guessing that they don't double
> > > fault, but bails
> > > out to do_page_fault from the TLB Miss handler, like 8xx used to do.
> >
> > Assuming Dan doesn't come up with a more simple & better fix, maybe we
> > should go back to the original patch I made?
>
> That was what I was thinking too(or some variation of your patch)
> I wonder if that would solve the misbehaving dcbst problem Marcelo found
> some time ago too?
Hi Joakim,
Yes, it would fix the "dcbst" issue. That problem was triggered by a
zeroed TLB entry.
In practice it seems that the "three exception" approach does not impose
a significant overhead in comparison with the "two exception" version
(as can be seen by the results of the latency tests).
Anyway, if decided upon, the "two exception" version (no zeroed TLB
entry state) needs the TLBMiss handler should to the present bit as Dan
mentioned.
I don't know what Dan is up to, he meant to be doing significant changes.
I'll be playing with TLB preloading next week... how's your TLB handler
shrinkage idea?
^ 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