* Re: [PATCH] ppc: add support for new powerbooks
From: Olof Johansson @ 2005-11-10 16:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20051109213837.47c8dce7.akpm@osdl.org>
On Wed, Nov 09, 2005 at 09:38:37PM -0800, Andrew Morton wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> I don't think I'm adding much value handling ppc/ppc64 patches, really.
> I'd prefer to get out of that business.
Main benefit for me, as a patch submitter, is that you consistently,
always, ACK when you pick up or drop a patch. In other words, I don't
have to go polling a tree to see if it made it in or not.
> It would be better to have an arch maintainer who runs a git tree, same as
> ia64, arm, etc.
>
> And, given the amount of shared infrastructure, I suspect it would have to
> be a single git tree for both architectures.
>
> I'd still sweep up random ppc patches, but those will go into mainline via the
> originator->mm->git-powerpc->linus route.
>
> Possible?
I'm fine with all that; to be honest I haven't been certain where the
smaller ppc/ppc64 patches should go during this whole merge business (or
after, for that matter).
If Paulus wants to start an arch tree, that's fine with me. I do share
Ben's opinion about less review though, I guess we'll just have to deal
with that.
Also, Paul, I kindly request some sort of ACK mechanism similar to
Andrew's when patches are picked up. :-)
Thanks,
-Olof
^ permalink raw reply
* [PATCH] ppc32: fix PQ2 PCI DMA interrupt handling
From: Kumar Gala @ 2005-11-10 16:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc-embedded
The bit position in the status register corresponding to the
PCI DMA interrupt was incorrect. Additionally, we did not
have a define for the PCI DMA interrupt.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 6a9fa9805be85c33a177061d6bf4f4c2a95c9c7e
tree 2a72692b7373d2f4d328aee3652ece9d9ff7e750
parent b23f8a20b85440d4bebf1a2ddea5830ca85ff655
author Kumar Gala <galak@kernel.crashing.org> Thu, 10 Nov 2005 10:35:15 -0600
committer Kumar Gala <galak@kernel.crashing.org> Thu, 10 Nov 2005 10:35:15 -0600
arch/ppc/syslib/cpm2_pic.c | 2 +-
include/asm-powerpc/irq.h | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/syslib/cpm2_pic.c b/arch/ppc/syslib/cpm2_pic.c
index c867be6..29d95d4 100644
--- a/arch/ppc/syslib/cpm2_pic.c
+++ b/arch/ppc/syslib/cpm2_pic.c
@@ -37,7 +37,7 @@ static u_char irq_to_siureg[] = {
static u_char irq_to_siubit[] = {
0, 15, 14, 13, 12, 11, 10, 9,
8, 7, 6, 5, 4, 3, 2, 1,
- 2, 1, 15, 14, 13, 12, 11, 10,
+ 2, 1, 0, 14, 13, 12, 11, 10,
9, 8, 7, 6, 5, 4, 3, 0,
31, 30, 29, 28, 27, 26, 25, 24,
23, 22, 21, 20, 19, 18, 17, 16,
diff --git a/include/asm-powerpc/irq.h b/include/asm-powerpc/irq.h
index b3935ea..921bfa9 100644
--- a/include/asm-powerpc/irq.h
+++ b/include/asm-powerpc/irq.h
@@ -389,6 +389,7 @@ extern u64 ppc64_interrupt_controller;
#define SIU_INT_TIMER4 ((uint)0x0f + CPM_IRQ_OFFSET)
#define SIU_INT_TMCNT ((uint)0x10 + CPM_IRQ_OFFSET)
#define SIU_INT_PIT ((uint)0x11 + CPM_IRQ_OFFSET)
+#define SIU_INT_PCI ((uint)0x12 + CPM_IRQ_OFFSET)
#define SIU_INT_IRQ1 ((uint)0x13 + CPM_IRQ_OFFSET)
#define SIU_INT_IRQ2 ((uint)0x14 + CPM_IRQ_OFFSET)
#define SIU_INT_IRQ3 ((uint)0x15 + CPM_IRQ_OFFSET)
^ permalink raw reply related
* Re: PowerPC reservations
From: Michael R. Zucca @ 2005-11-10 15:20 UTC (permalink / raw)
To: Kalle Pokki; +Cc: linuxppc-embedded
In-Reply-To: <437302CE.8070309@iki.fi>
Kalle Pokki wrote:
> Am I just not getting how this is really supposed to work? Are there
> still some other constructs in use to prevent this, e.g. extra stwcx.
> instructions when changing the thread of execution?
Yes. When a context switch occurs, there's a stcwx. to clear any
reservations from the previous thread. When you enter another thread
from a context switch, you enter it with no reservations pending.
So you might have something that looks like this:
thread 1 -> lwarx w/ successful reservation
context switch -> stwcx.. to garbage location to clear any reservations
thread 2 -> stwcx. fails since there's no reservation pending
context switch -> stwcx. to garbage location to clear any reservations
thread 1 -> stwcx. fails since there's no reservation pending
thread 1 -> loops to try lwarx again
So the context switcher protects a reservation from "leaking" into
another thread. In that sense, you can act as though lwarx/stwcx. pairs
belong to a single thread.
The other important thing to remember is that there can only be one
outstanding reservation. Thus, lwarx and stcwx. instructions have to be
"paired" or you're going to get unexpected results.
^ permalink raw reply
* SCC QMC driver for 8247
From: Robin Mathew @ 2005-11-10 14:48 UTC (permalink / raw)
To: Linuxppc-embedded; +Cc: Nicholas Basker
Hello:
We are working on implementing driver for SCC operating in QMC mode that
supports multiple HDLC channels. The details of the system we are using
are the following.
CPU Version = 8247 based on 82xx family of processor(PVR 80822014)
The Linux OS Version = DENKS Linux version 2.4.20.
The Peripherals used are = FCC1 in 10/100 ethernet
FCC2 in 10/100 ethernet
SCC1 currently not used, but
proposed to be used in HDLC mode.
SCC3 is not used.
SCC4 operating in QMC mode
with super -channel capability. Trying to operate 192kbps HDLC channel
(using 3x64kbps QMC channels).
SMC2 in UART mode (as a
simple debug port without any modem signals).
SPI interface currently not
used but shall be used in future.
I2C is being used.
01. Can the channel specific parameters of the SCC4 in QMC mode be
relocated from DPRAM base address?? There is no mention in the
8272RM.pdf about configuring the base address of channel specific
parameters. From the QMC memory structure diagram, it looks like the
channel specific parameters will be taken from the the DPRAM base
address. Can you please confirm it?
02. We have changed the function m8260_cpm_dpalloc() used for DPRAM
allocation in the linux source code. It was allocating memory from
128Byte location to 8KByte location in DPRAM. But since QMC requires the
lower 4KByte for channel specific parameters, we changed the function to
allocate DPRAM from 4KByte location. Will this change lead to any
problem for proper linux operation?
03. We are encountering a strange problem with scc4 parameter RAM. When
the driver is coming up, its trying to initialize the SCC4 parameter RAM
for QMC. In the location (immr + 0x8318), we are writing the value
0x8320 but the value magically changes to 0x8300. We tried to write to
the location using BDI and again the problem is seen. Is this a known
problem with the processor?? This problem doesnot appear everytime. Is
there any known cause for this problem?
Regards,
Robin
^ permalink raw reply
* floating point + kernel (PPC)
From: srideep.devireddy @ 2005-11-10 12:37 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]
Thanks for your help friends ...
I am able to bring my kernel up ...... right now I have a problem
after some time at the console .... I get floating point used in kernel
(task=C0188480,pc=1100)
10.0.0.2 login: root
Last login: Tnhu Jan 1 00:00sole
Linux 10.0.0.2 2.4.22 #1 Tue Nov 8 12:03:26 UTC 2005 ppc unknown
MontaVista(R) Linux(R) Professional Edition 3.1
root@10.0.0.2:~# <mailto:root@10.0.0.2:~>
root@10.0.0.2:/home# cd ..
root@10.0.0.2:/# ls
bin boot dev etc home lib mnt opt proc root sbin tmp usr
var
root@10.0.0.2:/# floating point used in kernel (task=c0188480, pc=1100)
What does this mean ...? This makes the console hang .....Can any 1 help
me on in this?
Best Regards
srideep
Confidentiality Notice
The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
[-- Attachment #2: Type: text/html, Size: 7550 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32 8xx: MPC8xx PCMCIA update
From: Dominik Brodowski @ 2005-11-10 10:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-ppc-embedded
In-Reply-To: <17262.42993.975296.653728@cargo.ozlabs.ibm.com>
Hi,
On Mon, Nov 07, 2005 at 12:03:45PM +1100, Paul Mackerras wrote:
> Marcelo Tosatti writes:
>
> > The following patch updates the MPC8xx PCMCIA driver:
>
> This and the following patch look OK as far as I can tell - Dominik,
> will you take care of sending them to Linus?
Yes, will do.
Thanks,
Dominik
^ permalink raw reply
* Re: "Now booting the kernel"
From: Nathael PAJANI @ 2005-11-10 10:40 UTC (permalink / raw)
To: linuxppc-embedded
(Sorry, I first replyed with the wrong mail address)
>Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
>Uncompressing Linux...done.
>Now booting the kernel
Hi!
At this state the bootloader stops executing and the Linux Kernel
starts. The problem is that the Linux kernel does not know yet how to
use the serial.
You won't have any message before it is set up (in early-console if my
memory is allright)
So what you can do to check what's going on, is put "breakpoints" in the
boot sequence. This means in the file arch/ppc/kernel/head*.S used for
your board you should try to comment the line with the "tlbwe"
instruction in the section "/* 2. Invalidate all entries except the
entry we're executing in */"
This will allow you to keep access to your board registers.
Then you go step by step, putting some code which will reboot the board
when executed, so you know you're going up to that point, and then move
the "breakpoint" further.
This code does the reboot (for the booke I can reboot the board by
writting '4' at address 0xfa001001):
ASM:
lis r4,0xfa00
li r5,4
stb r5,0x1001(r4)
msync
C:
*((volatile unsigned char*)0xfa001001 = 4;
This way, instead of hanging up, the board reboots and you know where
you are.
If you're going up to this:
bl machine_init /* arch/ppc/kernel/setup.c */
bl MMU_init /* arch/ppc/mm/init.c */
It's quite good, these are C functions, but they are processor specific,
once again, check that the ones used (compiled) are those you need.
And next you've got the "start_kernel" call, which leads you to C code
definitely. It's in init/main.c.
I hope I did not tell anything wrong, and that this will help.
Have fun.
Nathael.
^ permalink raw reply
* Re: "Now booting the kernel"
From: Nathael PAJANI @ 2005-11-10 8:46 UTC (permalink / raw)
To: linuxppc-embedded
>Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
>Uncompressing Linux...done.
>Now booting the kernel
Hi!
At this state the bootloader stops executing and the Linux Kernel
starts. The problem is that the Linux kernel does not know yet how to
use the serial.
You won't have any message before it is set up (in early-console if my
memory is allright)
So what you can do to check what's going on, is put "breakpoints" in the
boot sequence. This means in the file arch/ppc/kernel/head*.S used for
your board you should try to comment the line with the "tlbwe"
instruction in the section "/* 2. Invalidate all entries except the
entry we're executing in */"
This will allow you to keep access to your board registers.
Then you go step by step, putting some code which will reboot the board
when executed, so you know you're going up to that point, and then move
the "breakpoint" further.
This code does the reboot (for the booke I can reboot the board by
writting '4' at address 0xfa001001):
ASM:
lis r4,0xfa00
li r5,4
stb r5,0x1001(r4)
msync
C:
*((volatile unsigned char*)0xfa001001 = 4;
This way, instead of hanging up, the board reboots and you know where
you are.
If you're going up to this:
bl machine_init /* arch/ppc/kernel/setup.c */
bl MMU_init /* arch/ppc/mm/init.c */
It's quite good, these are C functions, but they are processor specific,
once again, check that the ones used (compiled) are those you need.
And next you've got the "start_kernel" call, which leads you to C code
definitely. It's in init/main.c.
I hope I did not tell anything wrong, and that this will help.
Have fun.
Nathael.
^ permalink raw reply
* PowerPC reservations
From: Kalle Pokki @ 2005-11-10 8:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Can someone please help me understand how the memory reservations in
PowerPC actually work. Let's just assume uniprocessor with a pre-emptive
scheduler, and take a text-book example of an atomic increment case,
which is also frequently used in e.g. the Linux kernel. With two atomic
operations, everything seems to be just fine. But how about with three
concurrent threads of execution?
From the following code, assume r3 contains the same address for each
incrementing operation. If the first atomic increment is pre-empted in
the middle, execution then jumps to the second increment (by the
scheduler). The second increment runs through and succeeds, and
continues straight to the third increment. Then it is again pre-empted
in the middle, execution returning to the first increment. Now the
processor has the reservation with the correct address, and the first
increment succeeds when still holding the original input value. The
first and the second increment thus write the same value in memory.
After the first increment, the scheduler again continues the third
increment, which doesn't succeed a first, but the second round succeeds.
However, the value in the address pointed by r3 was not increased by
three, but by two.
Am I just not getting how this is really supposed to work? Are there
still some other constructs in use to prevent this, e.g. extra stwcx.
instructions when changing the thread of execution?
I'm also wondering why the architecture specifically defines the stwcx.
instruction to have, well, undefined behavior in case the reservation
address differs from the address of the previous lwarx...
1: lwarx r6, r0, r3
addi r6, r6, 1
stwcx. r6, r0, r3
bne- 1b
.....
2: lwarx r7, r0, r3
addi r7, r7, 1
stwcx. r7, r0, r3
bne- 2b
3: lwarx r8, r0, r3
addi r8, r8, 1
stwcx. r8, r0, r3
bne- 3b
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: David Jander @ 2005-11-10 8:18 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200511100848.46263.david.jander@protonic.nl>
On Thursday 10 November 2005 08:48, David Jander wrote:
>[...]
> Hmmm. This is a lot in the line of the tests I did with (the more generic
> benchmark) nbench. After looking at those results (see my other post in
> this thread) I already suspected something like this.
Sorry, I obviously did not mean this thread, but the following post on another
thread:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-November/020775.html
Regards,
--
David Jander
^ permalink raw reply
* [PATCH] 2.6: PRTPPC board-support was: Re: about MPC 8XX SPI Driver
From: David Jander @ 2005-11-10 8:02 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: 徐小威的EMAIL
In-Reply-To: <1131605445.4691.4.camel@banana>
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
On Thursday 10 November 2005 07:50, 徐小威的EMAIL wrote:
> Anybody know where can found 'CPM SPI Driver' for MPC852T.I found a
> cpm_spi.c at /arch/ppc/8260_io directory in Linux 2.4.25.But I don't
> know how to program application to
> handle this driver.
Do you want it for 2.4 or 2.6? (I have both running on a mpc852T).
Here's a patch for 2.6.14 (denx-git tree).
Sorry to send you the complete patch for prtppc board support, but the spi
driver makes up most part of it, so it wouldn't be much smaller anyway ;-)
Regards,
--
David Jander
Protonic Holland.
[-- Attachment #2: linux-2.6.14-20051107-prt.patch --]
[-- Type: text/x-diff, Size: 33276 bytes --]
diff --git a/arch/ppc/8xx_io/Kconfig b/arch/ppc/8xx_io/Kconfig
--- a/arch/ppc/8xx_io/Kconfig
+++ b/arch/ppc/8xx_io/Kconfig
@@ -77,6 +77,14 @@ config ENET_BIG_BUFFERS
config HTDMSOUND
bool "Embedded Planet HIOX Audio"
depends on SOUND=y
+
+config CPM_SPI
+ bool "Simple CPM SPI driver"
+
+config CPM_SPI_BDSIZE
+ int "Size of Rx/Tx Buffer for SPI"
+ depends on CPM_SPI
+ default "16"
# This doesn't really belong here, but it is convenient to ask
# 8xx specific questions.
diff --git a/arch/ppc/8xx_io/Makefile b/arch/ppc/8xx_io/Makefile
--- a/arch/ppc/8xx_io/Makefile
+++ b/arch/ppc/8xx_io/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_FEC_ENET) += fec.o
obj-$(CONFIG_SCC_ENET) += enet.o
obj-$(CONFIG_UCODE_PATCH) += micropatch.o
obj-$(CONFIG_HTDMSOUND) += cs4218_tdm.o
+obj-$(CONFIG_CPM_SPI) += cpm_spi.o
diff --git a/arch/ppc/8xx_io/cpm_spi.c b/arch/ppc/8xx_io/cpm_spi.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/8xx_io/cpm_spi.c
@@ -0,0 +1,448 @@
+/*
+ * Simple CPM SPI interface for the MPC 8xx.
+ *
+ * Copyright (c) 2002 Wolfgang Grandegger (wg@denx.de)
+ *
+ * This interface is partially derived from code copyrighted
+ * by Navin Boppuri (nboppuri@trinetcommunication.co) and
+ * Prashant Patel (pmpatel@trinetcommunication.com).
+ *
+ * This driver implements the function "cpm_spi_io()" to be
+ * used by other drivers and a simple read/write interface
+ * for user-land applications. The latter is mainly useful
+ * for debugging purposes. Some further remarks:
+ *
+ * - Board specific definitions and code should go into
+ * the file "cpm_spi.h".
+ *
+ * - For the moment, no interrupts are used. This be useful
+ * for (very) long transfers.
+ *
+ * Ported back from 2.4.25/mpc82xx to 2.6.14/mpc8xx by
+ * David Jander (david@protonic.nl)
+ *
+ */
+
+#ifndef EXPORT_SYMTAB
+# define EXPORT_SYMTAB /* need this one 'cause we export symbols */
+#endif
+
+#include <linux/config.h>
+#include <linux/module.h>
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/fs.h>
+#include <linux/errno.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/delay.h>
+#include <linux/proc_fs.h>
+#include <linux/device.h>
+#include <asm/page.h>
+#include <asm/uaccess.h>
+#include <asm/io.h>
+
+#include <asm/8xx_immap.h>
+#include <asm/mpc8xx.h>
+
+#include <asm/commproc.h>
+#include <asm/cpm_spi.h>
+
+#define DRIVER_NAME "cmp_spi"
+
+MODULE_AUTHOR("Wolfgang Grandegger (wg@denx.de)");
+MODULE_DESCRIPTION("Simple Driver for the CPM SPI");
+
+#undef DEBUG
+#ifdef DEBUG
+# define debugk(fmt,args...) printk(fmt ,##args)
+#else
+# define debugk(fmt,args...)
+#endif
+
+#if defined(CONFIG_SCC2_ENET) && !defined(CONFIG_UCODE_PATCH)
+#error "I2C/SPI Microcode Patch is needed, please enable it!"
+#endif
+
+#define CPM_SPI_MAJOR 65 /* "borrowed" from "plink" driver */
+
+extern void invalidate_dcache_range(unsigned long start, unsigned long end);
+
+static volatile immap_t *immap = (immap_t *)IMAP_ADDR;
+
+static unsigned int dp_addr;
+static ushort r_tbase, r_rbase;
+static cbd_t *tx_bdf, *rx_bdf;
+static u_char *tx_buf, *rx_buf;
+
+#if CPM_SPI_SWAP_BYTES
+static void swap_bytes(u_char *buf, int len)
+{
+ u_short *sbuf = (u_short *)buf;
+ while (len > 0) {
+ *sbuf = cpu_to_le16(*sbuf);
+ sbuf++;
+ len -= 2;
+ }
+}
+#else
+#define swap_bytes(buf, len)
+#endif
+
+/*
+ * CPM SPI Kernel API function(s)
+ */
+ssize_t cpm_spi_io (int chip_id, int serial,
+ u_char *tx_buffer, int tx_size,
+ u_char *rx_buffer, int rx_size)
+{
+ unsigned long flags;
+ int i;
+
+ /*
+ * Serialize access to the SPI. We have to disable interrupts
+ * because we may need to call it from interrupt handlers.
+ */
+ local_irq_save(flags); local_irq_disable();
+
+ rx_bdf->cbd_datlen = 0;
+ if (serial)
+ tx_bdf->cbd_datlen = tx_size + rx_size;
+ else
+ tx_bdf->cbd_datlen = tx_size > rx_size ? tx_size : rx_size;
+ if (tx_bdf->cbd_datlen > CONFIG_CPM_SPI_BDSIZE) {
+ printk("cpm_spi_io: Invalid size\n");
+ local_irq_restore(flags);
+ return -EINVAL;
+ }
+ if (tx_size > 0) {
+ memcpy(tx_buf, tx_buffer, tx_size);
+#ifdef DEBUG
+ printk("Tx:");
+ for (i = 0; i < tx_size; i++)
+ printk(" %02x", tx_buf[i]);
+ printk("\n");
+#endif
+ swap_bytes(tx_buf, tx_size);
+ }
+
+ flush_dcache_range((unsigned long) tx_buf,
+ (unsigned long) (tx_buf+CONFIG_CPM_SPI_BDSIZE-1));
+ flush_dcache_range((unsigned long) rx_buf,
+ (unsigned long) (rx_buf+CONFIG_CPM_SPI_BDSIZE-1));
+ invalidate_dcache_range((unsigned long) rx_buf,
+ (unsigned long) (rx_buf+
+ CONFIG_CPM_SPI_BDSIZE-1));
+
+ /* Setting Rx and Tx BD status and data length */
+ tx_bdf->cbd_sc = BD_SC_READY | BD_SC_LAST | BD_SC_WRAP;
+ rx_bdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP;
+
+ /* Chip select for device */
+ cpm_spi_set_cs(immap, chip_id, 1);
+
+ /* Start SPI Tx/Rx transfer */
+ cpmp->cp_spcom |= 0x80;
+
+ /*
+ * Wait until the Tx/Rx transfer is done.
+ */
+ for (i = 0; i < CPM_SPI_POLL_RETRIES; i++) {
+ udelay(1);
+ if ((tx_bdf->cbd_sc & BD_SC_EMPTY) == 0 &&
+ (rx_bdf->cbd_sc & BD_SC_EMPTY) == 0)
+ break;
+ }
+
+ /* De-select device */
+ cpm_spi_set_cs(immap, chip_id, 0);
+
+ /* Check for timeout */
+ if (i == CPM_SPI_POLL_RETRIES) {
+ printk("cpm_spi_io: Tx/Rx transfer timeout\n");
+ local_irq_restore(flags);
+ return -EIO;
+ }
+
+#ifdef DEBUG
+ printk("Transfer time approx. %d us\n", i);
+ if (rx_bdf->cbd_datlen > 0) {
+ printk("Rx:");
+ for (i = 0; i < rx_bdf->cbd_datlen; i++)
+ printk(" %02x", rx_buf[i]);
+ printk("\n");
+ }
+#endif
+
+ /* Copy receive data if appropriate */
+ i = rx_bdf->cbd_datlen;
+#ifdef DEBUG
+ if (i != tx_bdf->cbd_datlen)
+ {
+ printk("i=%d tx_size=%d rx_size=%d\n", i, tx_size, rx_size);
+ }
+#endif
+ if (i > tx_bdf->cbd_datlen)
+ {
+ local_irq_restore(flags);
+ return -EIO;
+ }
+ swap_bytes(rx_buf, i);
+ if (rx_size > 0) {
+ if (serial) {
+ i -= tx_size;
+ memcpy(rx_buffer, rx_buf + tx_size, i);
+ } else {
+ memcpy(rx_buffer, rx_buf, i);
+ }
+ }
+
+ local_irq_restore(flags);
+
+ return i;
+}
+
+EXPORT_SYMBOL(cpm_spi_io);
+
+/*
+ * Prototypes for driver entry functions.
+ */
+static int
+cpm_spi_open(struct inode *inode, struct file *filp);
+static int
+cpm_spi_release(struct inode *inode, struct file *filp);
+static ssize_t
+cpm_spi_read(struct file *filp, char *buf, size_t count, loff_t *f_pos);
+static ssize_t
+cpm_spi_write(struct file *filp, const char *buf, size_t count, loff_t *f_pos);
+static int
+cpm_spi_init(void);
+static void
+cpm_spi_cleanup(void);
+
+/*
+ * File operations supported by this driver.
+ */
+struct file_operations cpm_spi_fops = {
+ owner: THIS_MODULE,
+ open: cpm_spi_open,
+ release: cpm_spi_release,
+ read: cpm_spi_read,
+ write: cpm_spi_write,
+};
+
+
+static int
+cpm_spi_open (struct inode *inode, struct file *filp)
+{
+ int minor = MINOR(inode->i_rdev);
+
+ if (minor >= CPM_SPI_MAX_CHIPS)
+ return -ENODEV;
+
+ filp->private_data = (void *)minor;
+ // MOD_INC_USE_COUNT;
+ return 0;
+}
+
+static int
+cpm_spi_release(struct inode *inode, struct file *filp)
+{
+ // MOD_DEC_USE_COUNT;
+ return 0;
+}
+
+static ssize_t
+cpm_spi_read(struct file *filp, char *buf, size_t count, loff_t *f_pos)
+{
+ u_char tx_kbuf[CONFIG_CPM_SPI_BDSIZE];
+ u_char rx_kbuf[CONFIG_CPM_SPI_BDSIZE];
+ int chip_id = (int)filp->private_data;
+ ssize_t size;
+
+ debugk("cpm_spi_read: count=%d, chip_id=%d\n", count, chip_id);
+
+ if (count > CONFIG_CPM_SPI_BDSIZE)
+ return -ENXIO;
+
+ if (copy_from_user(tx_kbuf, buf, count))
+ return -EFAULT;
+
+ size = cpm_spi_io(chip_id, 0, tx_kbuf, count, rx_kbuf, count);
+ if (size < 0)
+ return size;
+
+ if (copy_to_user(buf, rx_kbuf, size))
+ return -EFAULT;
+
+ return size;
+}
+
+static ssize_t
+cpm_spi_write(struct file *filp, const char *buf, size_t count, loff_t *f_pos)
+{
+ int chip_id = (int)filp->private_data;
+ u_char tx_kbuf[CONFIG_CPM_SPI_BDSIZE];
+
+ if (count > CONFIG_CPM_SPI_BDSIZE)
+ return -ENXIO;
+
+ if (copy_from_user(tx_kbuf, buf, count))
+ return -EFAULT;
+
+ return cpm_spi_io(chip_id, 0, tx_kbuf, count, NULL, 0);
+}
+
+/* Tx and Rx buffers are so small, we don't need to worry about
+ * consistent alloc. Just make them static here (ugly, but simple).
+ */
+static unsigned char txbufspace[CONFIG_CPM_SPI_BDSIZE];
+static unsigned char rxbufspace[CONFIG_CPM_SPI_BDSIZE];
+
+static int
+cpm_spi_init(void)
+{
+ int err = 0;
+ volatile spi_t *spi;
+
+
+ printk (KERN_INFO "CPM SPI Driver: $Revision: 1.1 $ wg@denx.de\n");
+
+ /* Global pointer to internal registers */
+ immap = (immap_t *)IMAP_ADDR;
+
+ spi = (spi_t *)&cpmp->cp_dparam[PROFF_SPI];
+
+#ifdef USE_IIC_PATCH
+ /* Check for and use a microcode relocation patch. */
+ if (spi->spi_rpbase)
+ spi = (spi_t *)&cpmp->cp_dpmem[spi->spi_rpbase];
+ printk("cpm_spi: using microcode patch (spi_rpbase=0x%p)\n", spi);
+#endif
+
+ /*
+ * Initialize the parameter RAM. We need to make sure
+ * many things are initialized to zero, especially in
+ * the case of a microcode patch.
+ */
+ spi->spi_rdp = 0;
+ spi->spi_rbptr = 0;
+ spi->spi_rbc = 0;
+ spi->spi_rxtmp = 0;
+ spi->spi_tstate = 0;
+ spi->spi_tdp = 0;
+ spi->spi_tbptr = 0;
+ spi->spi_tbc = 0;
+ spi->spi_txtmp = 0;
+
+ /*
+ * Allocate space for one transmit and one receive buffer
+ * descriptor in the DP RAM.
+ */
+ dp_addr = cpm_dpalloc(sizeof(cbd_t) * 2,0);
+ if (dp_addr == CPM_DP_NOSPACE) {
+ printk("cpm_spi: m8xx_cpm_dpalloc() failed\n");
+ return -ENOMEM;
+ }
+
+ /*
+ * Set up the IIC parameters in the parameter RAM.
+ */
+ spi->spi_rbase = r_rbase = dp_addr;
+ spi->spi_tbase = r_tbase = dp_addr + sizeof(cbd_t);
+
+ /*
+ * Setting transmit and receive buffer descriptor pointers
+ * intially to rbase and rbase.
+ */
+ spi->spi_rbptr = spi->spi_rbase;
+ spi->spi_tbptr = spi->spi_tbase;
+
+ /* Setting CPCR */
+ while(cpmp->cp_cpcr & CPM_CR_FLG) ;
+ cpmp->cp_cpcr |=
+ mk_cr_cmd(CPM_CR_CH_SPI, CPM_CR_INIT_TRX) | CPM_CR_FLG;
+ udelay(1);
+ while(cpmp->cp_cpcr & CPM_CR_FLG) ;
+
+ /* Sets the SDMA configuration register. */
+ immap->im_siu_conf.sc_sdcr = 0x0001;
+
+ /* Set to big endian. */
+ spi->spi_tfcr = SMC_EB;
+ spi->spi_rfcr = SMC_EB;
+
+ /* Set maximum receive size. */
+ spi->spi_mrblr = CONFIG_CPM_SPI_BDSIZE;
+
+ /*
+ * Clear all pending SPI events and mask all possible SPI
+ * interrupts. For the moment we don't use interrupts.
+ */
+ cpmp->cp_spie = 0xff;
+ cpmp->cp_spim = 0x00;
+
+ /*
+ * Set SPI Mode register.
+ * Note: the board-specific definitions are in cpm_spi.h.
+ */
+ cpmp->cp_spmode = CPM_SPI_SPMODE | SPMODE_EN;
+
+ /*
+ * Initiliaze port pins for SPI
+ * par dir odr
+ * PB28 -> SPIMISO: 1 1 0
+ * PB29 -> SPIMOSI: 1 1 0
+ * PB30 -> SPICLK : 1 1 0
+ */
+ cpmp->cp_pbpar |= 0x000e;
+ cpmp->cp_pbdir |= 0x000e;
+ cpmp->cp_pbodr &= ~(0x000e);
+
+ /*
+ * Initialize board-specific port for chip select etc.
+ * Note: the board-specific definitions are in cpm_spi.h.
+ */
+ cpm_spi_init_ports(immap);
+
+ /* Tx and Rx buffer descriptors. */
+ tx_bdf = (cbd_t *)&cpmp->cp_dpmem[r_tbase];
+ rx_bdf = (cbd_t *)&cpmp->cp_dpmem[r_rbase];
+
+ /* Initialize Tx and Tx BD's */
+ rx_bdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP;
+ tx_bdf->cbd_sc = BD_SC_LAST | BD_SC_WRAP;
+
+ /* Allocate memory for Rx and Tx buffers */
+ tx_buf = (u_char *)txbufspace;
+ rx_buf = (u_char *)rxbufspace;
+ debugk("rxbuf = 0x%p tx_buf = 0x%p\n", rx_buf, tx_buf);
+
+ /* Set the bd's rx and tx buffer address pointers */
+ tx_bdf->cbd_bufaddr = virt_to_bus(tx_buf);
+ rx_bdf->cbd_bufaddr = virt_to_bus(rx_buf);
+ debugk("pa:rxbuf = 0x%p pa:tx_buf = 0x%p\n", rx_bdf->cbd_bufaddr, tx_bdf->cbd_bufaddr);
+
+ /*
+ * Finally register the driver.
+ */
+ err = register_chrdev(CPM_SPI_MAJOR, DRIVER_NAME, &cpm_spi_fops);
+ if (err < 0) {
+ printk("cpm_spi: Couldn't register driver (major=%d)\n",
+ CPM_SPI_MAJOR);
+ return err;
+ }
+
+ return 0;
+}
+
+static void
+cpm_spi_cleanup(void)
+{
+ unregister_chrdev(CPM_SPI_MAJOR, DRIVER_NAME);
+ cpm_dpfree(dp_addr);
+}
+
+module_init(cpm_spi_init);
+module_exit(cpm_spi_cleanup);
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -504,6 +504,13 @@ config WINCEPT
MPC821 PowerPC, introduced in 1998 and designed to be used in
thin-client machines. Say Y to support it directly.
+config PRTPPC
+ bool "PRTPPC"
+ help
+ PRTPPC is a single-board computer module based on a Freescale MPC852T
+ embedded processor. It is used in different products designed and
+ manufactured by Protonic Holland.
+
endchoice
choice
@@ -954,6 +961,16 @@ config NR_CPUS
config HIGHMEM
bool "High memory support"
+config PRT_IOADDR
+ hex "PRTPPC IO-address space start"
+ depends on PRTPPC
+ default "0xf8100000"
+
+config PRT_IOSIZE
+ hex "PRTPPC IO-address space size"
+ depends on PRTPPC
+ default "0x00040000"
+
source kernel/Kconfig.hz
source kernel/Kconfig.preempt
source "mm/Kconfig"
diff --git a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile
--- a/arch/ppc/platforms/Makefile
+++ b/arch/ppc/platforms/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SBC82xx) += sbc82xx.o
obj-$(CONFIG_SPRUCE) += spruce.o
obj-$(CONFIG_LITE5200) += lite5200.o
obj-$(CONFIG_EV64360) += ev64360.o
+obj-$(CONFIG_PRTPPC) += prtppc_setup.o
ifeq ($(CONFIG_SMP),y)
obj-$(CONFIG_PPC_PMAC) += pmac_smp.o
diff --git a/arch/ppc/platforms/prtppc.h b/arch/ppc/platforms/prtppc.h
new file mode 100644
--- /dev/null
+++ b/arch/ppc/platforms/prtppc.h
@@ -0,0 +1,40 @@
+/*
+ * PRTPPC board definitions, loosely based on:
+ * TQM8xx(L/M) board specific definitions
+ *
+ * Author: David Jander <david@protonic.nl>
+ *
+ * Copyright (c) 2005 Protonic Holland b.v.
+ *
+ * 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.
+ */
+
+#ifndef __PRTPPC_H__
+#define __PRTPPC_H__
+
+#include <linux/config.h>
+
+#include <asm/ppcboot.h>
+
+#define BOARD_CHIP_NAME "MPC86X"
+
+#define PRTPPC_IMMR_BASE 0xF8000000 /* phys. addr of IMMR */
+#define PRTPPC_IMAP_SIZE (64 * 1024) /* size of mapped area */
+
+#define IMAP_ADDR PRTPPC_IMMR_BASE /* physical base address of IMMR area */
+#define IMAP_SIZE PRTPPC_IMAP_SIZE /* mapped size of IMMR area */
+
+/* define IO_BASE for External bus devices */
+#define _IO_BASE CONFIG_PRT_IOADDR
+#define _IO_BASE_SIZE CONFIG_PRT_IOSIZE
+
+#define FEC_INTERRUPT 9 /* = SIU_LEVEL4 */
+
+/* We don't use the 8259.
+*/
+#define NR_8259_INTS 0
+
+#endif /* __PRTPPC_H__ */
diff --git a/arch/ppc/platforms/prtppc_serial.h b/arch/ppc/platforms/prtppc_serial.h
new file mode 100644
--- /dev/null
+++ b/arch/ppc/platforms/prtppc_serial.h
@@ -0,0 +1,100 @@
+/*
+ * include/asm-ppc/prtppc_serial.h
+ *
+ * Definitions for Protonic PRTPPC board multi-uart interface
+ * Usable for PRTACM and MSAMPS doughterboards.
+ *
+ * Author: David Jander <david@protonic.nl>
+ *
+ * Copyright (c) 2005 Protonic Holland b.v.
+ *
+ * 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.
+ */
+
+#ifndef __PRTPPC_SERIAL_H
+#define __PRTPPC_SERIAL_H
+
+#include <linux/config.h>
+
+/* Make room for 3 mpc8xx SCM devices at minor 64,65 and 66 */
+// #define SERIAL_DEV_OFFSET 3
+
+#if !defined(CONFIG_PRT_UARTADDR)
+#define CONFIG_PRT_UARTADDR _IO_BASE
+#endif
+
+/* Define the UART base addresses and IRQs */
+#define PRTPPC_UART0_BASE (CONFIG_PRT_UARTADDR)
+#define PRTPPC_UART1_BASE (CONFIG_PRT_UARTADDR + 8)
+#define PRTPPC_UART2_BASE (CONFIG_PRT_UARTADDR + 16)
+#define PRTPPC_UART3_BASE (CONFIG_PRT_UARTADDR + 24)
+#define PRTPPC_UART4_BASE (CONFIG_PRT_UARTADDR + 32)
+#define PRTPPC_UART5_BASE (CONFIG_PRT_UARTADDR + 40)
+#define PRTPPC_UART6_BASE (CONFIG_PRT_UARTADDR + 48)
+#define PRTPPC_UART7_BASE (CONFIG_PRT_UARTADDR + 56)
+
+/* On PRTACM there are 2 16C554 quad uart chips, with INTx outputs
+ * Negted and OR'd together 4 on 1.
+ * Chip one goes to IRQ1, Chip two to IRQ2
+ */
+#define PRTPPC_UART0_IRQ SIU_IRQ1
+#define PRTPPC_UART1_IRQ SIU_IRQ1
+#define PRTPPC_UART2_IRQ SIU_IRQ1
+#define PRTPPC_UART3_IRQ SIU_IRQ1
+#define PRTPPC_UART4_IRQ SIU_IRQ2
+#define PRTPPC_UART5_IRQ SIU_IRQ2
+#define PRTPPC_UART6_IRQ SIU_IRQ2
+#define PRTPPC_UART7_IRQ SIU_IRQ2
+
+
+#ifdef CONFIG_SERIAL_MANY_PORTS
+#define RS_TABLE_SIZE 16
+#else
+#define RS_TABLE_SIZE 8
+#endif
+
+/* Rate for the 1.8432 Mhz clock for the onboard serial chip */
+#define BASE_BAUD ( 1843200 / 16 )
+
+/* AUTO_IRQ is scary, but maybe it even works :-) */
+#ifdef CONFIG_SERIAL_DETECT_IRQ
+#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF|ASYNC_SKIP_TEST|ASYNC_AUTO_IRQ)
+#else
+#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF|ASYNC_SKIP_TEST)
+#endif
+
+/* Define a prototype UART entry.... */
+#define STD_SERIAL_PORT_ITEM(num) \
+ { 0, BASE_BAUD, PRTPPC_UART##num##_BASE, \
+ PRTPPC_UART##num##_IRQ, \
+ STD_COM_FLAGS, \
+ iomem_base: (u8 *)PRTPPC_UART##num##_BASE, \
+ iomem_reg_shift: 0, \
+ io_type: SERIAL_IO_MEM }
+
+/* Make a table from it */
+#if (CONFIG_SERIAL_8250_NR_UARTS > 4)
+#define STD_SERIAL_PORT_DFNS \
+ STD_SERIAL_PORT_ITEM(0), \
+ STD_SERIAL_PORT_ITEM(1), \
+ STD_SERIAL_PORT_ITEM(2), \
+ STD_SERIAL_PORT_ITEM(3), \
+ STD_SERIAL_PORT_ITEM(4), \
+ STD_SERIAL_PORT_ITEM(5), \
+ STD_SERIAL_PORT_ITEM(6), \
+ STD_SERIAL_PORT_ITEM(7)
+#else
+#define STD_SERIAL_PORT_DFNS \
+ STD_SERIAL_PORT_ITEM(0), \
+ STD_SERIAL_PORT_ITEM(1), \
+ STD_SERIAL_PORT_ITEM(2), \
+ STD_SERIAL_PORT_ITEM(3)
+#endif /* CONFIG_SERIAL_8250_NR_UARTS */
+
+#define SERIAL_PORT_DFNS \
+ STD_SERIAL_PORT_DFNS
+
+#endif /* __PRTPPC_SERIAL_H */
diff --git a/arch/ppc/platforms/prtppc_setup.c b/arch/ppc/platforms/prtppc_setup.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/platforms/prtppc_setup.c
@@ -0,0 +1,88 @@
+/*
+ * arch/ppc/platforms/prtppc_setup.c
+ *
+ * PRTPPC platform support
+ *
+ * Author: David Jander <david@protonic.nl>
+ *
+ * Copyright (c) 2005 Protonic Holland b.v.
+ *
+ * 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/init.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/usb_isp116x.h>
+#include <linux/ioport.h>
+#include <linux/irq.h>
+#include <linux/platform_device.h>
+
+#include <asm/mpc8xx.h>
+#include <asm/8xx_immap.h>
+#include <asm/machdep.h>
+#include <asm/irq.h>
+#include <asm/delay.h>
+
+struct resource prt_isp1160_resource[] =
+{
+ {
+ .name = "isp1160_data",
+ .flags = IORESOURCE_MEM,
+ .start = 0xf8100040,
+ .end = 0xf8100041,
+ },
+ {
+ .name = "isp1160_addr",
+ .flags = IORESOURCE_MEM,
+ .start = 0xf8100042,
+ .end = 0xf8100043,
+ },
+ {
+ .name = "isp1160_irq",
+ .flags = IORESOURCE_IRQ,
+ .start = SIU_IRQ6,
+ .end = SIU_IRQ6,
+ }
+};
+
+
+void platform_delay(struct device * dev, int delay)
+{
+ ndelay(delay);
+}
+
+struct isp116x_platform_data isp1160_config =
+{
+ .sel15Kres = 1,
+ .oc_enable = 1,
+ .int_act_high = 0,
+ .int_edge_triggered = 1,
+ .remote_wakeup_enable = 0,
+ .delay = platform_delay,
+};
+
+void __init prtppc_platform_init(void)
+{
+ struct platform_device *pdev;
+ static volatile immap_t *immap = (immap_t *)IMAP_ADDR;
+
+ printk("prtppc_platform_init()\n");
+
+ pdev = platform_device_register_simple("isp116x-hcd",0,prt_isp1160_resource,3);
+ pdev->dev.platform_data = &isp1160_config;
+
+ /* Configure SIU_IRQ6 as edge triggered */
+ immap->im_siu_conf.sc_siel |= 0x00080000;
+ irq_desc[SIU_IRQ6].status &= ~IRQ_LEVEL;
+}
+
+/* Anything special for this platform */
+void __init board_init(void)
+{
+ /* Register a platform_init function */
+ ppc_md.init=prtppc_platform_init;
+}
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
@@ -367,7 +367,7 @@ m8xx_map_io(void)
#ifdef CONFIG_PCI
io_block_mapping(PCI_CSR_ADDR, PCI_CSR_ADDR, PCI_CSR_SIZE, _PAGE_IO);
#endif
-#if defined(CONFIG_NETTA)
+#if defined(CONFIG_NETTA) || defined (CONFIG_PRTPPC)
io_block_mapping(_IO_BASE,_IO_BASE,_IO_BASE_SIZE, _PAGE_IO);
#endif
}
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -10,7 +10,8 @@ menu "USB support"
config USB_ARCH_HAS_HCD
boolean
default y if USB_ARCH_HAS_OHCI
- default y if ARM # SL-811
+ default y if ARM # SL-811
+ default y if PRTPPC
default PCI
# many non-PCI SOC chips embed OHCI
diff --git a/drivers/usb/host/isp116x.h b/drivers/usb/host/isp116x.h
--- a/drivers/usb/host/isp116x.h
+++ b/drivers/usb/host/isp116x.h
@@ -365,6 +365,33 @@ struct isp116x_ep {
#define IRQ_TEST() do{}while(0)
#endif
+#if defined(CONFIG_PRTPPC)
+/* On the PRTPPC the ISP1160 is connected through an 8-bit bus via a CPLD
+ * which translates the 8-bit data to 16-bit back and forth.
+ * The UPM splits the 16-bit bus-cycles up into two 8-bit cycles.
+ * The only caveat is that on writing, we have to write to the higher address first
+ * and then to the lower address, while on reading it has to be done the other way around,
+ * that is first the lower address and then the higher address.
+ * So for reading we can use normal 16-bit read functions, while for writing,
+ * we just redefine (temporarily) writew() and __raw_writew() to these below.
+ */
+static void inline writew_hcd(unsigned int port,u16 data)
+{
+ out_8((volatile unsigned char __iomem *)(port | 0x00000001), (data>>8) & 0x00ff);
+ out_8((volatile unsigned char __iomem *)(port & 0xfffffffe), data & 0x00ff);
+}
+
+static void inline raw_writew_hcd(unsigned int port,u16 data)
+{
+ __raw_writeb(data & 0x00ff, (volatile unsigned char __iomem *)(port | 0x00000001));
+ __raw_writeb((data>>8) & 0x00ff, (volatile unsigned char __iomem *)(port & 0xfffffffe));
+}
+
+#define writew(b,a) writew_hcd((unsigned int)(a),b)
+#define __raw_writew(b,a) raw_writew_hcd((unsigned int)(a),b)
+
+#endif /* CONFIG_PRTPPC */
+
static inline void isp116x_write_addr(struct isp116x *isp116x, unsigned reg)
{
IRQ_TEST();
@@ -421,6 +448,11 @@ static inline u32 isp116x_read_data32(st
return val;
}
+#if defined(CONFIG_PRTPPC)
+#undef writew
+#undef __raw_writew
+#endif /* CONFIG_PRTPPC */
+
/* Let's keep register access functions out of line. Hint:
we wait at least 150 ns at every access.
*/
diff --git a/include/asm-ppc/cpm_spi.h b/include/asm-ppc/cpm_spi.h
new file mode 100644
--- /dev/null
+++ b/include/asm-ppc/cpm_spi.h
@@ -0,0 +1,340 @@
+/*
+ * Simple CPM SPI interface for the MPC 8260 and MPC 8xx.
+ *
+ * Copyright (c) 2002 Wolfgang Grandegger (wg@denx.de)
+ *
+ * This interface is partly derived from code copyrighted
+ * by Navin Boppuri (nboppuri@trinetcommunication.co) and
+ * Prashant Patel (pmpatel@trinetcommunication.com).
+ */
+
+#ifndef __CPM_SPI_H
+#define __CPM_SPI_H
+
+#define SPMODE_LEN(x) (((x) - 1) << 4)
+
+#define CPM_SPI_POLL_RETRIES 1000 /* in micro-seconds */
+
+/*
+ * Board specific setting and functions:
+ *
+ * CPM_SPI_MAX_CHIPS: Maximum number of chips on the SPI.
+ *
+ * CPM_SPI_CLOCK: the bitwise or of the DIV16 and PM bits,
+ * see 16.12.4.1 in the MPC823e User's Manual.
+ *
+ * CPM_SPI_MODE : SPI mode setting,
+ * see 16.12.4.1 in the MPC823e User's Manual.
+ *
+ */
+
+#ifdef CONFIG_R360MPI
+/* There are two MPC2510 connected to the SPI */
+
+#define CPM_SPI_MAX_CHIPS 2
+#if 1
+#define CPM_SPI_BITS_PER_CHAR 8
+#define CPM_SPI_SWAP_BYTES 0
+#else
+#define CPM_SPI_BITS_PER_CHAR 16
+#define CPM_SPI_SWAP_BYTES 1
+#endif
+
+/* There are read timeouts with a clock value of 2 */
+#define CPM_SPI_CLOCK 3
+
+#define CPM_SPI_SPMODE (SPMODE_REV | SPMODE_MSTR | \
+ SPMODE_LEN(CPM_SPI_BITS_PER_CHAR) |\
+ CPM_SPI_CLOCK)
+
+static inline void
+cpm_spi_init_ports (volatile immap_t *immap)
+{
+ volatile iop8xx_t *iop = &immap->im_ioport;
+ /* we use PC14 and PC15 for chip select */
+ iop->iop_pcpar &= ~(0x0003);
+ iop->iop_pcdir |= 0x0003;
+ iop->iop_pcso &= ~(0x0003);
+ iop->iop_pcdat |= 0x0003 ; /* de-select */
+}
+
+static inline void
+cpm_spi_set_cs (volatile immap_t *immap, int id, int select)
+{
+ volatile iop8xx_t *iop = &immap->im_ioport;
+ /* we use PC14/PC15 for chip 0/1 select */
+ if (select)
+ iop->iop_pcdat &= ~(2 >> id);
+ else
+ iop->iop_pcdat |= (2 >> id);
+}
+
+#elif defined(CONFIG_HMI10)
+
+#define CPM_SPI_MAX_CHIPS 1
+#define CPM_SPI_BITS_PER_CHAR 8
+#define CPM_SPI_SWAP_BYTES 0
+
+#define CPM_SPI_CLOCK 15
+
+#define CPM_SPI_SPMODE (SPMODE_CP | SPMODE_REV | SPMODE_MSTR | \
+ SPMODE_LEN(CPM_SPI_BITS_PER_CHAR) |\
+ CPM_SPI_CLOCK)
+
+static inline void
+cpm_spi_init_ports (volatile immap_t *immap)
+{
+ volatile iop8xx_t *iop = &immap->im_ioport;
+ /* we use PA6 for chip select */
+ iop->iop_papar &= ~(0x0200);
+ iop->iop_padir |= 0x0200;
+ iop->iop_padat |= 0x0200 ; /* de-select */
+}
+
+static inline void
+cpm_spi_set_cs (volatile immap_t *immap, int id, int select)
+{
+ volatile iop8xx_t *iop = &immap->im_ioport;
+ /* we use PA6 for chip select */
+ if (select)
+ iop->iop_padat &= ~(0x0200);
+ else
+ iop->iop_padat |= (0x0200);
+}
+
+#elif defined (CONFIG_PM826)
+/* There are two MPC2510 connected to the SPI */
+
+#define CPM_SPI_MAX_CHIPS 32
+#if 0
+#define CPM_SPI_BITS_PER_CHAR 8
+#define CPM_SPI_SWAP_BYTES 0
+#else
+#define CPM_SPI_BITS_PER_CHAR 16
+#define CPM_SPI_SWAP_BYTES 1
+#endif
+
+/* There are read timeouts with a clock value of 2 */
+#define CPM_SPI_CLOCK 0
+
+#define CPM_SPI_SPMODE (SPMODE_REV | SPMODE_MSTR | \
+ SPMODE_LEN(CPM_SPI_BITS_PER_CHAR) |\
+ CPM_SPI_CLOCK)
+
+/*
+ * Pin configuration:
+ *
+ * SEL:
+ * PD19
+ *
+ * CS:
+ * PA9 PA8 PB17 PB16 PB13 PB12
+ * High Low
+ *
+ * IRQ:
+ * PC7 PC6 PC5 PC4 PC3 PC2 PC1
+ * High Low
+ */
+
+static inline void
+cpm_spi_init_ports (volatile immap_t *immap)
+{
+ volatile iop8260_t *iop = &immap->im_ioport;
+
+ /* Configure CS pins */
+ iop->iop_ppara &= ~0x00c00000;
+ iop->iop_pdira |= 0x00c00000;
+ iop->iop_podra &= ~0x00c00000;
+ iop->iop_pdata &= ~0x00c00000;
+
+ iop->iop_pparb &= ~0x000cc000;
+ iop->iop_pdirb |= 0x000cc000;
+ iop->iop_podrb &= ~0x000cc000;
+ iop->iop_pdatb &= ~0x000cc000;
+
+ iop->iop_ppard &= ~0x00001000;
+ iop->iop_pdird |= 0x00001000;
+ iop->iop_podrd &= ~0x00001000;
+ iop->iop_podrd |= 0x00001000;
+
+ /* Configure IRQ pins */
+ iop->iop_pparc &= ~0x7f000000;
+ iop->iop_pdirc &= ~0x7f000000;
+ iop->iop_podrc |= 0x7f000000;
+}
+
+static inline void
+cpm_spi_set_cs (volatile immap_t *immap, int id, int select)
+{
+ volatile iop8260_t *iop = &immap->im_ioport;
+ unsigned long portb, porta;
+
+ if (select) {
+ iop->iop_pdatd |= 0x00001000;
+
+ porta = portb = 0;
+ if (id & 0x01) portb |= 0x00080000;
+ if (id & 0x02) portb |= 0x00040000;
+ if (id & 0x04) portb |= 0x00008000;
+ if (id & 0x08) portb |= 0x00004000;
+ if (id & 0x10) porta |= 0x00800000;
+ if (id & 0x20) porta |= 0x00400000;
+
+ iop->iop_pdata = (iop->iop_pdata & ~0x00c00000) | porta;
+ iop->iop_pdatb = (iop->iop_pdatb & ~0x000cc000) | portb;
+ iop->iop_pdatd &= ~0x00001000;
+
+ } else {
+#if 0 /* SEL line won't work correctly */
+ iop->iop_pdatd |= 0x00001000;
+#else
+ iop->iop_pdata &= ~0x00c00000;
+ iop->iop_pdatb &= ~0x000cc000;
+#endif
+ }
+}
+
+static inline int
+cpm_spi_get_irq_cs (void)
+{
+ volatile immap_t *immap = (immap_t *)IMAP_ADDR;
+ volatile iop8260_t *iop = &immap->im_ioport;
+ unsigned long portc;
+ int irq;
+
+ portc = iop->iop_pdatc;
+
+ irq = 0;
+ if (portc & 0x01000000) irq += 64;
+ if (portc & 0x02000000) irq += 32;
+ if (portc & 0x04000000) irq += 16;
+ if (portc & 0x08000000) irq += 8;
+ if (portc & 0x10000000) irq += 4;
+ if (portc & 0x20000000) irq += 2;
+ if (portc & 0x40000000) irq += 1;
+
+ return irq;
+}
+
+#elif defined (CONFIG_ATC)
+
+#define CPM_SPI_MAX_CHIPS 32
+#define CPM_SPI_SWAP_BYTES 0
+
+static inline void
+cpm_spi_init_ports (volatile immap_t *immap)
+{
+
+ immap->im_ioport.iop_ppard &= ~0x00080000;
+ immap->im_ioport.iop_pdird |= 0x00080000;
+ immap->im_ioport.iop_podrd &= ~0x00080000;
+ immap->im_ioport.iop_pdatd |= 0x00080000;
+}
+
+static inline void
+cpm_spi_set_cs (volatile immap_t *immap, int id, int select)
+{
+
+ if (select) {
+ immap->im_ioport.iop_pdatd &= ~0x00080000;
+ } else {
+ immap->im_ioport.iop_pdatd |= 0x00080000;
+ }
+}
+
+#elif defined (CONFIG_PRTPPC)
+
+#define NUM_SPI_CHIPSELS 4
+
+#define PB_SPI_CS0 0x00010000 /* PB 15 is Chip Select for the RTC */
+#define PB_SPI_CS1 0x00000001 /* PB 31 is Chip select for the MMC */
+#define PA_SPI_CS2 0x2000 /* PA 2 (PA has 16-bit registers !!) */
+#define PA_SPI_CS3 0x1000 /* PA 3 (PA has 16-bit registers !!) */
+
+#define CPM_SPI_MAX_CHIPS NUM_SPI_CHIPSELS
+#define CPM_SPI_SWAP_BYTES 0
+
+#define CPM_SPI_SPMODE (/* SPMODE_DIV16 | */\
+ SPMODE_CP | \
+ SPMODE_REV | \
+ SPMODE_MSTR | \
+ SPMODE_LEN(8) | \
+ 0x0f )
+
+static inline void
+cpm_spi_init_ports (volatile immap_t *immap)
+{
+ printk("CPM_SPI: Config chipsels\n");
+ /* Set Port-B pin assignment for SPI pins */
+ immap->im_cpm.cp_pbpar |= 0x0000000e; /* Route PB30,29,28 to second function */
+ immap->im_cpm.cp_pbdir |= 0x0000000e; /* Select SPI block for second function */
+
+ /* Set Port-B and Port-A pin assignments for SPI_CS0...CS3 pins */
+ immap->im_cpm.cp_pbpar &= ~(PB_SPI_CS0 | PB_SPI_CS1); /* Route PB15,PB31 to GPIO */
+ immap->im_ioport.iop_papar &= ~(PA_SPI_CS2 | PA_SPI_CS3); /* Route PB15,PB31 to GPIO */
+
+ immap->im_cpm.cp_pbdir |= (PB_SPI_CS0 | PB_SPI_CS1); /* Set PB15,PB31 as outputs */
+ immap->im_ioport.iop_padir |= (PA_SPI_CS2 | PA_SPI_CS3); /* Set PA2,PA3 as outputs */
+
+ immap->im_cpm.cp_pbdat |= (PB_SPI_CS0 | PB_SPI_CS1); /* Clear Chip Selects (active low) */
+ immap->im_ioport.iop_padat |= (PA_SPI_CS2 | PA_SPI_CS3); /* Clear Chip Selects (active low) */
+}
+
+static inline void
+cpm_spi_set_cs (volatile immap_t *immap, int id, int select)
+{
+ /* printk("CPM_SPI: CS%d = %d\n",id,select); */
+ if(select) {
+ switch(id)
+ {
+ case 0:
+ immap->im_cpm.cp_pbdat |= PB_SPI_CS0; /* SET */
+ /* Clear all others */
+ immap->im_cpm.cp_pbdat |= PB_SPI_CS1;
+ immap->im_ioport.iop_padat |= PA_SPI_CS2 | PA_SPI_CS3;
+ break;
+ case 1:
+ immap->im_cpm.cp_pbdat &= ~PB_SPI_CS1; /* SET */
+ /* Clear all others */
+ immap->im_cpm.cp_pbdat &= ~PB_SPI_CS0;
+ immap->im_ioport.iop_padat |= PA_SPI_CS2 | PA_SPI_CS3;
+ break;
+ case 2:
+ immap->im_ioport.iop_padat &= ~PA_SPI_CS2; /* SET */
+ /* Clear all others */
+ immap->im_cpm.cp_pbdat &= ~PB_SPI_CS0;
+ immap->im_cpm.cp_pbdat |= PB_SPI_CS1;
+ immap->im_ioport.iop_padat |= PA_SPI_CS3;
+ break;
+ case 3:
+ immap->im_ioport.iop_padat &= ~PA_SPI_CS3; /* SET */
+ /* Clear all others */
+ immap->im_cpm.cp_pbdat &= ~PB_SPI_CS0;
+ immap->im_cpm.cp_pbdat |= PB_SPI_CS1;
+ immap->im_ioport.iop_padat |= PA_SPI_CS2;
+ break;
+ default:
+ break;
+ }
+ }
+ else {
+ /* Just clear all CS's */
+ /* FIXME: This _can_ go wrong when doing this:
+ Select1
+ Do something on SPI 1
+ Select2
+ Unselect 1
+ Do something on SPI 2 will fail
+ Unselect 2
+ */
+ immap->im_cpm.cp_pbdat &= ~PB_SPI_CS0;
+ immap->im_cpm.cp_pbdat |= PB_SPI_CS1;
+ immap->im_ioport.iop_padat |= PA_SPI_CS2 | PA_SPI_CS3;
+ }
+}
+
+#else
+#error "CPM SPI support is not implemented for your board"
+#endif
+
+#endif
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
@@ -68,6 +68,10 @@
#include <platforms/mpc885ads.h>
#endif
+#if defined(CONFIG_PRTPPC)
+#include <platforms/prtppc.h>
+#endif
+
/* Currently, all 8xx boards that support a processor to PCI/ISA bridge
* use the same memory map.
*/
diff --git a/include/asm-ppc/serial.h b/include/asm-ppc/serial.h
--- a/include/asm-ppc/serial.h
+++ b/include/asm-ppc/serial.h
@@ -38,6 +38,8 @@
#include <asm/mpc85xx.h>
#elif defined(CONFIG_RADSTONE_PPC7D)
#include <platforms/radstone_ppc7d.h>
+#elif defined(CONFIG_PRTPPC)
+#include <platforms/prtppc_serial.h>
#else
/*
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: David Jander @ 2005-11-10 7:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051109120450.GB8588@logos.cnet>
On Wednesday 09 November 2005 13:04, Marcelo Tosatti wrote:
>[...]
>
> ** 2.6.14 DataTLBHandler jump direct ("two exceptions"):
>
> first batch:
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
>
> second batch:
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
>
> ** 2.6.14 vanilla ("three exceptions"):
>
> first batch:
> avg: 288ms
> avg: 285ms
> avg: 287ms
> avg: 287ms
> avg: 288ms
>
> second batch:
> avg: 288ms
> avg: 288ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
>
> ** 2.4.17 (root on RAMDISK):
>
> avg: 309ms
> avg: 313ms
> avg: 312ms
> avg: 311ms
> avg: 310ms
Hmmm. This is a lot in the line of the tests I did with (the more generic
benchmark) nbench. After looking at those results (see my other post in this
thread) I already suspected something like this.
> The v2.6.14's kernel jump-direct is more consistent at 287ms,
> while vanilla 2.6.14 oscillates between 285 and 288ms, but
> no significant difference between the two.
>
> v2.6's fault handling is clearly faster than 2.4's (note that the compiler
> is also different, 2.4 uses gcc 2.95 and 2.6 gcc 3.3).
I don't think the compiler does much difference here though. In my test the
exact same compiler was used for both kernels, and the same rootfs and binary
of nbench. gcc-3.3.3. I did also use oprofile to get an idea of where the
code spent its most cpu time during nbench, and AFAIR flush_dcache_icache()
took quite a chunk of it, so I assume page fault latency is of importance
there too, and might account for the huge difference between 2.4 and 2.6.
Greetings,
--
David Jander
^ permalink raw reply
* about MPC 8XX SPI Driver
From: 徐小威的EMAIL @ 2005-11-10 6:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi All:
Anybody know where can found 'CPM SPI Driver' for MPC852T.I found a
cpm_spi.c at /arch/ppc/8260_io directory in Linux 2.4.25.But I don't
know how to program application to
handle this driver.
Best Regards,
Rober Hsu
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Andrew Morton @ 2005-11-10 6:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17266.58346.798470.79283@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote:
>
> > And, given the amount of shared infrastructure, I suspect it would have to
> > be a single git tree for both architectures.
> >
> > I'd still sweep up random ppc patches, but those will go into mainline via the
> > originator->mm->git-powerpc->linus route.
> >
> > Possible?
>
> Yes. Good idea, in fact. I'll create a powerpc.git tree once the
> current merge window closes.
OK.
> Do I need to grep the -mm releases for ppc patches or will you mail
> them to me?
If I see a ppc patch I will:
- merge it into -mm, add you guys to the cc on the mm-commits email.
- stage the patch after git-powerpc.patch in the -mm lineup.
- if I see the patch appear in git-powerpc.patch, I just drop it. I sync
with the git trees maybe twice per day.
- time passes
- if it still hasn't been merged into git-powerpc, I start spamming you
with the patch.
So no, you don't need to grep -mm and I won't bypass the git-powerpc tree
and the patch won't get lost. All you need to do is to either merge or
nack the patch at some stage.
Easy as pie ;)
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Paul Mackerras @ 2005-11-10 6:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20051109213837.47c8dce7.akpm@osdl.org>
Andrew Morton writes:
> I don't think I'm adding much value handling ppc/ppc64 patches, really.
> I'd prefer to get out of that business.
>
> It would be better to have an arch maintainer who runs a git tree, same as
> ia64, arm, etc.
My powerpc-merge.git tree is sort-of de-facto that at the moment.
> And, given the amount of shared infrastructure, I suspect it would have to
> be a single git tree for both architectures.
>
> I'd still sweep up random ppc patches, but those will go into mainline via the
> originator->mm->git-powerpc->linus route.
>
> Possible?
Yes. Good idea, in fact. I'll create a powerpc.git tree once the
current merge window closes.
Do I need to grep the -mm releases for ppc patches or will you mail
them to me?
Regards,
Paul.
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Benjamin Herrenschmidt @ 2005-11-10 6:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20051109220022.264437f8.akpm@osdl.org>
> Well yes, that's a generic problem with subsystem trees. I suppose one
> could enforce processes which prevent it from happening.
I think the right process is to go through the linuxppc[64]-dev list(s)
first, maybe CC lkml when it's not strictly arch gore, and then hop from
there to -git. We also have a nice patch tracking system scanning those
lists, I suppose I need to fix my own habits of bypassing all of that
stuff :)
> OK, well please think about it. It's not a ton of work at this end at
> present, but a) you lazy bums don't ack most of the things I cc you on, so
> it's rather open-loop and I don't know whether I'm merging wrong patches
> and b) there's now increasing potential for patches in -mm to clash with
> patches in Paul's git tree.
>
> The latter can be solved easily enough: I add Paul's git tree to the -mm
> lineup.
I think going through the -git tree always makes sense and I've doing
doing that for my own production, I'll route patches that I'm acking
that way too from now on.
I'm keeping the liberty of bombing you & linus directly when I think
it's an important bug fix late in the rc cycle though :)
Ben.
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Andrew Morton @ 2005-11-10 6:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1131601224.24637.155.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>
> > I don't think I'm adding much value handling ppc/ppc64 patches, really.
> > I'd prefer to get out of that business.
> >
> > It would be better to have an arch maintainer who runs a git tree, same as
> > ia64, arm, etc.
> >
> > And, given the amount of shared infrastructure, I suspect it would have to
> > be a single git tree for both architectures.
> >
> > I'd still sweep up random ppc patches, but those will go into mainline via the
> > originator->mm->git-powerpc->linus route.
> >
> > Possible?
>
> Well, I'm personally no fan of the git route as it causes us to have
> less review on the list imho
Well yes, that's a generic problem with subsystem trees. I suppose one
could enforce processes which prevent it from happening.
> (too easy also for me to just bounce a
> patch to paulus to shove in his git tree :) though that's what I've been
> doing for the last few days at least. But if you prefer that way, yes,
> it's certainly possible.
OK, well please think about it. It's not a ton of work at this end at
present, but a) you lazy bums don't ack most of the things I cc you on, so
it's rather open-loop and I don't know whether I'm merging wrong patches
and b) there's now increasing potential for patches in -mm to clash with
patches in Paul's git tree.
The latter can be solved easily enough: I add Paul's git tree to the -mm
lineup. Gimme.
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Benjamin Herrenschmidt @ 2005-11-10 5:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20051109213837.47c8dce7.akpm@osdl.org>
> I don't think I'm adding much value handling ppc/ppc64 patches, really.
> I'd prefer to get out of that business.
>
> It would be better to have an arch maintainer who runs a git tree, same as
> ia64, arm, etc.
>
> And, given the amount of shared infrastructure, I suspect it would have to
> be a single git tree for both architectures.
>
> I'd still sweep up random ppc patches, but those will go into mainline via the
> originator->mm->git-powerpc->linus route.
>
> Possible?
Well, I'm personally no fan of the git route as it causes us to have
less review on the list imho (too easy also for me to just bounce a
patch to paulus to shove in his git tree :) though that's what I've been
doing for the last few days at least. But if you prefer that way, yes,
it's certainly possible.
Ben.
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Andrew Morton @ 2005-11-10 5:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1131526855.24637.67.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
I don't think I'm adding much value handling ppc/ppc64 patches, really.
I'd prefer to get out of that business.
It would be better to have an arch maintainer who runs a git tree, same as
ia64, arm, etc.
And, given the amount of shared infrastructure, I suspect it would have to
be a single git tree for both architectures.
I'd still sweep up random ppc patches, but those will go into mainline via the
originator->mm->git-powerpc->linus route.
Possible?
^ permalink raw reply
* "Now booting the kernel"
From: Nitesh Guinde @ 2005-11-10 4:57 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]
Hello all,
I am loading a linux kernel onto ML310 board .I want networking support and
hence I have a pci enabled design.
I am using linux 2.4 powerpc devel kernel. I have also tried the montavista
previewkit
But I end up with the same problem. I have enabled the option " support for
early boot texts: in the kernel debugging.
Now once run the kernel program in powerpc I get the following essages in
the serial minicom terminal
Enter Desired System ACE CF Configuration <0-7>.
0: ACE-loader.
1: Linux w/PCI.
2: VxWorks w/PCI.
3: QNX Demo.
4: Linux EDK Base Build.
5: VxWorks EDK Base Build.
6: User Configuration A.
7: User Configuration B.
Select:
loaded at: 00400000 008CB1E0
board data at: 008C8138 008C8150
relocated to: 00405308 00405320
zimage at: 00405813 004DE42A
initrd at: 004DF000 008C7382
avail ram: 008CC000 10000000
Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
Uncompressing Linux...done.
Now booting the kernel
The prompt goes dead at this point.The board details is available at
www.xilinx.com/ml310 <http://www.xilinx.com/ml310>
Any workarounds?
Thanks,
Nitesh
[-- Attachment #2: Type: text/html, Size: 1518 bytes --]
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Benjamin Herrenschmidt @ 2005-11-10 1:51 UTC (permalink / raw)
To: Eddy Petrişor; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <60381eeb0511091712u115979f2jf92717a3641f7952@mail.gmail.com>
On Thu, 2005-11-10 at 03:12 +0200, Eddy Petrişor wrote:
> On 11/7/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > i've applied your patch and it seems that when i put my powerbook to
> > > sleep ( by closing the lid ) the kernel just crashes since everytime i
> > > come back, the machine is turned off. I had a look at the logs and i see
> > > that i'm having a reboot almost immediateley after the lid is closed.
> > > However i've got no trace of a kernel panic .....
> > > my conf:
> >
> > What about this patch ?
>
> I tried to apply this patch and the previous one over 2.6.14, but they failed.
> I also tied to apply the second patch over the first, also the third
> over the first, but I had the same result.
>
> Over which version should these pacthes be applied?
2.6.14 :) (But not some git checkout from after 2.6.14 release)
Ben.
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Eddy Petrişor @ 2005-11-10 1:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1131397208.4652.41.camel@gaston>
On 11/7/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > i've applied your patch and it seems that when i put my powerbook to
> > sleep ( by closing the lid ) the kernel just crashes since everytime i
> > come back, the machine is turned off. I had a look at the logs and i se=
e
> > that i'm having a reboot almost immediateley after the lid is closed.
> > However i've got no trace of a kernel panic .....
> > my conf:
>
> What about this patch ?
I tried to apply this patch and the previous one over 2.6.14, but they fail=
ed.
I also tied to apply the second patch over the first, also the third
over the first, but I had the same result.
Over which version should these pacthes be applied?
--
Regards,
EddyP
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
"Imagination is more important than knowledge" A.Einstein
^ permalink raw reply
* Re: u-boot + kernel (help required)
From: Wolfgang Denk @ 2005-11-09 22:58 UTC (permalink / raw)
To: srideep.devireddy; +Cc: linuxppc-embedded
In-Reply-To: <6AD9F6A5F6E096408F0B703773355A075BB210@CHN-SNR-MBX01.wipro.com>
In message <6AD9F6A5F6E096408F0B703773355A075BB210@CHN-SNR-MBX01.wipro.com> you wrote:
>
> we were able to get the u-boot up on MPC8272ADS board . We are just
...
Arghh... Why are you posting the same message 3 times?????
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"There's only one kind of woman ..." "Or man, for that matter. You
either believe in yourself or you don't."
-- Kirk and Harry Mudd, "Mudd's Women", stardate 1330.1
^ permalink raw reply
* Re: FW: U-boot linux kernel
From: Wolfgang Denk @ 2005-11-09 22:57 UTC (permalink / raw)
To: srideep.devireddy; +Cc: linuxppc-embedded
In-Reply-To: <6AD9F6A5F6E096408F0B703773355A075BB03B@CHN-SNR-MBX01.wipro.com>
In message <6AD9F6A5F6E096408F0B703773355A075BB03B@CHN-SNR-MBX01.wipro.com> you wrote:
>
> I am right now working on MPC 8272 Ads board to bring up the u-boot
> and the linux kernel on it . As I am success full in bringing up the
> u-boot . but I am finding it difficult in getting the linux up . As I
> downloaded the vmlinux image from montavista linux site for 8272Ads
Are you sure this image is configured for use with U-Boot?
> board and they tried to tftp to 100000 at u-boot prompt I am not able
And did you read the FAQ, for example
http://www.denx.de/wiki/view/DULG/LinuxUncompressingError ???
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
Alliance: In international politics, the union of two thieves who
have their hands so deeply inserted in each other's pocket that they
cannot separately plunder a third. - Ambrose Bierce
^ permalink raw reply
* Re: [patch 2.6.14 (take #2)] fec_8xx: make CONFIG_FEC_8XX depend on CONFIG_8xx
From: John W. Linville @ 2005-11-09 21:52 UTC (permalink / raw)
To: Pantelis Antoniou, linuxppc-embedded, netdev, linux-kernel
In-Reply-To: <20051107182459.GD13797@tuxdriver.com>
On Mon, Nov 07, 2005 at 01:24:59PM -0500, John W. Linville wrote:
> Change CONFIG_FEC_8XX to depend on CONFIG_8xx instead of CONFIG_FEC.
> CONFIG_FEC depends on ColdFire CPUs, which does not apply for the
> PPC 8xx processors.
FWIW, I have this patch available on the linville-fec_8xx branch of
netdev-jwl as described below.
Thanks,
John
---
The following changes since commit 330d57fb98a916fa8e1363846540dd420e99499a:
Al Viro:
Fix sysctl unregistration oops (CVE-2005-2709)
are found in the git repository at:
git://git.tuxdriver.com/git/netdev-jwl.git linville-fec_8xx
John W. Linville:
fec_8xx: make CONFIG_FEC_8XX depend on CONFIG_8xx
drivers/net/fec_8xx/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fec_8xx/Kconfig b/drivers/net/fec_8xx/Kconfig
index 94e7a9a..a84c232 100644
--- a/drivers/net/fec_8xx/Kconfig
+++ b/drivers/net/fec_8xx/Kconfig
@@ -1,6 +1,6 @@
config FEC_8XX
tristate "Motorola 8xx FEC driver"
- depends on NET_ETHERNET && FEC
+ depends on NET_ETHERNET && 8xx
select MII
config FEC_8XX_GENERIC_PHY
--
John W. Linville
linville@tuxdriver.com
^ 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