* AW: MPC5200,PSC in uart mode, receiving problem
From: Achim Machura @ 2005-10-11 8:10 UTC (permalink / raw)
To: 'Wolfgang Denk'; +Cc: Linuxppc-Embedded (E-Mail)
In-Reply-To: <20051011071841.6C0FE353ADC@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 108 bytes --]
Here the patch
> Even better, post a patch here on the list so we all can benefit.
Best regards,
Achim
[-- Attachment #2: patch_linuxppc_2_4_develLABEL_2004_04_30_1320_psc --]
[-- Type: application/octet-stream, Size: 7506 bytes --]
Index: psc.c
===================================================================
--- psc.c (.../kernel/linux/arch/ppc/5xxx_io/psc.c) (Revision 777)
+++ psc.c (.../firmware/kernel/linux/arch/ppc/5xxx_io/psc.c) (Arbeitskopie)
@@ -29,6 +29,7 @@
#include <linux/serial.h>
#include <linux/serialP.h>
#include <linux/generic_serial.h>
+#include <linux/proc_fs.h>
#ifdef CONFIG_UBOOT
#include <asm/ppcboot.h>
#endif
@@ -37,7 +38,7 @@
* This driver can spew a whole lot of debugging output at you. If you
* need maximum performance, you should disable the DEBUG define.
*/
-#undef MPC5xxx_PSC_DEBUG
+#undef MPC5xxx_PSC_DEBUG
#ifdef MPC5xxx_PSC_DEBUG
#define MPC5xxx_PSC_DEBUG_OPEN 0x00000001
@@ -55,6 +56,7 @@
#define MPC5xxx_PSC_DEBUG_FIRMWARE 0x00001000
#define MPC5xxx_PSC_DEBUG_MEMTEST 0x00002000
#define MPC5xxx_PSC_DEBUG_THROTTLE 0x00004000
+#define MPC5xxx_PSC_DEBUG_CLEARERR 0x00008000
#define MPC5xxx_PSC_DEBUG_ALL 0xffffffff
int rs_debug = MPC5xxx_PSC_DEBUG_ALL & ~MPC5xxx_PSC_DEBUG_TRANSMIT;
@@ -150,13 +152,23 @@
int rs_refcount;
int rs_initialized = 0;
+
/*
+ * proc stuff
+ */
+static int sio_read_info(char * buf, char ** start, off_t offset, int count, int *eof, void * data );
+static int sio_clear_err(struct file *file, const char *buffer, unsigned long count, void *data);
+static struct proc_dir_entry *pProcEntry = NULL;
+
+
+void clear_err(struct mpc5xxx_psc * psc);
+/*
* ----------------------------------------------------------------------
*
* Here starts the interrupt handling routines. All of the following
* subroutines are declared as inline and are folded into
* rs_interrupt(). They were separated out for readability's sake.
- *
+ *MPC5xxx_PSC_DEBUG_RECEIVE
* Note: rs_interrupt() is a "fast" interrupt, which means that it
* runs with interrupts turned off. People who may want to modify
* rs_interrupt() should try to keep the interrupt handler as fast as
@@ -294,19 +306,36 @@
static void rs_interrupt(int irq, void *dev_id, struct pt_regs * regs)
{
- struct rs_port * port;
+ struct rs_port * port = (struct rs_port *)dev_id;
+ struct mpc5xxx_psc *psc = port->psc;
unsigned long flags;
+ u16 status;
spin_lock_irqsave(&mpc5xxx_serial_lock, flags);
- port = (struct rs_port *)dev_id;
+
rs_dprintk(MPC5xxx_PSC_DEBUG_INTERRUPTS,
"rs_interrupt (port %p)...", port);
+ if (!port || !port->gs.tty) {
+ printk( KERN_DEBUG"%s(%d): port=%p tty=%p\n", __FUNCTION__, __LINE__,
+ port, port?port->gs.tty:NULL );
+ goto out;
+ }
+
+ status = in_be16(&psc->mpc5xxx_psc_status);
+ /* RB-Bit is set ? */
+ if(status & MPC5xxx_PSC_SR_RB)
+ {
+ clear_err(psc);
+ rs_dprintk(MPC5xxx_PSC_DEBUG_INTERRUPTS, "clear err in isr nach status %d.\n", status);
+ goto out;
+ }
+
receive_char(port);
transmit_char(port);
-
+out:
spin_unlock_irqrestore(&mpc5xxx_serial_lock, flags);
rs_dprintk(MPC5xxx_PSC_DEBUG_INTERRUPTS, "end.\n");
@@ -318,7 +347,7 @@
* interface with the generic_serial driver *
************************************************************************
*/
-static void rs_disable_tx_interrupts(void * ptr)
+static void rs_disable_tx_interrupts(void * ptr)
{
struct rs_port *port = ptr;
struct mpc5xxx_psc *psc = port->psc;
@@ -360,7 +389,7 @@
port->imr &= ~MPC5xxx_PSC_IMR_RXRDY;
out_be16(&psc->mpc5xxx_psc_imr, port->imr);
-
+ rs_dprintk(MPC5xxx_PSC_DEBUG_RECEIVE,"disable RxInt\n");
spin_unlock_irqrestore(&mpc5xxx_serial_lock, flags);
}
@@ -382,7 +411,7 @@
* while (in_be16(&psc->mpc5xxx_psc_status) & MPC5xxx_PSC_SR_RXRDY)
* in_8(&psc->mpc5xxx_psc_buffer_8);
*/
-
+ rs_dprintk(MPC5xxx_PSC_DEBUG_RECEIVE,"enable RxInt\n");
spin_unlock_irqrestore(&mpc5xxx_serial_lock, flags);
}
@@ -442,9 +471,15 @@
val32 |= (MPC5xxx_GPIO_PSC_CONFIG_UART_WITHOUT_CD << (4*line));
out_be32(&gpio->port_config, val32);
/* reset and enable PSC */
- out_8(&psc->command, MPC5xxx_PSC_RST_TX
- | MPC5xxx_PSC_RX_DISABLE | MPC5xxx_PSC_TX_ENABLE);
- out_8(&psc->command, MPC5xxx_PSC_RST_RX);
+// out_8(&psc->command, MPC5xxx_PSC_RST_TX
+// | MPC5xxx_PSC_RX_DISABLE | MPC5xxx_PSC_TX_ENABLE);
+// out_8(&psc->command, MPC5xxx_PSC_RST_RX);
+
+ /* neu */
+ /* reset and enable PSC */
+ out_8(&psc->command, MPC5xxx_PSC_RST_TX | MPC5xxx_PSC_TX_ENABLE);
+ //out_8(&psc->command, MPC5xxx_PSC_RST_RX);
+ /* ende neu*/
/* Set PSC operation mode as 'UART, DCD ignored' */
out_be32(&psc->sicr, 0x0);
/* Set clocking */
@@ -539,7 +574,7 @@
line = minor(tty->device) - tty->driver.minor_start;
rs_dprintk(MPC5xxx_PSC_DEBUG_OPEN,
- "%d: opening line %d. tty=%p ctty=%p)\n",
+ "%d: opening line %d. tty=%p ctty=%p)\n",
(int) current->pid, line, tty, current->tty);
if ((line < 0) || (line >= RS_TABLE_SIZE))
@@ -813,6 +848,7 @@
#endif
rs_dprintk(MPC5xxx_PSC_DEBUG_INIT, "psc base 0x%08lx\n",
(unsigned long)port->psc);
+ clear_err(port->psc);
port++;
}
@@ -878,6 +914,11 @@
return 1;
}
+ //pProcEntry = create_proc_read_entry("driver/sio0",0444,NULL,sio_read_info,NULL);
+ pProcEntry = create_proc_entry("driver/sio0",0444,NULL);
+ pProcEntry->read_proc = sio_read_info;
+ pProcEntry->write_proc = sio_clear_err;
+ pProcEntry->owner = THIS_MODULE;
func_exit();
return 0;
}
@@ -1094,3 +1135,61 @@
}
#endif
+static int sio_read_info(char * buf, char ** start, off_t offset, int count, int *eof, void * data )
+{
+
+ int len = 0;
+ struct mpc5xxx_psc *psc = (struct mpc5xxx_psc *) MPC5xxx_PSC1;
+ u16 nStat;
+
+ *eof = 1;
+ *buf = 0;
+ nStat = in_be16(&psc->mpc5xxx_psc_status);
+ if(count > len + 120)
+ {
+ len += sprintf(buf+len, "\n Status PSC 1: %d",nStat);
+ len += sprintf(buf+len, "\n RB: %d",(nStat & MPC5xxx_PSC_SR_RB) ? 1 : 0);
+ len += sprintf(buf+len, "\n FE: %d",(nStat & MPC5xxx_PSC_SR_FE) ? 1 : 0);
+ len += sprintf(buf+len, "\n PE: %d",(nStat & MPC5xxx_PSC_SR_PE) ? 1 : 0);
+ len += sprintf(buf+len, "\n OR: %d",(nStat & MPC5xxx_PSC_SR_OE) ? 1 : 0);
+ len += sprintf(buf+len, "\n TxEMP: %d",(nStat & MPC5xxx_PSC_SR_TXEMP) ? 1 : 0);
+ len += sprintf(buf+len, "\n TxRDY: %d",(nStat & MPC5xxx_PSC_SR_TXRDY) ? 1 : 0);
+ len += sprintf(buf+len, "\n RXFULL: %d",(nStat & MPC5xxx_PSC_SR_RXFULL) ? 1 : 0);
+ len += sprintf(buf+len, "\n RxRDY: %d",(nStat & MPC5xxx_PSC_SR_RXRDY) ? 1 : 0);
+ len += sprintf(buf+len, "\n CDE: %d\n",(nStat & MPC5xxx_PSC_SR_CDE) ? 1 : 0);
+
+ }
+ return len;
+
+}
+static int sio_clear_err(struct file *file, const char *buffer, unsigned long count, void *data)
+{
+
+ struct mpc5xxx_psc *psc = (struct mpc5xxx_psc *) MPC5xxx_PSC1;
+
+ clear_err(psc);
+ return (int)count;
+}
+
+void clear_err(struct mpc5xxx_psc * psc)
+{
+ u8 byCmd;
+ u16 i;
+ unsigned int status, nBytes;
+
+ nBytes = in_be16(&psc->rfnum) & MPC5xxx_PSC_RFNUM_MASK;
+ for(i=0; i< nBytes;i++)
+ {
+ byCmd = in_8(&psc->mpc5xxx_psc_buffer_8);
+ rs_dprintk(MPC5xxx_PSC_DEBUG_CLEARERR,"loesche Byte %d von %d Bytes\n",i+1,nBytes);
+ }
+ status = in_be16(&psc->mpc5xxx_psc_status);
+ rs_dprintk(MPC5xxx_PSC_DEBUG_CLEARERR,"status Start %d\n",status);
+ byCmd = (u8) MPC5xxx_PSC_RST_ERR_STAT;
+ out_8(&psc->command, byCmd);
+ wmb();
+ status = in_be16(&psc->mpc5xxx_psc_status);
+ rmb();
+ rs_dprintk(MPC5xxx_PSC_DEBUG_CLEARERR,"status clear %d\n",status);
+}
+
^ permalink raw reply
* Re: [PATCH] powerpc: zero out BSS for all platforms
From: Olaf Hering @ 2005-10-11 9:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Kumar Gala, linuxppc64-dev
In-Reply-To: <1129016771.17365.198.camel@gaston>
On Tue, Oct 11, Benjamin Herrenschmidt wrote:
> On Mon, 2005-10-10 at 14:51 -0500, Kumar Gala wrote:
> > We need to ensure that the BSS is zeroed out for all platforms.
> > Currently only prom_init.c was clearlying out the BSS which only works
> > for PPC_OF platforms.
> >
> > Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
>
> You need to make absolutely certain that we have not written anything to
> the bss yet though... Is that the case ? I usually prefer doing the
> zero'ing in assembly :)
early_init is called so early, its almost like asm code.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: MPC8xx slave USB driver
From: Wolfgang Denk @ 2005-10-11 9:31 UTC (permalink / raw)
To: Alexey Dyatchkov; +Cc: linuxppc-embedded
In-Reply-To: <002001c5ce38$3a5de690$0100000a@Omerxp>
In message <002001c5ce38$3a5de690$0100000a@Omerxp> you wrote:
> I believe, it was taken from the development tree. Actually, I joined this
> project already after the linux was tuned for the board, it was about 3 or 4
> years ago.
Please make sure to specify exactly which source tree you are talking
about. There are too many different versions of 2.4 trees for PPC.
> > We are using slightly modified Denx linux 2.4.12 on our board (modified
> > RPXLITE)
>
> We never released such a kernel version.
We (DENX) never released such a tree. We jumped from 2.4.4 to 2.4.18;
and we never removed anything from the development tree - the whole
history is on our CVS server (and now also on git).
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
You don't have to worry about me. I might have been born yesterday...
but I stayed up all night.
^ permalink raw reply
* Re: [PATCH] powerpc: zero out BSS for all platforms
From: Benjamin Herrenschmidt @ 2005-10-11 9:48 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Kumar Gala, linuxppc64-dev
In-Reply-To: <20051011093040.GA5362@suse.de>
On Tue, 2005-10-11 at 11:30 +0200, Olaf Hering wrote:
> On Tue, Oct 11, Benjamin Herrenschmidt wrote:
>
> > On Mon, 2005-10-10 at 14:51 -0500, Kumar Gala wrote:
> > > We need to ensure that the BSS is zeroed out for all platforms.
> > > Currently only prom_init.c was clearlying out the BSS which only works
> > > for PPC_OF platforms.
> > >
> > > Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
> >
> > You need to make absolutely certain that we have not written anything to
> > the bss yet though... Is that the case ? I usually prefer doing the
> > zero'ing in assembly :)
>
> early_init is called so early, its almost like asm code.
Yah, as long as that stuff is still separate between ppc32 and ppc64,
that's fine. We'll have to be careful with iSeries once we do the
merge :)
Ben.
^ permalink raw reply
* Which PHY connection to use on MPC8541...
From: Gerhard Jaeger @ 2005-10-11 10:13 UTC (permalink / raw)
To: linuxppc-embedded
Hi list,
we're currently designing a custon MPC8541 based board having three ethernet connections.
For some reasons, we'd like to use the FCC1 and 2 + TSEC1. From what I see from the
docs, it should be no problem to connect i.e. a quad phy (for FCC1/2) and a gigabit phy
(for TSEC1) to the EC_MDIO of the TSEC as long as they have different addresses.
I don't want to use the GPIO stuff for MDIO.
The question is, what does this mean to the drivers? For the gianfar driver this should
be okay and from what I see, the upcoming fs_enet driver supports also a phy
connected either to the GPIOs (bitbanging) or the TSEC MDIO. Is this right, or am I
missing something essential?
Would it be better to use the GPIO-MDIO for the FCC phy and the TSEC-MDIO
for the TSEC phy?
TIA
Gerhard
^ permalink raw reply
* What Can I do to port JVM on MPC?
From: Dick Hollenbeck @ 2005-10-11 10:39 UTC (permalink / raw)
To: linuxppc-embedded
There is a JVM that is part of GCC called libgcj. It differs from Sun's
JVM in that is uses "ahead of time compilation" of the Java code all the
way to machine code. Whereas Sun's JVM runs on "java bytecode" and at
runtime compiles this bytecode to machine code "just in time".
Unfortunately the build system for libgcj is abysmal and shameful, and
the garbage collector will pause the process that runs it about 55 msecs
every so often. So aside from the build system and the GC, libgcj is
excellent work.
I would start with libgcj.
http://gcc.gnu.org/java/
It should be your path of best investment.
Been there, done that.
Regards,
Dick Hollenbeck
--
Please help fix the U.S. software industry before it is too late.
Contact your U.S. representatives with this information:
http://lpf.ai.mit.edu/Patents/industry-at-risk.html
http://www.groklaw.net/article.php?story=20041003041632172
^ permalink raw reply
* RE: Which PHY connection to use on MPC8541...
From: Stefan Nickl @ 2005-10-11 10:57 UTC (permalink / raw)
To: Gerhard Jaeger; +Cc: Stefan Nickl, linuxppc-embedded
Hi,
about a year ago we resorted to using port pin MDIO in this situation
for the FCCs because the fcc_enet driver and the gianfar driver live
in separate worlds, so to speak.
But in the meantime, Andy Fleming was very active regarding the PHY
abstraction layer. I still haven't seen patches that migrate fcc_enet
to using this layer, but the gianfar driver seems to use this code now.
So I'd say quick solution: use TSEC1 MDIO for TSECs and cpm port pins
for FCC, clean solution: change fcc_enet to use the PHY abstraction
layer.
--=20
Stefan Nickl
Kontron Modular Computers
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=20
> Gerhard Jaeger
> Sent: Tuesday, October 11, 2005 12:14 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Which PHY connection to use on MPC8541...
>=20
> Hi list,
>=20
> we're currently designing a custon MPC8541 based board having=20
> three ethernet connections.
> For some reasons, we'd like to use the FCC1 and 2 + TSEC1.=20
> From what I see from the docs, it should be no problem to=20
> connect i.e. a quad phy (for FCC1/2) and a gigabit phy (for=20
> TSEC1) to the EC_MDIO of the TSEC as long as they have=20
> different addresses.=20
> I don't want to use the GPIO stuff for MDIO.
>=20
> The question is, what does this mean to the drivers? For the=20
> gianfar driver this should be okay and from what I see, the=20
> upcoming fs_enet driver supports also a phy connected either=20
> to the GPIOs (bitbanging) or the TSEC MDIO. Is this right, or=20
> am I missing something essential?=20
> Would it be better to use the GPIO-MDIO for the FCC phy and=20
> the TSEC-MDIO for the TSEC phy?
>=20
> TIA
> Gerhard
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: Problem Regarding Ping in Linux kernel version 2.4.24
From: Mark Chambers @ 2005-10-11 12:23 UTC (permalink / raw)
To: apoorv sangal, Linuxppc-embedded
In-Reply-To: <a79669360510102327o694dffb4pcf8ead02d95c9414@mail.gmail.com>
Hi,
I am sending the output from the console of the boot sequence and ifconfig
command as following.
Please check the same and let me know where i am going wrong.
****************************************************************************
***************************
[snip]
eth0: FCC2 ENET Version 0.4, 00:10:EC:40:30:8C
[snip]
init started: BusyBox v0.60.5 (2004.11.09-16:07+0000) multi-call
binarymount: Mounting /dev/ram0 on /tmp failed: Invalid argument
# ifconfig eth0 down
# ifconfig eth0 172.19.56.218
# ifconfig eth0 up
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:EC:40:30:8C
inet addr:172.19.56.218 Bcast:172.19.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 iB) TX bytes:0 (0.0 iB)
Base address:0x8500
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 iB) TX bytes:0 (0.0 iB)
# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.6 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.2 ms
--- 127.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.6 ms
#
# ping 172.19.59.101
PING 172.19.59.101 (172.19.59.101): 56 data bytes
--- 172.19.59.101 ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss
****************************************************************************
***************************
Regards,
Apoorv Sangal.
It appears you have correctly assigned MAC and IP addresses. The problem
does appear to be at
the hardware level, because the ethernet interface is not doing anything at
all. My guess would be
that the driver is not configured for the correct pins. You mentioned that
you are using custom hardware,
so look, probably in arch/ppc/8260_io/fcc_enet.c and make sure you have it
configured for Tx and
Rx clock coming in on the right pins, and also check that you are configured
for the correct PHY
interrupt.
Good luck,
Mark Chambers
^ permalink raw reply
* merge progress
From: Paul Mackerras @ 2005-10-11 12:26 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
I have just pushed out a new pile of commits to the powerpc-merge tree
on kernel.org. (It may take a little while for them to get mirrored
from master.kernel.org to ftp/rsync.kernel.org.)
The current state is that with ARCH=ppc, the merge tree will build all
the ppc32 configs that build in the stock 2.6.14-rc2 tree, and the
powermac configs run (I haven't boot-tested any of the others).
With ARCH=powerpc, a 32-bit powermac target builds (both UP and SMP)
and runs, and a 64-bit pSeries target builds and runs. 64-bit iSeries
builds but there is some weird bug that Stephen Rothwell and BenH have
been chasing. I haven't got far enough with the merge to be able to
build a 64-bit powermac target.
With ARCH=ppc64, pSeries, iSeries, powermac and maple all build, and
pSeries and iSeries have been boot-tested. I think I have broken
BPA/cell because it was using pSeries_smp.c (I think we need to make
cell have its own bpa_smp.c or whatever anyway).
I have about a week's backlog of mail, resulting from being on
vacation last week and from concentrating on pushing the merge along.
Tomorrow I'll hopefully get a chance to look at all the patches people
have sent in the last week. :)
Paul.
^ permalink raw reply
* Re: merge progress
From: Simon Richter @ 2005-10-11 12:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17227.44943.714106.911471@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 403 bytes --]
Hi,
Paul Mackerras wrote:
> I have just pushed out a new pile of commits to the powerpc-merge tree
> on kernel.org. (It may take a little while for them to get mirrored
> from master.kernel.org to ftp/rsync.kernel.org.)
Should I fast-forward the APUS patches towards the merge tree, or is it
better to apply them in the unmerged tree and merge them back into the
merge tree from there?
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* make modules failed.
From: JohnsonCheng @ 2005-10-11 12:52 UTC (permalink / raw)
To: linux-ppc-embedded
[-- Attachment #1: Type: text/plain, Size: 718 bytes --]
When I install linux2.6 modules on powerpc, it's failed as following:
[root]# make ARCH=ppc CROSS_COMPILE=powerpc-linux-
INSTALL_MOD_PATH=/opt/cross-project/images/modules-2.6.12.3 modules
INSTALL drivers/net/bonding/bonding.ko
INSTALL drivers/usb/serial/usbserial.ko
INSTALL drivers/usb/serial/visor.ko
INSTALL fs/binfmt_misc.ko
INSTALL fs/udf/udf.ko
INSTALL lib/crc-ccitt.ko
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map
-b
/opt/cross-project/TS-101/images/modules-2.6.12.3 -r 2.6.12.3; fi
make: *** [_modinst_post] Error 139
[root]#
It seems that I can't use /sbin/depmod, because it's for x86. I am not sure.
How to fix it?
Thanks,
Johnson Cheng
[-- Attachment #2: Type: text/html, Size: 5120 bytes --]
^ permalink raw reply
* Re: boot-time partitions and bootargs for 2.6.14
From: Vitaly Bordug @ 2005-10-11 13:10 UTC (permalink / raw)
To: Dmytro Bablinyuk; +Cc: linuxppc-embedded
In-Reply-To: <434B635D.1000509@rftechnology.com.au>
Assuming the board is 8272ads, you could try the MTD cvs from
infradead.org,
I used to add the map for this board - look into drivers/mtd/maps/pq2fads.c
Dmytro Bablinyuk wrote:
>> In that case you should have a u-boot line of
>>
>> mtdparts=physically_mapped_flash:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()
>
>
>
> Yep, I set
> mtdparts=phys_mapped_flash:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()
>
>
> I got flash discovery working and I set 'CONFIG_MTD_CMDLINE_PARTS=y' but
> kernel is not even attempting to parse 'mtdparts'. It's not calling
> 'parse_cmdline_partitions' function. Even if I got wrong 'mtd-id', it
> still should attempt to parse 'mtdparts' (well, at least I think so).
>
> Here is output:
>
> Kernel command line: console=ttyCPM0,115200 root=31:01 rw rootfstype=jffs2
> PID hash table entries: 512 (order: 9, 8192 bytes)
> Warning: real time clock seems stuck!
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Memory: 62720k available (1572k kernel code, 408k data, 96k init, 0k
> highmem)
> Mount-cache hash table entries: 512
> NET: Registered protocol family 16
> JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
> JFFS2: default compression mode: priority
> fuse init (API version 7.2)
> Initializing Cryptographic API
> Generic RTC Driver v1.07
> Serial: CPM driver $Revision: 0.01 $
> ttyCPM0 at MMIO 0xf0011a00 (irq = 40) is a CPM UART
> ttyCPM1 at MMIO 0xf0011a20 (irq = 41) is a CPM UART
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered
> RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
> loop: loaded (max 8 devices)
> physmap flash device: 800000 at ff800000
> Found: Intel I28F016S3
> phys_mapped_flash: Found 4 x8 devices at 0x0 in 32-bit bank
> RedBoot partition parsing not available
> eth0: FCC ENET Version 0.3, 00:04:9f:91:22:33
> mii_reg: 600eb881
> eth0: Phy @ 0x0, type Davicom DM9161E (0x0181b881)
> eth1: FCC ENET Version 0.3, 00:04:9f:51:22:33
> mii_reg: 618eb881
> eth1: Phy @ 0x3, type Davicom DM9161E (0x0181b881)
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> TCP: Hash tables configured (established 4096 bind 4096)
> TCP reno registered
> TCP bic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
>
> Does anybody has any idea of why parsing of 'mtdparts' is not even started?
>
> I have enabled debug macro:
>
> /* debug macro */
> #if 1
> #define dbg(x) do { printk("DEBUG-CMDLINE-PART: "); printk x; } while(0)
> #else
> #define dbg(x)
> #endif
>
> Thank you
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx
From: Vitaly Bordug @ 2005-10-11 13:54 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Kumar Gala, linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
This patch fixes a numbers of issues regarding to that both 8xx and 82xx
began to use ppc_sys model:
- Platform is now identified by default deviceless SOC, if no
BOARD_CHIP_NAME is specified in the bard-specific header. For the list
of supported names refer to (arch/ppc/syslib/) mpc8xx_sys.c and
mpc82xx_sys.c for 8xx and 82xx respectively.
- Fixed a bug in identification by name - if the name was not found, it
returned -1 instead of default deviceless ppc_spec.
- fixed devices amount in the 8xx platform system descriptions
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: 1.patch --]
[-- Type: text/x-patch, Size: 3539 bytes --]
diff --git a/arch/ppc/platforms/fads.h b/arch/ppc/platforms/fads.h
--- a/arch/ppc/platforms/fads.h
+++ b/arch/ppc/platforms/fads.h
@@ -25,6 +25,8 @@
#if defined(CONFIG_MPC86XADS)
+#define BOARD_CHIP_NAME "MPC86X"
+
/* U-Boot maps BCSR to 0xff080000 */
#define BCSR_ADDR ((uint)0xff080000)
diff --git a/arch/ppc/platforms/mpc885ads.h b/arch/ppc/platforms/mpc885ads.h
--- a/arch/ppc/platforms/mpc885ads.h
+++ b/arch/ppc/platforms/mpc885ads.h
@@ -88,5 +88,7 @@
#define SICR_ENET_MASK ((uint)0x00ff0000)
#define SICR_ENET_CLKRT ((uint)0x002c0000)
+#define BOARD_CHIP_NAME "MPC885"
+
#endif /* __ASM_MPC885ADS_H__ */
#endif /* __KERNEL__ */
diff --git a/arch/ppc/syslib/m8260_setup.c b/arch/ppc/syslib/m8260_setup.c
--- a/arch/ppc/syslib/m8260_setup.c
+++ b/arch/ppc/syslib/m8260_setup.c
@@ -62,6 +62,9 @@ m8260_setup_arch(void)
if (initrd_start)
ROOT_DEV = Root_RAM0;
#endif
+
+ identify_ppc_sys_by_name_and_id(BOARD_CHIP_NAME, in_be32(CPM_MAP_ADDR + CPM_IMMR_OFFSET));
+
m82xx_board_setup();
}
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -403,7 +403,9 @@ platform_init(unsigned long r3, unsigned
*(char *)(r7+KERNELBASE) = 0;
strcpy(cmd_line, (char *)(r6+KERNELBASE));
}
-
+
+ identify_ppc_sys_by_name(BOARD_CHIP_NAME);
+
ppc_md.setup_arch = m8xx_setup_arch;
ppc_md.show_percpuinfo = m8xx_show_percpuinfo;
ppc_md.irq_canonicalize = NULL;
diff --git a/arch/ppc/syslib/mpc8xx_sys.c b/arch/ppc/syslib/mpc8xx_sys.c
--- a/arch/ppc/syslib/mpc8xx_sys.c
+++ b/arch/ppc/syslib/mpc8xx_sys.c
@@ -24,7 +24,7 @@ struct ppc_sys_spec ppc_sys_specs[] = {
.ppc_sys_name = "MPC86X",
.mask = 0xFFFFFFFF,
.value = 0x00000000,
- .num_devices = 2,
+ .num_devices = 7,
.device_list = (enum ppc_sys_devices[])
{
MPC8xx_CPM_FEC1,
@@ -40,7 +40,7 @@ struct ppc_sys_spec ppc_sys_specs[] = {
.ppc_sys_name = "MPC885",
.mask = 0xFFFFFFFF,
.value = 0x00000000,
- .num_devices = 3,
+ .num_devices = 8,
.device_list = (enum ppc_sys_devices[])
{
MPC8xx_CPM_FEC1,
diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
--- a/arch/ppc/syslib/ppc_sys.c
+++ b/arch/ppc/syslib/ppc_sys.c
@@ -69,6 +69,9 @@ static int __init find_chip_by_name_and_
matched[j++] = i;
i++;
}
+
+ ret = i;
+
if (j != 0) {
for (i = 0; i < j; i++) {
if ((ppc_sys_specs[matched[i]].mask & id) ==
diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
--- a/include/asm-ppc/cpm2.h
+++ b/include/asm-ppc/cpm2.h
@@ -1087,6 +1087,9 @@ typedef struct im_idma {
#define SCCR_PCIDF_MSK 0x00000078 /* PCI division factor */
#define SCCR_PCIDF_SHIFT 3
+#ifndef CPM_IMMR_OFFSET
+#define CPM_IMMR_OFFSET 0x101a8
+#endif
#endif /* __CPM2__ */
#endif /* __KERNEL__ */
diff --git a/include/asm-ppc/mpc8260.h b/include/asm-ppc/mpc8260.h
--- a/include/asm-ppc/mpc8260.h
+++ b/include/asm-ppc/mpc8260.h
@@ -92,6 +92,10 @@ enum ppc_sys_devices {
extern unsigned char __res[];
#endif
+#ifndef BOARD_CHIP_NAME
+#define BOARD_CHIP_NAME ""
+#endif
+
#endif /* CONFIG_8260 */
#endif /* !__ASM_PPC_MPC8260_H__ */
#endif /* __KERNEL__ */
diff --git a/include/asm-ppc/mpc8xx.h b/include/asm-ppc/mpc8xx.h
--- a/include/asm-ppc/mpc8xx.h
+++ b/include/asm-ppc/mpc8xx.h
@@ -113,6 +113,10 @@ enum ppc_sys_devices {
MPC8xx_CPM_USB,
};
+#ifndef BOARD_CHIP_NAME
+#define BOARD_CHIP_NAME ""
+#endif
+
#endif /* !__ASSEMBLY__ */
#endif /* CONFIG_8xx */
#endif /* __CONFIG_8xx_DEFS */
^ permalink raw reply
* Re: Which PHY connection to use on MPC8541...
From: Andy Fleming @ 2005-10-11 18:05 UTC (permalink / raw)
To: Stefan Nickl; +Cc: linuxppc-embedded, Gerhard Jaeger
In-Reply-To: <DADA32856852FC458E0F96B664A6F55E73A8EF@kom-mailsrv1.kontron-modular.com>
On Oct 11, 2005, at 05:57, Stefan Nickl wrote:
> Hi,
>
> about a year ago we resorted to using port pin MDIO in this situation
> for the FCCs because the fcc_enet driver and the gianfar driver live
> in separate worlds, so to speak.
>
> But in the meantime, Andy Fleming was very active regarding the PHY
> abstraction layer. I still haven't seen patches that migrate fcc_enet
> to using this layer, but the gianfar driver seems to use this code
> now.
>
The work to migrate the new fs_enet driver to use the TSEC MDIO is in
progress. I have a few other things I'm working on right now, and
I've been having some hardware issues, but I've already done most of
the work to get the FCC to use the TSEC's MDIO bus.
>
> So I'd say quick solution: use TSEC1 MDIO for TSECs and cpm port pins
> for FCC, clean solution: change fcc_enet to use the PHY abstraction
> layer.
>
I'd say it depends on how long until your hardware is ready. You
might want to wire up the cpm IO pins, just in case. I have yet to
actually get the fs_enet driver to send packets on the 8560, so
there's no telling how long it will be before that driver works on 8541.
Andy
^ permalink raw reply
* Re: merge progress
From: Arnd Bergmann @ 2005-10-11 18:54 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: linuxppc-dev
In-Reply-To: <17227.44943.714106.911471@cargo.ozlabs.ibm.com>
On Dinsdag 11 Oktober 2005 14:26, Paul Mackerras wrote:
> With ARCH=ppc64, pSeries, iSeries, powermac and maple all build, and
> pSeries and iSeries have been boot-tested. I think I have broken
> BPA/cell because it was using pSeries_smp.c (I think we need to make
> cell have its own bpa_smp.c or whatever anyway).
I will fix that up when I move BPA over to arch/powerpc/platforms/cell.
Do you plan to have the whole merge tree included in 2.6.15? Otherwise
I'd rather postpone doing the structural changes on BPA until November,
because we're currently freezing our spufs development to 2.6.14 and
I'd like to have only one current set of big patches.
Arnd <><
^ permalink raw reply
* [PATCH] make gcc -O1 in fs/reiserfs optional
From: Olaf Hering @ 2005-10-11 19:01 UTC (permalink / raw)
To: Hans Reiser, Andrew Morton; +Cc: linuxppc-dev, reiserfs-dev, Jeff Mahoney
In-Reply-To: <426F9646.3000407@namesys.com>
On Wed, Apr 27, Hans Reiser wrote:
> Olaf Hering wrote:
>
> >Jeff,
> >
> >you added this EXTRA_CFLAGS= during 2.4 development, I think the broken
> >compiler was gcc 3.2 on SLES8. Can we turn this -O1 into a .config
> >option?
> Sounds reasonable.
only compile with -O1 if the (very old) compiler is broken
We use reiserfs alot in SLES9 on ppc64, and it was never seen
with gcc33.
Signed-off-by: Olaf Hering <olh@suse.de>
Index: linux-2.6.12-rc3-olh/fs/reiserfs/Makefile
===================================================================
--- linux-2.6.12-rc3-olh.orig/fs/reiserfs/Makefile
+++ linux-2.6.12-rc3-olh/fs/reiserfs/Makefile
@@ -21,13 +21,7 @@ ifeq ($(CONFIG_REISERFS_FS_POSIX_ACL),y)
reiserfs-objs += xattr_acl.o
endif
-# gcc -O2 (the kernel default) is overaggressive on ppc32 when many inline
-# functions are used. This causes the compiler to advance the stack
-# pointer out of the available stack space, corrupting kernel space,
-# and causing a panic. Since this behavior only affects ppc32, this ifeq
-# will work around it. If any other architecture displays this behavior,
-# add it here.
-ifeq ($(CONFIG_PPC32),y)
+ifeq ($(CONFIG_REISERFS_CC_REDUCE_OPTIMZE),y)
EXTRA_CFLAGS := -O1
endif
Index: linux-2.6.12-rc3-olh/fs/Kconfig
===================================================================
--- linux-2.6.12-rc3-olh.orig/fs/Kconfig
+++ linux-2.6.12-rc3-olh/fs/Kconfig
@@ -186,6 +186,18 @@ config REISERFS_FS
If you like it, you can pay us to add new features to it that you
need, buy a support contract, or pay us to port it to another OS.
+config REISERFS_CC_REDUCE_OPTIMZE
+ bool "Reduce CC optimization level to workaround compiler bugs"
+ depends on PPC32
+ default n
+ help
+ gcc -O2 (the kernel default) is overaggressive on ppc32 when many inline
+ functions are used. This causes the compiler to advance the stack
+ pointer out of the available stack space, corrupting kernel space,
+ and causing a panic. Since this behavior only affects ppc32, this ifeq
+ will work around it. If any other architecture displays this behavior,
+ add it here.
+
config REISERFS_CHECK
bool "Enable reiserfs debug mode"
depends on REISERFS_FS
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Compilation Error
From: Jeff Stevens @ 2005-10-11 19:51 UTC (permalink / raw)
To: linuxppc-embedded
I am trying to cross compile one of our drivers at
work to run on both an AMCC 440SP platform (Luan2),
and an MPC8540 platform (MPC8540ADS). I am using the
ELDK compilers (ppc_4xx-gcc and ppc_85xx-gcc), and the
kernel.org 2.6.13 source. I was getting warnings
about implicit declarations for both dma_cache_wback
and dma_cache_inv. I went ahead and replaced them
with clean_dcache_range and invalidate_dcache_range
(since that is what they are #defined to), and
included cache.h. So then I was able to get through
the compilation without the implicit declaration
warnings, but now when it does MODPOST, I get warnings
about clean_dcache_range and invalidate_dcache_range
being undefined! This driver was originally written
for x86 platforms where dma_cache_wback and
dma_cache_inv both are #defined to inline funtions
within io.h. Has anyone else seen this? I'm sure
it's most likely an include issue, but I'm not sure
what else to include. I have tried dma-mapping.h and
cache.h? Any help would be greatly appreciated.
Also, if this is the wrong place for this post, what
is the correct place for this question?
Thanks,
Jeff Stevens
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] make gcc -O1 in fs/reiserfs optional
From: Hans Reiser @ 2005-10-11 20:04 UTC (permalink / raw)
To: Olaf Hering; +Cc: Andrew Morton, linuxppc-dev, reiserfs-dev, Jeff Mahoney
In-Reply-To: <20051011190133.GA31348@suse.de>
Sounds good to me. Thanks Olaf!
Hans
Olaf Hering wrote:
> On Wed, Apr 27, Hans Reiser wrote:
>
>
>
>>Olaf Hering wrote:
>>
>>
>>
>>>Jeff,
>>>
>>>you added this EXTRA_CFLAGS= during 2.4 development, I think the broken
>>>compiler was gcc 3.2 on SLES8. Can we turn this -O1 into a .config
>>>option?
>>>
>>>
>
>
>
>>Sounds reasonable.
>>
>>
>
> only compile with -O1 if the (very old) compiler is broken
> We use reiserfs alot in SLES9 on ppc64, and it was never seen
> with gcc33.
>
>Signed-off-by: Olaf Hering <olh@suse.de>
>
>Index: linux-2.6.12-rc3-olh/fs/reiserfs/Makefile
>===================================================================
>--- linux-2.6.12-rc3-olh.orig/fs/reiserfs/Makefile
>+++ linux-2.6.12-rc3-olh/fs/reiserfs/Makefile
>@@ -21,13 +21,7 @@ ifeq ($(CONFIG_REISERFS_FS_POSIX_ACL),y)
> reiserfs-objs += xattr_acl.o
> endif
>
>-# gcc -O2 (the kernel default) is overaggressive on ppc32 when many inline
>-# functions are used. This causes the compiler to advance the stack
>-# pointer out of the available stack space, corrupting kernel space,
>-# and causing a panic. Since this behavior only affects ppc32, this ifeq
>-# will work around it. If any other architecture displays this behavior,
>-# add it here.
>-ifeq ($(CONFIG_PPC32),y)
>+ifeq ($(CONFIG_REISERFS_CC_REDUCE_OPTIMZE),y)
> EXTRA_CFLAGS := -O1
> endif
>
>Index: linux-2.6.12-rc3-olh/fs/Kconfig
>===================================================================
>--- linux-2.6.12-rc3-olh.orig/fs/Kconfig
>+++ linux-2.6.12-rc3-olh/fs/Kconfig
>@@ -186,6 +186,18 @@ config REISERFS_FS
> If you like it, you can pay us to add new features to it that you
> need, buy a support contract, or pay us to port it to another OS.
>
>+config REISERFS_CC_REDUCE_OPTIMZE
>+ bool "Reduce CC optimization level to workaround compiler bugs"
>+ depends on PPC32
>+ default n
>+ help
>+ gcc -O2 (the kernel default) is overaggressive on ppc32 when many inline
>+ functions are used. This causes the compiler to advance the stack
>+ pointer out of the available stack space, corrupting kernel space,
>+ and causing a panic. Since this behavior only affects ppc32, this ifeq
>+ will work around it. If any other architecture displays this behavior,
>+ add it here.
>+
> config REISERFS_CHECK
> bool "Enable reiserfs debug mode"
> depends on REISERFS_FS
>
>
^ permalink raw reply
* SPI driver for MPC8541
From: Bizhan Gholikhamseh (bgholikh) @ 2005-10-11 20:04 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 127 bytes --]
HI All,
Are there any SPI driver for MC8541? If there is, could someone point me
to it.
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 775 bytes --]
^ permalink raw reply
* Re: MPC8555 USB host support
From: Kylo Ginsberg @ 2005-10-11 20:29 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200510101900.58976.sr@denx.de>
Stefan,
I asked a similar question a few months back and found the comments
instructive. Google for a thread started with this subject: "MPC885 -
USB HCI drivers".
Kylo
On 10/10/05, Stefan Roese <sr@denx.de> wrote:
> I am wondering, if the USB host controller of the MPC8555 is supported at=
all
> right now. The manual states, that it is similar to, but not fully OHCI o=
r
> UHCI compatible. Any infos about this?
>
> Best regards,
> Stefan
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: SRAM support for the Pegasos II platform
From: Andrew Morton @ 2005-10-11 20:50 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev, sl, dholm
In-Reply-To: <20050914091229.A27721C007F7@mwinf0309.wanadoo.fr>
Nicolas DET <det.nicolas@free.fr> wrote:
>
> You can find enclosed or at the URL a patch for the 2.6.14-rc1.
> http://arrakin.homedns.org/~nicolas/mv643xx_eth_chrp_pegasos_eth.c.2.6.14-rc1.diff
>
> It allows (with drivers/net/mv643xx_eth.*) to take advantage of the SRAM of
> the Marvell Discovery II for the network driver.
I've kind of lost the plot with what happened with this patch. Who is the
maintainer of this driver, and has [s]he commented on this patch?
The patch does strange things with whitespace: some places it uses spaces,
other places it uses tabs. Please fix that up using hard tabs and resend.
When doing so, please first review
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt for the patch
preparation protocol, thanks.
^ permalink raw reply
* Re: [PATCH] MPC5200 - Make PCI work in 2.6 with the IceCube 5200
From: Sylvain Munaut @ 2005-10-11 23:22 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20051010193700.67266353ADC@atlas.denx.de>
Hi Wolfgang,
Weird, I would have thought the usage of in_be out_be macro ensured
that. But after checking, they only include a isync instruction which
doesn't guarantee memory access will be done while mb() uses sync that
does guarantee that.
Any one can comment on that ? Wasn't the purpose of the in_be out_be to
ensure that ?
Sylvain
Wolfgang Denk wrote:
> Hello,
>
> the following patch is against the current 2.6 kernel.org tree
> (commit f96c3bbe91117402f13119ce9e609db9087ed58f):
>
> As a prerequisite for a working system, the following two poatches
> are needed, too:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=2018
> http://patchwork.ozlabs.org/linuxppc/patch?id=2017
>
> \f
> !-------------------------------------------------------------flip-
>
> [patch] making PCI work in the MPC5200
> Patch by Alessandro Rubini, 08 Oct 2005
>
> Make PCI work in 2.6 with the IceCube 5200.
>
> Without the memory barriers all PCI config reads returned 0xffffffff
> (actually, there may be more mb() than needed). Using wmb(); was not
> enough to be able to read configuration registers.
>
> Signed-off by Alessandro Rubini <rubini@gnudd.com>
> Signed-off by Wolfgang Denk <wd@denx.de>
>
> ---
> commit cdd7fdf10b3cbb7eb82cacc7ba5dba3553020f49
> tree 97d045b44c87c00a4b3fe5bca57b479be87e68b6
> parent 509b5c9fcbfe7fcae7d4f98946e4dc9794d68645
> author Wolfgang Denk <wd@pollux.denx.de> Sat, 08 Oct 2005 22:41:53 +0200
> committer Wolfgang Denk <wd@pollux.denx.de> Sat, 08 Oct 2005 22:41:53 +0200
>
> arch/ppc/syslib/mpc52xx_pci.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/ppc/syslib/mpc52xx_pci.c b/arch/ppc/syslib/mpc52xx_pci.c
> --- a/arch/ppc/syslib/mpc52xx_pci.c
> +++ b/arch/ppc/syslib/mpc52xx_pci.c
> @@ -39,6 +39,7 @@ mpc52xx_pci_read_config(struct pci_bus *
> ((bus->number - hose->bus_offset) << 16) |
> (devfn << 8) |
> (offset & 0xfc));
> + mb();
>
> value = in_le32(hose->cfg_data);
>
> @@ -70,6 +71,7 @@ mpc52xx_pci_write_config(struct pci_bus
> ((bus->number - hose->bus_offset) << 16) |
> (devfn << 8) |
> (offset & 0xfc));
> + mb();
>
> if (len != 4) {
> value = in_le32(hose->cfg_data);
> @@ -80,9 +82,11 @@ mpc52xx_pci_write_config(struct pci_bus
>
> value &= ~mask;
> val = value | ((val << offset) & mask);
> + mb();
> }
>
> out_le32(hose->cfg_data, val);
> + mb();
>
> out_be32(hose->cfg_addr, 0);
>
>
>
> \f
> !-------------------------------------------------------------flip-
>
>
>
> Best regards,
>
> Wolfgang Denk
>
^ permalink raw reply
* [PATCH] ppc32: Fix timekeeping
From: Benjamin Herrenschmidt @ 2005-10-12 1:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list, Linus Torvalds
Interestingly enough, ppc32 had broken timekeeping for ages... It
worked, but probably drifted a bit more than could be explained by the
actual bad precision of the timebase calibration. We discovered that
recently when somebody figured out that the common code was using
CLOCK_TICK_RATE to correct the timekeeing, and ppc32 had a completely
bogus value for it.
This patch turns it into something saner. Probably not as good as doing
something based on the actual timebase frequency precision but I'll
leave that sort of math to others. This at least makes it better for the
common HZ values.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Please get that one in 2.6.14
Index: linux-work/include/asm-powerpc/timex.h
===================================================================
--- linux-work.orig/include/asm-powerpc/timex.h 2005-09-22 14:07:27.000000000 +1000
+++ linux-work/include/asm-powerpc/timex.h 2005-10-06 11:53:51.000000000 +1000
@@ -10,7 +10,7 @@
#include <linux/config.h>
#include <asm/cputable.h>
-#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
+#define CLOCK_TICK_RATE 1024000 /* Underlying HZ */
typedef unsigned long cycles_t;
^ permalink raw reply
* [PATCH 0/4] updated 440SPe support
From: Roland Dreier @ 2005-10-12 4:20 UTC (permalink / raw)
To: mporter; +Cc: linuxppc-embedded
Here is an updated 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, serial and PCI
Express in root port mode working (tested with an InfiniBand HCA,
naturally ;).
Since my last posting, I've fixed a few bugs (UIC3 interrupt handling
being the most notable fix) and implemented basic PCI Express support.
I left out the changes required for the old ibm_emac ethernet driver,
since I'm assuming Eugene's new driver will be merged, and his tree
already has 440SPe support.
I now have all the features I need for the project I'm working on, so
I don't expect to be adding much to my port. I will do whatever
cleanup, bugfixing and integration is required to get this merged
upstream. It looks like 2.6.15 will be opening up soon, so please let
me know if there's anything I can do to make merging easier.
I also have a git tree based on Eugene Surovegin's 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
^ permalink raw reply
* [PATCH 1/4] [PPC32] Allow ERPN for early serial to depend on CPU type
From: Roland Dreier @ 2005-10-12 4:20 UTC (permalink / raw)
To: mporter; +Cc: linuxppc-embedded
In-Reply-To: <200510112120.0zjEUfdtXtv77Emb@cisco.com>
The PowerPC 440SPe supports up to 16 GB of RAM, and therefore its IO
registers are at 0x4_xxxx_xxxx instead of being at 0x1_xxxx_xxxx 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@cisco.com>
---
arch/ppc/kernel/head_44x.S | 4 ++--
include/asm-ppc/ibm44x.h | 7 ++++++-
2 files changed, 8 insertions(+), 3 deletions(-)
applies-to: 191b41b19d91b0893c5699fa3ff5ca984841b7a7
00f2126e653cc45212ae72aa0cac150eff712087
diff --git a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S
index 599245b..92bf8ab 100644
--- a/arch/ppc/kernel/head_44x.S
+++ b/arch/ppc/kernel/head_44x.S
@@ -190,8 +190,8 @@ skpinv: addi r4,r4,1 /* Increment */
/* xlat fields */
lis r4,UART0_PHYS_IO_BASE@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
index e5374be..197a9ff 100644
--- 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_SLOT 63
-/* 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_ERPN 1
#define UART0_PHYS_IO_BASE 0xf0000200
#elif defined(CONFIG_440EP)
#define UART0_PHYS_IO_BASE 0xe0000000
#else
+#define UART0_PHYS_ERPN 1
#define UART0_PHYS_IO_BASE 0x40000200
#endif
---
0.99.8.GIT
^ permalink raw reply related
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