* Re: OF compatible MTD platform RAM driver ?
From: Paul Mackerras @ 2008-03-30 21:16 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <7c44646510c3b98075de9aa57cad0bce@kernel.crashing.org>
Segher Boessenkool writes:
> > For RAMs we
> > need something to indicate that it's memory but intended for secondary
> > storage, not as main memory.
>
> How it is intended to be used is not a property of the hardware, so
> that information doesn't belong in the device tree at all. The Linux
> platform code should handle this, I imagine.
There must be some reason why it is not intended to be used as main
memory. Presumably it has something different about it compared to
"normal" RAM, and that difference could perfectly well be expressed in
the device tree.
Paul.
^ permalink raw reply
* mmu_hash_lock deadlock causes kernel stuck at 2.6.21 SMP powerpc 32bit
From: Gaash Hazan @ 2008-03-30 21:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: gaash-ppclnx, Gilad Ben-Yossef
(reposting)
Hello PPC SMP MM experts,
mmu_hash_lock (arch/powerpc/mm/hash_low_32.S) is a
(non-standard) spin lock that protects the CPU MMU
hashing table. It exists and used only with SMP
configurations.
In some scenarios, the spin lock is taken when
interrupts are *enabled* causing kernel deadlock at
the next take attempt in the same CPU.
The deadlock happened on 2.6.21 kernel, Powerpc 32 bit
with SMP enabled. At this moment system had one active
CPU. The sequence I saw was:
do_exit (program termination)
exit_mm
mmput
exit_mmap
free_pgtables
free_pgd_range
unmap_vmas
pte_free
hash_page_sync (takes mmu_hash_lock. Note: interrupts
are enabled)
timer_interrupt (timer interrupts occurs during
hash_page_sync, lock is taken) irq_exit do_softirq
__do_softirq net_rx_action (packet received from
network) ( ... omitted ... ) xdr_skb_read_bits
skb_copy_bits memcpy - memcpy causes DSI
exception(0x300). This is OK.
DSI exception handler calls hash_page
hash_page waits for mmu_mash_lock. It waits forever
since the lock is already taken.
Deadlock! with interrupts disabled. kernel is dead.
I think the rout cause of the problem is
hash_page_sync() taking the mmu_hash_lock spin lock
without disabling interrupts. This leads to the
deadlock.
To verify the theory, hash_page_sync() was wrapped
with interrupts disabled code and problem never
occurred again. Of course this is temporary workaround
as there are several places needed to be fixed.
What do you think?
Thanks,
Gaash
^ permalink raw reply
* Re: mmu_hash_lock deadlock causes kernel stuck at 2.6.21 SMP powerpc 32bit
From: Benjamin Herrenschmidt @ 2008-03-30 21:40 UTC (permalink / raw)
To: gaash-ppclnx; +Cc: linuxppc-dev, Gilad Ben-Yossef
In-Reply-To: <90380.16819.qm@web39603.mail.mud.yahoo.com>
On Sun, 2008-03-30 at 14:28 -0700, Gaash Hazan wrote:
> To verify the theory, hash_page_sync() was wrapped
> with interrupts disabled code and problem never
> occurred again. Of course this is temporary workaround
> as there are several places needed to be fixed.
It is definitely a bug in hash_page_sync() which should
clear MSR:EE while holding the lock.
I'll do a patch.
Thanks for finding that out !
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc: Fix deadlock with mmu_hash_lock in hash_page_sync
From: Benjamin Herrenschmidt @ 2008-03-30 21:49 UTC (permalink / raw)
To: gaash-ppclnx; +Cc: linuxppc-dev, Paul Mackerras, Gilad Ben-Yossef
In-Reply-To: <90380.16819.qm@web39603.mail.mud.yahoo.com>
hash_page_sync() takes and releases the low level mmu hash
lock in order to sync with other processors disposing of page
tables. Because that lock can be needed to service hash misses
triggered by interrupt handler, taking it must be done with
interrupts off. However, hash_page_sync() appear to be called
with interrupts enabled, thus causing occasional deadlocks.
We fix it by making sure hash_page_sync() masks interrupts while
holding the lock.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Please test and report asap thought it's probably too late for
2.6.25, it can still go into stable later on.
Index: linux-work/arch/powerpc/mm/hash_low_32.S
===================================================================
--- linux-work.orig/arch/powerpc/mm/hash_low_32.S 2008-03-31 08:42:56.000000000 +1100
+++ linux-work/arch/powerpc/mm/hash_low_32.S 2008-03-31 08:45:05.000000000 +1100
@@ -44,6 +44,9 @@ mmu_hash_lock:
#ifdef CONFIG_SMP
.text
_GLOBAL(hash_page_sync)
+ mfmsr r10
+ rlwinm r0,r10,0,17,15 /* clear bit 16 (MSR_EE) */
+ mtmsr r0
lis r8,mmu_hash_lock@h
ori r8,r8,mmu_hash_lock@l
lis r0,0x0fff
@@ -60,8 +63,9 @@ _GLOBAL(hash_page_sync)
eieio
li r0,0
stw r0,0(r8)
- blr
-#endif
+ mtmsr r10
+ blr
+#endif /* CONFIG_SMP */
/*
* Load a PTE into the hash table, if possible.
^ permalink raw reply
* Re: [PATCH 1/5] [v2][POWERPC] refactor dcr code
From: Benjamin Herrenschmidt @ 2008-03-30 22:02 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080328162616.61AEF15006B@mail199-sin.bigfish.com>
On Fri, 2008-03-28 at 09:23 -0700, Stephen Neuendorffer wrote:
> Previously, dcr support was configured at compile time to either using
> MMIO or native dcr instructions. Although this works for most
> platforms, it fails on FPGA platforms:
>
> 1) Systems may include more than one dcr bus.
> 2) Systems may be native dcr capable and still use memory mapped dcr interface.
>
> This patch provides runtime support based on the device trees for the
> case where CONFIG_PPC_DCR_MMIO and CONFIG_PPC_DCR_NATIVE are both
> selected. Previously, this was a poorly defined configuration, which
> happened to provide NATIVE support. The runtime selection is made
> based on the dcr slave device having a 'dcr-access-method' attribute
> in the device tree. If only one of the above options is selected,
> then the code uses #defines to select only the used code in order to
> avoid interoducing overhead in existing usage.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Looks good. Haven't had a chance to test it yet, but tentatively
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Initially, I thought about using function pointers but the if/else will
probably end up being more efficient. The only thing maybe to ponder
is whether we could avoid the dcr-generic.h file completely, and have
the generic wrappers be inline, though considering how slow DCRs are,
it may not be that useful in practice and less clean...
Cheers,
Ben.
> ---
> arch/powerpc/sysdev/dcr.c | 91 ++++++++++++++++++++++++++++++++-----
> include/asm-powerpc/dcr-generic.h | 49 ++++++++++++++++++++
> include/asm-powerpc/dcr-mmio.h | 20 +++++---
> include/asm-powerpc/dcr-native.h | 16 ++++---
> include/asm-powerpc/dcr.h | 36 ++++++++++++++-
> 5 files changed, 186 insertions(+), 26 deletions(-)
> create mode 100644 include/asm-powerpc/dcr-generic.h
>
> diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
> index 437e48d..d3de0ff 100644
> --- a/arch/powerpc/sysdev/dcr.c
> +++ b/arch/powerpc/sysdev/dcr.c
> @@ -23,6 +23,68 @@
> #include <asm/prom.h>
> #include <asm/dcr.h>
>
> +#if defined(CONFIG_PPC_DCR_NATIVE) && defined(CONFIG_PPC_DCR_MMIO)
> +
> +bool dcr_map_ok_generic(dcr_host_t host)
> +{
> + if (host.type == INVALID)
> + return 0;
> + else if (host.type == NATIVE)
> + return dcr_map_ok_native(host.host.native);
> + else
> + return dcr_map_ok_mmio(host.host.mmio);
> +}
> +EXPORT_SYMBOL_GPL(dcr_map_ok_generic);
> +
> +dcr_host_t dcr_map_generic(struct device_node *dev,
> + unsigned int dcr_n,
> + unsigned int dcr_c)
> +{
> + dcr_host_t host;
> + const char *prop = of_get_property(dev, "dcr-access-method", NULL);
> +
> + if (!strcmp(prop, "native")) {
> + host.type = NATIVE;
> + host.host.native = dcr_map_native(dev, dcr_n, dcr_c);
> + } else if (!strcmp(prop, "mmio")) {
> + host.type = MMIO;
> + host.host.mmio = dcr_map_mmio(dev, dcr_n, dcr_c);
> + } else
> + host.type = INVALID;
> +
> + return host;
> +}
> +EXPORT_SYMBOL_GPL(dcr_map_generic);
> +
> +void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c)
> +{
> + if (host.type == NATIVE)
> + dcr_unmap_native(host.host.native, dcr_c);
> + else
> + dcr_unmap_mmio(host.host.mmio, dcr_c);
> +}
> +EXPORT_SYMBOL_GPL(dcr_unmap_generic);
> +
> +u32 dcr_read_generic(dcr_host_t host, unsigned int dcr_n)
> +{
> + if (host.type == NATIVE)
> + return dcr_read_native(host.host.native, dcr_n);
> + else
> + return dcr_read_mmio(host.host.mmio, dcr_n);
> +}
> +EXPORT_SYMBOL_GPL(dcr_read_generic);
> +
> +void dcr_write_generic(dcr_host_t host, unsigned int dcr_n, u32 value)
> +{
> + if (host.type == NATIVE)
> + dcr_write_native(host.host.native, dcr_n, value);
> + else
> + dcr_write_mmio(host.host.mmio, dcr_n, value);
> +}
> +EXPORT_SYMBOL_GPL(dcr_write_generic);
> +
> +#endif /* defined(CONFIG_PPC_DCR_NATIVE) && defined(CONFIG_PPC_DCR_MMIO) */
> +
> unsigned int dcr_resource_start(struct device_node *np, unsigned int index)
> {
> unsigned int ds;
> @@ -47,7 +109,7 @@ unsigned int dcr_resource_len(struct device_node *np, unsigned int index)
> }
> EXPORT_SYMBOL_GPL(dcr_resource_len);
>
> -#ifndef CONFIG_PPC_DCR_NATIVE
> +#ifdef CONFIG_PPC_DCR_MMIO
>
> static struct device_node * find_dcr_parent(struct device_node * node)
> {
> @@ -101,18 +163,19 @@ u64 of_translate_dcr_address(struct device_node *dev,
> return ret;
> }
>
> -dcr_host_t dcr_map(struct device_node *dev, unsigned int dcr_n,
> - unsigned int dcr_c)
> +dcr_host_mmio_t dcr_map_mmio(struct device_node *dev,
> + unsigned int dcr_n,
> + unsigned int dcr_c)
> {
> - dcr_host_t ret = { .token = NULL, .stride = 0, .base = dcr_n };
> + dcr_host_mmio_t ret = { .token = NULL, .stride = 0, .base = dcr_n };
> u64 addr;
>
> pr_debug("dcr_map(%s, 0x%x, 0x%x)\n",
> dev->full_name, dcr_n, dcr_c);
>
> addr = of_translate_dcr_address(dev, dcr_n, &ret.stride);
> - pr_debug("translates to addr: 0x%lx, stride: 0x%x\n",
> - addr, ret.stride);
> + pr_debug("translates to addr: 0x%llx, stride: 0x%x\n",
> + (unsigned long long) addr, ret.stride);
> if (addr == OF_BAD_ADDR)
> return ret;
> pr_debug("mapping 0x%x bytes\n", dcr_c * ret.stride);
> @@ -124,11 +187,11 @@ dcr_host_t dcr_map(struct device_node *dev, unsigned int dcr_n,
> ret.token -= dcr_n * ret.stride;
> return ret;
> }
> -EXPORT_SYMBOL_GPL(dcr_map);
> +EXPORT_SYMBOL_GPL(dcr_map_mmio);
>
> -void dcr_unmap(dcr_host_t host, unsigned int dcr_c)
> +void dcr_unmap_mmio(dcr_host_mmio_t host, unsigned int dcr_c)
> {
> - dcr_host_t h = host;
> + dcr_host_mmio_t h = host;
>
> if (h.token == NULL)
> return;
> @@ -136,7 +199,11 @@ void dcr_unmap(dcr_host_t host, unsigned int dcr_c)
> iounmap(h.token);
> h.token = NULL;
> }
> -EXPORT_SYMBOL_GPL(dcr_unmap);
> -#else /* defined(CONFIG_PPC_DCR_NATIVE) */
> +EXPORT_SYMBOL_GPL(dcr_unmap_mmio);
> +
> +#endif /* defined(CONFIG_PPC_DCR_MMIO) */
> +
> +#ifdef CONFIG_PPC_DCR_NATIVE
> DEFINE_SPINLOCK(dcr_ind_lock);
> -#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
> +#endif /* defined(CONFIG_PPC_DCR_NATIVE) */
> +
> diff --git a/include/asm-powerpc/dcr-generic.h b/include/asm-powerpc/dcr-generic.h
> new file mode 100644
> index 0000000..0ee74fb
> --- /dev/null
> +++ b/include/asm-powerpc/dcr-generic.h
> @@ -0,0 +1,49 @@
> +/*
> + * (c) Copyright 2006 Benjamin Herrenschmidt, IBM Corp.
> + * <benh@kernel.crashing.org>
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
> + * the GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +#ifndef _ASM_POWERPC_DCR_GENERIC_H
> +#define _ASM_POWERPC_DCR_GENERIC_H
> +#ifdef __KERNEL__
> +#ifndef __ASSEMBLY__
> +
> +enum host_type_t {MMIO, NATIVE, INVALID};
> +
> +typedef struct {
> + enum host_type_t type;
> + union {
> + dcr_host_mmio_t mmio;
> + dcr_host_native_t native;
> + } host;
> +} dcr_host_t;
> +
> +extern bool dcr_map_ok_generic(dcr_host_t host);
> +
> +extern dcr_host_t dcr_map_generic(struct device_node *dev, unsigned int dcr_n,
> + unsigned int dcr_c);
> +extern void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c);
> +
> +extern u32 dcr_read_generic(dcr_host_t host, unsigned int dcr_n);
> +
> +extern void dcr_write_generic(dcr_host_t host, unsigned int dcr_n, u32 value);
> +
> +#endif /* __ASSEMBLY__ */
> +#endif /* __KERNEL__ */
> +#endif /* _ASM_POWERPC_DCR_GENERIC_H */
> +
> +
> diff --git a/include/asm-powerpc/dcr-mmio.h b/include/asm-powerpc/dcr-mmio.h
> index 08532ff..acd491d 100644
> --- a/include/asm-powerpc/dcr-mmio.h
> +++ b/include/asm-powerpc/dcr-mmio.h
> @@ -27,20 +27,26 @@ typedef struct {
> void __iomem *token;
> unsigned int stride;
> unsigned int base;
> -} dcr_host_t;
> +} dcr_host_mmio_t;
>
> -#define DCR_MAP_OK(host) ((host).token != NULL)
> +static inline bool dcr_map_ok_mmio(dcr_host_mmio_t host)
> +{
> + return host.token != NULL;
> +}
>
> -extern dcr_host_t dcr_map(struct device_node *dev, unsigned int dcr_n,
> - unsigned int dcr_c);
> -extern void dcr_unmap(dcr_host_t host, unsigned int dcr_c);
> +extern dcr_host_mmio_t dcr_map_mmio(struct device_node *dev,
> + unsigned int dcr_n,
> + unsigned int dcr_c);
> +extern void dcr_unmap_mmio(dcr_host_mmio_t host, unsigned int dcr_c);
>
> -static inline u32 dcr_read(dcr_host_t host, unsigned int dcr_n)
> +static inline u32 dcr_read_mmio(dcr_host_mmio_t host, unsigned int dcr_n)
> {
> return in_be32(host.token + ((host.base + dcr_n) * host.stride));
> }
>
> -static inline void dcr_write(dcr_host_t host, unsigned int dcr_n, u32 value)
> +static inline void dcr_write_mmio(dcr_host_mmio_t host,
> + unsigned int dcr_n,
> + u32 value)
> {
> out_be32(host.token + ((host.base + dcr_n) * host.stride), value);
> }
> diff --git a/include/asm-powerpc/dcr-native.h b/include/asm-powerpc/dcr-native.h
> index be6c879..67832e5 100644
> --- a/include/asm-powerpc/dcr-native.h
> +++ b/include/asm-powerpc/dcr-native.h
> @@ -26,14 +26,18 @@
>
> typedef struct {
> unsigned int base;
> -} dcr_host_t;
> +} dcr_host_native_t;
>
> -#define DCR_MAP_OK(host) (1)
> +static inline bool dcr_map_ok_native(dcr_host_native_t host)
> +{
> + return 1;
> +}
>
> -#define dcr_map(dev, dcr_n, dcr_c) ((dcr_host_t){ .base = (dcr_n) })
> -#define dcr_unmap(host, dcr_c) do {} while (0)
> -#define dcr_read(host, dcr_n) mfdcr(dcr_n + host.base)
> -#define dcr_write(host, dcr_n, value) mtdcr(dcr_n + host.base, value)
> +#define dcr_map_native(dev, dcr_n, dcr_c) \
> + ((dcr_host_native_t){ .base = (dcr_n) })
> +#define dcr_unmap_native(host, dcr_c) do {} while (0)
> +#define dcr_read_native(host, dcr_n) mfdcr(dcr_n + host.base)
> +#define dcr_write_native(host, dcr_n, value) mtdcr(dcr_n + host.base, value)
>
> /* Device Control Registers */
> void __mtdcr(int reg, unsigned int val);
> diff --git a/include/asm-powerpc/dcr.h b/include/asm-powerpc/dcr.h
> index 9338d50..6b86322 100644
> --- a/include/asm-powerpc/dcr.h
> +++ b/include/asm-powerpc/dcr.h
> @@ -20,14 +20,47 @@
> #ifndef _ASM_POWERPC_DCR_H
> #define _ASM_POWERPC_DCR_H
> #ifdef __KERNEL__
> +#ifndef __ASSEMBLY__
> #ifdef CONFIG_PPC_DCR
>
> #ifdef CONFIG_PPC_DCR_NATIVE
> #include <asm/dcr-native.h>
> -#else
> +#endif
> +
> +#ifdef CONFIG_PPC_DCR_MMIO
> #include <asm/dcr-mmio.h>
> #endif
>
> +#if defined(CONFIG_PPC_DCR_NATIVE) && defined(CONFIG_PPC_DCR_MMIO)
> +
> +#include <asm/dcr-generic.h>
> +
> +#define DCR_MAP_OK(host) dcr_map_ok_generic(host)
> +#define dcr_map(dev, dcr_n, dcr_c) dcr_map_generic(dev, dcr_n, dcr_c)
> +#define dcr_unmap(host, dcr_c) dcr_unmap_generic(host, dcr_c)
> +#define dcr_read(host, dcr_n) dcr_read_generic(host, dcr_n)
> +#define dcr_write(host, dcr_n, value) dcr_write_generic(host, dcr_n, value)
> +
> +#else
> +
> +#ifdef CONFIG_PPC_DCR_NATIVE
> +typedef dcr_host_native_t dcr_host_t;
> +#define DCR_MAP_OK(host) dcr_map_ok_native(host)
> +#define dcr_map(dev, dcr_n, dcr_c) dcr_map_native(dev, dcr_n, dcr_c)
> +#define dcr_unmap(host, dcr_c) dcr_unmap_native(host, dcr_c)
> +#define dcr_read(host, dcr_n) dcr_read_native(host, dcr_n)
> +#define dcr_write(host, dcr_n, value) dcr_write_native(host, dcr_n, value)
> +#else
> +typedef dcr_host_mmio_t dcr_host_t;
> +#define DCR_MAP_OK(host) dcr_map_ok_mmio(host)
> +#define dcr_map(dev, dcr_n, dcr_c) dcr_map_mmio(dev, dcr_n, dcr_c)
> +#define dcr_unmap(host, dcr_c) dcr_unmap_mmio(host, dcr_c)
> +#define dcr_read(host, dcr_n) dcr_read_mmio(host, dcr_n)
> +#define dcr_write(host, dcr_n, value) dcr_write_mmio(host, dcr_n, value)
> +#endif
> +
> +#endif /* defined(CONFIG_PPC_DCR_NATIVE) && defined(CONFIG_PPC_DCR_MMIO) */
> +
> /*
> * On CONFIG_PPC_MERGE, we have additional helpers to read the DCR
> * base from the device-tree
> @@ -41,5 +74,6 @@ extern unsigned int dcr_resource_len(struct device_node *np,
> #endif /* CONFIG_PPC_MERGE */
>
> #endif /* CONFIG_PPC_DCR */
> +#endif /* __ASSEMBLY__ */
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_DCR_H */
^ permalink raw reply
* Re: [PATCH 3/5] [POWERPC] explicit dcr support
From: Benjamin Herrenschmidt @ 2008-03-30 22:04 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080328162617.E9E3017A008F@mail170-dub.bigfish.com>
On Fri, 2008-03-28 at 09:23 -0700, Stephen Neuendorffer wrote:
> Added literal mapping support if no device-tree support. Added
> CONFIG_OF to guard device-tree parts, since literal support works for
> arch=ppc.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
I'll let others decide whether they want to do that addition
to arch/ppc (which is really what it is) or not ... I'd rather
not myself considering that arch/ppc is scheduled to go away
soon now.
Cheers,
Ben.
> ---
> arch/powerpc/sysdev/dcr.c | 82 ++++++++++++++++++++++++++++---------
> include/asm-powerpc/dcr-generic.h | 2 +
> include/asm-powerpc/dcr-mmio.h | 11 +++++
> include/asm-powerpc/dcr-native.h | 8 ++++
> include/asm-powerpc/dcr.h | 24 +++++++++++
> 5 files changed, 108 insertions(+), 19 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
> index d3de0ff..2ccae80 100644
> --- a/arch/powerpc/sysdev/dcr.c
> +++ b/arch/powerpc/sysdev/dcr.c
> @@ -20,9 +20,34 @@
> #undef DEBUG
>
> #include <linux/kernel.h>
> +#include <linux/module.h>
> #include <asm/prom.h>
> #include <asm/dcr.h>
>
> +#ifdef CONFIG_OF
> +static struct device_node *find_dcr_parent(struct device_node *node)
> +{
> + struct device_node *par, *tmp;
> + const u32 *p;
> +
> + for (par = of_node_get(node); par;) {
> + if (of_get_property(par, "dcr-controller", NULL))
> + break;
> + p = of_get_property(par, "dcr-parent", NULL);
> + tmp = par;
> + if (p == NULL)
> + par = of_get_parent(par);
> + else
> + par = of_find_node_by_phandle(*p);
> + of_node_put(tmp);
> + }
> + return par;
> +}
> +#endif /* CONFIG_OF */
> +
> +
> +/* Indirection layer for providing both NATIVE and MMIO support. */
> +
> #if defined(CONFIG_PPC_DCR_NATIVE) && defined(CONFIG_PPC_DCR_MMIO)
>
> bool dcr_map_ok_generic(dcr_host_t host)
> @@ -36,12 +61,24 @@ bool dcr_map_ok_generic(dcr_host_t host)
> }
> EXPORT_SYMBOL_GPL(dcr_map_ok_generic);
>
> +#ifdef CONFIG_OF
> dcr_host_t dcr_map_generic(struct device_node *dev,
> unsigned int dcr_n,
> unsigned int dcr_c)
> {
> dcr_host_t host;
> - const char *prop = of_get_property(dev, "dcr-access-method", NULL);
> + struct device_node *dp;
> +
> + dp = find_dcr_parent(dev);
> + if (dp == NULL) {
> + host.type = INVALID;
> + return host;
> + }
> +
> + const char *prop = of_get_property(dp, "dcr-access-method", NULL);
> +
> + pr_debug("dcr_map_generic(dcr-access-method = %s)\n",
> + prop);
>
> if (!strcmp(prop, "native")) {
> host.type = NATIVE;
> @@ -56,6 +93,8 @@ dcr_host_t dcr_map_generic(struct device_node *dev,
> }
> EXPORT_SYMBOL_GPL(dcr_map_generic);
>
> +#endif /* CONFIG_OF */
> +
> void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c)
> {
> if (host.type == NATIVE)
> @@ -85,9 +124,10 @@ EXPORT_SYMBOL_GPL(dcr_write_generic);
>
> #endif /* defined(CONFIG_PPC_DCR_NATIVE) && defined(CONFIG_PPC_DCR_MMIO) */
>
> +#ifdef CONFIG_OF
> unsigned int dcr_resource_start(struct device_node *np, unsigned int index)
> {
> - unsigned int ds;
> + int ds;
> const u32 *dr = of_get_property(np, "dcr-reg", &ds);
>
> if (dr == NULL || ds & 1 || index >= (ds / 8))
> @@ -99,7 +139,7 @@ EXPORT_SYMBOL_GPL(dcr_resource_start);
>
> unsigned int dcr_resource_len(struct device_node *np, unsigned int index)
> {
> - unsigned int ds;
> + int ds;
> const u32 *dr = of_get_property(np, "dcr-reg", &ds);
>
> if (dr == NULL || ds & 1 || index >= (ds / 8))
> @@ -109,26 +149,28 @@ unsigned int dcr_resource_len(struct device_node *np, unsigned int index)
> }
> EXPORT_SYMBOL_GPL(dcr_resource_len);
>
> +#endif /* CONFIG_OF */
> +
> +
> +
> +/* Support for MMIO */
> #ifdef CONFIG_PPC_DCR_MMIO
>
> -static struct device_node * find_dcr_parent(struct device_node * node)
> +dcr_host_mmio_t dcr_map_mmio_literal_mmio(resource_size_t mmio_start,
> + unsigned int stride,
> + unsigned int dcr_n,
> + unsigned int dcr_c)
> {
> - struct device_node *par, *tmp;
> - const u32 *p;
> -
> - for (par = of_node_get(node); par;) {
> - if (of_get_property(par, "dcr-controller", NULL))
> - break;
> - p = of_get_property(par, "dcr-parent", NULL);
> - tmp = par;
> - if (p == NULL)
> - par = of_get_parent(par);
> - else
> - par = of_find_node_by_phandle(*p);
> - of_node_put(tmp);
> - }
> - return par;
> + dcr_host_mmio_t host;
> + host.stride = stride;
> + host.token = ioremap(mmio_start, dcr_c * stride);
> + host.token -= dcr_n * stride;
> + host.base = dcr_n;
> + return host;
> }
> +EXPORT_SYMBOL_GPL(dcr_map_mmio_literal_mmio);
> +
> +#ifdef CONFIG_OF
>
> u64 of_translate_dcr_address(struct device_node *dev,
> unsigned int dcr_n,
> @@ -189,6 +231,8 @@ dcr_host_mmio_t dcr_map_mmio(struct device_node *dev,
> }
> EXPORT_SYMBOL_GPL(dcr_map_mmio);
>
> +#endif /* CONFIG_OF */
> +
> void dcr_unmap_mmio(dcr_host_mmio_t host, unsigned int dcr_c)
> {
> dcr_host_mmio_t h = host;
> diff --git a/include/asm-powerpc/dcr-generic.h b/include/asm-powerpc/dcr-generic.h
> index 0ee74fb..8032795 100644
> --- a/include/asm-powerpc/dcr-generic.h
> +++ b/include/asm-powerpc/dcr-generic.h
> @@ -34,8 +34,10 @@ typedef struct {
>
> extern bool dcr_map_ok_generic(dcr_host_t host);
>
> +#ifdef CONFIG_OF
> extern dcr_host_t dcr_map_generic(struct device_node *dev, unsigned int dcr_n,
> unsigned int dcr_c);
> +#endif
> extern void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c);
>
> extern u32 dcr_read_generic(dcr_host_t host, unsigned int dcr_n);
> diff --git a/include/asm-powerpc/dcr-mmio.h b/include/asm-powerpc/dcr-mmio.h
> index acd491d..b12d291 100644
> --- a/include/asm-powerpc/dcr-mmio.h
> +++ b/include/asm-powerpc/dcr-mmio.h
> @@ -34,9 +34,18 @@ static inline bool dcr_map_ok_mmio(dcr_host_mmio_t host)
> return host.token != NULL;
> }
>
> +extern dcr_host_mmio_t dcr_map_mmio_literal_mmio(resource_size_t mmio_start,
> + unsigned int stride,
> + unsigned int dcr_n,
> + unsigned int dcr_c);
> +
> +
> +#ifdef CONFIG_OF
> extern dcr_host_mmio_t dcr_map_mmio(struct device_node *dev,
> unsigned int dcr_n,
> unsigned int dcr_c);
> +#endif
> +
> extern void dcr_unmap_mmio(dcr_host_mmio_t host, unsigned int dcr_c);
>
> static inline u32 dcr_read_mmio(dcr_host_mmio_t host, unsigned int dcr_n)
> @@ -51,9 +60,11 @@ static inline void dcr_write_mmio(dcr_host_mmio_t host,
> out_be32(host.token + ((host.base + dcr_n) * host.stride), value);
> }
>
> +#ifdef CONFIG_OF
> extern u64 of_translate_dcr_address(struct device_node *dev,
> unsigned int dcr_n,
> unsigned int *stride);
> +#endif
>
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_DCR_MMIO_H */
> diff --git a/include/asm-powerpc/dcr-native.h b/include/asm-powerpc/dcr-native.h
> index 67832e5..9b3e255 100644
> --- a/include/asm-powerpc/dcr-native.h
> +++ b/include/asm-powerpc/dcr-native.h
> @@ -33,6 +33,14 @@ static inline bool dcr_map_ok_native(dcr_host_native_t host)
> return 1;
> }
>
> +static inline
> +dcr_host_native_t dcr_map_native_literal_native(unsigned int dcr_n)
> +{
> + dcr_host_native_t host;
> + host.base = dcr_n;
> + return host;
> +}
> +
> #define dcr_map_native(dev, dcr_n, dcr_c) \
> ((dcr_host_native_t){ .base = (dcr_n) })
> #define dcr_unmap_native(host, dcr_c) do {} while (0)
> diff --git a/include/asm-powerpc/dcr.h b/include/asm-powerpc/dcr.h
> index 6b86322..dfd1c24 100644
> --- a/include/asm-powerpc/dcr.h
> +++ b/include/asm-powerpc/dcr.h
> @@ -35,6 +35,27 @@
>
> #include <asm/dcr-generic.h>
>
> +static inline
> +dcr_host_t dcr_map_mmio_literal(resource_size_t mmio_start,
> + unsigned int stride,
> + unsigned int dcr_n,
> + unsigned int dcr_c)
> +{
> + dcr_host_t host;
> + host.type = MMIO;
> + host.host.mmio =
> + dcr_map_mmio_literal_mmio(mmio_start, stride, dcr_n, dcr_c);
> + return host;
> +}
> +static inline
> +dcr_host_t dcr_map_native_literal(unsigned int dcr_n)
> +{
> + dcr_host_t host;
> + host.type = NATIVE;
> + host.host.native = dcr_map_native_literal_native(dcr_n);
> + return host;
> +}
> +
> #define DCR_MAP_OK(host) dcr_map_ok_generic(host)
> #define dcr_map(dev, dcr_n, dcr_c) dcr_map_generic(dev, dcr_n, dcr_c)
> #define dcr_unmap(host, dcr_c) dcr_unmap_generic(host, dcr_c)
> @@ -45,6 +66,7 @@
>
> #ifdef CONFIG_PPC_DCR_NATIVE
> typedef dcr_host_native_t dcr_host_t;
> +#define dcr_map_native_literal(dcr_n) dcr_map_native_literal_native(dcr_n)
> #define DCR_MAP_OK(host) dcr_map_ok_native(host)
> #define dcr_map(dev, dcr_n, dcr_c) dcr_map_native(dev, dcr_n, dcr_c)
> #define dcr_unmap(host, dcr_c) dcr_unmap_native(host, dcr_c)
> @@ -52,6 +74,8 @@ typedef dcr_host_native_t dcr_host_t;
> #define dcr_write(host, dcr_n, value) dcr_write_native(host, dcr_n, value)
> #else
> typedef dcr_host_mmio_t dcr_host_t;
> +#define dcr_map_mmio_literal(mmio_start, stride, dcr_n, dcr_c) \
> + dcr_map_mmio_literal_mmio(mmio_start, stride, dcr_n, dcr_c)
> #define DCR_MAP_OK(host) dcr_map_ok_mmio(host)
> #define dcr_map(dev, dcr_n, dcr_c) dcr_map_mmio(dev, dcr_n, dcr_c)
> #define dcr_unmap(host, dcr_c) dcr_unmap_mmio(host, dcr_c)
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Segher Boessenkool @ 2008-03-30 22:39 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <18416.813.635397.559197@cargo.ozlabs.ibm.com>
>>> For RAMs we
>>> need something to indicate that it's memory but intended for
>>> secondary
>>> storage, not as main memory.
>>
>> How it is intended to be used is not a property of the hardware, so
>> that information doesn't belong in the device tree at all. The Linux
>> platform code should handle this, I imagine.
>
> There must be some reason why it is not intended to be used as main
> memory. Presumably it has something different about it compared to
> "normal" RAM, and that difference could perfectly well be expressed in
> the device tree.
Sure, that's a different thing. It might sit on a bus that doesn't
do cache coherency, or maybe it's just slow (or sits on a slow bus).
All these things can be usefully expressed in the device tree (but
typically are not, it is left to the client code to know this stuff
implicitly).
It's still the (platform) probe code its responsibility to figure
out what (if anything) to do with any device. And "main memory"
is probed differently (via /chosen/memory, for example) anyway.
Well, actually, Linux searches for all nodes with device_type "memory",
which should work fine as well [*].
So, all in all, I think we should just give these "auxiliary memory"
devices a name of "ram" c.q. "rom", and some "reg", and that should
be all that is needed: the main memory probe stuff won't consider
these nodes, and the (platform) device probe code can do whatever it
wants (create mtd devices, I guess).
Segher
[*] It seems to me the longtrail workaround code in prom_init.c is
incorrect though: it will match any node with name "memory" that
doesn't have a device_type?
^ permalink raw reply
* [2.6 patch] powerpc: remove the non-functional PPC_PREP bits
From: Adrian Bunk @ 2008-03-30 22:40 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel
Back in November 2005, the PPC_PREP bits under arch/powerpc/ were marked
as BROKEN due to not being working.
It doesn't seem to make much sense to keep this rudimentary support even
longer.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
arch/powerpc/Kconfig | 5 +---
arch/powerpc/kernel/setup-common.c | 6 -----
arch/powerpc/platforms/Kconfig | 3 --
arch/powerpc/platforms/prep/Kconfig | 31 ----------------------------
include/asm-powerpc/processor.h | 7 ------
5 files changed, 3 insertions(+), 49 deletions(-)
75e5883ddd71921318afb01dd7d2402528f3b8e5 diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1189d8d..380b7a0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -309,7 +309,6 @@ config CRASH_DUMP
config PPCBUG_NVRAM
bool "Enable reading PPCBUG NVRAM during boot" if PPLUS || LOPEC
- default y if PPC_PREP
config IRQ_ALL_CPUS
bool "Distribute interrupts on all CPUs by default"
@@ -453,7 +452,7 @@ menu "Bus options"
config ISA
bool "Support for ISA-bus hardware"
- depends on PPC_PREP || PPC_CHRP
+ depends on PPC_CHRP
select PPC_I8259
help
Find out whether you have ISA slots on your motherboard. ISA is the
@@ -635,7 +634,7 @@ config TASK_SIZE_BOOL
config TASK_SIZE
hex "Size of user task space" if TASK_SIZE_BOOL
- default "0x80000000" if PPC_PREP || PPC_8xx
+ default "0x80000000" if PPC_8xx
default "0xc0000000"
config CONSISTENT_START_BOOL
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 6adb5a1..fc32f53 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -570,12 +570,6 @@ int check_legacy_ioport(unsigned long base_port)
case FDC_BASE: /* FDC1 */
np = of_find_node_by_type(NULL, "fdc");
break;
-#ifdef CONFIG_PPC_PREP
- case _PIDXR:
- case _PNPWRP:
- case PNPBIOS_BASE:
- /* implement me */
-#endif
default:
/* ipmi is supposed to fail here */
break;
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index a578b96..3a2954d 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -42,7 +42,6 @@ source "arch/powerpc/platforms/chrp/Kconfig"
source "arch/powerpc/platforms/512x/Kconfig"
source "arch/powerpc/platforms/52xx/Kconfig"
source "arch/powerpc/platforms/powermac/Kconfig"
-source "arch/powerpc/platforms/prep/Kconfig"
source "arch/powerpc/platforms/maple/Kconfig"
source "arch/powerpc/platforms/pasemi/Kconfig"
source "arch/powerpc/platforms/celleb/Kconfig"
@@ -210,7 +209,7 @@ endmenu
config PPC601_SYNC_FIX
bool "Workarounds for PPC601 bugs"
- depends on 6xx && (PPC_PREP || PPC_PMAC)
+ depends on 6xx && PPC_PMAC
help
Some versions of the PPC601 (the first PowerPC chip) have bugs which
mean that extra synchronization instructions are required near
diff --git a/arch/powerpc/platforms/prep/Kconfig b/arch/powerpc/platforms/prep/Kconfig
deleted file mode 100644
index 29d4112..0000000
--- a/arch/powerpc/platforms/prep/Kconfig
+++ /dev/null
@@ -1,31 +0,0 @@
-config PPC_PREP
- bool "PowerPC Reference Platform (PReP) based machines"
- depends on PPC_MULTIPLATFORM && PPC32 && BROKEN
- select MPIC
- select PPC_I8259
- select PPC_INDIRECT_PCI
- select PPC_UDBG_16550
- select PPC_NATIVE
- default n
-
-config PREP_RESIDUAL
- bool "Support for PReP Residual Data"
- depends on PPC_PREP
- help
- Some PReP systems have residual data passed to the kernel by the
- firmware. This allows detection of memory size, devices present and
- other useful pieces of information. Sometimes this information is
- not present or incorrect, in which case it could lead to the machine
- behaving incorrectly. If this happens, either disable PREP_RESIDUAL
- or pass the 'noresidual' option to the kernel.
-
- If you are running a PReP system, say Y here, otherwise say N.
-
-config PROC_PREPRESIDUAL
- bool "Support for reading of PReP Residual Data in /proc"
- depends on PREP_RESIDUAL && PROC_FS
- help
- Enabling this option will create a /proc/residual file which allows
- you to get at the residual data on PReP systems. You will need a tool
- (lsresidual) to parse it. If you aren't on a PReP system, you don't
- want this.
diff --git a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h
index fd98ca9..077bcbd 100644
--- a/include/asm-powerpc/processor.h
+++ b/include/asm-powerpc/processor.h
@@ -38,13 +38,6 @@
extern int _chrp_type;
-#ifdef CONFIG_PPC_PREP
-
-/* what kind of prep workstation we are */
-extern int _prep_type;
-
-#endif /* CONFIG_PPC_PREP */
-
#endif /* defined(__KERNEL__) && defined(CONFIG_PPC32) */
/*
^ permalink raw reply related
* Re: [PATCH 1/9] [POWERPC] mv64x60: change FDT compatible prefix to mrvl
From: David Gibson @ 2008-03-30 23:44 UTC (permalink / raw)
To: Grant Likely; +Cc: paulus, linuxppc-dev
In-Reply-To: <fa686aa40803281647y4ccc4605n1507f9c1868d4c0f@mail.gmail.com>
On Fri, Mar 28, 2008 at 05:47:25PM -0600, Grant Likely wrote:
> On Fri, Mar 28, 2008 at 5:42 PM, Dale Farnsworth <dale@farnsworth.org> wrote:
> > From: Dale Farnsworth <dale@farnsworth.org>
> >
> > Follow the convention that compatible names are prefixed by the
> > vendor's stock ticker symbol. For Marvell Technology Group Ltd.,
> > that's MRVL.
> >
> > Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> > Acked-by: Mark A. Greer <mgreer@mvista.com>
>
> Are there any boards "in the wild" using the old string? If so are
> does changing this string risk complicating upgrades to a new kernel
> version?
In particular are there any pre-flattened-tree real-OF systems in the
wild using "marvell" as the vendor prefix (there might be Apple or IBM
systems out there with Marvell PHYs for example).
Existing practice trumps "use stock ticker" for the standard vendor
prefix.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Paul Mackerras @ 2008-03-31 0:42 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <56851566f85e117c42b078dd2d6a2028@kernel.crashing.org>
Segher Boessenkool writes:
> It's still the (platform) probe code its responsibility to figure
> out what (if anything) to do with any device. And "main memory"
> is probed differently (via /chosen/memory, for example) anyway.
> Well, actually, Linux searches for all nodes with device_type "memory",
> which should work fine as well [*].
>
> So, all in all, I think we should just give these "auxiliary memory"
> devices a name of "ram" c.q. "rom", and some "reg", and that should
> be all that is needed: the main memory probe stuff won't consider
> these nodes, and the (platform) device probe code can do whatever it
> wants (create mtd devices, I guess).
Sounds reasonable.
> [*] It seems to me the longtrail workaround code in prom_init.c is
> incorrect though: it will match any node with name "memory" that
> doesn't have a device_type?
It only matches on children of the root node, and it's that way
because the /memory node in the longtrail device tree doesn't have a
device_type. Actually we could probably remove the longtrail stuff
now; I think mine has stopped working, and I only know of 2 others in
existence. :)
Paul.
^ permalink raw reply
* Re: [2.6 patch] powerpc: remove the non-functional PPC_PREP bits
From: Paul Mackerras @ 2008-03-31 0:44 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080330224012.GD28445@cs181133002.pp.htv.fi>
Adrian Bunk writes:
> Back in November 2005, the PPC_PREP bits under arch/powerpc/ were marked
> as BROKEN due to not being working.
>
> It doesn't seem to make much sense to keep this rudimentary support even
> longer.
NAK - I have some patches that get ARCH=powerpc working on at least
some PRePs, and I plan to get them in before arch/ppc goes away.
Paul.
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Segher Boessenkool @ 2008-03-31 0:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <18416.13196.812280.794832@cargo.ozlabs.ibm.com>
>> [*] It seems to me the longtrail workaround code in prom_init.c is
>> incorrect though: it will match any node with name "memory" that
>> doesn't have a device_type?
>
> It only matches on children of the root node,
Oh okay, I misread that then.
> and it's that way
> because the /memory node in the longtrail device tree doesn't have a
> device_type.
Yeah.
> Actually we could probably remove the longtrail stuff
> now; I think mine has stopped working, and I only know of 2 others in
> existence. :)
I'll prepare a patch.
Segher
^ permalink raw reply
* Fwd: [PATCH] Fix missed hardware breakpoints across multiple threads
From: Michael Ellerman @ 2008-03-31 1:07 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]
From: Michael Ellerman <michael@ellerman.id.au>
Subject: [PATCH] Fix missed hardware breakpoints across multiple threads
There is a bug in the powerpc DABR (data access breakpoint) handling,
which can result in us missing breakpoints if several threads are trying
to break on the same address.
The circumstances are that do_page_fault() calls do_dabr(), this clears
the DABR (sets it to 0) and sets up the signal which will report to
userspace that the DABR was hit. The do_signal() code will restore the DABR
value on the way out to userspace.
If we reschedule before calling do_signal(), __switch_to() will check the
cached DABR value and compare it to the new thread's value, if they match
we don't set the DABR in hardware.
So if two threads have the same DABR value, and we schedule from one to
the other after taking the interrupt for the first thread hitting the DABR,
the second thread will run without the DABR set in hardware.
The cleanest fix is to move the cache update into set_dabr(), that way we
can't forget to do it.
Reported-by: Jan Kratochvil <jan.kratochvil@redhat.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/process.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
Sorry all, I forgot to CC this to the list in my rush to get out of the
office on Friday night, sorry! :)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 59311ec..4ec6055 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -241,8 +241,12 @@ void discard_lazy_cpu_state(void)
}
#endif /* CONFIG_SMP */
+static DEFINE_PER_CPU(unsigned long, current_dabr);
+
int set_dabr(unsigned long dabr)
{
+ __get_cpu_var(current_dabr) = dabr;
+
#ifdef CONFIG_PPC_MERGE /* XXX for now */
if (ppc_md.set_dabr)
return ppc_md.set_dabr(dabr);
@@ -259,8 +263,6 @@ int set_dabr(unsigned long dabr)
DEFINE_PER_CPU(struct cpu_usage, cpu_usage_array);
#endif
-static DEFINE_PER_CPU(unsigned long, current_dabr);
-
struct task_struct *__switch_to(struct task_struct *prev,
struct task_struct *new)
{
@@ -325,10 +327,8 @@ struct task_struct *__switch_to(struct task_struct *prev,
#endif /* CONFIG_SMP */
- if (unlikely(__get_cpu_var(current_dabr) != new->thread.dabr)) {
+ if (unlikely(__get_cpu_var(current_dabr) != new->thread.dabr))
set_dabr(new->thread.dabr);
- __get_cpu_var(current_dabr) = new->thread.dabr;
- }
new_thread = &new->thread;
old_thread = ¤t->thread;
--
1.5.2.rc1.1884.g59b20
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: OF compatible MTD platform RAM driver ?
From: Segher Boessenkool @ 2008-03-31 1:24 UTC (permalink / raw)
To: Segher Boessenkool
Cc: ben, linuxppc-dev@ozlabs.org list, Paul Mackerras, David Gibson
In-Reply-To: <b393df3f814388b5cd5ae2f3b2b7fd66@kernel.crashing.org>
[Removed linux-mtd from cc:]
>>> [*] It seems to me the longtrail workaround code in prom_init.c is
>>> incorrect though: it will match any node with name "memory" that
>>> doesn't have a device_type?
>>
>> It only matches on children of the root node,
>
> Oh okay, I misread that then.
...No, I did not. prom_next_node() does a depth-first tree traversal.
>> Actually we could probably remove the longtrail stuff
>> now; I think mine has stopped working, and I only know of 2 others in
>> existence. :)
>
> I'll prepare a patch.
...Actually, that's a lot of code to rip out, and I can't test this at
all,
so I'll have to pass on this.
Segher
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Laurent Pinchart @ 2008-03-31 8:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ben, linux-mtd, Paul Mackerras, David Gibson
In-Reply-To: <56851566f85e117c42b078dd2d6a2028@kernel.crashing.org>
On Monday 31 March 2008 00:39, Segher Boessenkool wrote:
> >>> For RAMs we
> >>> need something to indicate that it's memory but intended for=20
> >>> secondary
> >>> storage, not as main memory.
> >>
> >> How it is intended to be used is not a property of the hardware, so
> >> that information doesn't belong in the device tree at all. The Linux
> >> platform code should handle this, I imagine.
> >
> > There must be some reason why it is not intended to be used as main
> > memory. Presumably it has something different about it compared to
> > "normal" RAM, and that difference could perfectly well be expressed in
> > the device tree.
>=20
> Sure, that's a different thing. It might sit on a bus that doesn't
> do cache coherency, or maybe it's just slow (or sits on a slow bus).
> All these things can be usefully expressed in the device tree (but
> typically are not, it is left to the client code to know this stuff
> implicitly).
>=20
> It's still the (platform) probe code its responsibility to figure
> out what (if anything) to do with any device. And "main memory"
> is probed differently (via /chosen/memory, for example) anyway.
> Well, actually, Linux searches for all nodes with device_type "memory",
> which should work fine as well [*].
>=20
> So, all in all, I think we should just give these "auxiliary memory"
> devices a name of "ram" c.q. "rom", and some "reg", and that should
> be all that is needed: the main memory probe stuff won't consider
> these nodes, and the (platform) device probe code can do whatever it
> wants (create mtd devices, I guess).
Ok, I get your point. I'll prepare a new documentation patch; changes to=20
physmap_of.c will go away.
If I understand you correctly, there should be no "compatible" property on =
the=20
ram and rom devices. Should the "non-volatile", "slow" and "static ram"=20
properties still be expressed in the device tree ?
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: [PATCH] powerpc: Fix deadlock with mmu_hash_lock in hash_page_sync
From: Gaash Hazan @ 2008-03-31 8:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, gaash-ppclnx, Gilad Ben-Yossef
In-Reply-To: <8C22373EA650AF40928EEA0C188D62D206C71041@xmb-ams-338.emea.cisco.com>
> -----Original Message-----
> From: Benjamin Herrenschmidt
> [mailto:benh@kernel.crashing.org]
> Sent: Monday, March 31, 2008 0:49
> To: gaash-ppclnx@gaashh.com
> Cc: linuxppc-dev@ozlabs.org; Gilad Ben-Yossef; Paul
> Mackerras
> Subject: [PATCH] powerpc: Fix deadlock with
> mmu_hash_lock in
> hash_page_sync
>
> hash_page_sync() takes and releases the low level
> mmu hash lock in order
> to sync with other processors disposing of page
> tables. Because that
> lock can be needed to service hash misses triggered
> by interrupt
> handler, taking it must be done with interrupts off.
> However,
> hash_page_sync() appear to be called with interrupts
> enabled, thus
> causing occasional deadlocks.
>
> We fix it by making sure hash_page_sync() masks
> interrupts while holding
> the lock.
>
> Signed-off-by: Benjamin Herrenschmidt
> <benh@kernel.crashing.org>
> ---
>
> Please test and report asap thought it's probably
> too late for 2.6.25,
> it can still go into stable later on.
>
Thank you for the quick acknowledgment and patch.
Patch works well.
Thanks,
Gaash
^ permalink raw reply
* Re: Xilinx LLTEMAC driver issues
From: rza1 @ 2008-03-31 9:14 UTC (permalink / raw)
To: Magnus Hjorth; +Cc: linuxppc-embedded, John Linn, git
In-Reply-To: <1206802234.5247.19.camel@magnus-desktop>
Hi Magnus,
1.
I am using nearly the same versions then you and got the same problems
too ;-).
I think there are some problems with the checksum offloading.
Try to sniff the some packages (e.g. wireshark)...
For me ICMP (ping) worked but udp and tcp not (because off a wrong
checksum in the transport layer).
A quick solution is to just deactivate checksum offloading.
2.
I remember some problems with Virtex-4 presamples too.
There where problems with the hard-temac wrapper. You had to use 1.00.a
and not b version.
But I don't have these problems with the EDK 9.2sp2/ISE9.2sp3 anymore.
all the best,
Robert
Magnus Hjorth wrote:
> Hi John,
>
> Thanks for the very fast reply! Right now I'm not at work so I don't
> have the board or EDK here to test anything.
>
> I'm using checksum offload, but I don't know if DRE is enabled or not. I
> can't recall seeing any setting to enable/disable DRE..
>
> A few things that crossed my mind:
>
> Last year I did a design with EDK 8.2, back then there was an issue with
> the ML403 boards having an old revision of the FPGA which wasn't
> compatible with some versions of the IP core. There are no such version
> issues with the xps_ll_temac?
>
> I don't think that I had phy-addr set in the DTS file. Will test that on
> Monday.
>
> Best regards,
> Magnus
>
>
> On Sat, 2008-03-29 at 07:58 -0600, John Linn wrote:
>
>> Hi Magnus,
>>
>> Sorry to hear you're having problems with it.
>>
>> I am doing testing on an ML405 which is the same board but with a bigger FPGA, but with ppc arch and I don't see this issue. I have done limited testing with powerpc arch and the LL TEMAC, but I didn't see this issue there either. Powerpc arch is definitely less mature in my experience than the ppc arch. I'll do a quick test with my powerpc arch and make sure again I'm not seeing it.
>>
>> My kernel is from the Xilinx Git tree, but there have been a number of changes we have pushed out so I don't know how long ago you pulled from the Git tree.
>>
>> My EDK project is 10.1 so it's a little newer. I am using LL TEMAC 1.01a so it's a little newer. I reviewed the change log for the LL TEMAC and don't see any big problems that were fixed in the newer versions, more new features. I'll check with some others here to see if I missed something there.
>>
>> I am using DMA also, but no DRE or checksum offload. You didn't say anything about those. I'm going to insert my mhs file that describes my system to let you compare your system configuration. It's not clear to me yet if you have a h/w or s/w problem.
>>
>> I'll also insert some of my device tree with the LL TEMAC so you can compare (ignore 16550 stuff as we are still working on that).
>>
>> Since you can't ping reliably I would probably focus on that since it's simpler than the other issues you're seeing.
>>
>> Thanks,
>> John
>>
>>
>>
>> # ##############################################################################
>> # Created by Base System Builder Wizard for Xilinx EDK 10.1.1 Build EDK_K_SP1.1
>> # Thu Feb 14 14:11:12 2008
>> # Target Board: Xilinx Virtex 4 ML405 Evaluation Platform Rev 1
>> # Family: virtex4
>> # Device: xc4vfx20
>> # Package: ff672
>> # Speed Grade: -10
>> # Processor: ppc405_0
>> # Processor clock frequency: 300.00 MHz
>> # Bus clock frequency: 100.00 MHz
>> # On Chip Memory : 8 KB
>> # Total Off Chip Memory : 128 MB
>> # - DDR_SDRAM = 128 MB
>> # ##############################################################################
>> PARAMETER VERSION = 2.1.0
>>
>>
>> PORT fpga_0_RS232_Uart_sin_pin = fpga_0_RS232_Uart_sin, DIR = I
>> PORT fpga_0_RS232_Uart_sout_pin = fpga_0_RS232_Uart_sout, DIR = O
>> PORT fpga_0_LEDs_4Bit_GPIO_IO_pin = fpga_0_LEDs_4Bit_GPIO_IO, DIR = IO, VEC = [0:3]
>> PORT fpga_0_IIC_EEPROM_Scl_pin = fpga_0_IIC_EEPROM_Scl, DIR = IO
>> PORT fpga_0_IIC_EEPROM_Sda_pin = fpga_0_IIC_EEPROM_Sda, DIR = IO
>> PORT fpga_0_SysACE_CompactFlash_SysACE_CLK_pin = fpga_0_SysACE_CompactFlash_SysACE_CLK, DIR = I
>> PORT fpga_0_SysACE_CompactFlash_SysACE_MPA_pin = fpga_0_SysACE_CompactFlash_SysACE_MPA, DIR = O, VEC = [6:1]
>> PORT fpga_0_SysACE_CompactFlash_SysACE_MPD_pin = fpga_0_SysACE_CompactFlash_SysACE_MPD, DIR = IO, VEC = [15:0]
>> PORT fpga_0_SysACE_CompactFlash_SysACE_CEN_pin = fpga_0_SysACE_CompactFlash_SysACE_CEN, DIR = O
>> PORT fpga_0_SysACE_CompactFlash_SysACE_OEN_pin = fpga_0_SysACE_CompactFlash_SysACE_OEN, DIR = O
>> PORT fpga_0_SysACE_CompactFlash_SysACE_WEN_pin = fpga_0_SysACE_CompactFlash_SysACE_WEN, DIR = O
>> PORT fpga_0_SysACE_CompactFlash_SysACE_MPIRQ_pin = fpga_0_SysACE_CompactFlash_SysACE_MPIRQ, DIR = I
>> PORT fpga_0_DDR_SDRAM_DDR_Clk_pin = fpga_0_DDR_SDRAM_DDR_Clk, DIR = O
>> PORT fpga_0_DDR_SDRAM_DDR_Clk_n_pin = fpga_0_DDR_SDRAM_DDR_Clk_n, DIR = O
>> PORT fpga_0_DDR_SDRAM_DDR_Addr_pin = fpga_0_DDR_SDRAM_DDR_Addr, DIR = O, VEC = [12:0]
>> PORT fpga_0_DDR_SDRAM_DDR_BankAddr_pin = fpga_0_DDR_SDRAM_DDR_BankAddr, DIR = O, VEC = [1:0]
>> PORT fpga_0_DDR_SDRAM_DDR_CAS_n_pin = fpga_0_DDR_SDRAM_DDR_CAS_n, DIR = O
>> PORT fpga_0_DDR_SDRAM_DDR_CE_pin = fpga_0_DDR_SDRAM_DDR_CE, DIR = O
>> PORT fpga_0_DDR_SDRAM_DDR_CS_n_pin = fpga_0_DDR_SDRAM_DDR_CS_n, DIR = O
>> PORT fpga_0_DDR_SDRAM_DDR_RAS_n_pin = fpga_0_DDR_SDRAM_DDR_RAS_n, DIR = O
>> PORT fpga_0_DDR_SDRAM_DDR_WE_n_pin = fpga_0_DDR_SDRAM_DDR_WE_n, DIR = O
>> PORT fpga_0_DDR_SDRAM_DDR_DM_pin = fpga_0_DDR_SDRAM_DDR_DM, DIR = O, VEC = [3:0]
>> PORT fpga_0_DDR_SDRAM_DDR_DQS = fpga_0_DDR_SDRAM_DDR_DQS, DIR = IO, VEC = [3:0]
>> PORT fpga_0_DDR_SDRAM_DDR_DQ = fpga_0_DDR_SDRAM_DDR_DQ, DIR = IO, VEC = [31:0]
>> PORT fpga_0_TriMode_MAC_GMII_GMII_TXD_0_pin = fpga_0_TriMode_MAC_GMII_GMII_TXD_0, DIR = O, VEC = [7:0]
>> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0_pin = fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0, DIR = O
>> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0_pin = fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0, DIR = O
>> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0_pin = fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0, DIR = O
>> PORT fpga_0_TriMode_MAC_GMII_GMII_RXD_0_pin = fpga_0_TriMode_MAC_GMII_GMII_RXD_0, DIR = I, VEC = [7:0]
>> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0_pin = fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0, DIR = I
>> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0_pin = fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0, DIR = I
>> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0_pin = fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0, DIR = I
>> PORT fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0_pin = fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0, DIR = I
>> PORT fpga_0_TriMode_MAC_GMII_MDIO_0_pin = fpga_0_TriMode_MAC_GMII_MDIO_0, DIR = IO
>> PORT fpga_0_TriMode_MAC_GMII_MDC_0_pin = fpga_0_TriMode_MAC_GMII_MDC_0, DIR = O
>> PORT fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n_pin = fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n, DIR = O
>> PORT sys_clk_pin = dcm_clk_s, DIR = I, SIGIS = CLK, CLK_FREQ = 100000000
>> PORT sys_rst_pin = sys_rst_s, DIR = I, RST_POLARITY = 0, SIGIS = RST
>>
>>
>> BEGIN ppc405_virtex4
>> PARAMETER INSTANCE = ppc405_0
>> PARAMETER HW_VER = 2.01.a
>> PARAMETER C_FASTEST_PLB_CLOCK = DPLB1
>> PARAMETER C_IDCR_BASEADDR = 0b0100000000
>> PARAMETER C_IDCR_HIGHADDR = 0b0111111111
>> BUS_INTERFACE JTAGPPC = jtagppc_0_0
>> BUS_INTERFACE IPLB0 = plb
>> BUS_INTERFACE DPLB0 = plb
>> BUS_INTERFACE IPLB1 = ppc405_0_iplb1
>> BUS_INTERFACE DPLB1 = ppc405_0_dplb1
>> BUS_INTERFACE RESETPPC = ppc_reset_bus
>> PORT CPMC405CLOCK = proc_clk_s
>> PORT EICC405EXTINPUTIRQ = EICC405EXTINPUTIRQ
>> END
>>
>> BEGIN jtagppc_cntlr
>> PARAMETER INSTANCE = jtagppc_0
>> PARAMETER HW_VER = 2.01.a
>> BUS_INTERFACE JTAGPPC0 = jtagppc_0_0
>> END
>>
>> BEGIN plb_v46
>> PARAMETER INSTANCE = plb
>> PARAMETER C_DCR_INTFCE = 0
>> PARAMETER C_NUM_CLK_PLB2OPB_REARB = 100
>> PARAMETER HW_VER = 1.02.a
>> PORT PLB_Clk = sys_clk_s
>> PORT SYS_Rst = sys_bus_reset
>> END
>>
>> BEGIN xps_bram_if_cntlr
>> PARAMETER INSTANCE = xps_bram_if_cntlr_1
>> PARAMETER HW_VER = 1.00.a
>> PARAMETER C_SPLB_NATIVE_DWIDTH = 64
>> PARAMETER C_BASEADDR = 0xffffe000
>> PARAMETER C_HIGHADDR = 0xffffffff
>> BUS_INTERFACE SPLB = plb
>> BUS_INTERFACE PORTA = xps_bram_if_cntlr_1_port
>> END
>>
>> BEGIN bram_block
>> PARAMETER INSTANCE = plb_bram_if_cntlr_1_bram
>> PARAMETER HW_VER = 1.00.a
>> BUS_INTERFACE PORTA = xps_bram_if_cntlr_1_port
>> END
>>
>> BEGIN xps_uart16550
>> PARAMETER INSTANCE = RS232_Uart
>> PARAMETER HW_VER = 2.00.a
>> PARAMETER C_IS_A_16550 = 1
>> PARAMETER C_BASEADDR = 0x83e00000
>> PARAMETER C_HIGHADDR = 0x83e0ffff
>> BUS_INTERFACE SPLB = plb
>> PORT sin = fpga_0_RS232_Uart_sin
>> PORT sout = fpga_0_RS232_Uart_sout
>> PORT IP2INTC_Irpt = RS232_Uart_IP2INTC_Irpt
>> END
>>
>> BEGIN xps_gpio
>> PARAMETER INSTANCE = LEDs_4Bit
>> PARAMETER HW_VER = 1.00.a
>> PARAMETER C_INTERRUPT_PRESENT = 1
>> PARAMETER C_GPIO_WIDTH = 4
>> PARAMETER C_IS_DUAL = 0
>> PARAMETER C_IS_BIDIR = 1
>> PARAMETER C_ALL_INPUTS = 0
>> PARAMETER C_BASEADDR = 0x81400000
>> PARAMETER C_HIGHADDR = 0x8140ffff
>> BUS_INTERFACE SPLB = plb
>> PORT GPIO_IO = fpga_0_LEDs_4Bit_GPIO_IO
>> PORT IP2INTC_Irpt = LEDs_4Bit_IP2INTC_Irpt
>> END
>>
>> BEGIN xps_iic
>> PARAMETER INSTANCE = IIC_EEPROM
>> PARAMETER HW_VER = 2.00.a
>> PARAMETER C_CLK_FREQ = 100000000
>> PARAMETER C_IIC_FREQ = 100000
>> PARAMETER C_TEN_BIT_ADR = 0
>> PARAMETER C_BASEADDR = 0x81600000
>> PARAMETER C_HIGHADDR = 0x8160ffff
>> BUS_INTERFACE SPLB = plb
>> PORT Scl = fpga_0_IIC_EEPROM_Scl
>> PORT Sda = fpga_0_IIC_EEPROM_Sda
>> PORT IIC2INTC_Irpt = IIC_EEPROM_IIC2INTC_Irpt
>> END
>>
>> BEGIN xps_sysace
>> PARAMETER INSTANCE = SysACE_CompactFlash
>> PARAMETER HW_VER = 1.00.a
>> PARAMETER C_MEM_WIDTH = 16
>> PARAMETER C_BASEADDR = 0x83600000
>> PARAMETER C_HIGHADDR = 0x8360ffff
>> BUS_INTERFACE SPLB = plb
>> PORT SysACE_CLK = fpga_0_SysACE_CompactFlash_SysACE_CLK
>> PORT SysACE_MPA = fpga_0_SysACE_CompactFlash_SysACE_MPA_split
>> PORT SysACE_MPD = fpga_0_SysACE_CompactFlash_SysACE_MPD
>> PORT SysACE_CEN = fpga_0_SysACE_CompactFlash_SysACE_CEN
>> PORT SysACE_OEN = fpga_0_SysACE_CompactFlash_SysACE_OEN
>> PORT SysACE_WEN = fpga_0_SysACE_CompactFlash_SysACE_WEN
>> PORT SysACE_MPIRQ = fpga_0_SysACE_CompactFlash_SysACE_MPIRQ
>> PORT SysACE_IRQ = SysACE_CompactFlash_SysACE_IRQ
>> END
>>
>> BEGIN mpmc
>> PARAMETER INSTANCE = DDR_SDRAM
>> PARAMETER HW_VER = 4.00.a
>> PARAMETER C_NUM_PORTS = 3
>> PARAMETER C_MEM_PARTNO = HYB25D512160BE-5
>> PARAMETER C_MEM_DATA_WIDTH = 32
>> PARAMETER C_MEM_DQS_WIDTH = 4
>> PARAMETER C_MEM_DM_WIDTH = 4
>> PARAMETER C_MEM_TYPE = DDR
>> PARAMETER C_NUM_IDELAYCTRL = 2
>> PARAMETER C_IDELAYCTRL_LOC = IDELAYCTRL_X0Y3-IDELAYCTRL_X0Y2
>> PARAMETER C_PIM0_BASETYPE = 2
>> PARAMETER C_PIM1_BASETYPE = 2
>> PARAMETER C_PIM2_BASETYPE = 3
>> PARAMETER C_MPMC_CLK0_PERIOD_PS = 10000
>> PARAMETER C_SDMA2_PI2LL_CLK_RATIO = 1
>> PARAMETER C_MPMC_BASEADDR = 0x00000000
>> PARAMETER C_MPMC_HIGHADDR = 0x07ffffff
>> PARAMETER C_SDMA_CTRL_BASEADDR = 0x84600000
>> PARAMETER C_SDMA_CTRL_HIGHADDR = 0x8460ffff
>> BUS_INTERFACE SPLB0 = ppc405_0_iplb1
>> BUS_INTERFACE SPLB1 = ppc405_0_dplb1
>> BUS_INTERFACE SDMA_LL2 = TriMode_MAC_GMII_LLINK0
>> BUS_INTERFACE SDMA_CTRL2 = plb
>> PORT DDR_Addr = fpga_0_DDR_SDRAM_DDR_Addr
>> PORT DDR_BankAddr = fpga_0_DDR_SDRAM_DDR_BankAddr
>> PORT DDR_CAS_n = fpga_0_DDR_SDRAM_DDR_CAS_n
>> PORT DDR_CE = fpga_0_DDR_SDRAM_DDR_CE
>> PORT DDR_CS_n = fpga_0_DDR_SDRAM_DDR_CS_n
>> PORT DDR_RAS_n = fpga_0_DDR_SDRAM_DDR_RAS_n
>> PORT DDR_WE_n = fpga_0_DDR_SDRAM_DDR_WE_n
>> PORT DDR_DM = fpga_0_DDR_SDRAM_DDR_DM
>> PORT DDR_DQS = fpga_0_DDR_SDRAM_DDR_DQS
>> PORT DDR_DQ = fpga_0_DDR_SDRAM_DDR_DQ
>> PORT DDR_Clk = fpga_0_DDR_SDRAM_DDR_Clk
>> PORT DDR_Clk_n = fpga_0_DDR_SDRAM_DDR_Clk_n
>> PORT MPMC_Clk0 = sys_clk_s
>> PORT MPMC_Clk90 = DDR_SDRAM_mpmc_clk_90_s
>> PORT SDMA2_Clk = sys_clk_s
>> PORT MPMC_Clk_200MHz = clk_200mhz_s
>> PORT MPMC_Rst = sys_periph_reset
>> PORT SDMA2_Rx_IntOut = DDR_SDRAM_SDMA2_Rx_IntOut
>> PORT SDMA2_Tx_IntOut = DDR_SDRAM_SDMA2_Tx_IntOut
>> END
>>
>> BEGIN xps_ll_temac
>> PARAMETER INSTANCE = TriMode_MAC_GMII
>> PARAMETER HW_VER = 1.01.a
>> PARAMETER C_SPLB_CLK_PERIOD_PS = 10000
>> PARAMETER C_PHY_TYPE = 1
>> PARAMETER C_NUM_IDELAYCTRL = 4
>> PARAMETER C_IDELAYCTRL_LOC = IDELAYCTRL_X1Y1-IDELAYCTRL_X1Y3-IDELAYCTRL_X2Y2-IDELAYCTRL_X2Y3
>> PARAMETER C_TEMAC_TYPE = 1
>> PARAMETER C_BUS2CORE_CLK_RATIO = 1
>> PARAMETER C_BASEADDR = 0x81c00000
>> PARAMETER C_HIGHADDR = 0x81c0ffff
>> BUS_INTERFACE SPLB = plb
>> BUS_INTERFACE LLINK0 = TriMode_MAC_GMII_LLINK0
>> PORT GMII_TXD_0 = fpga_0_TriMode_MAC_GMII_GMII_TXD_0
>> PORT GMII_TX_EN_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0
>> PORT GMII_TX_ER_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0
>> PORT GMII_TX_CLK_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0
>> PORT GMII_RXD_0 = fpga_0_TriMode_MAC_GMII_GMII_RXD_0
>> PORT GMII_RX_DV_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0
>> PORT GMII_RX_ER_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0
>> PORT GMII_RX_CLK_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0
>> PORT MII_TX_CLK_0 = fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0
>> PORT MDIO_0 = fpga_0_TriMode_MAC_GMII_MDIO_0
>> PORT MDC_0 = fpga_0_TriMode_MAC_GMII_MDC_0
>> PORT TemacPhy_RST_n = fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n
>> PORT GTX_CLK_0 = temac_clk_s
>> PORT REFCLK = clk_200mhz_s
>> PORT LlinkTemac0_CLK = sys_clk_s
>> PORT TemacIntc0_Irpt = TriMode_MAC_GMII_TemacIntc0_Irpt
>> END
>>
>> BEGIN util_bus_split
>> PARAMETER INSTANCE = SysACE_CompactFlash_util_bus_split_0
>> PARAMETER HW_VER = 1.00.a
>> PARAMETER C_SIZE_IN = 7
>> PARAMETER C_LEFT_POS = 0
>> PARAMETER C_SPLIT = 6
>> PORT Sig = fpga_0_SysACE_CompactFlash_SysACE_MPA_split
>> PORT Out1 = fpga_0_SysACE_CompactFlash_SysACE_MPA
>> END
>>
>> BEGIN plb_v46
>> PARAMETER INSTANCE = ppc405_0_iplb1
>> PARAMETER HW_VER = 1.02.a
>> PORT PLB_Clk = sys_clk_s
>> PORT SYS_Rst = sys_bus_reset
>> END
>>
>> BEGIN plb_v46
>> PARAMETER INSTANCE = ppc405_0_dplb1
>> PARAMETER HW_VER = 1.02.a
>> PORT PLB_Clk = sys_clk_s
>> PORT SYS_Rst = sys_bus_reset
>> END
>>
>> BEGIN clock_generator
>> PARAMETER INSTANCE = clock_generator_0
>> PARAMETER HW_VER = 2.00.a
>> PARAMETER C_EXT_RESET_HIGH = 1
>> PARAMETER C_CLKIN_FREQ = 100000000
>> PARAMETER C_CLKOUT0_FREQ = 100000000
>> PARAMETER C_CLKOUT0_BUF = TRUE
>> PARAMETER C_CLKOUT0_PHASE = 0
>> PARAMETER C_CLKOUT0_GROUP = DCM0
>> PARAMETER C_CLKOUT1_FREQ = 100000000
>> PARAMETER C_CLKOUT1_BUF = TRUE
>> PARAMETER C_CLKOUT1_PHASE = 90
>> PARAMETER C_CLKOUT1_GROUP = DCM0
>> PARAMETER C_CLKOUT2_FREQ = 300000000
>> PARAMETER C_CLKOUT2_BUF = TRUE
>> PARAMETER C_CLKOUT2_PHASE = 0
>> PARAMETER C_CLKOUT2_GROUP = DCM0
>> PARAMETER C_CLKOUT3_FREQ = 200000000
>> PARAMETER C_CLKOUT3_BUF = TRUE
>> PARAMETER C_CLKOUT3_PHASE = 0
>> PARAMETER C_CLKOUT3_GROUP = NONE
>> PARAMETER C_CLKOUT4_FREQ = 125000000
>> PARAMETER C_CLKOUT4_BUF = TRUE
>> PARAMETER C_CLKOUT4_PHASE = 0
>> PARAMETER C_CLKOUT4_GROUP = NONE
>> PORT CLKOUT0 = sys_clk_s
>> PORT CLKOUT1 = DDR_SDRAM_mpmc_clk_90_s
>> PORT CLKOUT2 = proc_clk_s
>> PORT CLKOUT3 = clk_200mhz_s
>> PORT CLKOUT4 = temac_clk_s
>> PORT CLKIN = dcm_clk_s
>> PORT LOCKED = Dcm_all_locked
>> PORT RST = net_gnd
>> END
>>
>> BEGIN proc_sys_reset
>> PARAMETER INSTANCE = proc_sys_reset_0
>> PARAMETER HW_VER = 2.00.a
>> PARAMETER C_EXT_RESET_HIGH = 0
>> BUS_INTERFACE RESETPPC0 = ppc_reset_bus
>> PORT Slowest_sync_clk = sys_clk_s
>> PORT Dcm_locked = Dcm_all_locked
>> PORT Ext_Reset_In = sys_rst_s
>> PORT Bus_Struct_Reset = sys_bus_reset
>> PORT Peripheral_Reset = sys_periph_reset
>> END
>>
>> BEGIN xps_intc
>> PARAMETER INSTANCE = xps_intc_0
>> PARAMETER HW_VER = 1.00.a
>> PARAMETER C_BASEADDR = 0x81800000
>> PARAMETER C_HIGHADDR = 0x8180ffff
>> BUS_INTERFACE SPLB = plb
>> PORT Irq = EICC405EXTINPUTIRQ
>> PORT Intr = RS232_Uart_IP2INTC_Irpt & LEDs_4Bit_IP2INTC_Irpt & IIC_EEPROM_IIC2INTC_Irpt & SysACE_CompactFlash_SysACE_IRQ & TriMode_MAC_GMII_TemacIntc0_Irpt & DDR_SDRAM_SDMA2_Rx_IntOut & DDR_SDRAM_SDMA2_Tx_IntOut
>> END
>>
>>
>>
>> #address-cells = <1>;
>> #size-cells = <1>;
>> compatible = "xlnx,virtex";
>> model = "testing";
>> DDR_SDRAM: memory@0 {
>> device_type = "memory";
>> reg = < 0 8000000 >;
>> } ;
>> chosen {
>> bootargs = "console=ttyS0,9600 ip=on nfsroot=172.16.40.76:/v2pclients/jhl26,tcp";
>> linux,stdout-path = "/plb@0/serial@83e00000";
>> } ;
>> cpus {
>> #address-cells = <1>;
>> #cpus = <1>;
>> #size-cells = <0>;
>> ppc405_0: cpu@0 {
>> clock-frequency = <11e1a300>;
>> compatible = "PowerPC,405", "ibm,ppc405";
>> d-cache-line-size = <20>;
>> d-cache-size = <4000>;
>> device_type = "cpu";
>> i-cache-line-size = <20>;
>> i-cache-size = <4000>;
>> model = "PowerPC,405";
>> reg = <0>;
>> timebase-frequency = <11e1a300>;
>> xlnx,apu-control = <de00>;
>> xlnx,apu-udi-1 = <a18983>;
>> xlnx,apu-udi-2 = <a38983>;
>> xlnx,apu-udi-3 = <a589c3>;
>> xlnx,apu-udi-4 = <a789c3>;
>> xlnx,apu-udi-5 = <a98c03>;
>> xlnx,apu-udi-6 = <ab8c03>;
>> xlnx,apu-udi-7 = <ad8c43>;
>> xlnx,apu-udi-8 = <af8c43>;
>> xlnx,deterministic-mult = <0>;
>> xlnx,disable-operand-forwarding = <1>;
>> xlnx,fastest-plb-clock = "DPLB0";
>> xlnx,generate-plb-timespecs = <1>;
>> xlnx,mmu-enable = <1>;
>> xlnx,pvr-high = <0>;
>> xlnx,pvr-low = <0>;
>> } ;
>> } ;
>> plb: plb@0 {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> compatible = "xlnx,plb-v46-1.02.a";
>> ranges ;
>> IIC_EEPROM: i2c@81600000 {
>> compatible = "xlnx,xps-iic-2.00.a";
>> interrupt-parent = <&xps_intc_0>;
>> interrupts = < 4 2 >;
>> reg = < 81600000 10000 >;
>> xlnx,clk-freq = <5f5e100>;
>> xlnx,family = "virtex4";
>> xlnx,gpo-width = <1>;
>> xlnx,iic-freq = <186a0>;
>> xlnx,scl-inertial-delay = <0>;
>> xlnx,sda-inertial-delay = <0>;
>> xlnx,ten-bit-adr = <0>;
>> } ;
>> LEDs_4Bit: gpio@81400000 {
>> compatible = "xlnx,xps-gpio-1.00.a";
>> interrupt-parent = <&xps_intc_0>;
>> interrupts = < 5 2 >;
>> reg = < 81400000 10000 >;
>> xlnx,all-inputs = <0>;
>> xlnx,all-inputs-2 = <0>;
>> xlnx,dout-default = <0>;
>> xlnx,dout-default-2 = <0>;
>> xlnx,family = "virtex4";
>> xlnx,gpio-width = <4>;
>> xlnx,interrupt-present = <1>;
>> xlnx,is-bidir = <1>;
>> xlnx,is-bidir-2 = <1>;
>> xlnx,is-dual = <0>;
>> xlnx,tri-default = <ffffffff>;
>> xlnx,tri-default-2 = <ffffffff>;
>> } ;
>> RS232_Uart: serial@83e00000 {
>> compatible = "xlnx,xps-uart16550-2.00.a";
>> // compatible = "ns16550";
>> device_type = "serial";
>> interrupt-parent = <&xps_intc_0>;
>> interrupts = < 6 2 >;
>> reg = < 83e00000 10000 >;
>> current-speed = <d#9600>;
>> clock-frequency = <d#100000000>; /* added by jhl */
>> reg-shift = <2>;
>> xlnx,family = "virtex4";
>> xlnx,has-external-rclk = <0>;
>> xlnx,has-external-xin = <0>;
>> xlnx,is-a-16550 = <1>;
>> } ;
>> SysACE_CompactFlash: sysace@83600000 {
>> compatible = "xlnx,xps-sysace-1.00.a";
>> interrupt-parent = <&xps_intc_0>;
>> interrupts = < 3 2 >;
>> reg = < 83600000 10000 >;
>> xlnx,family = "virtex4";
>> xlnx,mem-width = <10>;
>> } ;
>> TriMode_MAC_GMII: xps-ll-temac@81c00000 {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> compatible = "xlnx,compound";
>> ethernet@81c00000 {
>> compatible = "xlnx,xps-ll-temac-1.01.a";
>> device_type = "network";
>> interrupt-parent = <&xps_intc_0>;
>> interrupts = < 2 2 >;
>> llink-connected = <&PIM2>;
>> local-mac-address = [ 02 00 00 00 00 01 ];
>> reg = < 81c00000 40 >;
>> xlnx,bus2core-clk-ratio = <1>;
>> xlnx,phy-type = <1>;
>> xlnx,phyaddr = <1>;
>> xlnx,rxcsum = <0>;
>> xlnx,rxfifo = <1000>;
>> xlnx,temac-type = <1>;
>> xlnx,txcsum = <0>;
>> xlnx,txfifo = <1000>;
>> } ;
>> } ;
>> mpmc@0 {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> compatible = "xlnx,mpmc-4.00.a";
>> PIM2: sdma@84600100 {
>> compatible = "xlnx,ll-dma-1.00.a";
>> interrupt-parent = <&xps_intc_0>;
>> interrupts = < 1 2 0 2 >;
>> reg = < 84600100 80 >;
>> } ;
>> } ;
>> xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffffe000 {
>> compatible = "xlnx,xps-bram-if-cntlr-1.00.a";
>> reg = < ffffe000 2000 >;
>> xlnx,family = "virtex4";
>> } ;
>> xps_intc_0: interrupt-controller@81800000 {
>> #interrupt-cells = <2>;
>> compatible = "xlnx,xps-intc-1.00.a";
>> interrupt-controller ;
>> reg = < 81800000 10000 >;
>> xlnx,num-intr-inputs = <7>;
>> } ;
>> } ;
>> ppc405_0_dplb1: plb@1 {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> compatible = "xlnx,plb-v46-1.02.a";
>> ranges ;
>> } ;
>> } ;
>>
>>
>>
>> -----Original Message-----
>> From: Magnus Hjorth [mailto:mh@omnisys.se]
>> Sent: Saturday, March 29, 2008 6:54 AM
>> To: git
>> Cc: linuxppc-embedded@ozlabs.org
>> Subject: Xilinx LLTEMAC driver issues
>>
>> Hi,
>>
>> I'm having some networking troubles with the Xilinx LLTEMAC driver from the
>> Xilinx Linux git tree (powerpc arch) on an ML403 board. EDK9.2SP2,
>> xps_ll_temac v1.00.b
>>
>> The weird thing is, that it sort of half works. It successfully makes a DHCP
>> request and gets its IP address. I tried setting up a tftpd server, and I can
>> see UDP requests coming in but the response doesn't seem to come out. I also
>> tried running a TCP server on the board, and it can see and accept incoming
>> connections but after that no data seems to get through. I can ping out and
>> get around 40% packet loss.
>>
>> Looking at /proc/interrupts, I can see both TxDma interrupts and RxDma
>> interrupts. No eth0 interrupts but that seems to be OK judging by the driver
>> source comments. Ifconfig shows no collistions, no dropped packets, no errors,
>> so the system seems to think that everything is OK.
>>
>> Clues anyone? I'm starting to run out of ideas...
>>
>> Best regards,
>> Magnus
>>
>>
>> --
>>
>> Magnus Hjorth, M.Sc.
>> Omnisys Instruments AB
>> Gruvgatan 8
>> SE-421 30 Västra Frölunda, SWEDEN
>> Phone: +46 31 734 34 09
>> Fax: +46 31 734 34 29
>> http://www.omnisys.se
>>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in the device tree.
From: Laurent Pinchart @ 2008-03-31 9:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47ED33FC.3020107@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 3708 bytes --]
On Friday 28 March 2008 19:07, Scott Wood wrote:
> Laurent Pinchart wrote:
> > On Friday 28 March 2008 18:11, Scott Wood wrote:
> >> Laurent Pinchart wrote:
> >>> Locating the end of the muram isn't as straightforward as it
> >>> could be. As the current code already uses the beginning of the
> >>> muram to store the BDs and data buffers, should I really bother
> >>> locating the end or can I store the SMC parameter ram at the
> >>> beginning as well ?
> >> Maybe, but the end would be safer. What's the problem with finding
> >> the end?
> >
> > That requires manual parsing of all the cells in the reg property.
> > The device-tree API doesn't provide a way to get the length of a
> > property,
>
> Sure it does. Do a getprop with an insufficiently large buffer, and it
> tells you how much you really need. :-)
Ok thanks.
> > so I'll have to use a big enough pre-allocated buffer. I'm also not
> > sure if resources are guaranteed to be sorted in increasing order.
>
> Ah, good point.
>
> > This doesn't make finding the end of the muram really difficult. I
> > was just wondering if the increased code complexity was worth it,
> > especially seeing how the cpm_serial code in the boot wrapper seem
> > quite unstable.
>
> Unstable in what way?
I was refering to the virtual-reg (non-)issue I mentionned below.
> > I'm not familiar with the boot wrapper code so I'm sometimes not very
> > confident in my assumptions, but isn't the handling of the
> > virtual-reg property in cpm_console_init broken ?
>
> Not as far as I can see.
>
> > If I'm not mistaken, getprop will return the address and size of the
> > first resource and not the addresses of the first two resources.
>
> No, it'll get as much of the virtual-reg property as will fit in the
> buffer. There's no size in virtual-reg.
Ah right. Sorry about the misunderstanding.
> > What is virtual-reg used for ? To report the virtual address without
> > requiring a device tree walk ? Does it provide any information that
> > dt_xlate_reg can't find ?
>
> Yes, it tells you the virtual address when it's not an identity mapping.
> It's not currently used on CPM platforms, but might be used down the
> road with a QE device on 85xx.
Will the virtual-reg property on the muram node list the addresses of all
muram chunks or the address of the first chunk only ?
> >> Even the end of the first reg resource would be OK.
> >
> > If I use the end of the first resource, can I assume it spans 0x0000
> > - 0x8000 to set the default tx BD address in Kconfig ?
>
> No, especially seeing as it doesn't on any existing boards. :-)
I still need a default value :-) It obviously won't work for all boards.
> You could set the default to just before 0x2000 with board-specific
> exceptions, though.
We're getting a bit lost. I'll try to summarize the discussion.
- The muram node has a reg property that lists the offsets and sizes of all
muram chunks, and an optional virtual-reg property that lists the virtual
address of all chunks/the first chunk only.
- From the above information I can locate a section of muram at the end of the
first chunk (easy) or at the end of the muram (not really difficult, just a
bit more complex, especially if chunks are not sorted by their start
address).
- Kconfig needs a default address for the tx BD. This depends on the
allocation strategy (end of first chunk vs. end of last chunk). Is there some
consistent default across QE devices ?
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Using FEC on a MPC5200 with default PHY configuration
From: Wolfgang Grandegger @ 2008-03-31 9:20 UTC (permalink / raw)
To: ppc-dev
Hello,
is it possible to use the FEC on a MPC5200 with the default hardware PHY
configuration. I mean running the link with a default speed without
handling or even touching the PHY like U-Boot does. I removed the PHY
entries from the DTS file and disabled CONFIG_FEC_MPC52xx_MDIO but it
did not work.
Any help is appreciated, TIA.
Wolfgang.
^ permalink raw reply
* Re: Using FEC on a MPC5200 with default PHY configuration
From: Wolfgang Grandegger @ 2008-03-31 9:44 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: ppc-dev
In-Reply-To: <47F0ACC7.9080709@grandegger.com>
Wolfgang Grandegger wrote:
> Hello,
>
> is it possible to use the FEC on a MPC5200 with the default hardware PHY
> configuration. I mean running the link with a default speed without
> handling or even touching the PHY like U-Boot does. I removed the PHY
> entries from the DTS file and disabled CONFIG_FEC_MPC52xx_MDIO but it
> did not work.
To be more precise, I want to support a 3-Port managed switch with PHY
from Micrel using the direct switch link.
TIA.
Wolfgang.
^ permalink raw reply
* RE: Xilinx LLTEMAC driver issues
From: Magnus Hjorth @ 2008-03-31 11:10 UTC (permalink / raw)
To: 'rza1'; +Cc: linuxppc-embedded, 'John Linn', 'git'
In-Reply-To: <47F0AB74.4070802@so-logic.net>
Deactivating checksum offloading helped a lot! I still have some packet =
loss and not the best performance (TFTP transfer about 100 kbyte/s) but =
at least it works.=20
Thanks!
//Magnus
> -----Original Message-----
> From: rza1 [mailto:rza1@so-logic.net]
> Sent: den 31 mars 2008 11:14
> To: Magnus Hjorth
> Cc: John Linn; git; linuxppc-embedded@ozlabs.org
> Subject: Re: Xilinx LLTEMAC driver issues
>=20
> Hi Magnus,
>=20
> 1.
> I am using nearly the same versions then you and got the same problems
> too ;-).
> I think there are some problems with the checksum offloading.
> Try to sniff the some packages (e.g. wireshark)...
> For me ICMP (ping) worked but udp and tcp not (because off a wrong
> checksum in the transport layer).
> A quick solution is to just deactivate checksum offloading.
>=20
> 2.
> I remember some problems with Virtex-4 presamples too.
> There where problems with the hard-temac wrapper. You had to use =
1.00.a
> and not b version.
> But I don't have these problems with the EDK 9.2sp2/ISE9.2sp3 anymore.
>=20
> all the best,
> Robert
>=20
> Magnus Hjorth wrote:
> > Hi John,
> >
> > Thanks for the very fast reply! Right now I'm not at work so I don't
> > have the board or EDK here to test anything.
> >
> > I'm using checksum offload, but I don't know if DRE is enabled or =
not. I
> > can't recall seeing any setting to enable/disable DRE..
> >
> > A few things that crossed my mind:
> >
> > Last year I did a design with EDK 8.2, back then there was an issue =
with
> > the ML403 boards having an old revision of the FPGA which wasn't
> > compatible with some versions of the IP core. There are no such =
version
> > issues with the xps_ll_temac?
> >
> > I don't think that I had phy-addr set in the DTS file. Will test =
that on
> > Monday.
> >
> > Best regards,
> > Magnus
> >
> >
> > On Sat, 2008-03-29 at 07:58 -0600, John Linn wrote:
> >
> >> Hi Magnus,
> >>
> >> Sorry to hear you're having problems with it.
> >>
> >> I am doing testing on an ML405 which is the same board but with a =
bigger
> FPGA, but with ppc arch and I don't see this issue. I have done =
limited testing
> with powerpc arch and the LL TEMAC, but I didn't see this issue there =
either.
> Powerpc arch is definitely less mature in my experience than the ppc =
arch. I'll
> do a quick test with my powerpc arch and make sure again I'm not =
seeing it.
> >>
> >> My kernel is from the Xilinx Git tree, but there have been a number =
of
> changes we have pushed out so I don't know how long ago you pulled =
from the Git
> tree.
> >>
> >> My EDK project is 10.1 so it's a little newer. I am using LL TEMAC =
1.01a so
> it's a little newer. I reviewed the change log for the LL TEMAC and =
don't see
> any big problems that were fixed in the newer versions, more new =
features. I'll
> check with some others here to see if I missed something there.
> >>
> >> I am using DMA also, but no DRE or checksum offload. You didn't =
say anything
> about those. I'm going to insert my mhs file that describes my system =
to let you
> compare your system configuration. It's not clear to me yet if you =
have a h/w or
> s/w problem.
> >>
> >> I'll also insert some of my device tree with the LL TEMAC so you =
can compare
> (ignore 16550 stuff as we are still working on that).
> >>
> >> Since you can't ping reliably I would probably focus on that since =
it's
> simpler than the other issues you're seeing.
> >>
> >> Thanks,
> >> John
> >>
> >>
> >>
> >> #
> =
#########################################################################=
#####
> >> # Created by Base System Builder Wizard for Xilinx EDK 10.1.1 Build
> EDK_K_SP1.1
> >> # Thu Feb 14 14:11:12 2008
> >> # Target Board: Xilinx Virtex 4 ML405 Evaluation Platform Rev 1
> >> # Family: virtex4
> >> # Device: xc4vfx20
> >> # Package: ff672
> >> # Speed Grade: -10
> >> # Processor: ppc405_0
> >> # Processor clock frequency: 300.00 MHz
> >> # Bus clock frequency: 100.00 MHz
> >> # On Chip Memory : 8 KB
> >> # Total Off Chip Memory : 128 MB
> >> # - DDR_SDRAM =3D 128 MB
> >> #
> =
#########################################################################=
#####
> >> PARAMETER VERSION =3D 2.1.0
> >>
> >>
> >> PORT fpga_0_RS232_Uart_sin_pin =3D fpga_0_RS232_Uart_sin, DIR =3D =
I
> >> PORT fpga_0_RS232_Uart_sout_pin =3D fpga_0_RS232_Uart_sout, DIR =
=3D O
> >> PORT fpga_0_LEDs_4Bit_GPIO_IO_pin =3D fpga_0_LEDs_4Bit_GPIO_IO, =
DIR =3D IO, VEC
> =3D [0:3]
> >> PORT fpga_0_IIC_EEPROM_Scl_pin =3D fpga_0_IIC_EEPROM_Scl, DIR =3D =
IO
> >> PORT fpga_0_IIC_EEPROM_Sda_pin =3D fpga_0_IIC_EEPROM_Sda, DIR =3D =
IO
> >> PORT fpga_0_SysACE_CompactFlash_SysACE_CLK_pin =3D
> fpga_0_SysACE_CompactFlash_SysACE_CLK, DIR =3D I
> >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPA_pin =3D
> fpga_0_SysACE_CompactFlash_SysACE_MPA, DIR =3D O, VEC =3D [6:1]
> >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPD_pin =3D
> fpga_0_SysACE_CompactFlash_SysACE_MPD, DIR =3D IO, VEC =3D [15:0]
> >> PORT fpga_0_SysACE_CompactFlash_SysACE_CEN_pin =3D
> fpga_0_SysACE_CompactFlash_SysACE_CEN, DIR =3D O
> >> PORT fpga_0_SysACE_CompactFlash_SysACE_OEN_pin =3D
> fpga_0_SysACE_CompactFlash_SysACE_OEN, DIR =3D O
> >> PORT fpga_0_SysACE_CompactFlash_SysACE_WEN_pin =3D
> fpga_0_SysACE_CompactFlash_SysACE_WEN, DIR =3D O
> >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPIRQ_pin =3D
> fpga_0_SysACE_CompactFlash_SysACE_MPIRQ, DIR =3D I
> >> PORT fpga_0_DDR_SDRAM_DDR_Clk_pin =3D fpga_0_DDR_SDRAM_DDR_Clk, =
DIR =3D O
> >> PORT fpga_0_DDR_SDRAM_DDR_Clk_n_pin =3D =
fpga_0_DDR_SDRAM_DDR_Clk_n, DIR =3D O
> >> PORT fpga_0_DDR_SDRAM_DDR_Addr_pin =3D fpga_0_DDR_SDRAM_DDR_Addr, =
DIR =3D O, VEC
> =3D [12:0]
> >> PORT fpga_0_DDR_SDRAM_DDR_BankAddr_pin =3D =
fpga_0_DDR_SDRAM_DDR_BankAddr, DIR
> =3D O, VEC =3D [1:0]
> >> PORT fpga_0_DDR_SDRAM_DDR_CAS_n_pin =3D =
fpga_0_DDR_SDRAM_DDR_CAS_n, DIR =3D O
> >> PORT fpga_0_DDR_SDRAM_DDR_CE_pin =3D fpga_0_DDR_SDRAM_DDR_CE, DIR =
=3D O
> >> PORT fpga_0_DDR_SDRAM_DDR_CS_n_pin =3D fpga_0_DDR_SDRAM_DDR_CS_n, =
DIR =3D O
> >> PORT fpga_0_DDR_SDRAM_DDR_RAS_n_pin =3D =
fpga_0_DDR_SDRAM_DDR_RAS_n, DIR =3D O
> >> PORT fpga_0_DDR_SDRAM_DDR_WE_n_pin =3D fpga_0_DDR_SDRAM_DDR_WE_n, =
DIR =3D O
> >> PORT fpga_0_DDR_SDRAM_DDR_DM_pin =3D fpga_0_DDR_SDRAM_DDR_DM, DIR =
=3D O, VEC =3D
> [3:0]
> >> PORT fpga_0_DDR_SDRAM_DDR_DQS =3D fpga_0_DDR_SDRAM_DDR_DQS, DIR =
=3D IO, VEC =3D
> [3:0]
> >> PORT fpga_0_DDR_SDRAM_DDR_DQ =3D fpga_0_DDR_SDRAM_DDR_DQ, DIR =3D =
IO, VEC =3D
> [31:0]
> >> PORT fpga_0_TriMode_MAC_GMII_GMII_TXD_0_pin =3D
> fpga_0_TriMode_MAC_GMII_GMII_TXD_0, DIR =3D O, VEC =3D [7:0]
> >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0_pin =3D
> fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0, DIR =3D O
> >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0_pin =3D
> fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0, DIR =3D O
> >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0_pin =3D
> fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0, DIR =3D O
> >> PORT fpga_0_TriMode_MAC_GMII_GMII_RXD_0_pin =3D
> fpga_0_TriMode_MAC_GMII_GMII_RXD_0, DIR =3D I, VEC =3D [7:0]
> >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0_pin =3D
> fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0, DIR =3D I
> >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0_pin =3D
> fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0, DIR =3D I
> >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0_pin =3D
> fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0, DIR =3D I
> >> PORT fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0_pin =3D
> fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0, DIR =3D I
> >> PORT fpga_0_TriMode_MAC_GMII_MDIO_0_pin =3D =
fpga_0_TriMode_MAC_GMII_MDIO_0,
> DIR =3D IO
> >> PORT fpga_0_TriMode_MAC_GMII_MDC_0_pin =3D =
fpga_0_TriMode_MAC_GMII_MDC_0, DIR
> =3D O
> >> PORT fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n_pin =3D
> fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n, DIR =3D O
> >> PORT sys_clk_pin =3D dcm_clk_s, DIR =3D I, SIGIS =3D CLK, CLK_FREQ =
=3D 100000000
> >> PORT sys_rst_pin =3D sys_rst_s, DIR =3D I, RST_POLARITY =3D 0, =
SIGIS =3D RST
> >>
> >>
> >> BEGIN ppc405_virtex4
> >> PARAMETER INSTANCE =3D ppc405_0
> >> PARAMETER HW_VER =3D 2.01.a
> >> PARAMETER C_FASTEST_PLB_CLOCK =3D DPLB1
> >> PARAMETER C_IDCR_BASEADDR =3D 0b0100000000
> >> PARAMETER C_IDCR_HIGHADDR =3D 0b0111111111
> >> BUS_INTERFACE JTAGPPC =3D jtagppc_0_0
> >> BUS_INTERFACE IPLB0 =3D plb
> >> BUS_INTERFACE DPLB0 =3D plb
> >> BUS_INTERFACE IPLB1 =3D ppc405_0_iplb1
> >> BUS_INTERFACE DPLB1 =3D ppc405_0_dplb1
> >> BUS_INTERFACE RESETPPC =3D ppc_reset_bus
> >> PORT CPMC405CLOCK =3D proc_clk_s
> >> PORT EICC405EXTINPUTIRQ =3D EICC405EXTINPUTIRQ
> >> END
> >>
> >> BEGIN jtagppc_cntlr
> >> PARAMETER INSTANCE =3D jtagppc_0
> >> PARAMETER HW_VER =3D 2.01.a
> >> BUS_INTERFACE JTAGPPC0 =3D jtagppc_0_0
> >> END
> >>
> >> BEGIN plb_v46
> >> PARAMETER INSTANCE =3D plb
> >> PARAMETER C_DCR_INTFCE =3D 0
> >> PARAMETER C_NUM_CLK_PLB2OPB_REARB =3D 100
> >> PARAMETER HW_VER =3D 1.02.a
> >> PORT PLB_Clk =3D sys_clk_s
> >> PORT SYS_Rst =3D sys_bus_reset
> >> END
> >>
> >> BEGIN xps_bram_if_cntlr
> >> PARAMETER INSTANCE =3D xps_bram_if_cntlr_1
> >> PARAMETER HW_VER =3D 1.00.a
> >> PARAMETER C_SPLB_NATIVE_DWIDTH =3D 64
> >> PARAMETER C_BASEADDR =3D 0xffffe000
> >> PARAMETER C_HIGHADDR =3D 0xffffffff
> >> BUS_INTERFACE SPLB =3D plb
> >> BUS_INTERFACE PORTA =3D xps_bram_if_cntlr_1_port
> >> END
> >>
> >> BEGIN bram_block
> >> PARAMETER INSTANCE =3D plb_bram_if_cntlr_1_bram
> >> PARAMETER HW_VER =3D 1.00.a
> >> BUS_INTERFACE PORTA =3D xps_bram_if_cntlr_1_port
> >> END
> >>
> >> BEGIN xps_uart16550
> >> PARAMETER INSTANCE =3D RS232_Uart
> >> PARAMETER HW_VER =3D 2.00.a
> >> PARAMETER C_IS_A_16550 =3D 1
> >> PARAMETER C_BASEADDR =3D 0x83e00000
> >> PARAMETER C_HIGHADDR =3D 0x83e0ffff
> >> BUS_INTERFACE SPLB =3D plb
> >> PORT sin =3D fpga_0_RS232_Uart_sin
> >> PORT sout =3D fpga_0_RS232_Uart_sout
> >> PORT IP2INTC_Irpt =3D RS232_Uart_IP2INTC_Irpt
> >> END
> >>
> >> BEGIN xps_gpio
> >> PARAMETER INSTANCE =3D LEDs_4Bit
> >> PARAMETER HW_VER =3D 1.00.a
> >> PARAMETER C_INTERRUPT_PRESENT =3D 1
> >> PARAMETER C_GPIO_WIDTH =3D 4
> >> PARAMETER C_IS_DUAL =3D 0
> >> PARAMETER C_IS_BIDIR =3D 1
> >> PARAMETER C_ALL_INPUTS =3D 0
> >> PARAMETER C_BASEADDR =3D 0x81400000
> >> PARAMETER C_HIGHADDR =3D 0x8140ffff
> >> BUS_INTERFACE SPLB =3D plb
> >> PORT GPIO_IO =3D fpga_0_LEDs_4Bit_GPIO_IO
> >> PORT IP2INTC_Irpt =3D LEDs_4Bit_IP2INTC_Irpt
> >> END
> >>
> >> BEGIN xps_iic
> >> PARAMETER INSTANCE =3D IIC_EEPROM
> >> PARAMETER HW_VER =3D 2.00.a
> >> PARAMETER C_CLK_FREQ =3D 100000000
> >> PARAMETER C_IIC_FREQ =3D 100000
> >> PARAMETER C_TEN_BIT_ADR =3D 0
> >> PARAMETER C_BASEADDR =3D 0x81600000
> >> PARAMETER C_HIGHADDR =3D 0x8160ffff
> >> BUS_INTERFACE SPLB =3D plb
> >> PORT Scl =3D fpga_0_IIC_EEPROM_Scl
> >> PORT Sda =3D fpga_0_IIC_EEPROM_Sda
> >> PORT IIC2INTC_Irpt =3D IIC_EEPROM_IIC2INTC_Irpt
> >> END
> >>
> >> BEGIN xps_sysace
> >> PARAMETER INSTANCE =3D SysACE_CompactFlash
> >> PARAMETER HW_VER =3D 1.00.a
> >> PARAMETER C_MEM_WIDTH =3D 16
> >> PARAMETER C_BASEADDR =3D 0x83600000
> >> PARAMETER C_HIGHADDR =3D 0x8360ffff
> >> BUS_INTERFACE SPLB =3D plb
> >> PORT SysACE_CLK =3D fpga_0_SysACE_CompactFlash_SysACE_CLK
> >> PORT SysACE_MPA =3D fpga_0_SysACE_CompactFlash_SysACE_MPA_split
> >> PORT SysACE_MPD =3D fpga_0_SysACE_CompactFlash_SysACE_MPD
> >> PORT SysACE_CEN =3D fpga_0_SysACE_CompactFlash_SysACE_CEN
> >> PORT SysACE_OEN =3D fpga_0_SysACE_CompactFlash_SysACE_OEN
> >> PORT SysACE_WEN =3D fpga_0_SysACE_CompactFlash_SysACE_WEN
> >> PORT SysACE_MPIRQ =3D fpga_0_SysACE_CompactFlash_SysACE_MPIRQ
> >> PORT SysACE_IRQ =3D SysACE_CompactFlash_SysACE_IRQ
> >> END
> >>
> >> BEGIN mpmc
> >> PARAMETER INSTANCE =3D DDR_SDRAM
> >> PARAMETER HW_VER =3D 4.00.a
> >> PARAMETER C_NUM_PORTS =3D 3
> >> PARAMETER C_MEM_PARTNO =3D HYB25D512160BE-5
> >> PARAMETER C_MEM_DATA_WIDTH =3D 32
> >> PARAMETER C_MEM_DQS_WIDTH =3D 4
> >> PARAMETER C_MEM_DM_WIDTH =3D 4
> >> PARAMETER C_MEM_TYPE =3D DDR
> >> PARAMETER C_NUM_IDELAYCTRL =3D 2
> >> PARAMETER C_IDELAYCTRL_LOC =3D IDELAYCTRL_X0Y3-IDELAYCTRL_X0Y2
> >> PARAMETER C_PIM0_BASETYPE =3D 2
> >> PARAMETER C_PIM1_BASETYPE =3D 2
> >> PARAMETER C_PIM2_BASETYPE =3D 3
> >> PARAMETER C_MPMC_CLK0_PERIOD_PS =3D 10000
> >> PARAMETER C_SDMA2_PI2LL_CLK_RATIO =3D 1
> >> PARAMETER C_MPMC_BASEADDR =3D 0x00000000
> >> PARAMETER C_MPMC_HIGHADDR =3D 0x07ffffff
> >> PARAMETER C_SDMA_CTRL_BASEADDR =3D 0x84600000
> >> PARAMETER C_SDMA_CTRL_HIGHADDR =3D 0x8460ffff
> >> BUS_INTERFACE SPLB0 =3D ppc405_0_iplb1
> >> BUS_INTERFACE SPLB1 =3D ppc405_0_dplb1
> >> BUS_INTERFACE SDMA_LL2 =3D TriMode_MAC_GMII_LLINK0
> >> BUS_INTERFACE SDMA_CTRL2 =3D plb
> >> PORT DDR_Addr =3D fpga_0_DDR_SDRAM_DDR_Addr
> >> PORT DDR_BankAddr =3D fpga_0_DDR_SDRAM_DDR_BankAddr
> >> PORT DDR_CAS_n =3D fpga_0_DDR_SDRAM_DDR_CAS_n
> >> PORT DDR_CE =3D fpga_0_DDR_SDRAM_DDR_CE
> >> PORT DDR_CS_n =3D fpga_0_DDR_SDRAM_DDR_CS_n
> >> PORT DDR_RAS_n =3D fpga_0_DDR_SDRAM_DDR_RAS_n
> >> PORT DDR_WE_n =3D fpga_0_DDR_SDRAM_DDR_WE_n
> >> PORT DDR_DM =3D fpga_0_DDR_SDRAM_DDR_DM
> >> PORT DDR_DQS =3D fpga_0_DDR_SDRAM_DDR_DQS
> >> PORT DDR_DQ =3D fpga_0_DDR_SDRAM_DDR_DQ
> >> PORT DDR_Clk =3D fpga_0_DDR_SDRAM_DDR_Clk
> >> PORT DDR_Clk_n =3D fpga_0_DDR_SDRAM_DDR_Clk_n
> >> PORT MPMC_Clk0 =3D sys_clk_s
> >> PORT MPMC_Clk90 =3D DDR_SDRAM_mpmc_clk_90_s
> >> PORT SDMA2_Clk =3D sys_clk_s
> >> PORT MPMC_Clk_200MHz =3D clk_200mhz_s
> >> PORT MPMC_Rst =3D sys_periph_reset
> >> PORT SDMA2_Rx_IntOut =3D DDR_SDRAM_SDMA2_Rx_IntOut
> >> PORT SDMA2_Tx_IntOut =3D DDR_SDRAM_SDMA2_Tx_IntOut
> >> END
> >>
> >> BEGIN xps_ll_temac
> >> PARAMETER INSTANCE =3D TriMode_MAC_GMII
> >> PARAMETER HW_VER =3D 1.01.a
> >> PARAMETER C_SPLB_CLK_PERIOD_PS =3D 10000
> >> PARAMETER C_PHY_TYPE =3D 1
> >> PARAMETER C_NUM_IDELAYCTRL =3D 4
> >> PARAMETER C_IDELAYCTRL_LOC =3D IDELAYCTRL_X1Y1-IDELAYCTRL_X1Y3-
> IDELAYCTRL_X2Y2-IDELAYCTRL_X2Y3
> >> PARAMETER C_TEMAC_TYPE =3D 1
> >> PARAMETER C_BUS2CORE_CLK_RATIO =3D 1
> >> PARAMETER C_BASEADDR =3D 0x81c00000
> >> PARAMETER C_HIGHADDR =3D 0x81c0ffff
> >> BUS_INTERFACE SPLB =3D plb
> >> BUS_INTERFACE LLINK0 =3D TriMode_MAC_GMII_LLINK0
> >> PORT GMII_TXD_0 =3D fpga_0_TriMode_MAC_GMII_GMII_TXD_0
> >> PORT GMII_TX_EN_0 =3D fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0
> >> PORT GMII_TX_ER_0 =3D fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0
> >> PORT GMII_TX_CLK_0 =3D fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0
> >> PORT GMII_RXD_0 =3D fpga_0_TriMode_MAC_GMII_GMII_RXD_0
> >> PORT GMII_RX_DV_0 =3D fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0
> >> PORT GMII_RX_ER_0 =3D fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0
> >> PORT GMII_RX_CLK_0 =3D fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0
> >> PORT MII_TX_CLK_0 =3D fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0
> >> PORT MDIO_0 =3D fpga_0_TriMode_MAC_GMII_MDIO_0
> >> PORT MDC_0 =3D fpga_0_TriMode_MAC_GMII_MDC_0
> >> PORT TemacPhy_RST_n =3D fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n
> >> PORT GTX_CLK_0 =3D temac_clk_s
> >> PORT REFCLK =3D clk_200mhz_s
> >> PORT LlinkTemac0_CLK =3D sys_clk_s
> >> PORT TemacIntc0_Irpt =3D TriMode_MAC_GMII_TemacIntc0_Irpt
> >> END
> >>
> >> BEGIN util_bus_split
> >> PARAMETER INSTANCE =3D SysACE_CompactFlash_util_bus_split_0
> >> PARAMETER HW_VER =3D 1.00.a
> >> PARAMETER C_SIZE_IN =3D 7
> >> PARAMETER C_LEFT_POS =3D 0
> >> PARAMETER C_SPLIT =3D 6
> >> PORT Sig =3D fpga_0_SysACE_CompactFlash_SysACE_MPA_split
> >> PORT Out1 =3D fpga_0_SysACE_CompactFlash_SysACE_MPA
> >> END
> >>
> >> BEGIN plb_v46
> >> PARAMETER INSTANCE =3D ppc405_0_iplb1
> >> PARAMETER HW_VER =3D 1.02.a
> >> PORT PLB_Clk =3D sys_clk_s
> >> PORT SYS_Rst =3D sys_bus_reset
> >> END
> >>
> >> BEGIN plb_v46
> >> PARAMETER INSTANCE =3D ppc405_0_dplb1
> >> PARAMETER HW_VER =3D 1.02.a
> >> PORT PLB_Clk =3D sys_clk_s
> >> PORT SYS_Rst =3D sys_bus_reset
> >> END
> >>
> >> BEGIN clock_generator
> >> PARAMETER INSTANCE =3D clock_generator_0
> >> PARAMETER HW_VER =3D 2.00.a
> >> PARAMETER C_EXT_RESET_HIGH =3D 1
> >> PARAMETER C_CLKIN_FREQ =3D 100000000
> >> PARAMETER C_CLKOUT0_FREQ =3D 100000000
> >> PARAMETER C_CLKOUT0_BUF =3D TRUE
> >> PARAMETER C_CLKOUT0_PHASE =3D 0
> >> PARAMETER C_CLKOUT0_GROUP =3D DCM0
> >> PARAMETER C_CLKOUT1_FREQ =3D 100000000
> >> PARAMETER C_CLKOUT1_BUF =3D TRUE
> >> PARAMETER C_CLKOUT1_PHASE =3D 90
> >> PARAMETER C_CLKOUT1_GROUP =3D DCM0
> >> PARAMETER C_CLKOUT2_FREQ =3D 300000000
> >> PARAMETER C_CLKOUT2_BUF =3D TRUE
> >> PARAMETER C_CLKOUT2_PHASE =3D 0
> >> PARAMETER C_CLKOUT2_GROUP =3D DCM0
> >> PARAMETER C_CLKOUT3_FREQ =3D 200000000
> >> PARAMETER C_CLKOUT3_BUF =3D TRUE
> >> PARAMETER C_CLKOUT3_PHASE =3D 0
> >> PARAMETER C_CLKOUT3_GROUP =3D NONE
> >> PARAMETER C_CLKOUT4_FREQ =3D 125000000
> >> PARAMETER C_CLKOUT4_BUF =3D TRUE
> >> PARAMETER C_CLKOUT4_PHASE =3D 0
> >> PARAMETER C_CLKOUT4_GROUP =3D NONE
> >> PORT CLKOUT0 =3D sys_clk_s
> >> PORT CLKOUT1 =3D DDR_SDRAM_mpmc_clk_90_s
> >> PORT CLKOUT2 =3D proc_clk_s
> >> PORT CLKOUT3 =3D clk_200mhz_s
> >> PORT CLKOUT4 =3D temac_clk_s
> >> PORT CLKIN =3D dcm_clk_s
> >> PORT LOCKED =3D Dcm_all_locked
> >> PORT RST =3D net_gnd
> >> END
> >>
> >> BEGIN proc_sys_reset
> >> PARAMETER INSTANCE =3D proc_sys_reset_0
> >> PARAMETER HW_VER =3D 2.00.a
> >> PARAMETER C_EXT_RESET_HIGH =3D 0
> >> BUS_INTERFACE RESETPPC0 =3D ppc_reset_bus
> >> PORT Slowest_sync_clk =3D sys_clk_s
> >> PORT Dcm_locked =3D Dcm_all_locked
> >> PORT Ext_Reset_In =3D sys_rst_s
> >> PORT Bus_Struct_Reset =3D sys_bus_reset
> >> PORT Peripheral_Reset =3D sys_periph_reset
> >> END
> >>
> >> BEGIN xps_intc
> >> PARAMETER INSTANCE =3D xps_intc_0
> >> PARAMETER HW_VER =3D 1.00.a
> >> PARAMETER C_BASEADDR =3D 0x81800000
> >> PARAMETER C_HIGHADDR =3D 0x8180ffff
> >> BUS_INTERFACE SPLB =3D plb
> >> PORT Irq =3D EICC405EXTINPUTIRQ
> >> PORT Intr =3D RS232_Uart_IP2INTC_Irpt & LEDs_4Bit_IP2INTC_Irpt &
> IIC_EEPROM_IIC2INTC_Irpt & SysACE_CompactFlash_SysACE_IRQ &
> TriMode_MAC_GMII_TemacIntc0_Irpt & DDR_SDRAM_SDMA2_Rx_IntOut &
> DDR_SDRAM_SDMA2_Tx_IntOut
> >> END
> >>
> >>
> >>
> >> #address-cells =3D <1>;
> >> #size-cells =3D <1>;
> >> compatible =3D "xlnx,virtex";
> >> model =3D "testing";
> >> DDR_SDRAM: memory@0 {
> >> device_type =3D "memory";
> >> reg =3D < 0 8000000 >;
> >> } ;
> >> chosen {
> >> bootargs =3D "console=3DttyS0,9600 ip=3Don
> nfsroot=3D172.16.40.76:/v2pclients/jhl26,tcp";
> >> linux,stdout-path =3D "/plb@0/serial@83e00000";
> >> } ;
> >> cpus {
> >> #address-cells =3D <1>;
> >> #cpus =3D <1>;
> >> #size-cells =3D <0>;
> >> ppc405_0: cpu@0 {
> >> clock-frequency =3D <11e1a300>;
> >> compatible =3D "PowerPC,405", "ibm,ppc405";
> >> d-cache-line-size =3D <20>;
> >> d-cache-size =3D <4000>;
> >> device_type =3D "cpu";
> >> i-cache-line-size =3D <20>;
> >> i-cache-size =3D <4000>;
> >> model =3D "PowerPC,405";
> >> reg =3D <0>;
> >> timebase-frequency =3D <11e1a300>;
> >> xlnx,apu-control =3D <de00>;
> >> xlnx,apu-udi-1 =3D <a18983>;
> >> xlnx,apu-udi-2 =3D <a38983>;
> >> xlnx,apu-udi-3 =3D <a589c3>;
> >> xlnx,apu-udi-4 =3D <a789c3>;
> >> xlnx,apu-udi-5 =3D <a98c03>;
> >> xlnx,apu-udi-6 =3D <ab8c03>;
> >> xlnx,apu-udi-7 =3D <ad8c43>;
> >> xlnx,apu-udi-8 =3D <af8c43>;
> >> xlnx,deterministic-mult =3D <0>;
> >> xlnx,disable-operand-forwarding =3D <1>;
> >> xlnx,fastest-plb-clock =3D "DPLB0";
> >> xlnx,generate-plb-timespecs =3D <1>;
> >> xlnx,mmu-enable =3D <1>;
> >> xlnx,pvr-high =3D <0>;
> >> xlnx,pvr-low =3D <0>;
> >> } ;
> >> } ;
> >> plb: plb@0 {
> >> #address-cells =3D <1>;
> >> #size-cells =3D <1>;
> >> compatible =3D "xlnx,plb-v46-1.02.a";
> >> ranges ;
> >> IIC_EEPROM: i2c@81600000 {
> >> compatible =3D "xlnx,xps-iic-2.00.a";
> >> interrupt-parent =3D <&xps_intc_0>;
> >> interrupts =3D < 4 2 >;
> >> reg =3D < 81600000 10000 >;
> >> xlnx,clk-freq =3D <5f5e100>;
> >> xlnx,family =3D "virtex4";
> >> xlnx,gpo-width =3D <1>;
> >> xlnx,iic-freq =3D <186a0>;
> >> xlnx,scl-inertial-delay =3D <0>;
> >> xlnx,sda-inertial-delay =3D <0>;
> >> xlnx,ten-bit-adr =3D <0>;
> >> } ;
> >> LEDs_4Bit: gpio@81400000 {
> >> compatible =3D "xlnx,xps-gpio-1.00.a";
> >> interrupt-parent =3D <&xps_intc_0>;
> >> interrupts =3D < 5 2 >;
> >> reg =3D < 81400000 10000 >;
> >> xlnx,all-inputs =3D <0>;
> >> xlnx,all-inputs-2 =3D <0>;
> >> xlnx,dout-default =3D <0>;
> >> xlnx,dout-default-2 =3D <0>;
> >> xlnx,family =3D "virtex4";
> >> xlnx,gpio-width =3D <4>;
> >> xlnx,interrupt-present =3D <1>;
> >> xlnx,is-bidir =3D <1>;
> >> xlnx,is-bidir-2 =3D <1>;
> >> xlnx,is-dual =3D <0>;
> >> xlnx,tri-default =3D <ffffffff>;
> >> xlnx,tri-default-2 =3D <ffffffff>;
> >> } ;
> >> RS232_Uart: serial@83e00000 {
> >> compatible =3D "xlnx,xps-uart16550-2.00.a";
> >> // compatible =3D "ns16550";
> >> device_type =3D "serial";
> >> interrupt-parent =3D <&xps_intc_0>;
> >> interrupts =3D < 6 2 >;
> >> reg =3D < 83e00000 10000 >;
> >> current-speed =3D <d#9600>;
> >> clock-frequency =3D <d#100000000>; /* added
> by jhl */
> >> reg-shift =3D <2>;
> >> xlnx,family =3D "virtex4";
> >> xlnx,has-external-rclk =3D <0>;
> >> xlnx,has-external-xin =3D <0>;
> >> xlnx,is-a-16550 =3D <1>;
> >> } ;
> >> SysACE_CompactFlash: sysace@83600000 {
> >> compatible =3D "xlnx,xps-sysace-1.00.a";
> >> interrupt-parent =3D <&xps_intc_0>;
> >> interrupts =3D < 3 2 >;
> >> reg =3D < 83600000 10000 >;
> >> xlnx,family =3D "virtex4";
> >> xlnx,mem-width =3D <10>;
> >> } ;
> >> TriMode_MAC_GMII: xps-ll-temac@81c00000 {
> >> #address-cells =3D <1>;
> >> #size-cells =3D <1>;
> >> compatible =3D "xlnx,compound";
> >> ethernet@81c00000 {
> >> compatible =3D "xlnx,xps-ll-temac-
> 1.01.a";
> >> device_type =3D "network";
> >> interrupt-parent =3D
> <&xps_intc_0>;
> >> interrupts =3D < 2 2 >;
> >> llink-connected =3D <&PIM2>;
> >> local-mac-address =3D [ 02 00 00
> 00 00 01 ];
> >> reg =3D < 81c00000 40 >;
> >> xlnx,bus2core-clk-ratio =3D <1>;
> >> xlnx,phy-type =3D <1>;
> >> xlnx,phyaddr =3D <1>;
> >> xlnx,rxcsum =3D <0>;
> >> xlnx,rxfifo =3D <1000>;
> >> xlnx,temac-type =3D <1>;
> >> xlnx,txcsum =3D <0>;
> >> xlnx,txfifo =3D <1000>;
> >> } ;
> >> } ;
> >> mpmc@0 {
> >> #address-cells =3D <1>;
> >> #size-cells =3D <1>;
> >> compatible =3D "xlnx,mpmc-4.00.a";
> >> PIM2: sdma@84600100 {
> >> compatible =3D "xlnx,ll-dma-
> 1.00.a";
> >> interrupt-parent =3D
> <&xps_intc_0>;
> >> interrupts =3D < 1 2 0 2 >;
> >> reg =3D < 84600100 80 >;
> >> } ;
> >> } ;
> >> xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffffe000 {
> >> compatible =3D "xlnx,xps-bram-if-cntlr-
> 1.00.a";
> >> reg =3D < ffffe000 2000 >;
> >> xlnx,family =3D "virtex4";
> >> } ;
> >> xps_intc_0: interrupt-controller@81800000 {
> >> #interrupt-cells =3D <2>;
> >> compatible =3D "xlnx,xps-intc-1.00.a";
> >> interrupt-controller ;
> >> reg =3D < 81800000 10000 >;
> >> xlnx,num-intr-inputs =3D <7>;
> >> } ;
> >> } ;
> >> ppc405_0_dplb1: plb@1 {
> >> #address-cells =3D <1>;
> >> #size-cells =3D <1>;
> >> compatible =3D "xlnx,plb-v46-1.02.a";
> >> ranges ;
> >> } ;
> >> } ;
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Magnus Hjorth [mailto:mh@omnisys.se]
> >> Sent: Saturday, March 29, 2008 6:54 AM
> >> To: git
> >> Cc: linuxppc-embedded@ozlabs.org
> >> Subject: Xilinx LLTEMAC driver issues
> >>
> >> Hi,
> >>
> >> I'm having some networking troubles with the Xilinx LLTEMAC driver =
from the
> >> Xilinx Linux git tree (powerpc arch) on an ML403 board. EDK9.2SP2,
> >> xps_ll_temac v1.00.b
> >>
> >> The weird thing is, that it sort of half works. It successfully =
makes a DHCP
> >> request and gets its IP address. I tried setting up a tftpd server, =
and I can
> >> see UDP requests coming in but the response doesn't seem to come =
out. I also
> >> tried running a TCP server on the board, and it can see and accept =
incoming
> >> connections but after that no data seems to get through. I can ping =
out and
> >> get around 40% packet loss.
> >>
> >> Looking at /proc/interrupts, I can see both TxDma interrupts and =
RxDma
> >> interrupts. No eth0 interrupts but that seems to be OK judging by =
the driver
> >> source comments. Ifconfig shows no collistions, no dropped packets, =
no
> errors,
> >> so the system seems to think that everything is OK.
> >>
> >> Clues anyone? I'm starting to run out of ideas...
> >>
> >> Best regards,
> >> Magnus
> >>
> >>
> >> --
> >>
> >> Magnus Hjorth, M.Sc.
> >> Omnisys Instruments AB
> >> Gruvgatan 8
> >> SE-421 30 V=C3=A4stra Fr=C3=B6lunda, SWEDEN
> >> Phone: +46 31 734 34 09
> >> Fax: +46 31 734 34 29
> >> http://www.omnisys.se
> >>
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/xcis: ansify
From: David Howells @ 2008-03-31 12:07 UTC (permalink / raw)
To: Al Viro; +Cc: linuxppc-dev, torvalds, linux-kernel
In-Reply-To: <E1JfRSo-00030J-LV@ZenIV.linux.org.uk>
Al Viro <viro@ftp.linux.org.uk> wrote:
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Segher Boessenkool @ 2008-03-31 12:21 UTC (permalink / raw)
To: Laurent Pinchart
Cc: ben, linux-mtd, Paul Mackerras, linuxppc-dev, David Gibson
In-Reply-To: <200803311021.28919.laurentp@cse-semaphore.com>
>> So, all in all, I think we should just give these "auxiliary memory"
>> devices a name of "ram" c.q. "rom", and some "reg", and that should
>> be all that is needed: the main memory probe stuff won't consider
>> these nodes, and the (platform) device probe code can do whatever it
>> wants (create mtd devices, I guess).
>
> Ok, I get your point. I'll prepare a new documentation patch; changes
> to
> physmap_of.c will go away.
Thanks.
> If I understand you correctly, there should be no "compatible"
> property on the
> ram and rom devices.
They aren't normally needed here, I think.
> Should the "non-volatile", "slow" and "static ram"
> properties still be expressed in the device tree ?
If those are useful. I'll need to see a proposed binding to form
an opinion on this, it's too vague now, sorry.
Segher
^ permalink raw reply
* [PATCH] mpc83xx SPI glitch
From: Mike Hench @ 2008-03-31 13:04 UTC (permalink / raw)
To: linuxppc-dev
dont write SPMODE reg unless mode changed.
it causes SPI to go hi-z momentarily
which can cause a spike on the CLK line
this is a problem in MMC where /CS is held asserted
across multiple transactions.
Signed-off-by: Mike Hench <mhench@elutions.com>
---
--- linux-2.6.25-rc5.orig/drivers/spi/spi_mpc83xx.c 2008-03-10
00:22:27.000000000 -0500
+++ linux-2.6.25-rc5/drivers/spi/spi_mpc83xx.c 2008-03-31
07:37:37.000000000 -0500
@@ -147,6 +147,7 @@
=20
if (value =3D=3D BITBANG_CS_ACTIVE) {
u32 regval =3D
mpc83xx_spi_read_reg(&mpc83xx_spi->base->mode);
+ u32 regval0 =3D regval;
u32 len =3D spi->bits_per_word;
u8 pm;
=20
@@ -188,9 +189,16 @@
regval |=3D SPMODE_PM(pm);
}
=20
- /* Turn off SPI unit prior changing mode */
- mpc83xx_spi_write_reg(&mpc83xx_spi->base->mode, 0);
- mpc83xx_spi_write_reg(&mpc83xx_spi->base->mode, regval);
+ // dont write reg unless mode changed.
+ // it causes SPI to go hi-z momentarily
+ // which can cause a spike on the CLK line
+ // this is a problem in MMC where /CS is held asserted
+ // across multiple transactions.
+ if(regval !=3D regval0) {
+ /* Turn off SPI unit prior changing mode */
+ mpc83xx_spi_write_reg(&mpc83xx_spi->base->mode,
0);
+ mpc83xx_spi_write_reg(&mpc83xx_spi->base->mode,
regval);
+ }
if (mpc83xx_spi->activate_cs)
mpc83xx_spi->activate_cs(spi->chip_select, pol);
}
^ permalink raw reply
* [PATCH] Add idle power save for ppc 4xx
From: Jerone Young @ 2008-03-31 13:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel
# HG changeset patch
# User Jerone Young <jyoung5@us.ibm.com>
# Date 1206969060 18000
# Node ID 10aea37177130bbe5de7bee6ec06d9010bc5da1f
# Parent 1506aa38ddabb0bf73fff3ac3f3db5f9ef6458cc
Add idle power save for ppc 4xx
This patch sets the wait state MSR when power_save is called in cpu_idle loop for ppc4xx. This is mainly to help out virtualization solutions such as KVM. This way the virtualization soultions are able to tell if the guest kernel is idle.
I have tested this on hardware & KVM virtual guest.
Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsy
obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsync.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
+obj-$(CONFIG_4xx) += idle_4xx.o
obj-$(CONFIG_TAU) += tau_6xx.o
obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o \
swsusp_$(CONFIG_WORD_SIZE).o
diff --git a/arch/powerpc/kernel/idle_4xx.c b/arch/powerpc/kernel/idle_4xx.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/kernel/idle_4xx.c
@@ -0,0 +1,24 @@
+/*
+ * This file contains the power_save function for 4xx CPUs
+ *
+ * added by Jerone Young <jyoung5@us.ibm.com>
+ *
+ * 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/processor.h>
+#include <asm/machdep.h>
+
+void ppc4xx_idle()
+{
+ unsigned long msr_save;
+
+ /* set wait state MSR */
+ local_irq_enable();
+ msr_save = mfmsr();
+ mtmsr(msr_save|MSR_WE);
+ local_irq_disable();
+}
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -132,6 +132,10 @@ void __init machine_init(unsigned long d
if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
cpu_has_feature(CPU_FTR_CAN_NAP))
ppc_md.power_save = ppc6xx_idle;
+#endif
+
+#ifdef CONFIG_4xx
+ ppc_md.power_save = ppc4xx_idle;
#endif
if (ppc_md.progress)
diff --git a/include/asm-powerpc/machdep.h b/include/asm-powerpc/machdep.h
--- a/include/asm-powerpc/machdep.h
+++ b/include/asm-powerpc/machdep.h
@@ -266,6 +266,7 @@ extern void power4_idle(void);
extern void power4_idle(void);
extern void power4_cpu_offline_powersave(void);
extern void ppc6xx_idle(void);
+extern void ppc4xx_idle(void);
/*
* ppc_md contains a copy of the machine description structure for the
^ 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