* Re: [PATCH 3/5 v2] Add the platform device support with RapidIO to MPC8641HPCN platform.
From: Arnd Bergmann @ 2007-06-28 14:47 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <46B96294322F7D458F9648B60E15112C6F31B2@zch01exm26.fsl.freescale.net>
On Thursday 28 June 2007, Zhang Wei-r63237 wrote:
> > > +static __init int mpc86xx_of_device_init(void)
> > > +{
> > > +=A0=A0=A0=A0=A0=A0=A0return of_platform_bus_probe(NULL, mpc86xx_of_i=
ds, NULL);
> > > +}
> >=20
> > This will add any devices below the "fsl,rapidio-delta" device
> > as an of_device. Is that what you actually want? I would guess that
> > you want to add the bridge itself, not the devices below it.
> >=20
> > Is the rapidio device at the root of the device tree, and if so, why
> > not under the soc bus?
> >=20
>=20
> RapidIO is rather a bus that a device although these is no other nodes de=
fined in its sector now.
>=20
That's exactly my point. The meaning of of_platform_bus_probe() is 'add all
direct children of these nodes', not 'add these nodes', although it
happens to do that in the process.
Of course, looking at the device tree, rapidio is a device, not a bus,
because it does not have a device_type and it does not have any children
of its own.
Arnd <><
^ permalink raw reply
* Re: powerpc stacktrace and lockdep support
From: Johannes Berg @ 2007-06-28 16:20 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <1182970829.4769.62.camel@johannes.berg>
This one doesn't break 32-bit build by simply disabling irqtrace for
32-bit.
---
arch/powerpc/Kconfig | 9 ++++++
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/entry_64.S | 24 +++++++++++++++++
arch/powerpc/kernel/head_64.S | 54 ++++++++++++++++++++++++++++++++--------
arch/powerpc/kernel/irq.c | 2 -
arch/powerpc/kernel/irqtrace.S | 47 ++++++++++++++++++++++++++++++++++
arch/powerpc/kernel/ppc_ksyms.c | 2 -
arch/powerpc/kernel/setup_64.c | 6 ++++
include/asm-powerpc/hw_irq.h | 14 +++++-----
include/asm-powerpc/irqflags.h | 13 ---------
include/asm-powerpc/rwsem.h | 34 +++++++++++++++++++------
include/asm-powerpc/spinlock.h | 1
12 files changed, 167 insertions(+), 40 deletions(-)
--- linux-2.6-git32.orig/arch/powerpc/Kconfig 2007-06-28 14:53:58.603430447 +0200
+++ linux-2.6-git32/arch/powerpc/Kconfig 2007-06-28 14:58:02.683430447 +0200
@@ -38,6 +38,15 @@ config STACKTRACE_SUPPORT
bool
default y
+config TRACE_IRQFLAGS_SUPPORT
+ bool
+ depends on PPC64
+ default y
+
+config LOCKDEP_SUPPORT
+ bool
+ default y
+
config RWSEM_GENERIC_SPINLOCK
bool
--- linux-2.6-git32.orig/arch/powerpc/kernel/irq.c 2007-06-28 14:53:58.604430447 +0200
+++ linux-2.6-git32/arch/powerpc/kernel/irq.c 2007-06-28 14:48:38.709430447 +0200
@@ -114,7 +114,7 @@ static inline void set_soft_enabled(unsi
: : "r" (enable), "i" (offsetof(struct paca_struct, soft_enabled)));
}
-void local_irq_restore(unsigned long en)
+void raw_local_irq_restore(unsigned long en)
{
/*
* get_paca()->soft_enabled = en;
--- linux-2.6-git32.orig/arch/powerpc/kernel/ppc_ksyms.c 2007-06-28 14:53:58.678430447 +0200
+++ linux-2.6-git32/arch/powerpc/kernel/ppc_ksyms.c 2007-06-28 14:49:24.887430447 +0200
@@ -50,7 +50,7 @@
#endif
#ifdef CONFIG_PPC64
-EXPORT_SYMBOL(local_irq_restore);
+EXPORT_SYMBOL(raw_local_irq_restore);
#endif
#ifdef CONFIG_PPC32
--- linux-2.6-git32.orig/include/asm-powerpc/hw_irq.h 2007-06-28 14:53:58.730430447 +0200
+++ linux-2.6-git32/include/asm-powerpc/hw_irq.h 2007-06-28 14:58:41.508430447 +0200
@@ -27,7 +27,7 @@ static inline unsigned long local_get_fl
return flags;
}
-static inline unsigned long local_irq_disable(void)
+static inline unsigned long raw_local_irq_disable(void)
{
unsigned long flags, zero;
@@ -39,14 +39,15 @@ static inline unsigned long local_irq_di
return flags;
}
-extern void local_irq_restore(unsigned long);
+extern void raw_local_irq_restore(unsigned long);
extern void iseries_handle_interrupts(void);
-#define local_irq_enable() local_irq_restore(1)
-#define local_save_flags(flags) ((flags) = local_get_flags())
-#define local_irq_save(flags) ((flags) = local_irq_disable())
+#define raw_local_irq_enable() raw_local_irq_restore(1)
+#define raw_local_save_flags(flags) ((flags) = local_get_flags())
+#define raw_local_irq_save(flags) ((flags) = raw_local_irq_disable())
-#define irqs_disabled() (local_get_flags() == 0)
+#define raw_irqs_disabled() (local_get_flags() == 0)
+#define raw_irqs_disabled_flags(flags) ((flags) == 0)
#define __hard_irq_enable() __mtmsrd(mfmsr() | MSR_EE, 1)
#define __hard_irq_disable() __mtmsrd(mfmsr() & ~MSR_EE, 1)
@@ -108,6 +109,7 @@ static inline void local_irq_save_ptr(un
#define local_save_flags(flags) ((flags) = mfmsr())
#define local_irq_save(flags) local_irq_save_ptr(&flags)
#define irqs_disabled() ((mfmsr() & MSR_EE) == 0)
+#define irqs_disabled_flags(flags) (((flags) & MSR_EE) == 0)
#define hard_irq_enable() local_irq_enable()
#define hard_irq_disable() local_irq_disable()
--- linux-2.6-git32.orig/include/asm-powerpc/irqflags.h 2007-06-28 14:53:58.779430447 +0200
+++ linux-2.6-git32/include/asm-powerpc/irqflags.h 2007-06-28 14:52:51.821430447 +0200
@@ -15,17 +15,4 @@
*/
#include <asm-powerpc/hw_irq.h>
-/*
- * Do the CPU's IRQ-state tracing from assembly code. We call a
- * C function, so save all the C-clobbered registers:
- */
-#ifdef CONFIG_TRACE_IRQFLAGS
-
-#error No support on PowerPC yet for CONFIG_TRACE_IRQFLAGS
-
-#else
-# define TRACE_IRQS_ON
-# define TRACE_IRQS_OFF
-#endif
-
#endif
--- linux-2.6-git32.orig/include/asm-powerpc/rwsem.h 2007-06-28 14:53:58.779430447 +0200
+++ linux-2.6-git32/include/asm-powerpc/rwsem.h 2007-06-28 14:52:51.588430447 +0200
@@ -28,11 +28,21 @@ struct rw_semaphore {
#define RWSEM_ACTIVE_WRITE_BIAS (RWSEM_WAITING_BIAS + RWSEM_ACTIVE_BIAS)
spinlock_t wait_lock;
struct list_head wait_list;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
};
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+# define __RWSEM_DEP_MAP_INIT(lockname) , .dep_map = { .name = #lockname }
+#else
+# define __RWSEM_DEP_MAP_INIT(lockname)
+#endif
+
#define __RWSEM_INITIALIZER(name) \
{ RWSEM_UNLOCKED_VALUE, SPIN_LOCK_UNLOCKED, \
- LIST_HEAD_INIT((name).wait_list) }
+ LIST_HEAD_INIT((name).wait_list) \
+ __RWSEM_DEP_MAP_INIT(name) }
#define DECLARE_RWSEM(name) \
struct rw_semaphore name = __RWSEM_INITIALIZER(name)
@@ -42,12 +52,15 @@ extern struct rw_semaphore *rwsem_down_w
extern struct rw_semaphore *rwsem_wake(struct rw_semaphore *sem);
extern struct rw_semaphore *rwsem_downgrade_wake(struct rw_semaphore *sem);
-static inline void init_rwsem(struct rw_semaphore *sem)
-{
- sem->count = RWSEM_UNLOCKED_VALUE;
- spin_lock_init(&sem->wait_lock);
- INIT_LIST_HEAD(&sem->wait_list);
-}
+extern void __init_rwsem(struct rw_semaphore *sem, const char *name,
+ struct lock_class_key *key);
+
+#define init_rwsem(sem) \
+ do { \
+ static struct lock_class_key __key; \
+ \
+ __init_rwsem((sem), #sem, &__key); \
+ } while (0)
/*
* lock for reading
@@ -74,7 +87,7 @@ static inline int __down_read_trylock(st
/*
* lock for writing
*/
-static inline void __down_write(struct rw_semaphore *sem)
+static inline void __down_write_nested(struct rw_semaphore *sem, int subclass)
{
int tmp;
@@ -84,6 +97,11 @@ static inline void __down_write(struct r
rwsem_down_write_failed(sem);
}
+static inline void __down_write(struct rw_semaphore *sem)
+{
+ __down_write_nested(sem, 0);
+}
+
static inline int __down_write_trylock(struct rw_semaphore *sem)
{
int tmp;
--- linux-2.6-git32.orig/include/asm-powerpc/spinlock.h 2007-06-28 14:53:58.780430447 +0200
+++ linux-2.6-git32/include/asm-powerpc/spinlock.h 2007-06-28 14:52:51.641430447 +0200
@@ -19,6 +19,7 @@
*
* (the type definitions are in asm/spinlock_types.h)
*/
+#include <linux/irqflags.h>
#ifdef CONFIG_PPC64
#include <asm/paca.h>
#include <asm/hvcall.h>
--- linux-2.6-git32.orig/arch/powerpc/kernel/head_64.S 2007-06-28 14:53:58.679430447 +0200
+++ linux-2.6-git32/arch/powerpc/kernel/head_64.S 2007-06-28 14:48:33.858430447 +0200
@@ -394,6 +394,12 @@ label##_iSeries: \
EXCEPTION_PROLOG_ISERIES_2; \
b label##_common; \
+#ifdef CONFIG_TRACE_IRQFLAGS
+#define TRACE_DISABLE_INTS bl .powerpc_trace_hardirqs_off
+#else
+#define TRACE_DISABLE_INTS
+#endif
+
#ifdef CONFIG_PPC_ISERIES
#define DISABLE_INTS \
li r11,0; \
@@ -405,14 +411,15 @@ BEGIN_FW_FTR_SECTION; \
mfmsr r10; \
ori r10,r10,MSR_EE; \
mtmsrd r10,1; \
-END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
+END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES); \
+ TRACE_DISABLE_INTS
#else
#define DISABLE_INTS \
li r11,0; \
stb r11,PACASOFTIRQEN(r13); \
- stb r11,PACAHARDIRQEN(r13)
-
+ stb r11,PACAHARDIRQEN(r13); \
+ TRACE_DISABLE_INTS
#endif /* CONFIG_PPC_ISERIES */
#define ENABLE_INTS \
@@ -965,24 +972,38 @@ bad_stack:
*/
fast_exc_return_irq: /* restores irq state too */
ld r3,SOFTE(r1)
- ld r12,_MSR(r1)
+#ifdef CONFIG_TRACE_IRQFLAGS
+ cmpdi r3,0
+ beq 1f
+ bl .trace_hardirqs_on
+ ld r3,SOFTE(r1)
+1:
stb r3,PACASOFTIRQEN(r13) /* restore paca->soft_enabled */
+ cmpdi r3,0
+ bne 2f
+ bl .trace_hardirqs_off
+ ld r3,SOFTE(r1)
+2:
+#else
+ stb r3,PACASOFTIRQEN(r13) /* restore paca->soft_enabled */
+#endif
+ ld r12,_MSR(r1)
rldicl r4,r12,49,63 /* get MSR_EE to LSB */
stb r4,PACAHARDIRQEN(r13) /* restore paca->hard_enabled */
- b 1f
+ b 3f
.globl fast_exception_return
fast_exception_return:
ld r12,_MSR(r1)
-1: ld r11,_NIP(r1)
+3: ld r11,_NIP(r1)
andi. r3,r12,MSR_RI /* check if RI is set */
beq- unrecov_fer
#ifdef CONFIG_VIRT_CPU_ACCOUNTING
andi. r3,r12,MSR_PR
- beq 2f
+ beq 4f
ACCOUNT_CPU_USER_EXIT(r3, r4)
-2:
+4:
#endif
ld r3,_CCR(r1)
@@ -1387,11 +1408,24 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISER
/*
* hash_page couldn't handle it, set soft interrupt enable back
- * to what it was before the trap. Note that .local_irq_restore
+ * to what it was before the trap. Note that .raw_local_irq_restore
* handles any interrupts pending at this point.
*/
ld r3,SOFTE(r1)
- bl .local_irq_restore
+#ifdef CONFIG_TRACE_IRQFLAGS
+ cmpdi r3,0
+ beq 14f
+ bl .trace_hardirqs_on
+ ld r3,SOFTE(r1)
+14:
+ bl .raw_local_irq_restore
+ cmpdi r3,0
+ bne 15f
+ bl .trace_hardirqs_off
+15:
+#else
+ bl .raw_local_irq_restore
+#endif
b 11f
/* Here we have a page fault that hash_page can't handle. */
--- linux-2.6-git32.orig/arch/powerpc/kernel/setup_64.c 2007-06-28 14:53:58.729430447 +0200
+++ linux-2.6-git32/arch/powerpc/kernel/setup_64.c 2007-06-28 14:49:08.305430447 +0200
@@ -33,6 +33,7 @@
#include <linux/serial_8250.h>
#include <linux/bootmem.h>
#include <linux/pci.h>
+#include <linux/lockdep.h>
#include <asm/io.h>
#include <asm/kdump.h>
#include <asm/prom.h>
@@ -359,6 +360,11 @@ void __init setup_system(void)
&__start___fw_ftr_fixup, &__stop___fw_ftr_fixup);
/*
+ * start lockdep
+ */
+ lockdep_init();
+
+ /*
* Unflatten the device-tree passed by prom_init or kexec
*/
unflatten_device_tree();
--- linux-2.6-git32.orig/arch/powerpc/kernel/entry_64.S 2007-06-28 14:53:58.729430447 +0200
+++ linux-2.6-git32/arch/powerpc/kernel/entry_64.S 2007-06-28 14:49:13.125430447 +0200
@@ -91,6 +91,13 @@ system_call_common:
li r10,1
stb r10,PACASOFTIRQEN(r13)
stb r10,PACAHARDIRQEN(r13)
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl .trace_hardirqs_on
+ REST_GPR(0,r1)
+ REST_4GPRS(3,r1)
+ REST_2GPRS(7,r1)
+ addi r9,r1,STACK_FRAME_OVERHEAD
+#endif
std r10,SOFTE(r1)
#ifdef CONFIG_PPC_ISERIES
BEGIN_FW_FTR_SECTION
@@ -491,8 +498,20 @@ BEGIN_FW_FTR_SECTION
4:
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
#endif
+#ifdef CONFIG_TRACE_IRQFLAGS
+ cmpdi r5,0
+ beq 5f
+ bl .trace_hardirqs_on
+ ld r5,SOFTE(r1)
stb r5,PACASOFTIRQEN(r13)
-
+ b 6f
+5:
+ stb r5,PACASOFTIRQEN(r13)
+ bl .trace_hardirqs_off
+6:
+#else
+ stb r5,PACASOFTIRQEN(r13)
+#endif
/* extract EE bit and use it to restore paca->hard_enabled */
ld r3,_MSR(r1)
rldicl r4,r3,49,63 /* r0 = (r3 >> 15) & 1 */
@@ -560,6 +579,9 @@ do_work:
bne restore
/* here we are preempting the current task */
1:
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl .powerpc_trace_hardirqs_on
+#endif
li r0,1
stb r0,PACASOFTIRQEN(r13)
stb r0,PACAHARDIRQEN(r13)
--- linux-2.6-git32.orig/arch/powerpc/kernel/Makefile 2007-06-28 14:53:58.729430447 +0200
+++ linux-2.6-git32/arch/powerpc/kernel/Makefile 2007-06-28 14:48:41.691430447 +0200
@@ -62,6 +62,7 @@ obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
+obj-$(CONFIG_TRACE_IRQFLAGS) += irqtrace.o
module-$(CONFIG_PPC64) += module_64.o
obj-$(CONFIG_MODULES) += $(module-y)
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-git32/arch/powerpc/kernel/irqtrace.S 2007-06-28 14:49:25.754430447 +0200
@@ -0,0 +1,47 @@
+/*
+ * crappy helper for irq-trace
+ */
+
+#include <asm/ppc_asm.h>
+#include <asm/asm-offsets.h>
+
+#define STACKSPACE GPR0 + 16*8
+
+#ifdef __powerpc64__
+#define ST std
+#define L ld
+#else
+#define ST stw
+#define L lw
+#endif
+
+#define PRE \
+ subi r1,r1,STACKSPACE ; \
+ SAVE_GPR(0, r1) ; \
+ SAVE_8GPRS(2, r1) ; \
+ SAVE_4GPRS(10, r1) ; \
+ mfcr r0 ; \
+ ST r0, (14*8)(r1) ; \
+ mflr r0 ; \
+ ST r0, (15*8)(r1)
+
+#define POST \
+ REST_8GPRS(2, r1) ; \
+ REST_4GPRS(10, r1) ; \
+ L r0, (14*8)(r1) ; \
+ mtcr r0 ; \
+ L r0, (15*8)(r1) ; \
+ mtlr r0 ; \
+ REST_GPR(0, r1) ; \
+ addi r1,r1,STACKSPACE
+
+_GLOBAL(powerpc_trace_hardirqs_off)
+ PRE
+ bl .trace_hardirqs_off
+ POST
+ blr
+_GLOBAL(powerpc_trace_hardirqs_on)
+ PRE
+ bl .trace_hardirqs_on
+ POST
+ blr
^ permalink raw reply
* Re: PCI IO range limitation
From: Benjamin Herrenschmidt @ 2007-06-28 17:43 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <46838B54.2010806@semihalf.com>
On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
> Hi,
>
> Trying to change PCI IO window base for 52xx target I found that
> we are pretty much limited to a "0" offset only.
>
> pci_process_bridge_OF_ranges() will not process any IO range that has
> addresses set to anything else.
>
> 956: case 1: /* I/O space */
> 957: if (ranges[2] != 0)
> 958: break;
>
> When this range[2] checking is removed from
> pci_process_bridge_OF_ranges() kernel boots ok with the non-zero PCI IO
> base, but the PCI device I am using (e100) will not work.
>
> I guess that with the above dropping of non-zero based PCI IO ranges
> this is not supposed to be working. But does anyone know why?
We just fixed that for 64 bits but 32 bits still has the limitation.
Note that it's not a very good idea to have your IO range at !0 if
you're going to use anything ISA-like, such as a VGA video card or other
legacy devices behind a PCI southbridge or SuperIO.
Ben.
^ permalink raw reply
* Re: Porting Linux to Xilinx ML410
From: khollan @ 2007-06-28 17:53 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070627211825.GA2003@cip.informatik.uni-erlangen.de>
I fixed my error. I was using gcc 4.1.0 and read some other threads here
and found that there is a linker error in gcc 4.1.0 So I created a new
toolchain with crosstool with gcc 4.0.2 and my system booted until it tried
to mount the root file system like I had planned. Now Ill have to create a
rfs and see if it will boot all the way.
Thanks for your replies
Kevin
--
View this message in context: http://www.nabble.com/Porting-Linux-to-Xilinx-ML410-tf3989483.html#a11347823
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* 2.4/2.6/ppc/powerpc/8245/8347e
From: Marc Leeman @ 2007-06-28 18:06 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070621171340.GS5417@chiana.homelinux.org>
[-- Attachment #1.1: Type: text/plain, Size: 3224 bytes --]
a small update:
> 8245: 2.4.34
> 8237e: 2.6.21.1
I've tried the following setup:
multicast stream @8192 kbps, one process taking in and dumping the data
on each board [1].
a) 8245/2.4.34/e100: 2.3.43-k1, @400 MHz
b) 8245/2.6.17/e100: 2.3.43-k1 [2] @350 MHz
c) 8347e/2.6.21.1/gianfar @400 Mhz
c) XScale-IXP42x/2.6.18-4/ixp4xx @266 MHz (NSLU2)
(2.3.43-k1 is the e100 driver version).
The process load for taking in the data is:
a) 4-5% [3]
b) 10-11%
c) 13-14%
d) 4-5%
While the current 8347/gianfar platform is the worst performer, the
2.6 kernel with the 2.4 e100 (before the rewrite) seems to perform
poorly too [4].
So the 834x preforms worse wrt the 8245 based configuration even though
it is slightly higher clocked.
It seems as if I bumped into the problem that lead me stick with the 2.4
in the first place for this 8245 platform; but never got round to
investigating. I find these results especially intriguing when
considering an ARM platform (NSLU2 device) that I had around, clocked at
only 66% of the 8347 and at 80% of the 8245 performs certainly in par
with the last one...
Even though I will need to recheck this (results to follow), a quick
test didn't reveal any significant difference between a ppc and powerpc
arch in the kernel.
It does look like, on our 8245/83xx platforms, the 2.6.x kernel performs
worse wrt the 2.4 ppc kernels and the 83xx configuration is worse wrt
the 8245 based configuration [5]. In retrospect, we had signals that
there was a problem with the 8245/83xx performance over the network last
year when investigating gstreamer, but due to time pressure but assumed
it was due to gstreamer and not the processor. This came as a suprise to
some of the ppl on the gstreamer mailing list that reported performant
ports to ARM architectures.
The results with the NSLU2 will certainly put heat on us from management
when redesigning or for follow up designs :(
Anyhow, I'm currently extending my test setups since this is an
important problem and set back.
If anyone has a hint to explaining what is going on here, please do
since solving this will certainly beat redesigning (esp. considering the
timeframe we've been assigned).
I've only found one relevant reference to 2.4/2.6 network performance
decrease at this point [6].
[1] sources attached
mcrecv -p 225.1.2.3 -a 12345
mcsend -p 225.1.2.3 -a 12345 -b 8192
I'm preparing more tests in the next days, in trying to figure out
what really is going on here.
[2] 2.4 driver ported to 2.6 kernel.
[3] This figure is read from top and not from the app since it seems to
be an underestimate (./fs/proc/array.c).
[4] I believe I ported the 2.4 e100 to the 2.6 2 years ago because it
performed much better, but I'll verify that in the next days.
[5] Obviously, testing 834x against the 2.4 kernel is not really an
option :)
[6] http://www.mail-archive.com/linux-net@vger.kernel.org/msg01283.html
--
greetz, marc
Don't think I'm going to miss you, any of you. I'm not. Well, maybe
a little bit.
Rygel - Into the Lion's Den - Wolf in Sheep's Clothing
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux
[-- Attachment #1.2: recv_mcast.c --]
[-- Type: text/x-csrc, Size: 9890 bytes --]
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/time.h>
#include <time.h>
#define BUFSIZE 64*1024 /* Maximal packet content is 64k bytes */
#define MAXPARAMLEN 80
#define STATFILE "/proc/stat"
#define SELFSTATFILE "/proc/self/stat"
void error(char *msg);
void usage(const char* program)
{
fprintf(stdout,"usage : %s -a address -p port\n",program);
}
float getsysload()
{
unsigned long user = 0ul, nice = 0ul, system = 0ul, idle = 0ul;
char buf[BUFSIZ];
FILE *fp;
char buffer[BUFSIZ];
memset(buffer,0x0,BUFSIZ);
if((fp=fopen(STATFILE,"r"))<=0){
fprintf(stderr, "Problem opening %s\n", STATFILE);
return EXIT_FAILURE;
}
fread(buffer, sizeof(char), BUFSIZ, fp);
fclose(fp);
if(sscanf(buffer,"%s %lu %lu %lu %lu",buf, &user, &nice, &system, &idle)){
return (float)(user+system)/(user+system+nice+idle);
}
else{
fprintf(stdout, "no matching strings found\n");
}
}
unsigned long getcurrjiffies()
{
FILE *fp;
char buffer[BUFSIZ];
memset(buffer, 0x0, BUFSIZ);
fp=popen("cat /proc/self/stat | cut -d \\ -f 22","r");
fread(buffer, sizeof(char), BUFSIZ, fp);
pclose(fp);
return atoi(buffer);
}
unsigned long scan_stat(unsigned long *user, unsigned long *kernel)
{
FILE *fp;
char buffer[BUFSIZ];
uint32_t scanned = 0u;
signed int pid = 0;
char tcomm[BUFSIZ];
char state = 0x0;
signed int ppid = 0;
signed int pgid = 0;
signed int sid = 0;
signed int tty_nr = 0;
signed int tty_pgrp = 0;
unsigned long flags = 0ul;
unsigned long min_flt = 0ul;
unsigned long cmin_flt = 0ul;
unsigned long maj_flt = 0ul;
unsigned long cmaj_flt = 0ul;
unsigned long utime = 0ul;
unsigned long stime = 0ul;
signed long cutime = 0l;
signed long cstime = 0l;
signed long priority = 0l;
signed long nice = 0l;
signed int num_threads = 0;
unsigned long long start_time = 0ul;
unsigned long vsize = 0ul;
signed long rss = 0l;
unsigned long rsslim = 0ul;
unsigned long start_code = 0ul;
unsigned long end_code = 0ul;
unsigned long start_stack = 0ul;
unsigned long esp = 0ul;
unsigned long eip = 0ul;
/* The signal information here is obsolete.
* It must be decimal for Linux 2.0 compatibility.
* Use /proc/#/status for real-time signals.
*/
unsigned long signalpending = 0ul;
unsigned long signalblocked = 0ul;
unsigned long sigign = 0ul;
unsigned long sigcatch = 0ul;
unsigned long wchan = 0ul;
unsigned long dummy0 = 0ul;
unsigned long dummy1 = 0ul;
int exit_signal = 0;
int task_cpu = 0;
unsigned long rt_priority = 0ul;
unsigned long policy = 0ul;
unsigned long long delayticks = 0ull;
memset(buffer,0x0,BUFSIZ);
memset(tcomm,0x0,BUFSIZ);
if(!(fp=fopen(SELFSTATFILE,"r"))){
fprintf(stderr,"Error opening \"%s\".\n",SELFSTATFILE);
return 0;
}
fread(buffer, sizeof(char), BUFSIZ, fp);
fclose(fp);
#if 0
fprintf(stdout,"Reference:\n");
fprintf(stdout,"-------\n");
fprintf(stdout,"%s\n",buffer);
fprintf(stdout,"-------\n");
#endif
scanned = sscanf(buffer,"%d %s %c %d %d %d %d %d %lu %lu \
%lu %lu %lu %lu %lu %ld %ld %ld %ld %d 0 %llu %lu %ld %lu %lu %lu %lu %lu \
%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu %llu\n",
&pid,
tcomm,
&state,
&ppid,
&pgid,
&sid,
&tty_nr,
&tty_pgrp,
&flags,
&min_flt,
&cmin_flt,
&maj_flt,
&cmaj_flt,
&utime,
&stime,
&cutime,
&cstime,
&priority,
&nice,
&num_threads,
&start_time,
&vsize,
&rss,
&rsslim,
&start_code,
&end_code,
&start_stack,
&esp,
&eip,
/* The signal information here is obsolete.
* It must be decimal for Linux 2.0 compatibility.
* Use /proc/#/status for real-time signals.
*/
&signalpending,
&signalblocked,
&sigign,
&sigcatch,
&wchan,
&dummy0,
&dummy1,
&exit_signal,
&task_cpu,
&rt_priority,
&policy,
&delayticks);
#if 0
fprintf(stdout,"scanned %u items.\n",scanned);
fprintf(stdout,"%d %s %c %d %d %d %d %d %lu %lu \
%lu %lu %lu %lu %lu %ld %ld %ld %ld %d 0 %llu %lu %ld %lu %lu %lu %lu %lu \
%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu %llu\n",
pid,
tcomm,
state,
ppid,
pgid,
sid,
tty_nr,
tty_pgrp,
flags,
min_flt,
cmin_flt,
maj_flt,
cmaj_flt,
utime,
stime,
cutime,
cstime,
priority,
nice,
num_threads,
start_time,
vsize,
rss,
rsslim,
start_code,
end_code,
start_stack,
esp,
eip,
/* The signal information here is obsolete.
* It must be decimal for Linux 2.0 compatibility.
* Use /proc/#/status for real-time signals.
*/
signalpending,
signalblocked,
sigign,
sigcatch,
wchan,
dummy0,
dummy1,
exit_signal,
task_cpu,
rt_priority,
policy,
delayticks);
#endif
*user = utime;
*kernel = stime;
return utime + stime;
}
int main(int argc, char *argv[])
{
extern int getopt();
extern int optind;
extern char *optarg;
int c_opt;
int socket_val, bind_val, recvfromval, ctrlboardlen,
rc, recvbuff;
unsigned optlen, cameralen;
uint16_t mc_port;
char mc_addr[16];
struct ip_mreq mreq;
struct sockaddr_in ctrlboard, camera;
struct in_addr mcast_address;
struct hostent *h;
unsigned char buffer[BUFSIZE];
FILE *fp;
uint32_t ucnt = 0u,i,cnt=0u;
uint64_t usecs[8];
uint64_t received[8];
uint64_t treceived = 0ul;
struct timeval newtime;
unsigned long p_jiffies, c_jiffies;
unsigned long puser, pkernel;
unsigned long cuser, ckernel;
unsigned long long p_start, c_start;
/* Initialize the buffer */
memset(mc_addr, 0x0, 16);
memset(buffer,0x0,BUFSIZE);
for(i=0;i<8;i++){
usecs[i] = 0ul;
received[8] = 0ul;
}
/* handling of command line options */
while ((c_opt = getopt(argc, argv, "a:b:p:")) != EOF) {
switch (c_opt) {
case 'a':
strncpy(mc_addr,optarg,16);
break;
case 'p':
mc_port = (atoi(optarg));
break;
default:
fprintf(stderr, "%s: Bad Option -%c\n", argv[0], c_opt);
exit(EXIT_FAILURE);
}
}
if(!mc_addr || !mc_port){
usage(argv[0]);
return EXIT_FAILURE;
}
/* Get mcast address to listen to */
h=gethostbyname(mc_addr);
if(h==NULL) {
fprintf(stdout,"Unknown group %s\n",mc_addr);
exit(1);
}
memcpy(&mcast_address, h->h_addr_list[0],h->h_length);
/* Check given address is multicast */
if(!IN_MULTICAST(ntohl(mcast_address.s_addr))) {
fprintf(stdout,"Given address '%s' is not multicast\n",
inet_ntoa(mcast_address));
exit(1);
}
/* Create socket for incoming connections */
socket_val=socket(AF_INET, SOCK_DGRAM, 0);
if (socket_val < 0)
error("Error opening socket");
/* Set content of ctrlboard */
ctrlboardlen = sizeof(ctrlboard);
bzero(&ctrlboard,ctrlboardlen);
/* Fill in the UDP Receiver properties */
ctrlboard.sin_family=AF_INET;
ctrlboard.sin_addr.s_addr=htonl(INADDR_ANY);
ctrlboard.sin_port=htons(mc_port);
/* Set socket options */
recvbuff=128*1024;
if (setsockopt(socket_val,SOL_SOCKET,SO_RCVBUF,(char *) &recvbuff, sizeof(recvbuff)) < 0)
error("Error setting socket options");
/* Get socket options */
optlen=sizeof(recvbuff);
if (getsockopt(socket_val,SOL_SOCKET,SO_RCVBUF,(char *) &recvbuff, &optlen) < 0)
error("Error getting socket options");
fprintf(stdout,"Receive buffer size: %d \n",recvbuff);
/* Bind to associate port number with the socket */
bind_val = bind(socket_val,(struct sockaddr *)&ctrlboard,ctrlboardlen);
if (bind_val < 0)
error("Error bind");
/* join multicast group */
mreq.imr_multiaddr.s_addr=mcast_address.s_addr;
mreq.imr_interface.s_addr=htonl(INADDR_ANY);
rc = setsockopt(socket_val,IPPROTO_IP,IP_ADD_MEMBERSHIP, (void *) &mreq, sizeof(mreq));
if(rc<0){
fprintf(stdout,"Cannot join multicast group '%s'", inet_ntoa(mcast_address));
exit(1);
}
else
fprintf(stdout,"Listening to mgroup %s:%d\n", inet_ntoa(mcast_address), mc_port);
/* Fill in length of struct sockaddr_in camera */
cameralen = sizeof(camera);
gettimeofday(&newtime,NULL);
p_jiffies = scan_stat(&puser, &pkernel);
p_start = getcurrjiffies();
/* Loop */
while (1) {
recvfromval = recvfrom(socket_val,buffer,BUFSIZE,0,(struct sockaddr *)&camera,&cameralen);
treceived += recvfromval;
if (recvfromval < 0) error("Error recvfrom");
if(!(cnt&0xff)){
double cbitrate = 0.0;
uint8_t ccnt = ucnt&0x7;
uint8_t pcnt = ccnt?ccnt-1:0x7;
uint64_t dt;
c_jiffies = scan_stat(&cuser,&ckernel);
c_start = getcurrjiffies();
gettimeofday(&newtime,NULL);
usecs[ccnt] = (uint64_t)(newtime.tv_sec*1e6+newtime.tv_usec);
received[ccnt] = treceived;
dt = usecs[ccnt] - usecs[pcnt];
if(usecs[ccnt]<usecs[pcnt]){
ucnt = 0;
}
else{
unsigned lcnt = 0u;
for(i=0;i<8;i++){
lcnt = received[i];
}
if(dt){
cbitrate = (((double)lcnt*8)/((double)dt))*1e3;
fprintf(stdout,"Approx bitrate is %2.2lf kbps, system load is %2.2f%%, process %2.2f%% (u %2.2f%%, s %2.2f).\n",
cbitrate,
getsysload()*100,
(double)(c_jiffies - p_jiffies)*100/(c_start - p_start),
(double)(cuser-puser)*100/(c_start - p_start),
(double)(ckernel-pkernel)*100/(c_start - p_start)
);
}
}
ucnt++;
treceived = 0;
p_jiffies = c_jiffies;
p_start = c_start;
pkernel = ckernel;
puser = cuser;
}
cnt++;
}
close(socket_val);
fclose(fp);
}
void error(char *msg) {
perror(msg);
exit(0);
}
[-- Attachment #1.3: send_mcast.c --]
[-- Type: text/x-csrc, Size: 9247 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <fcntl.h>
#include <netdb.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/time.h>
#include <time.h>
#define STATFILE "/proc/stat"
#define SELFSTATFILE "/proc/self/stat"
void usage(const char* program)
{
fprintf(stdout,"Usage: %s -a address -p port -b bitrate\n",program);
fprintf(stdout," bitrate in kbps.\n");
}
float getsysload()
{
unsigned long user = 0ul, nice = 0ul, system = 0ul, idle = 0ul;
char buf[BUFSIZ];
FILE *fp;
char buffer[BUFSIZ];
memset(buffer,0x0,BUFSIZ);
if((fp=fopen(STATFILE,"r"))<=0){
fprintf(stderr, "Problem opening %s\n", STATFILE);
return EXIT_FAILURE;
}
fread(buffer, sizeof(char), BUFSIZ, fp);
fclose(fp);
if(sscanf(buffer,"%s %lu %lu %lu %lu",buf, &user, &nice, &system, &idle)){
return (float)(user+system)/(user+system+nice+idle);
}
else{
fprintf(stdout, "no matching strings found\n");
}
}
unsigned long getcurrjiffies()
{
FILE *fp;
char buffer[BUFSIZ];
memset(buffer, 0x0, BUFSIZ);
fp=popen("cat /proc/self/stat | cut -d \\ -f 22","r");
fread(buffer, sizeof(char), BUFSIZ, fp);
pclose(fp);
return atoi(buffer);
}
unsigned long scan_stat(unsigned long *user, unsigned long *kernel)
{
FILE *fp;
char buffer[BUFSIZ];
uint32_t scanned = 0u;
signed int pid = 0;
char tcomm[BUFSIZ];
char state = 0x0;
signed int ppid = 0;
signed int pgid = 0;
signed int sid = 0;
signed int tty_nr = 0;
signed int tty_pgrp = 0;
unsigned long flags = 0ul;
unsigned long min_flt = 0ul;
unsigned long cmin_flt = 0ul;
unsigned long maj_flt = 0ul;
unsigned long cmaj_flt = 0ul;
unsigned long utime = 0ul;
unsigned long stime = 0ul;
signed long cutime = 0l;
signed long cstime = 0l;
signed long priority = 0l;
signed long nice = 0l;
signed int num_threads = 0;
unsigned long long start_time = 0ul;
unsigned long vsize = 0ul;
signed long rss = 0l;
unsigned long rsslim = 0ul;
unsigned long start_code = 0ul;
unsigned long end_code = 0ul;
unsigned long start_stack = 0ul;
unsigned long esp = 0ul;
unsigned long eip = 0ul;
/* The signal information here is obsolete.
* It must be decimal for Linux 2.0 compatibility.
* Use /proc/#/status for real-time signals.
*/
unsigned long signalpending = 0ul;
unsigned long signalblocked = 0ul;
unsigned long sigign = 0ul;
unsigned long sigcatch = 0ul;
unsigned long wchan = 0ul;
unsigned long dummy0 = 0ul;
unsigned long dummy1 = 0ul;
int exit_signal = 0;
int task_cpu = 0;
unsigned long rt_priority = 0ul;
unsigned long policy = 0ul;
unsigned long long delayticks = 0ull;
memset(buffer,0x0,BUFSIZ);
memset(tcomm,0x0,BUFSIZ);
if(!(fp=fopen(SELFSTATFILE,"r"))){
fprintf(stderr,"Error opening \"%s\".\n",SELFSTATFILE);
return 0;
}
fread(buffer, sizeof(char), BUFSIZ, fp);
fclose(fp);
#if 0
fprintf(stdout,"Reference:\n");
fprintf(stdout,"-------\n");
fprintf(stdout,"%s\n",buffer);
fprintf(stdout,"-------\n");
#endif
scanned = sscanf(buffer,"%d %s %c %d %d %d %d %d %lu %lu \
%lu %lu %lu %lu %lu %ld %ld %ld %ld %d 0 %llu %lu %ld %lu %lu %lu %lu %lu \
%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu %llu\n",
&pid,
tcomm,
&state,
&ppid,
&pgid,
&sid,
&tty_nr,
&tty_pgrp,
&flags,
&min_flt,
&cmin_flt,
&maj_flt,
&cmaj_flt,
&utime,
&stime,
&cutime,
&cstime,
&priority,
&nice,
&num_threads,
&start_time,
&vsize,
&rss,
&rsslim,
&start_code,
&end_code,
&start_stack,
&esp,
&eip,
/* The signal information here is obsolete.
* It must be decimal for Linux 2.0 compatibility.
* Use /proc/#/status for real-time signals.
*/
&signalpending,
&signalblocked,
&sigign,
&sigcatch,
&wchan,
&dummy0,
&dummy1,
&exit_signal,
&task_cpu,
&rt_priority,
&policy,
&delayticks);
#if 0
fprintf(stdout,"scanned %u items.\n",scanned);
fprintf(stdout,"%d %s %c %d %d %d %d %d %lu %lu \
%lu %lu %lu %lu %lu %ld %ld %ld %ld %d 0 %llu %lu %ld %lu %lu %lu %lu %lu \
%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu %llu\n",
pid,
tcomm,
state,
ppid,
pgid,
sid,
tty_nr,
tty_pgrp,
flags,
min_flt,
cmin_flt,
maj_flt,
cmaj_flt,
utime,
stime,
cutime,
cstime,
priority,
nice,
num_threads,
start_time,
vsize,
rss,
rsslim,
start_code,
end_code,
start_stack,
esp,
eip,
/* The signal information here is obsolete.
* It must be decimal for Linux 2.0 compatibility.
* Use /proc/#/status for real-time signals.
*/
signalpending,
signalblocked,
sigign,
sigcatch,
wchan,
dummy0,
dummy1,
exit_signal,
task_cpu,
rt_priority,
policy,
delayticks);
#endif
*user = utime;
*kernel = stime;
return utime + stime;
}
int main(int argc, char *argv[])
{
extern int getopt();
extern int optind;
extern char *optarg;
int c_opt;
unsigned int mc_server_socket;
struct sockaddr_in mc_addr_sockaddr;
uint8_t TTL = 0u;
uint8_t buffer[BUFSIZ];
int retval;
uint16_t mc_port = 0u;
char mc_addr[16];
uint32_t mc_bitrate = 0u, i, cnt = 0u, ucnt=0u;
float delay = 0;
unsigned long usecs[8];
unsigned long p_jiffies, c_jiffies;
unsigned long puser, pkernel;
unsigned long cuser, ckernel;
unsigned long long p_start, c_start;
struct timeval newtime;
/* Init */
memset(mc_addr, 0x0, 16);
for(i=0;i<8;i++){
usecs[i] = 0ul;
}
for(i=0;i<BUFSIZ>>2;i++){
((uint32_t*)buffer)[i]=0xbadc0ffe;
}
/* handling of command line options */
while ((c_opt = getopt(argc, argv, "a:b:p:")) != EOF) {
switch (c_opt) {
case 'a':
strncpy(mc_addr,optarg,16);
break;
case 'b':
mc_bitrate = (atoi(optarg));
break;
case 'p':
mc_port = (atoi(optarg));
break;
default:
fprintf(stderr, "%s: Bad Option -%c\n", argv[0], c_opt);
exit(EXIT_FAILURE);
}
}
if(!mc_addr || !mc_port || !mc_bitrate){
usage(argv[0]);
return EXIT_FAILURE;
}
/* Create a multicast socket */
mc_server_socket=socket(AF_INET, SOCK_DGRAM,0);
/* Create multicast group address information */
mc_addr_sockaddr.sin_family = AF_INET;
mc_addr_sockaddr.sin_addr.s_addr = inet_addr(mc_addr);
mc_addr_sockaddr.sin_port = htons(mc_port);
/* Set the TTL for the sends using a setsockopt() */
TTL = 1;
retval = setsockopt(mc_server_socket, IPPROTO_IP, IP_MULTICAST_TTL, (char *)&TTL, sizeof(TTL));
if (retval < 0){
fprintf(stdout,"ERROR setsockopt() failed with %d \n", retval);
return EXIT_FAILURE;
}
/* get estimated us delay */
delay = 1e6/((float)(mc_bitrate<<10)/(sizeof(buffer)<<3));
/* Send MC message */
fprintf(stdout,"Multicast to socket %s:%u.\n",mc_addr, mc_port);
fprintf(stdout,"Requested bitrate is %u kbps.\n",mc_bitrate);
fprintf(stdout,"Need %2.2f packets of %u bytes per second.\n",((float)(mc_bitrate<<10)/(sizeof(buffer)<<3)),sizeof(buffer));
fprintf(stdout,"Setting interpacket delay at %2.2f usec.\n",delay);
gettimeofday(&newtime,NULL);
p_jiffies = scan_stat(&puser, &pkernel);
p_start = getcurrjiffies();
// usecs[ucnt++] = newtime.tv_sec*1e6+newtime.tv_usec;
while(1){
/* Send buffer as a datagram to the multicast group */
sendto(mc_server_socket, buffer, sizeof(buffer), 0,
(struct sockaddr*)&mc_addr_sockaddr, sizeof(mc_addr_sockaddr));
usleep(delay);
if(!(cnt&0xff)){
double cbitrate = 0.0;
uint8_t ccnt = ucnt&0x7;
uint8_t pcnt = ccnt?ccnt-1:0x7;
unsigned long dt;
c_jiffies = scan_stat(&cuser,&ckernel);
c_start = getcurrjiffies();
gettimeofday(&newtime,NULL);
usecs[ccnt] = newtime.tv_sec*1e6+newtime.tv_usec;
dt = usecs[ccnt] - usecs[pcnt];
if(usecs[ccnt]<usecs[pcnt]){
ucnt = 0;
}
else{
cbitrate = ((((double)sizeof(buffer)*8)*0xff)/((float)dt))*1e3;
fprintf(stdout,"Approx bitrate is %2.2lf kbps, system load is %2.2f%%, process %2.2f%% (u %2.2f%%, s %2.2f).\n",
cbitrate,
getsysload()*100,
(double)(c_jiffies - p_jiffies)*100/(c_start - p_start),
(double)(cuser-puser)*100/(c_start - p_start),
(double)(ckernel-pkernel)*100/(c_start - p_start)
);
if(((cbitrate+256)<mc_bitrate)){
delay -= 500;
fprintf(stdout,"Interpacket delay adjusted to %2.2f usec\n",delay);
}
else if ((cbitrate-256)>mc_bitrate){
delay += 500;
fprintf(stdout,"Interpacket delay adjusted to %2.2f usec\n",delay);
}
if(delay<0){
fprintf(stderr,"Cannot send data out fast enough.\n");
mc_bitrate -= 1024;
delay = 0;
fprintf(stdout,"Limiting data to %u kbps.\n",mc_bitrate);
}
ucnt++;
}
p_jiffies = c_jiffies;
p_start = c_start;
pkernel = ckernel;
puser = cuser;
}
cnt++;
}
/* Close and clean-up */
close(mc_server_socket);
return EXIT_SUCCESS;
}
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5 v2] Add the platform device support with RapidIO to MPC8641HPCN platform.
From: Segher Boessenkool @ 2007-06-28 18:26 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus, linux-kernel, Zhang Wei-r63237
In-Reply-To: <200706281647.57408.arnd@arndb.de>
> Of course, looking at the device tree, rapidio is a device, not a bus,
> because it does not have a device_type and it does not have any
> children
> of its own.
It's a device _of course_, but it's also a bus parent, since
it has a "#address-cells" not equal to zero (and, if this used
real OF, it would have decode-unit and encode-unit methods).
A quite empty bus perhaps heh (in this device tree, anyway).
Segher
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Guennadi Liakhovetski @ 2007-06-28 19:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18051.22185.374607.755419@cargo.ozlabs.ibm.com>
On Thu, 28 Jun 2007, Paul Mackerras wrote:
> Guennadi Liakhovetski writes:
>
> > These two i2c patches:
> >
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037327.html
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037328.html
> >
> > also would be nice to get in, although, they only make sense with an ack
> > from Scott Wood and another patch from him, as explained in links above...
>
> Looks OK, but the first of those two patches doesn't have a
> Signed-off-by: line, and the description is not suitable.
>
> Please repost that patch with a nice description that describes what
> the patch does and why, without references to other web pages. You
> don't need to describe what is different from previous patches or who
> suggested those changes.
Sure, no problem, will repost with a description and a Signed-off-by...
but, not giving Scott Wood credit for that patch doesn't seem right.
Scott, is it ok with you if I repost that patch with your "Signed-off-by"
first and mine second? And, Paul, as Scott noticed in another email and as
I mentioned in the above post too, we also need this one, please:
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036333.html
As soon as we clarify these 2, I'll repost.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* cuImage question
From: Bizhan Gholikhamseh (bgholikh) @ 2007-06-28 21:54 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
Hi All,
I am kind of new to the concept of "cuImage" and I am not able to find
any info on the net(?).
We are using older version of the uboot: 1.1.2. I have compiled the
latest kernel from git tree for
MPC8541E from freescale.
I would appreciate any hints on how to use 'cuImage" to load this image
with our legacy uboot version?
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 1452 bytes --]
^ permalink raw reply
* mpc8270 & Intel 82551ER on 2.6.17.14
From: Nicholas Hickman @ 2007-06-28 22:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3417 bytes --]
I am having trouble getting two 82551ER Ethernet controllers running in
Linux. I am able to scan the PCI bus and see the devices and I was even
able to program the EEPROM from U-boot.
In the kernel I mapped the IRQ's through /arch/ppc/m82xx_pci.c. I've
been using the e100 drive that comes with the 2.6.17.14 kernel and have
also tried the driver directly from Intel. Both give the same results.
The PCI scan shows the correct output for how the device should be
configured.
The situation is when I use the ethtool with the driver loaded and eth0
not configured with ifconfig I get this:
SCB Status Word (Lower Word) 0x0000
RU Status: Idle
CU Status: Idle
---- Interrupts Pending ----
Flow Control Pause: no
Early Receive: no
Software Generated Interrupt: no
MDI Done: no
RU Not In Ready State: no
CU Not in Active State: no
RU Received Frame: no
CU Completed Command: no
SCB Command Word (Upper Word) 0x0100
RU Command: No Command
CU Command: No Command
Software Generated Interrupt: no
---- Interrupts Masked ----
ALL Interrupts: yes
Flow Control Pause: no
Early Receive: no
RU Not In Ready State: no
CU Not in Active State: no
RU Received Frame: no
CU Completed Command: no
MDI/MDI-X Status: MDI
With eth0 configured using the command "ifconfig eth0 192.168.1.7
netmask 255.255.255.0 up" I get this:
SCB Status Word (Lower Word) 0x6450
RU Status: Ready
CU Status: Suspended
---- Interrupts Pending ----
Flow Control Pause: no
Early Receive: no
Software Generated Interrupt: yes
MDI Done: no
RU Not In Ready State: no
CU Not in Active State: yes
RU Received Frame: yes
CU Completed Command: no
SCB Command Word (Upper Word) 0x0000
RU Command: No Command
CU Command: No Command
Software Generated Interrupt: no
---- Interrupts Masked ----
ALL Interrupts: no
Flow Control Pause: no
Early Receive: no
RU Not In Ready State: no
CU Not in Active State: no
RU Received Frame: no
CU Completed Command: no
MDI/MDI-X Status: MDI
If I issue a PING out of the port and sniff the traffic on the
destination PC I see the ARP requests and I send the reply, but the
embedded machine sees nothing. If I use ethtool or even ifconfig to
view the statistics on the port they both show that there are no packets
in or out.
I have no idea where to go with this. It seems like the PCI bus is
working, but possibly not the Interrupt handler.
Nicholas Hickman
Applications Engineer
DTech Labs, Inc.
[-- Attachment #2: Type: text/html, Size: 9048 bytes --]
^ permalink raw reply
* Re: PCI IO range limitation
From: Matt Sealey @ 2007-06-28 23:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <1183052634.5521.284.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
>> Hi,
>>
>> Trying to change PCI IO window base for 52xx target I found that
>> we are pretty much limited to a "0" offset only.
>
> We just fixed that for 64 bits but 32 bits still has the limitation.
> Note that it's not a very good idea to have your IO range at !0 if
> you're going to use anything ISA-like, such as a VGA video card or other
> legacy devices behind a PCI southbridge or SuperIO.
The chances of that on an MPC52xx platform are practically zero, aren't
they?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: PCI IO range limitation
From: Benjamin Herrenschmidt @ 2007-06-29 0:13 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <46844692.1040804@genesi-usa.com>
On Fri, 2007-06-29 at 00:38 +0100, Matt Sealey wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
> >> Hi,
> >>
> >> Trying to change PCI IO window base for 52xx target I found that
> >> we are pretty much limited to a "0" offset only.
> >
> > We just fixed that for 64 bits but 32 bits still has the limitation.
> > Note that it's not a very good idea to have your IO range at !0 if
> > you're going to use anything ISA-like, such as a VGA video card or other
> > legacy devices behind a PCI southbridge or SuperIO.
>
> The chances of that on an MPC52xx platform are practically zero, aren't
> they?
Euh... don't you use VGA video cards on Efika ? :-)
Ben.
^ permalink raw reply
* Re: cuImage question
From: Kumar Gala @ 2007-06-29 3:14 UTC (permalink / raw)
To: Bizhan Gholikhamseh; +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A436@xmb-sjc-212.amer.cisco.com>
On Jun 28, 2007, at 4:54 PM, Bizhan Gholikhamseh ((bgholikh)) wrote:
> Hi All,
> I am kind of new to the concept of "cuImage" and I am not able to
> find any info on the net(?).
>
> We are using older version of the uboot: 1.1.2. I have compiled the
> latest kernel from git tree for
> MPC8541E from freescale.
>
> I would appreciate any hints on how to use 'cuImage" to load this
> image with our legacy uboot version?
Take a look at arch/powerpc/boot/ and the Kconfig DEVICE_TREE option.
- k
^ permalink raw reply
* Re: ARCH=ppc or ARCH=powerpc
From: Kumar Gala @ 2007-06-29 3:15 UTC (permalink / raw)
To: Erik Christiansen; +Cc: linuxppc-embedded
In-Reply-To: <20070628083624.GE8794@dd.nec.com.au>
On Jun 28, 2007, at 3:36 AM, Erik Christiansen wrote:
> On Thu, Jun 28, 2007 at 05:44:30PM +1000, Erik Christiansen wrote:
>> Encountering a kernel build error with ARCH=ppc, after configuring
>> as much as
>> possible for MPC8248, I've just tried ARCH=powerpc on
>> linux-2.6.21.5, with this
>> slightly scary result:
>
> Oh dear. Please excuse the noise. That was clearly acute lack of
> familiarity with menuconfig. <blush>
>
> Minus fingerfumbling, ARCH=powerpc starts to build, before coughing
> up a
> bunch of compiler errors:
>
> cpm2_common.c:63: error: 'CPM_MAP_ADDR' undeclared
>
> Is that due to this patch not being accepted?:
> http://patchwork.ozlabs.org/linuxppc/patch?id=8891
>
> If the patch's "State Superseded" means something else fixes the build
> failure, then how could I lay my grubby paws on that little gem?
It probably means there was a newer version of the patch w/changes
made to it based on feedback.
- k
^ permalink raw reply
* RE: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Zhang Wei-r63237 @ 2007-06-29 4:01 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <5f0438212493766009684d63e41c85cc@kernel.crashing.org>
Hi, Segher,=20
=20
> > + - #address-cells : Address representation for=20
> "rapidio" devices.
> > + This field represents the number of cells needed to represent
> > + the RapidIO address of the registers. For=20
> supporting more than
> > + 32-bits RapidIO address, this field should be <2>.
> > + See 1) above for more details on defining #address-cells.
>=20
> What does the RapidIO standard say about number of address
> bits? You want to follow that, so all RapidIO devices can
> use the same #address-cells, not just the FSL ones. Also,
> are there different kinds of address spaces on the bus, or
> is it just one big memory-like space?
>=20
>=20
I've checked the specification of RapidIO. The supporting of RapidIO
extended address modes are 66, 50 and 34 bit.
The Freescale's silicons is only support 34 bit address now.
Do you mean I should not use words -- 'should be <2>'?
The #address-cells should be assigned according the address mode
supported by silicon.
Thanks!
Wei.
^ permalink raw reply
* Please pull from 'for_paulus' branch
From: Kumar Gala @ 2007-06-29 5:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for_paulus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_paulus
to receive the following updates:
arch/powerpc/Kconfig | 6
arch/powerpc/Makefile | 19
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 99 +++-
arch/powerpc/kernel/Makefile | 2
arch/powerpc/kernel/pci-common.c | 454 ++++++++++++++++++++
arch/powerpc/kernel/pci_32.c | 476 ----------------------
arch/powerpc/kernel/pci_64.c | 391 ------------------
arch/powerpc/kernel/ppc_ksyms.c | 4
arch/powerpc/platforms/4xx/Kconfig | 11
arch/powerpc/platforms/52xx/Kconfig | 2
arch/powerpc/platforms/52xx/efika.c | 9
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 18
arch/powerpc/platforms/82xx/Kconfig | 3
arch/powerpc/platforms/82xx/mpc82xx_ads.c | 17
arch/powerpc/platforms/83xx/Kconfig | 8
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 7
arch/powerpc/platforms/83xx/mpc832x_mds.c | 7
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 7
arch/powerpc/platforms/83xx/mpc834x_itx.c | 7
arch/powerpc/platforms/83xx/mpc834x_mds.c | 7
arch/powerpc/platforms/83xx/mpc836x_mds.c | 7
arch/powerpc/platforms/83xx/mpc83xx.h | 6
arch/powerpc/platforms/83xx/pci.c | 18
arch/powerpc/platforms/85xx/Kconfig | 5
arch/powerpc/platforms/85xx/mpc85xx.h | 2
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 10
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 17
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 7
arch/powerpc/platforms/85xx/pci.c | 11
arch/powerpc/platforms/86xx/Kconfig | 3
arch/powerpc/platforms/86xx/mpc86xx.h | 11
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 12
arch/powerpc/platforms/86xx/pci.c | 67 ++-
arch/powerpc/platforms/Kconfig | 24 +
arch/powerpc/platforms/Kconfig.cputype | 306 ++++++++++++--
arch/powerpc/platforms/cell/Kconfig | 1
arch/powerpc/platforms/celleb/Kconfig | 1
arch/powerpc/platforms/chrp/Kconfig | 1
arch/powerpc/platforms/chrp/Makefile | 3
arch/powerpc/platforms/chrp/pci.c | 7
arch/powerpc/platforms/embedded6xx/Kconfig | 5
arch/powerpc/platforms/embedded6xx/holly.c | 2
arch/powerpc/platforms/embedded6xx/linkstation.c | 10
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 9
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.h | 5
arch/powerpc/platforms/iseries/pci.c | 2
arch/powerpc/platforms/maple/Kconfig | 1
arch/powerpc/platforms/maple/pci.c | 6
arch/powerpc/platforms/pasemi/Kconfig | 1
arch/powerpc/platforms/pasemi/pci.c | 4
arch/powerpc/platforms/powermac/Kconfig | 2
arch/powerpc/platforms/powermac/pci.c | 14
arch/powerpc/platforms/ps3/Kconfig | 1
arch/powerpc/sysdev/Makefile | 3
arch/powerpc/sysdev/fsl_pcie.c | 171 -------
arch/powerpc/sysdev/indirect_pci.c | 44 +-
arch/powerpc/sysdev/mv64x60_pci.c | 7
arch/powerpc/sysdev/tsi108_pci.c | 10
arch/ppc/syslib/Makefile | 1
arch/ppc/syslib/indirect_pci.c | 134 ++++++
include/asm-powerpc/machdep.h | 2
include/asm-powerpc/mpc86xx.h | 6
include/asm-powerpc/pci-bridge.h | 129 ++++-
include/asm-powerpc/pci.h | 7
64 files changed, 1299 insertions(+), 1350 deletions(-)
Arnd Bergmann (7):
[POWERPC] move 82xx/83xx/86xx Kconfig options to platform selection
[POWERPC] autoselect optimal -mcpu= flag by platform
[POWERPC] rename add_bridge to avoid namespace clashes
[POWERPC] mpc82xx_ads build fix
[POWERPC] kill isa_{io,mem}_base definitions for !PCI
[POWERPC] fix building without PCI
[POWERPC] disallow building powermac and tsi108 without PCI
Kumar Gala (18):
[POWERPC] Remove set_cfg_type for PCI indirect users that don't need it
[POWERPC] 52xx: Remove support for PCI bus_offset
[POWERPC] Pass the pci_controller into pci_exclude_device
[POWERPC] Remove hack to determine the 2nd PHBs bus number
[POWERPC] Remove bus_offset in places its not really used
[POWERPC] Added self_busno to indicate which bus number the PHB is
[POWERPC] Removed remnants of bus_offset
[POWERPC] Added indirect_type to handle variants of PCI ops
[POWERPC] 86xx: Workaround PCI_PRIMARY_BUS usage
[POWERPC] Merge asm-ppc/pci-bridge.h into asm-power/pci-bridge.h
[POWERPC] Remove local_number from pci_controller
[POWERPC] Removed dead code related to PCI on ppc32
[POWERPC] Use global_number in ppc32 pci_controller
[POWERPC] Merge ppc32 and ppc64 pcibios_alloc_controller() prototypes
[POWERPC] Move pci_bus_to_hose users to pci_bus_to_host
[POWERPC] Move common PCI code out of pci_32/pci_64
[POWERPC] Use ppc64 style list management for pci_controller on ppc32
[POWERPC] Add copyright header to pci-common.c based on pci_{32,64}.c
Wade Farnsworth (1):
[POWERPC] 86xx: Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
York Sun (1):
[POWERPC] Let subordinate transparent bridges be transparent.
Zhang Wei (4):
[POWERPC] Remove PCI-e errata for MPC8641 silicon ver 1.0
[POWERPC] 86xx: Avoid system halt if link training isn't at least L0.
[POWERPC] MPC8641HPCN: Set IDE in ULI1575 to not native mode.
[POWERPC] 86xx: Created quirk_fsl_pcie_transparent() to initialize bridge resources.
^ permalink raw reply
* Re: [patch 2/9] autoselect optimal -mcpu= flag by platform
From: Paul Mackerras @ 2007-06-29 5:58 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev
In-Reply-To: <20070616000618.314570319@arndb.de>
arnd@arndb.de writes:
> +config PPC_CPU_SELECTION
> + bool "Advanced CPU selection"
Please provide some reasonable help for this option. As it is at the
moment, I get asked whether I want "Advanced CPU selection" - whatever
that is - and as a user I have no clue whether I want it or not. The
prompt is pretty uninformative. Do I want to be able to select an
advanced CPU? Well I suppose I do - who would want to select a
retarded CPU? - but that's presumably not what the question's about.
Paul.
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Paul Mackerras @ 2007-06-29 6:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <Pine.LNX.4.64.0706290023590.15748@blarg.am.freescale.net>
Kumar Gala writes:
> Please pull from 'for_paulus' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_paulus
Unfortunately with those commits I get this when compiling for a
64-bit target:
{standard input}: Assembler messages:
{standard input}:668: Error: Unrecognized opcode: `sldi'
{standard input}:676: Error: Unrecognized opcode: `sldi'
{standard input}:694: Error: Unrecognized opcode: `sldi'
{standard input}:952: Error: Unrecognized opcode: `slwi'
{standard input}:953: Error: Unrecognized opcode: `sldi'
{standard input}:1121: Error: Unrecognized opcode: `sldi'
{standard input}:1359: Error: Unrecognized opcode: `sldi'
{standard input}:1464: Error: Unrecognized opcode: `srdi'
make[2]: *** [init/main.o] Error 1
make[1]: *** [init] Error 2
make: *** [_all] Error 2
It turns out that with Arnd's patches we now get "-mcpu=powerpc64" on
the command line, and that means that gcc *doesn't* put "-mppc64" the
as command line, and as barfs on the 64-bit instructions. That's
presumably a gcc bug, but we'll have to work around it. I think the
best thing is just to not put the -mcpu=powerpc64 in CFLAGS when no
specific CPU is selected.
Paul.
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Kumar Gala @ 2007-06-29 7:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <18052.42546.78964.805791@cargo.ozlabs.ibm.com>
On Jun 29, 2007, at 1:26 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Please pull from 'for_paulus' branch of
>>
>> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
>> for_paulus
>
> Unfortunately with those commits I get this when compiling for a
> 64-bit target:
>
> {standard input}: Assembler messages:
> {standard input}:668: Error: Unrecognized opcode: `sldi'
> {standard input}:676: Error: Unrecognized opcode: `sldi'
> {standard input}:694: Error: Unrecognized opcode: `sldi'
> {standard input}:952: Error: Unrecognized opcode: `slwi'
> {standard input}:953: Error: Unrecognized opcode: `sldi'
> {standard input}:1121: Error: Unrecognized opcode: `sldi'
> {standard input}:1359: Error: Unrecognized opcode: `sldi'
> {standard input}:1464: Error: Unrecognized opcode: `srdi'
> make[2]: *** [init/main.o] Error 1
> make[1]: *** [init] Error 2
> make: *** [_all] Error 2
>
> It turns out that with Arnd's patches we now get "-mcpu=powerpc64" on
> the command line, and that means that gcc *doesn't* put "-mppc64" the
> as command line, and as barfs on the 64-bit instructions. That's
> presumably a gcc bug, but we'll have to work around it. I think the
> best thing is just to not put the -mcpu=powerpc64 in CFLAGS when no
> specific CPU is selected.
I dropped the patch and re-pushed my tree w/o it.
Let me know if you have any issues.
- k
^ permalink raw reply
* Re: mpc8270 & Intel 82551ER on 2.6.17.14
From: Pradyumna Sampath @ 2007-06-29 8:12 UTC (permalink / raw)
To: Nicholas Hickman; +Cc: linuxppc-embedded
In-Reply-To: <8140AAF341CC904BA92C3D6A5A1909782A2FA3@ditech-1.ditechllc.com>
Hi Nicholas,
On 6/29/07, Nicholas Hickman <nhickman@dtechlabs.com> wrote:
>
>
> I am having trouble getting two 82551ER Ethernet controllers running in
> Linux. I am able to scan the PCI bus and see the devices and I was even
> able to program the EEPROM from U-boot.
>
> In the kernel I mapped the IRQ's through /arch/ppc/m82xx_pci.c. I've been
> using the e100 drive that comes with the 2.6.17.14 kernel and have also
> tried the driver directly from Intel. Both give the same results. The PCI
> scan shows the correct output for how the device should be configured.
<snip..>
I have the same, exact same problem. But there are some of the
differences with the setup though. I have an MPC5200B and the other
difference is that I have a 2.6.21-rt3. However its the same ethernet
controller.
I am trying out a few things here, some of them being complete
guesses. But if I hit something, I will let this list know. Anyone
else had similar issues ? Request you to please holler.
regards
prady
--
htp://prady.livejournal.com
^ permalink raw reply
* Re: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Segher Boessenkool @ 2007-06-29 9:05 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <46B96294322F7D458F9648B60E15112C6F3281@zch01exm26.fsl.freescale.net>
>>> + - #address-cells : Address representation for
>> "rapidio" devices.
>>> + This field represents the number of cells needed to represent
>>> + the RapidIO address of the registers. For
>> supporting more than
>>> + 32-bits RapidIO address, this field should be <2>.
>>> + See 1) above for more details on defining #address-cells.
>>
>> What does the RapidIO standard say about number of address
>> bits? You want to follow that, so all RapidIO devices can
>> use the same #address-cells, not just the FSL ones. Also,
>> are there different kinds of address spaces on the bus, or
>> is it just one big memory-like space?
>
> I've checked the specification of RapidIO. The supporting of RapidIO
> extended address modes are 66, 50 and 34 bit.
These three are all two bits more than some "regular" size --
do those two extra bits have some special meaning perhaps,
like an address space identifier or something?
> The Freescale's silicons is only support 34 bit address now.
> Do you mean I should not use words -- 'should be <2>'?
> The #address-cells should be assigned according the address mode
> supported by silicon.
No. The #address-cells is determined by the bus binding,
so that all RapidIO busses on the planet can be represented
in a similar way in the OF device tree. Take for example
the PCI binding, which gives you three address cells -- one
to distinguish between different address spaces (configuration
space, legacy I/O space, memory mapped space) and to contain
some flags (prefetchable vs. non-prefetchable, etc.); the
other two 32-bit cells contain a 64-bit address, although
config and legacy I/O never are more than 32 bit, and many
PCI devices can't do 64-bit addressing at all.
Now, there is no OF binding for RapidIO yet of course, but
it would be good to start thinking about one while doing
the binding for your specific controller -- it will make
life easier down the line for everyone, including yourself.
Segher
^ permalink raw reply
* flashing file system
From: sarpa @ 2007-06-29 9:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I want to flash my file system which is in squashfs format in to my mpc5200
board. I have bdi2000. But it recognises .bin, .sss (S19), .hex formats. But
i don't know how to flash a file system (it is not showing any file type).
Do we need to convert it into any other format such as .bin? please help me
Thanks & Regards,
VS
--
View this message in context: http://www.nabble.com/flashing-file-system-tf3998851.html#a11357002
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Segher Boessenkool @ 2007-06-29 9:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <18052.42546.78964.805791@cargo.ozlabs.ibm.com>
>> Please pull from 'for_paulus' branch of
>>
>> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
>> for_paulus
>
> Unfortunately with those commits I get this when compiling for a
> 64-bit target:
>
> {standard input}: Assembler messages:
> {standard input}:668: Error: Unrecognized opcode: `sldi'
[etc.]
> It turns out that with Arnd's patches we now get "-mcpu=powerpc64" on
> the command line, and that means that gcc *doesn't* put "-mppc64" the
> as command line, and as barfs on the 64-bit instructions. That's
> presumably a gcc bug, but we'll have to work around it.
It is not. -mcpu=powerpc64 doesn't select an ABI, and your
GCC presumably defaults to the 32-bit ABI. Use -m64 on the
GCC command line, too, you need it, and it solves this issue
as a side effect.
It would be a bug if GCC would allow 64-bit insns in the
32-bit ABI for Linux, but that is currently not the case :-(
> I think the
> best thing is just to not put the -mcpu=powerpc64 in CFLAGS when no
> specific CPU is selected.
That would be the "use the compiler default CPU" option.
Segher
^ permalink raw reply
* RE: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Zhang Wei-r63237 @ 2007-06-29 9:20 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <8ee77b5f79ee0c0c5ead1f0acbe95bda@kernel.crashing.org>
Hi, Segher,=20
> DTS sector to the document of booting-without-of.txt file.
>=20
> >>> + - #address-cells : Address representation for
> >> "rapidio" devices.
> >>> + This field represents the number of cells needed=20
> to represent
> >>> + the RapidIO address of the registers. For
> >> supporting more than
> >>> + 32-bits RapidIO address, this field should be <2>.
> >>> + See 1) above for more details on defining #address-cells.
> >>
> >> What does the RapidIO standard say about number of address
> >> bits? You want to follow that, so all RapidIO devices can
> >> use the same #address-cells, not just the FSL ones. Also,
> >> are there different kinds of address spaces on the bus, or
> >> is it just one big memory-like space?
> >
> > I've checked the specification of RapidIO. The supporting of RapidIO
> > extended address modes are 66, 50 and 34 bit.
>=20
> These three are all two bits more than some "regular" size --
> do those two extra bits have some special meaning perhaps,
> like an address space identifier or something?
>=20
> > The Freescale's silicons is only support 34 bit address now.
> > Do you mean I should not use words -- 'should be <2>'?
> > The #address-cells should be assigned according the address mode
> > supported by silicon.
>=20
> No. The #address-cells is determined by the bus binding,
> so that all RapidIO busses on the planet can be represented
> in a similar way in the OF device tree. Take for example
> the PCI binding, which gives you three address cells -- one
> to distinguish between different address spaces (configuration
> space, legacy I/O space, memory mapped space) and to contain
> some flags (prefetchable vs. non-prefetchable, etc.); the
> other two 32-bit cells contain a 64-bit address, although
> config and legacy I/O never are more than 32 bit, and many
> PCI devices can't do 64-bit addressing at all.
>=20
> Now, there is no OF binding for RapidIO yet of course, but
> it would be good to start thinking about one while doing
> the binding for your specific controller -- it will make
> life easier down the line for everyone, including yourself.
>=20
How about I add more words here for more clear expression?
Such as "<2> for 34 and 50 bit address, <3> for 66 bit address".
Thanks!
Wei.
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Paul Mackerras @ 2007-06-29 9:31 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <fd3e668b664f28db6aa3071b1abdc642@kernel.crashing.org>
Segher Boessenkool writes:
> It is not. -mcpu=powerpc64 doesn't select an ABI, and your
> GCC presumably defaults to the 32-bit ABI. Use -m64 on the
> GCC command line, too, you need it, and it solves this issue
> as a side effect.
No, actually the command line had -m64 on it. The situation is this:
gcc -m64 -mtune=power4 works
gcc -m64 -mcpu=powerpc64 -mtune=power4 fails.
The problem is in the spec file where it works out what parameters to
pass to `as'. Without any -mcpu it correctly defaults to passing
-mppc64 (when -m64 is given). It then also has a list of -mcpu values
and the corresponding flag to pass to as, but powerpc64 isn't in that
list. Thus with -mcpu=powerpc64 we don't get -mppc64 passed to as.
Paul.
^ permalink raw reply
* Re: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Segher Boessenkool @ 2007-06-29 9:49 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <46B96294322F7D458F9648B60E15112C6F3312@zch01exm26.fsl.freescale.net>
>> No. The #address-cells is determined by the bus binding,
>> so that all RapidIO busses on the planet can be represented
>> in a similar way in the OF device tree. Take for example
>> the PCI binding, which gives you three address cells -- one
>> to distinguish between different address spaces (configuration
>> space, legacy I/O space, memory mapped space) and to contain
>> some flags (prefetchable vs. non-prefetchable, etc.); the
>> other two 32-bit cells contain a 64-bit address, although
>> config and legacy I/O never are more than 32 bit, and many
>> PCI devices can't do 64-bit addressing at all.
>>
>> Now, there is no OF binding for RapidIO yet of course, but
>> it would be good to start thinking about one while doing
>> the binding for your specific controller -- it will make
>> life easier down the line for everyone, including yourself.
>>
> How about I add more words here for more clear expression?
> Such as "<2> for 34 and 50 bit address, <3> for 66 bit address".
You should more explicitly define the address format, i.e.
what every bit means -- just saying it is 64 or 96 bits isn't
enough. While you're doing that, think of a way that can
represent _every possible_ RapidIO address, not just the ones
supported by this particular controller.
Segher
^ 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