* [PATCH 05/18] Add PowerPC Xilinx Virtex entry to maintainers
From: Grant Likely @ 2007-09-28 18:16 UTC (permalink / raw)
To: linuxppc-dev, jwboyer, jacmet
In-Reply-To: <20070928181421.18608.74224.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Paul, is this okay by you? Josh has already okayed it.
Cheers,
g.
MAINTAINERS | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8f80068..ea4ff15 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2304,6 +2304,13 @@ L: linuxppc-embedded@ozlabs.org
T: git kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc.git
S: Maintained
+LINUX FOR POWERPC EMBEDDED XILINX VIRTEX
+P: Grant Likely
+M: grant.likely@secretlab.ca
+W: http://www.secretlab.ca/
+L: linuxppc-embedded@ozlabs.org
+S: Maintained
+
LINUX FOR POWERPC BOOT CODE
P: Tom Rini
M: trini@kernel.crashing.org
^ permalink raw reply related
* [PATCH 03/18] Virtex: add xilinx interrupt controller driver
From: Grant Likely @ 2007-09-28 18:16 UTC (permalink / raw)
To: linuxppc-dev, jwboyer, jacmet
In-Reply-To: <20070928181421.18608.74224.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/sysdev/Makefile | 1
arch/powerpc/sysdev/xilinx_intc.c | 151 +++++++++++++++++++++++++++++++++++++
include/asm-powerpc/xilinx_intc.h | 20 +++++
3 files changed, 172 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 08ce31e..0457117 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_PPC_INDIRECT_PCI) += indirect_pci.o
obj-$(CONFIG_PPC_I8259) += i8259.o
obj-$(CONFIG_PPC_83xx) += ipic.o
obj-$(CONFIG_4xx) += uic.o
+obj-$(CONFIG_XILINX_VIRTEX) += xilinx_intc.o
endif
# Temporary hack until we have migrated to asm-powerpc
diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
new file mode 100644
index 0000000..fe24f0f
--- /dev/null
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -0,0 +1,151 @@
+/*
+ * Interrupt controller driver for Xilinx Virtex FPGAs
+ *
+ * Copyright (C) 2007 Secret Lab Technologies Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+/*
+ * This is a driver for the interrupt controller typically found in
+ * Xilinx Virtex FPGA designs.
+ *
+ * The interrupt sense levels are hard coded into the FPGA design with
+ * typically a 1:1 relationship between irq lines and devices (no shared
+ * irq lines). Therefore, this driver does not attempt to handle edge
+ * and level interrupts differently.
+ */
+#undef DEBUG
+
+#include <linux/kernel.h>
+#include <linux/irq.h>
+#include <asm/io.h>
+#include <asm/processor.h>
+#include <asm/prom.h>
+#include <asm/irq.h>
+
+/*
+ * INTC Registers
+ */
+#define ISR 0 /* Interrupt Status */
+#define IPR 4 /* Interrupt Pending */
+#define IER 8 /* Interrupt Enable */
+#define IAR 12 /* Interrupt Acknowledge */
+#define SIE 16 /* Set Interrupt Enable bits */
+#define CIE 20 /* Clear Interrupt Enable bits */
+#define IVR 24 /* Interrupt Vector */
+#define MER 28 /* Master Enable */
+
+static struct irq_host *master_irqhost;
+
+/*
+ * IRQ Chip operations
+ */
+static void xilinx_intc_mask(unsigned int virq)
+{
+ int irq = irq_map[virq].hwirq;
+ void * regs = get_irq_chip_data(virq);
+ pr_debug("mask: %d\n", irq);
+ out_be32(regs + CIE, 1 << irq);
+}
+
+static void xilinx_intc_unmask(unsigned int virq)
+{
+ int irq = irq_map[virq].hwirq;
+ void * regs = get_irq_chip_data(virq);
+ pr_debug("unmask: %d\n", irq);
+ out_be32(regs + SIE, 1 << irq);
+}
+
+static void xilinx_intc_ack(unsigned int virq)
+{
+ int irq = irq_map[virq].hwirq;
+ void * regs = get_irq_chip_data(virq);
+ pr_debug("ack: %d\n", irq);
+ out_be32(regs + IAR, 1 << irq);
+}
+
+static struct irq_chip xilinx_intc_irqchip = {
+ .typename = "Xilinx INTC",
+ .mask = xilinx_intc_mask,
+ .unmask = xilinx_intc_unmask,
+ .ack = xilinx_intc_ack,
+};
+
+/*
+ * IRQ Host operations
+ */
+static int xilinx_intc_map(struct irq_host *h, unsigned int virq,
+ irq_hw_number_t irq)
+{
+ set_irq_chip_data(virq, h->host_data);
+ set_irq_chip_and_handler(virq, &xilinx_intc_irqchip, handle_level_irq);
+ set_irq_type(virq, IRQ_TYPE_NONE);
+ return 0;
+}
+
+static struct irq_host_ops xilinx_intc_ops = {
+ .map = xilinx_intc_map,
+};
+
+struct irq_host * __init
+xilinx_intc_init(struct device_node *np)
+{
+ struct irq_host * irq;
+ struct resource res;
+ void * regs;
+ int rc;
+
+ /* Find and map the intc registers */
+ rc = of_address_to_resource(np, 0, &res);
+ if (rc) {
+ printk(KERN_ERR __FILE__ ": of_address_to_resource() failed\n");
+ return NULL;
+ }
+ regs = ioremap(res.start, 32);
+
+ printk(KERN_INFO "Xilinx intc at 0x%08X mapped to 0x%p\n",
+ res.start, regs);
+
+ /* Setup interrupt controller */
+ out_be32(regs + IER, 0); /* disable all irqs */
+ out_be32(regs + IAR, ~(u32) 0); /* Acknowledge pending irqs */
+ out_be32(regs + MER, 0x3UL); /* Turn on the Master Enable. */
+
+ /* Allocate and initialize an irq_host structure. */
+ irq = irq_alloc_host(np, IRQ_HOST_MAP_LINEAR, 32, &xilinx_intc_ops, -1);
+ if (!irq)
+ panic(__FILE__ ": Cannot allocate IRQ host\n");
+ irq->host_data = regs;
+ return irq;
+}
+
+int xilinx_intc_get_irq(void)
+{
+ void * regs = master_irqhost->host_data;
+ pr_debug("get_irq:\n");
+ return irq_linear_revmap(master_irqhost, in_be32(regs + IVR));
+}
+
+void __init xilinx_intc_init_tree(void)
+{
+ struct device_node *np;
+
+ /* find top level interrupt controller */
+ for_each_compatible_node(np, NULL, "xilinx,intc") {
+ if (!of_get_property(np, "interrupts", NULL))
+ break;
+ }
+
+ /* xilinx interrupt controller needs to be top level */
+ BUG_ON(!np);
+
+ master_irqhost = xilinx_intc_init(np);
+ BUG_ON(!master_irqhost);
+
+ irq_set_default_host(master_irqhost);
+ of_node_put(np);
+}
diff --git a/include/asm-powerpc/xilinx_intc.h b/include/asm-powerpc/xilinx_intc.h
new file mode 100644
index 0000000..343612f
--- /dev/null
+++ b/include/asm-powerpc/xilinx_intc.h
@@ -0,0 +1,20 @@
+/*
+ * Xilinx intc external definitions
+ *
+ * Copyright 2007 Secret Lab Technologies Ltd.
+ *
+ * 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 _ASM_POWERPC_XILINX_INTC_H
+#define _ASM_POWERPC_XILINX_INTC_H
+
+#ifdef __KERNEL__
+
+extern void __init xilinx_intc_init_tree(void);
+extern unsigned int xilinx_intc_get_irq(void);
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_XILINX_INTC_H */
^ permalink raw reply related
* [PATCH 01/18] Virtex: Add uartlite bootwrapper driver
From: Grant Likely @ 2007-09-28 18:15 UTC (permalink / raw)
To: linuxppc-dev, jwboyer, jacmet
In-Reply-To: <20070928181421.18608.74224.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/Makefile | 2 +
arch/powerpc/boot/ops.h | 1 +
arch/powerpc/boot/serial.c | 2 +
arch/powerpc/boot/uartlite.c | 64 ++++++++++++++++++++++++++++++++++++++++++
4 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index ca469e5..ac488ab 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -51,7 +51,7 @@ src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
- cpm-serial.c stdlib.c
+ cpm-serial.c stdlib.c uartlite.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index 703255b..4ef30e4 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -84,6 +84,7 @@ int serial_console_init(void);
int ns16550_console_init(void *devp, struct serial_console_data *scdp);
int mpsc_console_init(void *devp, struct serial_console_data *scdp);
int cpm_console_init(void *devp, struct serial_console_data *scdp);
+int uartlite_console_init(void *devp, struct serial_console_data *scdp);
void *simple_alloc_init(char *base, unsigned long heap_size,
unsigned long granularity, unsigned long max_allocs);
extern void flush_cache(void *, unsigned long);
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index d47f8e0..70f36bf 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -126,6 +126,8 @@ int serial_console_init(void)
dt_is_compatible(devp, "fsl,cpm2-scc-uart") ||
dt_is_compatible(devp, "fsl,cpm2-smc-uart"))
rc = cpm_console_init(devp, &serial_cd);
+ else if (dt_is_compatible(devp, "xilinx,uartlite"))
+ rc = uartlite_console_init(devp, &serial_cd);
/* Add other serial console driver calls here */
diff --git a/arch/powerpc/boot/uartlite.c b/arch/powerpc/boot/uartlite.c
new file mode 100644
index 0000000..f4249a7
--- /dev/null
+++ b/arch/powerpc/boot/uartlite.c
@@ -0,0 +1,64 @@
+/*
+ * Xilinx UARTLITE bootloader driver
+ *
+ * Copyright (C) 2007 Secret Lab Technologies Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <stdarg.h>
+#include <stddef.h>
+#include "types.h"
+#include "string.h"
+#include "stdio.h"
+#include "io.h"
+#include "ops.h"
+
+static void * reg_base;
+
+static int uartlite_open(void)
+{
+ /* Clear the RX FIFO */
+ out_be32(reg_base + 0x0C, 0x2);
+ return 0;
+}
+
+static void uartlite_putc(unsigned char c)
+{
+ while ((in_be32(reg_base + 0x8) & 0x08) != 0); /* spin */
+ out_be32(reg_base + 0x4, c);
+}
+
+static unsigned char uartlite_getc(void)
+{
+ while ((in_be32(reg_base + 0x8) & 0x01) == 0); /* spin */
+ return in_be32(reg_base);
+}
+
+static u8 uartlite_tstc(void)
+{
+ return ((in_be32(reg_base + 0x8) & 0x01) != 0);
+}
+
+int uartlite_console_init(void *devp, struct serial_console_data *scdp)
+{
+ int n;
+ unsigned long reg_phys;
+
+ n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
+ if (n != sizeof(reg_base)) {
+ if (!dt_xlate_reg(devp, 0, ®_phys, NULL))
+ return -1;
+
+ reg_base = (void *)reg_phys;
+ }
+
+ scdp->open = uartlite_open;
+ scdp->putc = uartlite_putc;
+ scdp->getc = uartlite_getc;
+ scdp->tstc = uartlite_tstc;
+ scdp->close = NULL;
+ return 0;
+}
^ permalink raw reply related
* [PATCH 02/18] Add Kconfig macros for Xilinx Virtex support
From: Grant Likely @ 2007-09-28 18:16 UTC (permalink / raw)
To: linuxppc-dev, jwboyer, jacmet
In-Reply-To: <20070928181421.18608.74224.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/40x/Kconfig | 30 +++++++++++++++++-------------
1 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
index c3dce3b..1aae0e6 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -61,13 +61,14 @@ config WALNUT
help
This option enables support for the IBM PPC405GP evaluation board.
-#config XILINX_ML300
-# bool "Xilinx-ML300"
-# depends on 40x
-# default y
-# select VIRTEX_II_PRO
-# help
-# This option enables support for the Xilinx ML300 evaluation board.
+config XILINX_VIRTEX_GENERIC_BOARD
+ bool "Generic Xilinx Virtex board"
+ depends on 40x
+ default y
+ select VIRTEX_II_PRO
+ select VIRTEX_4_FX
+ help
+ This option enables generic support for Xilinx Virtex based boards.
# 40x specific CPU modules, selected based on the board above.
config NP405H
@@ -91,11 +92,19 @@ config 405EP
config 405GPR
bool
-config VIRTEX_II_PRO
+config XILINX_VIRTEX
bool
+
+config XILINX_VIRTEX_II_PRO
+ bool
+ select XILINX_VIRTEX
select IBM405_ERR77
select IBM405_ERR51
+config XILINX_VIRTEX_4_FX
+ bool
+ select XILINX_VIRTEX
+
config STB03xxx
bool
select IBM405_ERR77
@@ -111,11 +120,6 @@ config IBM405_ERR77
config IBM405_ERR51
bool
-#config XILINX_OCP
-# bool
-# depends on XILINX_ML300
-# default y
-
#config BIOS_FIXUP
# bool
# depends on BUBINGA || EP405 || SYCAMORE || WALNUT
^ permalink raw reply related
* [PATCH 04/18] Xilinx Virtex: Add generic virtex board support
From: Grant Likely @ 2007-09-28 18:16 UTC (permalink / raw)
To: linuxppc-dev, jwboyer, jacmet
In-Reply-To: <20070928181421.18608.74224.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/40x/Makefile | 1 +
arch/powerpc/platforms/40x/virtex.c | 50 +++++++++++++++++++++++++++++++++++
2 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/Makefile b/arch/powerpc/platforms/40x/Makefile
index e6c0bbd..0a3cfe9 100644
--- a/arch/powerpc/platforms/40x/Makefile
+++ b/arch/powerpc/platforms/40x/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_WALNUT) += walnut.o
+obj-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD) += virtex.o
diff --git a/arch/powerpc/platforms/40x/virtex.c b/arch/powerpc/platforms/40x/virtex.c
new file mode 100644
index 0000000..ede982c
--- /dev/null
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -0,0 +1,50 @@
+/*
+ * Xilinx Virtex (IIpro & 4FX) based board support
+ *
+ * Copyright 2007 Secret Lab Technologies Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/init.h>
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/time.h>
+#include <asm/xilinx_intc.h>
+#include <asm/of_platform.h>
+
+static int __init virtex_device_probe(void)
+{
+ if (!machine_is(virtex))
+ return 0;
+
+ of_platform_bus_probe(NULL, NULL, NULL);
+
+ return 0;
+}
+device_initcall(virtex_device_probe);
+
+static int __init virtex_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, "xilinx,virtex"))
+ return 0;
+
+ return 1;
+}
+
+static void __init virtex_setup_arch(void)
+{
+}
+
+define_machine(virtex) {
+ .name = "Xilinx Virtex",
+ .probe = virtex_probe,
+ .setup_arch = virtex_setup_arch,
+ .init_IRQ = xilinx_intc_init_tree,
+ .get_irq = xilinx_intc_get_irq,
+ .calibrate_decr = generic_calibrate_decr,
+};
^ permalink raw reply related
* [PATCH 00/18] Virtex support in arch/powerpc
From: Grant Likely @ 2007-09-28 18:15 UTC (permalink / raw)
To: linuxppc-dev, jwboyer, jacmet
This series adds Xilinx Virtex support to arch/powerpc. Please review
and comment. It includes support for the uartlite and SystemACE devices
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Help with Device tree setup and booting kernel
From: Jon Smirl @ 2007-09-28 18:06 UTC (permalink / raw)
To: Nick; +Cc: linuxppc-embedded
In-Reply-To: <46FD311D.2050100@rogers.com>
On 9/28/07, Nick <ndroogh@rogers.com> wrote:
> Hi everyone,
>
> I am having trouble booting a 2.6.23-rc6 kernel with a device tree. My
> board is a MPC5200b base board with 128 Megs of DDR memeory.
> My UBoot (1.3.0-rc2)seems to be doing what is should be doing. I
> download the .dtb file to 00800000 and the uImage to 00200000
> I get the following:
>
> => bootm 00200000 - 00800000
> ## Booting image at 00200000 ...
> Image Name: Linux-2.6.23-rc6-gea60adb5-dirty
> Created: 2007-09-28 9:49:16 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1212342 Bytes = 1.2 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using the fdt at 0x800000
> Loading Device Tree to 007fc000, end 007fefff ... OK
>
> My board is now hung, with no more output to the console. My board does
> work. I have been running 2.6.19 for more than a year but I had to
> upgrade.
Does the machine name in the root of your device tree match the name
the code in arch/powerpc/platforms/52xx/whatever.c? You get what you
are seeing if the names don't match.
You also get this error if the kernel is looking someplace where the
device tree isn't.
Do these need to match? 007fc000 and 00800000
>
> I used the latest kernel code from DENX. Is this a good distribution or
> is there a better one somewhere else? I can send my dts file and the
> kernel .config file if anyone is willing to help
>
> Thanks in advance,
>
> Nick
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Help with Device tree setup and booting kernel
From: Nick @ 2007-09-28 16:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi everyone,
I am having trouble booting a 2.6.23-rc6 kernel with a device tree. My
board is a MPC5200b base board with 128 Megs of DDR memeory.
My UBoot (1.3.0-rc2)seems to be doing what is should be doing. I
download the .dtb file to 00800000 and the uImage to 00200000
I get the following:
=> bootm 00200000 - 00800000
## Booting image at 00200000 ...
Image Name: Linux-2.6.23-rc6-gea60adb5-dirty
Created: 2007-09-28 9:49:16 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1212342 Bytes = 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x800000
Loading Device Tree to 007fc000, end 007fefff ... OK
My board is now hung, with no more output to the console. My board does
work. I have been running 2.6.19 for more than a year but I had to
upgrade.
I used the latest kernel code from DENX. Is this a good distribution or
is there a better one somewhere else? I can send my dts file and the
kernel .config file if anyone is willing to help
Thanks in advance,
Nick
^ permalink raw reply
* Re: [PATCH 1/2] qemu platform, v2
From: Segher Boessenkool @ 2007-09-28 16:53 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, David Gibson, Rob Landley, Milton Miller,
Christoph Hellwig
In-Reply-To: <18165.60185.316393.213864@cargo.ozlabs.ibm.com>
>> I'd be following this more closely if compiling a device tree didn't
>> currently
>> require an external utility (dtc or some such) that doesn't come with
>> the
>> Linux kernel. No other target platform I've built kernels for
>> requires such
>> an environmental dependency.
>
> No? You haven't built kernels for other platforms that have external
> dependencies such as perl, gcc, make, binutils, etc.? :)
Two of the supported Linux archs cannot be built with a mainline
compiler, even!
And I have to install GNU sed/awk to get builds to work, too.
OTOH, it would be nice if we didn't need DTC -- it itself doesn't
build out-of-the-box on all systems, either ;-)
>> (This is a problem both for hardwiring the
>> device tree into the kernel and for building a new boot rom from the
>> linux
>> kernel's ppc boot wrapper that would contain such a device tree to
>> feed to
>> the kernel.)
>
> It's only really been a problem for ps3 so far, since the embedded
> guys don't seem to have any difficulty with installing dtc. We are
> looking at what to do for ps3 and prep, and the answer may well
> involve bundling dtc in the kernel source (it's not too big, around
> 3400 lines).
If only a few platforms have this problem, we could instead include
their .dtb files in the kernel source tree.
Segher
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Segher Boessenkool @ 2007-09-28 16:33 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <1190932629.6158.37.camel@pasglop>
> Also, you may want to try adding --ffixed-r13 to the CFLAGS in the
> makefile and let us know if it makes a difference... r13 is marked
> reserved by the ABI but segher seems to imply that gcc may decide to
> ues
> it anyway (ouch !)
That's what I thought for a second, but I misread the GCC sources.
This however brings up another point: for PPC32, -ffixed-r2 is
superfluous for all the same reasons as why we don't need -ffixed-r13
on PPC64. Is there any reason to keep it or is this just historical
cruft?
Segher
^ permalink raw reply
* Re: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Scott Wood @ 2007-09-28 16:09 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <12934517.post@talk.nabble.com>
Misbah khan wrote:
>
>
> Scott Wood-2 wrote:
>> They're used all over the place. Is there anything about them that you
>> find suspect?
>>
>> -Scott
>>
>> I have devloped a character driver for FPGA which is memory mapped and
>> using these API's to test a bit , set a bit or to clear a bit in the
>> memory for eg :-
Please don't use quote markers on newly added text.
>> /* poll till data is transfered from sdram to dpram */
>> while((test_bit(DFR_BUSY,(UINT32 *)(\
>> (void *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
>> && (delay < MAX_DELAY_BUSY))
You should use in_be32() rather than direct dereferencing.
>> {
>> KDEBUG3(" In the Dfr delay loop \n");
>> mdelay(DELAY);
>> delay+=DELAY;
>> }/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>>
>> if(delay==MAX_DELAY_BUSY)
>> {
>> KDEBUG1("Out of the the Dfr busy loop \n");
>> return -1;
>> }
>>
>> People working for FPGA are sure that they are not making the bit high
>> where in my driver is returning -1 from the kernel space aborting it after
>> running for few minutes or so .
I don't suppose the "few minutes" corresponds to MAX_DELAY_BUSY?
-Scott
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Scott Wood @ 2007-09-28 15:40 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-embedded
In-Reply-To: <200709281112.18480.jbe@pengutronix.de>
Juergen Beisert wrote:
> I tried with in_atomic(). The BUG report is gone, but the problem still
> exists.
>
> While network stress testing:
>
> [...]
> NETDEV WATCHDOG: eth0: transmit timed out
> net eth0: transmit timed out
> net eth0: queues didn't drain
> net eth0: tx: index: 35, outdex: 36
> net eth0: rx: index: 24, outdex: 25
> PHY: f0003000:00 - Link is Down
> PHY: f0003000:00 - Link is Up - 100/Full
>
> The link is up again, but any connection is dead (no answers to ping etc.).
> But the serial console is still working. I'm not sure if the RT-Preempt patch
> *causes* this behavior or only *discover* it. Any idea?
I'd try looking at the driver's locking to make sure that it's correct.
-Scott
^ permalink raw reply
* Re: Fwd: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
From: Jeff Garzik @ 2007-09-28 15:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, linux-ppc-embedded ((((E-Mail))))
In-Reply-To: <7F0D5001-BDDC-48A3-A414-2D3C1CE1574B@kernel.crashing.org>
Kumar Gala wrote:
> Begin forwarded message:
>
>> From: Jochen Friedrich <jochen@scram.de>
>> Date: September 24, 2007 12:15:35 PM CDT
>> To: linuxppc-embedded@ozlabs.org
>> Cc: linux-kernel@vger.kernel.org, Marcelo Tosatti <marcelo@kvack.org>
>> Subject: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
>
> Jeff,
>
> Please pick up for 2.6.23 if you don't mind.
Please send an apply-able patch...
Jeff, off to bed
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Jon Smirl @ 2007-09-28 15:38 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-embedded
In-Reply-To: <200709281707.45030.jbe@pengutronix.de>
On 9/28/07, Juergen Beisert <jbe@pengutronix.de> wrote:
> But I can't run it a second time, as the network on target's side doesn't
> respond. Any idea?
Do the stress tests complete on a non-rt kernel?
That will narrow down the type of bug being looked for.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Please pull from 'for-2.6.23' branch
From: Kumar Gala @ 2007-09-28 15:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Linus Torvalds
Please pull from 'for-2.6.23' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.23
to receive the following updates:
arch/powerpc/boot/dts/mpc8349emitx.dts | 1 +
arch/powerpc/platforms/83xx/usb.c | 4 ++--
arch/powerpc/sysdev/commproc.c | 2 +-
arch/ppc/8xx_io/commproc.c | 2 +-
drivers/serial/cpm_uart/cpm_uart_cpm1.h | 2 +-
5 files changed, 6 insertions(+), 5 deletions(-)
Jochen Friedrich (3):
[POWERPC] Fix copy'n'paste typo in commproc.c
[PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem
[POWERPC] Fix cpm_uart driver for cpm1 machines
jacmet@sunsite.dk (2):
[POWERPC] Fix mpc834x USB-MPH configuration.
[POWERPC] mpc8349emitx.dts: Setup USB-DR for peripheral mode.
commit f93c7c5aab8d5efaf99c88c8452d9303baabc89b
Author: jacmet@sunsite.dk <jacmet@sunsite.dk>
Date: Fri Sep 28 16:21:15 2007 +0200
[POWERPC] mpc8349emitx.dts: Setup USB-DR for peripheral mode.
Setup dr_mode for USB-DR to peripheral as the default (host mode) doesn't make
much sense for the mini-AB connector on the ITX board.
Peripheral mode is preferable to OTG as the fsl_usb2_udc.c driver doesn't yet
properly support it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 39db0fd9db6caea8887f61fee4a0e53c6f8fec5e
Author: jacmet@sunsite.dk <jacmet@sunsite.dk>
Date: Fri Sep 28 16:21:14 2007 +0200
[POWERPC] Fix mpc834x USB-MPH configuration.
mpc834x USB-MPH configuration got broken by commit
6f442560021aecf08658e26ed9a37e6928ef0fa1. The selection bits in SICRL
should be cleared rather than set to configure the USB MUXes for the MPH.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit d214602804a85e5da68b745ae69d9beaa5bedc93
Author: Jochen Friedrich <jochen@scram.de>
Date: Mon Sep 24 19:15:43 2007 +0200
[POWERPC] Fix cpm_uart driver for cpm1 machines
in cpm_uart_cpm1.h, DPRAM_BASE is assigned an address derived from cpmp.
On ARC=ppc, this is a physical address with 1:1 DMA mapping which can't
be used for arithmetric compare operations with virtual addresses
returned by cpm_dpram_addr. This patch changes the assignment to use
cpm_dpram_addr as well, like in cpm_uart_cpm2.h.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit bc63818931ea55c54d6e59b7d38bff8f295dc8c1
Author: Jochen Friedrich <jochen@scram.de>
Date: Mon Sep 24 19:14:57 2007 +0200
[PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem
cpm_dpram_addr returns physical memory of the DP RAM instead of
iomapped virtual memory. As there usually is a 1:1 MMU map of
the IMMR area, this is often not noticed. However, cpm_dpram_phys
assumes this iomapped virtual memory and returns garbage on the
1:1 mapped memory causing CPM1 uart console to fail.
This patch fixes the problem (copied from the powerpc tree).
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 83af919e0f239e87bc644a2c932b9cebf5771380
Author: Jochen Friedrich <jochen@scram.de>
Date: Mon Sep 24 19:13:46 2007 +0200
[POWERPC] Fix copy'n'paste typo in commproc.c
The powerpc version of commproc.c exports cpm_dpram_addr twice
and cpm_dpram_phys not at all due to a typo. This patch fixes this
problem.
CC arch/powerpc/sysdev/commproc.o
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__kcrctab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__kcrctab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__kstrtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__kstrtab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__ksymtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__ksymtab_cpm_dpram_addr' was here
make[1]: *** [arch/powerpc/sysdev/commproc.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 502f47c..44c065a 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -99,6 +99,7 @@
#size-cells = <0>;
interrupt-parent = < &ipic >;
interrupts = <26 8>;
+ dr_mode = "peripheral";
phy_type = "ulpi";
};
diff --git a/arch/powerpc/platforms/83xx/usb.c b/arch/powerpc/platforms/83xx/usb.c
index e7fdf01..eafe760 100644
--- a/arch/powerpc/platforms/83xx/usb.c
+++ b/arch/powerpc/platforms/83xx/usb.c
@@ -76,14 +76,14 @@ int mpc834x_usb_cfg(void)
if (port0_is_dr)
printk(KERN_WARNING
"834x USB port0 can't be used by both DR and MPH!\n");
- sicrl |= MPC834X_SICRL_USB0;
+ sicrl &= ~MPC834X_SICRL_USB0;
}
prop = of_get_property(np, "port1", NULL);
if (prop) {
if (port1_is_dr)
printk(KERN_WARNING
"834x USB port1 can't be used by both DR and MPH!\n");
- sicrl |= MPC834X_SICRL_USB1;
+ sicrl &= ~MPC834X_SICRL_USB1;
}
of_node_put(np);
}
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index 4f67b89..dd5417a 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -395,4 +395,4 @@ uint cpm_dpram_phys(u8* addr)
{
return (dpram_pbase + (uint)(addr - dpram_vbase));
}
-EXPORT_SYMBOL(cpm_dpram_addr);
+EXPORT_SYMBOL(cpm_dpram_phys);
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
index 7088428..9da880b 100644
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -459,7 +459,7 @@ EXPORT_SYMBOL(cpm_dpdump);
void *cpm_dpram_addr(unsigned long offset)
{
- return ((immap_t *)IMAP_ADDR)->im_cpm.cp_dpmem + offset;
+ return (void *)(dpram_vbase + offset);
}
EXPORT_SYMBOL(cpm_dpram_addr);
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.h b/drivers/serial/cpm_uart/cpm_uart_cpm1.h
index a99e45e..2a64778 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm1.h
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.h
@@ -37,6 +37,6 @@ static inline void cpm_set_smc_fcr(volatile smc_uart_t * up)
up->smc_tfcr = SMC_EB;
}
-#define DPRAM_BASE ((unsigned char *)&cpmp->cp_dpmem[0])
+#define DPRAM_BASE ((unsigned char *)cpm_dpram_addr(0))
#endif
^ permalink raw reply related
* Fwd: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
From: Kumar Gala @ 2007-09-28 15:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-ppc-embedded ((((E-Mail))))
In-Reply-To: <46F7F0B7.2090205@scram.de>
Begin forwarded message:
> From: Jochen Friedrich <jochen@scram.de>
> Date: September 24, 2007 12:15:35 PM CDT
> To: linuxppc-embedded@ozlabs.org
> Cc: linux-kernel@vger.kernel.org, Marcelo Tosatti <marcelo@kvack.org>
> Subject: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
Jeff,
Please pick up for 2.6.23 if you don't mind.
- k
>
>
> Add #include <asm/cacheflush.h> for flush_dcache_range
> to make the driver compile again.
>
> CC arch/ppc/8xx_io/enet.o
> arch/ppc/8xx_io/enet.c: In function 'scc_enet_start_xmit':
> arch/ppc/8xx_io/enet.c:240: error: implicit declaration of function
> 'flush_dcache_range'
> make[1]: *** [arch/ppc/8xx_io/enet.o] Error 1
> make: *** [arch/ppc/8xx_io] Error 2
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> ---
> arch/ppc/8xx_io/enet.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
> diff --git a/arch/ppc/8xx_io/enet.c b/arch/ppc/8xx_io/enet.c
> index 703d47e..eace3bc 100644
> --- a/arch/ppc/8xx_io/enet.c
> +++ b/arch/ppc/8xx_io/enet.c
> @@ -44,6 +44,7 @@
> #include <asm/mpc8xx.h>
> #include <asm/uaccess.h>
> #include <asm/commproc.h>
> +#include <asm/cacheflush.h>
>
> /*
> * Theory of Operation
>
^ permalink raw reply
* Re: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16
From: Milton Miller @ 2007-09-28 15:16 UTC (permalink / raw)
To: David Gibson; +Cc: ppcdev
In-Reply-To: <20070928024052.GA18840@localhost.localdomain>
On Sep 27, 2007, at 9:40 PM, David Gibson wrote:
> On Thu, Sep 27, 2007 at 10:44:27AM -0500, Milton Miller wrote:
>> On Sep 26, 2007, at 9:45 PM, David Gibson wrote:
>>>> The actual binary structure is compatable, just not the contents of
>>>> the
>>>> properties nor how any slave cpus wait (for some trees it doesn't
>>>> matter).
>>
>> Sorry, copy and paste error. I was tring to point out this changelog
>> in 2.6.10:
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;
>> a=commitdiff;h=e1b47549d1588ccea1fa5726eb430aae4e80f8ed
>
> Hrm, I see, yes that seems conclusive enough. Yuck.
>
> In which case, I think we should try to forget that v1 ever existed.
> I don't think anyone ever generated v1 trees other than kernels which
> also consumed them,
I believe this to be true, unless you count telling dtc to do so.
> and I doubt current kernels will correctly deal
> with v1 trees in this form.
I'm quite certain of that.
> In any case, this is all rather beside the point. My basic point is
> that this bootwrapper stuff should not attempt to be a general
> backwards compatibility layer for every broken early dt format that
> ever existed.
The only broken format was v1; I was submitting v2 :-). Version 16 was
"... to support a more compact representation, for use by embedded
systems mostly"
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;
a=commitdiff;h=34153fa3af45d84f3221d9b67ba2ab7e8a220d28
> In general we should try to make sure nothing ever uses
> <v16 trees. We want, here, to do the minimum we can get away with to
> support the specific v2 trees produced by kexec-tools, as an interim
> measure
As I stated, that by itself isn't sufficient for my usage, as I have
other v2 trees I need to deal with, at least until that generator gets
updated.
> while kexec-tools itself is fixed to produce v17 trees (say,
> by replacing fs2dt with dtc plus a libfdt based post-processing
> program).
If you thought there were complaints trying to require an external
utility to build zImage, just wait until you try to make kexec-tools
not be self-contained. Currently kexec doesn't even use a data
directory, instead it builds the purgatory and other trampoline
binaries into the kexec program. Incorporating the post-processing and
generation using libfdt (with a copy of the library in the source)
could fly, if people don't care about kexec into kernels from 2.6.10 to
2.6.14 when v16 was merged (about 1 year).
Actually, there is another approach: put this converter in kexec's
purgatory or even the kexec program. It can then run conditionally
under command line flags to keep compatibility with the old kernels.
If and when its is decided to only support >=v16 in kexec-tools it can
be removed and we don't have this interim support code in the kernel
forever (I'll handle my other usage out of tree).
milton
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Juergen Beisert @ 2007-09-28 15:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200709271907.50479.jbe@pengutronix.de>
On Thursday 27 September 2007 19:07, Juergen Beisert wrote:
> On Friday 10 August 2007 11:51, Domen Puncer wrote:
> > Not for merge (yet)! But please do review.
> >
> > fec_mpc52xx driver (not in-tree, but floating around) isn't in very
> > good shape, so I tried to change that.
> > Diff against original is quite big (fec_phy.c is completely rewritten)
> > and confuzing, so I'm including whole drivers/net/fec_mpc52xx/ .
> >
> > I still have 'make CONFIG_FEC_MPC52xx_MDIO=3Dn compile and work' on my
> > TODO, maybe even ethtool support.
I add a few more debug outputs and now with this driver I can run a
$ nmap <ip>
from my host against the target and target's network stops always at the sa=
me=20
point.
The last output from the driver is (with DEBUG macro defined):
net eth0: ievent: 08020000
and no further interrupt occurs anymore (I checked all three interrupt entr=
y=20
functions)
nmap on host's side outputs:
Starting Nmap 4.20 ( http://insecure.org ) at 2007-09-28 16:56 CEST
Interesting ports on 192.168.23.226:
Not shown: 852 filtered ports, 843 closed ports
PORT STATE SERVICE
22/tcp open ssh
23/tcp open telnet
Nmap finished: 1 IP address (1 host up) scanned in 14.120 seconds
But I can't run it a second time, as the network on target's side doesn't=20
respond. Any idea?
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* [patch 0/2] MPC834x USB patches
From: jacmet @ 2007-09-28 14:21 UTC (permalink / raw)
To: galak, leoli, linuxppc-dev
MPC834x USB patches. The first is quite serious and would be nice
to get in 2.6.23.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [patch 1/2] Fix mpc834x USB-MPH configuration.
From: jacmet @ 2007-09-28 14:21 UTC (permalink / raw)
To: galak, leoli, linuxppc-dev
In-Reply-To: <20070928142113.163317000@sunsite.dk>
mpc834x USB-MPH configuration got broken by commit
6f442560021aecf08658e26ed9a37e6928ef0fa1. The selection bits in SICRL
should be cleared rather than set to configure the USB MUXes for the MPH.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/powerpc/platforms/83xx/usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.23-rc8/arch/powerpc/platforms/83xx/usb.c
===================================================================
--- linux-2.6.23-rc8.orig/arch/powerpc/platforms/83xx/usb.c
+++ linux-2.6.23-rc8/arch/powerpc/platforms/83xx/usb.c
@@ -76,14 +76,14 @@
if (port0_is_dr)
printk(KERN_WARNING
"834x USB port0 can't be used by both DR and MPH!\n");
- sicrl |= MPC834X_SICRL_USB0;
+ sicrl &= ~MPC834X_SICRL_USB0;
}
prop = of_get_property(np, "port1", NULL);
if (prop) {
if (port1_is_dr)
printk(KERN_WARNING
"834x USB port1 can't be used by both DR and MPH!\n");
- sicrl |= MPC834X_SICRL_USB1;
+ sicrl &= ~MPC834X_SICRL_USB1;
}
of_node_put(np);
}
--
Bye, Peter Korsgaard
^ permalink raw reply
* [patch 2/2] mpc8349emitx.dts: Setup USB-DR for peripheral mode.
From: jacmet @ 2007-09-28 14:21 UTC (permalink / raw)
To: galak, leoli, linuxppc-dev
In-Reply-To: <20070928142113.163317000@sunsite.dk>
Setup dr_mode for USB-DR to peripheral as the default (host mode) doesn't make
much sense for the mini-AB connector on the ITX board.
Peripheral mode is preferable to OTG as the fsl_usb2_udc.c driver doesn't yet
properly support it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.23-rc8/arch/powerpc/boot/dts/mpc8349emitx.dts
===================================================================
--- linux-2.6.23-rc8.orig/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ linux-2.6.23-rc8/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -99,6 +99,7 @@
#size-cells = <0>;
interrupt-parent = < &ipic >;
interrupts = <26 8>;
+ dr_mode = "peripheral";
phy_type = "ulpi";
};
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Valentine Barshak @ 2007-09-28 14:23 UTC (permalink / raw)
To: David Gibson, linuxppc-dev
In-Reply-To: <20070925022935.GI30338@localhost.localdomain>
David Gibson wrote:
> On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
>> Currently zImage is linked at the 4MB base address.
>> Some platforms (using cuboot, treeboot) need the zImage's
>> entry point and base address. They place zImage exactly
>> at the base address it's been linked to. Sometimes 4MB left
>> at the start of the memory is simply not enough to unpack zImage.
>> This could happen with initramfs enabled, since the kernel image
>> packed along with initramfs.cpio could be over 5MB in size.
>> This patch checks vmlinux image size and links zImage at
>> the base address that is equal to the unpacked image size
>> aligned to 4MB boundary. This way zImage base address is 4MB
>> only if unpacked kernel image size is less then 4MB.
>
> Good plan. However..
>
> [snip]
>> diff -ruN linux-2.6.orig/arch/powerpc/boot/zImage.lds.S linux-2.6/arch/powerpc/boot/zImage.lds.S
>> --- linux-2.6.orig/arch/powerpc/boot/zImage.lds.S 2007-09-22 00:48:08.000000000 +0400
>> +++ linux-2.6/arch/powerpc/boot/zImage.lds.S 2007-09-22 04:03:58.000000000 +0400
>> @@ -3,7 +3,7 @@
>> EXTERN(_zimage_start)
>> SECTIONS
>> {
>> - . = (4*1024*1024);
>> + . = ALIGN((_kend - _kstart), (4*1024*1024));
>
> ..I don't see any reason to keep the 4MB granularity. I would just
> align the address to say a 64k boundary (64k because that's the
> granularity used in the normal ABI).
Looking deeper at this I've found that currently u-boot thinks that
memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ
defined as (8 << 20)), although all physical memory is identity mapped.
That's why it puts command line and board info structure as high as
possible within the first 8MB. This worked fine with uImage, since
u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher
(we need space at the start of the memory to eventually put vmlinux
image there). So, if unpacked kernel image crosses 8MB boundary, it gets
damaged by u-boot when it prepares cmd_line and bdinfo. The possible
workaround for that is to always link zImage at >=8MB base or to have
4MB granularity like this:
+ . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));
Reserve at least 64K for u-boot cmd_line and bdinfo.
Thanks,
Valentine.
>
>> _start = .;
>> .text :
>> {
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Gerhard Pircher @ 2007-09-28 9:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18172.15699.359375.286439@cargo.ozlabs.ibm.com>
-------- Original-Nachricht --------
> Datum: Fri, 28 Sep 2007 09:31:31 +1000
> Von: Paul Mackerras <paulus@samba.org>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> You appear to have a working 16550-style serial port which the udbg
> infrastructure sees. Thus you should be able to use xmon, talking to
I couldn't get udbg running yet. Maybe i didn't specify a proper kernel
boot argument.
> it via the serial port. Put "xmon" on the kernel command line and the
> kernel will drop into xmon early in the boot process (in setup_arch).
> Then, either the kernel will oops at some point and drop into xmon,
> and you can then inspect memory and registers and get a stack trace,
> or it will hang at some point. If it hangs, you can work out where it
> hangs by putting in breakpoints at various points and seeing which
> breakpoints you get to (this might take several boots).
Okay, I'll investigate it. Is there a documentation for xmon (Google
wasn't really helpful in this case).
Thanks!
regards,
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: Flash paritioning and JFFS2
From: Mirek23 @ 2007-09-28 9:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1189180542.4826.33.camel@louie>
Dear All,
Finally I have sorted out few problems with linux and u-boot and I have
tried to come back to the jffs2 and mtd partitioning issue.
I am using CFI driver and I pass partitioning information from command line
via u-boot.
This part works fine:
Unfortunatly I have the problem when accesing the flash partitions because
my Avnet evaluation board is designet in such a way that the data should be
accessed in the mode x16 (16 bits in each goal).
Linux CFI driver is able to detect the x16 mode but it does not handle it
correctly.
I will give you an example:
My mtd1 partition contains the u-boot environment. When I print the mtd1
contents with (busybox) hexdump I get:
00000000 eb 92 00 00 62 6f 00 00 61 72 00 00 3d 63 00 00
|....bo..ar..=c..|
00000010 73 6f 00 00 3d 74 00 00 55 4c 00 00 39 36 00 00
|so..=t..UL..96..|
00000020 20 72 00 00 74 3d 00 00 65 76 00 00 66 73 00 00 |
r..t=..ev..fs..|
00000030 77 20 00 00 73 72 00 00 74 3d 00 00 39 2e 00 00 |w
..sr..t=..9...|
00000040 39 2e 00 00 34 2e 00 00 33 3a 00 00 70 74 00 00
|9...4...3:..pt..|
00000050 6c 64 00 00 31 2f 00 00 63 5f 00 00 78 2c 00 00
|ld..1/..c_..x,..|
00000060 70 20 00 00 70 3d 00 00 3a 3a 00 00 72 74 00 00 |p
..p=..::..rt..|
00000070 34 2d 00 00 72 65 00 00 65 74 00 00 3a 64 00 00
|4-..re..et..:d..|
When I copy the contents of the /dev/mtd1 to the file by 2 bytes (bs=2) I
get correct
readout:
dd if=/dev/mtd1 of=./u-boot_Env.txt bs=2 count=128k
hexdump ./u-boot_Env.txt
00000000 eb 92 c9 6d 62 6f 6f 74 61 72 67 73 3d 63 6f 6e
|...mbootargs=con|
00000010 73 6f 6c 65 3d 74 74 79 55 4c 30 2c 39 36 30 30
|sole=ttyUL0,9600|
00000020 20 72 6f 6f 74 3d 2f 64 65 76 2f 6e 66 73 20 72 | root=/dev/nfs
r|
00000030 77 20 6e 66 73 72 6f 6f 74 3d 31 32 39 2e 31 32 |w
nfsroot=129.12|
00000040 39 2e 31 34 34 2e 31 31 33 3a 2f 6f 70 74 2f 65
|9.144.113:/opt/e|
00000050 6c 64 6b 34 31 2f 70 70 63 5f 34 78 78 2c 74 63
|ldk41/ppc_4xx,tc|
The real problems begin when I want to deal with jffs2 file system.
I have mtd3 partition which is intended to hold jffs2 fs.
To create the jffs2 fs I do:
./mkfs.jffs2 --pad=0xA0000 --eraseblock=0x20000 --root=/tmp/bin/mtd1/work/
--output=image2.jffs2
flash_erase /dev/mtd3
dd if=./image2.jffs2 of=/dev/mtd3 bs=2 count=655360
After that I have jffs2 fs under /dev/mtd3.
When I try to mount the jffs2 partition fun begins:
mount -t jffs2 /dev/mtdblock3 /mnt
[ 2828.462121] jffs2_scan_eraseblock(): Node at 0x00000000 {0x1985, 0x2003,
0x00000000) has invalid CRC 0xf0600000 (calculated 0xf9d690b3)
[ 2828.610485] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00000008: 0xf060 instead
[ 2828.719326] jffs2_scan_eraseblock(): Node at 0x0000000c {0x1985, 0xe001,
0x00000000) has invalid CRC 0xc3200000 (calculated 0x92fedd67)
[ 2828.870047] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00000014: 0xc320 instead
[ 2828.979854] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00000024: 0x46fc instead
.
.
.
.
[ 2834.858103] Further such events for this erase block will not be printed
[ 2835.029913] Cowardly refusing to erase blocks on filesystem with no valid
JFFS2 nodes
[ 2835.124378] empty_blocks 0, bad_blocks 0, c->nr_blocks 5
mount: mounting /dev/mtdblock3 on /mnt failed
I have examined carefully the above output and what I see is that linux does
not properly access the flash memory:
I did the hexdump on the image2.jffs2 (which is placed in /dev/mtd3) and
compared it with the jffs2 mount messages:
hexdump -C image2.jffs2
00000000 19 85 20 03 00 00 00 0c f0 60 dc 98 19 85 e0 01 |..
......`......|
00000010 00 00 00 31 c3 20 dd 5d 00 00 00 01 00 00 00 00 |...1.
.]........|
jffs2_scan_eraseblock(): Node at 0x00000000 {0x1985, 0x2003, 0x00000000) has
invalid CRC 0xf0600000 (calculated 0xf9d690b3)
The linux mount complains about wrong CRC (invalid CRC 0xf0600000) but in
the memory it is
f0 60 dc 98 (so it means that it was read in byte by byte mode but not in
x16 (2 bytes) mode).
Does somebody know how to fix this problem?
Best Regards
Mirek
--
View this message in context: http://www.nabble.com/Flash-paritioning-and-JFFS2-tf4317566.html#a12937526
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 08/10] ia64: Convert cpu_sibling_map to a per_cpu data array (v3)
From: Paul Jackson @ 2007-09-28 9:49 UTC (permalink / raw)
To: travis; +Cc: linux-mm, ak, linux-kernel, linuxppc-dev, sparclinux, akpm,
clameter
In-Reply-To: <20070912015647.214306428@sgi.com>
Mike,
I think there is a bug either in this ia64 patch, or in the related
generic arch patch: Convert cpu_sibling_map to be a per cpu variable
(v3).
It dies early in boot on me, on the SGI internal 8 processor IA64
system that you and I know as 'margin'. The death is a hard hang, due
to a corrupt stack, due to a bogus cpu index.
I haven't tracked it down all the way, but have gotten this far. If I add
the following patch, I get a panic on the BUG_ON if I have these two patches
in 2.6.23-rc8-mm1, but it boots just fine if I don't have these two patches.
It seems that the "cpu_sibling_map[cpu]" cpumask_t is empty (all zero
bits) with your two patches applied, but has some non-zero bits
otherwise, which leads to 'group' being NR_CPUS instead of a useful CPU
number. Unfortunately, I have no idea why the "cpu_sibling_map[cpu]"
cpumask_t is empty -- good luck on that part.
The patch that catches this bug earlier is this:
--- 2.6.23-rc8-mm1.orig/kernel/sched.c 2007-09-28 01:42:20.144561024 -0700
+++ 2.6.23-rc8-mm1/kernel/sched.c 2007-09-28 02:27:14.239075497 -0700
@@ -5905,6 +5905,7 @@ static int cpu_to_phys_group(int cpu, co
#else
group = cpu;
#endif
+ BUG_ON(group == NR_CPUS);
if (sg)
*sg = &per_cpu(sched_group_phys, group);
return group;
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ 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