* How to use SPE on MPC8541
From: Gérard Guével @ 2005-09-27 15:30 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <e29792bf3239d4cfb5861e7826300795@freescale.com>
Hi,
I am running a Linux 2.6.9 on a MPC8541 custom board.
I would like to run a user application which contains
some SPE code extracted from a freescale library.
I compiled the kernel with the CONFIG_SPE set to yes.
The application also compiles and I can run it on the
board.
But it seems the SPE bit from the MSR register
is not set when the process runs.
I tried to use a call to the enable_kernel_spe function
to force the bit, but it is always erased by the kernel (??)
when scheduling task and never set again.
Must I compile the application with some special flags
to instruct the kernel I want to use SPE ?
Thanks for any idea
Gérard
^ permalink raw reply
* Re: Starting the arch/powerpc merge
From: Daniel Ostrow @ 2005-09-27 15:43 UTC (permalink / raw)
To: panto; +Cc: linuxppc64-dev, linuxppc-dev
>Pantelis Antoniou writes:
>
>> Count me in too; using a 970 in 32 bit mode, because of gentoo X.org
>> problems in 64 bit mode.
>
>I'm using an X.org server on a ppc64 kernel, and it all works,
>including DRI. Both 32-bit and 64-bit X server and clients work. We
>now have the 32-bit ioctl compatibility sorted out in the kernel DRM.
>So I don't think X is a reason to run a 32-bit kernel any more.
>
>What X.org problems do you see with a 64-bit kernel?
>
>Paul.
Speaking as a member of the Gentoo/PPC64 team I'm also curious what
issues you are having...the only open issues that I am aware of have to
do with the recent r7 X.org prereleases...both modular and monolithic.
If that is what you are talking about then yeah there are issues...but
more then likely they are on the X.org side not the kernels. Anything in
the 6.8.2 range (which is what is stable) has been working fine for a
long long time under a pure 64-bit env.
Thanks,
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org
^ permalink raw reply
* Re: How to use SPE on MPC8541
From: Andy Fleming @ 2005-09-27 15:56 UTC (permalink / raw)
To: Gérard Guével; +Cc: linuxppc-embedded
In-Reply-To: <000d01c5c378$64610960$5201a8c0@GEG2400>
On Sep 27, 2005, at 10:30, G=E9rard Gu=E9vel wrote:
>
> Hi,
>
> I am running a Linux 2.6.9 on a MPC8541 custom board.
>
> I would like to run a user application which contains
> some SPE code extracted from a freescale library.
>
> I compiled the kernel with the CONFIG_SPE set to yes.
> The application also compiles and I can run it on the
> board.
>
> But it seems the SPE bit from the MSR register
> is not set when the process runs.
>
> I tried to use a call to the enable_kernel_spe function
> to force the bit, but it is always erased by the kernel (??)
> when scheduling task and never set again.
>
> Must I compile the application with some special flags
> to instruct the kernel I want to use SPE ?
You say the application runs, right? So what made you check the SPE =20
bit state? The kernel keeps SPE disabled by default so it doesn't =20
have to save the upper 32 bits of the registers every context =20
switch. When a process uses SPE for the first time, an exception is =20
triggered, the kernel enables SPE for that process, and then that =20
process should be able to use SPE every time it gets cpu time.
How are you determining that the SPE bit is not set? Is your =20
application not executing the SPE instructions?
Andy
^ permalink raw reply
* Re: (no subject)
From: Wolfgang Denk @ 2005-09-27 16:07 UTC (permalink / raw)
To: xiay; +Cc: linuxppc-embedded
In-Reply-To: <200509272153.AA292552812@NARI-RELAYS.COM>
In message <200509272153.AA292552812@NARI-RELAYS.COM> you wrote:
> I have plugged a PCI net card (i82559)on the ICECUBE board (mpc5200), but could not make it work .Which environment should i config in U-BOOT?
What are you talking about? Make it work in U-Boot? In Linux? What
exactly did you try, and what did not work? What was the exact error
messages?
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
Der Horizont vieler Menschen ist ein Kreis mit Radius Null --
und das nennen sie ihren Standpunkt.
^ permalink raw reply
* Re: Starting the arch/powerpc merge
From: Christopher Friesen @ 2005-09-27 16:43 UTC (permalink / raw)
To: dostrow; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <1127835826.7811.27.camel@Memoria.anyarch.net>
Daniel Ostrow wrote:
> Anything in
> the 6.8.2 range (which is what is stable) has been working fine for a
> long long time under a pure 64-bit env.
What about mixed 32-bit userspace and 64-bit kernel?
Chris
^ permalink raw reply
* Re: CPM2 early console
From: Dan Malek @ 2005-09-27 16:39 UTC (permalink / raw)
To: Kalle Pokki; +Cc: linuxppc-embedded
In-Reply-To: <43395322.1080407@iki.fi>
On Sep 27, 2005, at 10:11 AM, Kalle Pokki wrote:
> Is the alloc_bootmem() function in e.g. cpm_uart_allocbuf() supposed
> to give non-cached memory? In my 8248 board it seems not to.
It provides cache coherent memory, whether it is cached or not
depends upon the capabilities of the cache controller and
peripherals. On the 82xx, it is supposed to be cached.
> Only using DPRAM as buffer storage allows booting to proceed without
> hanging right in the beginning.
The only thing that would cause a problem is an
incorrect CPM configuration.
> Any ideas what can set the bootmem memory as cached?
All of memory is always cached on 82xx. Which is fine
since the cache controller keeps the processor core
and peripherals coherent in hardware.
Thanks.
-- Dan
^ permalink raw reply
* Re: Starting the arch/powerpc merge
From: Daniel Ostrow @ 2005-09-27 17:29 UTC (permalink / raw)
To: Christopher Friesen; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <433976BA.6010206@nortel.com>
On Tue, 2005-09-27 at 10:43 -0600, Christopher Friesen wrote:
> Daniel Ostrow wrote:
> > Anything in
> > the 6.8.2 range (which is what is stable) has been working fine for a
> > long long time under a pure 64-bit env.
>
> What about mixed 32-bit userspace and 64-bit kernel?
>
> Chris
>
The way I set that up is still young...and has some issues (most of
which should be fixed by the ppc && ppc64 -> powerpc merge). From what I
have tested, it does work perfectly fine with 6.8.2...I haven't run into
any issues. I maintain that profile so if there are issues please take
them off this list...feel free to send them to ppc64@gentoo.org or open
a bug at bugs.gentoo.org and assign it to the ppc64 group. I'll see it
either way.
Thanks,
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org
^ permalink raw reply
* RE: How to use SPE on MPC8541
From: Gérard Guével @ 2005-09-27 17:36 UTC (permalink / raw)
To: 'Andy Fleming'; +Cc: linuxppc-embedded
In-Reply-To: <5D83ECE9-90F7-4BE2-B173-C20CB868E9F6@freescale.com>
> You say the application runs, right? So what made you check the SPE
> bit state? The kernel keeps SPE disabled by default so it doesn't
> have to save the upper 32 bits of the registers every context
> switch. When a process uses SPE for the first time, an exception is
> triggered, the kernel enables SPE for that process, and then that
> process should be able to use SPE every time it gets cpu time.
>
> How are you determining that the SPE bit is not set? Is your
> application not executing the SPE instructions?
>
> Andy
Yes the application runs. I wrote a mini driver with an ioctl which
performs a mfmsr() call and returns the value to the user application.
I called this ioctl at several times before and after executing SPE code.
I already tried to manually force the SPE bit with another ioctl which
performs a enable_kernel_spe() call. The bit SPE is right set at this time
but disappears later.
I don't know if using ioctls is a right way to check the bit.
Any idea ?
Thanks
Gérard
^ permalink raw reply
* Re: How to use SPE on MPC8541
From: Andy Fleming @ 2005-09-27 18:50 UTC (permalink / raw)
To: Gérard Guével; +Cc: linuxppc-embedded
In-Reply-To: <000a01c5c38a$0f77cda0$5201a8c0@GEG2400>
On Sep 27, 2005, at 12:36, G=E9rard Gu=E9vel wrote:
>
>
>
>> You say the application runs, right? So what made you check the SPE
>> bit state? The kernel keeps SPE disabled by default so it doesn't
>> have to save the upper 32 bits of the registers every context
>> switch. When a process uses SPE for the first time, an exception is
>> triggered, the kernel enables SPE for that process, and then that
>> process should be able to use SPE every time it gets cpu time.
>>
>> How are you determining that the SPE bit is not set? Is your
>> application not executing the SPE instructions?
>>
>> Andy
>>
>
> Yes the application runs. I wrote a mini driver with an ioctl which
> performs a mfmsr() call and returns the value to the user =20
> application.
> I called this ioctl at several times before and after executing SPE =20=
> code.
> I already tried to manually force the SPE bit with another ioctl which
> performs a enable_kernel_spe() call. The bit SPE is right set at =20
> this time
> but disappears later.
Your driver runs in kernel space. The kernel has the SPE bit off. =20
The MSR state is process-specific. If the code executes, the MSR bit =20=
is set. Why do you want to see if the bit is set?
^ permalink raw reply
* [PATCH] powerpc: merge byteorder.h
From: Becky Bruce @ 2005-09-27 19:28 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-dev
powerpc: Merge byteorder.h
Essentially adopts the 64-bit version of this file. The 32-bit version had
been using unsigned ints for arguments/return values that were actually
only 16 bits - the new file uses __u16 for these items as in the 64-bit
version of the header. The order of some of the asm constraints
in the 64-bit version was slightly different than the 32-bit version,
but they produce identical code.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 01344596fdecbe2b97e122b6a50570a19218cd2f
tree ccdf20534198e69459d95f21b8f45aafc00e8238
parent d407c9f3f6f3c84d9daec257f9a2550aacbd2892
author Becky Bruce <becky.bruce@freescale.com> Tue, 27 Sep 2005 14:04:44 -0500
committer Becky Bruce <becky.bruce@freescale.com> Tue, 27 Sep 2005 14:04:44 -0500
include/asm-powerpc/byteorder.h | 89 +++++++++++++++++++++++++++++++++++++++
include/asm-ppc/byteorder.h | 76 ---------------------------------
include/asm-ppc64/byteorder.h | 86 --------------------------------------
3 files changed, 89 insertions(+), 162 deletions(-)
diff --git a/include/asm-powerpc/byteorder.h b/include/asm-powerpc/byteorder.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/byteorder.h
@@ -0,0 +1,89 @@
+#ifndef _ASM_POWERPC_BYTEORDER_H
+#define _ASM_POWERPC_BYTEORDER_H
+
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <asm/types.h>
+#include <linux/compiler.h>
+
+#ifdef __GNUC__
+#ifdef __KERNEL__
+
+static __inline__ __u16 ld_le16(const volatile __u16 *addr)
+{
+ __u16 val;
+
+ __asm__ __volatile__ ("lhbrx %0,0,%1" : "=r" (val) : "r" (addr), "m" (*addr));
+ return val;
+}
+
+static __inline__ void st_le16(volatile __u16 *addr, const __u16 val)
+{
+ __asm__ __volatile__ ("sthbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
+}
+
+static __inline__ __u32 ld_le32(const volatile __u32 *addr)
+{
+ __u32 val;
+
+ __asm__ __volatile__ ("lwbrx %0,0,%1" : "=r" (val) : "r" (addr), "m" (*addr));
+ return val;
+}
+
+static __inline__ void st_le32(volatile __u32 *addr, const __u32 val)
+{
+ __asm__ __volatile__ ("stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
+}
+
+static __inline__ __attribute_const__ __u16 ___arch__swab16(__u16 value)
+{
+ __u16 result;
+
+ __asm__("rlwimi %0,%1,8,16,23"
+ : "=r" (result)
+ : "r" (value), "0" (value >> 8));
+ return result;
+}
+
+static __inline__ __attribute_const__ __u32 ___arch__swab32(__u32 value)
+{
+ __u32 result;
+
+ __asm__("rlwimi %0,%1,24,16,23\n\t"
+ "rlwimi %0,%1,8,8,15\n\t"
+ "rlwimi %0,%1,24,0,7"
+ : "=r" (result)
+ : "r" (value), "0" (value >> 24));
+ return result;
+}
+
+#define __arch__swab16(x) ___arch__swab16(x)
+#define __arch__swab32(x) ___arch__swab32(x)
+
+/* The same, but returns converted value from the location pointer by addr. */
+#define __arch__swab16p(addr) ld_le16(addr)
+#define __arch__swab32p(addr) ld_le32(addr)
+
+/* The same, but do the conversion in situ, ie. put the value back to addr. */
+#define __arch__swab16s(addr) st_le16(addr,*addr)
+#define __arch__swab32s(addr) st_le32(addr,*addr)
+
+#endif /* __KERNEL__ */
+
+#ifndef __STRICT_ANSI__
+#define __BYTEORDER_HAS_U64__
+#ifndef __powerpc64__
+#define __SWAB_64_THRU_32__
+#endif /* __powerpc64__ */
+#endif /* __STRICT_ANSI__ */
+
+#endif /* __GNUC__ */
+
+#include <linux/byteorder/big_endian.h>
+
+#endif /* _ASM_POWERPC_BYTEORDER_H */
diff --git a/include/asm-ppc/byteorder.h b/include/asm-ppc/byteorder.h
deleted file mode 100644
--- a/include/asm-ppc/byteorder.h
+++ /dev/null
@@ -1,76 +0,0 @@
-#ifndef _PPC_BYTEORDER_H
-#define _PPC_BYTEORDER_H
-
-#include <asm/types.h>
-#include <linux/compiler.h>
-
-#ifdef __GNUC__
-#ifdef __KERNEL__
-
-extern __inline__ unsigned ld_le16(const volatile unsigned short *addr)
-{
- unsigned val;
-
- __asm__ __volatile__ ("lhbrx %0,0,%1" : "=r" (val) : "r" (addr), "m" (*addr));
- return val;
-}
-
-extern __inline__ void st_le16(volatile unsigned short *addr, const unsigned val)
-{
- __asm__ __volatile__ ("sthbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
-}
-
-extern __inline__ unsigned ld_le32(const volatile unsigned *addr)
-{
- unsigned val;
-
- __asm__ __volatile__ ("lwbrx %0,0,%1" : "=r" (val) : "r" (addr), "m" (*addr));
- return val;
-}
-
-extern __inline__ void st_le32(volatile unsigned *addr, const unsigned val)
-{
- __asm__ __volatile__ ("stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
-}
-
-static __inline__ __attribute_const__ __u16 ___arch__swab16(__u16 value)
-{
- __u16 result;
-
- __asm__("rlwimi %0,%2,8,16,23" : "=&r" (result) : "0" (value >> 8), "r" (value));
- return result;
-}
-
-static __inline__ __attribute_const__ __u32 ___arch__swab32(__u32 value)
-{
- __u32 result;
-
- __asm__("rlwimi %0,%2,24,16,23" : "=&r" (result) : "0" (value>>24), "r" (value));
- __asm__("rlwimi %0,%2,8,8,15" : "=&r" (result) : "0" (result), "r" (value));
- __asm__("rlwimi %0,%2,24,0,7" : "=&r" (result) : "0" (result), "r" (value));
-
- return result;
-}
-#define __arch__swab32(x) ___arch__swab32(x)
-#define __arch__swab16(x) ___arch__swab16(x)
-
-/* The same, but returns converted value from the location pointer by addr. */
-#define __arch__swab16p(addr) ld_le16(addr)
-#define __arch__swab32p(addr) ld_le32(addr)
-
-/* The same, but do the conversion in situ, ie. put the value back to addr. */
-#define __arch__swab16s(addr) st_le16(addr,*addr)
-#define __arch__swab32s(addr) st_le32(addr,*addr)
-
-#endif /* __KERNEL__ */
-
-#if !defined(__STRICT_ANSI__) || defined(__KERNEL__)
-# define __BYTEORDER_HAS_U64__
-# define __SWAB_64_THRU_32__
-#endif
-
-#endif /* __GNUC__ */
-
-#include <linux/byteorder/big_endian.h>
-
-#endif /* _PPC_BYTEORDER_H */
diff --git a/include/asm-ppc64/byteorder.h b/include/asm-ppc64/byteorder.h
deleted file mode 100644
--- a/include/asm-ppc64/byteorder.h
+++ /dev/null
@@ -1,86 +0,0 @@
-#ifndef _PPC64_BYTEORDER_H
-#define _PPC64_BYTEORDER_H
-
-/*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include <asm/types.h>
-#include <linux/compiler.h>
-
-#ifdef __GNUC__
-#ifdef __KERNEL__
-
-static __inline__ __u16 ld_le16(const volatile __u16 *addr)
-{
- __u16 val;
-
- __asm__ __volatile__ ("lhbrx %0,0,%1" : "=r" (val) : "r" (addr), "m" (*addr));
- return val;
-}
-
-static __inline__ void st_le16(volatile __u16 *addr, const __u16 val)
-{
- __asm__ __volatile__ ("sthbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
-}
-
-static __inline__ __u32 ld_le32(const volatile __u32 *addr)
-{
- __u32 val;
-
- __asm__ __volatile__ ("lwbrx %0,0,%1" : "=r" (val) : "r" (addr), "m" (*addr));
- return val;
-}
-
-static __inline__ void st_le32(volatile __u32 *addr, const __u32 val)
-{
- __asm__ __volatile__ ("stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
-}
-
-static __inline__ __attribute_const__ __u16 ___arch__swab16(__u16 value)
-{
- __u16 result;
-
- __asm__("rlwimi %0,%1,8,16,23"
- : "=r" (result)
- : "r" (value), "0" (value >> 8));
- return result;
-}
-
-static __inline__ __attribute_const__ __u32 ___arch__swab32(__u32 value)
-{
- __u32 result;
-
- __asm__("rlwimi %0,%1,24,16,23\n\t"
- "rlwimi %0,%1,8,8,15\n\t"
- "rlwimi %0,%1,24,0,7"
- : "=r" (result)
- : "r" (value), "0" (value >> 24));
- return result;
-}
-
-#define __arch__swab16(x) ___arch__swab16(x)
-#define __arch__swab32(x) ___arch__swab32(x)
-
-/* The same, but returns converted value from the location pointer by addr. */
-#define __arch__swab16p(addr) ld_le16(addr)
-#define __arch__swab32p(addr) ld_le32(addr)
-
-/* The same, but do the conversion in situ, ie. put the value back to addr. */
-#define __arch__swab16s(addr) st_le16(addr,*addr)
-#define __arch__swab32s(addr) st_le32(addr,*addr)
-
-#endif /* __KERNEL__ */
-
-#ifndef __STRICT_ANSI__
-#define __BYTEORDER_HAS_U64__
-#endif
-
-#endif /* __GNUC__ */
-
-#include <linux/byteorder/big_endian.h>
-
-#endif /* _PPC64_BYTEORDER_H */
^ permalink raw reply
* [PATCH] powerpc: make cur_cpu_spec a single pointer instead of an array on ppc32
From: Kumar Gala @ 2005-09-27 20:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
If someone can test this on ppc32 and ppc32/SMP that would be helpful. I
tried this out on a 834x (603 core) and it works ok, but would like to
make sure it works on pmac & pmac/SMP. Also, this requires the previous
patch that unifies cputable.h
- kumar
---
Changed ppc32 so that cur_cpu_spec is just a single pointer for all CPUs.
Additionally, made call_setup_cpu check to see if the cpu_setup pointer
is NULL or not before calling the function. This lets remove the dummy
cpu_setup calls that just return.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 5624cf5d26b1c9318daceb92b605096cac58e206
tree 5ce3efa2a7c170406834f5d84786d1e1597cc87c
parent 1545c0ecc0c5f6bd96a1882e782f8a1f3c67179b
author Kumar K. Gala <kumar.gala@freescale.com> Tue, 27 Sep 2005 15:11:13 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Tue, 27 Sep 2005 15:11:13 -0500
arch/powerpc/kernel/head.S | 6 -----
arch/powerpc/oprofile/common.c | 6 ++---
arch/powerpc/platforms/powermac/pmac_setup.c | 2 +-
arch/ppc/kernel/cpu_setup_6xx.S | 2 --
arch/ppc/kernel/cpu_setup_power4.S | 2 --
arch/ppc/kernel/cputable.c | 33 ++++++++++----------------
arch/ppc/kernel/head.S | 6 -----
arch/ppc/kernel/misc.S | 22 ++++++++---------
arch/ppc/kernel/setup.c | 14 ++++++-----
arch/ppc/platforms/4xx/ebony.c | 2 +-
arch/ppc/platforms/pmac_setup.c | 2 +-
arch/ppc/platforms/radstone_ppc7d.c | 8 +++---
arch/ppc/syslib/ibm440gx_common.c | 6 ++---
include/asm-powerpc/cputable.h | 16 -------------
include/asm-powerpc/elf.h | 4 +--
15 files changed, 43 insertions(+), 88 deletions(-)
diff --git a/arch/powerpc/kernel/head.S b/arch/powerpc/kernel/head.S
--- a/arch/powerpc/kernel/head.S
+++ b/arch/powerpc/kernel/head.S
@@ -1059,7 +1059,6 @@ __secondary_start:
lis r3,-KERNELBASE@h
mr r4,r24
- bl identify_cpu
bl call_setup_cpu /* Call setup_cpu for this CPU */
#ifdef CONFIG_6xx
lis r3,-KERNELBASE@h
@@ -1109,11 +1108,6 @@ __secondary_start:
* Those generic dummy functions are kept for CPUs not
* included in CONFIG_6xx
*/
-_GLOBAL(__setup_cpu_power3)
- blr
-_GLOBAL(__setup_cpu_generic)
- blr
-
#if !defined(CONFIG_6xx) && !defined(CONFIG_POWER4)
_GLOBAL(__save_cpu_setup)
blr
diff --git a/arch/powerpc/oprofile/common.c b/arch/powerpc/oprofile/common.c
--- a/arch/powerpc/oprofile/common.c
+++ b/arch/powerpc/oprofile/common.c
@@ -155,8 +155,6 @@ static int op_powerpc_create_files(struc
int __init oprofile_arch_init(struct oprofile_operations *ops)
{
#ifndef __powerpc64__
- int cpu_id = smp_processor_id();
-
#ifdef CONFIG_FSL_BOOKE
model = &op_model_fsl_booke;
#else
@@ -167,9 +165,9 @@ int __init oprofile_arch_init(struct opr
if (NULL == cpu_type)
return -ENOMEM;
- sprintf(cpu_type, "ppc/%s", cur_cpu_spec[cpu_id]->cpu_name);
+ sprintf(cpu_type, "ppc/%s", cur_cpu_spec->cpu_name);
- model->num_counters = cur_cpu_spec[cpu_id]->num_pmcs;
+ model->num_counters = cur_cpu_spec->num_pmcs;
ops->cpu_type = cpu_type;
#else /* __powerpc64__ */
diff --git a/arch/powerpc/platforms/powermac/pmac_setup.c b/arch/powerpc/platforms/powermac/pmac_setup.c
--- a/arch/powerpc/platforms/powermac/pmac_setup.c
+++ b/arch/powerpc/platforms/powermac/pmac_setup.c
@@ -445,7 +445,7 @@ static int pmac_pm_enter(suspend_state_t
enable_kernel_fp();
#ifdef CONFIG_ALTIVEC
- if (cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC)
+ if (cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC)
enable_kernel_altivec();
#endif /* CONFIG_ALTIVEC */
diff --git a/arch/ppc/kernel/cpu_setup_6xx.S b/arch/ppc/kernel/cpu_setup_6xx.S
--- a/arch/ppc/kernel/cpu_setup_6xx.S
+++ b/arch/ppc/kernel/cpu_setup_6xx.S
@@ -17,8 +17,6 @@
#include <asm/asm-offsets.h>
#include <asm/cache.h>
-_GLOBAL(__setup_cpu_601)
- blr
_GLOBAL(__setup_cpu_603)
b setup_common_caches
_GLOBAL(__setup_cpu_604)
diff --git a/arch/ppc/kernel/cpu_setup_power4.S b/arch/ppc/kernel/cpu_setup_power4.S
--- a/arch/ppc/kernel/cpu_setup_power4.S
+++ b/arch/ppc/kernel/cpu_setup_power4.S
@@ -63,8 +63,6 @@ _GLOBAL(__970_cpu_preinit)
isync
blr
-_GLOBAL(__setup_cpu_power4)
- blr
_GLOBAL(__setup_cpu_ppc970)
mfspr r0,SPRN_HID0
li r11,5 /* clear DOZE and SLEEP */
diff --git a/arch/ppc/kernel/cputable.c b/arch/ppc/kernel/cputable.c
--- a/arch/ppc/kernel/cputable.c
+++ b/arch/ppc/kernel/cputable.c
@@ -14,23 +14,22 @@
#include <linux/sched.h>
#include <linux/threads.h>
#include <linux/init.h>
+#include <linux/module.h>
+
+#include <asm/oprofile_impl.h>
#include <asm/cputable.h>
-struct cpu_spec* cur_cpu_spec[NR_CPUS];
+struct cpu_spec* cur_cpu_spec = NULL;
-extern void __setup_cpu_601(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
-extern void __setup_cpu_603(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
-extern void __setup_cpu_604(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
-extern void __setup_cpu_750(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
-extern void __setup_cpu_750cx(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
-extern void __setup_cpu_750fx(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
-extern void __setup_cpu_7400(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
-extern void __setup_cpu_7410(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
-extern void __setup_cpu_745x(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
-extern void __setup_cpu_power3(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
-extern void __setup_cpu_power4(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
-extern void __setup_cpu_ppc970(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
-extern void __setup_cpu_generic(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
+extern void __setup_cpu_603(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_750cx(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_750fx(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_7400(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_7410(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_745x(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_ppc970(unsigned long offset, struct cpu_spec* spec);
#define CLASSIC_PPC (!defined(CONFIG_8xx) && !defined(CONFIG_4xx) && \
!defined(CONFIG_POWER3) && !defined(CONFIG_POWER4) && \
@@ -62,7 +61,6 @@ struct cpu_spec cpu_specs[] = {
PPC_FEATURE_UNIFIED_CACHE,
.icache_bsize = 32,
.dcache_bsize = 32,
- .cpu_setup = __setup_cpu_601
},
{ /* 603 */
.pvr_mask = 0xffff0000,
@@ -451,7 +449,6 @@ struct cpu_spec cpu_specs[] = {
.cpu_user_features = COMMON_PPC,
.icache_bsize = 32,
.dcache_bsize = 32,
- .cpu_setup = __setup_cpu_generic
},
#endif /* CLASSIC_PPC */
#ifdef CONFIG_PPC64BRIDGE
@@ -464,7 +461,6 @@ struct cpu_spec cpu_specs[] = {
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3
},
{ /* Power3+ */
.pvr_mask = 0xffff0000,
@@ -475,7 +471,6 @@ struct cpu_spec cpu_specs[] = {
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3
},
{ /* I-star */
.pvr_mask = 0xffff0000,
@@ -486,7 +481,6 @@ struct cpu_spec cpu_specs[] = {
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3
},
{ /* S-star */
.pvr_mask = 0xffff0000,
@@ -497,7 +491,6 @@ struct cpu_spec cpu_specs[] = {
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3
},
#endif /* CONFIG_PPC64BRIDGE */
#ifdef CONFIG_POWER4
diff --git a/arch/ppc/kernel/head.S b/arch/ppc/kernel/head.S
--- a/arch/ppc/kernel/head.S
+++ b/arch/ppc/kernel/head.S
@@ -1059,7 +1059,6 @@ __secondary_start:
lis r3,-KERNELBASE@h
mr r4,r24
- bl identify_cpu
bl call_setup_cpu /* Call setup_cpu for this CPU */
#ifdef CONFIG_6xx
lis r3,-KERNELBASE@h
@@ -1109,11 +1108,6 @@ __secondary_start:
* Those generic dummy functions are kept for CPUs not
* included in CONFIG_6xx
*/
-_GLOBAL(__setup_cpu_power3)
- blr
-_GLOBAL(__setup_cpu_generic)
- blr
-
#if !defined(CONFIG_6xx) && !defined(CONFIG_POWER4)
_GLOBAL(__save_cpu_setup)
blr
diff --git a/arch/ppc/kernel/misc.S b/arch/ppc/kernel/misc.S
--- a/arch/ppc/kernel/misc.S
+++ b/arch/ppc/kernel/misc.S
@@ -125,9 +125,8 @@ _GLOBAL(identify_cpu)
1:
addis r6,r3,cur_cpu_spec@ha
addi r6,r6,cur_cpu_spec@l
- slwi r4,r4,2
sub r8,r8,r3
- stwx r8,r4,r6
+ stw r8,0(r6)
blr
/*
@@ -186,19 +185,18 @@ _GLOBAL(do_cpu_ftr_fixups)
*
* Setup function is called with:
* r3 = data offset
- * r4 = CPU number
- * r5 = ptr to CPU spec (relocated)
+ * r4 = ptr to CPU spec (relocated)
*/
_GLOBAL(call_setup_cpu)
- addis r5,r3,cur_cpu_spec@ha
- addi r5,r5,cur_cpu_spec@l
- slwi r4,r24,2
- lwzx r5,r4,r5
+ addis r4,r3,cur_cpu_spec@ha
+ addi r4,r4,cur_cpu_spec@l
+ lwz r4,0(r4)
+ add r4,r4,r3
+ lwz r5,CPU_SPEC_SETUP(r4)
+ cmpi 0,r5,0
add r5,r5,r3
- lwz r6,CPU_SPEC_SETUP(r5)
- add r6,r6,r3
- mtctr r6
- mr r4,r24
+ beqlr
+ mtctr r5
bctr
#if defined(CONFIG_CPU_FREQ_PMAC) && defined(CONFIG_6xx)
diff --git a/arch/ppc/kernel/setup.c b/arch/ppc/kernel/setup.c
--- a/arch/ppc/kernel/setup.c
+++ b/arch/ppc/kernel/setup.c
@@ -188,18 +188,18 @@ int show_cpuinfo(struct seq_file *m, voi
seq_printf(m, "processor\t: %d\n", i);
seq_printf(m, "cpu\t\t: ");
- if (cur_cpu_spec[i]->pvr_mask)
- seq_printf(m, "%s", cur_cpu_spec[i]->cpu_name);
+ if (cur_cpu_spec->pvr_mask)
+ seq_printf(m, "%s", cur_cpu_spec->cpu_name);
else
seq_printf(m, "unknown (%08x)", pvr);
#ifdef CONFIG_ALTIVEC
- if (cur_cpu_spec[i]->cpu_features & CPU_FTR_ALTIVEC)
+ if (cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC)
seq_printf(m, ", altivec supported");
#endif
seq_printf(m, "\n");
#ifdef CONFIG_TAU
- if (cur_cpu_spec[i]->cpu_features & CPU_FTR_TAU) {
+ if (cur_cpu_spec->cpu_features & CPU_FTR_TAU) {
#ifdef CONFIG_TAU_AVERAGE
/* more straightforward, but potentially misleading */
seq_printf(m, "temperature \t: %u C (uncalibrated)\n",
@@ -754,12 +754,12 @@ void __init setup_arch(char **cmdline_p)
* for a possibly more accurate value.
*/
if (cpu_has_feature(CPU_FTR_SPLIT_ID_CACHE)) {
- dcache_bsize = cur_cpu_spec[0]->dcache_bsize;
- icache_bsize = cur_cpu_spec[0]->icache_bsize;
+ dcache_bsize = cur_cpu_spec->dcache_bsize;
+ icache_bsize = cur_cpu_spec->icache_bsize;
ucache_bsize = 0;
} else
ucache_bsize = dcache_bsize = icache_bsize
- = cur_cpu_spec[0]->dcache_bsize;
+ = cur_cpu_spec->dcache_bsize;
/* reboot on panic */
panic_timeout = 180;
diff --git a/arch/ppc/platforms/4xx/ebony.c b/arch/ppc/platforms/4xx/ebony.c
--- a/arch/ppc/platforms/4xx/ebony.c
+++ b/arch/ppc/platforms/4xx/ebony.c
@@ -91,7 +91,7 @@ ebony_calibrate_decr(void)
* on Rev. C silicon then errata forces us to
* use the internal clock.
*/
- if (strcmp(cur_cpu_spec[0]->cpu_name, "440GP Rev. B") == 0)
+ if (strcmp(cur_cpu_spec->cpu_name, "440GP Rev. B") == 0)
freq = EBONY_440GP_RB_SYSCLK;
else
freq = EBONY_440GP_RC_SYSCLK;
diff --git a/arch/ppc/platforms/pmac_setup.c b/arch/ppc/platforms/pmac_setup.c
--- a/arch/ppc/platforms/pmac_setup.c
+++ b/arch/ppc/platforms/pmac_setup.c
@@ -448,7 +448,7 @@ static int pmac_pm_enter(suspend_state_t
enable_kernel_fp();
#ifdef CONFIG_ALTIVEC
- if (cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC)
+ if (cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC)
enable_kernel_altivec();
#endif /* CONFIG_ALTIVEC */
diff --git a/arch/ppc/platforms/radstone_ppc7d.c b/arch/ppc/platforms/radstone_ppc7d.c
--- a/arch/ppc/platforms/radstone_ppc7d.c
+++ b/arch/ppc/platforms/radstone_ppc7d.c
@@ -1185,18 +1185,18 @@ static void __init ppc7d_setup_arch(void
ROOT_DEV = Root_HDA1;
#endif
- if ((cur_cpu_spec[0]->cpu_features & CPU_FTR_SPEC7450) ||
- (cur_cpu_spec[0]->cpu_features & CPU_FTR_L3CR))
+ if ((cur_cpu_spec->cpu_features & CPU_FTR_SPEC7450) ||
+ (cur_cpu_spec->cpu_features & CPU_FTR_L3CR))
/* 745x is different. We only want to pass along enable. */
_set_L2CR(L2CR_L2E);
- else if (cur_cpu_spec[0]->cpu_features & CPU_FTR_L2CR)
+ else if (cur_cpu_spec->cpu_features & CPU_FTR_L2CR)
/* All modules have 1MB of L2. We also assume that an
* L2 divisor of 3 will work.
*/
_set_L2CR(L2CR_L2E | L2CR_L2SIZ_1MB | L2CR_L2CLK_DIV3
| L2CR_L2RAM_PIPE | L2CR_L2OH_1_0 | L2CR_L2DF);
- if (cur_cpu_spec[0]->cpu_features & CPU_FTR_L3CR)
+ if (cur_cpu_spec->cpu_features & CPU_FTR_L3CR)
/* No L3 cache */
_set_L3CR(0);
diff --git a/arch/ppc/syslib/ibm440gx_common.c b/arch/ppc/syslib/ibm440gx_common.c
--- a/arch/ppc/syslib/ibm440gx_common.c
+++ b/arch/ppc/syslib/ibm440gx_common.c
@@ -236,9 +236,9 @@ void __init ibm440gx_l2c_setup(struct ib
/* Disable L2C on rev.A, rev.B and 800MHz version of rev.C,
enable it on all other revisions
*/
- if (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. A") == 0 ||
- strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. B") == 0
- || (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. C")
+ if (strcmp(cur_cpu_spec->cpu_name, "440GX Rev. A") == 0 ||
+ strcmp(cur_cpu_spec->cpu_name, "440GX Rev. B") == 0
+ || (strcmp(cur_cpu_spec->cpu_name, "440GX Rev. C")
== 0 && p->cpu > 667000000))
ibm440gx_l2c_disable();
else
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -25,11 +25,7 @@
struct cpu_spec;
struct op_powerpc_model;
-#ifdef __powerpc64__
typedef void (*cpu_setup_t)(unsigned long offset, struct cpu_spec* spec);
-#else /* __powerpc64__ */
-typedef void (*cpu_setup_t)(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
-#endif /* __powerpc64__ */
struct cpu_spec {
/* CPU is matched via (PVR & pvr_mask) == pvr_value */
@@ -51,23 +47,15 @@ struct cpu_spec {
* BHT, SPD, etc... from head.S before branching to identify_machine
*/
cpu_setup_t cpu_setup;
-#ifdef __powerpc64__
/* Used by oprofile userspace to select the right counters */
char *oprofile_cpu_type;
/* Processor specific oprofile operations */
struct op_powerpc_model *oprofile_model;
-#endif /* __powerpc64__ */
};
-extern struct cpu_spec cpu_specs[];
-
-#ifdef __powerpc64__
extern struct cpu_spec *cur_cpu_spec;
-#else /* __powerpc64__ */
-extern struct cpu_spec *cur_cpu_spec[];
-#endif /* __powerpc64__ */
#endif /* __ASSEMBLY__ */
@@ -398,11 +386,7 @@ static inline int cpu_has_feature(unsign
{
return (CPU_FTRS_ALWAYS & feature) ||
(CPU_FTRS_POSSIBLE
-#ifndef __powerpc64__
- & cur_cpu_spec[0]->cpu_features
-#else
& cur_cpu_spec->cpu_features
-#endif
& feature);
}
diff --git a/include/asm-powerpc/elf.h b/include/asm-powerpc/elf.h
--- a/include/asm-powerpc/elf.h
+++ b/include/asm-powerpc/elf.h
@@ -212,15 +212,13 @@ extern int dump_task_fpu(struct task_str
/* ELF_HWCAP yields a mask that user programs can use to figure out what
instruction set this cpu supports. This could be done in userspace,
but it's not easy, and we've already done it here. */
-#ifdef __powerpc64__
# define ELF_HWCAP (cur_cpu_spec->cpu_user_features)
+#ifdef __powerpc64__
# define ELF_PLAT_INIT(_r, load_addr) do { \
memset(_r->gpr, 0, sizeof(_r->gpr)); \
_r->ctr = _r->link = _r->xer = _r->ccr = 0; \
_r->gpr[2] = load_addr; \
} while (0)
-#else
-# define ELF_HWCAP (cur_cpu_spec[0]->cpu_user_features)
#endif /* __powerpc64__ */
/* This yields a string that ld.so will use to load implementation
^ permalink raw reply
* Re: CPM2 early console
From: Kalle Pokki @ 2005-09-27 20:35 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <384d09b865d454875c447cc02c89d001@embeddedalley.com>
Dan Malek wrote:
>
> On Sep 27, 2005, at 10:11 AM, Kalle Pokki wrote:
>
>> Any ideas what can set the bootmem memory as cached?
>
> All of memory is always cached on 82xx. Which is fine
> since the cache controller keeps the processor core
> and peripherals coherent in hardware.
OK. Then the question really is why isn't the cache controller enforcing
coherency between the G2_LE core and the CPM. While trying to debug the
console driver I wrote a really simple SCC driver separated from the
rest of the kernel in order to have a usable debug printf. And I
couldn't get any buffers printed through the SCC until I started to use
buffers in DPRAM. The CPM just didn't see anything I wrote to the
buffers. The same thing seems to bother at least the console driver and
the FCC ethernet driver (though they don't work at all for me at the
moment..)
I think it is obvious I have misconfigured something, but at this point
I am not even sure if it is something I should have initialised in the
boot loader.
^ permalink raw reply
* Re: CPM2 early console
From: Dan Malek @ 2005-09-27 20:48 UTC (permalink / raw)
To: Kalle Pokki; +Cc: linuxppc-embedded
In-Reply-To: <4339AD01.30708@iki.fi>
On Sep 27, 2005, at 4:35 PM, Kalle Pokki wrote:
> OK. Then the question really is why isn't the cache controller
> enforcing coherency between the G2_LE core and the CPM.
Is the GBL and DTB set properly in the function code registers
of the SCC parameter ram?
-- Dan
^ permalink raw reply
* Re: [PATCH] powerpc: merge byteorder.h
From: Gabriel Paubert @ 2005-09-27 21:15 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <Pine.LNX.4.61.0509271427090.21928@cde-tx32-ldt329.sps.mot.com>
On Tue, Sep 27, 2005 at 02:28:56PM -0500, Becky Bruce wrote:
> powerpc: Merge byteorder.h
>
> Essentially adopts the 64-bit version of this file. The 32-bit version had
> been using unsigned ints for arguments/return values that were actually
> only 16 bits - the new file uses __u16 for these items as in the 64-bit
> version of the header. The order of some of the asm constraints
> in the 64-bit version was slightly different than the 32-bit version,
> but they produce identical code.
>
> Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
>
> ---
> commit 01344596fdecbe2b97e122b6a50570a19218cd2f
> tree ccdf20534198e69459d95f21b8f45aafc00e8238
> parent d407c9f3f6f3c84d9daec257f9a2550aacbd2892
> author Becky Bruce <becky.bruce@freescale.com> Tue, 27 Sep 2005 14:04:44 -0500
> committer Becky Bruce <becky.bruce@freescale.com> Tue, 27 Sep 2005 14:04:44 -0500
>
> include/asm-powerpc/byteorder.h | 89 +++++++++++++++++++++++++++++++++++++++
> include/asm-ppc/byteorder.h | 76 ---------------------------------
> include/asm-ppc64/byteorder.h | 86 --------------------------------------
> 3 files changed, 89 insertions(+), 162 deletions(-)
>
> diff --git a/include/asm-powerpc/byteorder.h b/include/asm-powerpc/byteorder.h
> new file mode 100644
> --- /dev/null
> +++ b/include/asm-powerpc/byteorder.h
> @@ -0,0 +1,89 @@
> +#ifndef _ASM_POWERPC_BYTEORDER_H
> +#define _ASM_POWERPC_BYTEORDER_H
> +
> +/*
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include <asm/types.h>
> +#include <linux/compiler.h>
> +
> +#ifdef __GNUC__
> +#ifdef __KERNEL__
> +
> +static __inline__ __u16 ld_le16(const volatile __u16 *addr)
> +{
> + __u16 val;
> +
> + __asm__ __volatile__ ("lhbrx %0,0,%1" : "=r" (val) : "r" (addr), "m" (*addr));
> + return val;
> +}
> +
> +static __inline__ void st_le16(volatile __u16 *addr, const __u16 val)
> +{
> + __asm__ __volatile__ ("sthbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
> +}
> +
> +static __inline__ __u32 ld_le32(const volatile __u32 *addr)
> +{
> + __u32 val;
> +
> + __asm__ __volatile__ ("lwbrx %0,0,%1" : "=r" (val) : "r" (addr), "m" (*addr));
> + return val;
> +}
> +
> +static __inline__ void st_le32(volatile __u32 *addr, const __u32 val)
> +{
> + __asm__ __volatile__ ("stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
> +}
> +
> +static __inline__ __attribute_const__ __u16 ___arch__swab16(__u16 value)
> +{
> + __u16 result;
> +
> + __asm__("rlwimi %0,%1,8,16,23"
> + : "=r" (result)
> + : "r" (value), "0" (value >> 8));
> + return result;
> +}
This needs 2 registers where one is enough and often
adds a truncation to 16 bit of results in the generated
code. Consider instead:
__u32 result;
__asm__(" rlwimi %0,%0,16,8,15 # ??12->?212\n"
: =r(result) : "0"(value));
return (__u16)(result>>8);
GCC will combine the result>>8 with the truncation
to the lower sixteen bits, often saving one instruction.
This will likely generate worse code if you really need
to keep both the original value and the swapped one, but
this should not be the common case.
> +
> +static __inline__ __attribute_const__ __u32 ___arch__swab32(__u32 value)
> +{
> + __u32 result;
> +
> + __asm__("rlwimi %0,%1,24,16,23\n\t"
> + "rlwimi %0,%1,8,8,15\n\t"
> + "rlwimi %0,%1,24,0,7"
> + : "=r" (result)
> + : "r" (value), "0" (value >> 24));
> + return result;
> +}
That one can be improved too, in only needs one
rotlwi (rlwinm withou any mask) and 2 rlwimi:
__asm__(" rotlwi %0,%1,8 # 1234 -> 2341\n"
" rlwimi %0,%1,24,0,7 \n"
" rlwimi %0,%1,24,16,23 \n"
: "=&r" (result) : r(value))
Notes:
- reformat as you like, but I prefer the tab at the
beginning of every line, otherwise the assembly output
does not look right. I always add a \n at the end
just in case (do all versions of GCC add it or not?).
- the earlyclobber (&) is really necessary otherwise
GCC might allocate the same register for input and
output for __arch_swab32.
What should really be implemented in GCC is a recognizer
for the manipulations that can easily be mapped to
a single rlwimi instruction. But it is too complex
for the standard combiner IIRC.
Regards,
Gabriel
^ permalink raw reply
* Re: Starting the arch/powerpc merge
From: Benjamin Herrenschmidt @ 2005-09-28 0:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17209.817.732159.375607@cargo.ozlabs.ibm.com>
On Tue, 2005-09-27 at 18:30 +1000, Paul Mackerras wrote:
> Christoph Hellwig writes:
>
> > What about just dropping POWER3/4 support in 32bit mode?
>
> Yes... I'm getting very close to deciding to do that. In fact POWER3
> isn't too bad, since it still has BATs, but POWER4/PPC970 would be
> tricky.
>
> Does anyone on these lists have any major objections if we drop
> support for 32-bit kernels on POWER3 and POWER4/PPC970?
I've stopped supporting G5 on 32 bits kernel for some time now, I have
absolutely no problem just dropping the POWER4 support in 32 bits kernel
in the merged tree.
Ben.
^ permalink raw reply
* Re: Starting the arch/powerpc merge
From: Benjamin Herrenschmidt @ 2005-09-28 0:07 UTC (permalink / raw)
To: dostrow; +Cc: linuxppc-dev, Christopher Friesen, linuxppc64-dev
In-Reply-To: <1127842184.7811.61.camel@Memoria.anyarch.net>
> The way I set that up is still young...and has some issues (most of
> which should be fixed by the ppc && ppc64 -> powerpc merge). From what I
> have tested, it does work perfectly fine with 6.8.2...I haven't run into
> any issues. I maintain that profile so if there are issues please take
> them off this list...feel free to send them to ppc64@gentoo.org or open
> a bug at bugs.gentoo.org and assign it to the ppc64 group. I'll see it
> either way.
I'm running a 32 bits X.org 6.8.99 from CVS with the r300 DRI stuff
etc... on a G5 with 64 bits kernel without trouble. Paulus did the same
with a 64 bits X.
Ben.
^ permalink raw reply
* Driver radeonfb for ATI M6 video controller
From: Roberto Pavon Sierra @ 2005-09-28 7:02 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
i try to initialize my video card ATI M6. I installed the driver radeonfb
(kernel linux 2.6.12) for ATI M6 in ppc, but this driver cann´t read the
BIOS-serial flash and takes always default values and not the initialization
values from the BIOS.
Can someone help me with this problem? must i install too a XF86-emulator in
my board (ppc 440GX)? Can i initialize this video card without BIOS?
Best regards,
Roberto
^ permalink raw reply
* RE: How to use SPE on MPC8541
From: Gérard Guével @ 2005-09-28 8:02 UTC (permalink / raw)
To: 'Andy Fleming'; +Cc: linuxppc-embedded
In-Reply-To: <B310BDDC-A773-4D85-8314-F4320C5FA90C@freescale.com>
Andy,
> Your driver runs in kernel space. The kernel has the SPE bit off.
> The MSR state is process-specific. If the code executes, the
> MSR bit
> is set. Why do you want to see if the bit is set?
OK, this is a bad idea to use a driver to check the msr register.
I don't especially want to see if the bit is set, I just want
to improve the board performance for a Linux application :-).
To check the performance, I used the Dhrystone 2.1 benchmark with
the standard glibc (strcpy, strcmp, ...) on one part, and with
the freescale SPE library on the other part (vstrcpy, vstrcmp, ...).
I already verified in the binary elf file that the right functions are
called.
When I run the benchmark, I get the same MIPS with and without SPE code.
I ran the same benchmark on the same board without OS,
with a personal pseudo glibc, I have the same MIPS as under Linux,
with the freescale library, I gain 40% of perf.
That's I want to retreive with the Linux OS.
Regards
Gérard
^ permalink raw reply
* RE: How to use SPE on MPC8541
From: Fillod Stephane @ 2005-09-28 8:12 UTC (permalink / raw)
To: linuxppc-embedded
Bonjour G=E9rard,
G=E9rard Gu=E9vel wrote:
>I don't especially want to see if the bit is set, I just want
>to improve the board performance for a Linux application :-).
Do you know where your CPU is spending much of its time?
It looks like a job for OProfile. Support for e500 exists in 2.6.x=20
thanks to the fine folks of Freescale. We appreciate their involvement=20
in OSS community.
>To check the performance, I used the Dhrystone 2.1 benchmark=20
I like the lmbench microbenchmark too. It depends on what profile
is your application (instruction mix, library calls, cache usage, =
paging,..)
>with the standard glibc (strcpy, strcmp, ...) on one part, and with
>the freescale SPE library on the other part (vstrcpy, vstrcmp, ...).
Will the SPE enhanced C library calls will be integrated in Glibc one =
day?=20
Regards,
Stephane
^ permalink raw reply
* Installation XF86 in powerpc
From: Roberto Pavon Sierra @ 2005-09-28 8:44 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
i work in my Master Thesis with a custom board ppc 440GX and i try to
install xfree86 on my board. I work with kernel 2.6.12 and i use to boot an
uImage-Boot.
How can i install the xfree86 on my board?
Best regards,
Roberto Pavón
^ permalink raw reply
* Re: Driver radeonfb for ATI M6 video controller
From: Stefan Nickl @ 2005-09-28 8:49 UTC (permalink / raw)
To: Roberto Pavon Sierra; +Cc: linuxppc-embedded
In-Reply-To: <000701c5c3fa$99fcd090$8700a8c0@SN7855>
On Wed, 2005-09-28 at 09:02 +0200, Roberto Pavon Sierra wrote:
> Hi,
>=20
> i try to initialize my video card ATI M6. I installed the driver radeonfb
> (kernel linux 2.6.12) for ATI M6 in ppc, but this driver cann=B4t read th=
e
> BIOS-serial flash and takes always default values and not the initializat=
ion
> values from the BIOS.
> Can someone help me with this problem? must i install too a XF86-emulator=
in
> my board (ppc 440GX)? Can i initialize this video card without BIOS?
We tried that too :-} Without BIOS initialisation, the chip won't work.
The x86 emulation approach was led by a company
http://www.scitechsoft.com,
but I seems they got to know the chips well enough in the meantime to
program them directly...
The emulator was based on x86emu, and the last time I saw it was in one
of the {linux,free}bios projects. I actually ran it once with a M6 BIOS
on a PPC,
but it didn't work right away and I didn't wanted to dig in there at the
time.
While I would be interested to hear about any progess you can make with
ATI on PPC, I'll tell that we gave up on that and settled for another
chip.
You may want to have a look at Siliconmotion's SM501 or Fujitsu's
Coral-P.
Regards,
--=20
Stefan Nickl
Kontron Modular Computers
^ permalink raw reply
* Re: linuxppc-2.4.30-pre1 crashes with root fs on Xilinx SystemACE
From: Peter Ryser @ 2005-09-28 9:32 UTC (permalink / raw)
To: Tony Lee; +Cc: linuxppc-embedded
In-Reply-To: <470b639705083118114bcd2070@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3520 bytes --]
Some time ago we did some tests with bonnie++ on Linux running on the
PPC405 in a Virtex-II Pro FPGA. You can expect the following performance:
Read peak: 629 KB/s
Write peak: 299 KB/s
Not considering network overhead, a 10MB file should take less than a
minute to update.
- Peter
Tony Lee wrote:
> Keith,
>
> Some suggestions, before you verify your hw board/FPGA works fine with
> SYSACE,
> * don't use sysace as root fs.
> * use a ram fs as root fs.
> * Next, load sysace driver a loadable driver module. It works, I
> tried it.
> * check mount read only and see if it works.
> * Next, mount it writable.
>
> We have some issues with sysace driver initially, everything works out
> fine later.
> There were small errors in our HW layout.
>
> I had to hack the sysace driver left and right to id the problem. But
> at the
> end, after I fixed the layout problem from the fpga's ucf file, the
> original driver
> run perfectly without any modification.
>
> In my experiences, the ppc linux distribution and its linux sysace
> driver are good
> if everything is setup correctly.
>
> One minor issues: The sysace driver's write performance sucks. I
> have to explain
> to others why the upgrade 10 MBytes files with usb flash writer takes
> tens of
> seconds. When we do it from linux (nfs or ftp), it tooks minutes to sync.
>
> Peter, maybe you can push the xilinx a bit on sysace write
> performance? :-)
>
> -Tony
>
> On 8/29/05, Peter Ryser <peter.ryser@xilinx.com
> <mailto:peter.ryser@xilinx.com>> wrote:
>
> Hi Keith,
>
> I sent you a private email but for other interested people:
> Downloading the latest linuxppc-2.4 kernel I could boot from and
> access
> System ACE CF without problems on a ML403 (Virtex-4, 4VFX12) and a
> ML310
> (Virtex-II Pro, 2VP30) using EDK 7.1.2. In both cases I started with
> config_xilinx_ml300.
>
> - Peter
>
>
>
> Keith J Outwater wrote:
>
> >Hello -
> >Per a previous suggestion from this list, I rsynced the linuxppc-2.4
> >kernel sources from MontaVista and modified the kernel to run on
> my custom
> >ppc405/VirtexII Pro based system with U-Boot as the bootloader.
> >When I try to use the SystemACE device as the root filesystem,
> the kernel
> >crashes with a sig 11. Looking at the 'oops' output it appears the
> >SystemACE driver may be to blame. The crash is random -
> sometimes I get
> >all the way to login as root and then things crash on a file copy
> or a
> >file read.
> >Before I start digging deeper, is anyone running a VirtexIIPro based
> >system with the root filesystem in the CF card attached to a
> SystemACE?
> >I'm wondering if I really have the best kernel and SystemACE driver.
> >BTW, I'm developing the hardware design using Xilinx EDK 7.02i.
> >Thanks,
> >Keith
> >_______________________________________________
> >Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> >
> >
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> <https://ozlabs.org/mailman/listinfo/linuxppc-embedded>
>
>
>
>
> --
> -Tony
> Having fun with FPGA HW + ppc + Linux
[-- Attachment #2: Type: text/html, Size: 4516 bytes --]
^ permalink raw reply
* Re: CPM2 early console
From: Kalle Pokki @ 2005-09-28 10:20 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <714c16295fbfa97caafd1d0aa3a5932e@embeddedalley.com>
Dan Malek wrote:
> On Sep 27, 2005, at 4:35 PM, Kalle Pokki wrote:
>
>> OK. Then the question really is why isn't the cache controller
>> enforcing coherency between the G2_LE core and the CPM.
>
> Is the GBL and DTB set properly in the function code registers
> of the SCC parameter ram?
The 60x bus is used, but snooping wasn't enabled before.
However, even after enabling snooping it still doesn't work right. If
I'm just within my boot loader I still cannot use e.g. the SMC with WIMG
bits 0010 and the GBL 1. If I set the write-through in WIMG bits as
1010, it works. The core now sees the RX buffers from the CPM and, of
course, my TX buffers since they are written to the memory.
I guess Linux remaps the RAM as copy-back. But snooping should work with
copy-back caches, shouldn't it?
^ permalink raw reply
* Re: Source of xparameter_ml300.h
From: Peter Ryser @ 2005-09-28 9:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <430C7C3A.4000601@ru.mvista.com>
Please have a look at XAPP765
(http://direct.xilinx.com/bvdocs/appnotes/xapp765.pdf) and the EDK
documentation to see how this works. The latest MLD to create a BSP for
a linuxppc-2.4 kernel is linuxppc_mvl31_v1_01_a. linuxppc_mvl31_v1_00_a
works too but everything else is not up-to-date.
The documentation and tutorials for the ML310 board are also an
excellent source of information how to get a Linux kernel up and running
on Virtex-II Pro (see http://www.xilinx.com/ml310).
The reference design for the ML403 is yet another source of information
(http://www.xilinx.com/ml403). Have a look at the reference design users
guide.
Using the MLD (tcl script) is much less error-prone than any other
method that involves changing the files by hand. It's a little bit of a
learning curve but once mastered it just works.
- Peter
Andrei Konovalov wrote:
> Grant Likely wrote:
>
>> Does anyone know the origin of xparameter_ml300.h? The
>> Xilinx EDK generates an xparameters.h file for each design, but the
>> structure of the file changes between releases.
>>
>> I want to know if xparameters_ml300.h is the exact output produced by
>> EDK or if stuff was changed before it was submitted to the mainline
>> tree. (ie. all the stuff under the "linux redefines" comment block)
>
>
> EDK can also generate the "Linux BSP".
> In this case EDK uses the scripts from (depending on your setup)
> /opt/xilinx/edk/7.1/sw/ThirdParty/bsp/linux_v2_00_b/data/
> In particular, linux_v2_1_0.tcl adds those "linux redefines"
> and renames xparameters.h to xparameters_ml300.h.
>
>> Also, where can I get the bitstream/systemace file that matches
>> xparameters_ml300.h?
>
>
> The most reliable way is to generate both (bitstream and
> xparameters_ml300.h) by yourself. :)
>
> But if you are speaking about the xparameters_ml300.h in the community
> trees (linuxppc-2.4 and the 2.6 one from kernel.org), this file
> is for the reference design by Xilinx:
>
> http://www.xilinx.com/ise/embedded/edk6_2docs/ml300_edk3.zip
>
>> I've got a custom ml300 image that I'm regression
>> testing against, but I'd like to also test against some form of 'stock'
>> image. :)
>>
>> Thanks,
>> g.
>
>
> Thanks,
> Andrei
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* booting and mounting PCIIDE: kernel access of bad area
From: KokHow Teh @ 2005-09-28 10:01 UTC (permalink / raw)
To: linuxppc-embedded
Hi;
I have rebuilt arabella linux kernel with PCI IDE support. However,
the kernel bootup crashes with "kernel access of bad area" message. I think
it has something to do with the IDE base addess setup. I have tried to
change the ide0=base,ctl but to no avail. Hope you are able to advise me on
that. Thanks.
Regards,
TEH
u-boot> diskboot $loadaddr 0:1
Loading from IDE device 0, partition 1: Name: hda1
Type: U-Boot
Image Name: Linux Kernel Image
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 893382 Bytes = 872.4 kB
Load Address: 00000000
Entry Point: 00000000
u-boot> bootm
## Booting image at 00100000 ...
Image Name: Linux Kernel Image
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 893382 Bytes = 872.4 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
MPC82xxADS/PQ2FADS board support by Arabella
Memory BAT mapping: BAT2=32Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.26 (root@ShrekII.marconi.com) (gcc version 3.3.2) #6 Wed
Sep 28 11:58:24 MYT 2005
ADS setup arch
MPC82xx PCI bridge initialization
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/hda2 rw ide0=0x1f0,0x3f6
ide_setup: ide0=0x1f0,0x3f6
ADS init IRQ. NR_IRQS=256
PIC: fully preemptible IRQ mode
ADS time init
ADS calibrate decrementer. FREQ=100000000, tb_ticks_per_jiffy=250000
Calibrating delay loop... 266.24 BogoMIPS
Memory: 30252k available (1384k kernel code, 472k data, 232k init, 0k
highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
PCI: moved device 00:16.0 resource 6 (7201) to 90000000
PCI: moved device 00:16.0 resource 4 (101) to 0
PCI: moved device 00:16.0 resource 0 (101) to 10
PCI: moved device 00:16.0 resource 2 (101) to 10
PCI: moved device 00:16.0 resource 1 (101) to 20
PCI: moved device 00:16.0 resource 3 (101) to 20
ADS init
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
pty: 256 Unix98 ptys configured
Generic RTC Driver v1.07
devsoc: devsoc_init:
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Oops: kernel access of bad area, sig: 11
NIP: C00BC0B0 XER: 20000000 LR: C00BC0A4 SP: C02F1F20 REGS: c02f1e70 TRAP:
0300 Not tainted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000CFB, DSISR: 22000000
TASK = c02f0000[1] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: 00000001 C02F1F20 C02F0000 00000001 00009032 00000001 00000832
00000000
GPR08: C01E0000 C01B0000 C01E0000 00000000 C01E0000 FFFFFFFF 01FC5000
00000000
GPR16: 00000001 00000001 FFFFFFFF 007FFF00 003FF000 00000000 00000001
01B78978
GPR24: 00000000 00000000 40000000 00000000 007FFF00 C01E0000 C01B067C
C01E0000
Call backtrace:
C0197464 C01A7658 C01A88B8 C01A8940 C01A898C C019E684 C0003970
C000820C
Kernel panic: Attempted to kill init!
<0>Rebooting in 180 seconds..
^ 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