* Re: Mapping huge user buffers for DMA
From: Stephen Williams @ 2005-08-31 0:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200508310210.51561.roger.larsson@norran.net>
Roger Larsson wrote:
> On Tuesday 30 August 2005 19.27, Stephen Williams wrote:
>
>>I have a PPC405GPr system with an image processing device, that
>>is creating potentially huge amounts of data. In one setup I
>>have a 256Meg system, and I'm trying to map a 192Meg destination
>>buffer using map_user_kiovec and an array of kiobufs.
>
>
> Never tried to map that amount at once. Our code looks, or looked, like this.
> Found some code...
> /usr/src/linuxppc_2_4_devel/arch/cris/drivers/examples/kiobuftest.c
That's similar to where I'm at now, and I'm finding it inadequate.
>>I'm finding, however, that I'm getting an Oops in map_user_kiovec
>>when it tries this, and I'm wondering where I need to look for
>>any limits I might be overrunning.
>
>
> What does the Oops say??
> Hmm... How much space will the vector itself require?
If placed into a single kiobuf, it would need 49,152 page pointers,
which would be 192K bytes for the maplist. Since the kernel uses
kmalloc to allocate the maplist, that won't work. Thus, I've
created an array of kiobufs to hold a smaller chunk of the pages
for the user buffer.
The Oops is a sig11 within the map_user_kiovec. (?!)
I also see errors from the kernel being unable to allocate
pages, so it seems like something is not handling an OOM
situation very well.
>
>>Also, I've been considering skipping kiobufs all together and
>>instead using code like this (lifted from map_user_kiobuf)
>>
>> /* Try to fault in all of the necessary pages */
>> down_read(&mm->mmap_sem);
>> /* rw==READ means read from disk, write into memory area */
>> err = get_user_pages(current, mm, va, pgcount,
>> (rw==READ), 0, iobuf->maplist, NULL);
>> up_read(&mm->mmap_sem);
>>
>>to get the user pages directly. This is really what I want, and
>>I do not need the other functionality of kiobufs. Is the
>>get_user_pages function kosher for use by drivers? Is there
>>a limit to what get_user_pages may map?
>
>
> Isn't this the way it is done in 2.6 anyway?
Well that's how the map_user_kiovec in 2.4 does it. I'm just
wondering if I were to do it myself using get_user_pages, would
I be peeking around the curtain at interfaces not meant to be
public. I'm thinking I need to ues get_user_pages myself to
avoid the extra overhead of kiobufs, and I can use vmalloc'ed
memory to hold those page pointers for later unmap so I don't
run up against the kmalloc limit.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
^ permalink raw reply
* Question about SMC serial port on MPC8270 in u-boot
From: FCG WANG Baohua @ 2005-08-31 0:51 UTC (permalink / raw)
To: linuxppc-embedded, wd; +Cc: Jack_liu, Tsi-Chung.Liew
[-- Attachment #1: Type: text/plain, Size: 794 bytes --]
Dear All:
When i port the u-boot 1.1.3 on my MPC8270 board, the serial port has the following question:
1. the Dual port ram cannot be revised manually, but can be revised by the u-boot code. What's the problem?
2. the serial_putc() in serial_smc.c is loop forever on "while (tbdf->cbd_sc & BD_SC_READY);". How to slove the bug?
3. the speed.c calc the wrong cpm, cpu, brg_clk, I had hard coded the right cpm, cpu, brg_clk values. But the "m8260_cpm_setbrg()" is still wrong? Why?
the registers are all right.
4. Can you tell me the ALL items about the SMC1 UART output? I had checked almost all the concerned SMC registers, IO ports,
data structures, they all seems right, but the UART cannot work. How could I find the problem?
thanks a lot !
[-- Attachment #2: Type: text/html, Size: 2056 bytes --]
^ permalink raw reply
* Re: Marvell MV6436xx ethernet driver patch
From: Andrew Morton @ 2005-08-31 0:59 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev, sl, Garzik, galak, Jeff
In-Reply-To: <20050830181119.E3A491C000B2@mwinf1203.wanadoo.fr>
Nicolas DET <nd@bplan-gmbh.de> wrote:
>
> You can find enclosed a patch for the Marvell MV643xx ethernet driver.
>
> It's also there:
> http://arrakin.homedns.org/~nicolas/mv643xx_eth.tar.gz (tarball)
> http://arrakin.homedns.org/~nicolas/mv643xx_eth.diff.bz2
>
> The diff is against the kernel 2.6.13 (kernel.org).
>
> The main changes (AFAIR):
> * Workaround for the TCP/UDP hw checksum
> * Use hardware for statistics
> * Define and use SRAM (for pegasos II archp/ppc/chrp_pegasos_eth.c)
> * Able to use max burst size from/to DDR (serious transfer boost)
> * Option can be selected through the menu (drivers/net/Kconfig)
> * ...
>
> some testing...
>
> By the way, I noticed that page_address() sometimes returns NULL when using
> highmem (with a lot of mem).
>
> You are welcome to review this patch. Some parts (especially the TX bug
> workaroud) will be appreciated IMO.
- Does strange things to drivers/net/Kconfig, like removing the SKGE entry(?)
- Generates rather a lot of rejects agains post-2.6.13 changes. You'll
need to rediff this against current Linus tree or, preferably, against
the next -mm kernel, please.
- Please cc netdev@vger.kernel.org next time.
^ permalink raw reply
* Re: Remove progress msgs from MMU_init()
From: Dan Malek @ 2005-08-31 1:09 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20050830233851.GA29529@mag.az.mvista.com>
On Aug 30, 2005, at 7:38 PM, Mark A. Greer wrote:
> Does anyone object to this patch?
Don't you still need this to run stuff like xmon and kgdb?
Thanks.
-- Dan
^ permalink raw reply
* Re: Remove progress msgs from MMU_init()
From: Mark A. Greer @ 2005-08-31 1:29 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <d561d896950ba7adde6b93c1a2bba272@embeddededge.com>
On Tue, Aug 30, 2005 at 09:09:55PM -0400, Dan Malek wrote:
>
> On Aug 30, 2005, at 7:38 PM, Mark A. Greer wrote:
>
> >Does anyone object to this patch?
>
> Don't you still need this to run stuff like xmon and kgdb?
Those should work with just an io_block_mapping() which will be active
before setup_arch() calls xmon() and breakpoint().
The problem with progress msgs in MMU_init() is that they try to bang on
the uart before ioremaps/io_block_mappings are active. That's why I (and
others) had the xxx_set_bat() hack.
Mark
^ permalink raw reply
* Remove progress msgs from MMU_init()
From: Mark A. Greer @ 2005-08-31 1:39 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
With that patch this time...Argh...
--
This dates back to a discussion in May. This patch addresses point 1)
in the email below by ripping out the progress msgs from MMU_init().
This would allow us to get rid of all the xxx_set_bat() routines in the
various platform files.
Does anyone object to this patch?
Mark
http://ozlabs.org/pipermail/linuxppc-dev/2005-May/019120.html
[-- Attachment #2: mmu_init.patch --]
[-- Type: text/plain, Size: 1128 bytes --]
diff --git a/arch/ppc/mm/init.c b/arch/ppc/mm/init.c
--- a/arch/ppc/mm/init.c
+++ b/arch/ppc/mm/init.c
@@ -237,9 +237,6 @@ void MMU_setup(void)
*/
void __init MMU_init(void)
{
- if (ppc_md.progress)
- ppc_md.progress("MMU:enter", 0x111);
-
/* parse args from command line */
MMU_setup();
@@ -272,13 +269,9 @@ void __init MMU_init(void)
set_phys_avail(total_lowmem);
/* Initialize the MMU hardware */
- if (ppc_md.progress)
- ppc_md.progress("MMU:hw init", 0x300);
MMU_init_hw();
/* Map in all of RAM starting at KERNELBASE */
- if (ppc_md.progress)
- ppc_md.progress("MMU:mapin", 0x301);
mapin_ram();
#ifdef CONFIG_HIGHMEM
@@ -289,17 +282,12 @@ void __init MMU_init(void)
ioremap_bot = ioremap_base;
/* Map in I/O resources */
- if (ppc_md.progress)
- ppc_md.progress("MMU:setio", 0x302);
if (ppc_md.setup_io_mappings)
ppc_md.setup_io_mappings();
/* Initialize the context management stuff */
mmu_context_init();
- if (ppc_md.progress)
- ppc_md.progress("MMU:exit", 0x211);
-
#ifdef CONFIG_BOOTX_TEXT
/* By default, we are no longer mapped */
boot_text_mapped = 0;
^ permalink raw reply
* Re: Remove progress msgs from MMU_init()
From: Paul Mackerras @ 2005-08-31 3:41 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20050831013953.GA5456@mag.az.mvista.com>
Mark A. Greer writes:
> Does anyone object to this patch?
Seems fine to me. Those progress calls are only for debugging.
Paul.
^ permalink raw reply
* [PATCH] ppc32: move 4xx PHY_MODE_XXX defines to ibm_ocp.h
From: Eugene Surovegin @ 2005-08-31 4:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
Move 4xx PHY_MODE_XXX defines to asm-ppc/ibm_ocp.h. This is
a preparation step for the new EMAC driver.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
arch/ppc/platforms/4xx/bamboo.c | 7 -------
arch/ppc/platforms/4xx/ebony.c | 7 -------
arch/ppc/platforms/4xx/luan.c | 7 -------
arch/ppc/platforms/4xx/ocotea.c | 7 -------
include/asm-ppc/ibm_ocp.h | 13 +++++++++++++
5 files changed, 13 insertions(+), 28 deletions(-)
diff --git a/arch/ppc/platforms/4xx/bamboo.c b/arch/ppc/platforms/4xx/bamboo.c
--- a/arch/ppc/platforms/4xx/bamboo.c
+++ b/arch/ppc/platforms/4xx/bamboo.c
@@ -52,13 +52,6 @@
#include <syslib/gen550.h>
#include <syslib/ibm440gx_common.h>
-/*
- * This is a horrible kludge, we eventually need to abstract this
- * generic PHY stuff, so the standard phy mode defines can be
- * easily used from arch code.
- */
-#include "../../../../drivers/net/ibm_emac/ibm_emac_phy.h"
-
bd_t __res;
static struct ibm44x_clocks clocks __initdata;
diff --git a/arch/ppc/platforms/4xx/ebony.c b/arch/ppc/platforms/4xx/ebony.c
--- a/arch/ppc/platforms/4xx/ebony.c
+++ b/arch/ppc/platforms/4xx/ebony.c
@@ -55,13 +55,6 @@
#include <syslib/gen550.h>
#include <syslib/ibm440gp_common.h>
-/*
- * This is a horrible kludge, we eventually need to abstract this
- * generic PHY stuff, so the standard phy mode defines can be
- * easily used from arch code.
- */
-#include "../../../../drivers/net/ibm_emac/ibm_emac_phy.h"
-
bd_t __res;
static struct ibm44x_clocks clocks __initdata;
diff --git a/arch/ppc/platforms/4xx/luan.c b/arch/ppc/platforms/4xx/luan.c
--- a/arch/ppc/platforms/4xx/luan.c
+++ b/arch/ppc/platforms/4xx/luan.c
@@ -53,13 +53,6 @@
#include <syslib/ibm440gx_common.h>
#include <syslib/ibm440sp_common.h>
-/*
- * This is a horrible kludge, we eventually need to abstract this
- * generic PHY stuff, so the standard phy mode defines can be
- * easily used from arch code.
- */
-#include "../../../../drivers/net/ibm_emac/ibm_emac_phy.h"
-
bd_t __res;
static struct ibm44x_clocks clocks __initdata;
diff --git a/arch/ppc/platforms/4xx/ocotea.c b/arch/ppc/platforms/4xx/ocotea.c
--- a/arch/ppc/platforms/4xx/ocotea.c
+++ b/arch/ppc/platforms/4xx/ocotea.c
@@ -53,13 +53,6 @@
#include <syslib/gen550.h>
#include <syslib/ibm440gx_common.h>
-/*
- * This is a horrible kludge, we eventually need to abstract this
- * generic PHY stuff, so the standard phy mode defines can be
- * easily used from arch code.
- */
-#include "../../../../drivers/net/ibm_emac/ibm_emac_phy.h"
-
bd_t __res;
static struct ibm44x_clocks clocks __initdata;
diff --git a/include/asm-ppc/ibm_ocp.h b/include/asm-ppc/ibm_ocp.h
--- a/include/asm-ppc/ibm_ocp.h
+++ b/include/asm-ppc/ibm_ocp.h
@@ -100,6 +100,19 @@ void ocp_show_emac_data(struct device *d
device_create_file(dev, &dev_attr_emac_phy_map); \
}
+/*
+ * PHY mode settings (EMAC <-> ZMII/RGMII bridge <-> PHY)
+ */
+#define PHY_MODE_NA 0
+#define PHY_MODE_MII 1
+#define PHY_MODE_RMII 2
+#define PHY_MODE_SMII 3
+#define PHY_MODE_RGMII 4
+#define PHY_MODE_TBI 5
+#define PHY_MODE_GMII 6
+#define PHY_MODE_RTBI 7
+#define PHY_MODE_SGMII 8
+
#ifdef CONFIG_40x
/*
* Helper function to copy MAC addresses from the bd_t to OCP EMAC
^ permalink raw reply
* [PATCH] ppc32: add dcr_base field to ocp_func_mal_data
From: Eugene Surovegin @ 2005-08-31 4:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
Add dcr_base field to ocp_func_mal_data. This is preparation step for
the new EMAC driver.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
arch/ppc/platforms/4xx/ibm405ep.c | 1 +
arch/ppc/platforms/4xx/ibm405gp.c | 1 +
arch/ppc/platforms/4xx/ibm405gpr.c | 1 +
arch/ppc/platforms/4xx/ibm440ep.c | 1 +
arch/ppc/platforms/4xx/ibm440gp.c | 1 +
arch/ppc/platforms/4xx/ibm440gx.c | 1 +
arch/ppc/platforms/4xx/ibm440sp.c | 1 +
arch/ppc/platforms/4xx/ibmnp405h.c | 1 +
include/asm-ppc/ibm_ocp.h | 3 +++
9 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/platforms/4xx/ibm405ep.c b/arch/ppc/platforms/4xx/ibm405ep.c
--- a/arch/ppc/platforms/4xx/ibm405ep.c
+++ b/arch/ppc/platforms/4xx/ibm405ep.c
@@ -33,6 +33,7 @@ static struct ocp_func_mal_data ibm405ep
.txde_irq = 13, /* TX Descriptor Error IRQ */
.rxde_irq = 14, /* RX Descriptor Error IRQ */
.serr_irq = 10, /* MAL System Error IRQ */
+ .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */
};
OCP_SYSFS_MAL_DATA()
diff --git a/arch/ppc/platforms/4xx/ibm405gp.c b/arch/ppc/platforms/4xx/ibm405gp.c
--- a/arch/ppc/platforms/4xx/ibm405gp.c
+++ b/arch/ppc/platforms/4xx/ibm405gp.c
@@ -46,6 +46,7 @@ static struct ocp_func_mal_data ibm405gp
.txde_irq = 13, /* TX Descriptor Error IRQ */
.rxde_irq = 14, /* RX Descriptor Error IRQ */
.serr_irq = 10, /* MAL System Error IRQ */
+ .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */
};
OCP_SYSFS_MAL_DATA()
diff --git a/arch/ppc/platforms/4xx/ibm405gpr.c b/arch/ppc/platforms/4xx/ibm405gpr.c
--- a/arch/ppc/platforms/4xx/ibm405gpr.c
+++ b/arch/ppc/platforms/4xx/ibm405gpr.c
@@ -42,6 +42,7 @@ static struct ocp_func_mal_data ibm405gp
.txde_irq = 13, /* TX Descriptor Error IRQ */
.rxde_irq = 14, /* RX Descriptor Error IRQ */
.serr_irq = 10, /* MAL System Error IRQ */
+ .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */
};
OCP_SYSFS_MAL_DATA()
diff --git a/arch/ppc/platforms/4xx/ibm440ep.c b/arch/ppc/platforms/4xx/ibm440ep.c
--- a/arch/ppc/platforms/4xx/ibm440ep.c
+++ b/arch/ppc/platforms/4xx/ibm440ep.c
@@ -53,6 +53,7 @@ static struct ocp_func_mal_data ibm440ep
.txde_irq = 33, /* TX Descriptor Error IRQ */
.rxde_irq = 34, /* RX Descriptor Error IRQ */
.serr_irq = 32, /* MAL System Error IRQ */
+ .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */
};
OCP_SYSFS_MAL_DATA()
diff --git a/arch/ppc/platforms/4xx/ibm440gp.c b/arch/ppc/platforms/4xx/ibm440gp.c
--- a/arch/ppc/platforms/4xx/ibm440gp.c
+++ b/arch/ppc/platforms/4xx/ibm440gp.c
@@ -56,6 +56,7 @@ static struct ocp_func_mal_data ibm440gp
.txde_irq = 33, /* TX Descriptor Error IRQ */
.rxde_irq = 34, /* RX Descriptor Error IRQ */
.serr_irq = 32, /* MAL System Error IRQ */
+ .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */
};
OCP_SYSFS_MAL_DATA()
diff --git a/arch/ppc/platforms/4xx/ibm440gx.c b/arch/ppc/platforms/4xx/ibm440gx.c
--- a/arch/ppc/platforms/4xx/ibm440gx.c
+++ b/arch/ppc/platforms/4xx/ibm440gx.c
@@ -84,6 +84,7 @@ static struct ocp_func_mal_data ibm440gx
.txde_irq = 33, /* TX Descriptor Error IRQ */
.rxde_irq = 34, /* RX Descriptor Error IRQ */
.serr_irq = 32, /* MAL System Error IRQ */
+ .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */
};
OCP_SYSFS_MAL_DATA()
diff --git a/arch/ppc/platforms/4xx/ibm440sp.c b/arch/ppc/platforms/4xx/ibm440sp.c
--- a/arch/ppc/platforms/4xx/ibm440sp.c
+++ b/arch/ppc/platforms/4xx/ibm440sp.c
@@ -43,6 +43,7 @@ static struct ocp_func_mal_data ibm440sp
.txde_irq = 34, /* TX Descriptor Error IRQ */
.rxde_irq = 35, /* RX Descriptor Error IRQ */
.serr_irq = 33, /* MAL System Error IRQ */
+ .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */
};
OCP_SYSFS_MAL_DATA()
diff --git a/arch/ppc/platforms/4xx/ibmnp405h.c b/arch/ppc/platforms/4xx/ibmnp405h.c
--- a/arch/ppc/platforms/4xx/ibmnp405h.c
+++ b/arch/ppc/platforms/4xx/ibmnp405h.c
@@ -73,6 +73,7 @@ static struct ocp_func_mal_data ibmnp405
.txde_irq = 46, /* TX Descriptor Error IRQ */
.rxde_irq = 47, /* RX Descriptor Error IRQ */
.serr_irq = 45, /* MAL System Error IRQ */
+ .dcr_base = DCRN_MAL_BASE /* MAL0_CFG DCR number */
};
OCP_SYSFS_MAL_DATA()
diff --git a/include/asm-ppc/ibm_ocp.h b/include/asm-ppc/ibm_ocp.h
--- a/include/asm-ppc/ibm_ocp.h
+++ b/include/asm-ppc/ibm_ocp.h
@@ -146,6 +146,7 @@ struct ocp_func_mal_data {
int txde_irq; /* TX Descriptor Error IRQ */
int rxde_irq; /* RX Descriptor Error IRQ */
int serr_irq; /* MAL System Error IRQ */
+ int dcr_base; /* MALx_CFG DCR number */
};
#define OCP_SYSFS_MAL_DATA() \
@@ -156,6 +157,7 @@ OCP_SYSFS_ADDTL(struct ocp_func_mal_data
OCP_SYSFS_ADDTL(struct ocp_func_mal_data, "%d\n", mal, txde_irq) \
OCP_SYSFS_ADDTL(struct ocp_func_mal_data, "%d\n", mal, rxde_irq) \
OCP_SYSFS_ADDTL(struct ocp_func_mal_data, "%d\n", mal, serr_irq) \
+OCP_SYSFS_ADDTL(struct ocp_func_mal_data, "%d\n", mal, dcr_base) \
\
void ocp_show_mal_data(struct device *dev) \
{ \
@@ -166,6 +168,7 @@ void ocp_show_mal_data(struct device *de
device_create_file(dev, &dev_attr_mal_txde_irq); \
device_create_file(dev, &dev_attr_mal_rxde_irq); \
device_create_file(dev, &dev_attr_mal_serr_irq); \
+ device_create_file(dev, &dev_attr_mal_dcr_base); \
}
/*
^ permalink raw reply
* [PATCH 0/2] New PowerPC 4xx on-chip ethernet controller driver
From: Eugene Surovegin @ 2005-08-31 4:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
Jeff,
the following patches replace current PowerPC 4xx EMAC driver with
new, re-written version.
New driver uses NAPI, it solves problems under heavy packet load and
low memory, corrects chip register access and fixes numerous small
bugs I don't even remember now :).
This patch has been tested on all supported in 2.6 PPC 4xx boards.
It's been used in production for almost a year now on custom
4xx hardware. PPC32 specific parts were just posted to linuxppc-dev
and linuxppc-embedded mail lists.
Patch was acked by the current EMAC driver maintainer (Matt Porter). I
will be maintaining this new version.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
^ permalink raw reply
* [PATCH 1/2] New PowerPC 4xx on-chip ethernet controller driver
From: Eugene Surovegin @ 2005-08-31 5:00 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20050831045847.GA17017@gate.ebshome.net>
Remove old PPC4xx EMAC driver
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
drivers/net/Kconfig | 34 -
drivers/net/ibm_emac/Makefile | 12
drivers/net/ibm_emac/ibm_emac.h | 267 ----
drivers/net/ibm_emac/ibm_emac_core.c | 2011 ---------------------------------
drivers/net/ibm_emac/ibm_emac_core.h | 146 --
drivers/net/ibm_emac/ibm_emac_debug.c | 224 ----
drivers/net/ibm_emac/ibm_emac_mal.c | 463 --------
drivers/net/ibm_emac/ibm_emac_mal.h | 131 --
drivers/net/ibm_emac/ibm_emac_phy.c | 298 -----
drivers/net/ibm_emac/ibm_emac_phy.h | 137 --
drivers/net/ibm_emac/ibm_emac_rgmii.h | 65 -
drivers/net/ibm_emac/ibm_emac_tah.h | 48 -
drivers/net/ibm_emac/ibm_emac_zmii.h | 93 --
13 files changed, 0 insertions(+), 3929 deletions(-)
Patch is quite big (110K) and not interesting, it can be found at
http://kernel.ebshome.net/emac/05-remove_old_ibm_emac.diff
^ permalink raw reply
* [PATCH 2/2] New PowerPC 4xx on-chip ethernet controller driver
From: Eugene Surovegin @ 2005-08-31 5:01 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20050831050048.GB17017@gate.ebshome.net>
Add new PPC 4xx NAPI EMAC driver
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
drivers/net/Kconfig | 70 +
drivers/net/ibm_emac/Makefile | 11
drivers/net/ibm_emac/ibm_emac.h | 309 +++++
drivers/net/ibm_emac/ibm_emac_core.c | 2248 +++++++++++++++++++++++++++++++++
drivers/net/ibm_emac/ibm_emac_core.h | 221 +++
drivers/net/ibm_emac/ibm_emac_debug.c | 213 +++
drivers/net/ibm_emac/ibm_emac_debug.h | 63 +
drivers/net/ibm_emac/ibm_emac_mal.c | 584 +++++++++
drivers/net/ibm_emac/ibm_emac_mal.h | 267 ++++
drivers/net/ibm_emac/ibm_emac_phy.c | 355 +++++
drivers/net/ibm_emac/ibm_emac_phy.h | 80 +
drivers/net/ibm_emac/ibm_emac_rgmii.c | 202 +++
drivers/net/ibm_emac/ibm_emac_rgmii.h | 65 +
drivers/net/ibm_emac/ibm_emac_tah.c | 111 ++
drivers/net/ibm_emac/ibm_emac_tah.h | 88 +
drivers/net/ibm_emac/ibm_emac_zmii.c | 256 ++++
drivers/net/ibm_emac/ibm_emac_zmii.h | 83 +
17 files changed, 5226 insertions(+), 0 deletions(-)
Patch is quite big (146K) and can be found at
http://kernel.ebshome.net/emac/06-add_napi_ibm_emac.diff
I can post it to the mail list for discussion, just let me know.
^ permalink raw reply
* Re: Marvell MV6436xx ethernet driver patch
From: Nicolas DET @ 2005-08-31 6:55 UTC (permalink / raw)
To: Dale Farnsworth, linuxppc-dev
In-Reply-To: <20050830233205.GB24345@xyzzy.farnsworth.org>
Hello Dale,
On 31/08/2005, you wrote:
> On Tue, Aug 30, 2005 at 08:16:12PM +0100, Nicolas DET wrote:
>> You can find enclosed a patch for the Marvell MV643xx ethernet driver.
>>
>> It's also there:
>> http://arrakin.homedns.org/~nicolas/mv643xx_eth.tar.gz (tarball)
>> http://arrakin.homedns.org/~nicolas/mv643xx_eth.diff.bz2
>>
>> The diff is against the kernel 2.6.13 (kernel.org).
> Thank you for working on this driver, Nicolas.
It was very fun and interresting :-)
I wish I could spend more time, however I won't be able to this week ;-/.
>> The main changes (AFAIR):
>> * Workaround for the TCP/UDP hw checksum
> I implemented something similar a while back, but found it too ugly to
> keep around. Fortunately, there is already a much simpler workaround for
> the hw checksum bug in linux-2.6.git. See
> http://oss.sgi.com/archives/netdev/2005-08/msg00124.html
Ok.
>> * Define and use SRAM (for pegasos II archp/ppc/chrp_pegasos_eth.c)
> Good. This is pegasos-specific and it would be good to split this
> patch out from the mv643xx driver bits. Descriptors in SRAM is a big
> win.
>> * Able to use max burst size from/to DDR (serious transfer boost)
> This is a good idea. I suspect that most of the gain is from
> turning off snooping and flushing/invalidating the cache explicitly.
> Implementation-wise, I'd rather we not manipulate the MV643XX_ETH_BAR_?
> registers directly in the driver. Today that is done in platform
> setup code. This has promise but needs to be reworked.
Yeah, the point was to have no snooping for this part of the chip.
The descriptors in SRAM, and the data in DDR. This give a serious boost.
I noticed MV643xx memory performances are really higher when turning
off snoop (not only for ethernet).
Well, I confess manipulating such thing here, is not totaly smart.
However I don't really know where to put them.
Maybe, somewhere in arch/ppc ?
Because, at some pooint the driver will need to have this modified in order
to reall work correctly.
For example, if you use a module with that option (it will disable
snooping) and then 'rmmod & modprobe' a new module without it will not work
(no snooping as the new module expect!).
Conclusion: yes, touching ETH_BAR isn't really well here, but where could
we move it ?
>> * Option can be selected through the menu (drivers/net/Kconfig)
> Do these really need to be user configurable?
> The following shouldn't be user options, IMHO:
> MV643XX_CHECKSUM_OFFLOAD_TX -- on
> MV643XX_CHECKSUM_OFFLOAD_TX_WORKAROUND -- on
> MV64XXX_HWSTATS -- on
> MV643XX_COAL -- on
> MV64XXX_USESRAM -- on/off depending on platform
> MV64XXX_MAXBURST -- on/off depending on platform
Ok. It can easily go back into the .h
> I'm not as sure about MV643XX_NAPI, but I think it should always be on
> for GigE drivers. Is it worth being able to turn off NAPI?
I'm really not sure. I also though NAPI should always be turned on.
Nevertheless, I noticed the CPU usage is really highy with NAPI on than
off. Maybe, NAPI doesn't like too much interrupt coalescing.
> Some general comments:
> Several Kconfig hunks seem unrelated to MV643XX
> Several lines in the patch have trailing whitespace.
> C++ style comments (//) aren't acceptable.
> Why the addition of EXTRA_BYTES to the definition of RX_SKB_SIZE? Did
> you see problems without it?
Thanks a lot for this comments!
I confess eassily,, I'm not use to submit patch and to the kernel code
rules.
So, you advices are welcome.
Do you want me to clean the patch ? or something ?
I'm not sure I could, I'll be away from thursday to the next friday at
least.
Regards
--
Nicolas DET
MorphOS & Linux developer
^ permalink raw reply
* [PATCH] Ethtool support for the new PowerPC 4xx on-chip ethernet controller driver
From: Eugene Surovegin @ 2005-08-31 6:24 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
Jeff,
this patch adds PPC4xx EMAC support to Ethtool. Patch was generated
against your Ethtool BK repo - I haven't found anything more recent.
Let me know if you have gkernel GIT repository somewhere and I'll redo
the patch if needed.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
diff -Nru a/Makefile.am b/Makefile.am
--- a/Makefile.am 2005-03-23 01:20:59 -08:00
+++ b/Makefile.am 2005-03-23 01:20:59 -08:00
@@ -6,7 +6,7 @@
sbin_PROGRAMS = ethtool
ethtool_SOURCES = de2104x.c ethtool.c ethtool-copy.h ethtool-util.h natsemi.c \
e1000.c realtek.c e100.c tg3.c amd8111e.c pcnet32.c \
- fec_8xx.c ixgb.c skge.c
+ fec_8xx.c ibm_emac.c ixgb.c skge.c
dist-hook:
cp $(top_srcdir)/ethtool.spec $(distdir)
diff -Nru a/ethtool-util.h b/ethtool-util.h
--- a/ethtool-util.h 2005-03-23 01:20:59 -08:00
+++ b/ethtool-util.h 2005-03-23 01:20:59 -08:00
@@ -45,4 +45,7 @@
/* SysKonnect Gigabit Yukon Family */
int skge_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs);
+/* PowerPC 4xx on-chip Ethernet controller */
+int ibm_emac_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs);
+
#endif
diff -Nru a/ethtool.c b/ethtool.c
--- a/ethtool.c 2005-03-23 01:20:59 -08:00
+++ b/ethtool.c 2005-03-23 01:20:59 -08:00
@@ -1015,6 +1015,7 @@
{ "fec_8xx", fec_8xx_dump_regs },
{ "ixgb", ixgb_dump_regs },
{ "skge", skge_dump_regs },
+ { "ibm_emac", ibm_emac_dump_regs },
};
static int dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
diff -Nru a/ibm_emac.c b/ibm_emac.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/ibm_emac.c 2005-03-23 01:20:59 -08:00
@@ -0,0 +1,244 @@
+/*
+ * Copyright (c) 2004, 2005 Zultys Technologies
+ * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
+ */
+#include <stdio.h>
+#include <stdint.h>
+#include <stddef.h>
+
+#include "ethtool-util.h"
+
+/* Ethtool get_regs complex data.
+ * we want to get not just EMAC registers, but also MAL, ZMII, RGMII, TAH
+ * when available.
+ *
+ * Returned BLOB consists of the ibm_emac_ethtool_regs_hdr,
+ * MAL registers, EMAC registers and optional ZMII, RGMII, TAH registers.
+ * Each register component is preceded with emac_ethtool_regs_subhdr.
+ * Order of the optional headers follows their relative bit posititions
+ * in emac_ethtool_regs_hdr.components
+ */
+#define EMAC_ETHTOOL_REGS_ZMII 0x00000001
+#define EMAC_ETHTOOL_REGS_RGMII 0x00000002
+#define EMAC_ETHTOOL_REGS_TAH 0x00000004
+
+struct emac_ethtool_regs_hdr {
+ u32 components;
+};
+
+struct emac_ethtool_regs_subhdr {
+ u32 version;
+ u32 index;
+};
+
+struct emac_regs {
+ u32 mr0;
+ u32 mr1;
+ u32 tmr0;
+ u32 tmr1;
+ u32 rmr;
+ u32 isr;
+ u32 iser;
+ u32 iahr;
+ u32 ialr;
+ u32 vtpid;
+ u32 vtci;
+ u32 ptr;
+ u32 iaht1;
+ u32 iaht2;
+ u32 iaht3;
+ u32 iaht4;
+ u32 gaht1;
+ u32 gaht2;
+ u32 gaht3;
+ u32 gaht4;
+ u32 lsah;
+ u32 lsal;
+ u32 ipgvr;
+ u32 stacr;
+ u32 trtr;
+ u32 rwmr;
+ u32 octx;
+ u32 ocrx;
+ u32 ipcr;
+};
+
+struct mal_regs {
+ u32 tx_count;
+ u32 rx_count;
+
+ u32 cfg;
+ u32 esr;
+ u32 ier;
+ u32 tx_casr;
+ u32 tx_carr;
+ u32 tx_eobisr;
+ u32 tx_deir;
+ u32 rx_casr;
+ u32 rx_carr;
+ u32 rx_eobisr;
+ u32 rx_deir;
+ u32 tx_ctpr[32];
+ u32 rx_ctpr[32];
+ u32 rcbs[32];
+};
+
+struct zmii_regs {
+ u32 fer;
+ u32 ssr;
+ u32 smiisr;
+};
+
+struct rgmii_regs {
+ u32 fer;
+ u32 ssr;
+};
+
+struct tah_regs {
+ u32 revid;
+ u32 pad[3];
+ u32 mr;
+ u32 ssr0;
+ u32 ssr1;
+ u32 ssr2;
+ u32 ssr3;
+ u32 ssr4;
+ u32 ssr5;
+ u32 tsr;
+};
+
+static void *print_emac_regs(void *buf)
+{
+ struct emac_ethtool_regs_subhdr *hdr = buf;
+ struct emac_regs *p = (struct emac_regs *)(hdr + 1);
+ void *res = p + 1;
+
+ printf("EMAC%d Registers\n", hdr->index);
+ printf("-----------------\n");
+ printf("MR0 = 0x%08x MR1 = 0x%08x RMR = 0x%08x\n"
+ "ISR = 0x%08x ISER = 0x%08x\n"
+ "TMR0 = 0x%08x TMR1 = 0x%08x\n"
+ "TRTR = 0x%08x RWMR = 0x%08x\n"
+ "IAR = %04x%08x\n"
+ "LSA = %04x%08x\n"
+ "IAHT = 0x%04x 0x%04x 0x%04x 0x%04x\n"
+ "GAHT = 0x%04x 0x%04x 0x%04x 0x%04x\n"
+ "VTPID = 0x%04x VTCI = 0x%04x\n"
+ "IPGVR = 0x%04x STACR = 0x%08x\n"
+ "OCTX = 0x%08x OCRX = 0x%08x\n",
+ p->mr0, p->mr1, p->rmr,
+ p->isr, p->iser,
+ p->tmr0, p->tmr1,
+ p->trtr, p->rwmr,
+ p->iahr, p->ialr,
+ p->lsah, p->lsal,
+ p->iaht1, p->iaht2, p->iaht3, p->iaht4,
+ p->gaht1, p->gaht2, p->gaht3, p->gaht4,
+ p->vtpid, p->vtci, p->ipgvr, p->stacr, p->octx, p->ocrx);
+
+ if (hdr->version)
+ printf(" IPCR = 0x%08x\n\n", p->ipcr);
+ else {
+ printf("\n\n");
+ res -= sizeof(u32);
+ }
+ return res;
+}
+
+static void *print_mal_regs(void *buf)
+{
+ struct emac_ethtool_regs_subhdr *hdr = buf;
+ struct mal_regs *p = (struct mal_regs *)(hdr + 1);
+ int i;
+
+ printf("MAL%d Registers\n", hdr->index);
+ printf("-----------------\n");
+ printf("CFG = 0x%08x ESR = 0x%08x IER = 0x%08x\n"
+ "TX|CASR = 0x%08x CARR = 0x%08x EOBISR = 0x%08x DEIR = 0x%08x\n"
+ "RX|CASR = 0x%08x CARR = 0x%08x EOBISR = 0x%08x DEIR = 0x%08x\n",
+ p->cfg, p->esr, p->ier,
+ p->tx_casr, p->tx_carr, p->tx_eobisr, p->tx_deir,
+ p->rx_casr, p->rx_carr, p->rx_eobisr, p->rx_deir);
+
+ printf("TX|");
+ for (i = 0; i < p->tx_count; ++i) {
+ if (i && !(i % 4))
+ printf("\n ");
+ printf("CTP%d = 0x%08x ", i, p->tx_ctpr[i]);
+ }
+ printf("\nRX|");
+ for (i = 0; i < p->rx_count; ++i) {
+ if (i && !(i % 4))
+ printf("\n ");
+ printf("CTP%d = 0x%08x ", i, p->rx_ctpr[i]);
+ }
+ printf("\n ");
+ for (i = 0; i < p->rx_count; ++i) {
+ u32 r = p->rcbs[i];
+ if (i && !(i % 3))
+ printf("\n ");
+ printf("RCBS%d = 0x%08x (%d) ", i, r, r * 16);
+ }
+ printf("\n\n");
+ return p + 1;
+}
+
+static void *print_zmii_regs(void *buf)
+{
+ struct emac_ethtool_regs_subhdr *hdr = buf;
+ struct zmii_regs *p = (struct zmii_regs *)(hdr + 1);
+
+ printf("ZMII%d Registers\n", hdr->index);
+ printf("-----------------\n");
+ printf("FER = %08x SSR = %08x\n"
+ "SMIISR = %08x\n\n", p->fer, p->ssr, p->smiisr);
+
+ return p + 1;
+}
+
+static void *print_rgmii_regs(void *buf)
+{
+ struct emac_ethtool_regs_subhdr *hdr = buf;
+ struct rgmii_regs *p = (struct rgmii_regs *)(hdr + 1);
+
+ printf("RGMII%d Registers\n", hdr->index);
+ printf("-----------------\n");
+ printf("FER = %08x SSR = %08x\n\n", p->fer, p->ssr);
+
+ return p + 1;
+}
+
+static void *print_tah_regs(void *buf)
+{
+ struct emac_ethtool_regs_subhdr *hdr = buf;
+ struct tah_regs *p = (struct tah_regs *)(hdr + 1);
+
+ printf("TAH%d Registers\n", hdr->index);
+ printf("-----------------\n");
+
+ printf("REVID = %08x MR = %08x TSR = %08x\n"
+ "SSR0 = %08x SSR1 = %08x SSR2 = %08x\n"
+ "SSR3 = %08x SSR4 = %08x SSR5 = %08x\n\n",
+ p->revid, p->mr, p->tsr,
+ p->ssr0, p->ssr1, p->ssr2, p->ssr3, p->ssr4, p->ssr5);
+
+ return p + 1;
+}
+
+int ibm_emac_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
+{
+ struct emac_ethtool_regs_hdr *hdr =
+ (struct emac_ethtool_regs_hdr *)regs->data;
+ void *buf = hdr + 1;
+
+ buf = print_mal_regs(buf);
+ buf = print_emac_regs(buf);
+ if (hdr->components & EMAC_ETHTOOL_REGS_ZMII)
+ buf = print_zmii_regs(buf);
+ if (hdr->components & EMAC_ETHTOOL_REGS_RGMII)
+ buf = print_rgmii_regs(buf);
+ if (hdr->components & EMAC_ETHTOOL_REGS_TAH)
+ print_tah_regs(buf);
+
+ return 0;
+}
^ permalink raw reply
* Re: Question about SMC serial port on MPC8270 in u-boot
From: Wolfgang Denk @ 2005-08-31 7:03 UTC (permalink / raw)
To: FCG WANG Baohua; +Cc: Jack_liu, Tsi-Chung.Liew, linuxppc-embedded
In-Reply-To: <A9DE2BAF233E444FA9C5E77A5825A01E865067@ydmail.sbell.com.cn>
In message <A9DE2BAF233E444FA9C5E77A5825A01E865067@ydmail.sbell.com.cn> you wrote:
>
> When i port the u-boot 1.1.3 on my MPC8270 board, the serial port has
Your question is off topic on this list. Please send U-Boot related
questions to the u-boot-users list instead.
> 1. the Dual port ram cannot be revised manually, but can be revised by
> the u-boot code. What's the problem?
You're doing something wrong.
> 2. the serial_putc() in serial_smc.c is loop forever on "while
> (tbdf->cbd_sc & BD_SC_READY);". How to slove the bug?
Make sure your clocks / BRG's are configured correctly.
> 3. the speed.c calc the wrong cpm, cpu, brg_clk, I had hard coded the
> right cpm, cpu, brg_clk values. But the "m8260_cpm_setbrg()" is still
> wrong? Why?
Your system is misconfigured.
> data structures, they all seems right, but the UART cannot work.
> How could I find the problem?
Fix the problems as you encounter them. If the clocks show up wrong
you should fix this problem first. Then all the rest might just fall
into place.
> Content-Type: text/html;
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
And please don't post HTML.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A meeting is an event at which the minutes are kept and the hours are
lost.
^ permalink raw reply
* linux kernel does not bring up!!
From: lily @ 2005-08-31 7:05 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 5477 bytes --]
hi,everybody:
I am a new to embeded linux,my work is to port linux on powerpc , the board i uses is octobusHPPC405EP .when I power on the board it prints the boot message in minicom as follows :
U-Boot 1.1.2 (Jun 3 2005 - 12:05:48)
CPU: IBM PowerPC 405EP Rev. B at 133.333 MHz (PLB=133, OPB=66, EBC=33 MHz)
IIC Boot EEPROM disabled
PCI async ext clock used, internal PCI arbiter enabled
16 kB I-Cache 16 kB D-Cache
OCTOBUS Board: ### No HW ID - assuming OCTOBUS HPPC405
I2C: ready
DRAM: 32 MB
FLASH: 4 MB
Hit any key to stop autoboot: 0
## Booting image at ffc00000 ...
Image Name: Linux-2.4.21-pre5
Created: 2005-06-09 13:24:37 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 550124 Bytes = 537.2 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at ffd00000 ...
Image Name: PPCLinux Ramdisk Image
Created: 2005-06-16 9:15:17 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1732209 Bytes = 1.7 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 01def000, end 01f95e71 ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:mapin_ram done
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
arch:exit
then the system hang .one time the message have difference like:
U-Boot 1.1.2 (Jun 3 2005 - 12:05:48)
CPU: IBM PowerPC 405EP Rev. B at 133.333 MHz (PLB=133, OPB=66, EBC=33 MHz)
IIC Boot EEPROM disabled
PCI async ext clock used, internal PCI arbiter enabled
16 kB I-Cache 16 kB D-Cache
OCTOBUS Board: ### No HW ID - assuming OCTOBUS HPPC405
I2C: ready
DRAM: 32 MB
FLASH: 4 MB
Hit any key to stop autoboot: 0
## Booting image at ffc00000 ...
Image Name: Linux-2.4.21-pre5
Created: 2005-06-09 13:24:37 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 550124 Bytes = 537.2 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at ffd00000 ...
Image Name: PPCLinux Ramdisk Image
Created: 2005-06-16 9:15:17 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1732209 Bytes = 1.7 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 01def000, end 01f95e71 ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:mapin_ram done
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
arch:exit
Linux version 2.4.21-pre5 (tzn@linux-tzn) (gcc version 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a_1)) #1 Do Jun 9 15:21:40 CEST 2005
DAVE Srl PPChameleonEVB port (C) 2003 DAVE Srl (info@wawnet.biz)
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/ram rw ip=192.168.1.2:::255.255.255.0::eth0:off console=ttyS0,115200
Calibrating delay loop... 133.12 BogoMIPS
Memory: 29264k available (1004k kernel code, 324k data, 76k init, 0k highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
OCP uart ver 1.6.2 init complete
Starting kswapd
i2c-core.o: i2c core module
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0xef600300 (irq = 0) is a 16550A
ttyS01 at 0xef600400 (irq = 1) is a 16550A
PPC 405 watchdog driver v0.6
IBM gpio driver version 07.25.02
GPIO #0 at 0xc3000700
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
eth0: Phy @ 0x1, type STE100P (0x1c040011)
Reset ethernet interfaces
eth1: No PHY device found.
removing net dev
IBM IIC driver
i2c-core.o: adapter IBM IIC adapter registered as adapter 0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
eth0: IBM EMAC: link up, 100 Mbps Half Duplex.
eth0: IBM EMAC: MAC 00:50:c2:1e:af:fe.
eth0: IBM EMAC: open completed
IP-Config: Complete:
device=eth0, addr=192.168.1.2, mask=255.255.255.0, gw=255.255.255.255,
host=192.168.1.2, domain=, nis-domain=(none),
bootserver=255.255.255.255, rootserver=255.255.255.255, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1691k freed
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 76k init
init started: BusyBox v0.60.5 (2005.06.06-14:19+0000) multi-call binary
rm: cannot remove `/www/log/seriald_started.log': No such file or directory
but this message just print once ,what's the problem with the board ,does it destroy？
there is somebody give me some suggestion what i do next.Thanks !!
[-- Attachment #2: Type: text/html, Size: 7896 bytes --]
^ permalink raw reply
* how to link .o
From: zhonglei @ 2005-08-31 7:58 UTC (permalink / raw)
To: linuxppc-embedded
hi
In my module htm.c , I use the a set of API function in bestcomm.o.
I include the bestcomm.h in htm.c and in makefile I write:
ppc_82xx-gcc -c htm.c .
when I insmod htm.o , the "unresolved symbol" error happens because there is no definition of the function.
My question is:
What command should I write in makefile to link the bestcomm.o into my htm.o to make the function defined?
BestRegards
zhonglei
^ permalink raw reply
* ??: Question about SMC serial port on MPC8270 in u-boot
From: FCG WANG Baohua @ 2005-08-31 8:51 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
Dear Denk:
thanks a lot ! I had found the reason: I use brg7 instead of brg1 in =
code, but the hardware is use brg1 to UART.=20
Now the UART can work. But another question comes :
The u-Boot reboot forever when enter
" *((ulong *) addr_sp)-- =3D 0;
*((ulong *) addr_sp)-- =3D 0; "
The code is in lib_ppc/board.c line 474-475,function board_init_f. =
I found the pointer addr_sp is valid.
I erase the *((ulong *) addr_sp)-- =3D 0 code, but no use.
What's the prblem? can you give me some hints ? thanks !
=20
-----????-----
???: wd@denx.de [mailto:wd@denx.de]
????: 2005?8?31? 15:04
???: FCG WANG Baohua
??: linuxppc-embedded@ozlabs.org; wd@denx.de; =
Tsi-Chung.Liew@freescale.com; jdl@freescale.com; Jack_liu@usish.com
??: Re: Question about SMC serial port on MPC8270 in u-boot=20
In message <A9DE2BAF233E444FA9C5E77A5825A01E865067@ydmail.sbell.com.cn> =
you wrote:
>=20
> When i port the u-boot 1.1.3 on my MPC8270 board, the serial port has
Your question is off topic on this list. Please send U-Boot related
questions to the u-boot-users list instead.
> 1. the Dual port ram cannot be revised manually, but can be revised =
by
> the u-boot code. What's the problem?
You're doing something wrong.
> 2. the serial_putc() in serial_smc.c is loop forever on "while
> (tbdf->cbd_sc & BD_SC_READY);". How to slove the bug?
Make sure your clocks / BRG's are configured correctly.
> 3. the speed.c calc the wrong cpm, cpu, brg_clk, I had hard coded =
the
> right cpm, cpu, brg_clk values. But the "m8260_cpm_setbrg()" is =
still
> wrong? Why?
Your system is misconfigured.
> data structures, they all seems right, but the UART cannot =
work.
> How could I find the problem?=20
Fix the problems as you encounter them. If the clocks show up wrong
you should fix this problem first. Then all the rest might just fall
into place.
> Content-Type: text/html;
> Content-Transfer-Encoding: quoted-printable
>=20
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
And please don't post HTML.
Best regards,
Wolfgang Denk
--=20
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A meeting is an event at which the minutes are kept and the hours are
lost.
^ permalink raw reply
* Re: linux kernel does not bring up!!
From: Alex Zeffertt @ 2005-08-31 8:58 UTC (permalink / raw)
To: lily; +Cc: linuxppc-embedded
In-Reply-To: <325470355.17275@st.lzu.edu.cn>
> VFS: Mounted root (ext2 filesystem).
> Freeing unused kernel memory: 76k init
> init started: BusyBox v0.60.5 (2005.06.06-14:19+0000) multi-call binary
> rm: cannot remove `/www/log/seriald_started.log': No such file or directo=
ry
>=20
> but this message just print once ,what's the problem with the board ,does=
it destroy
^ permalink raw reply
* Re: linux kernel does not bring up!!
From: Alex Zeffertt @ 2005-08-31 9:03 UTC (permalink / raw)
To: lily; +Cc: linuxppc-embedded
In-Reply-To: <325470355.17275@st.lzu.edu.cn>
On Wed, 31 Aug 2005 15:05:24 +0800
"lily" <lichanjuan04@st.lzu.edu.cn> wrote:
> ET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> RAMDISK: Compressed image found at block 0
> Freeing initrd memory: 1691k freed
> VFS: Mounted root (ext2 filesystem).
> Freeing unused kernel memory: 76k init
> init started: BusyBox v0.60.5 (2005.06.06-14:19+0000) multi-call binary
> rm: cannot remove `/www/log/seriald_started.log': No such file or directory
>
> but this message just print once ,what's the problem with the board ,does it destroy
> there is somebody give me some suggestion what i do next.Thanks !!
This question is off topic here.
You need to read "man init" and "man inittab" and your /etc/inittab to find out which startup
scripts are being called. You can then find the script which is attempting to remove the
nonexistent file, and fix it (e.g. by using rm -f instead).
This list cannot help any further as this is not related to the PPC port of linux.
Alex
^ permalink raw reply
* Did anybody use netatalk on ppc??
From: JohnsonCheng @ 2005-08-31 9:08 UTC (permalink / raw)
To: linux-ppc-embedded
[-- Attachment #1: Type: text/plain, Size: 286 bytes --]
Dear All,
I have used netatalk2.0.3 with Unicode on x86, it's no problem.
Then I port it to ppc board, compiler is OK and also can running.
Unfortunately, I have trouble on Unicode issue, I found it doesn't work.
Does someone give me some advice??
Thanks,
Johnson Cheng
[-- Attachment #2: Type: text/html, Size: 3272 bytes --]
^ permalink raw reply
* Re: Marvell MV6436xx ethernet driver patch
From: Sven Luther @ 2005-08-31 9:47 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev
In-Reply-To: <20050831055934.871E41C00097@mwinf1107.wanadoo.fr>
On Wed, Aug 31, 2005 at 07:55:49AM +0100, Nicolas DET wrote:
> Hello Dale,
> > This is a good idea. I suspect that most of the gain is from
> > turning off snooping and flushing/invalidating the cache explicitly.
> > Implementation-wise, I'd rather we not manipulate the MV643XX_ETH_BAR_?
> > registers directly in the driver. Today that is done in platform
> > setup code. This has promise but needs to be reworked.
>
> Conclusion: yes, touching ETH_BAR isn't really well here, but where could
> we move it ?
What about : arch/ppc/plateform/chrp_pegasos_eth.c ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: Add cputable entry for 750CXe DD2.4
From: Nicolas DET @ 2005-08-31 11:40 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-dev
Hello,
>This adds a cputable entry for 750CXe DD2.4, as found in the
>GameCube from Nintendo. To be correctly enumerated, however,
>the table has to be slightly re-ordered first.
There is also this patch:
http://ozlabs.org/pipermail/linuxppc-dev/attachments/20050601/557155f7/patch_750CXe_2.6.obj
It add support for the 750CXe rev 3.1.
Maybe we could merge both and get them into the main stream ?
Regards,
--
Nicolas DET
MorphOS & Linux developer
^ permalink raw reply
* Export assembly symbols
From: Garcia Jérémie @ 2005-08-31 12:35 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody, I need your help again.
I'm desesperatly tryin to insert some new assembly code in the
linux montavista sources PE 3.1 for a ppc 405EP.=20
What I'd like to do is to have, in my kernel source file "myfile.S", two
assembly functions and export those symbols to the ksyms table.
The final point for me is to make those symbols availabale for
modules loading.
The functions definition in "myfile.S" is the one below:
/*
myfile.S : DESCRIPTION
This module contains chip-dependent routines written in assembly =
language.
*/
#include <linux/config.h>
#include <linux/sys.h>
#include <linux/threads.h>
#include <asm/processor.h>
#include <asm/page.h>
#include <asm/mmu.h>
#include <asm/cputable.h>
#include <asm/ppc_asm.h>
#include <asm/errno.h>
#include <asm/ppc_asm.h>
#include "myfile.h"
=20
#define _ASMLANGUAGE
=20
.globl stas_Read_TBl_F
.globl stas_Set_TBl_F
.text
=
/************************************************************************=
******
* stas_Read_TBl_F : This function returns the content of TBL.
* uLong stas_Read_TBl_F(void)
=
*************************************************************************=
*****/
_GLOBAL(stas_Read_TBl_F)
mftb r3
nop
nop
nop
blr
=
/************************************************************************=
******
* stas_Set_TBl_F : This function is used to set the TBL.=20
* void stas_Set_TBl_F(uLong)
=
*************************************************************************=
*****/
_GLOBAL(stas_Set_TBl_F)
mttbl r3
nop
nop
nop
blr
Due to a modified Linux Makefile, it is compiled by the kernel with this =
command line:
ppc_405-gcc -D__ASSEMBLY__ -D__KERNEL__ =
-I/myWorks/en-cours/linux-2.4.20_mvl31/include [...]
-I/myWorks/en-cours/linux-2.4.20_mvl31/arch/ppc -Wa,-m405 -c -o =
myfile.o myfile.S
What do I have to do to get both functions in the symbols table when =
reading/proc/ksyms.
Is there a specific way to do for ppc?=20
Please help me cause I can't finf any info on that browsing the web.
Tks a lot for your precious help
J=E9r=E9mie
^ permalink raw reply
* Platform devices on MPC8245
From: Mark Brown @ 2005-08-31 12:26 UTC (permalink / raw)
To: linuxppc-embedded
I'm having some trouble using the platform device support for the
MPC8245 using memory map B, set up using mpc10x_bridge_init(). When
that function registers the host bridge it registers addresses
0x80000000-0xfebfffff for the bridge but by default (with EUMB mapped to
MPC10X_MAPB_EUMB_BASE) the platform devices on the chip are also within
this address range. The problem I'm seeing is that when
platform_device_register() comes to call request_resource() on the
devices that call fails because the addresses have already been
allocated to the PCI host bridge.
I'm sure I must be missing something really obvious about how this is
supposed to work but I can't for the life of me see what. Changing the
platform code to use insert_resource() rather than request_resource()
allows the devices to register and be used but that seems rather too
drastic to be it.
Thanks for any help.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
^ 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