* Re: SPI support for MPC8xx in ELDK 3.1.1?
From: Wolfgang Denk @ 2006-02-10 23:26 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <IUHUQX$E3BAE7D116850E80B61395D5308F6B3C@libero.it>
In message <IUHUQX$E3BAE7D116850E80B61395D5308F6B3C@libero.it> you wrote:
>
> the support for SPI device for MPC8xx (MPC880) is present in the ELDK 3.1.1 ?
Yes, if you use the ELDK in combination with a kernel tree that
supports SPI on your board.
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
When some people discover the truth, they just can't understand why
everybody isn't eager to hear it.
^ permalink raw reply
* Re: [PATCH] Add PCI support for 8540 ADS to powerpc tree
From: Kumar Gala @ 2006-02-10 22:56 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0602101654580.8978@ld0175-tx32.am.freescale.net>
Ok, How far off is 8555 CDS?
- kumar
On Fri, 10 Feb 2006, Andy Fleming wrote:
> This patch applies on top off Becky's cleanup patches
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
>
> diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
> index 70e1190..ffc4139 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -1,4 +1,5 @@
> #
> # Makefile for the PowerPC 85xx linux kernel.
> #
> -obj-$(CONFIG_PPC_85xx) += misc.o mpc85xx_ads.o
> +obj-$(CONFIG_PPC_85xx) += misc.o pci.o
> +obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
> diff --git a/arch/powerpc/platforms/85xx/mpc8540_ads.h b/arch/powerpc/platforms/85xx/mpc8540_ads.h
> index b3ec88c..16976bd 100644
> --- a/arch/powerpc/platforms/85xx/mpc8540_ads.h
> +++ b/arch/powerpc/platforms/85xx/mpc8540_ads.h
> @@ -39,7 +39,7 @@
> #define MPC85XX_PCI1_IO_BASE 0xe2000000
> #define MPC85XX_PCI1_MEM_OFFSET 0x00000000
>
> -#define MPC85XX_PCI1_IO_SIZE 0x01000000
> +#define MPC85XX_PCI1_IO_SIZE 0x00100000
>
> /* PCI config */
> #define PCI1_CFG_ADDR_OFFSET (0x8000)
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h b/arch/powerpc/platforms/85xx/mpc85xx.h
> index be75abb..b44db62 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx.h
> +++ b/arch/powerpc/platforms/85xx/mpc85xx.h
> @@ -15,3 +15,4 @@
> */
>
> extern void mpc85xx_restart(char *);
> +extern int add_bridge(struct device_node *dev);
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> index e14cd20..3a4b409 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> @@ -67,6 +67,62 @@ static u_char mpc85xx_ads_openpic_initse
> 0x0, /* External 11: */
> };
>
> +#ifdef CONFIG_PCI
> +/*
> + * interrupt routing
> + */
> +
> +int
> +mpc85xx_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
> +{
> + static char pci_irq_table[][4] =
> + /*
> + * This is little evil, but works around the fact
> + * that revA boards have IDSEL starting at 18
> + * and others boards (older) start at 12
> + *
> + * PCI IDSEL/INTPIN->INTLINE
> + * A B C D
> + */
> + {
> + {PIRQA, PIRQB, PIRQC, PIRQD}, /* IDSEL 2 */
> + {PIRQD, PIRQA, PIRQB, PIRQC},
> + {PIRQC, PIRQD, PIRQA, PIRQB},
> + {PIRQB, PIRQC, PIRQD, PIRQA}, /* IDSEL 5 */
> + {0, 0, 0, 0}, /* -- */
> + {0, 0, 0, 0}, /* -- */
> + {0, 0, 0, 0}, /* -- */
> + {0, 0, 0, 0}, /* -- */
> + {0, 0, 0, 0}, /* -- */
> + {0, 0, 0, 0}, /* -- */
> + {PIRQA, PIRQB, PIRQC, PIRQD}, /* IDSEL 12 */
> + {PIRQD, PIRQA, PIRQB, PIRQC},
> + {PIRQC, PIRQD, PIRQA, PIRQB},
> + {PIRQB, PIRQC, PIRQD, PIRQA}, /* IDSEL 15 */
> + {0, 0, 0, 0}, /* -- */
> + {0, 0, 0, 0}, /* -- */
> + {PIRQA, PIRQB, PIRQC, PIRQD}, /* IDSEL 18 */
> + {PIRQD, PIRQA, PIRQB, PIRQC},
> + {PIRQC, PIRQD, PIRQA, PIRQB},
> + {PIRQB, PIRQC, PIRQD, PIRQA}, /* IDSEL 21 */
> + };
> +
> + const long min_idsel = 2, max_idsel = 21, irqs_per_slot = 4;
> + return PCI_IRQ_TABLE_LOOKUP;
> +}
> +
> +int
> +mpc85xx_exclude_device(u_char bus, u_char devfn)
> +{
> + if (bus == 0 && PCI_SLOT(devfn) == 0)
> + return PCIBIOS_DEVICE_NOT_FOUND;
> + else
> + return PCIBIOS_SUCCESSFUL;
> +}
> +
> +#endif /* CONFIG_PCI */
> +
> +
> void __init mpc85xx_ads_pic_init(void)
> {
> struct mpic *mpic1;
> @@ -110,6 +166,7 @@ void __init mpc85xx_ads_pic_init(void)
> static void __init mpc85xx_ads_setup_arch(void)
> {
> struct device_node *cpu;
> + struct device_node *np;
>
> if (ppc_md.progress)
> ppc_md.progress("mpc85xx_ads_setup_arch()", 0);
> @@ -125,6 +182,16 @@ static void __init mpc85xx_ads_setup_arc
> loops_per_jiffy = 50000000 / HZ;
> of_node_put(cpu);
> }
> +
> +#ifdef CONFIG_PCI
> + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> + add_bridge(np);
> +
> + ppc_md.pci_swizzle = common_swizzle;
> + ppc_md.pci_map_irq = mpc85xx_map_irq;
> + ppc_md.pci_exclude_device = mpc85xx_exclude_device;
> +#endif
> +
> #ifdef CONFIG_ROOT_NFS
> ROOT_DEV = Root_NFS;
> #else
> diff --git a/arch/powerpc/platforms/85xx/pci.c b/arch/powerpc/platforms/85xx/pci.c
> new file mode 100644
> index 0000000..93b0bb1
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/pci.c
> @@ -0,0 +1,96 @@
> +/*
> + * FSL SoC setup code
> + *
> + * Maintained by Kumar Gala (see MAINTAINERS for contact information)
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/config.h>
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/pci.h>
> +#include <linux/delay.h>
> +#include <linux/irq.h>
> +#include <linux/module.h>
> +
> +#include <asm/system.h>
> +#include <asm/atomic.h>
> +#include <asm/io.h>
> +#include <asm/pci-bridge.h>
> +#include <asm/prom.h>
> +#include <sysdev/fsl_soc.h>
> +
> +#undef DEBUG
> +
> +#ifdef DEBUG
> +#define DBG(x...) printk(x)
> +#else
> +#define DBG(x...)
> +#endif
> +
> +int mpc85xx_pci2_busno = 0;
> +
> +#ifdef CONFIG_PCI
> +int __init add_bridge(struct device_node *dev)
> +{
> + int len;
> + struct pci_controller *hose;
> + struct resource rsrc;
> + int *bus_range;
> + int primary = 1, has_address = 0;
> + phys_addr_t immr = get_immrbase();
> +
> + DBG("Adding PCI host bridge %s\n", dev->full_name);
> +
> + /* Fetch host bridge registers address */
> + has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
> +
> + /* Get bus range if any */
> + bus_range = (int *) get_property(dev, "bus-range", &len);
> + if (bus_range == NULL || len < 2 * sizeof(int)) {
> + printk(KERN_WARNING "Can't get bus-range for %s, assume"
> + " bus 0\n", dev->full_name);
> + }
> +
> + hose = pcibios_alloc_controller();
> + if (!hose)
> + return -ENOMEM;
> + hose->arch_data = dev;
> + hose->set_cfg_type = 1;
> +
> + hose->first_busno = bus_range ? bus_range[0] : 0;
> + hose->last_busno = bus_range ? bus_range[1] : 0xff;
> +
> + /* PCI 1 */
> + if ((rsrc.start & 0xfffff) == 0x8000) {
> + setup_indirect_pci(hose, immr + 0x8000, immr + 0x8004);
> + }
> + /* PCI 2*/
> + if ((rsrc.start & 0xfffff) == 0x9000) {
> + setup_indirect_pci(hose, immr + 0x9000, immr + 0x9004);
> + primary = 0;
> + hose->bus_offset = hose->first_busno;
> + mpc85xx_pci2_busno = hose->first_busno;
> + }
> +
> + printk(KERN_INFO "Found MPC85xx PCI host bridge at 0x%08lx. "
> + "Firmware bus number: %d->%d\n",
> + rsrc.start, hose->first_busno, hose->last_busno);
> +
> + DBG(" ->Hose at 0x%p, cfg_addr=0x%p,cfg_data=0x%p\n",
> + hose, hose->cfg_addr, hose->cfg_data);
> +
> + /* Interpret the "ranges" property */
> + /* This also maps the I/O region and sets isa_io/mem_base */
> + pci_process_bridge_OF_ranges(hose, dev, primary);
> +
> + return 0;
> +}
> +
> +#endif
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* SPI support for MPC8xx in ELDK 3.1.1?
From: dibacco @ 2006-02-10 23:04 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
the support for SPI device for MPC8xx (MPC880) is present in the ELDK 3.1=
.1 ?
Thank you,
Antonio.
^ permalink raw reply
* [PATCH] Add PCI support for 8540 ADS to powerpc tree
From: Andy Fleming @ 2006-02-10 23:01 UTC (permalink / raw)
To: linuxppc-embedded
This patch applies on top off Becky's cleanup patches
Signed-off-by: Andy Fleming <afleming@freescale.com>
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 70e1190..ffc4139 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -1,4 +1,5 @@
#
# Makefile for the PowerPC 85xx linux kernel.
#
-obj-$(CONFIG_PPC_85xx) += misc.o mpc85xx_ads.o
+obj-$(CONFIG_PPC_85xx) += misc.o pci.o
+obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
diff --git a/arch/powerpc/platforms/85xx/mpc8540_ads.h b/arch/powerpc/platforms/85xx/mpc8540_ads.h
index b3ec88c..16976bd 100644
--- a/arch/powerpc/platforms/85xx/mpc8540_ads.h
+++ b/arch/powerpc/platforms/85xx/mpc8540_ads.h
@@ -39,7 +39,7 @@
#define MPC85XX_PCI1_IO_BASE 0xe2000000
#define MPC85XX_PCI1_MEM_OFFSET 0x00000000
-#define MPC85XX_PCI1_IO_SIZE 0x01000000
+#define MPC85XX_PCI1_IO_SIZE 0x00100000
/* PCI config */
#define PCI1_CFG_ADDR_OFFSET (0x8000)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h b/arch/powerpc/platforms/85xx/mpc85xx.h
index be75abb..b44db62 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx.h
+++ b/arch/powerpc/platforms/85xx/mpc85xx.h
@@ -15,3 +15,4 @@
*/
extern void mpc85xx_restart(char *);
+extern int add_bridge(struct device_node *dev);
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index e14cd20..3a4b409 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -67,6 +67,62 @@ static u_char mpc85xx_ads_openpic_initse
0x0, /* External 11: */
};
+#ifdef CONFIG_PCI
+/*
+ * interrupt routing
+ */
+
+int
+mpc85xx_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
+{
+ static char pci_irq_table[][4] =
+ /*
+ * This is little evil, but works around the fact
+ * that revA boards have IDSEL starting at 18
+ * and others boards (older) start at 12
+ *
+ * PCI IDSEL/INTPIN->INTLINE
+ * A B C D
+ */
+ {
+ {PIRQA, PIRQB, PIRQC, PIRQD}, /* IDSEL 2 */
+ {PIRQD, PIRQA, PIRQB, PIRQC},
+ {PIRQC, PIRQD, PIRQA, PIRQB},
+ {PIRQB, PIRQC, PIRQD, PIRQA}, /* IDSEL 5 */
+ {0, 0, 0, 0}, /* -- */
+ {0, 0, 0, 0}, /* -- */
+ {0, 0, 0, 0}, /* -- */
+ {0, 0, 0, 0}, /* -- */
+ {0, 0, 0, 0}, /* -- */
+ {0, 0, 0, 0}, /* -- */
+ {PIRQA, PIRQB, PIRQC, PIRQD}, /* IDSEL 12 */
+ {PIRQD, PIRQA, PIRQB, PIRQC},
+ {PIRQC, PIRQD, PIRQA, PIRQB},
+ {PIRQB, PIRQC, PIRQD, PIRQA}, /* IDSEL 15 */
+ {0, 0, 0, 0}, /* -- */
+ {0, 0, 0, 0}, /* -- */
+ {PIRQA, PIRQB, PIRQC, PIRQD}, /* IDSEL 18 */
+ {PIRQD, PIRQA, PIRQB, PIRQC},
+ {PIRQC, PIRQD, PIRQA, PIRQB},
+ {PIRQB, PIRQC, PIRQD, PIRQA}, /* IDSEL 21 */
+ };
+
+ const long min_idsel = 2, max_idsel = 21, irqs_per_slot = 4;
+ return PCI_IRQ_TABLE_LOOKUP;
+}
+
+int
+mpc85xx_exclude_device(u_char bus, u_char devfn)
+{
+ if (bus == 0 && PCI_SLOT(devfn) == 0)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ else
+ return PCIBIOS_SUCCESSFUL;
+}
+
+#endif /* CONFIG_PCI */
+
+
void __init mpc85xx_ads_pic_init(void)
{
struct mpic *mpic1;
@@ -110,6 +166,7 @@ void __init mpc85xx_ads_pic_init(void)
static void __init mpc85xx_ads_setup_arch(void)
{
struct device_node *cpu;
+ struct device_node *np;
if (ppc_md.progress)
ppc_md.progress("mpc85xx_ads_setup_arch()", 0);
@@ -125,6 +182,16 @@ static void __init mpc85xx_ads_setup_arc
loops_per_jiffy = 50000000 / HZ;
of_node_put(cpu);
}
+
+#ifdef CONFIG_PCI
+ for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
+ add_bridge(np);
+
+ ppc_md.pci_swizzle = common_swizzle;
+ ppc_md.pci_map_irq = mpc85xx_map_irq;
+ ppc_md.pci_exclude_device = mpc85xx_exclude_device;
+#endif
+
#ifdef CONFIG_ROOT_NFS
ROOT_DEV = Root_NFS;
#else
diff --git a/arch/powerpc/platforms/85xx/pci.c b/arch/powerpc/platforms/85xx/pci.c
new file mode 100644
index 0000000..93b0bb1
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/pci.c
@@ -0,0 +1,96 @@
+/*
+ * FSL SoC setup code
+ *
+ * Maintained by Kumar Gala (see MAINTAINERS for contact information)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/config.h>
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/pci.h>
+#include <linux/delay.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+
+#include <asm/system.h>
+#include <asm/atomic.h>
+#include <asm/io.h>
+#include <asm/pci-bridge.h>
+#include <asm/prom.h>
+#include <sysdev/fsl_soc.h>
+
+#undef DEBUG
+
+#ifdef DEBUG
+#define DBG(x...) printk(x)
+#else
+#define DBG(x...)
+#endif
+
+int mpc85xx_pci2_busno = 0;
+
+#ifdef CONFIG_PCI
+int __init add_bridge(struct device_node *dev)
+{
+ int len;
+ struct pci_controller *hose;
+ struct resource rsrc;
+ int *bus_range;
+ int primary = 1, has_address = 0;
+ phys_addr_t immr = get_immrbase();
+
+ DBG("Adding PCI host bridge %s\n", dev->full_name);
+
+ /* Fetch host bridge registers address */
+ has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
+
+ /* Get bus range if any */
+ bus_range = (int *) get_property(dev, "bus-range", &len);
+ if (bus_range == NULL || len < 2 * sizeof(int)) {
+ printk(KERN_WARNING "Can't get bus-range for %s, assume"
+ " bus 0\n", dev->full_name);
+ }
+
+ hose = pcibios_alloc_controller();
+ if (!hose)
+ return -ENOMEM;
+ hose->arch_data = dev;
+ hose->set_cfg_type = 1;
+
+ hose->first_busno = bus_range ? bus_range[0] : 0;
+ hose->last_busno = bus_range ? bus_range[1] : 0xff;
+
+ /* PCI 1 */
+ if ((rsrc.start & 0xfffff) == 0x8000) {
+ setup_indirect_pci(hose, immr + 0x8000, immr + 0x8004);
+ }
+ /* PCI 2*/
+ if ((rsrc.start & 0xfffff) == 0x9000) {
+ setup_indirect_pci(hose, immr + 0x9000, immr + 0x9004);
+ primary = 0;
+ hose->bus_offset = hose->first_busno;
+ mpc85xx_pci2_busno = hose->first_busno;
+ }
+
+ printk(KERN_INFO "Found MPC85xx PCI host bridge at 0x%08lx. "
+ "Firmware bus number: %d->%d\n",
+ rsrc.start, hose->first_busno, hose->last_busno);
+
+ DBG(" ->Hose at 0x%p, cfg_addr=0x%p,cfg_data=0x%p\n",
+ hose, hose->cfg_addr, hose->cfg_data);
+
+ /* Interpret the "ranges" property */
+ /* This also maps the I/O region and sets isa_io/mem_base */
+ pci_process_bridge_OF_ranges(hose, dev, primary);
+
+ return 0;
+}
+
+#endif
^ permalink raw reply related
* denx 2.4 kernel doesn't compile amd_flash.c
From: dibacco @ 2006-02-10 23:00 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I downloaded denx 2.4 kernel via cvs. I tried to compile it for a MBX boa=
rd but I get the following problem:
amd_flash.c:143: error: structure has no member named `buswidth'
I was successful using the kernel included in ELDK 3.1.1.
Someone could help?
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2006-02-10 22:31 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
Just 4 commits this time. Log and diffstat follow.
Thanks,
Paul.
Becky Bruce:
powerpc: Add FSL USB node to documentation
JANAK DESAI:
powerpc: unshare system call registration
Kumar Gala:
powerpc: Add CONFIG_DEFAULT_UIMAGE for embedded boards
Paul Mackerras:
ppc: Use the system call table from arch/powerpc/kernel/systbl.S
Documentation/powerpc/booting-without-of.txt | 60 +++++-
arch/powerpc/Kconfig | 6 +
arch/powerpc/Makefile | 1
arch/powerpc/kernel/Makefile | 6 -
arch/powerpc/kernel/systbl.S | 3
arch/ppc/kernel/misc.S | 283 --------------------------
include/asm-powerpc/unistd.h | 3
7 files changed, 72 insertions(+), 290 deletions(-)
^ permalink raw reply
* Re: [CFT] Don't use ASYNC_* nor SERIAL_IO_* with serial_core
From: Russell King @ 2006-02-10 21:52 UTC (permalink / raw)
To: Pat Gefre; +Cc: linux-mips, Linux Kernel List, linuxppc-dev
In-Reply-To: <200602101457.45847.pfg@sgi.com>
On Fri, Feb 10, 2006 at 02:57:45PM -0600, Pat Gefre wrote:
> Yeah this is something I should've fixed up... thanks
>
> Acked-by: pfg@sgi.com
Thanks, applied.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [CFT] Don't use ASYNC_* nor SERIAL_IO_* with serial_core
From: Pat Gefre @ 2006-02-10 20:57 UTC (permalink / raw)
To: Russell King; +Cc: linux-mips, Linux Kernel List, linuxppc-dev
In-Reply-To: <20060210084445.GA1947@flint.arm.linux.org.uk>
Yeah this is something I should've fixed up... thanks
Acked-by: pfg@sgi.com
On Fri February 10 2006 2:44 am, Russell King wrote:
> On Sat, Jan 21, 2006 at 09:14:07PM +0000, Russell King wrote:
> > The ioc4_serial driver is worse. It assumes that it can set/clear
> > ASYNC_CTS_FLOW in the uart_info flags field, which is private to
> > serial_core. It also seems to set TTY_IO_ERROR followed by immediately
> > clearing it (pointless), and then it writes to tty->alt_speed... which
> > isn't used by the serial layer so is also pointless.
>
> Okay, the only remaining part of this patch which hasn't been applied
> is this - can anyone ack it?
>
> diff --git a/drivers/serial/ioc4_serial.c b/drivers/serial/ioc4_serial.c
> --- a/drivers/serial/ioc4_serial.c
> +++ b/drivers/serial/ioc4_serial.c
> @@ -1717,11 +1717,9 @@ ioc4_change_speed(struct uart_port *the_
> }
>
> if (cflag & CRTSCTS) {
> - info->flags |= ASYNC_CTS_FLOW;
> port->ip_sscr |= IOC4_SSCR_HFC_EN;
> }
> else {
> - info->flags &= ~ASYNC_CTS_FLOW;
> port->ip_sscr &= ~IOC4_SSCR_HFC_EN;
> }
> writel(port->ip_sscr, &port->ip_serial_regs->sscr);
> @@ -1760,18 +1758,6 @@ static inline int ic4_startup_local(stru
>
> info = the_port->info;
>
> - if (info->tty) {
> - set_bit(TTY_IO_ERROR, &info->tty->flags);
> - clear_bit(TTY_IO_ERROR, &info->tty->flags);
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
> - info->tty->alt_speed = 57600;
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI)
> - info->tty->alt_speed = 115200;
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_SHI)
> - info->tty->alt_speed = 230400;
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_WARP)
> - info->tty->alt_speed = 460800;
> - }
> local_open(port);
>
> /* set the speed of the serial port */
^ permalink raw reply
* Re: mv-linux: Problem to implement custom driver interrupt handling
From: Andrei Konovalov @ 2006-02-10 19:13 UTC (permalink / raw)
To: Eckart Göhler; +Cc: linuxppc-embedded
In-Reply-To: <43ECB078.4080209@ifen.com>
Eckart Göhler wrote:
>
> Andrei Konovalov wrote:
> > Hi,
> >
> > In the Linux driver you should not access the interrupt controller
> > directly.
> > The relevant XIntc_* calls are done by arch/ppc/syslib/xilinx_pic.c
> code.
> > E.g. the particular interrupt is unmasked when one calls request_irq().
> >
> > Few more comments below.
>
>
> Hi,
>
> Thanks a lot. Actually I inserted the low-level code below after
> request_irq() did not work. The note about xilinx_pic.c code (that is
> located in my implementation in arch/ppc/kernel/xilinx_pic.c) lead me to
Correct. arch/ppc/syslib/xilinx_pic.c is the 2.6 kernel case.
> the problem origin that should be reported here for the community (which
> I presume already know the very fact):
> The interrupt numbering generated by the EDK is opposite to the one used
> by linux, i.e. interrupt number 4 reported in EDK-generated
> xparameters.h/xparameters_ml300.h becomes 31-4 = 27 when using request_irq.
Yes, this is true for 2.4 kernels.
In 2.6 the "natural" irq numbering is used.
I.e. for irq number of 4 (as per xparameters.h) one should pass
to request_irq()
31-4 = 27 if using 2.4 kernel
and
4 if using 2.6 kernel.
Thanks,
Andrei
> Therefore the handler was not called because he was attached to the
> wrong interrupt, and also was not able to reset the interrupt pending
> flag, that must be done as you noted below.
>
> cheers
>
> eckart
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 19:13 UTC (permalink / raw)
To: Travis B. Sawyer, linuxppc-embedded
In-Reply-To: <43ECD19E.8010604@sandburst.com>
Hi Travis,
>>> Ah, the ol' dec 21555, everyone has had to use one in their lifetime...
>>> Not bad, not great...
>>
>> Not great, so any suggestions for whats better?
>>
> Everytone uses them because they're easy and just work. Sometimes you
> may need to tweak the setup eeprom, but in general they just work.
> We use a pericom 7300 (can't remember and working from home today), that
> is quite nice. Not an issue with it at all. HW guy just plunked it down
> and it worked. They have an eval board to.
The 7300 is a PCI-to-PCI bridge that only operates in transparent
mode, it does not have any I2O capabilities. I used the Pericom
cross-reference guide and they don't have a replacement part
for the 21555, or the PLX6254 or PLX6540. So, thanks for the
suggestion, but the 21555 still has it.
I didn't find any Pericom bridge that was non-transparent.
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 18:19 UTC (permalink / raw)
To: Mark Chambers, linuxppc-embedded
In-Reply-To: <001701c62e6c$09c48ea0$6401a8c0@CHUCK2>
Hi Mark,
> Some unsolicited brainstorming
Brainstorm away!
> if you go with a QUICC based processor you could bring
> the data into SDRAM via a serial port. That gets you DMA
> and some extra buffer management help from the co-processor.
Ooooh I like it.
> Some extra logic in the FPGA (but less pins), but you've got
> a lot of flexibility in what you can do with SCCs or I2C.
But do I have the bandwidth? (I'll look in the data book).
> I'm currently working on an MPC8247 based design, btw.
> It has a PC104+ header and is directly connected to a
> T.I. 6205 (which, at $10, is a lot of crunch for the buck).
But the you have to program it with Code Composer and
the horrid TI DSP tools. Yeah, ok I've got the older
C31 version, not the newer 6x-based DSPs. I'm trying
to move the system to Linux, so that others round
here can 'share the burden'. I'm designing the boards,
drivers, and host software (ACE/C++) at the moment.
I need a break! :)
I want to avoid spending $20k on the TI tools and an
emulator ... hey, call me cheap.
However, I like the SCC idea. They sound very similar
to the multi-processor links on the Analog Devices
SHARC DSPs.
More reading :)
Dave
^ permalink raw reply
* Re: Stability of MPC5200 FEC
From: John Rigby @ 2006-02-10 18:22 UTC (permalink / raw)
To: Asier Llano Palacios; +Cc: Sylvain Munaut, linuxppc-embedded
In-Reply-To: <1139592010.14894.22.camel@localhost.localdomain>
Do you have a lite5200 board that exhibits the same bad FEC behavior.
If so you could try the new
version on it and see if things improve.
Asier Llano Palacios wrote:
>We are working with MPC5200 cpu.
>We've been using it since early 2.6 kernel versions.
>We're currently quite stabilished with the version of the kernel Sylvain
>had before the Platform Device rework. But the problem is that we are
>experiencing that the FEC stops working after a long uptime.
>
>So, do you think that the current git version is more stable than the
>one we are using? Do you think that there is anything that could stop us
>upgrading to the latest version?
>
>The problem is that we have a custom board, with some custom devices, so
>it is not so easy to upgrade. We need to know that a new version, is
>more stable than the previous one, before we upgrade. As soon as we
>upgrade, we can help if we find any problem.
>
>Thank you,
>Asier Llano
>
>
>
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 18:11 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602101859.24830.sr@denx.de>
>>There's actually an additional issue with the 440EP
>>for my application. I'll be using it in a 5V PCI
>>environment (due to the reuse of the existing host
>>CPUs).
>
> Autsch! Those must be pretty old CPU's! Is this standard desktop PCI or
> CompactPCI or PMC?
They're not too old ... but at $2k a piece, you don't want
to just throw them away.
The CPUs are Force Computers 735AR2 devices. They contain
a Force Sentinel PCI-to-PCI bridge. The bridges can operate
at 3.3V or 5V, but they decided to hardwire them for 5V
operation to implement hot-swap.
The other newer CPUs are Trenton CPLEs.
http://www.trentontechnology.com/products/singleboards/5932.php4
The system uses cPCI crates. In some cases 21152 bridges are
used to make larger backplanes, in other cases SBS bridges
containing 21152's are used to link crates.
>>Since the 440EP is not 5V tolerant, I figured
>>I would add clamps or buffers to the board design.
>
> I would be careful here, since you easily can violate the pci
> specs. Do you have other pci devices on this pci bus?
Yeah, I'd make sure that I had others check my work. However,
the 21555 would take care of it, and the only PCI bus
on the board would be the one between the 440EP and the
bridge.
> Just use newer host CPU's! ;-)
Ah, the words of a true engineer :)
Of course the project manager wouldn't appreciate me doing that.
However, its not totally out of the question ... $50 per 21555
and 20 per crate, thats $1000, about half the price of
a CPU. But of course, without the I20 unit on the 440EP,
I might need the 21555 anyway.
Cheers
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 17:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43ECCF7C.9070701@ovro.caltech.edu>
Hey Travis,
>> Not great, so any suggestions for whats better?
>>
> Everyone uses them because they're easy and just work. Sometimes
> you may need to tweak the setup eeprom, but in general they just work.
> We use a pericom 7300 (can't remember and working from home
> today), that is quite nice. Not an issue with it at all. HW
> guy just plunked it down and it worked. They have an eval board to.
I was going to take a look around TIs site, I'd forgotten Pericom
makes bridges too, I'll read the data book.
> ... I've not had a need to use it, my work is 90% PCI
> (forwarding engine, queueing engine, etc) for 10G ethernet, so
> FPU stuff is very rare, and not time critical (used for setting
> up policing/rate limiting etc). Basically, set it and forget it
> calculations.
I figured that was probably the case - and the reason the majority
of the embedded processors are sans-FPU. I didn't want to use a
TI DSP again, there's just no 'community spirit' like with Linux.
So, I'll take a look at the PowerQUICC that Wolfgang mentioned, and
see if I want to change to that processor, another look at the ColdFire
(I have an MCF5485 eval board), and a look at the bridge data sheets
and see where that leaves me.
Personally, I want to stay with the PowerPC, the developer mailing
list is great!
Thanks,
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: Stefan Roese @ 2006-02-10 17:59 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43ECC7CE.1010409@ovro.caltech.edu>
Hi David,
On Friday 10 February 2006 18:05, David Hawkins wrote:
> There's actually an additional issue with the 440EP
> for my application. I'll be using it in a 5V PCI
> environment (due to the reuse of the existing host
> CPUs).
Autsch! Those must be pretty old CPU's! Is this standard desktop PCI or
CompactPCI or PMC?
> Since the 440EP is not 5V tolerant, I figured
> I would add clamps or buffers to the board design.
I would be careful here, since you easily can violate the pci specs. Do you
have other pci devices on this pci bus?
Just use newer host CPU's! ;-)
Best regards,
Stefan
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: Andrew Armitage @ 2006-02-10 17:20 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43ECC7CE.1010409@ovro.caltech.edu>
Hi David,
> However, given the meager host-to-host communications
> features, I think I would be better off putting an
> Intel 21555 non-transparent bridge on the board.
> That will provide 5V tolerance, and a full set of
> messaging unit and I2O facilities. All for $50-80
> or so according to the single-piece pricing from
> Digikey. I'm not so happy to need to add another
> chip, but if the 440EP passes all the other
> benchmark requirements, then it seems the least
> painful way to proceed.
>
> Has anyone reading this list had good or bad experiences
> with the Intel 21555 or perhaps some of the PLX offers,
> eg. PCI 6254?
We've used the 21555 on a couple of our designs (mated to a 7457/107
pair) and have never had too many problems with them. The messaging
unit has been very helpful.
Just my $0.02,
Andrew
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 17:38 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060210173133.964B53525CC@atlas.denx.de>
>>Of course there is also the option of finding another
>>PowerPC that matches my requirements;
>
> ...
>
> MPC834x comes to mind. But I have to admit that we never tried using
> this as a PCI device yet...
>
Thanks Wolfgang, I'll take a look at the user manual.
Regarding PowerPC devices that can be (uselessly) configured
as PCI agents/targets/peripherals;
- the Artesyn PMC board I got from eBay contains the
IBM CPC700 bridge - it can never generate PCI interrupts
as a target (non-monarch mode).
- the MPC5200 PowerPC, can also be configured as a target,
but will never generate PCI interrupts.
Gee, who knew. I didn't :)
Dave
^ permalink raw reply
* Stability of MPC5200 FEC
From: Asier Llano Palacios @ 2006-02-10 17:20 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Sylvain Munaut, John Rigby
We are working with MPC5200 cpu.=20
We've been using it since early 2.6 kernel versions.
We're currently quite stabilished with the version of the kernel Sylvain
had before the Platform Device rework. But the problem is that we are
experiencing that the FEC stops working after a long uptime.
So, do you think that the current git version is more stable than the
one we are using? Do you think that there is anything that could stop us
upgrading to the latest version?
The problem is that we have a custom board, with some custom devices, so
it is not so easy to upgrade. We need to know that a new version, is
more stable than the previous one, before we upgrade. As soon as we
upgrade, we can help if we find any problem.
Thank you,
Asier Llano
--=20
Asier Llano Palacios
ZIV I+D Smart Energy Networks
Dpto. Ingenier=EDa de Desarrollo.
ZIV, Aplicaciones y Tecnolog=EDa.
Parque Tecnol=F3gico, 210
48170 ZAMUDIO (Bizkaia)
E-mail: a.llano@ziv.es
Tlfno: (+34)944037400=20
=20
----------------------------------------- PLEASE NOTE =
-------------------------------------------
This message, along with any attachments, may be confidential or legally =
privileged.=20
It is intended only for the named person(s), who is/are the only =
authorized recipients.
If this message has reached you in error, kindly destroy it without =
review and notify the sender immediately.
Thank you for your help.
=B5SysCom uses virus scanning software but excludes any liability for =
viruses contained in any attachment.
=20
------------------------------------ ROGAMOS LEA ESTE TEXTO =
-------------------------------
Este mensaje y sus anexos pueden contener informaci=F3n confidencial y/o =
con derecho legal.=20
Est=E1 dirigido =FAnicamente a la/s persona/s o entidad/es rese=F1adas =
como =FAnico destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elim=EDnelo sin =
revisarlo ni reenviarlo y notif=EDquelo inmediatamente al remitente. =
Gracias por su colaboraci=F3n. =20
=B5SysCom utiliza software antivirus, pero no se hace responsable de los =
virus contenidos en los ficheros anexos.
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: Wolfgang Denk @ 2006-02-10 17:31 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43ECC7CE.1010409@ovro.caltech.edu>
Dear David,
in message <43ECC7CE.1010409@ovro.caltech.edu> you wrote:
>
> Of course there is also the option of finding another
> PowerPC that matches my requirements;
...
MPC834x comes to mind. But I have to admit that we never tried using
this as a PCI device yet...
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
I can type faster than I can move a mouse, so I find menu-driven
drawing packages time consuming and frustrating. - W. R. Stevens
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 17:26 UTC (permalink / raw)
To: Andrew Armitage; +Cc: linuxppc-embedded
In-Reply-To: <43ECCB4D.9080602@varisys.co.uk>
> We've used the 21555 on a couple of our designs (mated to a 7457/107
> pair) and have never had too many problems with them. The messaging
> unit has been very helpful.
>
> Just my $0.02,
Hey Andrew,
Thanks!
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 17:05 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602100847.54363.sr@denx.de>
Hi Stefan,
Thanks for confirming my analysis.
There's actually an additional issue with the 440EP
for my application. I'll be using it in a 5V PCI
environment (due to the reuse of the existing host
CPUs). Since the 440EP is not 5V tolerant, I figured
I would add clamps or buffers to the board design.
However, given the meager host-to-host communications
features, I think I would be better off putting an
Intel 21555 non-transparent bridge on the board.
That will provide 5V tolerance, and a full set of
messaging unit and I2O facilities. All for $50-80
or so according to the single-piece pricing from
Digikey. I'm not so happy to need to add another
chip, but if the 440EP passes all the other
benchmark requirements, then it seems the least
painful way to proceed.
Has anyone reading this list had good or bad experiences
with the Intel 21555 or perhaps some of the PLX offers,
eg. PCI 6254?
If only the GX/SP had an FPU ...
Of course there is also the option of finding another
PowerPC that matches my requirements;
- 300-500MHz CPU
- ~2W
- FPU
- three independent buses; SDRAM, PCI, external
- the external bus will contain multiple FPGAs
that generate 128kB of data every 10ms or so.
The data needs to be DMAed to SDRAM, where
the host CPU can convert it to float, FFT
it, process, and average the data. Transfers
to host over PCI occur every 100ms.
FPGA-to-SDRAM should occur in ~1ms;
128kB/1ms = 128MB/s
There will be up to 20 boards in a crate,
and transfers from all 20 boards need to
complete in 100ms, so
FPGA-to-host should occur in ~5ms;
128kB/5ms = 25MB/s
So I don't need stunning PCI performance, but
I do need a reasonable external memory bus
bandwidth.
The 440EP 16bit/66MHz 132MB/s would just meet
my requirement (and I can handle a 50% drop
in bus bandwidth if benchmarks go that way).
The PCI performance hits 50MB/s, so its ok.
I don't want to use a local-bus PCI interface
with the FPGAs, since then I'd need a PCI core
in each. I typically pack the FPGAs to 90%
with processing logic, so can't afford the
space for a complex host-to-FPGA interface.
I think I've shown you the current boards (that
use a TI DSP);
http://www.ovro.caltech.edu/~dwh/correlator
I had looked at the MPC8245 processor a while back,
but its SDRAM interface is multiplexed with its external
memory bus, so DMA from the external bus to SDRAM
would likely be pretty poor.
Do you have any experience with features of the PowerQUICC
processors? I've tried to avoid a full-up G4/G5 processor
since they typically also require a system controller
chip, and consume a lot more power.
I had also considered using a ColdFire processor, but
went with the PowerPC since I'll be using some Virtex
FPGAs with the PowerPC in a future project.
Anyway, just thought I'd give you an idea of what I'm
trying to figure out.
Cheers,
Dave
^ permalink raw reply
* Re: mv-linux: Problem to implement custom driver interrupt handling
From: Eckart Göhler @ 2006-02-10 15:25 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-embedded
In-Reply-To: <43E767DE.4060003@ru.mvista.com>
Andrei Konovalov wrote:
> Hi,
>
> In the Linux driver you should not access the interrupt controller
> directly.
> The relevant XIntc_* calls are done by arch/ppc/syslib/xilinx_pic.c code.
> E.g. the particular interrupt is unmasked when one calls request_irq().
>
> Few more comments below.
Hi,
Thanks a lot. Actually I inserted the low-level code below after
request_irq() did not work. The note about xilinx_pic.c code (that is
located in my implementation in arch/ppc/kernel/xilinx_pic.c) lead me to
the problem origin that should be reported here for the community (which
I presume already know the very fact):
The interrupt numbering generated by the EDK is opposite to the one used
by linux, i.e. interrupt number 4 reported in EDK-generated
xparameters.h/xparameters_ml300.h becomes 31-4 = 27 when using request_irq.
Therefore the handler was not called because he was attached to the
wrong interrupt, and also was not able to reset the interrupt pending
flag, that must be done as you noted below.
cheers
eckart
>
>
> Thanks,
> Andrei
>
>
> Eckart Göhler wrote:
>> Hi,
>>
>> We try to run montavista Linux pro 3.1 on an ml300 like embedded
>> system on an Virtex V2-Pro system. The system works fine with UART,
>> Xilinx enet
>> driver (booting with Das U-Boot).
>> Now we try to implement some custom GPIO driver that must be triggered
>> from outside interrupts. Polling for data works fine but the handler
>> for HW-timer interrupts does behaves strange.
>>
>> The relevant Linux driver part that requests the interrupt and starts
>> the timer look like below.
>>
>> Installing such a driver works but
>> - No report of driver interrupt called is sent
>> - installing the driver results in a system that almost gets stuck and
>> has poor response (~sec) till the driver is rmmodded.
>>
>> Checking the implementation with native Xilinx example timer
>> application works fine, provided the Xilinx exception handling is
>> implemented.
>>
>> Its not clear for me whether on ppc environment something specific
>> must be done for custom interrupts, though implementation of
>> xilinx_enet/xilinx_uartlite does not hint for something specific.
>>
>>
>> sincerely
>>
>> eckart goehler
>>
>>
>> -----------------------------------------------------------------(snip)
>>
>> // driver snippet that reacts on timer interrupts:
>>
>> // timer\interrupt base addresses, modified by ioremap:
>> unsigned long timer_base, interrupt_base;
>>
>>
>> /* interrupt handler: */
>> static
>> void drv_interrupt_handler(int irq, void *dev_id, struct pt_regs *regs)
>> {
>> printk(KERN_INFO DEVICE_NAME "interrupt occurred\n");
>
> Most probably you should clear the interrupt source here.
> Otherwise you could get back into the interrupt handler as
> soon as you return from it due to the interrupt request still
> being active.
>
>> }
>>
>>
>>
>> static int __init drv_init_module(void)
>> {
>>
>> interrupt_base = (unsigned long)
>> ioremap(XPAR_INTC_BASEADDR,XPAR_INTC_HIGHADDR-XPAR_INTC_BASEADDR);
>> timer_base = (unsigned long)
>> ioremap(XPAR_TIMER_BASEADDR,XPAR_TIMER_HIGHADDR-XPAR_TIMER_BASEADDR);
>>
>> // install interrupt handler:
>> if (request_irq(DRV_IRQ, commdrv_interrupt_handler,
>> 0, DEVICE_NAME, NULL)
>> )
>
> You call request_irq() (i.e. unmask this interrupt) too early.
> Configure the timer first.
>
>> {
>> printk(KERN_INFO DEVICE_NAME ": can¢t get assigned irq %i\n",
>> COMM_IRQ
>> );
>> }
>> else { /* enable interrupt */
>>
>> printk(KERN_INFO DEVICE_NAME ": interrupt installed\n");
>>
>> /* Start the interrupt controller */
>> XIntc_mMasterEnable(interrupt_base);
>
> - must not be used in the driver
>
>> // here: enable timer interrupt:
>> /* Set the number of cycles the timer counts before interrupting */
>> XTmrCtr_mSetLoadReg(timer_base, 0, TIMER_VALUE * 80000000l);
>>
>>
>> printk(KERN_INFO DEVICE_NAME ": clear timer\n");
>>
>> /* Reset the timers, and clear interrupts */
>> XTmrCtr_mSetControlStatusReg(timer_base, 0, XTC_CSR_INT_OCCURED_MASK
>> | XTC_CSR_LOAD_MASK );
>>
>> printk(KERN_INFO DEVICE_NAME ": enable interrupt\n");
>>
>> /* Enable timer interrupts in the interrupt controller */
>>
>> XIntc_mEnableIntr(interrupt_base, DRV_IRQ_MASK);
>
> - must not be used in the driver. Unmasking the interrupt is done inside
> request_irq().
>
>> //printk(KERN_INFO DEVICE_NAME ": start timer\n");
>> /* Start the timers */
>> XTmrCtr_mSetControlStatusReg(timer_base, 0, XTC_CSR_ENABLE_TMR_MASK
>> | XTC_CSR_ENABLE_INT_MASK
>> | XTC_CSR_AUTO_RELOAD_MASK |
>> XTC_CSR_DOWN_COUNT_MASK);
>>
>> }
>> }
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
^ permalink raw reply
* Re: yaboot 1.3.14 release candidate 1
From: Ben Collins @ 2006-02-10 14:21 UTC (permalink / raw)
To: Paul Nasrat; +Cc: linuxppc-dev list
In-Reply-To: <1139538538.3638.14.camel@enki.eridu>
On Thu, 2006-02-09 at 21:28 -0500, Paul Nasrat wrote:
> It's been some time in the making but I'd like to put out what is on
> HEAD for people to test. Key features are improved netbooting on IBM
> pSeries machines (Nathan Lynch), Amiga partition support (Sven Luther),
> Software RAID support on IBM pSeries machines (Dustin Kirkland), plus
> many small fixups. Thanks to all the contributors involved. It should be
> listed in the snapshot section at http://yaboot.ozlabs.org/
Not sure if you have anything like this in your tree at the moment, but
here's a patch we use for Ubuntu. It's based in part on code in silo (I
maintain silo upstream). Since the two are very close in code, this made
sense :). Silo allows you to add an arch in the image stanza like:
image[sun4,sun4m,sun4c]=/boot/foo
image[sun4u]=/boot/foo-64
This basically allows you to do things like this for ppc:
image=/boot/vmlinux-ppc32
name=Linux
...
image[macrisc4]=/boot/vmlinux-ppc64
name=Linux
...
One a powerpc64 (G5 for instance), this will override the default target
of "Linux" with the 64-bit image. The name is checked against the
root /compatible node in the device tree. (e.g. on my powerbook it has
"PowerBook5,9", "MacRISC3", and "Power Macintosh" as possible values).
This seemed a lot better than just doing "32-bit" and "64-bit", since it
also allows for things like:
image[powerbook5,8|powerbook5,9]=/boot/...
and
image[macrisc|macrisc3]=/boot/...
(note, | is the entry separator, so you can have more than one match).
We only use this for 32/64 kernels, but it's really useful for more than
that.
--- yaboot-1.3.13.orig/lib/ctype.c
+++ yaboot-1.3.13/lib/ctype.c
@@ -44,3 +44,11 @@
}
}
+int strncasecmp(const char *cs,const char *ct,size_t n)
+{
+ signed char __res = 0;
+ while (n--)
+ if ((__res = tolower(*cs) - tolower(*ct++)) != 0 || !*cs++)
+ break;
+ return __res;
+}
--- yaboot-1.3.13.orig/second/cfg.c
+++ yaboot-1.3.13/second/cfg.c
@@ -28,6 +28,7 @@
/* Imported functions */
extern int strcasecmp(const char *s1, const char *s2);
+extern int strncasecmp(const char *cs, const char *ct, size_t n);
typedef enum {
cft_strg, cft_flag, cft_end
@@ -101,10 +102,12 @@
static char *endp = NULL;
static char *file_name = NULL;
static CONFIG *curr_table = cf_options;
+static int ignore_entry;
static jmp_buf env;
static struct IMAGES {
CONFIG table[sizeof (cf_image) / sizeof (cf_image[0])];
+ int obsolete;
struct IMAGES *next;
} *images = NULL;
@@ -277,6 +280,16 @@
return 1;
}
+static char *cfg_get_strg_i (CONFIG * table, char *item)
+{
+ CONFIG *walk;
+
+ for (walk = table; walk->type != cft_end; walk++)
+ if (walk->name && !strcasecmp (walk->name, item))
+ return walk->data;
+ return 0;
+}
+
#if 0
// The one and only call to this procedure is commented out
// below, so we don't need this unless we decide to use it again.
@@ -287,13 +300,85 @@
}
#endif
+static int match_arch(const char *name)
+{
+ static prom_handle root;
+ static char model[256], *p;
+
+ if (!root) {
+ if (!(root = prom_finddevice("/")))
+ return 0;
+ }
+
+ if (!model[0]) {
+ if (!prom_getprop(root, "compatible", model, sizeof(model)))
+ return 0;
+ }
+
+ for (p = model; *p; p += strlen(p) + 1) {
+ if (!strcasecmp(p, name))
+ return 1;
+ }
+
+ return 0;
+}
+
+static void check_for_obsolete(const char *label)
+{
+ struct IMAGES *p;
+ char *cur_label;
+
+ /* Make sure our current entry isn't obsolete (ignored) */
+ for (p = images; p; p = p->next) {
+ if (curr_table == p->table && p->obsolete)
+ return;
+ }
+
+ for (p = images; p; p = p->next) {
+ if (curr_table == p->table)
+ continue;
+
+ cur_label = cfg_get_strg_i (p->table, "label");
+ if (!cur_label)
+ cur_label = cfg_get_strg_i (p->table, "image");
+
+ if (!cur_label)
+ continue;
+
+ if (!strcasecmp(cur_label, label))
+ p->obsolete = 1;
+ }
+}
+
static int cfg_set (char *item, char *value)
{
CONFIG *walk;
- if (!strcasecmp (item, "image")) {
+ if (!strncasecmp (item, "image", 5)) {
struct IMAGES **p = &images;
+ int ignore = 0;
+
+ if (item[5] == '[' && item[strlen(item) - 1] == ']') {
+ char *s, *q = item;
+
+ /* Get rid of braces */
+ item[strlen(item) - 1] = 0;
+ item[5] = 0;
+
+ for (s = item + 6; q; s = q) {
+ q = strchr(s, '|');
+ if (q)
+ *q++ = 0;
+
+ if (match_arch(s))
+ goto cfg_set_cont;
+ }
+ /* This just creates an unused table. It will get ignored */
+ ignore = 1;
+ } else if (item[5])
+ goto cfg_set_redo;
+cfg_set_cont:
while (*p)
p = &((*p)->next);
*p = (struct IMAGES *)malloc (sizeof (struct IMAGES));
@@ -302,9 +387,12 @@
return -1;
}
(*p)->next = 0;
+ (*p)->obsolete = ignore;
curr_table = ((*p)->table);
memcpy (curr_table, cf_image, sizeof (cf_image));
}
+
+cfg_set_redo:
for (walk = curr_table; walk->type != cft_end; walk++) {
if (walk->name && !strcasecmp (walk->name, item)) {
if (value && walk->type != cft_strg)
@@ -312,6 +400,8 @@
else if (!value && walk->type == cft_strg)
cfg_warn ("Value expected for '%s'", walk->name);
else {
+ if (!strcasecmp (item, "label"))
+ check_for_obsolete(value);
if (walk->data)
cfg_warn ("Duplicate entry '%s'", walk->name);
if (walk->type == cft_flag)
@@ -322,9 +412,12 @@
break;
}
}
+
if (walk->type != cft_end)
return 1;
-// cfg_return (item, value);
+
+ //cfg_return (item, value);
+
return 0;
}
@@ -369,6 +452,9 @@
if (!image)
return cfg_get_strg_i (cf_options, item);
for (p = images; p; p = p->next) {
+ if (p->obsolete)
+ continue;
+
label = cfg_get_strg_i (p->table, "label");
if (!label) {
label = cfg_get_strg_i (p->table, "image");
@@ -417,6 +503,9 @@
printl_count = 0;
for (p = images; p; p = p->next) {
+ if (p->obsolete)
+ continue;
+
label = cfg_get_strg_i (p->table, "label");
if (!label) {
label = cfg_get_strg_i (p->table, "image");
@@ -439,15 +528,21 @@
char *cfg_get_default (void)
{
char *label;
+ struct IMAGES *p;
char *ret = cfg_get_strg_i (cf_options, "default");
if (ret)
return ret;
if (!images)
return 0;
- ret = cfg_get_strg_i (images->table, "label");
+
+ for (p = images; p && p->obsolete; p = p->next);
+ if (!p)
+ return 0;
+
+ ret = cfg_get_strg_i (p->table, "label");
if (!ret) {
- ret = cfg_get_strg_i (images->table, "image");
+ ret = cfg_get_strg_i (p->table, "image");
label = strrchr (ret, '/');
if (label)
ret = label + 1;
--
Ben Collins
Kernel Developer - Ubuntu Linux
^ permalink raw reply
* [PATCH] poison invalid cpus
From: Olaf Hering @ 2006-02-10 14:00 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
from Anton Blanchard <anton@samba.org>
Novell bug145459
Ensure that per cpu access to !possible cpus causes a fault instead of silent
corruption.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/setup_64.c | 8 ++++++++
1 files changed, 8 insertions(+)
Index: linux-2.6.16-rc1-git3/arch/powerpc/kernel/setup_64.c
===================================================================
--- linux-2.6.16-rc1-git3.orig/arch/powerpc/kernel/setup_64.c
+++ linux-2.6.16-rc1-git3/arch/powerpc/kernel/setup_64.c
@@ -670,6 +670,14 @@ void __init setup_per_cpu_areas(void)
size = PERCPU_ENOUGH_ROOM;
#endif
+ /*
+ * Poison invalid cpus, with lots of high bits set this should
+ * always fault
+ */
+ for (i = 0; i < NR_CPUS; i++) {
+ paca[i].data_offset = 0xeeeeeeeeeeeeeeeeULL;
+ }
+
for_each_cpu(i) {
ptr = alloc_bootmem_node(NODE_DATA(cpu_to_node(i)), size);
if (!ptr)
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: HELP! Memory mapping and address space doubts
From: Tore Martin Hagen @ 2006-02-10 13:04 UTC (permalink / raw)
To: "Jose França (Ext_GTBC)"; +Cc: linuxppc-embedded
In-Reply-To: <16FD2D70D281D44F9BFCF6ACF9B6117102AD0EED@lisi053a.siemens.pt>
Hi Vitaly,
It seams that you are mixing virtual addresses and physical addresses.
You must put RAM at physical address 0 and you can keep the flash and
fpga as it is. The 0xc0000000 is the virtual address of the kernel, and
has nothing to do with the physical address.
Where have you mapped the IMMR?
If you have problems with probing of the CFI flash I would try to find
out what the problem realy is. I was given a board with what I would
call SwapEndian, I had to use littleendian for read and bigendian for
writes.
/Tore Martin Hagen
Jose França (Ext_GTBC) wrote:
>Vitaly,
>
> I'm using a linux 2.4.31 kernel. In the present situation I have BRx/ORx well configured and i can boot u-boot normally and without problems. I have a flash eprom with base address 0xD0000000 and a FPGA in 0xE0000000. In linux, i have the mtd driver similar to the rpxlite board. cfi_probe doesn't find my flash eprom. My colleague developped an fpga driver, but he can't access it either... It seem's that all the addresses that we try to access are all mixed-up. In ppc_md.map_io, i'm doing io_block_mapping for the CPM (from 0xf0000000 to the end of memory) , 0x80000000 and 0xa0000000 for PCI address space, both with 256MB of length. We are a bit lost... It seems that we forgot something to do. Can you help me on this?
>
>
>Best regards,
>Filipe.
>
> -----Mensagem original-----
> De: linuxppc-embedded-bounces@ozlabs.org em nome de Vitaly Bordug
> Enviada: sex 27-01-2006 13:37
> Para: Jose França (Ext_GTBC)
> Cc: linuxppc-embedded@ozlabs.org
> Assunto: Re: HELP! Memory mapping and address space doubts
>
>
>
> Jose,
> Can you please be a bit more specific in targets you want to achieve?
>
> An example how to setup br/or and use the device could be found as a part of PQ2 PCI support,
> where interrupt controller is implemented as a CPLD device (arch/ppc/syslib/m82xx_pci.{c,h}).
>
>
> On Thu, 26 Jan 2006 14:04:49 -0000
> Jose França (Ext_GTBC) <Jose.Franca.Ext@siemens.com> wrote:
>
> > Hello u all!
> >
> > I need to clarify some aspects of the memory management in ppc linux and i hope that you could help me.
> > Lets imagine we have a mpc8272 based board with 3 devices A, B and C.In the bootloader (in my case, i use u-boot), i configured the BRx and Orx so that A has base address X, B has base address Y and C has base address Z. My first doubt arrises here: what address should i use? Being SDRAM base address 0x00000000 and kernel base address 0xC0000000, where will i put these devices mapped on? Above 0xC0000000 or in between the end of physical memory and 0xC0000000? Do i really need to configure the BAT registers in u boot?
> > In linux 2.4 kernel, we have ppc_md.setup_io_mappings to map address blocks into the BAT registers... As i observed in the kernel source tree examples, we must map CPM (why?). And what about the other devices A, B and C? How will i setup them in this case and what addresses i can use? Above 0xC0000000 or in between the end of physical memory and 0xC0000000? Is the SDRAM included?
> >
> > Thanks in advance to all contributions! All of them will be most welcomed!
> >
> >
> >
> >
> >
> > Best regards,
> > Filipe
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
>
>
> --
> Sincerely,
> Vitaly
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox