* Re: [PATCH v4 0/3] OF-platform PATA driver
From: Anton Vorontsov @ 2008-01-16 5:47 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mundt, Jeff Garzik, linux-ide
In-Reply-To: <20080115164022.GA24590@lixom.net>
On Tue, Jan 15, 2008 at 10:40:22AM -0600, Olof Johansson wrote:
> Hi,
>
> I've applied 1/3 and 2/3 together with my electra_ide move to pasemi.git
> for-2.6.25, and will ask Paul to pull that. Kumar said he'd take 3/3.
>
> I also added the const to the match table as spotted by Stephen.
Great news, thank you!
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-16 5:34 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, netdev
In-Reply-To: <20080115200019.GA2598@gate.ebshome.net>
On Tuesday 15 January 2008, Eugene Surovegin wrote:
> > OK. But how do we detect GigE support? Seems like GigE enabled devices
> > have CONFIG_IBM_EMAC4 defined. If nobody objects I'll fix up another
> > version tomorrow.
>
> Look couple of lines down where I set MTU changing hook. If you cannot
> change MTU you cannot get big frames.
Ahhh, I must have been blind. Thanks for pointing out.
I'll send new patches for ibm_emac and ibm_newemac in a short while.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
From: David Gibson @ 2008-01-16 5:52 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801160604.56766.sr@denx.de>
On Wed, Jan 16, 2008 at 06:04:56AM +0100, Stefan Roese wrote:
> On Wednesday 16 January 2008, David Gibson wrote:
> > On Tue, Jan 15, 2008 at 08:09:25AM +0100, Stefan Roese wrote:
[snip]
> > > + RGMII0: emac-rgmii@ef600b00 {
> > > + device_type = "rgmii-interface";
> >
> > And especially not here.
>
> Ok.
>
> Your comments are valid for some of the other 4xx dts files too. Should I
> create a patch that removes these device-types there too?
Yes please :).
[snip]
> > Oh, for crying out loud. They put dcrs on the bridge as well as MMIO
> > registers. *facepalm*
>
> Yep. PCIe on 4xx has DCR, SDR *and* MMIO registers.
Ungh.
--
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
* MPIC ISU
From: vb @ 2008-01-16 6:03 UTC (permalink / raw)
To: linuxppc-embedded
Greetings,
I am trying to write a BSP for an 8245 based device. One thing which
really gets me puzzled is the 'ISU' facility in
arch/powerpc/sysdev/mpic.c, there is also a notion of ISU-less
platforms, etc. I looked through the chip's programmer's reference,
even read the original AMD/Cypress OpenPIC specification - not a clue.
What is it, at the very least - what does ISU stand for?
I would really appreciate any hints,
thank you in advance,
/vb
^ permalink raw reply
* Re: [PATCH 1/3] 8xx: Analogue & Micro Adder875 board support.
From: Vitaly Bordug @ 2008-01-16 6:16 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <1200439502.3618.26.camel@neuromancer.mindspace>
On Tue, 15 Jan 2008 23:25:02 +0000
Bryan O'Donoghue wrote:
> Greetings Scott.
>
> I've tried both of the procedures you've outlined on the Adder875 with
> the patches supplied against the paulus git tree to no avail.
>
> Pass #1 :
>
> Doing it safe with cuImage.8xx
>
[...]
> => bootm 0x400000
> ## Booting image at 00400000 ...
> Image Name: Linux-2.6.24-rc6-g4f43143f-dirty
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1032266 Bytes = 1008.1 kB
> Load Address: 00400000
> Entry Point: 00400554
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
>
> I haven't as yet tried to single step through the bootup process -
> but, just to say that assuming the above procedure isn't _too_ far
> wrong - the stuff posted to the list agains the tree you've
> recommended doesn't seem to work..
>
yes the sequence seems correct, so I'd check cmdline params, contents of chosen node in dts, etc to make sure stuff is being written to the proper UART with proper settings.
> If you can point out a flaw in my usage of it - that'd help alot. I
> have some code I'd love to be able to use with the Adder875+powerpc
> layer - which is why I'm interested in this patchset...
>
>
> Pass #2 :
>
> Replace step 9 with.
>
> 9. make uImage
> 10 dtc -o ../adder875-uboot.dtb -O dtb
> arch/powerpc/boot/dts/adder875-uboot.dts
>
>
> cp arch/powerpc/boot/uImage /tftpboot
> cp ../adder875-uboot.dtb /tftpboot
>
> Finally in u-boot
> => tftpboot 0x400000 uImage
> Using FEC ETHERNET device
> TFTP from server 192.168.0.101; our IP address is 192.168.0.202
> Filename 'uImage'.
> Load address: 0x400000
> Loading:
> #################################################################
>
> #################################################################
>
> #################################################################
> ###
> done
> Bytes transferred = 1009496 (f6758 hex)
> => tftpboot 0x500000 adder875-uboot.dtb
> Using FEC ETHERNET device
> TFTP from server 192.168.0.101; our IP address is 192.168.0.202
> Filename 'adder875-uboot.dtb'.
> Load address: 0x500000
> Loading: #
> done
> Bytes transferred = 3147 (c4b hex)
> => bootm 0x400000 - 0x500000
> ## Booting image at 00400000 ...
> Image Name: Linux-2.6.24-rc6-g4f43143f-dirty
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1009432 Bytes = 985.8 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using the fdt at 0x500000
>
>
> Aside from the u-boot modification of including
>
> #define CONFIG_OF_LIBFDT 1
>
> The rest is a pristine version of Yuli Barchoen's original U-Boot
> Adder stuff.
>
> The uImage + dtb seems to get a good bit further in that it seems to
> get stuck somewhere inside of some trampoline code in time.c
>
>
> (gdb) bt
> #0 0xc000ee30 in __div64_32 ()
> #1 0xc01d71f4 in time_init () at arch/powerpc/kernel/time.c:940
>
>
> I might have a go at some proper debugging tomorrow after work.
>
> If you have any suggestions as to what's going wrong or what I've not
> done right I'd appreciate the help.
>
following the u-boot way (which is more correct imo) you'll need to add some code that fixes up frequencies and stuff inside dtb, or you may try to hardcode those values inside dts(if you know exactly what should be there). Just adding CONFIG_*LIBFDT is not going to work.
--
Sincerely, Vitaly
^ permalink raw reply
* [libfdt] RFC: Node iterators
From: David Gibson @ 2008-01-16 6:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
Here's my counter-attempt at node iterators for libfdt. It's based on
an internal function very similar to Scott's fdt_next_node(), but the
exported interfaces are altered to be (IMO) safer and simpler.
So far, it only handles iterating across immediate children of a node,
not traversing an entire subtree. I'm still working on extending the
internals to cover that case. No property iteration as yet, either.
Index: dtc/libfdt/fdt_ro.c
===================================================================
--- dtc.orig/libfdt/fdt_ro.c 2008-01-16 15:06:49.000000000 +1100
+++ dtc/libfdt/fdt_ro.c 2008-01-16 16:27:55.000000000 +1100
@@ -65,7 +65,7 @@
static int nodename_eq(const void *fdt, int offset,
const char *s, int len)
{
- const char *p = fdt_offset_ptr(fdt, offset, len+1);
+ const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
if (! p)
/* short match */
@@ -104,50 +104,16 @@ int fdt_num_mem_rsv(const void *fdt)
return i;
}
-int fdt_subnode_offset_namelen(const void *fdt, int parentoffset,
+int fdt_subnode_offset_namelen(const void *fdt, int offset,
const char *name, int namelen)
{
- int level = 0;
- uint32_t tag;
- int offset, nextoffset;
-
CHECK_HEADER(fdt);
- tag = fdt_next_tag(fdt, parentoffset, &nextoffset);
- if (tag != FDT_BEGIN_NODE)
- return -FDT_ERR_BADOFFSET;
-
- do {
- offset = nextoffset;
- tag = fdt_next_tag(fdt, offset, &nextoffset);
-
- switch (tag) {
- case FDT_END:
- return -FDT_ERR_TRUNCATED;
-
- case FDT_BEGIN_NODE:
- level++;
- if (level != 1)
- continue;
- if (nodename_eq(fdt, offset+FDT_TAGSIZE, name, namelen))
- /* Found it! */
- return offset;
- break;
-
- case FDT_END_NODE:
- level--;
- break;
-
- case FDT_PROP:
- case FDT_NOP:
- break;
-
- default:
- return -FDT_ERR_BADSTRUCTURE;
- }
- } while (level >= 0);
+ for_each_subnode(fdt, offset)
+ if (nodename_eq(fdt, offset, name, namelen))
+ return offset;
- return -FDT_ERR_NOTFOUND;
+ return offset;
}
int fdt_subnode_offset(const void *fdt, int parentoffset,
Index: dtc/libfdt/fdt.c
===================================================================
--- dtc.orig/libfdt/fdt.c 2008-01-16 16:26:48.000000000 +1100
+++ dtc/libfdt/fdt.c 2008-01-16 17:03:09.000000000 +1100
@@ -129,6 +129,58 @@ uint32_t fdt_next_tag(const void *fdt, i
return tag;
}
+static int _fdt_next_node(const void *fdt, int offset, int *depth)
+{
+ uint32_t tag;
+ int nextoffset;
+
+ tag = fdt_next_tag(fdt, offset, &nextoffset);
+ if (tag != FDT_BEGIN_NODE)
+ return -FDT_ERR_BADOFFSET;
+
+ do {
+ offset = nextoffset;
+ tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+ switch (tag) {
+ case FDT_PROP:
+ case FDT_NOP:
+ break;
+
+ case FDT_BEGIN_NODE:
+ (*depth)++;
+ if (*depth == 1)
+ return offset;
+ break;
+
+ case FDT_END_NODE:
+ (*depth)--;
+ break;
+
+ case FDT_END:
+ return -FDT_ERR_TRUNCATED;
+
+ default:
+ return -FDT_ERR_BADSTRUCTURE;
+ }
+ } while (*depth >= 0);
+
+ return -FDT_ERR_NOTFOUND;
+}
+
+int _fdt_first_subnode(const void *fdt, int offset)
+{
+ int depth = 0;
+
+ return _fdt_next_node(fdt, offset, &depth);
+}
+
+int _fdt_next_subnode(const void *fdt, int offset)
+{
+ int depth = 1;
+ return _fdt_next_node(fdt, offset, &depth);
+}
+
const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
{
int len = strlen(s) + 1;
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2008-01-16 16:27:09.000000000 +1100
+++ dtc/libfdt/libfdt.h 2008-01-16 17:06:31.000000000 +1100
@@ -131,6 +131,18 @@ static inline void *fdt_offset_ptr_w(voi
uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
/**********************************************************************/
+/* Traversal functions */
+/**********************************************************************/
+
+int _fdt_first_subnode(const void *fdt, int offset);
+int _fdt_next_subnode(const void *fdt, int offset);
+
+#define for_each_subnode(fdt, offset) \
+ for ((offset) = _fdt_first_subnode((fdt), (offset)); \
+ (offset) >= 0; \
+ (offset) = _fdt_next_subnode((fdt), (offset)))
+
+/**********************************************************************/
/* General functions */
/**********************************************************************/
--
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
* [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-16 7:10 UTC (permalink / raw)
To: linuxppc-dev, netdev
Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
xmit. This routine doesn't check if the frame length exceeds the max.
MAL buffer size.
This patch now changes the driver to call emac_start_xmit_sg() on all
GigE platforms and not only the TAH equipped ones (440GX). This enables
an MTU of 9000 instead 4080.
Tested on Kilauea (405EX) with GigE link -> jumbo frames enabled.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_emac/ibm_emac_core.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index 73664f2..8d1901e 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -1089,7 +1089,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
return emac_xmit_finish(dev, len);
}
-#if defined(CONFIG_IBM_EMAC_TAH)
static inline int emac_xmit_split(struct ocp_enet_private *dev, int slot,
u32 pd, int len, int last, u16 base_ctrl)
{
@@ -1203,9 +1202,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
DBG2("%d: stopped TX queue" NL, dev->def->index);
return 1;
}
-#else
-# define emac_start_xmit_sg emac_start_xmit
-#endif /* !defined(CONFIG_IBM_EMAC_TAH) */
/* BHs disabled */
static void emac_parse_tx_error(struct ocp_enet_private *dev, u16 ctrl)
@@ -2163,11 +2159,8 @@ static int __init emac_probe(struct ocp_device *ocpdev)
/* Fill in the driver function table */
ndev->open = &emac_open;
- if (dev->tah_dev) {
- ndev->hard_start_xmit = &emac_start_xmit_sg;
+ if (dev->tah_dev)
ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
- } else
- ndev->hard_start_xmit = &emac_start_xmit;
ndev->tx_timeout = &emac_full_tx_reset;
ndev->watchdog_timeo = 5 * HZ;
ndev->stop = &emac_close;
@@ -2175,8 +2168,11 @@ static int __init emac_probe(struct ocp_device *ocpdev)
ndev->set_multicast_list = &emac_set_multicast_list;
ndev->do_ioctl = &emac_ioctl;
if (emac_phy_supports_gige(emacdata->phy_mode)) {
+ ndev->hard_start_xmit = &emac_start_xmit_sg;
ndev->change_mtu = &emac_change_mtu;
dev->commac.ops = &emac_commac_sg_ops;
+ } else {
+ ndev->hard_start_xmit = &emac_start_xmit;
}
SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
--
1.5.4.rc3
^ permalink raw reply related
* [PATCH] net: NEWEMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-16 7:11 UTC (permalink / raw)
To: linuxppc-dev, netdev
Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
xmit. This routine doesn't check if the frame length exceeds the max.
MAL buffer size.
This patch now changes the driver to call emac_start_xmit_sg() on all
GigE platforms and not only the TAH equipped ones (440GX). This enables
an MTU of 9000 instead 4080.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/core.c | 14 ++++----------
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index cb06280..b24bd2d 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -1297,7 +1297,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
return emac_xmit_finish(dev, len);
}
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
static inline int emac_xmit_split(struct emac_instance *dev, int slot,
u32 pd, int len, int last, u16 base_ctrl)
{
@@ -1410,9 +1409,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
DBG2(dev, "stopped TX queue" NL);
return 1;
}
-#else
-# define emac_start_xmit_sg emac_start_xmit
-#endif /* !defined(CONFIG_IBM_NEW_EMAC_TAH) */
/* Tx lock BHs */
static void emac_parse_tx_error(struct emac_instance *dev, u16 ctrl)
@@ -2683,13 +2679,8 @@ static int __devinit emac_probe(struct of_device *ofdev,
/* Fill in the driver function table */
ndev->open = &emac_open;
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
- if (dev->tah_dev) {
- ndev->hard_start_xmit = &emac_start_xmit_sg;
+ if (dev->tah_dev)
ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
- } else
-#endif
- ndev->hard_start_xmit = &emac_start_xmit;
ndev->tx_timeout = &emac_tx_timeout;
ndev->watchdog_timeo = 5 * HZ;
ndev->stop = &emac_close;
@@ -2697,8 +2688,11 @@ static int __devinit emac_probe(struct of_device *ofdev,
ndev->set_multicast_list = &emac_set_multicast_list;
ndev->do_ioctl = &emac_ioctl;
if (emac_phy_supports_gige(dev->phy_mode)) {
+ ndev->hard_start_xmit = &emac_start_xmit_sg;
ndev->change_mtu = &emac_change_mtu;
dev->commac.ops = &emac_commac_sg_ops;
+ } else {
+ ndev->hard_start_xmit = &emac_start_xmit;
}
SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
--
1.5.4.rc3
^ permalink raw reply related
* Re: [DTC PATCH] libfdt: Add ft_get_next_node(), ft_get_next_prop(), and ft_getprop_offset().
From: David Gibson @ 2008-01-16 7:15 UTC (permalink / raw)
To: Scott Wood, jdl, linuxppc-dev
In-Reply-To: <20080116034939.GB5016@localhost.localdomain>
On Wed, Jan 16, 2008 at 02:49:39PM +1100, David Gibson wrote:
> On Tue, Jan 15, 2008 at 10:52:30AM -0600, Scott Wood wrote:
> > On Tue, Jan 15, 2008 at 11:16:57AM +1100, David Gibson wrote:
> > > On Mon, Jan 14, 2008 at 10:30:04AM -0600, Scott Wood wrote:
[snip]
> > > > + if (depth != 0)
> > > > + return -FDT_ERR_BADSTRUCTURE;
> > >
> > > I think this should be FDT_ERR_TRUNCATED.
> >
> > I'd expect TRUNCATED when we hit totalsize without an FDT_END, not when
> > we hit FDT_END in an inappropriate context.
>
> Well, TRUNCATED is valid for either situation, and fdt_next_tag() also
> returns FDT_END if it reaches totalsize.
Thought I should elaborate on this a bit - I'm not sure that the
current handling of FDT_ERR_TRUNCATED is entirely correct. The
description says only when the FDT_END tag is missing, but the way
fdt_next_tag() works means we will also (for some functions, at least)
give this error when FDT_END appears without a suitable number of
FDT_END_NODE tags preceding it.
The rationale behind FDT_ERR_TRUNCATED - why it exists as a separate
code from FDT_ERR_BADSTRUCTURE - is that the read-only functions
should work more-or-less sanely on incomplete trees created by the
sequential-write functions (fdt_sw.c). FDT_ERR_TRUNCATED is supposed
to indicate that the function couldn't complete properly because the
tree is malformed, but that suitable calls to the fdt_sw functions
could complete the tree so that it's no longer malformed.
I'm not sure that either the comment describing TRUNCATED, or the code
entirely matches that rationale...
--
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: [PATCH] net: NEWEMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Benjamin Herrenschmidt @ 2008-01-16 7:15 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200467475-1663-1-git-send-email-sr@denx.de>
On Wed, 2008-01-16 at 08:11 +0100, Stefan Roese wrote:
> Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
> xmit. This routine doesn't check if the frame length exceeds the max.
> MAL buffer size.
>
> This patch now changes the driver to call emac_start_xmit_sg() on all
> GigE platforms and not only the TAH equipped ones (440GX). This enables
> an MTU of 9000 instead 4080.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Jeff, please pick up for .25.
Ben.
> drivers/net/ibm_newemac/core.c | 14 ++++----------
> 1 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
> index cb06280..b24bd2d 100644
> --- a/drivers/net/ibm_newemac/core.c
> +++ b/drivers/net/ibm_newemac/core.c
> @@ -1297,7 +1297,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> return emac_xmit_finish(dev, len);
> }
>
> -#ifdef CONFIG_IBM_NEW_EMAC_TAH
> static inline int emac_xmit_split(struct emac_instance *dev, int slot,
> u32 pd, int len, int last, u16 base_ctrl)
> {
> @@ -1410,9 +1409,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
> DBG2(dev, "stopped TX queue" NL);
> return 1;
> }
> -#else
> -# define emac_start_xmit_sg emac_start_xmit
> -#endif /* !defined(CONFIG_IBM_NEW_EMAC_TAH) */
>
> /* Tx lock BHs */
> static void emac_parse_tx_error(struct emac_instance *dev, u16 ctrl)
> @@ -2683,13 +2679,8 @@ static int __devinit emac_probe(struct of_device *ofdev,
>
> /* Fill in the driver function table */
> ndev->open = &emac_open;
> -#ifdef CONFIG_IBM_NEW_EMAC_TAH
> - if (dev->tah_dev) {
> - ndev->hard_start_xmit = &emac_start_xmit_sg;
> + if (dev->tah_dev)
> ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
> - } else
> -#endif
> - ndev->hard_start_xmit = &emac_start_xmit;
> ndev->tx_timeout = &emac_tx_timeout;
> ndev->watchdog_timeo = 5 * HZ;
> ndev->stop = &emac_close;
> @@ -2697,8 +2688,11 @@ static int __devinit emac_probe(struct of_device *ofdev,
> ndev->set_multicast_list = &emac_set_multicast_list;
> ndev->do_ioctl = &emac_ioctl;
> if (emac_phy_supports_gige(dev->phy_mode)) {
> + ndev->hard_start_xmit = &emac_start_xmit_sg;
> ndev->change_mtu = &emac_change_mtu;
> dev->commac.ops = &emac_commac_sg_ops;
> + } else {
> + ndev->hard_start_xmit = &emac_start_xmit;
> }
> SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
>
^ permalink raw reply
* [PATCH 2/2] [POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
From: Stefan Roese @ 2008-01-16 7:24 UTC (permalink / raw)
To: linuxppc-dev
The patch adds the Haleakala dts. The Haleakala is a stripped down
version of the Kilauea (405EX) with only one EMAC and only one PCIe
interface.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/haleakala.dts | 274 +++++++++++++++++++++++++++++++++++
1 files changed, 274 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/haleakala.dts
diff --git a/arch/powerpc/boot/dts/haleakala.dts b/arch/powerpc/boot/dts/haleakala.dts
new file mode 100644
index 0000000..5dd3d15
--- /dev/null
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -0,0 +1,274 @@
+/*
+ * Device Tree Source for AMCC Haleakala (405EXr)
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "amcc,haleakala";
+ compatible = "amcc,kilauea";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,405EXr";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <4000>; /* 16 kB */
+ d-cache-size = <4000>; /* 16 kB */
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller {
+ compatible = "ibm,uic-405exr", "ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-405exr","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-405exr","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1c 4 1d 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ plb {
+ compatible = "ibm,plb-405exr", "ibm,plb4";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: memory-controller {
+ compatible = "ibm,sdram-405exr";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-405exr", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <2>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
+ /*RXEOB*/ 1 &UIC0 b 4
+ /*SERR*/ 2 &UIC1 0 4
+ /*TXDE*/ 3 &UIC1 1 4
+ /*RXDE*/ 4 &UIC1 2 4>;
+ interrupt-map-mask = <ffffffff>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-405exr", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <80000000 80000000 10000000
+ ef600000 ef600000 a00000
+ f0000000 f0000000 10000000>;
+ dcr-reg = <0a0 5>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-405exr", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ /* ranges property is supplied by U-Boot */
+ interrupts = <5 1>;
+ interrupt-parent = <&UIC1>;
+
+ nor_flash@0,0 {
+ compatible = "amd,s29gl512n", "cfi-flash";
+ bank-width = <2>;
+ reg = <0 000000 4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "kernel";
+ reg = <0 200000>;
+ };
+ partition@200000 {
+ label = "root";
+ reg = <200000 200000>;
+ };
+ partition@400000 {
+ label = "user";
+ reg = <400000 3b60000>;
+ };
+ partition@3f60000 {
+ label = "env";
+ reg = <3f60000 40000>;
+ };
+ partition@3fa0000 {
+ label = "u-boot";
+ reg = <3fa0000 60000>;
+ };
+ };
+ };
+
+ UART0: serial@ef600200 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600200 8>;
+ virtual-reg = <ef600200>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1a 4>;
+ };
+
+ UART1: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ IIC0: i2c@ef600400 {
+ compatible = "ibm,iic-405exr", "ibm,iic";
+ reg = <ef600400 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600500 {
+ compatible = "ibm,iic-405exr", "ibm,iic";
+ reg = <ef600500 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <7 4>;
+ };
+
+
+ RGMII0: emac-rgmii@ef600b00 {
+ compatible = "ibm,rgmii-405exr", "ibm,rgmii";
+ reg = <ef600b00 104>;
+ has-mdio;
+ };
+
+ EMAC0: ethernet@ef600900 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-405exr", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC0 18 4
+ /*Wake*/ 1 &UIC1 1d 4>;
+ reg = <ef600900 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+ };
+
+ PCIE0: pciex@0a0000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-405exr", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = <a0000000 20000000 /* Config space access */
+ ef000000 00001000>; /* Registers */
+ dcr-reg = <040 020>;
+ sdr-base = <400>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 90000000 0 08000000
+ 01000000 0 00000000 e0000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 80000000>;
+
+ /* This drives busses 0x00 to 0x3f */
+ bus-range = <00 3f>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC2 0 4 /* swizzled int A */
+ 0000 0 0 2 &UIC2 1 4 /* swizzled int B */
+ 0000 0 0 3 &UIC2 2 4 /* swizzled int C */
+ 0000 0 0 4 &UIC2 3 4 /* swizzled int D */>;
+ };
+ };
+};
--
1.5.4.rc3
^ permalink raw reply related
* [PATCH] [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
From: Stefan Roese @ 2008-01-16 9:00 UTC (permalink / raw)
To: linuxppc-dev
Remove all "i2c" and "xxmii-interface" (rgmii etc) device_type entries
from the 4xx dts files.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/bamboo.dts | 3 ---
arch/powerpc/boot/dts/ebony.dts | 2 --
arch/powerpc/boot/dts/katmai.dts | 2 --
arch/powerpc/boot/dts/kilauea.dts | 3 ---
arch/powerpc/boot/dts/makalu.dts | 3 ---
arch/powerpc/boot/dts/rainier.dts | 4 ----
arch/powerpc/boot/dts/sequoia.dts | 4 ----
arch/powerpc/boot/dts/taishan.dts | 4 ----
8 files changed, 0 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/boot/dts/bamboo.dts b/arch/powerpc/boot/dts/bamboo.dts
index 29f1a6f..7dc37c9 100644
--- a/arch/powerpc/boot/dts/bamboo.dts
+++ b/arch/powerpc/boot/dts/bamboo.dts
@@ -185,7 +185,6 @@
};
IIC0: i2c@ef600700 {
- device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
@@ -193,7 +192,6 @@
};
IIC1: i2c@ef600800 {
- device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
@@ -201,7 +199,6 @@
};
ZMII0: emac-zmii@ef600d00 {
- device_type = "zmii-interface";
compatible = "ibm,zmii-440ep", "ibm,zmii-440gp", "ibm,zmii";
reg = <ef600d00 c>;
};
diff --git a/arch/powerpc/boot/dts/ebony.dts b/arch/powerpc/boot/dts/ebony.dts
index f8790c4..106ef37 100644
--- a/arch/powerpc/boot/dts/ebony.dts
+++ b/arch/powerpc/boot/dts/ebony.dts
@@ -215,7 +215,6 @@
IIC0: i2c@40000400 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000400 14>;
interrupt-parent = <&UIC0>;
@@ -223,7 +222,6 @@
};
IIC1: i2c@40000500 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000500 14>;
interrupt-parent = <&UIC0>;
diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
index 9bdfc0f..bc32ac7 100644
--- a/arch/powerpc/boot/dts/katmai.dts
+++ b/arch/powerpc/boot/dts/katmai.dts
@@ -187,7 +187,6 @@
};
IIC0: i2c@10000400 {
- device_type = "i2c";
compatible = "ibm,iic-440spe", "ibm,iic-440gp", "ibm,iic";
reg = <10000400 14>;
interrupt-parent = <&UIC0>;
@@ -195,7 +194,6 @@
};
IIC1: i2c@10000500 {
- device_type = "i2c";
compatible = "ibm,iic-440spe", "ibm,iic-440gp", "ibm,iic";
reg = <10000500 14>;
interrupt-parent = <&UIC0>;
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
index 67c7ea1..8baef61 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -182,7 +182,6 @@
};
IIC0: i2c@ef600400 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600400 14>;
interrupt-parent = <&UIC0>;
@@ -190,7 +189,6 @@
};
IIC1: i2c@ef600500 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600500 14>;
interrupt-parent = <&UIC0>;
@@ -199,7 +197,6 @@
RGMII0: emac-rgmii@ef600b00 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii";
reg = <ef600b00 104>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index bdd70e4..710c011 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -182,7 +182,6 @@
};
IIC0: i2c@ef600400 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600400 14>;
interrupt-parent = <&UIC0>;
@@ -190,7 +189,6 @@
};
IIC1: i2c@ef600500 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600500 14>;
interrupt-parent = <&UIC0>;
@@ -199,7 +197,6 @@
RGMII0: emac-rgmii@ef600b00 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii";
reg = <ef600b00 104>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/rainier.dts b/arch/powerpc/boot/dts/rainier.dts
index d3c2ac3..f947c75 100644
--- a/arch/powerpc/boot/dts/rainier.dts
+++ b/arch/powerpc/boot/dts/rainier.dts
@@ -229,7 +229,6 @@
};
IIC0: i2c@ef600700 {
- device_type = "i2c";
compatible = "ibm,iic-440grx", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
@@ -237,7 +236,6 @@
};
IIC1: i2c@ef600800 {
- device_type = "i2c";
compatible = "ibm,iic-440grx", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
@@ -245,13 +243,11 @@
};
ZMII0: emac-zmii@ef600d00 {
- device_type = "zmii-interface";
compatible = "ibm,zmii-440grx", "ibm,zmii";
reg = <ef600d00 c>;
};
RGMII0: emac-rgmii@ef601000 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-440grx", "ibm,rgmii";
reg = <ef601000 8>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
index d9046c1..276f596 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -236,7 +236,6 @@
};
IIC0: i2c@ef600700 {
- device_type = "i2c";
compatible = "ibm,iic-440epx", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
@@ -244,7 +243,6 @@
};
IIC1: i2c@ef600800 {
- device_type = "i2c";
compatible = "ibm,iic-440epx", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
@@ -252,13 +250,11 @@
};
ZMII0: emac-zmii@ef600d00 {
- device_type = "zmii-interface";
compatible = "ibm,zmii-440epx", "ibm,zmii";
reg = <ef600d00 c>;
};
RGMII0: emac-rgmii@ef601000 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-440epx", "ibm,rgmii";
reg = <ef601000 8>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index 0706a4a..8278068 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -203,7 +203,6 @@
IIC0: i2c@40000400 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000400 14>;
interrupt-parent = <&UIC0>;
@@ -211,7 +210,6 @@
};
IIC1: i2c@40000500 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000500 14>;
interrupt-parent = <&UIC0>;
@@ -225,13 +223,11 @@
};
ZMII0: emac-zmii@40000780 {
- device_type = "zgmii-interface";
compatible = "ibm,zmii-440gx", "ibm,zmii";
reg = <40000780 c>;
};
RGMII0: emac-rgmii@40000790 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii";
reg = <40000790 8>;
};
--
1.5.4.rc3
^ permalink raw reply related
* PPC440SPe: generating PCIe INTx
From: kannappan @ 2008-01-16 8:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 867 bytes --]
Hello All,
I would like to know how to generate PCIe INTx interrupt from Legacy
PCIe EP in PPC440SPe.
Also, please clarify,
Page 741 of the user manual (PPC440SPe_UM2014_V1_26.pdf) write
Assert_INTx message to INT_ADDR[61:63].
Page 739, table 27-9, mentions, Assert_INTA by writing to Outbound GBIF
write channel 9, A[52:59]=0x20.
Whether the INT_ADDR is any addresses BAR3 / POM3 address?
What is the Assert_INTx value to be written to INT_ADDR[61:63]? How do
I correlate with the message code values given in PCI express system
architecture?
The message codes given in PCI express system architecture is as follows
INTx Messages
Message Code
Assert_INTA
0010 0000
Assert_INTB
0010 0001
Assert_INTC
0010 0010
Assert_INTD
0010 0011
Deassert_INTA
0010 0100
Deassert_INTB
0010 0101
Deassert_INTC
0010 0110
Deassert_INTD
0010 0111
Regards,
Kans.
[-- Attachment #2: Type: text/html, Size: 12516 bytes --]
^ permalink raw reply
* [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Stefan Roese @ 2008-01-16 9:37 UTC (permalink / raw)
To: linuxppc-dev, netdev
With the removal the the "rgmii-interface" device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/rgmii.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index 9bc1132..5757788 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -302,7 +302,6 @@ static int __devexit rgmii_remove(struct of_device *ofdev)
static struct of_device_id rgmii_match[] =
{
{
- .type = "rgmii-interface",
.compatible = "ibm,rgmii",
},
{
--
1.5.4.rc3
^ permalink raw reply related
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: David Gibson @ 2008-01-16 9:39 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200476230-14026-1-git-send-email-sr@denx.de>
On Wed, Jan 16, 2008 at 10:37:10AM +0100, Stefan Roese wrote:
> With the removal the the "rgmii-interface" device_type property from the
> dts files, the newemac driver needs an update to only rely on compatible
> property.
In fact, this patch should go in before the one changing the dts
files.
--
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: [PATCH] [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
From: David Gibson @ 2008-01-16 9:40 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1200474000-5630-1-git-send-email-sr@denx.de>
On Wed, Jan 16, 2008 at 10:00:00AM +0100, Stefan Roese wrote:
> Remove all "i2c" and "xxmii-interface" (rgmii etc) device_type entries
> from the 4xx dts files.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Benjamin Herrenschmidt @ 2008-01-16 9:53 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200476230-14026-1-git-send-email-sr@denx.de>
On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> With the removal the the "rgmii-interface" device_type property from the
> dts files, the newemac driver needs an update to only rely on compatible
> property.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
I need to test if it works on CAB, can't change the DT on those. I'll
let you know tomorrow.
> ---
> drivers/net/ibm_newemac/rgmii.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
> index 9bc1132..5757788 100644
> --- a/drivers/net/ibm_newemac/rgmii.c
> +++ b/drivers/net/ibm_newemac/rgmii.c
> @@ -302,7 +302,6 @@ static int __devexit rgmii_remove(struct of_device *ofdev)
> static struct of_device_id rgmii_match[] =
> {
> {
> - .type = "rgmii-interface",
> .compatible = "ibm,rgmii",
> },
> {
^ permalink raw reply
* ppc: 4xx: sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
From: Stefan Roese @ 2008-01-16 10:55 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
I'm seeing this error message when booting an recent arch/ppc kernel on
4xx platforms (tested on Ocotea and other 4xx platforms). Booting NFS
rootfs still works fine, but this message kind of makes me "nervous".
This is not seen on 4xx arch/powerpc platforms. Here the bootlog:
Linux version 2.6.24-rc8 (stefan@ubuntu) (gcc version 4.2.2) #1 Wed Jan 16 11:51:57 CET 2008
IBM Ocotea port (MontaVista Software, Inc. <source@mvista.com>)
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 65536
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk-4.1/ppc_4xx ip=192.168.80.2:192.168.1.1::255.255.0.0:ocotea:eth0:off panic=1 console=ttyS0,115200
PID hash table entries: 1024 (order: 10, 4096 bytes)
console [ttyS0] enabled
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 257536k available (1660k kernel code, 540k data, 104k init, 0k highmem)
SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Mount-cache hash table entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
Call Trace:
[cfc11df0] [c00082d0] show_stack+0x44/0x1ac (unreliable)
[cfc11e30] [c0034ffc] set_fail+0x50/0x68
[cfc11e50] [c0035428] sysctl_check_table+0x414/0x70c
[cfc11ec0] [c003543c] sysctl_check_table+0x428/0x70c
[cfc11f30] [c0021fe4] register_sysctl_table+0x64/0xb4
[cfc11f50] [c0213858] register_ppc_htab_sysctl+0x18/0x2c
[cfc11f60] [c02121f4] kernel_init+0xd0/0x2b0
[cfc11ff0] [c0003b3c] kernel_thread+0x44/0x60
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
...
Any ideas?
Thanks.
Best regards,
Stefan
^ permalink raw reply
* MPC52xx problems with fec-driver
From: Mehlan, Markus (Ritter Elektronik) @ 2008-01-16 12:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
i have a mpc5200b-based board with 2 ethernet interfaces,
Kernel 2.6.23.1-rt5 (arch=3Dpowerpc), last fec/bestcomm-patches:
eth0: mpc52xx_FEC
eth1: natsemi dp8381x
The natsemi driver works pretty, but the FEC makes problems:
If i ping the board i get damaged packages. The interrupt-counter
for the control-irq (mpc52xx-fec_ctrl) stays on zero.
The FEC interface works with an older kernel (2.6.14-rt22 arch=3Dppc).
Markus
root@phyCORE-MPC5200B-tiny:~ cat /proc/interrupts
CPU0
66: 5 MPC52xx IRQ[0-3] Edge eth1
132: 1368 MPC52xx Peripherals Edge mpc52xx_psc_uart
133: 0 MPC52xx Peripherals Edge mpc52xx-fec_ctrl
143: 2 MPC52xx Peripherals Edge i2c-mpc
144: 60 MPC52xx Peripherals Edge i2c-mpc
145: 0 MPC52xx Peripherals Edge can0
146: 0 MPC52xx Peripherals Edge can1
192: 32 MPC52xx SDMA Edge mpc52xx-fec_rx
193: 35 MPC52xx SDMA Edge mpc52xx-fec_tx
BAD: 0
ritter-ewc2:/home/meh # ping -a 192.168.0.9
PING 192.168.0.9 (192.168.0.9) 56(84) bytes of data.
64 bytes from 192.168.0.9: icmp_seq=3D3 ttl=3D64 time=3D0.267 ms
64 bytes from 192.168.0.9: icmp_seq=3D11 ttl=3D64 time=3D0.271 ms
64 bytes from 192.168.0.9: icmp_seq=3D17 ttl=3D64 time=3D0.266 ms
wrong data byte #20 should be 0x14 but was 0x0
#8 8 9 a b c d e f 10 11 12 13 0 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27
#40 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37
--- 192.168.0.9 ping statistics ---
19 packets transmitted, 3 received, 84% packet loss, time 18026ms
------------------------------------------------------------------
Using ritter_el392 machine description
Linux version 2.6.23.1-rt5-el392trunk (meh@ritter-ewc2) (gcc version
4.1.2) #445 PREEMPT RT Wed Jan 16 12:05:52 CET 2008
Found initrd at 0xc3a2e000:0xc3f47e63
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 16384
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists in Zone order. Total pages: 16256
Kernel command line: console=3DttyPSC0,115200 root=3D/dev/ram0 rw
ip=3D192.168.0.10:192.168.0.1::255.255.255.0:RITTER_EL392:eth1:off =
panic=3D1
WARNING: experimental RCU implementation.
MPC52xx PIC is up and running!
PID hash table entries: 256 (order: 8, 1024 bytes)
console [ttyPSC0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 56972k/65536k available (2412k kernel code, 8500k reserved, 132k
data, 101k bss, 148k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
DMA: MPC52xx BestComm driver
DMA: MPC52xx BestComm engine @f0001200 ok !
Generic PHY xxx: Registered new driver
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 4, 73728 bytes)
TCP bind hash table entries: 2048 (order: 3, 57344 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
checking if image is initramfs...it isn't (no cpio magic); looks like an
initrd
Freeing initrd memory: 5223k freed
io scheduler noop registered (default)
Serial: MPC52xx PSC UART driver
f0002c00.serial: ttyPSC0 at MMIO 0xf0002c00 (irq =3D 132) is a MPC52xx =
PSC
RAMDISK driver initialized: 2 RAM disks of 20480K size 1024 blocksize
mpc52xx-mscan initializing
mpc52xx-mscan mpc52xx-mscan.0: probe for a port 0xC500A900 done
mpc52xx-mscan mpc52xx-mscan.1: probe for a port 0xC500C980 done
mpc52xx MII bus: probed
natsemi dp8381x driver, version 2.1, Sept 11, 2006
originally by Donald Becker <becker@scyld.com>
2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
PCI: Enabling device 0000:00:18.0 (0006 -> 0007)
natsemi eth1: NatSemi DP8381[56] at 0xa0000000 (0000:00:18.0),
00:0b:93:80:01:00, IRQ 66, port TP.
i2c /dev entries driver
pcf8563 1-0051: chip found, driver version 0.4.2
pcf8563 1-0051: rtc core: registered pcf8563 as rtc0
MPC52xx Watchdog Timer on GPT0
MPC52xx Watchdog-Relay on GPIO
Registered led device: el392:right
Registered led device: el392:middle
Registered led device: el392:left
EL392 Front-LEDs found
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
can: controller area network core (rev 20070916 abi 8)
NET: Registered protocol family 29
can: raw protocol (rev 20070916)
pcf8563 1-0051: setting the system clock to 2008-01-16 12:06:42
(1200485202)
eth1: DSPCFG accepted after 0 usec.
eth1: link up.
eth1: Setting full-duplex based on negotiated link capability.
IP-Config: Complete:
device=3Deth1, addr=3D192.168.0.10, mask=3D255.255.255.0,
gw=3D255.255.255.255,
host=3DRITTER_EL392, domain=3D, nis-domain=3D(none),
bootserver=3D192.168.0.1, rootserver=3D192.168.0.1, rootpath=3D
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 148k init
mounting filesystems...done.
running rc.d services...
mounting... tmpfs at /dev
creating static nodes
creating initial udev device nodes...done
udev startup is finished
loading modules
syslogd starting
klogd starting
starting network interfaces...
can0: baudrate 250
can1: baudrate 250
net eth0: attached phy 0 to driver Generic PHY
PURE-FTPD: No /etc/pure-ftpd.defaults found.
/usr/sbin/pure-ftpd
PURE-FTPD: Starting pure-ftpd: /usr/sbin/pure-ftpd
PURE-FTPD: no upload script defined, skipping
Done
Starting telnetd...
thttpd: starting
thttpd: done
el392 login:=20
PHY: f0003000:00 - Link is Up - 100/Full
net eth0: attached phy 0 to driver Generic PHY
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
From: Josh Boyer @ 2008-01-16 12:40 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1200474000-5630-1-git-send-email-sr@denx.de>
On Wed, 16 Jan 2008 10:00:00 +0100
Stefan Roese <sr@denx.de> wrote:
> Remove all "i2c" and "xxmii-interface" (rgmii etc) device_type entries
> from the 4xx dts files.
Holding on this one until Ben or I can check Axon to see if it's DT can
handle no device_type for xxmii-interface.
josh
^ permalink raw reply
* Re: i2c device for a linux 2.6 in XUPV2P
From: greenlean @ 2008-01-16 12:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <ef1737dc0712241327t3cc7c14kcb91e9a4e550df18@mail.gmail.com>
Hi Josep,
I have read this post in linuxppc-embedded and you said that you're running
linux 2.6 in the XUPV2P. I'm beginning in this world (fpga and linux) and
nothing is running. I'm trying to boot kernel 2.6 on that board, but it is
resisting me. I have successfully booted it up on the ML403, but all my
attempts in the XUPV2P are crashing, maybe you could help me.
My problem is that I can't see anything in the minicom console when I
download the kernel. I build the kernel succesfully, using both UART IP
cores (UARTLite and UART16550) but in both cases there is no prompt in
minicom. I start with the TestApp generated by EDK and both MemTest and
PeripheralTest are running fine. But then when I do dow zImage, there is no
prompt.
I think I'm using correctly the drivers, when I use UARTLite I configure the
boud rate at arch/ppc/boot/common/ns16550.c and I configure the kernel with:
* initial command string console=ttyUL0,<baudrate>
* and in Device Drivers/Character Devices/Serial Drivers I choose Xilinx
uartlite serial port to include in the kernel and Support for console on
Xilinx UartLite serial port.
and when I use the UART16550 I configure it
* initial command string console=ttyS0,<baudrate>
* and in Device Drivers/Character Devices/Serial Drivers I choose Xilinx
8250/16550 and compatible support and console on 8250/16550 and compatible
serial port
I think that's the correct configuration,I read it in this list and in some
application notes from Xilinx which isn't very well.
By the other side I'm overwriting the xparameter_ml300.h file of the kernel
with the one generated by EDK 9.1i SP2, I'm using only this file from the
bsp generated by EDK.
I'm using the kernel from xilinx git and I've tried the one from secretlab,
but not the same as you, I'm using the (linux-2.6-virtex). I don't know how
to download or change to the branch "virtex-for-2.6.24" that you're using
(I'm new to git too, some help will be welcome).
Thanks I really need some guide for the process. If you know about any patch
or which is the problem I'm suffering please tell me.
Josep Maria Batlle wrote:
>
> Hi all,
>
> I have booted up linux 2.6 on Xilinx XUPV2P (using the base of ml300
> config
> file).
> Now I am trying to use the i2c in the user-space. First of all: is it
> possible?
>
> My first attempts have not worked. I have made this:
> 1) I enable "I2C Support" and "I2C device interface" in the kernel
> recompilation.
> 2) I added the "i2c-0" device in /dev (# mknod i2c-0 c 89 0)
> 3) then I run a simple program to open the device (provided by the
> "dev-interface" file of i2c kernel documentation) that returns this errno
> message: "No such device".
>
> I have tried to use the device number 1, 2, 3, 4 but these have not
> worked.
> I have tried to use the device "i2cn" but not worked. I have tried to use
> all the BSP's from the EDK (7.1i) and then only the "xparameters_ml300.h"
> in
> the compilation. After all of this, now I am modifying the RFS for
> "mdev"...
> Somebody can tell me what I am doing wrong if this use is possible?
>
> I use the kernel tree "virtex-for-2.6.24" from SecretLab and Busybox
> 1.7.2.
>
> Thanks.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
View this message in context: http://www.nabble.com/i2c-device-for-a-linux-2.6-in-XUPV2P-tp14491409p14879785.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Please pull from 'for-2.6.25' branch of 4xx tree
From: Josh Boyer @ 2008-01-16 12:49 UTC (permalink / raw)
To: paulus, linuxppc-dev
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.25
to pick up a small number of changes for 2.6.25. Mostly Xilinx stuff
from Stephen and Grant, with a couple of EMAC enables and a bug fix.
I'll likely send another pull request with some more patches from
Stefan and David, as well as the PIKA Warp platform patches. But I
need to look at those a bit longer.
josh
Grant Likely (1):
[POWERPC] 4xx: typo in calling machine_device_initcall() for Sequoia board
Hollis Blanchard (1):
[POWERPC] 4xx: enable built-in networking for Sequoia defconfig
Josh Boyer (1):
Merge branch 'virtex-for-2.6.25' of git://git.secretlab.ca/git/linux-2.6-v
Matthias Fuchs (1):
[POWERPC] 4xx: Add 405GPr and 405EP support in boot wrapper
Stefan Roese (2):
[POWERPC] 4xx: Add EMAC support to Kilauea defconfig
[POWERPC] 4xx: PCIe: Increase max busses per port to 64
Stephen Neuendorffer (5):
[POWERPC] Xilinx: update compatible list for interrupt controller
[POWERPC] Xilinx: Add correct compatible list for device tree bus bindings
[POWERPC] Xilinx: Update booting-without-of.
[POWERPC] Xilinx: updated device tree compatibility to match uboot bsp gen
[POWERPC] Xilinx uartlite: Section type fixups
Documentation/powerpc/booting-without-of.txt | 56 +++++++++++-------
arch/powerpc/boot/4xx.c | 81 +++++++++++++++++++++++--
arch/powerpc/boot/4xx.h | 1 +
arch/powerpc/boot/dcr.h | 5 ++
arch/powerpc/boot/serial.c | 3 +-
arch/powerpc/configs/bamboo_defconfig | 4 +-
arch/powerpc/configs/kilauea_defconfig | 23 +++++++-
arch/powerpc/configs/sequoia_defconfig | 24 ++++++-
arch/powerpc/platforms/40x/virtex.c | 12 ++++-
arch/powerpc/platforms/44x/sequoia.c | 2 +-
arch/powerpc/sysdev/ppc4xx_pci.c | 2 +-
arch/powerpc/sysdev/xilinx_intc.c | 8 ++-
drivers/serial/uartlite.c | 6 +-
13 files changed, 180 insertions(+), 47 deletions(-)
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
From: Stefan Roese @ 2008-01-16 13:01 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080116064008.390db210@zod.rchland.ibm.com>
Josh,
On Wednesday 16 January 2008, Josh Boyer wrote:
> > Remove all "i2c" and "xxmii-interface" (rgmii etc) device_type entries
> > from the 4xx dts files.
>
> Holding on this one until Ben or I can check Axon to see if it's DT can
> handle no device_type for xxmii-interface.
Best would be, if you would hold this patch at least until the newemac patch
is pulled.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
From: Josh Boyer @ 2008-01-16 13:08 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801161401.22855.sr@denx.de>
On Wed, 16 Jan 2008 14:01:22 +0100
Stefan Roese <sr@denx.de> wrote:
> Josh,
>
> On Wednesday 16 January 2008, Josh Boyer wrote:
> > > Remove all "i2c" and "xxmii-interface" (rgmii etc) device_type entries
> > > from the 4xx dts files.
> >
> > Holding on this one until Ben or I can check Axon to see if it's DT can
> > handle no device_type for xxmii-interface.
>
> Best would be, if you would hold this patch at least until the newemac patch
> is pulled.
Sure, I was already planning on doing that anyway. It's early, and
the Axon verification is really for that newemac patch anyway, not
this one :)
josh
^ permalink raw reply
* ml310 kernel2.6 booting problems
From: Joachim Meyer @ 2008-01-16 13:25 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I made an Ace file with my Kernel and load it with the Flash Card.
I made the Initial release CF image on the card and copied my ace file in an folder, from which I boot with the DIP-Switch.
If I used
"console=ttyUL0 ,9600 root=/dev/xsysace/disc0/part2 rw "
in the Kernel config booting aborts like this:
----------------------------------------------------------------------------------------------------------------
....
[ 5.715168] 000001c0: 00000000 00000000 00000000 00000000 ................
[ 5.797484] 000001d0: 00000000 00000000 00000000 00000000 ................
[ 5.879741] 000001e0: 00000000 00000000 00000000 00000000 ................
[ 5.962057] 000001f0: 00000000 00000000 00000000 00000000 ................
[ 6.044365] xsysace xsysace.0: capacity: 1000944 sectors
[ 6.109986] xsa:<7>xsysace xsysace.0: fsm_state=0, id_req_count=0
[ 6.207902] xsa1 xsa2
[ 6.226842] Xilinx SystemACE device driver, major=254
[ 6.281419] tun: Universal TUN/TAP device driver, 1.6
[ 6.341706] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 6.419485] mice: PS/2 mouse device common for all mice
[ 6.478716] TCP cubic registered
[ 6.516974] NET: Registered protocol family 1
[ 6.568940] NET: Registered protocol family 17
[ 6.627483] VFS: Cannot open root device "xsysace/disc0/part2" or unknown-block(0,0)
[ 6.714743] Please append a correct "root=" boot option; here are the available partitions:
[ 6.814732] fe00 500472 xsa (driver?)
[ 6.862193] fe01 98248 xsa1
[ 6.902974] fe02 402192 xsa2
[ 6.943603] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 7.042832] Rebooting in 180 seconds..
------------------------------------------------------------------------------------------------------------------------------------
I tried to use this:
"console=ttyUL0 ,9600 root=fe02 rw"
and with this, after making ace-file etc. I get:
-------------------------------------------------------------------------------------------------------
...
[ 5.447429] 00000190: 00000000 00000000 00000000 00000000 ................
[ 5.529734] 000001a0: 00000000 00000000 00000000 00000000 ................
[ 5.612002] 000001b0: 00000000 00000000 00000000 00000000 ................
[ 5.694288] 000001c0: 00000000 00000000 00000000 00000000 ................
[ 5.776594] 000001d0: 00000000 00000000 00000000 00000000 ................
[ 5.858861] 000001e0: 00000000 00000000 00000000 00000000 ................
[ 5.941167] 000001f0: 00000000 00000000 00000000 00000000 ................
[ 6.023453] xsysace xsysace.0: capacity: 1000944 sectors
[ 6.090042] xsa:<7>xsysace xsysace.0: fsm_state=0, id_req_count=0
[ 6.186832] xsa1 xsa2
[ 6.205880] Xilinx SystemACE device driver, major=254
[ 6.260331] tun: Universal TUN/TAP device driver, 1.6
[ 6.320626] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 6.398443] mice: PS/2 mouse device common for all mice
[ 6.457695] TCP cubic registered
[ 6.495755] NET: Registered protocol family 1
[ 6.547840] NET: Registered protocol family 17
[ 12.726608] kjournald starting. Commit interval 5 seconds
[ 12.862678] EXT3 FS on xsa2, internal journal
[ 12.899229] EXT3-fs: recovery complete.
[ 12.982635] EXT3-fs: mounted filesystem with ordered data mode.
[ 13.038505] VFS: Mounted root (ext3 filesystem).
[ 13.094113] Freeing unused kernel memory: 96k init
[ 13.159079] Warning: unable to open an initial console.
-------------------------------------------------------------------------------------------------
what is the Problem here?
What should I consider when I configure the kernel, what when building an rootfs?
Greetings
Joachim
_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten!
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114
^ 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