How to limit the log file size?
Hi all: There are some daemon like snmpd, boa...has log file at directory var, I want to know how to limte it's file size? Best Regards, Rober Hsu
[PATCH] ppc32: Fix configuration of PCI IO space on MPC85xx platform
For platforms that don't have PCI IO at 0 the outbound window registers were not being properly configured. Signed-off-by: Andrew Klossner andrew at cesa.opbu.xerox.com Signed-off-by: Kumar K. Gala kumar.gala at freescale.com --- commit 7b992aef26bd7dc2ed3eea0554d3e901d17aa999 tree a39f664767dbb49df981ed2037b7921f982a7854 parent db1488b812a7a96d50d51b018fbeb20586cc8e84 author Kumar K. Gala kumar.gala at freescale.com Wed, 21 Sep 2005 23:53:25 -0500 committer Kumar K. Gala kumar.gala at freescale.com Wed, 21 Sep 2005 23:53:25 -0500 arch/ppc/syslib/ppc85xx_setup.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/ppc/syslib/ppc85xx_setup.c b/arch/ppc/syslib/ppc85xx_setup.c --- a/arch/ppc/syslib/ppc85xx_setup.c +++ b/arch/ppc/syslib/ppc85xx_setup.c @@ -184,8 +184,8 @@ mpc85xx_setup_pci1(struct pci_controller pci-powar1 = 0x80044000 | (__ilog2(MPC85XX_PCI1_UPPER_MEM - MPC85XX_PCI1_LOWER_MEM + 1) - 1); - /* Setup outboud IO windows @ MPC85XX_PCI1_IO_BASE */ - pci-potar2 = 0x; + /* Setup outbound IO windows @ MPC85XX_PCI1_IO_BASE */ + pci-potar2 = (MPC85XX_PCI1_LOWER_IO 12) 0x000f; pci-potear2 = 0x; pci-powbar2 = (MPC85XX_PCI1_IO_BASE 12) 0x000f; /* Enable, IO R/W */ @@ -235,8 +235,8 @@ mpc85xx_setup_pci2(struct pci_controller pci-powar1 = 0x80044000 | (__ilog2(MPC85XX_PCI2_UPPER_MEM - MPC85XX_PCI2_LOWER_MEM + 1) - 1); - /* Setup outboud IO windows @ MPC85XX_PCI2_IO_BASE */ - pci-potar2 = 0x; + /* Setup outbound IO windows @ MPC85XX_PCI2_IO_BASE */ + pci-potar2 = (MPC85XX_PCI2_LOWER_IO 12) 0x000f;; pci-potear2 = 0x; pci-powbar2 = (MPC85XX_PCI2_IO_BASE 12) 0x000f; /* Enable, IO R/W */
CPM2 early console
Hello, I'm trying to get vanilla 2.6.13.1 running on an EP8248 board without much success. I created my own platform files and have the kernel booting, but the execution is permanently stuck in the cpm_uart_console_write() function in the first while ((bdp-cbd_sc BD_SC_READY) != 0) statement. I don't have any COP debugger for this processor family, so the only debugging aid is the two leds onboard... It's clear that the buffer descriptor is not in sync with the CPM, but I have no clue what the address of the buffer descriptor is. It seems this code is rather new, and I'm wondering if any of you have some patches that are not in the mainline kernel yet. Has anyone tested this with a 8248 processor? If so, could you please send your .config to me in case I made some errors in the platform definition.
Bamboo Products
An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050922/0f6df55c/attachment.htm
using SCC4 on MPC8272ADS
I am now using kernel 2.6.10.2 on the MPC8272ADS. I still have problems using the second SCC port (SCC4). If I do the following (assuming after configuring SCC4 to behave like SCC1 w/baud rate, etc using tcgetattr and tcsetattr): echo hello hhh echo hello hhh echo hello hhh more hhh /dev/ttyCPM1 then it works fine and I see the three lines of hello on the second port. But if I do: echo hello hhh echo hello hhh more hhh /dev/ttyCPM1 (i.e., only two lines of hello in hhh) then the system hangs. -Original Message- From: Vitaly Bordug [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 21, 2005 3:01 PM To: Landau, Bracha Subject: Re: using SCC4 on MPC8272ADS Landau, Bracha wrote: Which version has the fix? 2-6-10-rc7? Where can I find it? http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.2.tar.bz2 2.6.13.rc7 should have the fix. -Original Message- From: Vitaly Bordug [mailto:vbordug at ru.mvista.com] Sent: Wednesday, September 21, 2005 2:40 PM To: Landau, Bracha Cc: linuxppc-embedded list Subject: Re: using SCC4 on MPC8272ADS Landau, Bracha wrote: I reconfigured the kernel so that only SCC1 and SCC4 are supported. The same thing happens as before. Another bit of info is that if I run with console=ttyCPM1 as a kernel command line parameter, so that u-boot outputs to one port and the kernel outputs to the other, if I type ls /dev/ttyCPM0 the system hangs. Heh, didn't noticed, that you should use the latest rc of the linux kernel. I used to fix second UART in rc7 AFAIR. -Original Message- From: Vitaly Bordug [mailto:vbordug at ru.mvista.com] Sent: Wednesday, September 21, 2005 1:56 PM To: Landau, Bracha Cc: linuxppc-embedded at ozlabs.org Subject: Re: using SCC4 on MPC8272ADS Landau, Bracha wrote: I am using the MPC8272ADS with kernel 2.6.10. The kernel is configured to support 4 CPM SCCs, of which 1 and 4 are connected on the board. I created device files as follows: mknod /dev/ttyCPM0 c 204 46 mknod /dev/ttyCPM1 c 204 47 mknod /dev/ttyCPM2 c 204 48 mknod /dev/ttyCPM3 c 204 49 If I boot the kernel using console=ttyCPM3 I see that it uses SCC4. But when I boot with console=ttyCPM0 and write to the second port using a command like echo hello /dev/ttyCPM3 I don't see that anything is being outputted to the second console. What am I doing wrong? Funny - you said that SCC 1 and 4 are connected to the board; than why you are enabling SCC2 and SCC3? This board does have 2 SCCs assigned for UARTs. No need to configure SCC2 and SCC3 - this is useless and may lead to kernel crash. This board will use in the correct configuration /dev/ttyCPM0 SCC1 and /dev/ttyCPM1 SCC4. -- Sincerely, Vitaly *** Information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster at nds.com and destroy the original message. ***
CPM2 early console
There is a bug in the SMC init code, wher the base address for the SMC's is not reinitialized by the kernel, so if the SMC is not initialized by the bootloader, it will not work. If that is the case, try this patch. -Original Message- From: Rune Torgersen Sent: Tuesday, August 23, 2005 15:19 To: linuxppc-embedded at ozlabs.org Subject: [PATCH] ppc32: Fix baseaddress for SMC 1 and 2 Base addess register for SMC 1 and 2 are never initialized. This means that they will not work unless a bootloader already configured them. The DPRAM already have space reserved, this patch just makes sure the base addess register is updated correctly on initialization. Signed-off-by: Rune Torgersen runet at innovsys.com -- next part -- A non-text attachment was scrubbed... Name: smc_baseparam.patch Type: application/octet-stream Size: 1065 bytes Desc: smc_baseparam.patch Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050922/434d700b/attachment.obj
CPM2 early console
Rune's patch should be in 2.6.14-rc1 or greater. - kumar On Sep 22, 2005, at 11:02 AM, Rune Torgersen wrote: There is a bug in the SMC init code, wher the base address for the SMC's is not reinitialized by the kernel, so if the SMC is not initialized by the bootloader, it will not work. If that is the case, try this patch. -Original Message- From: Rune Torgersen Sent: Tuesday, August 23, 2005 15:19 To: linuxppc-embedded at ozlabs.org Subject: [PATCH] ppc32: Fix baseaddress for SMC 1 and 2 Base addess register for SMC 1 and 2 are never initialized. This means that they will not work unless a bootloader already configured them. The DPRAM already have space reserved, this patch just makes sure the base addess register is updated correctly on initialization. Signed-off-by: Rune Torgersen runet at innovsys.com smc_baseparam.patch ATT296548.txt
Slow read performance of NAND flash on PPC 405EP
Andy Hawkins wrote:
Hi,
We have a custom PPC-405EP based board, with a Samsumg 8Gbit flash
(K9W8G08U1M) attached via EBC bank 2. When we read from this flash, we are
only getting data rates of around 20 MBits/sec (this is using 'dd' to read
direct from the linux /dev/mtd/x device). Our estimates show that the device
should be capable of something like 100 MBits/sec.
The EBC bank is set up as follows:
#define CFG_EBC_PB2AP 0x8a015480
#define CFG_EBC_PB2CR 0xFF458000 /*
BAS=0xFF4,BS=4MB,BU=R/W,BW=8bit */
The EBC bus is running at 54 MHz. We were originally running this bus at 27
MHz, and this speed increase doesn't appear to have done an awful lot for
us. By looking at the timings of various signals on an oscilloscope, we
adjusted the PB2AP register to that shown above, in an attempt to remove as
many of the wait states as possible.
It would be nice if you would break out the fields in the PB2AP control
word. This is what I came up with.
BME = 1, burst mode enabled
FWT = 2, 3 wait states
BWT = 4, 5 wait states
CSN = 0, 0 clock cycles before CS asserted
OEN = 1, 1 clock cycle before the PerOE is asserted
WBN = 1, 1 clock cycle delay until the first PerW line assertion after CS
WBF = 1, 1 clock cycle delay
TH = 2, 2 clock cycles in between each burst
RE = 0, PerREADY line disabled
SOR = 1, no effect
BME = 0
So you are reading things in burst mode. I have no experience doing
things in burst mode so I'm not going to be much help. I would look at
your timing diagrams again. Try changing the TH to 1 or 0 and see what
happens.
However, during a read, we are seeing that each byte read cycle takes around
220 nSec (this is taken between the times when the #PERCS2 line for the
device goes low). A significant portion (about 6 clock periods) of this
time, the device appears to be doing nothing (i.e. the chip select line is
inactive). The code in the linux kernel to read a page of data from the
flash is very simple:
static void nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
{
int i;
struct nand_chip *this = mtd-priv;
for (i=0; ilen; i++)
buf[i] = readb(this-IO_ADDR_R);
}
readb maps to a call to in_8(FLASH_BASE_ADDRESS). The in_8 function does
contain what appear to be un-necessary calls to twi and isync, but removing
these calls does not alter the cycle time significantly.
Is there some setup of the EBC (or other component in the processor) that we
have incorrect that could be affecting the throughput?
Any advice you can offer would be greatly appreciated.
Thanks
Andy
__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Good Luck
-- Conn Clark
*
Blessed be the heretic, for he causes some to think and unites
the rest against him.
*
Conn Clark
Engineering Assistantclark at esteem.com
Electronic Systems Technology Inc.www.esteem.com
Stock Ticker SymbolELST
squashfs on ppc
Thanks for the reply. I've built file system images based on ext2, cramfs and squashfs (2.1). Uncompressed ext2 image is about 12MB consisting mostly of busybox, other executables and shared libraries etc. Everything is stripped. cramfs based image took the least ram allocation but the most flash space (18% more than gzipped ext2 image). squashfs was close to cramfs in ram usage but was about equal to gzipped ext2 image. Thus, I have found squashfs based initrd to be good blance between ram and flash. Eugene Surovegin wrote: On Fri, Sep 16, 2005 at 04:48:09PM -0500, Tolunay Orkun wrote: Has anyone any positive or negative experience of using squashfs on PowerPC as initrd? Our environment is PowerPC 405GP running 2.4.31 kernel. U-Boot is our bootloader. Any comparison with respect to CramFS? I use squashfs and squashfs2. Both work just fine on PPC. They provide significantly better compression ration than cramfs, although at the expense of some speed (mostly visible during initial startup of big user-space app).
How to limit the log file size?
Hi Rober, On Wednesday 21 September 2005 23:07, EMAIL wrote: Hi all: There are some daemon like snmpd, boa...has log file at directory var, I want to know how to limte it's file size? I'm using emlog module (http://www.circlemud.org/~jelson/software/emlog/) to create circular buffers that are used as log files instead of regular ones. You can define the file size when it is created; runs smoothly and flawlessly. HTH, -- Ricardo Scop. \|/ ___ -*- (@ @)/|\ / V \| R SCOP Consult. /( )\ Linux-based communications --^^---^^+-- rscop at matrix.com.br +55 51 999-36-777 Porto Alegre, RS - BRazil -- P. S.: If you don't have time to do it right, when will you have time to do it over? -- Penny Hines
[PATCH 4/4] [PPC32] Add Yucca (440SPe eval board) platform
Add support for AMCC PowerPC 440SPe Yucca eval board platform.
Signed-off-by: Roland Dreier rolandd at cisco.com
---
arch/ppc/boot/simple/Makefile |6 +
arch/ppc/platforms/4xx/Kconfig | 11 +-
arch/ppc/platforms/4xx/Makefile |1
arch/ppc/platforms/4xx/yucca.c | 286 +++
arch/ppc/platforms/4xx/yucca.h | 115
include/asm-ppc/ibm4xx.h|4 +
6 files changed, 421 insertions(+), 2 deletions(-)
create mode 100644 arch/ppc/platforms/4xx/yucca.c
create mode 100644 arch/ppc/platforms/4xx/yucca.h
542fc1a61c8a721ee4c894ca961d8242d20e813a
diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
--- a/arch/ppc/boot/simple/Makefile
+++ b/arch/ppc/boot/simple/Makefile
@@ -79,6 +79,12 @@ zimageinitrd-$(CONFIG_LUAN) := zImage.i
entrypoint-$(CONFIG_LUAN):= 0x0100
extra.o-$(CONFIG_LUAN):= pibs.o
+ zimage-$(CONFIG_YUCCA) := zImage-TREE
+zimageinitrd-$(CONFIG_YUCCA) := zImage.initrd-TREE
+ end-$(CONFIG_YUCCA) := yucca
+ entrypoint-$(CONFIG_YUCCA) := 0x0100
+ extra.o-$(CONFIG_YUCCA) := pibs.o
+
zimage-$(CONFIG_OCOTEA) := zImage-TREE
zimageinitrd-$(CONFIG_OCOTEA) := zImage.initrd-TREE
end-$(CONFIG_OCOTEA) := ocotea
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -82,6 +82,12 @@ config LUAN
help
This option enables support for the IBM PPC440SP evaluation board.
+config YUCCA
+ bool Yucca
+ select WANT_EARLY_SERIAL
+ help
+ This option enables support for the AMCC PPC440SPe evaluation board.
+
config OCOTEA
bool Ocotea
select WANT_EARLY_SERIAL
@@ -126,7 +132,8 @@ config 440SP
config 440SPE
bool
- default n
+ depends on YUCCA
+ default y
config 440
bool
@@ -162,7 +169,7 @@ config BOOKE
config IBM_OCP
bool
- depends on ASH || BAMBOO || BUBINGA || CPCI405 || EBONY || EP405 ||
LUAN || OCOTEA || REDWOOD_5 || REDWOOD_6 || SYCAMORE || WALNUT
+ depends on ASH || BAMBOO || BUBINGA || CPCI405 || EBONY || EP405 ||
LUAN || YUCCA || OCOTEA || REDWOOD_5 || REDWOOD_6 || SYCAMORE || WALNUT
default y
config XILINX_OCP
diff --git a/arch/ppc/platforms/4xx/Makefile b/arch/ppc/platforms/4xx/Makefile
--- a/arch/ppc/platforms/4xx/Makefile
+++ b/arch/ppc/platforms/4xx/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_EP405)+= ep405.o
obj-$(CONFIG_BUBINGA) += bubinga.o
obj-$(CONFIG_LUAN) += luan.o
+obj-$(CONFIG_YUCCA)+= yucca.o
obj-$(CONFIG_OCOTEA) += ocotea.o
obj-$(CONFIG_REDWOOD_5)+= redwood5.o
obj-$(CONFIG_REDWOOD_6)+= redwood6.o
diff --git a/arch/ppc/platforms/4xx/yucca.c b/arch/ppc/platforms/4xx/yucca.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/platforms/4xx/yucca.c
@@ -0,0 +1,286 @@
+/*
+ * arch/ppc/platforms/4xx/yucca.c
+ *
+ * Yucca board specific routines
+ *
+ * Roland Dreier rolandd at cisco.com (based on yucca.c by Matt Porter)
+ *
+ * Copyright 2004-2005 MontaVista Software Inc.
+ * Copyright (c) 2005 Cisco Systems. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/config.h
+#include linux/stddef.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/reboot.h
+#include linux/pci.h
+#include linux/kdev_t.h
+#include linux/types.h
+#include linux/major.h
+#include linux/blkdev.h
+#include linux/console.h
+#include linux/delay.h
+#include linux/ide.h
+#include linux/initrd.h
+#include linux/irq.h
+#include linux/seq_file.h
+#include linux/root_dev.h
+#include linux/tty.h
+#include linux/serial.h
+#include linux/serial_core.h
+
+#include asm/system.h
+#include asm/pgtable.h
+#include asm/page.h
+#include asm/dma.h
+#include asm/io.h
+#include asm/machdep.h
+#include asm/ocp.h
+#include asm/pci-bridge.h
+#include asm/time.h
+#include asm/todc.h
+#include asm/bootinfo.h
+#include asm/ppc4xx_pic.h
+#include asm/ppcboot.h
+
+#include syslib/ibm44x_common.h
+#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;
+
+static void __init
+yucca_calibrate_decr(void)
+{
+ unsigned int freq;
+
+ if
[PATCH 1/4] [PPC32] Allow ERPN for early serial to depend on CPU type
The PowerPC 440SPe supports up to 16 GB of RAM, and therefore its IO registers are at 0x4__ instead of being at 0x1__ like most other PPC 440 chips. To allow for this, this patch moves the definition of the ERPN used for mapping UART0 from being hard-coded in the head_44x.S assembly code to being defined in ibm44x.h. Signed-off-by: Roland Dreier rolandd at cisco.com --- arch/ppc/kernel/head_44x.S |4 ++-- include/asm-ppc/ibm44x.h |7 ++- 2 files changed, 8 insertions(+), 3 deletions(-) eb79641bc2a92b7d4c2f62e072650e20a7748f45 diff --git a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S --- a/arch/ppc/kernel/head_44x.S +++ b/arch/ppc/kernel/head_44x.S @@ -190,8 +190,8 @@ skpinv: addir4,r4,1 /* Increment */ /* xlat fields */ lis r4,UART0_PHYS_IO_BASE at h /* RPN depends on SoC */ -#ifndef CONFIG_440EP - ori r4,r4,0x0001/* ERPN is 1 for second 4GB page */ +#ifdef UART0_PHYS_ERPN + ori r4,r4,UART0_PHYS_ERPN /* Add ERPN if above 4GB */ #endif /* attrib fields */ diff --git a/include/asm-ppc/ibm44x.h b/include/asm-ppc/ibm44x.h --- a/include/asm-ppc/ibm44x.h +++ b/include/asm-ppc/ibm44x.h @@ -34,12 +34,17 @@ /* Lowest TLB slot consumed by the default pinned TLBs */ #define PPC44x_LOW_SLOT63 -/* LS 32-bits of UART0 physical address location for early serial text debug */ +/* + * Least significant 32-bits and extended real page number (ERPN) of + * UART0 physical address location for early serial text debug + */ #if defined(CONFIG_440SP) +#define UART0_PHYS_ERPN1 #define UART0_PHYS_IO_BASE 0xf200 #elif defined(CONFIG_440EP) #define UART0_PHYS_IO_BASE 0xe000 #else +#define UART0_PHYS_ERPN1 #define UART0_PHYS_IO_BASE 0x4200 #endif
[PATCH 3/4] [PPC32] ibm_emac: Add 440SPe support
Eugene, I'm not sure what the status of your ibm_emac rewrite is. Is
there a tree somewhere that you would like me to merge this change
with and then send you a patch, or do you want to take care of merging?
For some reason, the hardware designers made the polarity of one bit
in the 440SPe's PHY interface register the opposite of all other PPC
440 chips. To handle this, abstract our access to this bit into
emac_phy_start() and emac_phy_done() functions, and do the right thing
based on the configured CPU type.
Signed-off-by: Roland Dreier rolandd at cisco.com
---
drivers/net/ibm_emac/ibm_emac.h |2 -
drivers/net/ibm_emac/ibm_emac_core.c | 72 ++
2 files changed, 55 insertions(+), 19 deletions(-)
187bfbe2d410e5a229fb828e2c3dd0a8045857e8
diff --git a/drivers/net/ibm_emac/ibm_emac.h b/drivers/net/ibm_emac/ibm_emac.h
--- a/drivers/net/ibm_emac/ibm_emac.h
+++ b/drivers/net/ibm_emac/ibm_emac.h
@@ -237,7 +237,7 @@ typedef struct emac_regs {
#define EMAC_RWMR_DEFAULT 0x1000a200
#define EMAC_TMR0_DEFAULT EMAC_TMR0_TFAE_2_32
#define EMAC_TMR1_DEFAULT 0xa00f
-#elif defined(CONFIG_440SP)
+#elif defined(CONFIG_440SP) || defined(CONFIG_440SPE)
#define EMAC_RWMR_DEFAULT 0x08002000
#define EMAC_TMR0_DEFAULT EMAC_TMR0_TFAE_128_2048
#define EMAC_TMR1_DEFAULT 0xf820
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c
b/drivers/net/ibm_emac/ibm_emac_core.c
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -160,6 +160,34 @@ static struct net_device_stats *emac_sta
return fep-stats;
};
+/*
+ * For the 440SPe, AMCC inexplicably changed the polarity of
+ * the operation complete bit in the MII control register.
+ */
+#ifdef CONFIG_440SPE
+static inline int emac_phy_done(uint32_t stacr)
+{
+ return !(stacr EMAC_STACR_OC);
+};
+
+static inline uint32_t emac_phy_start(uint32_t stacr)
+{
+ return stacr | EMAC_STACR_OC;
+};
+
+#else /* CONFIG_440SPE */
+
+static inline int emac_phy_done(uint32_t stacr)
+{
+ return stacr EMAC_STACR_OC;
+};
+
+static inline uint32_t emac_phy_start(uint32_t stacr)
+{
+ return stacr;
+};
+#endif /* CONFIG_440SPE */
+
static int
emac_init_rgmii(struct ocp_device *rgmii_dev, int input, int phy_mode)
{
@@ -397,13 +425,15 @@ int emac_phy_read(struct net_device *dev
emacp = fep-emacp;
}
- count = 0;
- while stacr = in_be32(emacp-em0stacr)) EMAC_STACR_OC) == 0)
-(count++ MDIO_DELAY))
+ for (count = 0; count MDIO_DELAY; ++count) {
+ stacr = in_be32(emacp-em0stacr);
+ if (emac_phy_done(stacr))
+ break;
udelay(1);
+ }
MDIO_DEBUG(( (count was %d)\n, count));
- if ((stacr EMAC_STACR_OC) == 0) {
+ if (!emac_phy_done(stacr)) {
printk(KERN_WARNING %s: PHY read timeout #1!\n, dev-name);
return -1;
}
@@ -412,15 +442,17 @@ int emac_phy_read(struct net_device *dev
stacr = ((EMAC_STACR_READ | (reg 0x1f)) ~EMAC_STACR_CLK_100MHZ);
stacr |= ((mii_id 0x1F) 5);
- out_be32(emacp-em0stacr, stacr);
+ out_be32(emacp-em0stacr, emac_phy_start(stacr));
- count = 0;
- while stacr = in_be32(emacp-em0stacr)) EMAC_STACR_OC) == 0)
-(count++ MDIO_DELAY))
+ for (count = 0; count MDIO_DELAY; ++count) {
+ stacr = in_be32(emacp-em0stacr);
+ if (emac_phy_done(stacr))
+ break;
udelay(1);
+ }
MDIO_DEBUG(( (count was %d)\n, count));
- if ((stacr EMAC_STACR_OC) == 0) {
+ if (!emac_phy_done(stacr)) {
printk(KERN_WARNING %s: PHY read timeout #2!\n, dev-name);
return -1;
}
@@ -457,13 +489,15 @@ void emac_phy_write(struct net_device *d
emacp = fep-emacp;
}
- count = 0;
- while stacr = in_be32(emacp-em0stacr)) EMAC_STACR_OC) == 0)
-(count++ MDIO_DELAY))
+ for (count = 0; count MDIO_DELAY; ++count) {
+ stacr = in_be32(emacp-em0stacr);
+ if (emac_phy_done(stacr))
+ break;
udelay(1);
+ }
MDIO_DEBUG(( (count was %d)\n, count));
- if ((stacr EMAC_STACR_OC) == 0) {
+ if (!emac_phy_done(stacr)) {
printk(KERN_WARNING %s: PHY write timeout #2!\n, dev-name);
return;
}
@@ -473,15 +507,17 @@ void emac_phy_write(struct net_device *d
stacr = ((EMAC_STACR_WRITE | (reg 0x1f)) ~EMAC_STACR_CLK_100MHZ);
stacr |= ((mii_id 0x1f) 5) | ((data 0x) 16);
- out_be32(emacp-em0stacr, stacr);
+ out_be32(emacp-em0stacr, emac_phy_start(stacr));
-
[PATCH 0/4] 440SPe support
Here is a series of patches that add basic support for AMCC's PowerPC 440SPe SoC. With these patches, the kernel will boot and run on the Yucca 440SPe eval board, with ethernet and serial working. I don't have PCI-X or PCI Express in a mergeable state, but I thought it would be worth posting these now for review. Also, it would probably be good to figure out how we want to merge this upstream once 2.6.14 comes out -- 440SPe requires some minor changes to ethernet PHY handling, which will have to be coordinated with the ibm_emac rewrite, and there are also some minor conflicts with the 440GR patches I saw. Right now I'm working on PCI Express support, and I'll post those patches once I have something reasonable. I also have a git tree at rsync://rsync.kernel.org/pub/scm/linux/kernel/git/roland/ppc440spe.git that contains all of these patches, in case that makes it easier to merge this stuff. Thanks, Roland
[PATCH 3/4] [PPC32] ibm_emac: Add 440SPe support
On Thu, Sep 22, 2005 at 08:03:35PM -0700, Roland Dreier wrote: Eugene, I'm not sure what the status of your ibm_emac rewrite is. Is there a tree somewhere that you would like me to merge this change with and then send you a patch, or do you want to take care of merging? Well, new driver was sent to jgarzik and netdev list three weeks ago. So far I haven't heard anything technical from Jeff. I don't know when and even if it will be merged. There is a GIT tree with new driver, for more info look at http://kernel.ebshome.net/emac/index.html I don't know what to recommend now - wait for net driver maintainer (I've heard some people have been waiting for couple months already) or sent this patch upstream ignoring new driver :(. Matt? I'll try to look at merging your patch into my tree, but probably not right now - I'm kinda busy with other stuff and netdev progress doesn't quite motivate me working on this project, frankly. Though, if you can send me a patch against my tree, I'll appreciate it :). -- Eugene
[PATCH 2/4] [PPC32] Add 440SPe support
On Thu, Sep 22, 2005 at 08:03:35PM -0700, Roland Dreier wrote:
Add support for the AMCC PowerPC 440SPe SoC.
[snip]
+static struct ocp_func_mal_data amc440spe_mal0_def = {
+ .num_tx_chans = 1,/* Number of TX channels */
+ .num_rx_chans = 1,/* Number of RX channels */
+ .txeob_irq = 38, /* TX End Of Buffer IRQ */
+ .rxeob_irq = 39, /* RX End Of Buffer IRQ */
+ .txde_irq = 34, /* TX Descriptor Error IRQ */
+ .rxde_irq = 35, /* RX Descriptor Error IRQ */
+ .serr_irq = 33, /* MAL System Error IRQ*/
+};
+OCP_SYSFS_MAL_DATA()
Roland, I recently added new field (.dcr_base) to this structure (as a
preparation step for new EMAC driver), could you do this for 440SPe as
well? It's not needed right now, but as soon as new EMAC driver is in,
440SPe will stop working.
[snip]
+static void __init ppc4xx_pic_impl_init(void)
+{
+ /* Enable cascade interrupts in UIC0 */
+ /* Enable cascade interrupt in UIC0 */
I think you probably missed this part :)
--
Eugene
[PATCH 4/4] [PPC32] Add Yucca (440SPe eval board) platform
On Thu, Sep 22, 2005 at 08:03:35PM -0700, Roland Dreier wrote: Add support for AMCC PowerPC 440SPe Yucca eval board platform. [snip] +/* + * 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 This is not needed anymore. Please, remove this. -- Eugene
[PATCH 3/4] [PPC32] ibm_emac: Add 440SPe support
Eugene Well, new driver was sent to jgarzik and netdev list three
Eugene weeks ago. So far I haven't heard anything technical from
Eugene Jeff. I don't know when and even if it will be merged.
Assuming everyone in the PPC4xx world thinks your driver should
replace the old driver, it might be worth sending directly to Andrew.
There's no reason Jeff has to become a bottleneck for this.
Eugene I'll try to look at merging your patch into my tree, but
Eugene probably not right now - I'm kinda busy with other stuff
Eugene and netdev progress doesn't quite motivate me working on
Eugene this project, frankly. Though, if you can send me a patch
Eugene against my tree, I'll appreciate it :).
No problem at all. Here's a patch against your git tree -- only
tested on my Yucca board, so you might want to doublecheck that I
didn't break all the systems will the opposite polarity.
Thanks,
Roland
For some reason, the hardware designers made the polarity of one bit
in the 440SPe's PHY interface register the opposite of all other PPC
440 chips. To handle this, abstract our access to this bit and do the
right thing based on the configured CPU type.
Signed-off-by: Roland Dreier rolandd at cisco.com
diff --git a/drivers/net/ibm_emac/ibm_emac.h b/drivers/net/ibm_emac/ibm_emac.h
--- a/drivers/net/ibm_emac/ibm_emac.h
+++ b/drivers/net/ibm_emac/ibm_emac.h
@@ -26,7 +26,7 @@
/* This is a simple check to prevent use of this driver on non-tested SoCs */
#if !defined(CONFIG_405GP) !defined(CONFIG_405GPR)
!defined(CONFIG_405EP) \
!defined(CONFIG_440GP) !defined(CONFIG_440GX) !defined(CONFIG_440SP)
\
-!defined(CONFIG_440EP) !defined(CONFIG_NP405H)
+!defined(CONFIG_440EP) !defined(CONFIG_NP405H)
!defined(CONFIG_440SPE)
#error Unknown SoC. Please, check chip user manual and make sure EMAC defines
are OK
#endif
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c
b/drivers/net/ibm_emac/ibm_emac_core.c
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -139,6 +139,29 @@ static inline void EMAC_RX_CLK_DEFAULT(i
#define EMAC_CLK_EXTERNAL ((void)0)
#endif
+/*
+ * For the 440SPe, AMCC inexplicably changed the polarity of
+ * the operation complete bit in the MII control register.
+ */
+#ifdef CONFIG_440SPE
+static inline int emac_phy_done(uint32_t stacr)
+{
+ return !(stacr EMAC_STACR_OC);
+};
+
+#define EMAC_STACR_START EMAC_STACR_OC
+
+#else /* CONFIG_440SPE */
+
+static inline int emac_phy_done(uint32_t stacr)
+{
+ return stacr EMAC_STACR_OC;
+};
+
+#define EMAC_STACR_START 0
+#endif /* CONFIG_440SPE */
+
+
/* I don't want to litter system log with timeout errors
* when we have brain-damaged PHY.
*/
@@ -546,7 +569,7 @@ static int __emac_mdio_read(struct ocp_e
/* Wait for management interface to become idle */
n = 10;
- while (!(in_be32(p-stacr) EMAC_STACR_OC)) {
+ while (!emac_phy_done(in_be32(p-stacr))) {
udelay(1);
if (!--n)
goto to;
@@ -556,11 +579,12 @@ static int __emac_mdio_read(struct ocp_e
out_be32(p-stacr,
EMAC_STACR_BASE(emac_opb_mhz()) | EMAC_STACR_STAC_READ |
(reg EMAC_STACR_PRA_MASK)
-| ((id EMAC_STACR_PCDA_MASK) EMAC_STACR_PCDA_SHIFT));
+| ((id EMAC_STACR_PCDA_MASK) EMAC_STACR_PCDA_SHIFT)
+| EMAC_STACR_START);
/* Wait for read to complete */
n = 100;
- while (!((r = in_be32(p-stacr)) EMAC_STACR_OC)) {
+ while (!emac_phy_done(r = in_be32(p-stacr))) {
udelay(1);
if (!--n)
goto to;
@@ -594,7 +618,7 @@ static void __emac_mdio_write(struct ocp
/* Wait for management interface to be idle */
n = 10;
- while (!(in_be32(p-stacr) EMAC_STACR_OC)) {
+ while (!emac_phy_done(in_be32(p-stacr))) {
udelay(1);
if (!--n)
goto to;
@@ -605,11 +629,12 @@ static void __emac_mdio_write(struct ocp
EMAC_STACR_BASE(emac_opb_mhz()) | EMAC_STACR_STAC_WRITE |
(reg EMAC_STACR_PRA_MASK) |
((id EMAC_STACR_PCDA_MASK) EMAC_STACR_PCDA_SHIFT) |
-(val EMAC_STACR_PHYD_SHIFT));
+(val EMAC_STACR_PHYD_SHIFT) |
+EMAC_STACR_START);
/* Wait for write to complete */
n = 100;
- while (!(in_be32(p-stacr) EMAC_STACR_OC)) {
+ while (!emac_phy_done(in_be32(p-stacr))) {
udelay(1);
if (!--n)
goto to;
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h
b/drivers/net/ibm_emac/ibm_emac_mal.h
--- a/drivers/net/ibm_emac/ibm_emac_mal.h
+++ b/drivers/net/ibm_emac/ibm_emac_mal.h
@@ -34,7 +34,8 @@
#if defined(CONFIG_405GP) || defined(CONFIG_405GPR) || defined(CONFIG_405EP)
|| \
defined(CONFIG_440EP)
[PATCH 2/4] [PPC32] Add 440SPe support
Eugene Roland, I recently added new field (.dcr_base) to this Eugene structure (as a preparation step for new EMAC driver), Eugene could you do this for 440SPe as well? It's not needed Eugene right now, but as soon as new EMAC driver is in, 440SPe Eugene will stop working. Eugene I think you probably missed this part :) Both fixed and pushed in a new git tree... - R.
[PATCH 4/4] [PPC32] Add Yucca (440SPe eval board) platform
Eugene This is not needed anymore. Please, remove this. Done and also pushed out in the new git tree. - R.
