* [PATCH 4/7] [PPC] Stop using ppc_sys for Xilinx Virtex boards
From: Grant Likely @ 2007-04-27 19:50 UTC (permalink / raw)
To: linuxppc-embedded, paulus; +Cc: Peter Korsgaard, Andrei Konovalov, Rick Moleres
In-Reply-To: <11777034141879-git-send-email-grant.likely@secretlab.ca>
The arch/ppc/syslib/ppc_sys.c infrastructure does not work well for the
virtex ports. Move the ml300 and ml403 board ports over to use the new
virtex_devices infrastructure.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/ppc/platforms/4xx/Makefile | 1 -
arch/ppc/platforms/4xx/virtex.c | 56 ----------------------------
arch/ppc/platforms/4xx/virtex.h | 7 +---
arch/ppc/platforms/4xx/xilinx_ml300.c | 64 ++------------------------------
arch/ppc/platforms/4xx/xilinx_ml403.c | 65 ++-------------------------------
arch/ppc/syslib/Makefile | 3 +-
include/asm-ppc/ppc_sys.h | 2 -
7 files changed, 11 insertions(+), 187 deletions(-)
delete mode 100644 arch/ppc/platforms/4xx/virtex.c
diff --git a/arch/ppc/platforms/4xx/Makefile b/arch/ppc/platforms/4xx/Makefile
index fa6610b..723ad79 100644
--- a/arch/ppc/platforms/4xx/Makefile
+++ b/arch/ppc/platforms/4xx/Makefile
@@ -28,5 +28,4 @@ obj-$(CONFIG_440SP) += ibm440sp.o
obj-$(CONFIG_440SPE) += ppc440spe.o
obj-$(CONFIG_405EP) += ibm405ep.o
obj-$(CONFIG_405GPR) += ibm405gpr.o
-obj-$(CONFIG_XILINX_VIRTEX) += virtex.o
diff --git a/arch/ppc/platforms/4xx/virtex.c b/arch/ppc/platforms/4xx/virtex.c
deleted file mode 100644
index 133a831..0000000
--- a/arch/ppc/platforms/4xx/virtex.c
+++ /dev/null
@@ -1,56 +0,0 @@
-/*
- * Virtex-II Pro & Virtex-4 FX common infrastructure
- *
- * Maintainer: Grant Likely <grant.likely@secretlab.ca>
- *
- * Copyright 2005 Secret Lab Technologies Ltd.
- * Copyright 2005 General Dynamics Canada Ltd.
- * Copyright 2005 Freescale Semiconductor Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include <linux/init.h>
-#include <linux/module.h>
-#include <linux/device.h>
-#include <linux/serial_8250.h>
-#include <asm/ppc_sys.h>
-#include <platforms/4xx/virtex.h>
-#include <platforms/4xx/xparameters/xparameters.h>
-
-#define XPAR_UART(num) { \
- .mapbase = XPAR_UARTNS550_##num##_BASEADDR + 3, \
- .irq = XPAR_INTC_0_UARTNS550_##num##_VEC_ID, \
- .iotype = UPIO_MEM, \
- .uartclk = XPAR_UARTNS550_##num##_CLOCK_FREQ_HZ, \
- .flags = UPF_BOOT_AUTOCONF, \
- .regshift = 2, \
- }
-
-struct plat_serial8250_port serial_platform_data[] = {
-#ifdef XPAR_UARTNS550_0_BASEADDR
- XPAR_UART(0),
-#endif
-#ifdef XPAR_UARTNS550_1_BASEADDR
- XPAR_UART(1),
-#endif
-#ifdef XPAR_UARTNS550_2_BASEADDR
- XPAR_UART(2),
-#endif
-#ifdef XPAR_UARTNS550_3_BASEADDR
- XPAR_UART(3),
-#endif
- { }, /* terminated by empty record */
-};
-
-struct platform_device ppc_sys_platform_devices[] = {
- [VIRTEX_UART] = {
- .name = "serial8250",
- .id = 0,
- .dev.platform_data = serial_platform_data,
- },
-};
-
diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virtex.h
index e9f58a7..4fc76da 100644
--- a/arch/ppc/platforms/4xx/virtex.h
+++ b/arch/ppc/platforms/4xx/virtex.h
@@ -19,13 +19,8 @@
#if !defined(BASE_BAUD)
#define BASE_BAUD (0) /* dummy value; not used */
#endif
-
-/* Device type enumeration for platform bus definitions */
+
#ifndef __ASSEMBLY__
-enum ppc_sys_devices {
- VIRTEX_UART, NUM_PPC_SYS_DEVS,
-};
-
typedef struct board_info {
unsigned int bi_memsize; /* DRAM installed, in bytes */
unsigned char bi_enetaddr[6]; /* Local Ethernet MAC address */
diff --git a/arch/ppc/platforms/4xx/xilinx_ml300.c b/arch/ppc/platforms/4xx/xilinx_ml300.c
index 4e4aca4..6e522fe 100644
--- a/arch/ppc/platforms/4xx/xilinx_ml300.c
+++ b/arch/ppc/platforms/4xx/xilinx_ml300.c
@@ -18,9 +18,9 @@
#include <linux/serialP.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/ppc_sys.h>
#include <syslib/gen550.h>
+#include <syslib/virtex_devices.h>
#include <platforms/4xx/xparameters/xparameters.h>
/*
@@ -53,25 +53,9 @@
* ppc4xx_pic_init arch/ppc/syslib/xilinx_pic.c
*/
-/* Board specifications structures */
-struct ppc_sys_spec *cur_ppc_sys_spec;
-struct ppc_sys_spec ppc_sys_specs[] = {
- {
- /* Only one entry, always assume the same design */
- .ppc_sys_name = "Xilinx ML300 Reference Design",
- .mask = 0x00000000,
- .value = 0x00000000,
- .num_devices = 1,
- .device_list = (enum ppc_sys_devices[])
- {
- VIRTEX_UART,
- },
- },
-};
const char* virtex_machine_name = "ML300 Reference Design";
#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
-
static volatile unsigned *powerdown_base =
(volatile unsigned *) XPAR_POWER_0_POWERDOWN_BASEADDR;
@@ -96,52 +80,14 @@ ml300_map_io(void)
#endif
}
-/* Early serial support functions */
-static void __init
-ml300_early_serial_init(int num, struct plat_serial8250_port *pdata)
-{
-#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
- struct uart_port serial_req;
-
- memset(&serial_req, 0, sizeof(serial_req));
- serial_req.mapbase = pdata->mapbase;
- serial_req.membase = pdata->membase;
- serial_req.irq = pdata->irq;
- serial_req.uartclk = pdata->uartclk;
- serial_req.regshift = pdata->regshift;
- serial_req.iotype = pdata->iotype;
- serial_req.flags = pdata->flags;
- gen550_init(num, &serial_req);
-#endif
-}
-
-void __init
-ml300_early_serial_map(void)
-{
-#ifdef CONFIG_SERIAL_8250
- struct plat_serial8250_port *pdata;
- int i = 0;
-
- pdata = (struct plat_serial8250_port *) ppc_sys_get_pdata(VIRTEX_UART);
- while(pdata && pdata->flags)
- {
- pdata->membase = ioremap(pdata->mapbase, 0x100);
- ml300_early_serial_init(i, pdata);
- pdata++;
- i++;
- }
-#endif /* CONFIG_SERIAL_8250 */
-}
-
void __init
ml300_setup_arch(void)
{
- ml300_early_serial_map();
+ virtex_early_serial_map();
ppc4xx_setup_arch(); /* calls ppc4xx_find_bridges() */
/* Identify the system */
- printk(KERN_INFO "Xilinx Virtex-II Pro port\n");
- printk(KERN_INFO "Port by MontaVista Software, Inc. (source@mvista.com)\n");
+ printk(KERN_INFO "Xilinx ML300 Reference System (Virtex-II Pro)\n");
}
/* Called after board_setup_irq from ppc4xx_init_IRQ(). */
@@ -157,8 +103,6 @@ platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
{
ppc4xx_init(r3, r4, r5, r6, r7);
- identify_ppc_sys_by_id(mfspr(SPRN_PVR));
-
ppc_md.setup_arch = ml300_setup_arch;
ppc_md.setup_io_mappings = ml300_map_io;
ppc_md.init_IRQ = ml300_init_irq;
@@ -168,7 +112,7 @@ platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
#endif
#ifdef CONFIG_KGDB
- ppc_md.early_serial_map = ml300_early_serial_map;
+ ppc_md.early_serial_map = virtex_early_serial_map;
#endif
}
diff --git a/arch/ppc/platforms/4xx/xilinx_ml403.c b/arch/ppc/platforms/4xx/xilinx_ml403.c
index c98e40a..bc3ace3 100644
--- a/arch/ppc/platforms/4xx/xilinx_ml403.c
+++ b/arch/ppc/platforms/4xx/xilinx_ml403.c
@@ -1,11 +1,9 @@
/*
- * arch/ppc/platforms/4xx/xilinx_ml403.c
- *
* Xilinx ML403 evaluation board initialization
*
* Author: Grant Likely <grant.likely@secretlab.ca>
*
- * 2005 (c) Secret Lab Technologies Ltd.
+ * 2005-2007 (c) Secret Lab Technologies Ltd.
* 2002-2004 (c) MontaVista Software, Inc.
*
* This file is licensed under the terms of the GNU General Public License
@@ -22,9 +20,9 @@
#include <linux/serialP.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/ppc_sys.h>
#include <syslib/gen550.h>
+#include <syslib/virtex_devices.h>
#include <platforms/4xx/xparameters/xparameters.h>
/*
@@ -57,25 +55,9 @@
* ppc4xx_pic_init arch/ppc/syslib/xilinx_pic.c
*/
-/* Board specifications structures */
-struct ppc_sys_spec *cur_ppc_sys_spec;
-struct ppc_sys_spec ppc_sys_specs[] = {
- {
- /* Only one entry, always assume the same design */
- .ppc_sys_name = "Xilinx ML403 Reference Design",
- .mask = 0x00000000,
- .value = 0x00000000,
- .num_devices = 1,
- .device_list = (enum ppc_sys_devices[])
- {
- VIRTEX_UART,
- },
- },
-};
const char* virtex_machine_name = "ML403 Reference Design";
#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
-
static volatile unsigned *powerdown_base =
(volatile unsigned *) XPAR_POWER_0_POWERDOWN_BASEADDR;
@@ -100,47 +82,10 @@ ml403_map_io(void)
#endif
}
-/* Early serial support functions */
-static void __init
-ml403_early_serial_init(int num, struct plat_serial8250_port *pdata)
-{
-#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
- struct uart_port serial_req;
-
- memset(&serial_req, 0, sizeof(serial_req));
- serial_req.mapbase = pdata->mapbase;
- serial_req.membase = pdata->membase;
- serial_req.irq = pdata->irq;
- serial_req.uartclk = pdata->uartclk;
- serial_req.regshift = pdata->regshift;
- serial_req.iotype = pdata->iotype;
- serial_req.flags = pdata->flags;
- gen550_init(num, &serial_req);
-#endif
-}
-
-void __init
-ml403_early_serial_map(void)
-{
-#ifdef CONFIG_SERIAL_8250
- struct plat_serial8250_port *pdata;
- int i = 0;
-
- pdata = (struct plat_serial8250_port *) ppc_sys_get_pdata(VIRTEX_UART);
- while(pdata && pdata->flags)
- {
- pdata->membase = ioremap(pdata->mapbase, 0x100);
- ml403_early_serial_init(i, pdata);
- pdata++;
- i++;
- }
-#endif /* CONFIG_SERIAL_8250 */
-}
-
void __init
ml403_setup_arch(void)
{
- ml403_early_serial_map();
+ virtex_early_serial_map();
ppc4xx_setup_arch(); /* calls ppc4xx_find_bridges() */
/* Identify the system */
@@ -160,8 +105,6 @@ platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
{
ppc4xx_init(r3, r4, r5, r6, r7);
- identify_ppc_sys_by_id(mfspr(SPRN_PVR));
-
ppc_md.setup_arch = ml403_setup_arch;
ppc_md.setup_io_mappings = ml403_map_io;
ppc_md.init_IRQ = ml403_init_irq;
@@ -171,7 +114,7 @@ platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
#endif
#ifdef CONFIG_KGDB
- ppc_md.early_serial_map = ml403_early_serial_map;
+ ppc_md.early_serial_map = virtex_early_serial_map;
#endif
}
diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
index 0991111..9569415 100644
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -18,7 +18,8 @@ obj-$(CONFIG_440SP) += ibm440gx_common.o ibm440sp_common.o
obj-$(CONFIG_440SPE) += ibm440gx_common.o ibm440sp_common.o ppc440spe_pcie.o
ifeq ($(CONFIG_4xx),y)
ifeq ($(CONFIG_XILINX_VIRTEX),y)
-obj-$(CONFIG_40x) += xilinx_pic.o ppc_sys.o
+obj-$(CONFIG_40x) += xilinx_pic.o
+obj-y += virtex_devices.o
else
ifeq ($(CONFIG_403),y)
obj-$(CONFIG_40x) += ppc403_pic.o
diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
index 40f197a..de99e92 100644
--- a/include/asm-ppc/ppc_sys.h
+++ b/include/asm-ppc/ppc_sys.h
@@ -33,8 +33,6 @@
#include <asm/mpc52xx.h>
#elif defined(CONFIG_MPC10X_BRIDGE)
#include <asm/mpc10x.h>
-#elif defined(CONFIG_XILINX_VIRTEX)
-#include <platforms/4xx/virtex.h>
#else
#error "need definition of ppc_sys_devices"
#endif
--
1.5.1
^ permalink raw reply related
* [PATCH 3/7] [PPC] New registration for common Xilinx Virtex ppc405 platform devices
From: Grant Likely @ 2007-04-27 19:50 UTC (permalink / raw)
To: linuxppc-embedded, paulus; +Cc: Peter Korsgaard, Andrei Konovalov, Rick Moleres
In-Reply-To: <11777034143069-git-send-email-grant.likely@secretlab.ca>
Currently virtex support in mainline make use of the infrastructure in
arch/ppc/syslib/ppc_sys.c for registering common devices on virtex ppc405
platforms. The ppc_sys.c code is not well suited to the dynamic nature of
FPGA designs and makes adding new board ports more complex. This patch
adds a new listing of common devices which does not depend on the ppc_sys.c
infrastructure.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/ppc/syslib/virtex_devices.c | 233 ++++++++++++++++++++++++++++++++++++++
arch/ppc/syslib/virtex_devices.h | 27 +++++
2 files changed, 260 insertions(+), 0 deletions(-)
create mode 100644 arch/ppc/syslib/virtex_devices.c
create mode 100644 arch/ppc/syslib/virtex_devices.h
diff --git a/arch/ppc/syslib/virtex_devices.c b/arch/ppc/syslib/virtex_devices.c
new file mode 100644
index 0000000..1654678
--- /dev/null
+++ b/arch/ppc/syslib/virtex_devices.c
@@ -0,0 +1,233 @@
+/*
+ * Virtex hard ppc405 core common device listing
+ *
+ * Copyright 2005-2007 Secret Lab Technologies Ltd.
+ * Copyright 2005 Freescale Semiconductor Inc.
+ * Copyright 2002-2004 MontaVista Software, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/serial_8250.h>
+#include <syslib/virtex_devices.h>
+#include <platforms/4xx/xparameters/xparameters.h>
+#include <asm/io.h>
+
+/*
+ * UARTLITE: shortcut macro for single instance
+ */
+#define XPAR_UARTLITE(num) { \
+ .name = "uartlite", \
+ .id = num, \
+ .num_resources = 2, \
+ .resource = (struct resource[]) { \
+ { \
+ .start = XPAR_UARTLITE_##num##_BASEADDR + 3, \
+ .end = XPAR_UARTLITE_##num##_HIGHADDR, \
+ .flags = IORESOURCE_MEM, \
+ }, \
+ { \
+ .start = XPAR_INTC_0_UARTLITE_##num##_VEC_ID, \
+ .flags = IORESOURCE_IRQ, \
+ }, \
+ }, \
+}
+
+/*
+ * Full UART: shortcut macro for single instance + platform data structure
+ */
+#define XPAR_UART(num) { \
+ .mapbase = XPAR_UARTNS550_##num##_BASEADDR + 3, \
+ .irq = XPAR_INTC_0_UARTNS550_##num##_VEC_ID, \
+ .iotype = UPIO_MEM, \
+ .uartclk = XPAR_UARTNS550_##num##_CLOCK_FREQ_HZ, \
+ .flags = UPF_BOOT_AUTOCONF, \
+ .regshift = 2, \
+}
+
+/*
+ * SystemACE: shortcut macro for single instance
+ */
+#define XPAR_SYSACE(num) { \
+ .name = "xsysace", \
+ .id = XPAR_SYSACE_##num##_DEVICE_ID, \
+ .num_resources = 2, \
+ .resource = (struct resource[]) { \
+ { \
+ .start = XPAR_SYSACE_##num##_BASEADDR, \
+ .end = XPAR_SYSACE_##num##_HIGHADDR, \
+ .flags = IORESOURCE_MEM, \
+ }, \
+ { \
+ .start = XPAR_INTC_0_SYSACE_##num##_VEC_ID, \
+ .flags = IORESOURCE_IRQ, \
+ }, \
+ }, \
+}
+
+
+/* UART 8250 driver platform data table */
+struct plat_serial8250_port virtex_serial_platform_data[] = {
+#if defined(XPAR_UARTNS550_0_BASEADDR)
+ XPAR_UART(0),
+#endif
+#if defined(XPAR_UARTNS550_1_BASEADDR)
+ XPAR_UART(1),
+#endif
+#if defined(XPAR_UARTNS550_2_BASEADDR)
+ XPAR_UART(2),
+#endif
+#if defined(XPAR_UARTNS550_3_BASEADDR)
+ XPAR_UART(3),
+#endif
+#if defined(XPAR_UARTNS550_4_BASEADDR)
+ XPAR_UART(4),
+#endif
+#if defined(XPAR_UARTNS550_5_BASEADDR)
+ XPAR_UART(5),
+#endif
+#if defined(XPAR_UARTNS550_6_BASEADDR)
+ XPAR_UART(6),
+#endif
+#if defined(XPAR_UARTNS550_7_BASEADDR)
+ XPAR_UART(7),
+#endif
+ { }, /* terminated by empty record */
+};
+
+
+struct platform_device virtex_platform_devices[] = {
+ /* UARTLITE instances */
+#if defined(XPAR_UARTLITE_0_BASEADDR)
+ XPAR_UARTLITE(0),
+#endif
+#if defined(XPAR_UARTLITE_1_BASEADDR)
+ XPAR_UARTLITE(1),
+#endif
+#if defined(XPAR_UARTLITE_2_BASEADDR)
+ XPAR_UARTLITE(2),
+#endif
+#if defined(XPAR_UARTLITE_3_BASEADDR)
+ XPAR_UARTLITE(3),
+#endif
+#if defined(XPAR_UARTLITE_4_BASEADDR)
+ XPAR_UARTLITE(4),
+#endif
+#if defined(XPAR_UARTLITE_5_BASEADDR)
+ XPAR_UARTLITE(5),
+#endif
+#if defined(XPAR_UARTLITE_6_BASEADDR)
+ XPAR_UARTLITE(6),
+#endif
+#if defined(XPAR_UARTLITE_7_BASEADDR)
+ XPAR_UARTLITE(7),
+#endif
+
+ /* Full UART instances */
+#if defined(XPAR_UARTNS550_0_BASEADDR)
+ {
+ .name = "serial8250",
+ .id = 0,
+ .dev.platform_data = virtex_serial_platform_data,
+ },
+#endif
+
+ /* SystemACE instances */
+#if defined(XPAR_SYSACE_0_BASEADDR)
+ XPAR_SYSACE(0),
+#endif
+#if defined(XPAR_SYSACE_1_BASEADDR)
+ XPAR_SYSACE(1),
+#endif
+
+ /* ML300/403 reference design framebuffer */
+#if defined(XPAR_TFT_0_BASEADDR)
+ {
+ .name = "xilinxfb",
+ .id = 0,
+ .num_resources = 1,
+ .resource = (struct resource[]) {
+ {
+ .start = XPAR_TFT_0_BASEADDR,
+ .end = XPAR_TFT_0_BASEADDR+7,
+ .flags = IORESOURCE_IO,
+ },
+ },
+ },
+#endif
+};
+
+/* Early serial support functions */
+static void __init
+virtex_early_serial_init(int num, struct plat_serial8250_port *pdata)
+{
+#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
+ struct uart_port serial_req;
+
+ memset(&serial_req, 0, sizeof(serial_req));
+ serial_req.mapbase = pdata->mapbase;
+ serial_req.membase = pdata->membase;
+ serial_req.irq = pdata->irq;
+ serial_req.uartclk = pdata->uartclk;
+ serial_req.regshift = pdata->regshift;
+ serial_req.iotype = pdata->iotype;
+ serial_req.flags = pdata->flags;
+ gen550_init(num, &serial_req);
+#endif
+}
+
+void __init
+virtex_early_serial_map(void)
+{
+#ifdef CONFIG_SERIAL_8250
+ struct plat_serial8250_port *pdata;
+ int i = 0;
+
+ pdata = virtex_serial_platform_data;
+ while(pdata && pdata->flags) {
+ pdata->membase = ioremap(pdata->mapbase, 0x100);
+ virtex_early_serial_init(i, pdata);
+ pdata++;
+ i++;
+ }
+#endif /* CONFIG_SERIAL_8250 */
+}
+
+/*
+ * default fixup routine; do nothing and return success.
+ *
+ * Reimplement this routine in your custom board support file to
+ * override the default behaviour
+ */
+int __attribute__ ((weak))
+virtex_device_fixup(struct platform_device *dev)
+{
+ return 0;
+}
+
+static int __init virtex_init(void)
+{
+ struct platform_device *index = virtex_platform_devices;
+ unsigned int ret = 0;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(virtex_platform_devices); i++, index++) {
+ if (virtex_device_fixup(index) != 0)
+ continue;
+
+ if (platform_device_register(index)) {
+ ret = 1;
+ printk(KERN_ERR "cannot register dev %s:%d\n",
+ index->name, index->id);
+ }
+ }
+ return ret;
+}
+
+subsys_initcall(virtex_init);
diff --git a/arch/ppc/syslib/virtex_devices.h b/arch/ppc/syslib/virtex_devices.h
new file mode 100644
index 0000000..4a17dd3
--- /dev/null
+++ b/arch/ppc/syslib/virtex_devices.h
@@ -0,0 +1,27 @@
+/*
+ * Common support header for virtex ppc405 platforms
+ *
+ * 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.
+ */
+
+#ifndef __ASM_VIRTEX_DEVICES_H__
+#define __ASM_VIRTEX_DEVICES_H__
+
+#include <linux/platform_device.h>
+
+void __init virtex_early_serial_map(void);
+
+/* Prototype for device fixup routine. Implement this routine in the
+ * board specific fixup code and the generic setup code will call it for
+ * each device is the platform device list.
+ *
+ * If the hook returns a non-zero value, then the device will not get
+ * registered with the platform bus
+ */
+int virtex_device_fixup(struct platform_device *dev);
+
+#endif /* __ASM_VIRTEX_DEVICES_H__ */
--
1.5.1
^ permalink raw reply related
* [PATCH 0/7] Revised Xilinx virtex establish sanity patchset
From: Grant Likely @ 2007-04-27 19:49 UTC (permalink / raw)
To: linuxppc-embedded, paulus; +Cc: Peter Korsgaard, Andrei Konovalov, Rick Moleres
In-Reply-To: <11777034052773-git-send-email-grant.likely@secretlab.ca>
Paul, I believe this patch set is ready for merging. You can also pull
it from the 'virtex-forupstream' branch of my git tree if you prefer:
git://git.secretlab.ca/git/linux-2.6.git virtex-forupstream
Cheers,
g.
--- original description:
The Virtex support in Linus' tree is a mess. When I ported the common
devices over to using the platform bus I tried the use the ppc_sys
infrastructure. ppc_sys is intended for SoCs that have a fixed set of
devices. It is the *wrong* approach for FPGA support, and I made a
royal mess of things. This patch set fixes that problem and makes
a number of other changes that make supporting Virtex boards easier.
I do know that changes to arch/ppc are frowned upon at the moment. However,
4xx support in arch/powerpc is not merged yet, and Virtex support needs
additional work beyond that. I suspect that arch/ppc support for the
4xx parts is going to need to stay alive for the next 2-3 kernel releases
anyway while arch/powerpc support stablizes. Getting these patches in
will make it easier to support the Virtex ports while I hack on getting
arch/powerpc stuff figured out.
^ permalink raw reply
* [PATCH 2/7] [PPC] Merge common virtex header files
From: Grant Likely @ 2007-04-27 19:50 UTC (permalink / raw)
To: linuxppc-embedded, paulus; +Cc: Peter Korsgaard, Andrei Konovalov, Rick Moleres
In-Reply-To: <1177703413868-git-send-email-grant.likely@secretlab.ca>
The header files for the ml403 and ml300 are virtually identical, merge
them into a single file.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/ppc/platforms/4xx/virtex.h | 40 +++++++++++++++++++-------
arch/ppc/platforms/4xx/xilinx_ml300.c | 1 +
arch/ppc/platforms/4xx/xilinx_ml300.h | 45 ------------------------------
arch/ppc/platforms/4xx/xilinx_ml403.c | 1 +
arch/ppc/platforms/4xx/xilinx_ml403.h | 49 ---------------------------------
include/asm-ppc/ibm4xx.h | 8 +----
6 files changed, 33 insertions(+), 111 deletions(-)
delete mode 100644 arch/ppc/platforms/4xx/xilinx_ml300.h
delete mode 100644 arch/ppc/platforms/4xx/xilinx_ml403.h
diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virtex.h
index c14325d..e9f58a7 100644
--- a/arch/ppc/platforms/4xx/virtex.h
+++ b/arch/ppc/platforms/4xx/virtex.h
@@ -1,22 +1,18 @@
/*
- * arch/ppc/platforms/4xx/virtex.h
+ * Basic Virtex platform defines, included by <asm/ibm4xx.h>
*
- * Include file that defines the Xilinx Virtex-II Pro processor
+ * 2005-2007 (c) Secret Lab Technologies Ltd.
+ * 2002-2004 (c) MontaVista Software, Inc.
*
- * Author: MontaVista Software, Inc.
- * source@mvista.com
- *
- * 2002-2004 (c) MontaVista Software, Inc. 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 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.
*/
#ifdef __KERNEL__
#ifndef __ASM_VIRTEX_H__
#define __ASM_VIRTEX_H__
-/* serial defines */
-
#include <asm/ibm405.h>
/* Ugly, ugly, ugly! BASE_BAUD defined here to keep 8250.c happy. */
@@ -29,7 +25,29 @@
enum ppc_sys_devices {
VIRTEX_UART, NUM_PPC_SYS_DEVS,
};
-#endif
+typedef struct board_info {
+ unsigned int bi_memsize; /* DRAM installed, in bytes */
+ unsigned char bi_enetaddr[6]; /* Local Ethernet MAC address */
+ unsigned int bi_intfreq; /* Processor speed, in Hz */
+ unsigned int bi_busfreq; /* PLB Bus speed, in Hz */
+ unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
+} bd_t;
+
+/* Some 4xx parts use a different timebase frequency from the internal clock.
+ * the Virtex 405 does not, so just use a macro to make tbfreq match intfreq
+*/
+#define bi_tbfreq bi_intfreq
+
+extern const char* virtex_machine_name;
+#define PPC4xx_MACHINE_NAME (virtex_machine_name)
+
+#endif /* !__ASSEMBLY__ */
+
+/* We don't need anything mapped. Size of zero will accomplish that. */
+#define PPC4xx_ONB_IO_PADDR 0u
+#define PPC4xx_ONB_IO_VADDR 0u
+#define PPC4xx_ONB_IO_SIZE 0u
+
#endif /* __ASM_VIRTEX_H__ */
#endif /* __KERNEL__ */
diff --git a/arch/ppc/platforms/4xx/xilinx_ml300.c b/arch/ppc/platforms/4xx/xilinx_ml300.c
index fb5f0b5..4e4aca4 100644
--- a/arch/ppc/platforms/4xx/xilinx_ml300.c
+++ b/arch/ppc/platforms/4xx/xilinx_ml300.c
@@ -68,6 +68,7 @@ struct ppc_sys_spec ppc_sys_specs[] = {
},
},
};
+const char* virtex_machine_name = "ML300 Reference Design";
#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
diff --git a/arch/ppc/platforms/4xx/xilinx_ml300.h b/arch/ppc/platforms/4xx/xilinx_ml300.h
deleted file mode 100644
index 3d57332..0000000
--- a/arch/ppc/platforms/4xx/xilinx_ml300.h
+++ /dev/null
@@ -1,45 +0,0 @@
-/*
- * Include file that defines the Xilinx ML300 evaluation board
- *
- * Author: MontaVista Software, Inc.
- * source@mvista.com
- *
- * 2002-2004 (c) MontaVista Software, Inc. 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.
- */
-
-#ifdef __KERNEL__
-#ifndef __ASM_XILINX_ML300_H__
-#define __ASM_XILINX_ML300_H__
-
-/* ML300 has a Xilinx Virtex-II Pro processor */
-#include <platforms/4xx/virtex.h>
-
-#ifndef __ASSEMBLY__
-
-#include <linux/types.h>
-
-typedef struct board_info {
- unsigned int bi_memsize; /* DRAM installed, in bytes */
- unsigned char bi_enetaddr[6]; /* Local Ethernet MAC address */
- unsigned int bi_intfreq; /* Processor speed, in Hz */
- unsigned int bi_busfreq; /* PLB Bus speed, in Hz */
- unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
-} bd_t;
-
-/* Some 4xx parts use a different timebase frequency from the internal clock.
-*/
-#define bi_tbfreq bi_intfreq
-
-#endif /* !__ASSEMBLY__ */
-
-/* We don't need anything mapped. Size of zero will accomplish that. */
-#define PPC4xx_ONB_IO_PADDR 0u
-#define PPC4xx_ONB_IO_VADDR 0u
-#define PPC4xx_ONB_IO_SIZE 0u
-
-#define PPC4xx_MACHINE_NAME "Xilinx ML300 Reference System"
-
-#endif /* __ASM_XILINX_ML300_H__ */
-#endif /* __KERNEL__ */
diff --git a/arch/ppc/platforms/4xx/xilinx_ml403.c b/arch/ppc/platforms/4xx/xilinx_ml403.c
index cb3bf7a..c98e40a 100644
--- a/arch/ppc/platforms/4xx/xilinx_ml403.c
+++ b/arch/ppc/platforms/4xx/xilinx_ml403.c
@@ -72,6 +72,7 @@ struct ppc_sys_spec ppc_sys_specs[] = {
},
},
};
+const char* virtex_machine_name = "ML403 Reference Design";
#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
diff --git a/arch/ppc/platforms/4xx/xilinx_ml403.h b/arch/ppc/platforms/4xx/xilinx_ml403.h
deleted file mode 100644
index 4735969..0000000
--- a/arch/ppc/platforms/4xx/xilinx_ml403.h
+++ /dev/null
@@ -1,49 +0,0 @@
-/*
- * arch/ppc/platforms/4xx/xilinx_ml403.h
- *
- * Include file that defines the Xilinx ML403 reference design
- *
- * Author: Grant Likely <grant.likely@secretlab.ca>
- *
- * 2005 (c) Secret Lab Technologies Ltd.
- * 2002-2004 (c) MontaVista Software, Inc.
- *
- * 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.
- */
-
-#ifdef __KERNEL__
-#ifndef __ASM_XILINX_ML403_H__
-#define __ASM_XILINX_ML403_H__
-
-/* ML403 has a Xilinx Virtex-4 FPGA with a PPC405 hard core */
-#include <platforms/4xx/virtex.h>
-
-#ifndef __ASSEMBLY__
-
-#include <linux/types.h>
-
-typedef struct board_info {
- unsigned int bi_memsize; /* DRAM installed, in bytes */
- unsigned char bi_enetaddr[6]; /* Local Ethernet MAC address */
- unsigned int bi_intfreq; /* Processor speed, in Hz */
- unsigned int bi_busfreq; /* PLB Bus speed, in Hz */
- unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
-} bd_t;
-
-/* Some 4xx parts use a different timebase frequency from the internal clock.
-*/
-#define bi_tbfreq bi_intfreq
-
-#endif /* !__ASSEMBLY__ */
-
-/* We don't need anything mapped. Size of zero will accomplish that. */
-#define PPC4xx_ONB_IO_PADDR 0u
-#define PPC4xx_ONB_IO_VADDR 0u
-#define PPC4xx_ONB_IO_SIZE 0u
-
-#define PPC4xx_MACHINE_NAME "Xilinx ML403 Reference Design"
-
-#endif /* __ASM_XILINX_ML403_H__ */
-#endif /* __KERNEL__ */
diff --git a/include/asm-ppc/ibm4xx.h b/include/asm-ppc/ibm4xx.h
index 92fd02d..ed6891a 100644
--- a/include/asm-ppc/ibm4xx.h
+++ b/include/asm-ppc/ibm4xx.h
@@ -47,12 +47,8 @@
#include <platforms/4xx/walnut.h>
#endif
-#if defined(CONFIG_XILINX_ML300)
-#include <platforms/4xx/xilinx_ml300.h>
-#endif
-
-#if defined(CONFIG_XILINX_ML403)
-#include <platforms/4xx/xilinx_ml403.h>
+#if defined(CONFIG_XILINX_VIRTEX)
+#include <platforms/4xx/virtex.h>
#endif
#ifndef __ASSEMBLY__
--
1.5.1
^ permalink raw reply related
* [PATCH 1/7] [PPC] Rework Kconfig dependancies for Xilinx Virtex ppc405 platform
From: Grant Likely @ 2007-04-27 19:49 UTC (permalink / raw)
To: linuxppc-embedded, paulus; +Cc: Peter Korsgaard, Andrei Konovalov, Rick Moleres
In-Reply-To: <1177703413970-git-send-email-grant.likely@secretlab.ca>
Reverse dependency order for Xilinx Virtex parts. For these parts, It
makes more sense for boards/chips to specify which features they
provide instead of the features listing the parts they are implemented
in. I think it also makes adding new board ports simpler.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/ppc/platforms/4xx/Kconfig | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
index 705ae56..76551b6 100644
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -29,6 +29,7 @@ config CPCI405
config EP405
bool "EP405/EP405PC"
+ select EMBEDDEDBOOT
help
This option enables support for the EP405/EP405PC boards.
@@ -54,11 +55,15 @@ config WALNUT
config XILINX_ML300
bool "Xilinx-ML300"
+ select XILINX_VIRTEX_II_PRO
+ select EMBEDDEDBOOT
help
This option enables support for the Xilinx ML300 evaluation board.
config XILINX_ML403
bool "Xilinx-ML403"
+ select XILINX_VIRTEX_4_FX
+ select EMBEDDEDBOOT
help
This option enables support for the Xilinx ML403 evaluation board.
endchoice
@@ -215,18 +220,14 @@ config 405GPR
config XILINX_VIRTEX_II_PRO
bool
- depends on XILINX_ML300
- default y
+ select XILINX_VIRTEX
config XILINX_VIRTEX_4_FX
bool
- depends on XILINX_ML403
- default y
+ select XILINX_VIRTEX
config XILINX_VIRTEX
bool
- depends on XILINX_VIRTEX_II_PRO || XILINX_VIRTEX_4_FX
- default y
config STB03xxx
bool
@@ -235,8 +236,6 @@ config STB03xxx
config EMBEDDEDBOOT
bool
- depends on EP405 || XILINX_ML300 || XILINX_ML403
- default y
config IBM_OPENBIOS
bool
--
1.5.1
^ permalink raw reply related
* [PATCH 0/7] Revised Xilinx virtex establish sanity patchset
From: Grant Likely @ 2007-04-27 19:49 UTC (permalink / raw)
To: linuxppc-embedded, paulus; +Cc: Peter Korsgaard, Andrei Konovalov, Rick Moleres
Based on received comments, I posting this revised patchset for Virtex
cleanup in arch/ppc. Changes from the last set include Kconfig tweaks,
support for more than 4 serial ports, xparams fixups pulled from Xilinx
code. Biggest change is the move to use ppcboot.h for bd_t definition
which makes u-boot work correctly with the in-tree virtex ports.
Paul, I believe this patch set is ready for merging. You can also pull
it from the 'virtex-forupstream' branch of my git tree if you prefer:
git://git.secretlab.ca/git/linux-2.6.git virtex-forupstream
Cheers,
g.
--- original description:
The Virtex support in Linus' tree is a mess. When I ported the common
devices over to using the platform bus I tried the use the ppc_sys
infrastructure. ppc_sys is intended for SoCs that have a fixed set of
devices. It is the *wrong* approach for FPGA support, and I made a
royal mess of things. This patch set fixes that problem and makes
a number of other changes that make supporting Virtex boards easier.
I do know that changes to arch/ppc are frowned upon at the moment. However,
4xx support in arch/powerpc is not merged yet, and Virtex support needs
additional work beyond that. I suspect that arch/ppc support for the
4xx parts is going to need to stay alive for the next 2-3 kernel releases
anyway while arch/powerpc support stablizes. Getting these patches in
will make it easier to support the Virtex ports while I hack on getting
arch/powerpc stuff figured out.
^ permalink raw reply
* (no subject)
From: Mead, Joseph @ 2007-04-27 19:15 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3521 bytes --]
Hi,
I'm trying to use initramfs on an ML403 system but don't understand why
I can't see any console output after the line:
[ 1.034361] Freeing unused kernel memory: 1172k init
my filesystem is built from the following:
dir /dev 755 0 0
nod /dev/console 644 0 0 c 5 1
dir /proc 755 0 0
dir /sys 755 0 0
file /init usr/busybox 755 0 0
Busybox was built statically, with init functionality so I think I can
just rename it to init and it should run the init process. It seems to
find /dev/console because if I delete that node I get an error message
that it can't find /dev/console. Also I think it is finding the
busybox init because I don't get a kernel panic like I do when I don't
include it.
Any help would be great.
Thanks,
Joe
Kernel boot-up messages.
loaded at: 00400000 005E613C
board data at: 005E4124 005E413C
relocated to: 004050D0 004050E8
zimage at: 004057E9 005E3869
avail ram: 005E7000 04000000
Linux/PPC load: console=ttyS0,9600
Uncompressing Linux...done.
Now booting the kernel
[ 0.000000] Linux version 2.6.17.1 (root@ansto1) (gcc version 3.4.5)
#29 Thu Apr 27 11:13:26 EDT 2007
[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
[ 0.000000] Built 1 zonelists
[ 0.000000] Kernel command line: console=ttyS0,9600
[ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000
[ 0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[ 0.000105] Console: colour dummy device 80x25
[ 0.000394] Dentry cache hash table entries: 8192 (order: 3, 32768
bytes)
[ 0.000887] Inode-cache hash table entries: 4096 (order: 2, 16384
bytes)
[ 0.009214] Memory: 61964k available (1292k kernel code, 468k data,
1172k init, 0k highmem)
[ 0.096238] Mount-cache hash table entries: 512
[ 0.435539] NET: Registered protocol family 16
[ 0.440315] NET: Registered protocol family 2
[ 0.480121] IP route cache hash table entries: 512 (order: -1, 2048
bytes)
[ 0.480636] TCP established hash table entries: 2048 (order: 1, 8192
bytes)
[ 0.480755] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.480821] TCP: Hash tables configure
[ 0.480843] TCP reno registered
[ 0.484696] io scheduler noop registered
[ 0.484754] io scheduler anticipatory registered (default)
[ 0.484799] io scheduler deadline registered
[ 0.484890] io scheduler cfq registered
[ 0.510230] Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ
sharing disabled
[ 0.511764] serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 9) is a
16550A
[ 0.924578] RAMDISK driver initialized: 16 RAM disks of 65536K size
1024 blocksize
[ 0.948301] tun: Universal TUN
[ 0.963483] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 0.982713] mice: PS/2 mouse device common for all mice
[ 0.998445] TCP bic registered
[ 1.007702] NET: Registered protocol family 1
[ 1.020827] NET: Registered protocol family 17
[ 1.034361] Freeing unused kernel memory: 1172k init
[-- Attachment #2: Type: text/html, Size: 16517 bytes --]
^ permalink raw reply
* RE: How do external irq's get mapped?
From: Charles Krinke @ 2007-04-27 19:34 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <46324428.7070401@ru.mvista.com>
> transmit and 20 for receive.
> A 'cat /proc/interrupts' shows the 1st TSEC transmit as 93 and the
> receive as 94, so I am puzzled how we get from 19 to 93 for the
transmit
> and from 20 to 94 for the receive. Perhaps understanding this will
help
I'd suspect you also have CPM on this SoC (or have CONFIG_CPM*
wrongly enabled?).
> me figure out what number to put into the pci_dev structure for
external
> IRQ0.
Could you post your /proc/interrupts?
> Charles Krinke
WBR, Sergei
Dear Sergei:
Here is the result of /proc/interrupts
root@sff1:~# cat /proc/interrupts
CPU0
2: 0 i8259 Edge 82c59 secondary cascade
32: 0 CPM2 SIU Level ichar
93: 10701 OpenPIC Level enet_tx
94: 13945 OpenPIC Level enet_rx
98: 0 OpenPIC Level enet_error
106: 542 OpenPIC Level serial
107: 0 OpenPIC Level i2c-mpc
110: 0 OpenPIC Level cpm2_cascade
128: 0 OpenPIC Level <NULL>
BAD: 0
root@sff1:~#
The current issue is understanding how enet_tx, enet_rx & serial get to
be 93, 94 & 106 respectively. Once I understand that, I may have a clue
how to deal the one labelled ichar, which is the one that doesn't quite
work. This is a PCI chip our company designed.
Charles Krinke
^ permalink raw reply
* Re: [PATCH 3/5] [PPC] New registration for common Xilinx Virtex ppc405 platform devices
From: Grant Likely @ 2007-04-27 18:50 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded
In-Reply-To: <878xcgac2q.fsf@sleipner.barco.com>
On 4/25/07, Peter Korsgaard <peter.korsgaard@barco.com> wrote:
> Could we at the same time increase the amount of UARTs supported? We
> have designs with 5 16550s.
Absolutely, I'll make that change right now.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2/5] [PPC] Merge common virtex header files
From: Grant Likely @ 2007-04-27 18:49 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded
In-Reply-To: <87d51sac8l.fsf@sleipner.barco.com>
On 4/25/07, Peter Korsgaard <peter.korsgaard@barco.com> wrote:
> >>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
> GL> -#if defined(CONFIG_XILINX_ML300)
> GL> -#include <platforms/4xx/xilinx_ml300.h>
> GL> -#endif
> GL> -
> GL> -#if defined(CONFIG_XILINX_ML403)
> GL> -#include <platforms/4xx/xilinx_ml403.h>
> GL> +#if defined(CONFIG_XILINX_VIRTEX)
> GL> +#include <platforms/4xx/virtex.h>
> GL> #endif
>
> Could we make that
>
> #if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
>
> instead? I'm using RedBoot on a virtex platform, and hence another
> struct bd_info than the ML300/ML403.
Alternate suggestion: Can we change virtex support to use the
structure defined in ppcboot.h instead? (I've actually got that
change in my tree and was planning on posting it for review today or
tomorrow). bd_t is a stinking ugly mess, but things would be better
if we standardize all virtex platforms on the stinking ugly mess
shared by almost all the other ppc embedded board ports.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [RFC] SystemACE driver - abstract register ops
From: Grant Likely @ 2007-04-27 18:42 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: Stefan Roese, linuxppc-embedded, Rick Moleres
In-Reply-To: <46324340.5000506@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
On 4/27/07, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
> [ 10.511016] xsysace xsa: kicking stalled fsm; state=3 task=1 iter=2 dc=0
>
> Will have a deeper look tomorrow.
> And try CF card too.
> At the moment not sure if this the driver issue.
Oops, I messed it up; try the attached change (I had left in a bogus
data_count decrement). Thanks for catching the ptr increment bug.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
[-- Attachment #2: 0001-SYSACE-Bug-fixes-to-8-bit-binding.patch --]
[-- Type: application/x-patch, Size: 1307 bytes --]
^ permalink raw reply
* Re: How do external irq's get mapped?
From: Sergei Shtylyov @ 2007-04-27 18:42 UTC (permalink / raw)
To: Charles Krinke; +Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06A1F0@MERCURY.inside.istor.com>
Hello.
Charles Krinke wrote:
> As I understand it, the 8541 and 8555 have 12 external IRQ[0..11], 21
> internal interrupts, and 4 messaging interrupts.
> In looking at the MPC8555ERM.pdf file, which is my main resource, it
> looks like the internal interrupt numbers for the 1st TSEC are 19 for
> transmit and 20 for receive.
> A 'cat /proc/interrupts' shows the 1st TSEC transmit as 93 and the
> receive as 94, so I am puzzled how we get from 19 to 93 for the transmit
> and from 20 to 94 for the receive. Perhaps understanding this will help
I'd suspect you also have CPM on this SoC (or have CONFIG_CPM* wrongly enabled?).
> me figure out what number to put into the pci_dev structure for external
> IRQ0.
Could you post your /proc/interrupts?
> Charles Krinke
WBR, Sergei
^ permalink raw reply
* [PATCH] fs_enet & multicasting
From: Matvejchikov Ilya @ 2007-04-27 18:34 UTC (permalink / raw)
To: linuxppc-embedded
Good Day!
There is a problem in fs_enet driver. When TX times out or when PHY
transceiver adjusts the link the restart() function is called. But it
doesn't take into account the existing device multicast settings (and
IFF_PROMISC too). This little patch fixes the problem.
Signed-off-by: Matvejchikov Ilya <matvejchikov <at> gmail.com>
===================================================================
--- linux-2.6.21.orig/drivers/net/fs_enet/mac-fcc.c
+++ linux-2.6.21/drivers/net/fs_enet/mac-fcc.c
@@ -433,6 +433,8 @@
else
C32(fccp, fcc_fpsmr, FCC_PSMR_FDE | FCC_PSMR_LPB);
+ set_multicast_list(dev);
+
S32(fccp, fcc_gfmr, FCC_GFMR_ENR | FCC_GFMR_ENT);
}
^ permalink raw reply
* Re: [RFC] SystemACE driver - abstract register ops
From: Andrei Konovalov @ 2007-04-27 18:38 UTC (permalink / raw)
To: Grant Likely; +Cc: Stefan Roese, linuxppc-embedded, Rick Moleres
In-Reply-To: <528646bc0704270031w5c9966f8tc3a5e5292df10a35@mail.gmail.com>
Hi Grant,
Grant Likely wrote:
> For your reading pleasure, I've attached the bus attachment changes
> that I've made in my tree. I hope to get this driver accepted into
> mainline during the 2.6.22 merge window; so please get any comments
> you have back to me ASAP.
>
> Cheers,
> g.
ML300 + IBM microdrive.
8-bit, __BIG_ENDIAN
(ace->bus_width = 0;)
Have noticed a misprint (see below).
Correcting it seems to make the device geometry to be recognized OK, but then:
[ 3.798449] xsysace xsa: Xilinx SystemACE revision 1.0.12
[ 3.891228] xsysace xsa: capacity: 2104704 sectors
[ 3.973193] xsa:<4>xsysace xsa: kicking stalled fsm; state=3 task=1 iter=2 dc=0
[ 6.103446] xsysace xsa: kicking stalled fsm; state=3 task=1 iter=2 dc=0
[ 7.207342] xsysace xsa: kicking stalled fsm; state=3 task=1 iter=2 dc=0
[ 8.311230] xsysace xsa: kicking stalled fsm; state=3 task=1 iter=2 dc=0
[ 9.411113] xsysace xsa: kicking stalled fsm; state=3 task=1 iter=2 dc=0
[ 10.511016] xsysace xsa: kicking stalled fsm; state=3 task=1 iter=2 dc=0
Will have a deeper look tomorrow.
And try CF card too.
At the moment not sure if this the driver issue.
Thanks,
Andrei
Index: linux-2.6.20/drivers/block/xsysace.c
===================================================================
--- linux-2.6.20.orig/drivers/block/xsysace.c
+++ linux-2.6.20/drivers/block/xsysace.c
@@ -240,9 +240,9 @@ static void ace_identin_8(struct ace_dev
int i = ACE_FIFO_SIZE/2;
while (i--)
#if defined(__BIG_ENDIAN)
- *ace->data_ptr = (in_8(r)) | (in_8(r+1)<<8);
+ *ace->data_ptr++ = (in_8(r)) | (in_8(r+1)<<8);
#else
- *ace->data_ptr = (in_8(r)<<8) | (in_8(r+1));
+ *ace->data_ptr++ = (in_8(r)<<8) | (in_8(r+1));
#endif
ace->data_count--;
}
@@ -253,9 +253,9 @@ static void ace_datain_8(struct ace_devi
int i = ACE_FIFO_SIZE/2;
while (i--)
#if defined(__BIG_ENDIAN)
- *ace->data_ptr = (in_8(r)<<8) | (in_8(r+1));
+ *ace->data_ptr++ = (in_8(r)<<8) | (in_8(r+1));
#else
- *ace->data_ptr = (in_8(r)) | (in_8(r+1)<<8);
+ *ace->data_ptr++ = (in_8(r)) | (in_8(r+1)<<8);
#endif
}
^ permalink raw reply
* Re: [PATCH v4] powerpc: 64K page support for kexec
From: Haren Myneni @ 2007-04-27 18:23 UTC (permalink / raw)
To: Luke Browning
Cc: Arnd Bergmann, Milton Miller, linuxppc-dev, Paul Mackerras,
Olof Johansson, cbe-oss-dev
In-Reply-To: <1177695045.24866.135.camel@luke-laptop>
Luke Browning wrote:
> On Fri, 2007-04-27 at 11:59 -0500, Milton Miller wrote:
>
>
>> I see I've achived my nefarious goal of making these bugs never happen.
>>
>> (panic is a function, so you are checking that the staticly linked
>> non-weak function is available. If you want to check on when
>> if its a panic kdump or not, you need to decode the flag and pass
>> it to kexec_sequence, pass it back here, and update all platforms
>> for the new parameter).
>>
>> But I still say the check while clearing the table is too late,
>> it should be a debug scan before clearing any mappings.
>>
>
> How about the following as an alternative.
>
> BUG_ON((hpte_v & 0x4000000000000000UL) && (crashing_cpus == -1));
> BUG_ON((size == MMU_PAGE_16G) && (crashing_cpus == -1));
> BUG_ON((size == MMU_PAGE_64K_AP) && (crashing_cpus == -1));
>
should be crashing_cpu - contains the panic cpu ID
> I don't have time to work on a multi-platform solution.
>
> Regards,
> Luke
>
>
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: MPC5200 ethernet communication stops unexpected
From: David Kanceruk @ 2007-04-27 18:15 UTC (permalink / raw)
To: Eberhard Stoll; +Cc: linuxppc-embedded
In-Reply-To: <4632369E.8010000@berghof.com>
[-- Attachment #1: Type: text/plain, Size: 3768 bytes --]
Hi Eberhard,
I have the problem with corrupted data on the MPC5200B. I traced the
problem to the BestComm driver. I see the correct data in the socket buffer
for the icmp reply but when BestComm puts the data into the Tx FIFO of the
fec, it sometimes puts the wrong byte in location 0 (which corrupts the
ethernet destination address) or location 62 (which corrupts the ping data).
These locations are always the same locations. Here is the contents of some
sample buffers I captured after gracefully stopping the fec transmitter (so
I could examine the FIFO without the fec doing a reset):
icmp csum = 7c2b
skb->data = 14
skb->dst->output = c0175924
neigh_hh_output calls = c0162b20
calling neigh->ops->queue_xmit c015c360
calling q->enqueue c0168034
dev->hard_start_xmit = c013ff3c
before - fec_hard_start_xmit 1 skb->data = 14 ----------------- this is
at offset 62
after - fec_hard_start_xmit 1 skb->data = 14 ----------------- still
has the correct value
start_addr = 00000160, end_addr = 000001C6, buf_len = 00000066
FEC IEVENT- 00000000
00003923 CD3F0050 C2263023 08004500 ----------------- this is what is in
the fec Tx FIFO
005437E3 00004001 BF72C0A8 0102C0A8
01010000 7C2B064A 000405C4 27466579
00000809 0A0B0C0D 0E0F1011 12130015 ---------------- second last byte is
00 --- this is bad!
16171819 1A1B1C1D 1E1F2021 22232425
26272829 2A2B2C2D 2E2F3031 32333435
FEC IEVENT- 00000000
icmp csum = 3a2a
skb->data = 14
skb->dst->output = c0175924
neigh_hh_output calls = c0162b20
calling neigh->ops->queue_xmit c015c360
calling q->enqueue c0168034
dev->hard_start_xmit = c013ff3c
before - fec_hard_start_xmit 1 skb->data = 14
after - fec_hard_start_xmit 1 skb->data = 14
start_addr = 000001C6, end_addr = 0000022C, buf_len = 00000066
FEC IEVENT- 00000000
00003923 CD3F0050 C2263023 08004500
005437E4 00004001 BF71C0A8 0102C0A8
01010000 3A2A064A 000506C4 2746A679
00000809 0A0B0C0D 0E0F1011 12131415 ---------------- second last byte is
14 --- this is good this time!
16171819 1A1B1C1D 1E1F2021 22232425
26272829 2A2B2C2D 2E2F3031 32333435
FEC IEVENT- 00000000
I think we need to focus on how the BestComm driver works now. I wonder if
there are any experts out there that might know what could be wrong?
Best regards,
Dave
On 4/27/07, Eberhard Stoll <eberhard.stoll@berghof.com> wrote:
>
> Hi,
> > Do your boards use the MPC5200B or MPC5200? Also, do you ever see
> > any corrupted data? (I'm guessing you would have mentioned it if you
> > did see corrupted data)
> I use MPC5200B processors. With MPC5200(A) processors i don't get this
> error!
> I didn't recognize corrupted data 'til now. But this could be - now i'm
> sending only pings and sometimes get output like this on the console:
> -- 8< --
>
> ..............................................................................tcp_recheck_csum:
> seq 0x5881325f retransmit, csum 0x232b OK?
> .............................................tcp_recheck_csum: seq
> 0x58813dd6 retransmit, csum 0xd1ad OK?
> ...............tcp_recheck_csum: seq 0x58814286 retransmit, csum 0xee5b
> OK?
> .....................tcp_recheck_csum: seq 0x58814982 retransmit, csum
> 0x8528 OK?
> ..............................................tcp_recheck_csum: seq
> 0x58815601 retransmit, csum 0x6ee1 OK?
> -- 8< --
> but i don't know what it means and where it comes from. Does someone know?
>
> Eberhard
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
--
David Kanceruk
"The generation of random numbers is far too important to be left to
chance."
[-- Attachment #2: Type: text/html, Size: 4533 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Show current speed in /proc/cpuinfo
From: Olof Johansson @ 2007-04-27 18:14 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, paulus
In-Reply-To: <4631BBB1.9010705@genesi-usa.com>
On Fri, Apr 27, 2007 at 10:00:33AM +0100, Matt Sealey wrote:
> Would it not be relevant to keep listing the maximum CPU speed as well
> as the real, current CPU speed?
>
> Intel encode this into their CPUID string and when I bring up Windows' System
> Properties dialog I get this;
>
> Intel(R) Pentium(R) M processor 1.70GHz
> 593MHz, 512MB of RAM
>
> So you can always, always find out very easily what spec your processor
> is, and not just what cpufreq has done with it?
On a system running cpufreq, you might not even have booted
the system at full speed, so the only way to know for sure
what the max speed is, is to look at the one in cpufreq
(/sys/devices/system/cpu/cpu<x>/cpufreq/scaling_max_freq).
For non-cpufreq platforms, the speed reported will be the same as before,
which on most platforms is whatever firmware tells us the speed of the
cpu is.
> > + /* cpufreq_speed_get() is in kHz */
> > + freq = cpufreq_quick_get(cpu_id);
>
> Is it speed or quick? This and the comment below confused me, KHz or Hz? :D
It's quick, I'll fix that. ppc_proc_freq is in Hz, freq in kHz, so you
need to divide.
-Olof
^ permalink raw reply
* Re: [PATCH v2] [2.6.22] pasemi: cpufreq driver
From: Olof Johansson @ 2007-04-27 18:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, egor, paulus, arnd, cpufreq
In-Reply-To: <1177666803.7828.30.camel@johannes.berg>
On Fri, Apr 27, 2007 at 11:40:03AM +0200, Johannes Berg wrote:
> > Hmm, I just tried adding debugging to the cpu_init code, and I'm not
> > seeing it called more than once (i.e. only for cpu 0). Mind you, I don't
> > have cpu hotplug support at this time.
>
> Oh right, you need cpu hotplug support for the bug to show up. What
> happens then is you unplug and replug a CPU and the sysfs cpufreq stuff
> for the CPU you just replugged is gone.
Ok. Nothing for me to worry about right now then, but it's good to keep
in mind for when the time comes.
Thanks,
-Olof
^ permalink raw reply
* RE: How do external irq's get mapped?
From: Charles Krinke @ 2007-04-27 18:05 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <463236E0.8070409@ru.mvista.com>
As I understand it, the 8541 and 8555 have 12 external IRQ[0..11], 21
internal interrupts, and 4 messaging interrupts.
In looking at the MPC8555ERM.pdf file, which is my main resource, it
looks like the internal interrupt numbers for the 1st TSEC are 19 for
transmit and 20 for receive.
A 'cat /proc/interrupts' shows the 1st TSEC transmit as 93 and the
receive as 94, so I am puzzled how we get from 19 to 93 for the transmit
and from 20 to 94 for the receive. Perhaps understanding this will help
me figure out what number to put into the pci_dev structure for external
IRQ0.
At this particular moment, I can put 16, 32 or other numbers into the
pci_dev and do a request_irq for my driver in Linux-2.6.17.11. The
driver interrupts are enabled, but when "__do_IRQ" executes, its irq
variable is zero, which it should not be.
I can also see with a printk in this same "__do_IRQ" that the TSEC tx is
indeed 93, the TSEC rx is indeed 94 and the uart is 106.
Sorry to be a bit dense here, but understanding this is important to
moving forward.
Charles Krinke
^ permalink raw reply
* Re: [PATCH] powerpc: Show current speed in /proc/cpuinfo
From: Olof Johansson @ 2007-04-27 17:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1177665878.14873.320.camel@localhost.localdomain>
On Fri, Apr 27, 2007 at 07:24:38PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2007-04-27 at 03:41 -0500, Olof Johansson wrote:
> > On other architectures, the frequency in /proc/cpuinfo moves with cpufreq
> > changes. It makes sense to do the same on powerpc to keep users from
> > getting confused. Fall back to old ppc_proc_freq for non-cpufreq systems.
> >
> > Also change the format to three decimals, having full Hz granularity is
> > silly these days.
>
> That doesn't work if cpufreq is a module... on mac, I used to have
> exactly that hack, though at one point I changed to just updating
> ppc_proc_freq :-) But then, it's easy because I only change the freq on
> all CPUs at the same time. Might be different for you.
CONFIG_CPU_FREQ is a bool. do you mean the cpufreq driver?
I could change the output to be:
clock : xxxx.000MHz (current speed)
and
clock : xxxx.000MHz (reported by firmware)
depending on how I get the info.
-Olof
^ permalink raw reply
* Re: Small cleanups to the cuboot bootwrapper code
From: Scott Wood @ 2007-04-27 17:50 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070427020154.GA20608@localhost.localdomain>
David Gibson wrote:
> Index: working-2.6/arch/powerpc/boot/Makefile
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/Makefile 2007-04-27 11:48:56.000000000 +1000
> +++ working-2.6/arch/powerpc/boot/Makefile 2007-04-27 11:57:41.000000000 +1000
> @@ -129,7 +129,8 @@ image-$(CONFIG_PPC_CELLEB) += zImage.ps
> image-$(CONFIG_PPC_CHRP) += zImage.chrp
> image-$(CONFIG_PPC_EFIKA) += zImage.chrp
> image-$(CONFIG_PPC_PMAC) += zImage.pmac
> -image-$(CONFIG_DEFAULT_UIMAGE) += uImage cuImage
> +image-$(CONFIG_PPC_83xx) += cuImage.83xx
> +image-$(CONFIG_DEFAULT_UIMAGE) += uImage
You need to update BOOT_TARGETS in arch/powerpc/Makefile as well.
Otherwise, it looks good.
-Scott
^ permalink raw reply
* Re: How do external irq's get mapped?
From: Sergei Shtylyov @ 2007-04-27 17:46 UTC (permalink / raw)
To: Charles Krinke; +Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06A1EF@MERCURY.inside.istor.com>
Charles Krinke wrote:
>>Let me try a more simplified IRQ question a different way by only
>>referring to the 8541.
>>There are 12 external interrupt sources, irq[0..11] and as I understand
>>it, they all go through one vector, ExternalInput set in
>>head_fsl_booke.S and this vector resolves to "do_IRQ()", which I believe
>>is in arch/powerpc/kernel/irq.c (not arch/ppc/kernel/...).
>>I am striving to understand how mapping of these external pins
>>irq[0..11] gets to IRQ numbers as shown with "cat /proc/interrupts".
> IIUC, the external IRQ #'s should follow those occupied by 32
> internal IRQs.
> But those shown in that file are "virtual" numbers, i.e. they got
> re-mapped by the kernel as it sees fit (basically, it tries to assign
> the same # to IRQs above 15 and remaps those below)
>>Could someone point me at some references I can read to understand this
>>nuance of the 8541 in a linux-2.6.17.11 kernel, please.
> I'm not sure arch/powerpc/ in 2.6.17 had the complete MPC8541
> support...
> So would this mean that the external IRQ0 pin would map to irq #32 and
> not irq #16 and the external IRQ11 pin would map to irq #43 and not irq
Where from is that #16?
> #27? So that if I want IRQ0, I would set my irq member of the pci_dev
> struct to 32?
Yeah, unless MPC8541 has some complications like CPM. And also note that I'm assuming 32 internal IRQs based on what MPC8540 has, not having MPC8541 specs...
> Charles
WBR, Sergei
^ permalink raw reply
* RE: How do external irq's get mapped?
From: Charles Krinke @ 2007-04-27 17:38 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <46322CE4.1060004@ru.mvista.com>
-----Original Message-----
From: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com]=20
Sent: Friday, April 27, 2007 10:04 AM
To: Charles Krinke
Cc: Jon Loeliger; Randy Brown; Chris Carlson; Kevin Smith;
linuxppc-embedded@ozlabs.org
Subject: Re: How do external irq's get mapped?
Hello.
Charles Krinke wrote:
> Let me try a more simplified IRQ question a different way by only
> referring to the 8541.
> There are 12 external interrupt sources, irq[0..11] and as I
understand
> it, they all go through one vector, ExternalInput set in
> head_fsl_booke.S and this vector resolves to "do_IRQ()", which I
believe
> is in arch/powerpc/kernel/irq.c (not arch/ppc/kernel/...).
> I am striving to understand how mapping of these external pins
> irq[0..11] gets to IRQ numbers as shown with "cat /proc/interrupts".
IIUC, the external IRQ #'s should follow those occupied by 32
internal IRQs.
But those shown in that file are "virtual" numbers, i.e. they got
re-mapped by the kernel as it sees fit (basically, it tries to assign
the same # to IRQs above 15 and remaps those below)
> Could someone point me at some references I can read to understand
this
> nuance of the 8541 in a linux-2.6.17.11 kernel, please.
I'm not sure arch/powerpc/ in 2.6.17 had the complete MPC8541
support...
WBR, Sergei
So would this mean that the external IRQ0 pin would map to irq #32 and
not irq #16 and the external IRQ11 pin would map to irq #43 and not irq
#27? So that if I want IRQ0, I would set my irq member of the pci_dev
struct to 32?
Charles=20
^ permalink raw reply
* Re: How do external irq's get mapped?
From: Jon Loeliger @ 2007-04-27 17:35 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Randy Brown, Chris Carlson, Kevin Smith,
linuxppc-embedded@ozlabs.org
In-Reply-To: <46322CE4.1060004@ru.mvista.com>
On Fri, 2007-04-27 at 12:03, Sergei Shtylyov wrote:
> Hello.
>
> Charles Krinke wrote:
>
> > Let me try a more simplified IRQ question a different way by only
> > referring to the 8541.
>
> > There are 12 external interrupt sources, irq[0..11] and as I understand
> > it, they all go through one vector, ExternalInput set in
> > head_fsl_booke.S and this vector resolves to "do_IRQ()", which I believe
> > is in arch/powerpc/kernel/irq.c (not arch/ppc/kernel/...).
>
> > I am striving to understand how mapping of these external pins
> > irq[0..11] gets to IRQ numbers as shown with "cat /proc/interrupts".
>
> IIUC, the external IRQ #'s should follow those occupied by 32 internal IRQs.
> But those shown in that file are "virtual" numbers, i.e. they got re-mapped by the kernel as it sees fit (basically, it tries to assign the same # to IRQs above 15 and remaps those below)
And remember, Ben distorted the IRQ World right about
somewhere in that time frame too.
Kumar, can you remind us?
> > Could someone point me at some references I can read to understand this
> > nuance of the 8541 in a linux-2.6.17.11 kernel, please.
>
> I'm not sure arch/powerpc/ in 2.6.17 had the complete MPC8541 support...
Which might be a different way of saying "You should try the
current top of git or 2.6.21." :-)
jdl
^ permalink raw reply
* Re: [PATCH v4] powerpc: 64K page support for kexec
From: Luke Browning @ 2007-04-27 17:30 UTC (permalink / raw)
To: Milton Miller
Cc: Arnd Bergmann, linuxppc-dev, Paul Mackerras, Olof Johansson,
cbe-oss-dev
In-Reply-To: <c21def285f4ad2e13914af73f7610c0b@bga.com>
On Fri, 2007-04-27 at 11:59 -0500, Milton Miller wrote:
>
> I see I've achived my nefarious goal of making these bugs never happen.
>
> (panic is a function, so you are checking that the staticly linked
> non-weak function is available. If you want to check on when
> if its a panic kdump or not, you need to decode the flag and pass
> it to kexec_sequence, pass it back here, and update all platforms
> for the new parameter).
>
> But I still say the check while clearing the table is too late,
> it should be a debug scan before clearing any mappings.
How about the following as an alternative.
BUG_ON((hpte_v & 0x4000000000000000UL) && (crashing_cpus == -1));
BUG_ON((size == MMU_PAGE_16G) && (crashing_cpus == -1));
BUG_ON((size == MMU_PAGE_64K_AP) && (crashing_cpus == -1));
I don't have time to work on a multi-platform solution.
Regards,
Luke
^ 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