[PATCH] Consolidate XILINX_VIRTEX board support

[PATCH] Consolidate XILINX_VIRTEX board support

[Wolfgang Reissnegger]

[-- Attachment #1: Type: text/plain, Size: 152 bytes --]

Make support for Xilinx boards more generic, making it easier
to add new boards.  Add initial support for xupv2p and ml410 boards.

Thanks,
   Wolfgang

[-- Attachment #2: [PATCH] Consolidate XILINX_VIRTEX board support.txt --]
[-- Type: text/plain, Size: 34090 bytes --]


Signed-off-by: Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com>
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
 arch/ppc/boot/simple/Makefile                      |    3 +-
 arch/ppc/boot/simple/embed_config.c                |    4 +-
 arch/ppc/platforms/4xx/Kconfig                     |   15 +
 arch/ppc/platforms/4xx/Makefile                    |    2 +
 arch/ppc/platforms/4xx/virtex.h                    |    9 +
 arch/ppc/platforms/4xx/xilinx_generic_ppc.c        |  129 ++++++++
 arch/ppc/platforms/4xx/xilinx_xupv2p.c             |   43 +++
 arch/ppc/platforms/4xx/xparameters/xparameters.h   |    4 +
 .../platforms/4xx/xparameters/xparameters_ml41x.h  |  277 +++++++++++++++++
 .../platforms/4xx/xparameters/xparameters_xupv2p.h |  327 ++++++++++++++++++++
 10 files changed, 809 insertions(+), 4 deletions(-)
 create mode 100644 arch/ppc/platforms/4xx/xilinx_generic_ppc.c
 create mode 100644 arch/ppc/platforms/4xx/xilinx_xupv2p.c
 create mode 100644 arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h
 create mode 100644 arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h

diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
index 5b87779..05631fe 100644
--- a/arch/ppc/boot/simple/Makefile
+++ b/arch/ppc/boot/simple/Makefile
@@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6)	+= embed_config.o
 boot-$(CONFIG_8xx)		+= embed_config.o
 boot-$(CONFIG_8260)		+= embed_config.o
 boot-$(CONFIG_EP405)		+= embed_config.o
-boot-$(CONFIG_XILINX_ML300)	+= embed_config.o
-boot-$(CONFIG_XILINX_ML403)	+= embed_config.o
+boot-$(CONFIG_XILINX_VIRTEX)	+= embed_config.o
 boot-$(CONFIG_BSEIP)		+= iic.o
 boot-$(CONFIG_MBX)		+= iic.o pci.o qspan_pci.o
 boot-$(CONFIG_MV64X60)		+= misc-mv64x60.o
diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
index 840bff2..e0b8954 100644
--- a/arch/ppc/boot/simple/embed_config.c
+++ b/arch/ppc/boot/simple/embed_config.c
@@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
 }
 #endif /* WILLOW */
 
-#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
+#if defined(CONFIG_XILINX_VIRTEX)
 void
 embed_config(bd_t ** bdp)
 {
@@ -781,7 +781,7 @@ embed_config(bd_t ** bdp)
 	timebase_period_ns = 1000000000 / bd->bi_tbfreq;
 	/* see bi_tbfreq definition in arch/ppc/platforms/4xx/xilinx_ml300.h */
 }
-#endif /* CONFIG_XILINX_ML300 || CONFIG_XILINX_ML403 */
+#endif /* CONFIG_XILINX_VIRTEX */
 
 #ifdef CONFIG_IBM_OPENBIOS
 /* This could possibly work for all treeboot roms.
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
index d7db7e4..56965cb 100644
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -60,12 +60,27 @@ config XILINX_ML300
 	help
 	  This option enables support for the Xilinx ML300 evaluation board.
 
+config XILINX_XUPV2P
+	bool "Xilinx-XUPV2P"
+	select XILINX_VIRTEX_II_PRO
+	select EMBEDDEDBOOT
+	help
+	  This option enables support for the Xilinx University Program (XUP) Virtex 2 Pro 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.
+
+config XILINX_ML41x
+	bool "Xilinx-ML41x"
+	select XILINX_VIRTEX_4_FX
+	select EMBEDDEDBOOT
+	help
+	  This option enables support for the Xilinx ML410/411 evaluation boards.
+
 endchoice
 
 choice
diff --git a/arch/ppc/platforms/4xx/Makefile b/arch/ppc/platforms/4xx/Makefile
index 723ad79..bcf1a63 100644
--- a/arch/ppc/platforms/4xx/Makefile
+++ b/arch/ppc/platforms/4xx/Makefile
@@ -15,7 +15,9 @@ obj-$(CONFIG_SYCAMORE)		+= sycamore.o
 obj-$(CONFIG_TAISHAN)		+= taishan.o
 obj-$(CONFIG_WALNUT)		+= walnut.o
 obj-$(CONFIG_XILINX_ML300)	+= xilinx_ml300.o
+obj-$(CONFIG_XILINX_XUPV2P)	+= xilinx_generic_ppc.o xilinx_xupv2p.o
 obj-$(CONFIG_XILINX_ML403)	+= xilinx_ml403.o
+obj-$(CONFIG_XILINX_ML41x)	+= xilinx_generic_ppc.o
 
 obj-$(CONFIG_405GP)		+= ibm405gp.o
 obj-$(CONFIG_REDWOOD_5)		+= ibmstb4.o
diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virtex.h
index 7382804..47f67b3 100644
--- a/arch/ppc/platforms/4xx/virtex.h
+++ b/arch/ppc/platforms/4xx/virtex.h
@@ -31,5 +31,14 @@ extern const char* virtex_machine_name;
 #define PPC4xx_ONB_IO_VADDR	0u
 #define PPC4xx_ONB_IO_SIZE	0u
 
+
+#if defined(CONFIG_XILINX_VIRTEX_II_PRO)
+#define XILINX_ARCH "Virtex-II Pro"
+#elif defined(CONFIG_XILINX_VIRTEX_4_FX)
+#define XILINX_ARCH "Virtex-4 FX"
+#else
+#error "No Xilinx Architecture recognized."
+#endif
+
 #endif				/* __ASM_VIRTEX_H__ */
 #endif				/* __KERNEL__ */
diff --git a/arch/ppc/platforms/4xx/xilinx_generic_ppc.c b/arch/ppc/platforms/4xx/xilinx_generic_ppc.c
new file mode 100644
index 0000000..103e762
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xilinx_generic_ppc.c
@@ -0,0 +1,129 @@
+/*
+ * Xilinx Generic PPC evaluation board initialization
+ *
+ * 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.
+ */
+
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/tty.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/serial_8250.h>
+#include <linux/serialP.h>
+#include <linux/io.h>
+#include <asm/machdep.h>
+
+#include <syslib/gen550.h>
+#include <syslib/virtex_devices.h>
+#include <platforms/4xx/xparameters/xparameters.h>
+
+/*
+ * As an overview of how the following functions (platform_init,
+ * xilinx_generic_ppc_map_io, xilinx_generic_ppc_setup_arch and xilinx_generic_ppc_init_IRQ) fit into the
+ * kernel startup procedure, here's a call tree:
+ *
+ * start_here					arch/ppc/kernel/head_4xx.S
+ *  early_init					arch/ppc/kernel/setup.c
+ *  machine_init				arch/ppc/kernel/setup.c
+ *    platform_init				this file
+ *      ppc4xx_init				arch/ppc/syslib/ppc4xx_setup.c
+ *        parse_bootinfo
+ *          find_bootinfo
+ *        "setup some default ppc_md pointers"
+ *  MMU_init					arch/ppc/mm/init.c
+ *    *ppc_md.setup_io_mappings == xilinx_generic_ppc_map_io	this file
+ *      ppc4xx_map_io				arch/ppc/syslib/ppc4xx_setup.c
+ *  start_kernel				init/main.c
+ *    setup_arch				arch/ppc/kernel/setup.c
+ * #if defined(CONFIG_KGDB)
+ *      *ppc_md.kgdb_map_scc() == gen550_kgdb_map_scc
+ * #endif
+ *      *ppc_md.setup_arch == xilinx_generic_ppc_setup_arch	this file
+ *        ppc4xx_setup_arch			arch/ppc/syslib/ppc4xx_setup.c
+ *          ppc4xx_find_bridges			arch/ppc/syslib/ppc405_pci.c
+ *    init_IRQ					arch/ppc/kernel/irq.c
+ *      *ppc_md.init_IRQ == xilinx_generic_ppc_init_IRQ	this file
+ *        ppc4xx_init_IRQ			arch/ppc/syslib/ppc4xx_setup.c
+ *          ppc4xx_pic_init			arch/ppc/syslib/xilinx_pic.c
+ */
+
+#if defined(CONFIG_XILINX_ML300)
+const char *virtex_machine_name = "Xilinx ML300";
+#elif defined(CONFIG_XILINX_XUPV2P)
+const char *virtex_machine_name = "Xilinx XUPV2P";
+#elif defined(CONFIG_XILINX_ML40x)
+const char *virtex_machine_name = "Xilinx ML40x";
+#elif defined(CONFIG_XILINX_ML41x)
+const char *virtex_machine_name = "Xilinx ML41x";
+#else
+const char *virtex_machine_name = "Unknown Xilinx with PowerPC";
+#endif
+
+
+#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
+static volatile unsigned *powerdown_base =
+    (volatile unsigned *) XPAR_POWER_0_POWERDOWN_BASEADDR;
+
+static void
+xilinx_power_off(void)
+{
+	local_irq_disable();
+	out_be32(powerdown_base, XPAR_POWER_0_POWERDOWN_VALUE);
+	while (1) ;
+}
+#endif
+
+void __init
+xilinx_generic_ppc_map_io(void)
+{
+	ppc4xx_map_io();
+
+#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
+	powerdown_base = ioremap((unsigned long) powerdown_base,
+				 XPAR_POWER_0_POWERDOWN_HIGHADDR -
+				 XPAR_POWER_0_POWERDOWN_BASEADDR + 1);
+#endif
+}
+
+void __init
+xilinx_generic_ppc_setup_arch(void)
+{
+	virtex_early_serial_map();
+	ppc4xx_setup_arch();	/* calls ppc4xx_find_bridges() */
+
+	/* Identify the system */
+	printk(KERN_INFO "Xilinx Generic PowerPC board support package (%s) (%s)\n", PPC4xx_MACHINE_NAME, XILINX_ARCH);
+}
+
+/* Called after board_setup_irq from ppc4xx_init_IRQ(). */
+void __init
+xilinx_generic_ppc_init_irq(void)
+{
+	ppc4xx_init_IRQ();
+}
+
+void __init
+platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+	 unsigned long r6, unsigned long r7)
+{
+	ppc4xx_init(r3, r4, r5, r6, r7);
+
+	ppc_md.setup_arch = xilinx_generic_ppc_setup_arch;
+	ppc_md.setup_io_mappings = xilinx_generic_ppc_map_io;
+	ppc_md.init_IRQ = xilinx_generic_ppc_init_irq;
+
+#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
+	ppc_md.power_off = xilinx_power_off;
+#endif
+
+#ifdef CONFIG_KGDB
+	ppc_md.early_serial_map = virtex_early_serial_map;
+#endif
+}
+
diff --git a/arch/ppc/platforms/4xx/xilinx_xupv2p.c b/arch/ppc/platforms/4xx/xilinx_xupv2p.c
new file mode 100644
index 0000000..aa2d890
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xilinx_xupv2p.c
@@ -0,0 +1,43 @@
+/*
+ * Xilinx XUPV2P board initialization
+ *
+ * Author: Stephen.Neuendorffer@xilinx.com
+ *
+ * 2007 (c) Xilinx, 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.
+ */
+
+#include <linux/xilinx_devices.h>
+#include <platforms/4xx/xparameters/xparameters.h>
+
+int virtex_device_fixup(struct platform_device *dev)
+{
+ int i;
+#ifdef XPAR_ONEWIRE_0_BASEADDR
+ /* Use the Silicon Serial ID attached on the onewire bus to */
+ /* generate sensible MAC addresses. */
+ unsigned char *pOnewire = ioremap(XPAR_ONEWIRE_0_BASEADDR, 6);
+ struct xemac_platform_data *pdata = dev->dev.platform_data;
+ if (strcmp(dev->name, "xilinx_emac") == 0) {
+  printk(KERN_INFO "Fixup MAC address for %s:%d\n",
+    dev->name, dev->id);
+  /* FIXME.. this doesn't seem to return data that is consistent */
+  /* with the self test... why not? */
+  pdata->mac_addr[0] = 0x00;
+  pdata->mac_addr[1] = 0x0A;
+  pdata->mac_addr[2] = 0x35;
+  pdata->mac_addr[3] = dev->id;
+  pdata->mac_addr[4] = pOnewire[4];
+  pdata->mac_addr[5] = pOnewire[5];
+  printk(KERN_INFO "MAC address is now %2x:%2x:%2x:%2x:%2x:%2x\n",
+   pdata->mac_addr[0],
+   pdata->mac_addr[1],
+   pdata->mac_addr[2],
+   pdata->mac_addr[3],
+   pdata->mac_addr[4],
+   pdata->mac_addr[5]);
+ }
+#endif
+ return 0;
+}
diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h b/arch/ppc/platforms/4xx/xparameters/xparameters.h
index 01aa043..34d9844 100644
--- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
+++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
@@ -15,8 +15,12 @@
 
 #if defined(CONFIG_XILINX_ML300)
   #include "xparameters_ml300.h"
+#elif defined(CONFIG_XILINX_XUPV2P)
+  #include "xparameters_xupv2p.h"
 #elif defined(CONFIG_XILINX_ML403)
   #include "xparameters_ml403.h"
+#elif defined(CONFIG_XILINX_ML41x)
+  #include "xparameters_ml41x.h"
 #else
   /* Add other board xparameter includes here before the #else */
   #error No xparameters_*.h file included
diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h b/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h
new file mode 100644
index 0000000..ff6956f
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h
@@ -0,0 +1,277 @@
+
+/*******************************************************************
+*
+* CAUTION: This file is automatically generated by libgen.
+* Version: Xilinx EDK 8.2.02 EDK_Im_Sp2.4
+* DO NOT EDIT.
+*
+* Copyright (c) 2005 Xilinx, Inc.  All rights reserved.
+*
+* Description: Driver parameters
+*
+*******************************************************************/
+
+/* Definitions for driver PLBARB */
+#define XPAR_XPLBARB_NUM_INSTANCES 1
+
+/* Definitions for peripheral PLB */
+#define XPAR_PLB_BASEADDR 0x00000000
+#define XPAR_PLB_HIGHADDR 0x00000000
+#define XPAR_PLB_DEVICE_ID 0
+#define XPAR_PLB_PLB_NUM_MASTERS 3
+
+
+/******************************************************************/
+
+/* Definitions for driver OPBARB */
+#define XPAR_XOPBARB_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB */
+#define XPAR_OPB_BASEADDR 0xFFFFFFFF
+#define XPAR_OPB_HIGHADDR 0x00000000
+#define XPAR_OPB_DEVICE_ID 0
+#define XPAR_OPB_NUM_MASTERS 1
+
+/******************************************************************/
+
+
+/* Definitions for peripheral OPB_SOCKET_0 */
+#define XPAR_OPB_SOCKET_0_BASEADDR 0x40000000
+#define XPAR_OPB_SOCKET_0_HIGHADDR 0x7FFFFFFF
+#define XPAR_OPB_SOCKET_0_DCR_BASEADDR 0x40700300
+#define XPAR_OPB_SOCKET_0_DCR_HIGHADDR 0x40700307
+
+/******************************************************************/
+
+/* Definitions for driver UARTNS550 */
+#define XPAR_XUARTNS550_NUM_INSTANCES 2
+#define XPAR_XUARTNS550_CLOCK_HZ 100000000
+
+/* Definitions for peripheral RS232_UART_1 */
+#define XPAR_RS232_UART_1_BASEADDR 0x40400000
+#define XPAR_RS232_UART_1_HIGHADDR 0x4040FFFF
+#define XPAR_RS232_UART_1_DEVICE_ID 0
+
+
+/* Definitions for peripheral RS232_UART_2 */
+#define XPAR_RS232_UART_2_BASEADDR 0x40420000
+#define XPAR_RS232_UART_2_HIGHADDR 0x4042FFFF
+#define XPAR_RS232_UART_2_DEVICE_ID 1
+
+
+/******************************************************************/
+
+/* Definitions for driver SPI */
+#define XPAR_XSPI_NUM_INSTANCES 1
+
+/* Definitions for peripheral SPI_EEPROM */
+#define XPAR_SPI_EEPROM_BASEADDR 0x40A00000
+#define XPAR_SPI_EEPROM_HIGHADDR 0x40A0FFFF
+#define XPAR_SPI_EEPROM_DEVICE_ID 0
+#define XPAR_SPI_EEPROM_FIFO_EXIST 1
+#define XPAR_SPI_EEPROM_SPI_SLAVE_ONLY 0
+#define XPAR_SPI_EEPROM_NUM_SS_BITS 1
+
+
+/******************************************************************/
+
+#define XPAR_XSYSACE_MEM_WIDTH 16
+/* Definitions for driver SYSACE */
+#define XPAR_XSYSACE_NUM_INSTANCES 1
+
+/* Definitions for peripheral SYSACE_COMPACTFLASH */
+#define XPAR_SYSACE_COMPACTFLASH_BASEADDR 0x41800000
+#define XPAR_SYSACE_COMPACTFLASH_HIGHADDR 0x4180FFFF
+#define XPAR_SYSACE_COMPACTFLASH_DEVICE_ID 0
+#define XPAR_SYSACE_COMPACTFLASH_MEM_WIDTH 16
+
+
+/******************************************************************/
+
+/* Definitions for driver IIC */
+#define XPAR_XIIC_NUM_INSTANCES 1
+
+/* Definitions for peripheral IIC_BUS */
+#define XPAR_IIC_BUS_BASEADDR 0x40800000
+#define XPAR_IIC_BUS_HIGHADDR 0x4080FFFF
+#define XPAR_IIC_BUS_DEVICE_ID 0
+#define XPAR_IIC_BUS_TEN_BIT_ADR 0
+#define XPAR_IIC_BUS_GPO_WIDTH 1
+
+
+/******************************************************************/
+
+#define XPAR_INTC_MAX_NUM_INTR_INPUTS 6
+#define XPAR_XINTC_HAS_IPR 1
+#define XPAR_XINTC_USE_DCR 0
+/* Definitions for driver INTC */
+#define XPAR_XINTC_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB_INTC_0 */
+#define XPAR_OPB_INTC_0_BASEADDR 0x41200000
+#define XPAR_OPB_INTC_0_HIGHADDR 0x4120FFFF
+#define XPAR_OPB_INTC_0_DEVICE_ID 0
+#define XPAR_OPB_INTC_0_KIND_OF_INTR 0x00000000
+
+
+/******************************************************************/
+
+#define XPAR_INTC_SINGLE_BASEADDR 0x41200000
+#define XPAR_INTC_SINGLE_HIGHADDR 0x4120FFFF
+#define XPAR_INTC_SINGLE_DEVICE_ID XPAR_OPB_INTC_0_DEVICE_ID
+#define XPAR_ETHERNET_MAC_IP2INTC_IRPT_MASK 0X000001
+#define XPAR_OPB_INTC_0_ETHERNET_MAC_IP2INTC_IRPT_INTR 0
+#define XPAR_IIC_BUS_IP2INTC_IRPT_MASK 0X000002
+#define XPAR_OPB_INTC_0_IIC_BUS_IP2INTC_IRPT_INTR 1
+#define XPAR_SYSACE_COMPACTFLASH_SYSACE_IRQ_MASK 0X000004
+#define XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_SYSACE_IRQ_INTR 2
+#define XPAR_SPI_EEPROM_IP2INTC_IRPT_MASK 0X000008
+#define XPAR_OPB_INTC_0_SPI_EEPROM_IP2INTC_IRPT_INTR 3
+#define XPAR_RS232_UART_2_IP2INTC_IRPT_MASK 0X000010
+#define XPAR_OPB_INTC_0_RS232_UART_2_IP2INTC_IRPT_INTR 4
+#define XPAR_RS232_UART_1_IP2INTC_IRPT_MASK 0X000020
+#define XPAR_OPB_INTC_0_RS232_UART_1_IP2INTC_IRPT_INTR 5
+
+/******************************************************************/
+
+/* Definitions for driver HWICAP */
+#define XPAR_XHWICAP_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB_HWICAP_0 */
+#define XPAR_OPB_HWICAP_0_BASEADDR 0x41300000
+#define XPAR_OPB_HWICAP_0_HIGHADDR 0x4130FFFF
+#define XPAR_OPB_HWICAP_0_DEVICE_ID 0
+
+/******************************************************************/
+
+/* Definitions for driver DDR */
+#define XPAR_XDDR_NUM_INSTANCES 1
+
+/* Definitions for peripheral DDR_SDRAM_32MX64 */
+#define XPAR_DDR_SDRAM_32MX64_ECC_BASEADDR 0xFFFFFFFF
+#define XPAR_DDR_SDRAM_32MX64_ECC_HIGHADDR 0x00000000
+#define XPAR_DDR_SDRAM_32MX64_DEVICE_ID 0
+#define XPAR_DDR_SDRAM_32MX64_INCLUDE_ECC_INTR 0
+
+
+/******************************************************************/
+
+/* Definitions for peripheral DDR_SDRAM_32MX64 */
+#define XPAR_DDR_SDRAM_32MX64_MEM0_BASEADDR 0x00000000
+#define XPAR_DDR_SDRAM_32MX64_MEM0_HIGHADDR 0x03FFFFFF
+
+/******************************************************************/
+
+/* Definitions for driver EMAC */
+#define XPAR_XEMAC_NUM_INSTANCES 1
+
+/* Definitions for peripheral ETHERNET_MAC */
+#define XPAR_ETHERNET_MAC_BASEADDR 0x80400000
+#define XPAR_ETHERNET_MAC_HIGHADDR 0x8040FFFF
+#define XPAR_ETHERNET_MAC_DEVICE_ID 0
+#define XPAR_ETHERNET_MAC_ERR_COUNT_EXIST 1
+#define XPAR_ETHERNET_MAC_DMA_PRESENT 1
+#define XPAR_ETHERNET_MAC_MII_EXIST 1
+
+
+/******************************************************************/
+
+
+/* Definitions for peripheral PLB_BRAM_IF_CNTLR_1 */
+#define XPAR_PLB_BRAM_IF_CNTLR_1_BASEADDR 0xfffff000
+#define XPAR_PLB_BRAM_IF_CNTLR_1_HIGHADDR 0xffffffff
+
+
+/******************************************************************/
+
+#define XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ 300000000
+
+/******************************************************************/
+
+
+/******************************************************************/
+
+/* Cannonical Constant Names */
+
+/******************************************************************/
+
+#define XPAR_UARTNS550_0_BASEADDR (XPAR_RS232_UART_1_BASEADDR+0x1000)
+#define XPAR_UARTNS550_0_HIGHADDR XPAR_RS232_UART_1_HIGHADDR
+#define XPAR_UARTNS550_0_CLOCK_FREQ_HZ XPAR_XUARTNS550_CLOCK_HZ
+#define XPAR_UARTNS550_0_DEVICE_ID XPAR_RS232_UART_1_DEVICE_ID
+#define XPAR_UARTNS550_1_BASEADDR (XPAR_RS232_UART_2_BASEADDR+0x1000)
+#define XPAR_UARTNS550_1_HIGHADDR XPAR_RS232_UART_2_HIGHADDR
+#define XPAR_UARTNS550_1_CLOCK_FREQ_HZ XPAR_XUARTNS550_CLOCK_HZ
+#define XPAR_UARTNS550_1_DEVICE_ID XPAR_RS232_UART_2_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_SPI_0_BASEADDR XPAR_SPI_EEPROM_BASEADDR
+#define XPAR_SPI_0_HIGHADDR XPAR_SPI_EEPROM_HIGHADDR
+#define XPAR_SPI_0_FIFO_EXIST XPAR_SPI_EEPROM_FIFO_EXIST
+#define XPAR_SPI_0_SPI_SLAVE_ONLY XPAR_SPI_EEPROM_SPI_SLAVE_ONLY
+#define XPAR_SPI_0_NUM_SS_BITS XPAR_SPI_EEPROM_NUM_SS_BITS
+#define XPAR_SPI_0_DEVICE_ID XPAR_SPI_EEPROM_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_SYSACE_0_BASEADDR XPAR_SYSACE_COMPACTFLASH_BASEADDR
+#define XPAR_SYSACE_0_HIGHADDR XPAR_SYSACE_COMPACTFLASH_HIGHADDR
+#define XPAR_SYSACE_0_DEVICE_ID XPAR_SYSACE_COMPACTFLASH_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_IIC_0_BASEADDR XPAR_IIC_BUS_BASEADDR
+#define XPAR_IIC_0_HIGHADDR XPAR_IIC_BUS_HIGHADDR
+#define XPAR_IIC_0_TEN_BIT_ADR XPAR_IIC_BUS_TEN_BIT_ADR
+#define XPAR_IIC_0_DEVICE_ID XPAR_IIC_BUS_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_EMAC_0_BASEADDR XPAR_ETHERNET_MAC_BASEADDR
+#define XPAR_EMAC_0_HIGHADDR XPAR_ETHERNET_MAC_HIGHADDR
+#define XPAR_EMAC_0_DMA_PRESENT XPAR_ETHERNET_MAC_DMA_PRESENT
+#define XPAR_EMAC_0_MII_EXIST XPAR_ETHERNET_MAC_MII_EXIST
+#define XPAR_EMAC_0_ERR_COUNT_EXIST XPAR_ETHERNET_MAC_ERR_COUNT_EXIST
+#define XPAR_EMAC_0_DEVICE_ID XPAR_ETHERNET_MAC_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_HWICAP_0_BASEADDR XPAR_OPB_HWICAP_0_BASEADDR
+#define XPAR_HWICAP_0_HIGHADDR XPAR_OPB_HWICAP_0_HIGHADDR
+#define XPAR_HWICAP_0_DEVICE_ID XPAR_OPB_HWICAP_0_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_INTC_0_BASEADDR XPAR_OPB_INTC_0_BASEADDR
+#define XPAR_INTC_0_HIGHADDR XPAR_OPB_INTC_0_HIGHADDR
+#define XPAR_INTC_0_KIND_OF_INTR XPAR_OPB_INTC_0_KIND_OF_INTR
+#define XPAR_INTC_0_DEVICE_ID XPAR_OPB_INTC_0_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_INTC_0_EMAC_0_VEC_ID XPAR_OPB_INTC_0_ETHERNET_MAC_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_IIC_0_VEC_ID XPAR_OPB_INTC_0_IIC_BUS_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_SYSACE_0_VEC_ID XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_SYSACE_IRQ_INTR
+#define XPAR_INTC_0_SPI_0_VEC_ID XPAR_OPB_INTC_0_SPI_EEPROM_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_UARTNS550_1_VEC_ID XPAR_OPB_INTC_0_RS232_UART_2_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_UARTNS550_0_VEC_ID XPAR_OPB_INTC_0_RS232_UART_1_IP2INTC_IRPT_INTR
+
+/******************************************************************/
+
+#define XPAR_PLB_CLOCK_FREQ_HZ 100000000
+#define XPAR_CORE_CLOCK_FREQ_HZ XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ
+#define XPAR_DDR_0_SIZE 64000000
+
+/******************************************************************/
+
+#define XPAR_PERSISTENT_0_IIC_0_BASEADDR 1024
+#define XPAR_PERSISTENT_0_IIC_0_HIGHADDR 2047
+#define XPAR_PERSISTENT_0_IIC_0_EEPROMADDR 0xA0
+
+/******************************************************************/
+
+#define XPAR_PCI_0_CLOCK_FREQ_HZ    0
+
+/******************************************************************/
+
diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h b/arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h
new file mode 100644
index 0000000..cdaf28f
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h
@@ -0,0 +1,327 @@
+
+/*******************************************************************
+*
+* CAUTION: This file is automatically generated by libgen.
+* Version: Xilinx EDK 8.2.02 EDK_Im_Sp2.4
+* DO NOT EDIT.
+*
+* Copyright (c) 2005 Xilinx, Inc.  All rights reserved.
+*
+* Description: Driver parameters
+*
+*******************************************************************/
+
+/* Definitions for driver PLBARB */
+#define XPAR_XPLBARB_NUM_INSTANCES 1
+
+/* Definitions for peripheral PLB */
+#define XPAR_PLB_BASEADDR 0x00000000
+#define XPAR_PLB_HIGHADDR 0x00000000
+#define XPAR_PLB_DEVICE_ID 0
+#define XPAR_PLB_PLB_NUM_MASTERS 3
+
+
+/******************************************************************/
+
+/* Definitions for driver OPBARB */
+#define XPAR_XOPBARB_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB */
+#define XPAR_OPB_BASEADDR 0xFFFFFFFF
+#define XPAR_OPB_HIGHADDR 0x00000000
+#define XPAR_OPB_DEVICE_ID 0
+#define XPAR_OPB_NUM_MASTERS 1
+
+
+/******************************************************************/
+
+
+/* Definitions for peripheral OPB_SOCKET_0 */
+#define XPAR_OPB_SOCKET_0_BASEADDR 0x7D400000
+#define XPAR_OPB_SOCKET_0_HIGHADDR 0x7D4000FF
+#define XPAR_OPB_SOCKET_0_DCR_BASEADDR 0x40700300
+#define XPAR_OPB_SOCKET_0_DCR_HIGHADDR 0x40700307
+
+/******************************************************************/
+
+/* Definitions for driver OPB_ONEWIRE */
+#define XPAR_OPB_ONEWIRE_NUM_INSTANCES 1
+
+/* Definitions for peripheral ONEWIRE_0 */
+#define XPAR_ONEWIRE_0_BASEADDR 0x7A200000
+#define XPAR_ONEWIRE_0_HIGHADDR 0x7A20FFFF
+
+
+/******************************************************************/
+
+/* Definitions for driver UARTNS550 */
+#define XPAR_XUARTNS550_NUM_INSTANCES 1
+#define XPAR_XUARTNS550_CLOCK_HZ 100000000
+
+/* Definitions for peripheral RS232_UART_1 */
+#define XPAR_RS232_UART_1_BASEADDR 0x40400000
+#define XPAR_RS232_UART_1_HIGHADDR 0x4040FFFF
+#define XPAR_RS232_UART_1_DEVICE_ID 0
+
+
+/******************************************************************/
+
+#define XPAR_XSYSACE_MEM_WIDTH 16
+/* Definitions for driver SYSACE */
+#define XPAR_XSYSACE_NUM_INSTANCES 1
+
+/* Definitions for peripheral SYSACE_COMPACTFLASH */
+#define XPAR_SYSACE_COMPACTFLASH_BASEADDR 0x41800000
+#define XPAR_SYSACE_COMPACTFLASH_HIGHADDR 0x4180FFFF
+#define XPAR_SYSACE_COMPACTFLASH_DEVICE_ID 0
+#define XPAR_SYSACE_COMPACTFLASH_MEM_WIDTH 16
+
+
+/******************************************************************/
+
+/* Definitions for driver GPIO */
+#define XPAR_XGPIO_NUM_INSTANCES 3
+
+/* Definitions for peripheral LEDS_4BIT */
+#define XPAR_LEDS_4BIT_BASEADDR 0x40000000
+#define XPAR_LEDS_4BIT_HIGHADDR 0x4000FFFF
+#define XPAR_LEDS_4BIT_DEVICE_ID 0
+#define XPAR_LEDS_4BIT_INTERRUPT_PRESENT 0
+#define XPAR_LEDS_4BIT_IS_DUAL 0
+
+
+/* Definitions for peripheral DIPSWS_4BIT */
+#define XPAR_DIPSWS_4BIT_BASEADDR 0x40020000
+#define XPAR_DIPSWS_4BIT_HIGHADDR 0x4002FFFF
+#define XPAR_DIPSWS_4BIT_DEVICE_ID 1
+#define XPAR_DIPSWS_4BIT_INTERRUPT_PRESENT 0
+#define XPAR_DIPSWS_4BIT_IS_DUAL 0
+
+
+/* Definitions for peripheral PUSHBUTTONS_5BIT */
+#define XPAR_PUSHBUTTONS_5BIT_BASEADDR 0x40040000
+#define XPAR_PUSHBUTTONS_5BIT_HIGHADDR 0x4004FFFF
+#define XPAR_PUSHBUTTONS_5BIT_DEVICE_ID 2
+#define XPAR_PUSHBUTTONS_5BIT_INTERRUPT_PRESENT 0
+#define XPAR_PUSHBUTTONS_5BIT_IS_DUAL 0
+
+
+/******************************************************************/
+
+#define XPAR_XPS2_NUM_INSTANCES 2
+#define XPAR_PS2_PORTS_DEVICE_ID_0 0
+#define XPAR_PS2_PORTS_BASEADDR_0 0x7a400000
+#define XPAR_PS2_PORTS_HIGHADDR_0 (0x7a400000+0x3F)
+#define XPAR_PS2_PORTS_DEVICE_ID_1 1
+#define XPAR_PS2_PORTS_BASEADDR_1 (0x7a400000+0x1000)
+#define XPAR_PS2_PORTS_HIGHADDR_1 (0x7a400000+0x103F)
+
+/******************************************************************/
+
+#define XPAR_INTC_MAX_NUM_INTR_INPUTS 7
+#define XPAR_XINTC_HAS_IPR 1
+#define XPAR_XINTC_USE_DCR 0
+/* Definitions for driver INTC */
+#define XPAR_XINTC_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB_INTC_0 */
+#define XPAR_OPB_INTC_0_BASEADDR 0x41200000
+#define XPAR_OPB_INTC_0_HIGHADDR 0x4120FFFF
+#define XPAR_OPB_INTC_0_DEVICE_ID 0
+#define XPAR_OPB_INTC_0_KIND_OF_INTR 0x00000000
+
+
+/******************************************************************/
+
+#define XPAR_INTC_SINGLE_BASEADDR 0x41200000
+#define XPAR_INTC_SINGLE_HIGHADDR 0x4120FFFF
+#define XPAR_INTC_SINGLE_DEVICE_ID XPAR_OPB_INTC_0_DEVICE_ID
+#define XPAR_OPB_TIMER_0_INTERRUPT_MASK 0X000001
+#define XPAR_OPB_INTC_0_OPB_TIMER_0_INTERRUPT_INTR 0
+#define XPAR_OPB_SOCKET_IP2INTC_IRPT_MASK 0X000002
+#define XPAR_OPB_INTC_0_OPB_SOCKET_IP2INTC_IRPT_INTR 1
+#define XPAR_ETHERNET_MAC_IP2INTC_IRPT_MASK 0X000004
+#define XPAR_OPB_INTC_0_ETHERNET_MAC_IP2INTC_IRPT_INTR 2
+#define XPAR_SYSACE_COMPACTFLASH_SYSACE_IRQ_MASK 0X000008
+#define XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_SYSACE_IRQ_INTR 3
+#define XPAR_RS232_UART_1_IP2INTC_IRPT_MASK 0X000010
+#define XPAR_OPB_INTC_0_RS232_UART_1_IP2INTC_IRPT_INTR 4
+#define XPAR_PS2_PORTS_SYS_INTR2_MASK 0X000020
+#define XPAR_OPB_INTC_0_PS2_PORTS_SYS_INTR2_INTR 5
+#define XPAR_PS2_PORTS_SYS_INTR1_MASK 0X000040
+#define XPAR_OPB_INTC_0_PS2_PORTS_SYS_INTR1_INTR 6
+
+/******************************************************************/
+
+/* Definitions for driver HWICAP */
+#define XPAR_XHWICAP_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB_HWICAP_0 */
+#define XPAR_OPB_HWICAP_0_BASEADDR 0x41300000
+#define XPAR_OPB_HWICAP_0_HIGHADDR 0x4130FFFF
+#define XPAR_OPB_HWICAP_0_DEVICE_ID 0
+
+/******************************************************************/
+
+/* Definitions for driver TFT_REF */
+#define XPAR_XTFT_NUM_INSTANCES 1
+
+/* Definitions for peripheral VGA_FRAMEBUFFER */
+#define XPAR_VGA_FRAMEBUFFER_DCR_BASEADDR 0x40700200
+#define XPAR_VGA_FRAMEBUFFER_DCR_HIGHADDR 0x40700207
+#define XPAR_VGA_FRAMEBUFFER_DEVICE_ID 0
+
+
+/******************************************************************/
+
+/* Definitions for driver TMRCTR */
+#define XPAR_XTMRCTR_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB_TIMER_0 */
+#define XPAR_OPB_TIMER_0_BASEADDR 0x40800000
+#define XPAR_OPB_TIMER_0_HIGHADDR 0x408000FF
+#define XPAR_OPB_TIMER_0_DEVICE_ID 0
+
+
+/******************************************************************/
+
+/* Definitions for driver EMAC */
+#define XPAR_XEMAC_NUM_INSTANCES 1
+
+/* Definitions for peripheral ETHERNET_MAC */
+#define XPAR_ETHERNET_MAC_BASEADDR 0x80400000
+#define XPAR_ETHERNET_MAC_HIGHADDR 0x8040FFFF
+#define XPAR_ETHERNET_MAC_DEVICE_ID 0
+#define XPAR_ETHERNET_MAC_ERR_COUNT_EXIST 1
+#define XPAR_ETHERNET_MAC_DMA_PRESENT 1
+#define XPAR_ETHERNET_MAC_MII_EXIST 1
+
+
+/******************************************************************/
+
+/* Definitions for driver DDR */
+#define XPAR_XDDR_NUM_INSTANCES 1
+
+/* Definitions for peripheral DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5 */
+#define XPAR_DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5_ECC_BASEADDR 0xFFFFFFFF
+#define XPAR_DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5_ECC_HIGHADDR 0x00000000
+#define XPAR_DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5_DEVICE_ID 0
+#define XPAR_DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5_INCLUDE_ECC_INTR 0
+
+
+/******************************************************************/
+
+/* Definitions for peripheral DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5 */
+#define XPAR_DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5_MEM0_BASEADDR 0x00000000
+#define XPAR_DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5_MEM0_HIGHADDR 0x0FFFFFFF
+
+/******************************************************************/
+
+
+/* Definitions for peripheral PLB_BRAM_IF_CNTLR_1 */
+#define XPAR_PLB_BRAM_IF_CNTLR_1_BASEADDR 0xffffc000
+#define XPAR_PLB_BRAM_IF_CNTLR_1_HIGHADDR 0xffffffff
+
+
+/******************************************************************/
+
+#define XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ 300000000
+
+/******************************************************************/
+
+
+/******************************************************************/
+
+/* Cannonical Constant Names */
+
+/******************************************************************/
+
+#define XPAR_UARTNS550_0_BASEADDR (XPAR_RS232_UART_1_BASEADDR+0x1000)
+#define XPAR_UARTNS550_0_HIGHADDR XPAR_RS232_UART_1_HIGHADDR
+#define XPAR_UARTNS550_0_CLOCK_FREQ_HZ XPAR_XUARTNS550_CLOCK_HZ
+#define XPAR_UARTNS550_0_DEVICE_ID XPAR_RS232_UART_1_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_EMAC_0_BASEADDR XPAR_ETHERNET_MAC_BASEADDR
+#define XPAR_EMAC_0_HIGHADDR XPAR_ETHERNET_MAC_HIGHADDR
+#define XPAR_EMAC_0_DMA_PRESENT XPAR_ETHERNET_MAC_DMA_PRESENT
+#define XPAR_EMAC_0_MII_EXIST XPAR_ETHERNET_MAC_MII_EXIST
+#define XPAR_EMAC_0_ERR_COUNT_EXIST XPAR_ETHERNET_MAC_ERR_COUNT_EXIST
+#define XPAR_EMAC_0_DEVICE_ID XPAR_ETHERNET_MAC_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_SYSACE_0_BASEADDR XPAR_SYSACE_COMPACTFLASH_BASEADDR
+#define XPAR_SYSACE_0_HIGHADDR XPAR_SYSACE_COMPACTFLASH_HIGHADDR
+#define XPAR_SYSACE_0_DEVICE_ID XPAR_SYSACE_COMPACTFLASH_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_TMRCTR_0_BASEADDR XPAR_OPB_TIMER_0_BASEADDR
+#define XPAR_TMRCTR_0_HIGHADDR XPAR_OPB_TIMER_0_HIGHADDR
+#define XPAR_TMRCTR_0_DEVICE_ID XPAR_OPB_TIMER_0_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_HWICAP_0_BASEADDR XPAR_OPB_HWICAP_0_BASEADDR
+#define XPAR_HWICAP_0_HIGHADDR XPAR_OPB_HWICAP_0_HIGHADDR
+#define XPAR_HWICAP_0_DEVICE_ID XPAR_OPB_HWICAP_0_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_GPIO_0_BASEADDR XPAR_LEDS_4BIT_BASEADDR
+#define XPAR_GPIO_0_HIGHADDR XPAR_LEDS_4BIT_HIGHADDR
+#define XPAR_GPIO_0_IS_DUAL XPAR_LEDS_4BIT_IS_DUAL
+#define XPAR_GPIO_0_DEVICE_ID XPAR_LEDS_4BIT_DEVICE_ID
+#define XPAR_GPIO_1_BASEADDR XPAR_DIPSWS_4BIT_BASEADDR
+#define XPAR_GPIO_1_HIGHADDR XPAR_DIPSWS_4BIT_HIGHADDR
+#define XPAR_GPIO_1_IS_DUAL XPAR_DIPSWS_4BIT_IS_DUAL
+#define XPAR_GPIO_1_DEVICE_ID XPAR_DIPSWS_4BIT_DEVICE_ID
+#define XPAR_GPIO_2_BASEADDR XPAR_PUSHBUTTONS_5BIT_BASEADDR
+#define XPAR_GPIO_2_HIGHADDR XPAR_PUSHBUTTONS_5BIT_HIGHADDR
+#define XPAR_GPIO_2_IS_DUAL XPAR_PUSHBUTTONS_5BIT_IS_DUAL
+#define XPAR_GPIO_2_DEVICE_ID XPAR_PUSHBUTTONS_5BIT_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_PS2_0_BASEADDR XPAR_PS2_PORTS_BASEADDR_0
+#define XPAR_PS2_0_HIGHADDR XPAR_PS2_PORTS_HIGHADDR_0
+#define XPAR_PS2_0_DEVICE_ID XPAR_PS2_PORTS_DEVICE_ID_0
+#define XPAR_PS2_1_BASEADDR XPAR_PS2_PORTS_BASEADDR_1
+#define XPAR_PS2_1_HIGHADDR XPAR_PS2_PORTS_HIGHADDR_1
+#define XPAR_PS2_1_DEVICE_ID XPAR_PS2_PORTS_DEVICE_ID_1
+
+/******************************************************************/
+
+#define XPAR_INTC_0_BASEADDR XPAR_OPB_INTC_0_BASEADDR
+#define XPAR_INTC_0_HIGHADDR XPAR_OPB_INTC_0_HIGHADDR
+#define XPAR_INTC_0_KIND_OF_INTR XPAR_OPB_INTC_0_KIND_OF_INTR
+#define XPAR_INTC_0_DEVICE_ID XPAR_OPB_INTC_0_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_INTC_0_TMRCTR_0_VEC_ID XPAR_OPB_INTC_0_OPB_TIMER_0_INTERRUPT_INTR
+#define XPAR_INTC_0_OPB_SOCKET_0_VEC_ID XPAR_OPB_INTC_0_OPB_SOCKET_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_EMAC_0_VEC_ID XPAR_OPB_INTC_0_ETHERNET_MAC_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_SYSACE_0_VEC_ID XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_SYSACE_IRQ_INTR
+#define XPAR_INTC_0_UARTNS550_0_VEC_ID XPAR_OPB_INTC_0_RS232_UART_1_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_PS2_1_VEC_ID XPAR_OPB_INTC_0_PS2_PORTS_SYS_INTR2_INTR
+#define XPAR_INTC_0_PS2_0_VEC_ID XPAR_OPB_INTC_0_PS2_PORTS_SYS_INTR1_INTR
+
+/******************************************************************/
+
+#define XPAR_TFT_0_BASEADDR XPAR_VGA_FRAMEBUFFER_DCR_BASEADDR
+
+/******************************************************************/
+
+#define XPAR_PLB_CLOCK_FREQ_HZ 100000000
+#define XPAR_CORE_CLOCK_FREQ_HZ XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ
+#define XPAR_DDR_0_SIZE 0x10000000
+
+/******************************************************************/
+
+#define XPAR_PCI_0_CLOCK_FREQ_HZ    0
+
+/******************************************************************/
+
-- 
1.5.1

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[Arnd Bergmann]

On Tuesday 07 August 2007, Wolfgang Reissnegger wrote:
>=20
> Make support for Xilinx boards more generic, making it easier
> to add new boards. =A0Add initial support for xupv2p and ml410 boards.

I really think we shouldn't add stuff to arch/ppc at this point,
it has been deprecated for over two years now.

> --- a/arch/ppc/platforms/4xx/virtex.h
> +++ b/arch/ppc/platforms/4xx/virtex.h
> @@ -31,5 +31,14 @@ extern const char* virtex_machine_name;
> =A0#define PPC4xx_ONB_IO_VADDR=A0=A0=A0=A00u
> =A0#define PPC4xx_ONB_IO_SIZE=A0=A0=A0=A0=A00u
> =A0
> +
> +#if defined(CONFIG_XILINX_VIRTEX_II_PRO)
> +#define XILINX_ARCH "Virtex-II Pro"
> +#elif defined(CONFIG_XILINX_VIRTEX_4_FX)
> +#define XILINX_ARCH "Virtex-4 FX"
> +#else
> +#error "No Xilinx Architecture recognized."
> +#endif
> +
> =A0#endif=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0/* __ASM_VIRTEX_H__ */
> =A0#endif=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0/* __KERNEL__ */

When you move over to arch/powerpc, you can't do it this way, because
that prevents you from building a multiplatform kernel.

Every macro and global function that gets defined must be able to coexist
with others that are enabled by nonexclusive configuration options.

> +#if defined(CONFIG_XILINX_ML300)
> +const char *virtex_machine_name =3D "Xilinx ML300";
> +#elif defined(CONFIG_XILINX_XUPV2P)
> +const char *virtex_machine_name =3D "Xilinx XUPV2P";
> +#elif defined(CONFIG_XILINX_ML40x)
> +const char *virtex_machine_name =3D "Xilinx ML40x";
> +#elif defined(CONFIG_XILINX_ML41x)
> +const char *virtex_machine_name =3D "Xilinx ML41x";
> +#else
> +const char *virtex_machine_name =3D "Unknown Xilinx with PowerPC";
> +#endif

same here.

> +
> +
> +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> +static volatile unsigned *powerdown_base =3D
> + =A0 =A0(volatile unsigned *) XPAR_POWER_0_POWERDOWN_BASEADDR;

volatile is a bug. This needs to be __iomem, and the address probably
needs to come from of_iomap() or a similar function.

> +static void
> +xilinx_power_off(void)
> +{
> +=A0=A0=A0=A0=A0=A0=A0local_irq_disable();
> +=A0=A0=A0=A0=A0=A0=A0out_be32(powerdown_base, XPAR_POWER_0_POWERDOWN_VAL=
UE);
> +=A0=A0=A0=A0=A0=A0=A0while (1) ;
> +}
> +#endif

You should run 'sparse' on your code before submitting patches. That
would have caught this bug in the out_be32() instruction that expects
an __iomem pointer.

> +
> +void __init
> +xilinx_generic_ppc_map_io(void)
> +{
> +=A0=A0=A0=A0=A0=A0=A0ppc4xx_map_io();
> +
> +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> +=A0=A0=A0=A0=A0=A0=A0powerdown_base =3D ioremap((unsigned long) powerdow=
n_base,
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 XPAR_POWER_0_POWERDOWN_HIGHADDR -
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 XPAR_POWER_0_POWERDOWN_BASEADDR + 1);
> +#endif
> +}

It's a rather unconventional way of working with the addresses.
You should never use a single variable for pointers going to
two different address spaces (physical and kernel virtual in this
case).

> +void __init
> +xilinx_generic_ppc_setup_arch(void)
> +{
> +=A0=A0=A0=A0=A0=A0=A0virtex_early_serial_map();

Use legacy_serial/of_serial to do this, with proper device tree entries.

> +
> +int virtex_device_fixup(struct platform_device *dev)
> +{
> + int i;
> +#ifdef XPAR_ONEWIRE_0_BASEADDR
> + /* Use the Silicon Serial ID attached on the onewire bus to */
> + /* generate sensible MAC addresses. */
> + unsigned char *pOnewire =3D ioremap(XPAR_ONEWIRE_0_BASEADDR, 6);
> + struct xemac_platform_data *pdata =3D dev->dev.platform_data;
> + if (strcmp(dev->name, "xilinx_emac") =3D=3D 0) {

This is heavily whitespace damaged, use tabs for indentation instead
of spaces.

> diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h b/arch/ppc/=
platforms/4xx/xparameters/xparameters.h
> index 01aa043..34d9844 100644
> --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
> +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> @@ -15,8 +15,12 @@
> =A0
> =A0#if defined(CONFIG_XILINX_ML300)
> =A0 =A0#include "xparameters_ml300.h"
> +#elif defined(CONFIG_XILINX_XUPV2P)
> + =A0#include "xparameters_xupv2p.h"
> =A0#elif defined(CONFIG_XILINX_ML403)
> =A0 =A0#include "xparameters_ml403.h"
> +#elif defined(CONFIG_XILINX_ML41x)
> + =A0#include "xparameters_ml41x.h"
> =A0#else
> =A0 =A0/* Add other board xparameter includes here before the #else */
> =A0 =A0#error No xparameters_*.h file included

see comment above.

> +/* Definitions for driver PLBARB */
> +#define XPAR_XPLBARB_NUM_INSTANCES 1
> +
> +/* Definitions for peripheral PLB */
> +#define XPAR_PLB_BASEADDR 0x00000000
> +#define XPAR_PLB_HIGHADDR 0x00000000
> +#define XPAR_PLB_DEVICE_ID 0
> +#define XPAR_PLB_PLB_NUM_MASTERS 3
> +
> +
> +/******************************************************************/
> +
> +/* Definitions for driver OPBARB */
> +#define XPAR_XOPBARB_NUM_INSTANCES 1
> +
> +/* Definitions for peripheral OPB */
> +#define XPAR_OPB_BASEADDR 0xFFFFFFFF
> +#define XPAR_OPB_HIGHADDR 0x00000000
> +#define XPAR_OPB_DEVICE_ID 0
> +#define XPAR_OPB_NUM_MASTERS 1
> +
> +/******************************************************************/
> +
> +
> +/* Definitions for peripheral OPB_SOCKET_0 */
> +#define XPAR_OPB_SOCKET_0_BASEADDR 0x40000000
> +#define XPAR_OPB_SOCKET_0_HIGHADDR 0x7FFFFFFF
> +#define XPAR_OPB_SOCKET_0_DCR_BASEADDR 0x40700300
> +#define XPAR_OPB_SOCKET_0_DCR_HIGHADDR 0x40700307
> +
> +/******************************************************************/
> +
> +/* Definitions for driver UARTNS550 */
> +#define XPAR_XUARTNS550_NUM_INSTANCES 2
> +#define XPAR_XUARTNS550_CLOCK_HZ 100000000
> +
> +/* Definitions for peripheral RS232_UART_1 */
> +#define XPAR_RS232_UART_1_BASEADDR 0x40400000
> +#define XPAR_RS232_UART_1_HIGHADDR 0x4040FFFF
> +#define XPAR_RS232_UART_1_DEVICE_ID 0
> +
> +
> +/* Definitions for peripheral RS232_UART_2 */
> +#define XPAR_RS232_UART_2_BASEADDR 0x40420000
> +#define XPAR_RS232_UART_2_HIGHADDR 0x4042FFFF
> +#define XPAR_RS232_UART_2_DEVICE_ID 1
> +

none of theses addresses, nor those following below should be hardcoded
in the kernel source, but should come from the device tree.

	Arnd <><

RE: [PATCH] Consolidate XILINX_VIRTEX board support

[Stephen Neuendorffer]

> On Tuesday 07 August 2007, Wolfgang Reissnegger wrote:
> >=20
> > Make support for Xilinx boards more generic, making it easier
> > to add new boards. =A0Add initial support for xupv2p and ml410 =
boards.
>=20
> I really think we shouldn't add stuff to arch/ppc at this point,
> it has been deprecated for over two years now.

This is a good point...  In fact the other patch (although tiny) is
more important, since it affects drivers, which should work in
arch/powerpc.  Thanks for the feedback anyway!

On this topic: has anyone tried using the recent Walnut patches for
arch/powerpc?   I briefly took a look at starting to port the Virtex
support to arch/powerpc but I'm a bit lost as to where to start... :)

Steve

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[Grant Likely]

On 8/6/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> > On Tuesday 07 August 2007, Wolfgang Reissnegger wrote:
> > >
> > > Make support for Xilinx boards more generic, making it easier
> > > to add new boards. Add initial support for xupv2p and ml410 boards.
> >
> > I really think we shouldn't add stuff to arch/ppc at this point,
> > it has been deprecated for over two years now.
>
> This is a good point...  In fact the other patch (although tiny) is
> more important, since it affects drivers, which should work in
> arch/powerpc.  Thanks for the feedback anyway!
>
> On this topic: has anyone tried using the recent Walnut patches for
> arch/powerpc?   I briefly took a look at starting to port the Virtex
> support to arch/powerpc but I'm a bit lost as to where to start... :)

I plan to start hacking on it this week if things go well.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[Grant Likely]

On 8/6/07, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 07 August 2007, Wolfgang Reissnegger wrote:
> >
> > Make support for Xilinx boards more generic, making it easier
> > to add new boards. Add initial support for xupv2p and ml410 boards.
>
> I really think we shouldn't add stuff to arch/ppc at this point,
> it has been deprecated for over two years now.

Naahh, this is pretty benign stuff.  I say let it go in.  :-)

These changes are low risk and they don't hurt anything.  If Virtex
support worked in arch/powerpc then I'd agree, but for now it allows
us to keep the virtex device driver support somewhat current.

>
> > --- a/arch/ppc/platforms/4xx/virtex.h
> > +++ b/arch/ppc/platforms/4xx/virtex.h
> > @@ -31,5 +31,14 @@ extern const char* virtex_machine_name;
> > #define PPC4xx_ONB_IO_VADDR0u
> > #define PPC4xx_ONB_IO_SIZE0u
> >
> > +
> > +#if defined(CONFIG_XILINX_VIRTEX_II_PRO)
> > +#define XILINX_ARCH "Virtex-II Pro"
> > +#elif defined(CONFIG_XILINX_VIRTEX_4_FX)
> > +#define XILINX_ARCH "Virtex-4 FX"
> > +#else
> > +#error "No Xilinx Architecture recognized."
> > +#endif
> > +
> > #endif/* __ASM_VIRTEX_H__ */
> > #endif/* __KERNEL__ */
>
> When you move over to arch/powerpc, you can't do it this way, because
> that prevents you from building a multiplatform kernel.
>
> Every macro and global function that gets defined must be able to coexist
> with others that are enabled by nonexclusive configuration options.
>
> > +#if defined(CONFIG_XILINX_ML300)
> > +const char *virtex_machine_name = "Xilinx ML300";
> > +#elif defined(CONFIG_XILINX_XUPV2P)
> > +const char *virtex_machine_name = "Xilinx XUPV2P";
> > +#elif defined(CONFIG_XILINX_ML40x)
> > +const char *virtex_machine_name = "Xilinx ML40x";
> > +#elif defined(CONFIG_XILINX_ML41x)
> > +const char *virtex_machine_name = "Xilinx ML41x";
> > +#else
> > +const char *virtex_machine_name = "Unknown Xilinx with PowerPC";
> > +#endif
>
> same here.
>
> > +
> > +
> > +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> > +static volatile unsigned *powerdown_base =
> > + (volatile unsigned *) XPAR_POWER_0_POWERDOWN_BASEADDR;
>
> volatile is a bug. This needs to be __iomem, and the address probably
> needs to come from of_iomap() or a similar function.

Ugh; this is an old bug that they just copied.  I'll submit a fix for
the original code.

>
> > +static void
> > +xilinx_power_off(void)
> > +{
> > +local_irq_disable();
> > +out_be32(powerdown_base, XPAR_POWER_0_POWERDOWN_VALUE);
> > +while (1) ;
> > +}
> > +#endif
>
> You should run 'sparse' on your code before submitting patches. That
> would have caught this bug in the out_be32() instruction that expects
> an __iomem pointer.
>
> > +
> > +void __init
> > +xilinx_generic_ppc_map_io(void)
> > +{
> > +ppc4xx_map_io();
> > +
> > +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> > +powerdown_base = ioremap((unsigned long) powerdown_base,
> > + XPAR_POWER_0_POWERDOWN_HIGHADDR -
> > + XPAR_POWER_0_POWERDOWN_BASEADDR + 1);
> > +#endif
> > +}
>
> It's a rather unconventional way of working with the addresses.
> You should never use a single variable for pointers going to
> two different address spaces (physical and kernel virtual in this
> case).

Double ewh; this is also a cloned bug.

>
> > +void __init
> > +xilinx_generic_ppc_setup_arch(void)
> > +{
> > +virtex_early_serial_map();
>
> Use legacy_serial/of_serial to do this, with proper device tree entries.
>
> > +
> > +int virtex_device_fixup(struct platform_device *dev)
> > +{
> > + int i;
> > +#ifdef XPAR_ONEWIRE_0_BASEADDR
> > + /* Use the Silicon Serial ID attached on the onewire bus to */
> > + /* generate sensible MAC addresses. */
> > + unsigned char *pOnewire = ioremap(XPAR_ONEWIRE_0_BASEADDR, 6);
> > + struct xemac_platform_data *pdata = dev->dev.platform_data;
> > + if (strcmp(dev->name, "xilinx_emac") == 0) {
>
> This is heavily whitespace damaged, use tabs for indentation instead
> of spaces.
>
> > diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > index 01aa043..34d9844 100644
> > --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > @@ -15,8 +15,12 @@
> >
> > #if defined(CONFIG_XILINX_ML300)
> > #include "xparameters_ml300.h"
> > +#elif defined(CONFIG_XILINX_XUPV2P)
> > + #include "xparameters_xupv2p.h"
> > #elif defined(CONFIG_XILINX_ML403)
> > #include "xparameters_ml403.h"
> > +#elif defined(CONFIG_XILINX_ML41x)
> > + #include "xparameters_ml41x.h"
> > #else
> > /* Add other board xparameter includes here before the #else */
> > #error No xparameters_*.h file included
>
> see comment above.

This whole xparams stuff is a special case; but it is going away for
arch/powerpc.  xparameters.h is generated by the xilinx EDK tool and
it is painful to work with in the Linux context.  For arch/powerpc,
I've got a tool that generates a device tree from the FPGA hardware
design.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEX board support]

[Koss, Mike (Mission Systems)]

<<SNIPPAGE>>
> > > diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h=20
> > > b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > index 01aa043..34d9844 100644
> > > --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > @@ -15,8 +15,12 @@
> > >
> > > #if defined(CONFIG_XILINX_ML300)
> > > #include "xparameters_ml300.h"
> > > +#elif defined(CONFIG_XILINX_XUPV2P)  #include=20
> > > +"xparameters_xupv2p.h"
> > > #elif defined(CONFIG_XILINX_ML403)
> > > #include "xparameters_ml403.h"
> > > +#elif defined(CONFIG_XILINX_ML41x)
> > > + #include "xparameters_ml41x.h"
> > > #else
> > > /* Add other board xparameter includes here before the #else */=20
> > > #error No xparameters_*.h file included
> >
> > see comment above.

> This whole xparams stuff is a special case; but it is going away for
arch/powerpc.  xparameters.h is generated by the xilinx EDK tool and it
is painful to work with in the Linux context.  For arch/powerpc, I've
got a tool that generates a device tree from the FPGA hardware design.

What is the tool that you are using and are you willing to share it at
this point? I'm currently working on some code to generate platform
files for our internal drivers and the ll_temac vs using the ugle
xparam's file. I'd like to not duplicate, or actually assist, any effort
in this area.

-- Mike Koss

Re: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEX board support]

[Grant Likely]

On 8/10/07, Koss, Mike (Mission Systems) <mike.koss@ngc.com> wrote:
>
> <<SNIPPAGE>>
> > > > diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > > b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > > index 01aa043..34d9844 100644
> > > > --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > > +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > > @@ -15,8 +15,12 @@
> > > >
> > > > #if defined(CONFIG_XILINX_ML300)
> > > > #include "xparameters_ml300.h"
> > > > +#elif defined(CONFIG_XILINX_XUPV2P)  #include
> > > > +"xparameters_xupv2p.h"
> > > > #elif defined(CONFIG_XILINX_ML403)
> > > > #include "xparameters_ml403.h"
> > > > +#elif defined(CONFIG_XILINX_ML41x)
> > > > + #include "xparameters_ml41x.h"
> > > > #else
> > > > /* Add other board xparameter includes here before the #else */
> > > > #error No xparameters_*.h file included
> > >
> > > see comment above.
>
> > This whole xparams stuff is a special case; but it is going away for
> arch/powerpc.  xparameters.h is generated by the xilinx EDK tool and it
> is painful to work with in the Linux context.  For arch/powerpc, I've
> got a tool that generates a device tree from the FPGA hardware design.
>
> What is the tool that you are using and are you willing to share it at
> this point? I'm currently working on some code to generate platform
> files for our internal drivers and the ll_temac vs using the ugle
> xparam's file. I'd like to not duplicate, or actually assist, any effort
> in this area.

It's on my git tree; http://git.secretlab.ca

I've also got some feedback from the Xilinx folks in the form of a
patch, but I haven't integrated it yet.  Pretty experimental stuff,
I'll probably end up rewriting it from scratch before it's done.

Cheers,
g.

>
> -- Mike Koss
>
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

RE: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEX boardsupport]

[Stephen Neuendorffer]

The main thing that Grant's script lacks is the ability to pull in
default
parameters that aren't listed in the MPD for a core, but not in the MHS
file...
I think the only way to easily solve that is to live within EDK's bsp
generation, unfortunately...

BTW: I'm currently hacking away to see if I can get a microblaze system
booting
using a flat device tree...  I haven't decided if it's worth it to go
that
route in the end yet, but...

Steve

> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
labs.org] On Behalf Of Grant Likely
> Sent: Friday, August 10, 2007 6:48 AM
> To: Koss, Mike (Mission Systems)
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Device Tree tool [was RE: [PATCH] Consolidate=20
> XILINX_VIRTEX boardsupport]
>=20
> On 8/10/07, Koss, Mike (Mission Systems) <mike.koss@ngc.com> wrote:
> >
> > <<SNIPPAGE>>
> > > > > diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > > > b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > > > index 01aa043..34d9844 100644
> > > > > --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > > > +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> > > > > @@ -15,8 +15,12 @@
> > > > >
> > > > > #if defined(CONFIG_XILINX_ML300)
> > > > > #include "xparameters_ml300.h"
> > > > > +#elif defined(CONFIG_XILINX_XUPV2P)  #include
> > > > > +"xparameters_xupv2p.h"
> > > > > #elif defined(CONFIG_XILINX_ML403)
> > > > > #include "xparameters_ml403.h"
> > > > > +#elif defined(CONFIG_XILINX_ML41x)
> > > > > + #include "xparameters_ml41x.h"
> > > > > #else
> > > > > /* Add other board xparameter includes here before=20
> the #else */
> > > > > #error No xparameters_*.h file included
> > > >
> > > > see comment above.
> >
> > > This whole xparams stuff is a special case; but it is=20
> going away for
> > arch/powerpc.  xparameters.h is generated by the xilinx EDK=20
> tool and it
> > is painful to work with in the Linux context.  For=20
> arch/powerpc, I've
> > got a tool that generates a device tree from the FPGA=20
> hardware design.
> >
> > What is the tool that you are using and are you willing to=20
> share it at
> > this point? I'm currently working on some code to generate platform
> > files for our internal drivers and the ll_temac vs using the ugle
> > xparam's file. I'd like to not duplicate, or actually=20
> assist, any effort
> > in this area.
>=20
> It's on my git tree; http://git.secretlab.ca
>=20
> I've also got some feedback from the Xilinx folks in the form of a
> patch, but I haven't integrated it yet.  Pretty experimental stuff,
> I'll probably end up rewriting it from scratch before it's done.
>=20
> Cheers,
> g.
>=20
> >
> > -- Mike Koss
> >
> >
>=20
>=20
> --=20
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20

RE: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEXboardsupport]

[Stephen Neuendorffer]

> BTW: I'm currently hacking away to see if I can get a=20
> microblaze system
> booting
> using a flat device tree...  I haven't decided if it's worth it to go
> that
> route in the end yet, but...
>=20
> Steve

I've managed to get the first step working: a microblaze system
advertising of_devices in 2.6 using a flat device tree.  The next task
is to
reimplement probe() for a driver or two (probably the xilinx_emac driver
first).   My plan is to have the driver advertise both through
of_platform_bus, and
through the regular platform bus, and have a config option that either
advertises
the devices through of and links in the device tree, or using the
exising
platform_device mechanism.

Grant:  Does this make sense (in terms of dealing with drivers) with
your plans for
moving Virtex platforms to arch/powerpc?  I'd like to avoid duplicating
work on the
drivers, if possible.

Is there a concensus on how microblaze systems should get booted?
Currently,
I'm linking the device tree directly into the kernel itself, loading the
whole
mess using SystemAce and the start address jumps directly into the
kernel, which
is quite a bit different than the way powerpc works.  It's certainly
simpler:
maybe too simple.  At the same time, replicating
the complexity of arch/powerpc with separate boot code may or may not be
worth it...
Any thoughts?

Steve

RE: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEXboardsupport]

[Michal Simek]

Hi,

>I've managed to get the first step working: a microblaze system
>advertising of_devices in 2.6 using a flat device tree.  

It's great news.

>Is there a concensus on how microblaze systems should get booted?
>Currently,
>I'm linking the device tree directly into the kernel itself, loading the
>whole
>mess using SystemAce and the start address jumps directly into the
>kernel, which
>is quite a bit different than the way powerpc works.  It's certainly
>simpler:
>maybe too simple.  At the same time, replicating
>the complexity of arch/powerpc with separate boot code may or may not be
>worth it...
>Any thoughts?

Microblaze can be boot via U-BOOT. U-BOOT supports FDT for some PowerPC boards.
I would like to help with this part of bootloader code. 

Do you have any EDK script for generation FDT? 

Best regards,
Michal Simek

RE: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEXboardsupport]

[Stephen Neuendorffer]

I don't have an EDK script.  I'm currently using a hacked version of=20
Grant's gen_mhs_devtree.py script, and then I modified the resulting
device
tree in an effort to get things working.  In the long term, I think
having
an EDK script will be necessary to ensure that all of the information is
in the device tree.

Michal: what do you need from me?

Steve

> -----Original Message-----
> From: Michal Simek [mailto:Monstr@seznam.cz]=20
> Sent: Tuesday, August 14, 2007 11:42 PM
> To: Stephen Neuendorffer
> Cc: Grant Likely; microblaze-uclinux@itee.uq.edu.au;=20
> linuxppc-embedded@ozlabs.org
> Subject: RE: Device Tree tool [was RE: [PATCH] Consolidate=20
> XILINX_VIRTEXboardsupport]
>=20
> Hi,
>=20
> >I've managed to get the first step working: a microblaze system
> >advertising of_devices in 2.6 using a flat device tree. =20
>=20
> It's great news.
>=20
> >Is there a concensus on how microblaze systems should get booted?
> >Currently,
> >I'm linking the device tree directly into the kernel itself,=20
> loading the
> >whole
> >mess using SystemAce and the start address jumps directly into the
> >kernel, which
> >is quite a bit different than the way powerpc works.  It's certainly
> >simpler:
> >maybe too simple.  At the same time, replicating
> >the complexity of arch/powerpc with separate boot code may=20
> or may not be
> >worth it...
> >Any thoughts?
>=20
> Microblaze can be boot via U-BOOT. U-BOOT supports FDT for=20
> some PowerPC boards.
> I would like to help with this part of bootloader code.=20
>=20
> Do you have any EDK script for generation FDT?=20
>=20
> Best regards,
> Michal Simek
>=20
>=20

Re: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEXboardsupport]

[Grant Likely]

On 8/14/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> > BTW: I'm currently hacking away to see if I can get a
> > microblaze system
> > booting
> > using a flat device tree...  I haven't decided if it's worth it to go
> > that
> > route in the end yet, but...
> >
> > Steve
>
> I've managed to get the first step working: a microblaze system
> advertising of_devices in 2.6 using a flat device tree.  The next task
> is to
> reimplement probe() for a driver or two (probably the xilinx_emac driver
> first).   My plan is to have the driver advertise both through
> of_platform_bus, and
> through the regular platform bus, and have a config option that either
> advertises
> the devices through of and links in the device tree, or using the
> exising
> platform_device mechanism.

That's fantastic.  Yes, I think that is the right approach to have
both platform_bus and of_platform bus bindings in the drivers.

>
> Grant:  Does this make sense (in terms of dealing with drivers) with
> your plans for
> moving Virtex platforms to arch/powerpc?  I'd like to avoid duplicating
> work on the
> drivers, if possible.

Absolutely

>
> Is there a concensus on how microblaze systems should get booted?
> Currently,
> I'm linking the device tree directly into the kernel itself, loading the
> whole
> mess using SystemAce and the start address jumps directly into the
> kernel, which
> is quite a bit different than the way powerpc works.  It's certainly
> simpler:
> maybe too simple.  At the same time, replicating
> the complexity of arch/powerpc with separate boot code may or may not be
> worth it...
> Any thoughts?

It is a good starting point, and I think it is important that this
remain an option (ie. for boards without a bootloader).  However, it
is a really good idea to support the notion of passing in a device
tree from a bootloader (u-boot).  As Michal mentioned, u-boot already
has the code to support this, and u-boot is able to update the device
tree directly.  The key feature here is being able to support multiple
FPGA designs from a single kernel image because the device tree gives
us some level of abstraction on the hardware design.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[Kumar Gala]

On Aug 9, 2007, at 1:54 PM, Grant Likely wrote:

> On 8/6/07, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tuesday 07 August 2007, Wolfgang Reissnegger wrote:
>>>
>>> Make support for Xilinx boards more generic, making it easier
>>> to add new boards. Add initial support for xupv2p and ml410 boards.
>>
>> I really think we shouldn't add stuff to arch/ppc at this point,
>> it has been deprecated for over two years now.
>
> Naahh, this is pretty benign stuff.  I say let it go in.  :-)
>
> These changes are low risk and they don't hurt anything.  If Virtex
> support worked in arch/powerpc then I'd agree, but for now it allows
> us to keep the virtex device driver support somewhat current.

We've clearly stated for a while that only bug fixes should be going  
into arch/ppc.  This looks like new board support.

Also, be aware that arch/ppc is going away in Jun 2008. :)

- k

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[Grant Likely]

On 8/10/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Aug 9, 2007, at 1:54 PM, Grant Likely wrote:
>
> > On 8/6/07, Arnd Bergmann <arnd@arndb.de> wrote:
> > Naahh, this is pretty benign stuff.  I say let it go in.  :-)
> >
> > These changes are low risk and they don't hurt anything.  If Virtex
> > support worked in arch/powerpc then I'd agree, but for now it allows
> > us to keep the virtex device driver support somewhat current.
>
> We've clearly stated for a while that only bug fixes should be going
> into arch/ppc.  This looks like new board support.
>
> Also, be aware that arch/ppc is going away in Jun 2008. :)

So it only lives in the tree for 10 months time, big deal.  :-)  For
those who are need it, it allows them to participate without having to
do the heavy lifting of getting Virtex support into arch/powerpc.  It
also allow device driver development to progress on those boards in
the mean time.

Besides there is almost no new code in these changes.  The largest
part of the patch is a copy of older code (which I NAKed).  The other
changes are no big deal.

That being said, those excuses are *no* *bloody* *good* for folks like
me who *should* be getting virtex support into arch/powerpc.  :-)

Also, the moment it is viable to add new Virtex board ports to
arch/powerpc I will change my tune and agree 100% with you.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[Peter Korsgaard]

>>>>> "WR" == Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> writes:

Hi,

WR> diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
WR> index 5b87779..05631fe 100644
WR> --- a/arch/ppc/boot/simple/Makefile
WR> +++ b/arch/ppc/boot/simple/Makefile
WR> @@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6)	+= embed_config.o
WR>  boot-$(CONFIG_8xx)		+= embed_config.o
WR>  boot-$(CONFIG_8260)		+= embed_config.o
WR>  boot-$(CONFIG_EP405)		+= embed_config.o
WR> -boot-$(CONFIG_XILINX_ML300)	+= embed_config.o
WR> -boot-$(CONFIG_XILINX_ML403)	+= embed_config.o
WR> +boot-$(CONFIG_XILINX_VIRTEX)	+= embed_config.o

Don't do that. Other boards with Xilinx FPGAs don't necessarily need
embed_config.c

WR>  boot-$(CONFIG_BSEIP)		+= iic.o
WR>  boot-$(CONFIG_MBX)		+= iic.o pci.o qspan_pci.o
WR>  boot-$(CONFIG_MV64X60)		+= misc-mv64x60.o
WR> diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
WR> index 840bff2..e0b8954 100644
WR> --- a/arch/ppc/boot/simple/embed_config.c
WR> +++ b/arch/ppc/boot/simple/embed_config.c
WR> @@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
WR>  }
WR>  #endif /* WILLOW */
 
WR> -#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
WR> +#if defined(CONFIG_XILINX_VIRTEX)
WR>  void
WR>  embed_config(bd_t ** bdp)

.. And if they do, they might have another embed_config (E.G. if the
bootloader provides a valid struct bd_t).

-- 
Bye, Peter Korsgaard

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[Peter Korsgaard]

>>>>> "WR" == Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> writes:

Hi,

WR> diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
WR> index 5b87779..05631fe 100644
WR> --- a/arch/ppc/boot/simple/Makefile
WR> +++ b/arch/ppc/boot/simple/Makefile
WR> @@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6)	+= embed_config.o
WR>  boot-$(CONFIG_8xx)		+= embed_config.o
WR>  boot-$(CONFIG_8260)		+= embed_config.o
WR>  boot-$(CONFIG_EP405)		+= embed_config.o
WR> -boot-$(CONFIG_XILINX_ML300)	+= embed_config.o
WR> -boot-$(CONFIG_XILINX_ML403)	+= embed_config.o
WR> +boot-$(CONFIG_XILINX_VIRTEX)	+= embed_config.o

Don't do that. Other boards with Xilinx FPGAs don't necessarily need
embed_config.c

WR>  boot-$(CONFIG_BSEIP)		+= iic.o
WR>  boot-$(CONFIG_MBX)		+= iic.o pci.o qspan_pci.o
WR>  boot-$(CONFIG_MV64X60)		+= misc-mv64x60.o
WR> diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
WR> index 840bff2..e0b8954 100644
WR> --- a/arch/ppc/boot/simple/embed_config.c
WR> +++ b/arch/ppc/boot/simple/embed_config.c
WR> @@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
WR>  }
WR>  #endif /* WILLOW */
 
WR> -#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
WR> +#if defined(CONFIG_XILINX_VIRTEX)
WR>  void
WR>  embed_config(bd_t ** bdp)

.. And if they do, they might have another embed_config (E.G. if the
bootloader provides a valid struct bd_t).

-- 
Bye, Peter Korsgaard

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[Grant Likely]

On 8/7/07, Peter Korsgaard <peter.korsgaard@barco.com> wrote:
> >>>>> "WR" == Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> writes:
>
> Hi,
>
> WR> diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
> WR> index 5b87779..05631fe 100644
> WR> --- a/arch/ppc/boot/simple/Makefile
> WR> +++ b/arch/ppc/boot/simple/Makefile
> WR> @@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6)        += embed_config.o
> WR>  boot-$(CONFIG_8xx)         += embed_config.o
> WR>  boot-$(CONFIG_8260)                += embed_config.o
> WR>  boot-$(CONFIG_EP405)               += embed_config.o
> WR> -boot-$(CONFIG_XILINX_ML300)        += embed_config.o
> WR> -boot-$(CONFIG_XILINX_ML403)        += embed_config.o
> WR> +boot-$(CONFIG_XILINX_VIRTEX)       += embed_config.o
>
> Don't do that. Other boards with Xilinx FPGAs don't necessarily need
> embed_config.c

Then post patches for those boards so we can properly support the
different configuration.

>
> WR>  boot-$(CONFIG_BSEIP)               += iic.o
> WR>  boot-$(CONFIG_MBX)         += iic.o pci.o qspan_pci.o
> WR>  boot-$(CONFIG_MV64X60)             += misc-mv64x60.o
> WR> diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
> WR> index 840bff2..e0b8954 100644
> WR> --- a/arch/ppc/boot/simple/embed_config.c
> WR> +++ b/arch/ppc/boot/simple/embed_config.c
> WR> @@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
> WR>  }
> WR>  #endif /* WILLOW */
>
> WR> -#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
> WR> +#if defined(CONFIG_XILINX_VIRTEX)
> WR>  void
> WR>  embed_config(bd_t ** bdp)
>
> .. And if they do, they might have another embed_config (E.G. if the
> bootloader provides a valid struct bd_t).
>
> --
> Bye, Peter Korsgaard
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[Peter Korsgaard]

>>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:

Hi,

WR> -boot-$(CONFIG_XILINX_ML300)        += embed_config.o
WR> -boot-$(CONFIG_XILINX_ML403)        += embed_config.o
WR> +boot-$(CONFIG_XILINX_VIRTEX)       += embed_config.o
>> 
>> Don't do that. Other boards with Xilinx FPGAs don't necessarily need
>> embed_config.c

GL> Then post patches for those boards so we can properly support the
GL> different configuration.

Also if the boards are not generally available? No problem for me, but
I don't quite see the point.

-- 
Bye, Peter Korsgaard

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[Grant Likely]

On 8/10/07, Peter Korsgaard <peter.korsgaard@barco.com> wrote:
> >>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
>
> Hi,
>
> WR> -boot-$(CONFIG_XILINX_ML300)        += embed_config.o
> WR> -boot-$(CONFIG_XILINX_ML403)        += embed_config.o
> WR> +boot-$(CONFIG_XILINX_VIRTEX)       += embed_config.o
> >>
> >> Don't do that. Other boards with Xilinx FPGAs don't necessarily need
> >> embed_config.c
>
> GL> Then post patches for those boards so we can properly support the
> GL> different configuration.
>
> Also if the boards are not generally available? No problem for me, but
> I don't quite see the point.

GregKH likes to tell the story of one architecture that is actively
maintained, but only has about 2 users total.  The point isn't how
available the hardware is; the point is to see how others are using
the code.  Having a larger base of platform support to draw from makes
it easier to recognize patterns in the code which

Or, from a more selfish perspective; It's one thing to say "this
will/won't work because of that platform over there that you can't
see", and quite another to show the code and say "this is what I need
to do".  If you get your code merged, it is easier to influence the
design direction.  ie. you can say "Don't do that; you'll break this
supported board!"  :-)

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[David H. Lynch Jr.]

arch/boot/simple/embed_config.c jusst seems to be a random collection of 
board specific code anyway.
A giant case statement implimented with #ifdef's. It is just screaming 
to be done some better way.

Peter Korsgaard wrote:
>>>>>> "WR" == Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> writes:
>>>>>>             
>
> Hi,
>
> WR> diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
> WR> index 5b87779..05631fe 100644
> WR> --- a/arch/ppc/boot/simple/Makefile
> WR> +++ b/arch/ppc/boot/simple/Makefile
> WR> @@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6)	+= embed_config.o
> WR>  boot-$(CONFIG_8xx)		+= embed_config.o
> WR>  boot-$(CONFIG_8260)		+= embed_config.o
> WR>  boot-$(CONFIG_EP405)		+= embed_config.o
> WR> -boot-$(CONFIG_XILINX_ML300)	+= embed_config.o
> WR> -boot-$(CONFIG_XILINX_ML403)	+= embed_config.o
> WR> +boot-$(CONFIG_XILINX_VIRTEX)	+= embed_config.o
>
> Don't do that. Other boards with Xilinx FPGAs don't necessarily need
> embed_config.c
>
> WR>  boot-$(CONFIG_BSEIP)		+= iic.o
> WR>  boot-$(CONFIG_MBX)		+= iic.o pci.o qspan_pci.o
> WR>  boot-$(CONFIG_MV64X60)		+= misc-mv64x60.o
> WR> diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
> WR> index 840bff2..e0b8954 100644
> WR> --- a/arch/ppc/boot/simple/embed_config.c
> WR> +++ b/arch/ppc/boot/simple/embed_config.c
> WR> @@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
> WR>  }
> WR>  #endif /* WILLOW */
>  
> WR> -#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
> WR> +#if defined(CONFIG_XILINX_VIRTEX)
> WR>  void
> WR>  embed_config(bd_t ** bdp)
>
> .. And if they do, they might have another embed_config (E.G. if the
> bootloader provides a valid struct bd_t).
>
>   


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[Josh Boyer]

On Sat, 18 Aug 2007 21:34:43 -0400
"David H. Lynch Jr." <dhlii@dlasys.net> wrote:

> arch/boot/simple/embed_config.c jusst seems to be a random collection
> of board specific code anyway.
> A giant case statement implimented with #ifdef's. It is just
> screaming to be done some better way.

You mean like a device tree?  ;)

josh

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[David H. Lynch Jr.]

Josh Boyer wrote:
>> arch/boot/simple/embed_config.c jusst seems to be a random collection
>> of board specific code anyway.
>> A giant case statement implimented with #ifdef's. It is just
>> screaming to be done some better way.

>>
>> You mean like a device tree?  ;)
>>
>> josh
>>     
Maybe, I am waiting to see somebody move something to device tree so 
that I can get a better grasp of what it is and how it works.
 From what little I know I think it is going to be very significant for 
my BSP - we are trying to use a single binary for alot of different
boards, or the same board with different firmware. From what I am 
gathering I can have the loader pass a device tree to the kernel
and the device tree will basically describe the hardware to the kernel.

Only at the moment I don't have the time to learn enough to attempt to 
lead the charge moving xilinx stuff to powerpc.

Is there a way to do this in small peices ?

It would be nice to end some of the debate on how to setup ppc/4xx for 
multiple xilinx targets and just get it over with and move to powerpc
device tree, ...
But I can't beat others up for what I can't find time for myself.


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[Grant Likely]

On 8/6/07, Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> wrote:
> Make support for Xilinx boards more generic, making it easier
> to add new boards.  Add initial support for xupv2p and ml410 boards.
>
> Thanks,
>    Wolfgang
>
>
> Signed-off-by: Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>

Comments below...

> ---
>  arch/ppc/boot/simple/Makefile                      |    3 +-
>  arch/ppc/boot/simple/embed_config.c                |    4 +-
>  arch/ppc/platforms/4xx/Kconfig                     |   15 +
>  arch/ppc/platforms/4xx/Makefile                    |    2 +
>  arch/ppc/platforms/4xx/virtex.h                    |    9 +
>  arch/ppc/platforms/4xx/xilinx_generic_ppc.c        |  129 ++++++++
>  arch/ppc/platforms/4xx/xilinx_xupv2p.c             |   43 +++
>  arch/ppc/platforms/4xx/xparameters/xparameters.h   |    4 +
>  .../platforms/4xx/xparameters/xparameters_ml41x.h  |  277 +++++++++++++++++
>  .../platforms/4xx/xparameters/xparameters_xupv2p.h |  327 ++++++++++++++++++++
>  10 files changed, 809 insertions(+), 4 deletions(-)
>  create mode 100644 arch/ppc/platforms/4xx/xilinx_generic_ppc.c
>  create mode 100644 arch/ppc/platforms/4xx/xilinx_xupv2p.c
>  create mode 100644 arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h
>  create mode 100644 arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h
>
> diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
> index 5b87779..05631fe 100644
> --- a/arch/ppc/boot/simple/Makefile
> +++ b/arch/ppc/boot/simple/Makefile
> @@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6)    += embed_config.o
>  boot-$(CONFIG_8xx)             += embed_config.o
>  boot-$(CONFIG_8260)            += embed_config.o
>  boot-$(CONFIG_EP405)           += embed_config.o
> -boot-$(CONFIG_XILINX_ML300)    += embed_config.o
> -boot-$(CONFIG_XILINX_ML403)    += embed_config.o
> +boot-$(CONFIG_XILINX_VIRTEX)   += embed_config.o
>  boot-$(CONFIG_BSEIP)           += iic.o
>  boot-$(CONFIG_MBX)             += iic.o pci.o qspan_pci.o
>  boot-$(CONFIG_MV64X60)         += misc-mv64x60.o
> diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
> index 840bff2..e0b8954 100644
> --- a/arch/ppc/boot/simple/embed_config.c
> +++ b/arch/ppc/boot/simple/embed_config.c
> @@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
>  }
>  #endif /* WILLOW */
>
> -#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
> +#if defined(CONFIG_XILINX_VIRTEX)

You need to rebase your patch to mainline.  This change has already been applied

>  void
>  embed_config(bd_t ** bdp)
>  {
> @@ -781,7 +781,7 @@ embed_config(bd_t ** bdp)
>         timebase_period_ns = 1000000000 / bd->bi_tbfreq;
>         /* see bi_tbfreq definition in arch/ppc/platforms/4xx/xilinx_ml300.h */
>  }
> -#endif /* CONFIG_XILINX_ML300 || CONFIG_XILINX_ML403 */
> +#endif /* CONFIG_XILINX_VIRTEX */

ditto

>
>  #ifdef CONFIG_IBM_OPENBIOS
>  /* This could possibly work for all treeboot roms.
> diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
> index d7db7e4..56965cb 100644
> --- a/arch/ppc/platforms/4xx/Kconfig
> +++ b/arch/ppc/platforms/4xx/Kconfig
> @@ -60,12 +60,27 @@ config XILINX_ML300
>         help
>           This option enables support for the Xilinx ML300 evaluation board.
>
> +config XILINX_XUPV2P
> +       bool "Xilinx-XUPV2P"
> +       select XILINX_VIRTEX_II_PRO
> +       select EMBEDDEDBOOT
> +       help
> +         This option enables support for the Xilinx University Program (XUP) Virtex 2 Pro 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.
> +
> +config XILINX_ML41x
> +       bool "Xilinx-ML41x"
> +       select XILINX_VIRTEX_4_FX
> +       select EMBEDDEDBOOT
> +       help
> +         This option enables support for the Xilinx ML410/411 evaluation boards.
> +
>  endchoice
>
>  choice
> diff --git a/arch/ppc/platforms/4xx/Makefile b/arch/ppc/platforms/4xx/Makefile
> index 723ad79..bcf1a63 100644
> --- a/arch/ppc/platforms/4xx/Makefile
> +++ b/arch/ppc/platforms/4xx/Makefile
> @@ -15,7 +15,9 @@ obj-$(CONFIG_SYCAMORE)                += sycamore.o
>  obj-$(CONFIG_TAISHAN)          += taishan.o
>  obj-$(CONFIG_WALNUT)           += walnut.o
>  obj-$(CONFIG_XILINX_ML300)     += xilinx_ml300.o
> +obj-$(CONFIG_XILINX_XUPV2P)    += xilinx_generic_ppc.o xilinx_xupv2p.o
>  obj-$(CONFIG_XILINX_ML403)     += xilinx_ml403.o
> +obj-$(CONFIG_XILINX_ML41x)     += xilinx_generic_ppc.o
>
>  obj-$(CONFIG_405GP)            += ibm405gp.o
>  obj-$(CONFIG_REDWOOD_5)                += ibmstb4.o
> diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virtex.h
> index 7382804..47f67b3 100644
> --- a/arch/ppc/platforms/4xx/virtex.h
> +++ b/arch/ppc/platforms/4xx/virtex.h
> @@ -31,5 +31,14 @@ extern const char* virtex_machine_name;
>  #define PPC4xx_ONB_IO_VADDR    0u
>  #define PPC4xx_ONB_IO_SIZE     0u
>
> +
> +#if defined(CONFIG_XILINX_VIRTEX_II_PRO)
> +#define XILINX_ARCH "Virtex-II Pro"
> +#elif defined(CONFIG_XILINX_VIRTEX_4_FX)
> +#define XILINX_ARCH "Virtex-4 FX"
> +#else
> +#error "No Xilinx Architecture recognized."
> +#endif
> +

XILINX_ARCH is used in exactly *one* place; I wouldn't add it to the
header file.

>  #endif                         /* __ASM_VIRTEX_H__ */
>  #endif                         /* __KERNEL__ */
> diff --git a/arch/ppc/platforms/4xx/xilinx_generic_ppc.c b/arch/ppc/platforms/4xx/xilinx_generic_ppc.c

This is a clone of arch/ppc/platforms/4xx/xilinx_ml300.c and
xilinx_ml403.c; yet you don't remove the old files or consolidate
ml300 and ml403 to use them.  You should separate this change into a
separate patch that just consolidates the xilinx_ml300 & xilinx_ml403,
and then add the other boards in a second patch.

BTW, if you do so, you should add '__attribute ((weak))' to the
definition of platform_init so it can be overridden when needed.

> new file mode 100644
> index 0000000..103e762
> --- /dev/null
> +++ b/arch/ppc/platforms/4xx/xilinx_generic_ppc.c
> @@ -0,0 +1,129 @@
> +/*
> + * Xilinx Generic PPC evaluation board initialization
> + *
> + * 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.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/irq.h>
> +#include <linux/tty.h>
> +#include <linux/serial.h>
> +#include <linux/serial_core.h>
> +#include <linux/serial_8250.h>
> +#include <linux/serialP.h>
> +#include <linux/io.h>
> +#include <asm/machdep.h>
> +
> +#include <syslib/gen550.h>
> +#include <syslib/virtex_devices.h>
> +#include <platforms/4xx/xparameters/xparameters.h>
> +
> +/*
> + * As an overview of how the following functions (platform_init,
> + * xilinx_generic_ppc_map_io, xilinx_generic_ppc_setup_arch and xilinx_generic_ppc_init_IRQ) fit into the
> + * kernel startup procedure, here's a call tree:
> + *
> + * start_here                                  arch/ppc/kernel/head_4xx.S
> + *  early_init                                 arch/ppc/kernel/setup.c
> + *  machine_init                               arch/ppc/kernel/setup.c
> + *    platform_init                            this file
> + *      ppc4xx_init                            arch/ppc/syslib/ppc4xx_setup.c
> + *        parse_bootinfo
> + *          find_bootinfo
> + *        "setup some default ppc_md pointers"
> + *  MMU_init                                   arch/ppc/mm/init.c
> + *    *ppc_md.setup_io_mappings == xilinx_generic_ppc_map_io   this file
> + *      ppc4xx_map_io                          arch/ppc/syslib/ppc4xx_setup.c
> + *  start_kernel                               init/main.c
> + *    setup_arch                               arch/ppc/kernel/setup.c
> + * #if defined(CONFIG_KGDB)
> + *      *ppc_md.kgdb_map_scc() == gen550_kgdb_map_scc
> + * #endif
> + *      *ppc_md.setup_arch == xilinx_generic_ppc_setup_arch    this file
> + *        ppc4xx_setup_arch                    arch/ppc/syslib/ppc4xx_setup.c
> + *          ppc4xx_find_bridges                        arch/ppc/syslib/ppc405_pci.c
> + *    init_IRQ                                 arch/ppc/kernel/irq.c
> + *      *ppc_md.init_IRQ == xilinx_generic_ppc_init_IRQ        this file
> + *        ppc4xx_init_IRQ                      arch/ppc/syslib/ppc4xx_setup.c
> + *          ppc4xx_pic_init                    arch/ppc/syslib/xilinx_pic.c
> + */
> +
> +#if defined(CONFIG_XILINX_ML300)
> +const char *virtex_machine_name = "Xilinx ML300";
> +#elif defined(CONFIG_XILINX_XUPV2P)
> +const char *virtex_machine_name = "Xilinx XUPV2P";
> +#elif defined(CONFIG_XILINX_ML40x)
> +const char *virtex_machine_name = "Xilinx ML40x";
> +#elif defined(CONFIG_XILINX_ML41x)
> +const char *virtex_machine_name = "Xilinx ML41x";
> +#else
> +const char *virtex_machine_name = "Unknown Xilinx with PowerPC";
> +#endif
> +
> +
> +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> +static volatile unsigned *powerdown_base =
> +    (volatile unsigned *) XPAR_POWER_0_POWERDOWN_BASEADDR;
> +
> +static void
> +xilinx_power_off(void)
> +{
> +       local_irq_disable();
> +       out_be32(powerdown_base, XPAR_POWER_0_POWERDOWN_VALUE);
> +       while (1) ;
> +}
> +#endif
> +
> +void __init
> +xilinx_generic_ppc_map_io(void)
> +{
> +       ppc4xx_map_io();
> +
> +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> +       powerdown_base = ioremap((unsigned long) powerdown_base,
> +                                XPAR_POWER_0_POWERDOWN_HIGHADDR -
> +                                XPAR_POWER_0_POWERDOWN_BASEADDR + 1);
> +#endif
> +}
> +
> +void __init
> +xilinx_generic_ppc_setup_arch(void)
> +{
> +       virtex_early_serial_map();
> +       ppc4xx_setup_arch();    /* calls ppc4xx_find_bridges() */
> +
> +       /* Identify the system */
> +       printk(KERN_INFO "Xilinx Generic PowerPC board support package (%s) (%s)\n", PPC4xx_MACHINE_NAME, XILINX_ARCH);
> +}
> +
> +/* Called after board_setup_irq from ppc4xx_init_IRQ(). */
> +void __init
> +xilinx_generic_ppc_init_irq(void)
> +{
> +       ppc4xx_init_IRQ();
> +}
> +
> +void __init
> +platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> +        unsigned long r6, unsigned long r7)
> +{
> +       ppc4xx_init(r3, r4, r5, r6, r7);
> +
> +       ppc_md.setup_arch = xilinx_generic_ppc_setup_arch;
> +       ppc_md.setup_io_mappings = xilinx_generic_ppc_map_io;
> +       ppc_md.init_IRQ = xilinx_generic_ppc_init_irq;
> +
> +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> +       ppc_md.power_off = xilinx_power_off;
> +#endif
> +
> +#ifdef CONFIG_KGDB
> +       ppc_md.early_serial_map = virtex_early_serial_map;
> +#endif
> +}
> +
> diff --git a/arch/ppc/platforms/4xx/xilinx_xupv2p.c b/arch/ppc/platforms/4xx/xilinx_xupv2p.c
> new file mode 100644
> index 0000000..aa2d890
> --- /dev/null
> +++ b/arch/ppc/platforms/4xx/xilinx_xupv2p.c
> @@ -0,0 +1,43 @@
> +/*
> + * Xilinx XUPV2P board initialization
> + *
> + * Author: Stephen.Neuendorffer@xilinx.com
> + *
> + * 2007 (c) Xilinx, 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.
> + */
> +
> +#include <linux/xilinx_devices.h>
> +#include <platforms/4xx/xparameters/xparameters.h>
> +
> +int virtex_device_fixup(struct platform_device *dev)
> +{
> + int i;

If XPAR_ONEWIRE_0_BASEADDR is not set, then the unused 'int i' will
generate a warning.

> +#ifdef XPAR_ONEWIRE_0_BASEADDR
> + /* Use the Silicon Serial ID attached on the onewire bus to */
> + /* generate sensible MAC addresses. */
> + unsigned char *pOnewire = ioremap(XPAR_ONEWIRE_0_BASEADDR, 6);

Don't use CamelCase variable names.
ioremap() with no matching iounmap()

> + struct xemac_platform_data *pdata = dev->dev.platform_data;
> + if (strcmp(dev->name, "xilinx_emac") == 0) {
> +  printk(KERN_INFO "Fixup MAC address for %s:%d\n",
> +    dev->name, dev->id);
> +  /* FIXME.. this doesn't seem to return data that is consistent */
> +  /* with the self test... why not? */

Is this ready to be committed?

> +  pdata->mac_addr[0] = 0x00;
> +  pdata->mac_addr[1] = 0x0A;
> +  pdata->mac_addr[2] = 0x35;
> +  pdata->mac_addr[3] = dev->id;
> +  pdata->mac_addr[4] = pOnewire[4];
> +  pdata->mac_addr[5] = pOnewire[5];
> +  printk(KERN_INFO "MAC address is now %2x:%2x:%2x:%2x:%2x:%2x\n",
> +   pdata->mac_addr[0],
> +   pdata->mac_addr[1],
> +   pdata->mac_addr[2],
> +   pdata->mac_addr[3],
> +   pdata->mac_addr[4],
> +   pdata->mac_addr[5]);

The printk is ambiguous because it doesn't specify which device the
MAC addr is assigned to.  I'd drop the printk (or change it to a
pr_debug) and print the MAC addr in the Eth device driver itself.
Once you're in the driver, you know which 'eth#' will be assigned.

> + }
> +#endif
> + return 0;
> +}

whitespace problems here

> diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> index 01aa043..34d9844 100644
> --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
> +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> @@ -15,8 +15,12 @@
>
>  #if defined(CONFIG_XILINX_ML300)
>    #include "xparameters_ml300.h"
> +#elif defined(CONFIG_XILINX_XUPV2P)
> +  #include "xparameters_xupv2p.h"
>  #elif defined(CONFIG_XILINX_ML403)
>    #include "xparameters_ml403.h"
> +#elif defined(CONFIG_XILINX_ML41x)
> +  #include "xparameters_ml41x.h"
>  #else
>    /* Add other board xparameter includes here before the #else */
>    #error No xparameters_*.h file included


> diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h b/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h
> diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h b/arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h

Split the addition of new xparams files into a separate patch.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: [PATCH] Consolidate XILINX_VIRTEX board support

[Grant Likely]

On 8/9/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 8/6/07, Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> wrote:
> > Make support for Xilinx boards more generic, making it easier
> > to add new boards.  Add initial support for xupv2p and ml410 boards.
> >
> > Thanks,
> >    Wolfgang
> >
> >
> > Signed-off-by: Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com>
> > Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
>
> Comments below...
>
> > diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
> > index 840bff2..e0b8954 100644
> > --- a/arch/ppc/boot/simple/embed_config.c
> > +++ b/arch/ppc/boot/simple/embed_config.c
> > @@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
> >  }
> >  #endif /* WILLOW */
> >
> > -#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
> > +#if defined(CONFIG_XILINX_VIRTEX)
>
> You need to rebase your patch to mainline.  This change has already been applied

Oops, my mistake.  This change is in my tree, but not in mainline.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Best Linux tree for Xilinx support.

[Leonid]

Hi:

I have several boards with different architectures (Microblaze, PPC),
running Linux/uClinux and using Xilinx IP cores. I use both Virtex and
Spartan FPGAs.

Historically I'm using different kernels for them, starting from uClinux
2.4, all way through Linux 2.6.16 and 2.6.19. I patched them here and
there to get working.

I certainly feel a need to move to some standard kernel tree.

I understand that you guys are in some advanced steps of integrating
Xilinx into Linux. What would be my best choice of Linux kernel now?

I see the following options:

- download some GIT tree your are using (which one?).
- get latest tree from kernel.org and patch it using your patches (where
I can get them?).
- ??

Please advise,

Thanks,

Leonid.

Re: Best Linux tree for Xilinx support.

[Wolfgang Reissnegger]

Hi Leonid,

I am in the process of publishing a Xilinx Linux git tree which will
contain most of the drivers for Xilinx IP including recent contributions
from Grant Likely, John Williams, Joachim Foerster and others.

This tree will be available on the Xilinx git server soon, however it
will be a non-supported (and likely unstable) tree. Its main purpose is
to provide a common code base for development and a channel to push new
driver code out into the community.

I am still waiting on IT to set up the new server machine. I will post
an announcement once the server is up and running.

Cheers,
   Wolfgang

Leonid wrote:
> Hi:
> 
> I have several boards with different architectures (Microblaze, PPC),
> running Linux/uClinux and using Xilinx IP cores. I use both Virtex and
> Spartan FPGAs.
> 
> Historically I'm using different kernels for them, starting from uClinux
> 2.4, all way through Linux 2.6.16 and 2.6.19. I patched them here and
> there to get working.
> 
> I certainly feel a need to move to some standard kernel tree.
> 
> I understand that you guys are in some advanced steps of integrating
> Xilinx into Linux. What would be my best choice of Linux kernel now?
> 
> I see the following options:
> 
> - download some GIT tree your are using (which one?).
> - get latest tree from kernel.org and patch it using your patches (where
> I can get them?).
> - ??
> 
> Please advise,
> 
> Thanks,
> 
> Leonid.
> 

RE: Best Linux tree for Xilinx support.

[Leonid]

Hi Wolfgang:

Thank you very much for the information. What kernel.org version your
tree is based on?

As you noticed, it will be rather reference tree to set some coding
standard, namely where files are located, how drivers are included,
etc... So, I would appreciate if I can get a glimpse of your suggested
tree structure, actual sources are not even required.

Previous support for Xilinx was more oriented toward PPC405 core in
Virtex FPGA and everything was naturally concentrated under
arch/ppc/platform/4xx.

I deem such approach is not very good one. I'm using precisely same IP
cores like GPIO, EMAC, SPI, CAN, etc... in Virtex and Spartan FPGAs
which means (OK, may be cores are different somewhat for different FPGAs
but low level Xilinx code is the same). That means at least 2 different
CPU architectures (PPC and Microblaze).=20

You certainly gave thought to such an issue. What tree structure do you
suggest? There are 3 groups of Xilinx files to place in the Linux tree:

- common .h files (like xbasic_types.h);
- common .c files, used by several cores (like all DMA stuff).
- specific core .h/.c files (say xemac.h and xemac.c).

They all kind of "architecture independent" (at least 2 architectures
can be used - MB and PPC).

Of course, except tree structure there are several other (not completely
independent) questions to answer like:

A How EDK project parameters get into Linux kernel? This is huge issue
which can be divided on several items.

A.1. Do you also suppose that some special type of BSP (.tcl script,
defined by OS parameter of MSS file) shall run or you assume that it
will be regular xaparameters.h file, prepared by standard standalone
BSP? In latter case xparamerts.h needs manual editing since it doesn't
have all parameters required by certain cores.=20

A.2. There is also a question how these definitions get into .c and Make
files. Petalogix has interesting solution when they bump all XILINX
parameters to autoconf.h and .config files thus making them available
for both compiler and make. What's your approach?

A.3. If .config is not prepared automatically, then all configuration
must be done via "make menuconfig" meaning Kconfig files shall be
modified. Do you intend having several FPGA flags like CONFIG_VIRTEX and
CONFIG_SPARTAN? Drivers' inclusion will depend on one of them.

A.4. Is it assumed that Xilinx low level code will stay intact as it is
supplied with EDK package or you are going to prepare special Linux
Xilinx set (mostly because of name convention)?

B How drivers get registered - via platform devices structure in
virtex.c file or something different?

All these questions have been discussed by the community but I somehow
missed a conclusion if any took place. Does anything (kind of memo or
readme) exist on these subjects?

Thanks,

Leonid.

-----Original Message-----
From: Wolfgang Reissnegger [mailto:wolfgang.reissnegger@xilinx.com]=20
Sent: Monday, August 13, 2007 10:08 PM
To: Leonid
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Best Linux tree for Xilinx support.

Hi Leonid,

I am in the process of publishing a Xilinx Linux git tree which will
contain most of the drivers for Xilinx IP including recent contributions
from Grant Likely, John Williams, Joachim Foerster and others.

This tree will be available on the Xilinx git server soon, however it
will be a non-supported (and likely unstable) tree. Its main purpose is
to provide a common code base for development and a channel to push new
driver code out into the community.

I am still waiting on IT to set up the new server machine. I will post
an announcement once the server is up and running.

Cheers,
   Wolfgang

Leonid wrote:
> Hi:
>=20
> I have several boards with different architectures (Microblaze, PPC),=20
> running Linux/uClinux and using Xilinx IP cores. I use both Virtex and

> Spartan FPGAs.
>=20
> Historically I'm using different kernels for them, starting from=20
> uClinux 2.4, all way through Linux 2.6.16 and 2.6.19. I patched them=20
> here and there to get working.
>=20
> I certainly feel a need to move to some standard kernel tree.
>=20
> I understand that you guys are in some advanced steps of integrating=20
> Xilinx into Linux. What would be my best choice of Linux kernel now?
>=20
> I see the following options:
>=20
> - download some GIT tree your are using (which one?).
> - get latest tree from kernel.org and patch it using your patches=20
> (where I can get them?).
> - ??
>=20
> Please advise,
>=20
> Thanks,
>=20
> Leonid.
>=20

Re: Best Linux tree for Xilinx support.

[Grant Likely]

On 8/14/07, Leonid <Leonid@a-k-a.net> wrote:
> I deem such approach is not very good one. I'm using precisely same IP
> cores like GPIO, EMAC, SPI, CAN, etc... in Virtex and Spartan FPGAs
> which means (OK, may be cores are different somewhat for different FPGAs
> but low level Xilinx code is the same). That means at least 2 different
> CPU architectures (PPC and Microblaze).

The driver code should all be in platform independent locations.  Only
the ppc405 support code lives in arch/ppc.  For ublaze support, you
need to look at the ublaze mailing list.

>
> You certainly gave thought to such an issue. What tree structure do you
> suggest? There are 3 groups of Xilinx files to place in the Linux tree:
>
> - common .h files (like xbasic_types.h);

Common include files go in include/linux.  However, the xilinx
os-independent files are a stopgap measure.  They will probably never
be merged into the mainline Linux source tree.

> - common .c files, used by several cores (like all DMA stuff).

I think we've agreed that drivers/misc is a suitable location.

> - specific core .h/.c files (say xemac.h and xemac.c).

Eth drivers go under drivers/net
serial drivers go under drivers/serial
i2c drivers go under drivers/i2c
etc.

> They all kind of "architecture independent" (at least 2 architectures
> can be used - MB and PPC).

Many of the drivers already are arch independent.  A key feature of
this is that xilinx ip drivers should *not* make use of xparameters.h
directly.  Which drivers are you having trouble with?

> Of course, except tree structure there are several other (not completely
> independent) questions to answer like:
>
> A How EDK project parameters get into Linux kernel? This is huge issue
> which can be divided on several items.

In arch/ppc (depreciated), via platform bus registrations.  The
platform bus is populated via
arch/ppc/platforms/4xx/xparameters/xparameters.h

In arch/powerpc, via a device tree blob.  The device tree blob will be
generated from the EDK project.

in microblaze, I believe it is currently via platform bus
registrations like in arch/ppc, but there is desire to move to using
the arch/powerpc device tree also.

>
> A.1. Do you also suppose that some special type of BSP (.tcl script,
> defined by OS parameter of MSS file) shall run or you assume that it
> will be regular xaparameters.h file, prepared by standard standalone
> BSP? In latter case xparamerts.h needs manual editing since it doesn't
> have all parameters required by certain cores.
>
> A.2. There is also a question how these definitions get into .c and Make
> files. Petalogix has interesting solution when they bump all XILINX
> parameters to autoconf.h and .config files thus making them available
> for both compiler and make. What's your approach?

Just to reinforce my point: xilinx device drivers should *NEVER* use
xparameters.h directly.  The device driver binding code should either
retrieve the device configuration from the platform bus or from the
device tree.

>
> A.3. If .config is not prepared automatically, then all configuration
> must be done via "make menuconfig" meaning Kconfig files shall be
> modified. Do you intend having several FPGA flags like CONFIG_VIRTEX and
> CONFIG_SPARTAN? Drivers' inclusion will depend on one of them.

Yes, some of them even already exist!  :-)

There can also be some defconfigs for supported boards.

>
> A.4. Is it assumed that Xilinx low level code will stay intact as it is
> supplied with EDK package or you are going to prepare special Linux
> Xilinx set (mostly because of name convention)?

No.  The xilinx EDK drivers are not desirable for inclusion in
mainline.  Slowly the drivers are being replaced with Linux specific
drivers.  New uartlite, ns16550, xsysace and framebuffer drivers are
already in mainline.

>
> B How drivers get registered - via platform devices structure in
> virtex.c file or something different?

Read up on 'platform bus' and 'of platform bus'.  platform bus is what
works now.  of platform bus is how it will work when we migrate to
arch/powerpc.

>
> All these questions have been discussed by the community but I somehow
> missed a conclusion if any took place. Does anything (kind of memo or
> readme) exist on these subjects?

Unfortunately, no.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Best Linux tree for Xilinx support.

[Wolfgang Reissnegger]

Hi Leonid,

see my answers below.

> Thank you very much for the information. What kernel.org version your
> tree is based on?

Right now the development tree is based on mainline (Linus' tree)
v2.6.22. I also keep a release candidate (rc) branch around that I sync
up frequently with the leading edge mainline in order to catch merge
conflicts early. However, I'm not currently test-compiling the rc branch.

> As you noticed, it will be rather reference tree to set some coding
> standard, namely where files are located, how drivers are included,
> etc... So, I would appreciate if I can get a glimpse of your suggested
> tree structure, actual sources are not even required.

The structure follows pretty much what is out there so far. For example,
the temac/emac/lltemac drivers go into drivers/net/xilinx_xxx.

All the PPC405 stuff is still in arch/ppc. I know it needs to be ported
over to arch/powerpc, which is one of the future goals.

MicroBlaze support is in arch/microblaze and include/asm-microblaze.

> Previous support for Xilinx was more oriented toward PPC405 core in
> Virtex FPGA and everything was naturally concentrated under
> arch/ppc/platform/4xx.

This is, for now, still the case. See above.

> I deem such approach is not very good one. I'm using precisely same IP
> cores like GPIO, EMAC, SPI, CAN, etc... in Virtex and Spartan FPGAs
> which means (OK, may be cores are different somewhat for different FPGAs
> but low level Xilinx code is the same). That means at least 2 different
> CPU architectures (PPC and Microblaze). 

Yes.

> You certainly gave thought to such an issue. What tree structure do you
> suggest? There are 3 groups of Xilinx files to place in the Linux tree:
> 
> - common .h files (like xbasic_types.h);
> - common .c files, used by several cores (like all DMA stuff).
> - specific core .h/.c files (say xemac.h and xemac.c).
> 
> They all kind of "architecture independent" (at least 2 architectures
> can be used - MB and PPC).

Yes, the drivers are (or at least should be) arch independent. So far we
have been able compiling various drivers under PPC405 and MB without any
code changes. Further testing is needed, but generally it looks OK.

> Of course, except tree structure there are several other (not completely
> independent) questions to answer like:
> 
> A How EDK project parameters get into Linux kernel? This is huge issue
> which can be divided on several items.
> 
> A.1. Do you also suppose that some special type of BSP (.tcl script,
> defined by OS parameter of MSS file) shall run or you assume that it
> will be regular xaparameters.h file, prepared by standard standalone
> BSP? In latter case xparamerts.h needs manual editing since it doesn't
> have all parameters required by certain cores. 

The kernel will contain pre-generated xparameters_xxx.h files for the
reference systems. For custom projects you still need to copy over the
EDK-generated xparameters.h file.

For the xparameters.h file we are planning to move away from the bus
specific #defines and move towards more generic ones.

> A.2. There is also a question how these definitions get into .c and Make
> files. Petalogix has interesting solution when they bump all XILINX
> parameters to autoconf.h and .config files thus making them available
> for both compiler and make. What's your approach?

I have thought about adopting the Petalogix scheme at some point.
However, i got into trouble as I was changing too many things at a time.
I think the Petalogix way works well and could be one of the future
solutions for that.
Currently the approach is to copy over the EDK-generated xparamater.h file.

> A.3. If .config is not prepared automatically, then all configuration
> must be done via "make menuconfig" meaning Kconfig files shall be
> modified. Do you intend having several FPGA flags like CONFIG_VIRTEX and
> CONFIG_SPARTAN? Drivers' inclusion will depend on one of them.

The plan is to generate a .config file through the EDK.

> A.4. Is it assumed that Xilinx low level code will stay intact as it is
> supplied with EDK package or you are going to prepare special Linux
> Xilinx set (mostly because of name convention)?

For new drivers, meaning the ones that we are putting into the kernel
right now, the drivers will not follow the Linux coding convention. As
time progresses there will be one or the other driver being converted
for upstream, though.

> B How drivers get registered - via platform devices structure in
> virtex.c file or something different?

Drivers will be registered vie platform devices for botthe MB and PPC405
systems.

> All these questions have been discussed by the community but I somehow
> missed a conclusion if any took place. Does anything (kind of memo or
> readme) exist on these subjects?

Nope...

> Thanks,
> 
> Leonid.

Cheers,
   Wolfgang

RE: Best Linux tree for Xilinx support.

[Leonid]

Thank you both for detailed answers, it was very helpful indeed.

Reagrds,

Leonid.

-----Original Message-----
From: Wolfgang Reissnegger [mailto:wolfgang.reissnegger@xilinx.com]=20
Sent: Tuesday, August 14, 2007 1:44 PM
To: Leonid
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Best Linux tree for Xilinx support.

Hi Leonid,

see my answers below.

> Thank you very much for the information. What kernel.org version your=20
> tree is based on?

Right now the development tree is based on mainline (Linus' tree)
v2.6.22. I also keep a release candidate (rc) branch around that I sync
up frequently with the leading edge mainline in order to catch merge
conflicts early. However, I'm not currently test-compiling the rc
branch.

> As you noticed, it will be rather reference tree to set some coding=20
> standard, namely where files are located, how drivers are included,=20
> etc... So, I would appreciate if I can get a glimpse of your suggested

> tree structure, actual sources are not even required.

The structure follows pretty much what is out there so far. For example,
the temac/emac/lltemac drivers go into drivers/net/xilinx_xxx.

All the PPC405 stuff is still in arch/ppc. I know it needs to be ported
over to arch/powerpc, which is one of the future goals.

MicroBlaze support is in arch/microblaze and include/asm-microblaze.

> Previous support for Xilinx was more oriented toward PPC405 core in=20
> Virtex FPGA and everything was naturally concentrated under=20
> arch/ppc/platform/4xx.

This is, for now, still the case. See above.

> I deem such approach is not very good one. I'm using precisely same IP

> cores like GPIO, EMAC, SPI, CAN, etc... in Virtex and Spartan FPGAs=20
> which means (OK, may be cores are different somewhat for different=20
> FPGAs but low level Xilinx code is the same). That means at least 2=20
> different CPU architectures (PPC and Microblaze).

Yes.

> You certainly gave thought to such an issue. What tree structure do=20
> you suggest? There are 3 groups of Xilinx files to place in the Linux
tree:
>=20
> - common .h files (like xbasic_types.h);
> - common .c files, used by several cores (like all DMA stuff).
> - specific core .h/.c files (say xemac.h and xemac.c).
>=20
> They all kind of "architecture independent" (at least 2 architectures=20
> can be used - MB and PPC).

Yes, the drivers are (or at least should be) arch independent. So far we
have been able compiling various drivers under PPC405 and MB without any
code changes. Further testing is needed, but generally it looks OK.

> Of course, except tree structure there are several other (not=20
> completely
> independent) questions to answer like:
>=20
> A How EDK project parameters get into Linux kernel? This is huge issue

> which can be divided on several items.
>=20
> A.1. Do you also suppose that some special type of BSP (.tcl script,=20
> defined by OS parameter of MSS file) shall run or you assume that it=20
> will be regular xaparameters.h file, prepared by standard standalone=20
> BSP? In latter case xparamerts.h needs manual editing since it doesn't

> have all parameters required by certain cores.

The kernel will contain pre-generated xparameters_xxx.h files for the
reference systems. For custom projects you still need to copy over the
EDK-generated xparameters.h file.

For the xparameters.h file we are planning to move away from the bus
specific #defines and move towards more generic ones.

> A.2. There is also a question how these definitions get into .c and=20
> Make files. Petalogix has interesting solution when they bump all=20
> XILINX parameters to autoconf.h and .config files thus making them=20
> available for both compiler and make. What's your approach?

I have thought about adopting the Petalogix scheme at some point.
However, i got into trouble as I was changing too many things at a time.
I think the Petalogix way works well and could be one of the future
solutions for that.
Currently the approach is to copy over the EDK-generated xparamater.h
file.

> A.3. If .config is not prepared automatically, then all configuration=20
> must be done via "make menuconfig" meaning Kconfig files shall be=20
> modified. Do you intend having several FPGA flags like CONFIG_VIRTEX=20
> and CONFIG_SPARTAN? Drivers' inclusion will depend on one of them.

The plan is to generate a .config file through the EDK.

> A.4. Is it assumed that Xilinx low level code will stay intact as it=20
> is supplied with EDK package or you are going to prepare special Linux

> Xilinx set (mostly because of name convention)?

For new drivers, meaning the ones that we are putting into the kernel
right now, the drivers will not follow the Linux coding convention. As
time progresses there will be one or the other driver being converted
for upstream, though.

> B How drivers get registered - via platform devices structure in=20
> virtex.c file or something different?

Drivers will be registered vie platform devices for botthe MB and PPC405
systems.

> All these questions have been discussed by the community but I somehow

> missed a conclusion if any took place. Does anything (kind of memo or
> readme) exist on these subjects?

Nope...

> Thanks,
>=20
> Leonid.

Cheers,
   Wolfgang

Re: Best Linux tree for Xilinx support.

[David H. Lynch Jr.]

Leonid wrote:
> I deem such approach is not very good one. I'm using precisely same IP
> cores like GPIO, EMAC, SPI, CAN, etc... in Virtex and Spartan FPGAs
> which means (OK, may be cores are different somewhat for different FPGAs
> but low level Xilinx code is the same). That means at least 2 different
> CPU architectures (PPC and Microblaze). 
>   
    Most device drivers are outside the arch tree, only board specific 
configuration
    is inside.
   
    While there is a great deal of similarity between the microblaze and 
ppc code that
    would be under the arch tree's they are still as distinct as 
different architecures.
    Maybe there would be some way to share some of the code, but for the 
most part
    the similar or identical code falls outside the arch tree.

> A How EDK project parameters get into Linux kernel? This is huge issue
> which can be divided on several items.
>   
    Xilinx has their own idea's and thus far they do not seem to fit 
well with the
norms of Linux kernel developers. It is extremely unlikely the latter 
will change.

    I did the BSP for the Pico E1x series of boards. While it is based 
heavily on Grant's
MLXXX work that I am trying to track, very little of it is even xilinx 
specific.

    One the key distinctions between FPGA based systems and typical 
systems is that
the core is very very small. In a Pico E1x, you can only count on:
    A processor,
    an MMU,
    memory,
    and some serial (or pseudo serial) device capable of functioning as 
a console.
    Flash, Ethernet, Specific Uarts, Even interrupts and interrupt 
handling are
    all optional.
   
> A.2. There is also a question how these definitions get into .c and Make
> files. Petalogix has interesting solution when they bump all XILINX
> parameters to autoconf.h and .config files thus making them available
> for both compiler and make. What's your approach?
>   
    With all respect to Petalogix and the significant work they have 
done, I can not see migrating all
    the xparameters.h values into .config being adopted. Besides little 
of none of those values are
    needed outside the core of the BSP.

    I am not particular enamored with the CONFIG_VIRTEX or    
    CONFIG_VIRTEX_4 flags either. There is very very little that knowing
    the exact FPGA tells Linux. As an example Pico E12's, E14's and E16's
    are fundimentally very similar, despite having different form factors,
    being on different cards (CF, CardBus, ExpressBus), and using different
    Xilinx parts (sometimes on the same model)

    I beleive that the long term effort is to put everything into device 
tree's
    then the device information for the product is
        dynamically created, or stored in flash or otherwise provided to 
Linux
    at boot. But that is pretty close to the extent of my knowledge of 
device
    trees at this time.  

> A.4. Is it assumed that Xilinx low level code will stay intact as it is
> supplied with EDK package or you are going to prepare special Linux
> Xilinx set (mostly because of name convention)?
>   
    I do not beleive anyone is anticipating the Xilinx EDK code making 
its way into
a kernel.org Linux source.

> B How drivers get registered - via platform devices structure in
> virtex.c file or something different?
>   
    I beleive the current approach is mostly using platform devices - though
individual drivers may vary. I beleive the longterm approach is to use 
device
trees - I am not sure how the two interrelate.


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein