PATCH: support for Arctic/Beech/Ebony

PATCH: support for Arctic/Beech/Ebony

[Marius Groeger]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 820 bytes --]

Hello,

attached is a patch that adds MTD support for a couple of PowerPC
boards based on the IBM440GP CPU. It also clean up the PPC
section in the mapping drivers Config.in, making it more robust
against configuration errors.

All code was taken directly from linuxppc_2_4_devel, and I didn't
write it. I shall add commandline paritioning support some time soon,
though.

If nobody objects, I will commit it to the repository.

Thanks,
Marius

-----------------------------------------------------------------------------
Marius Groeger           SYSGO Real-Time Solutions AG       mgroeger@sysgo.de
Software Engineering     Embedded and Real-Time Software    www.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14                 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com

[-- Attachment #2: Type: TEXT/PLAIN, Size: 18233 bytes --]

diff -Naur --exclude Kconfig --exclude CVS mtd/drivers/mtd/maps/Config.in linuxppc_2_4_devel/drivers/mtd/maps/Config.in
--- mtd/drivers/mtd/maps/Config.in	Wed Oct 30 00:00:06 2002
+++ linuxppc_2_4_devel/drivers/mtd/maps/Config.in	Mon Jan 27 11:58:37 2003
@@ -37,13 +37,30 @@
    dep_tristate ' BIOS flash chip on Intel SCB2 boards' CONFIG_MTD_SCB2_FLASH $CONFIG_MTD_GEN_PROBE
 fi
 
-if [ "$CONFIG_PPC" = "y" ]; then
-   dep_tristate '  CFI Flash device mapped on TQM8XXL' CONFIG_MTD_TQM8XXL $CONFIG_MTD_CFI $CONFIG_TQM8xxL
-   dep_tristate '  CFI Flash device mapped on RPX Lite or CLLF' CONFIG_MTD_RPXLITE $CONFIG_MTD_CFI
-   dep_tristate '  System flash on MBX860 board' CONFIG_MTD_MBX860 $CONFIG_MTD_CFI
-   dep_tristate '  CFI Flash device mapped on D-Box2' CONFIG_MTD_DBOX2 $CONFIG_MTD_CFI
-   dep_tristate '  CFI Flash device mapping on FlagaDM' CONFIG_MTD_CFI_FLAGADM $CONFIG_MTD_CFI
-   dep_tristate '  CFI Flash device mapped on IBM Redwood-4/5' CONFIG_MTD_REDWOOD $CONFIG_MTD_CFI
+if [ "$CONFIG_PPC32" = "y" ]; then
+  if [ "$CONFIG_8xx" = "y" ]; then
+    if [ "$CONFIG_TQM8xxL" = "y" ]; then
+      dep_tristate '  CFI Flash device mapped on TQM8XXL' CONFIG_MTD_TQM8XXL $CONFIG_MTD_CFI
+    fi
+    if [ "$CONFIG_RPXLITE" = "y" -o "$CONFIG_RPXCLASSIC" = "y" ]; then
+      dep_tristate '  CFI Flash device mapped on RPX Lite or CLLF' CONFIG_MTD_RPXLITE $CONFIG_MTD_CFI
+    fi
+    dep_tristate '  System flash on MBX860 board' CONFIG_MTD_MBX860 $CONFIG_MTD_CFI
+    dep_tristate '  CFI Flash device mapped on D-Box2' CONFIG_MTD_DBOX2 $CONFIG_MTD_CFI
+    dep_tristate '  CFI Flash device mapping on FlagaDM' CONFIG_MTD_CFI_FLAGADM $CONFIG_MTD_CFI
+  fi
+  if [ "$CONFIG_4xx" = "y" ]; then
+    if [ "$CONFIG_40x" = "y" ]; then
+      if [ "$CONFIG_REDWOOD_4" = "y" -o "$CONFIG_REDWOOD_5" = "y" -o "$CONFIG_REDWOOD_6" = "y" ]; then
+        dep_tristate '  CFI Flash device mapped on IBM Redwood' CONFIG_MTD_REDWOOD $CONFIG_MTD_CFI
+      fi
+      dep_tristate '  CFI Flash device mapped on IBM Beech' CONFIG_MTD_BEECH $CONFIG_MTD_CFI $CONFIG_BEECH
+      dep_tristate '  CFI Flash device mapped on IBM Arctic' CONFIG_MTD_ARCTIC $CONFIG_MTD_CFI $CONFIG_ARCTIC2
+    fi
+    if [ "$CONFIG_440" = "y" ]; then
+      dep_tristate '  Flash devices mapped on IBM Ebony' CONFIG_MTD_EBONY $CONFIG_MTD_CFI $CONFIG_EBONY
+    fi
+  fi
 fi
 
 if [ "$CONFIG_MIPS" = "y" ]; then
diff -Naur --exclude Kconfig --exclude CVS mtd/drivers/mtd/maps/Makefile linuxppc_2_4_devel/drivers/mtd/maps/Makefile
--- mtd/drivers/mtd/maps/Makefile	Thu Nov 28 00:00:09 2002
+++ linuxppc_2_4_devel/drivers/mtd/maps/Makefile	Mon Jan 27 12:28:02 2003
@@ -59,5 +59,8 @@
 obj-$(CONFIG_MTD_UCLINUX)	+= uclinux.o
 obj-$(CONFIG_MTD_NETtel)	+= nettel.o
 obj-$(CONFIG_MTD_SCB2_FLASH)	+= scb2_flash.o
+obj-$(CONFIG_MTD_EBONY)		+= ebony.o
+obj-$(CONFIG_MTD_BEECH)		+= beech-mtd.o
+obj-$(CONFIG_MTD_ARCTIC)	+= arctic-mtd.o
 
 include $(TOPDIR)/Rules.make
diff -Naur --exclude Kconfig --exclude CVS mtd/drivers/mtd/maps/arctic-mtd.c linuxppc_2_4_devel/drivers/mtd/maps/arctic-mtd.c
--- mtd/drivers/mtd/maps/arctic-mtd.c	Thu Jan  1 01:00:00 1970
+++ linuxppc_2_4_devel/drivers/mtd/maps/arctic-mtd.c	Mon Jan 27 12:00:22 2003
@@ -0,0 +1,168 @@
+/*
+ * drivers/mtd/maps/arctic-mtd.c MTD mappings and partition tables for 
+ *                              IBM 405LP Arctic boards.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Copyright (C) 2002, International Business Machines Corporation
+ * All Rights Reserved.
+ *
+ * Bishop Brock
+ * IBM Research, Austin Center for Low-Power Computing
+ * bcbrock@us.ibm.com
+ * March 2002
+ *
+ * modified for Arctic by,
+ * David Gibson
+ * IBM OzLabs, Canberra, Australia
+ * <arctic@gibson.dropbear.id.au>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/types.h>
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/mtd/partitions.h>
+
+#include <asm/io.h>
+#include <asm/ibm4xx.h>
+
+#define ARCTIC_FFS_SIZE	0x1a00000 /* 26 M */
+
+#define NAME     "Arctic Linux Flash"
+#define PADDR    SUBZERO_BOOTFLASH_PADDR
+#define SIZE     SUBZERO_BOOTFLASH_SIZE
+#define BUSWIDTH 2
+
+/* Flash memories on these boards are memory resources, accessed big-endian. */
+
+static u8
+arctic_mtd_read8(struct map_info *map, unsigned long offset)
+{
+	return __raw_readb(map->map_priv_1 + offset);
+}
+
+static u16
+arctic_mtd_read16(struct map_info *map, unsigned long offset)
+{
+	return __raw_readw(map->map_priv_1 + offset);
+}
+
+static u32
+arctic_mtd_read32(struct map_info *map, unsigned long offset)
+{
+	return __raw_readl(map->map_priv_1 + offset);
+}
+
+static void
+arctic_mtd_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
+{
+	memcpy_fromio(to, (void *) (map->map_priv_1 + from), len);
+}
+
+static void
+arctic_mtd_write8(struct map_info *map, u8 data, unsigned long address)
+{
+	__raw_writeb(data, map->map_priv_1 + address);
+	mb();
+}
+
+static void
+arctic_mtd_write16(struct map_info *map, u16 data, unsigned long address)
+{
+	__raw_writew(data, map->map_priv_1 + address);
+	mb();
+}
+
+static void
+arctic_mtd_write32(struct map_info *map, u32 data, unsigned long address)
+{
+	__raw_writel(data, map->map_priv_1 + address);
+	mb();
+}
+
+static void
+arctic_mtd_copy_to(struct map_info *map,
+		  unsigned long to, const void *from, ssize_t len)
+{
+	memcpy_toio((void *) (map->map_priv_1 + to), from, len);
+}
+
+static struct map_info arctic_mtd_map = {
+	.name		= NAME,
+	.size		= SIZE,
+	.buswidth	= BUSWIDTH,
+	.read8		= arctic_mtd_read8,
+	.read16		= arctic_mtd_read16,
+	.read32		= arctic_mtd_read32,
+	.copy_from	= arctic_mtd_copy_from,
+	.write8		= arctic_mtd_write8,
+	.write16	= arctic_mtd_write16,
+	.write32	= arctic_mtd_write32,
+	.copy_to	= arctic_mtd_copy_to,
+};
+
+static struct mtd_info *arctic_mtd;
+
+static struct mtd_partition arctic_partitions[2] = {
+	{ .name		= "Arctic FFS",
+	  .size		= ARCTIC_FFS_SIZE,
+	  .offset	= 0,},
+	{ .name		= "Kernel & firmware",
+	  .size		= (SUBZERO_BOOTFLASH_SIZE - ARCTIC_FFS_SIZE),
+	  .offset	= ARCTIC_FFS_SIZE,},
+};
+
+static int __init
+init_arctic_mtd(void)
+{
+	printk("%s: 0x%08x at 0x%08x\n", NAME, SIZE, PADDR);
+
+	arctic_mtd_map.map_priv_1 = (unsigned long) ioremap(PADDR, SIZE);
+
+	if (!arctic_mtd_map.map_priv_1) {
+		printk("%s: failed to ioremap 0x%x\n", NAME, PADDR);
+		return -EIO;
+	}
+
+	printk("%s: probing %d-bit flash bus\n", NAME, BUSWIDTH * 8);
+	arctic_mtd = do_map_probe("cfi_probe", &arctic_mtd_map);
+
+	if (!arctic_mtd)
+		return -ENXIO;
+
+	arctic_mtd->module = THIS_MODULE;
+
+	return add_mtd_partitions(arctic_mtd, arctic_partitions, 2);
+}
+
+static void __exit
+cleanup_arctic_mtd(void)
+{
+	if (arctic_mtd) {
+		del_mtd_partitions(arctic_mtd);
+		map_destroy(arctic_mtd);
+		iounmap((void *) arctic_mtd_map.map_priv_1);
+	}
+}
+
+module_init(init_arctic_mtd);
+module_exit(cleanup_arctic_mtd);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("David Gibson <arctic@gibson.dropbear.id.au>");
+MODULE_DESCRIPTION("MTD map and partitions for IBM 405LP Arctic boards");
diff -Naur --exclude Kconfig --exclude CVS mtd/drivers/mtd/maps/beech-mtd.c linuxppc_2_4_devel/drivers/mtd/maps/beech-mtd.c
--- mtd/drivers/mtd/maps/beech-mtd.c	Thu Jan  1 01:00:00 1970
+++ linuxppc_2_4_devel/drivers/mtd/maps/beech-mtd.c	Mon Jan 27 12:00:27 2003
@@ -0,0 +1,164 @@
+/*
+ * drivers/mtd/maps/beech-mtd.c MTD mappings and partition tables for 
+ *                              IBM 405LP Beech boards.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Copyright (C) 2002, International Business Machines Corporation
+ * All Rights Reserved.
+ *
+ * Bishop Brock
+ * IBM Research, Austin Center for Low-Power Computing
+ * bcbrock@us.ibm.com
+ * March 2002
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/types.h>
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/mtd/partitions.h>
+
+#include <asm/io.h>
+#include <asm/ibm4xx.h>
+
+#define NAME     "Beech Linux Flash"
+#define PADDR    BEECH_BIGFLASH_PADDR
+#define SIZE     BEECH_BIGFLASH_SIZE
+#define BUSWIDTH 1
+
+/* Flash memories on these boards are memory resources, accessed big-endian. */
+
+static __u8
+beech_mtd_read8(struct map_info *map, unsigned long offset)
+{
+	return __raw_readb(map->map_priv_1 + offset);
+}
+
+static __u16
+beech_mtd_read16(struct map_info *map, unsigned long offset)
+{
+	return __raw_readw(map->map_priv_1 + offset);
+}
+
+static __u32
+beech_mtd_read32(struct map_info *map, unsigned long offset)
+{
+	return __raw_readl(map->map_priv_1 + offset);
+}
+
+static void
+beech_mtd_copy_from(struct map_info *map,
+		    void *to, unsigned long from, ssize_t len)
+{
+	memcpy(to, (void *) (map->map_priv_1 + from), len);
+}
+
+static void
+beech_mtd_write8(struct map_info *map, __u8 data, unsigned long address)
+{
+	__raw_writeb(data, map->map_priv_1 + address);
+	mb();
+}
+
+static void
+beech_mtd_write16(struct map_info *map, __u16 data, unsigned long address)
+{
+	__raw_writew(data, map->map_priv_1 + address);
+	mb();
+}
+
+static void
+beech_mtd_write32(struct map_info *map, __u32 data, unsigned long address)
+{
+	__raw_writel(data, map->map_priv_1 + address);
+	mb();
+}
+
+static void
+beech_mtd_copy_to(struct map_info *map,
+		  unsigned long to, const void *from, ssize_t len)
+{
+	memcpy((void *) (map->map_priv_1 + to), from, len);
+}
+
+static struct map_info beech_mtd_map = {
+	name:NAME,
+	size:SIZE,
+	buswidth:BUSWIDTH,
+	read8:beech_mtd_read8,
+	read16:beech_mtd_read16,
+	read32:beech_mtd_read32,
+	copy_from:beech_mtd_copy_from,
+	write8:beech_mtd_write8,
+	write16:beech_mtd_write16,
+	write32:beech_mtd_write32,
+	copy_to:beech_mtd_copy_to
+};
+
+static struct mtd_info *beech_mtd;
+
+static struct mtd_partition beech_partitions[2] = {
+	{
+	      name:"Linux Kernel",
+	      size:BEECH_KERNEL_SIZE,
+      offset:BEECH_KERNEL_OFFSET}, {
+	      name:		"Free Area",
+	      size:		BEECH_FREE_AREA_SIZE,
+      offset:			BEECH_FREE_AREA_OFFSET}
+};
+
+static int __init
+init_beech_mtd(void)
+{
+	printk("%s: 0x%08x at 0x%08x\n", NAME, SIZE, PADDR);
+
+	beech_mtd_map.map_priv_1 = (unsigned long) ioremap(PADDR, SIZE);
+
+	if (!beech_mtd_map.map_priv_1) {
+		printk("%s: failed to ioremap 0x%x\n", NAME, PADDR);
+		return -EIO;
+	}
+
+	printk("%s: probing %d-bit flash bus\n", NAME, BUSWIDTH * 8);
+	beech_mtd = do_map_probe("cfi_probe", &beech_mtd_map);
+
+	if (!beech_mtd)
+		return -ENXIO;
+
+	beech_mtd->module = THIS_MODULE;
+
+	return add_mtd_partitions(beech_mtd, beech_partitions, 2);
+}
+
+static void __exit
+cleanup_beech_mtd(void)
+{
+	if (beech_mtd) {
+		del_mtd_partitions(beech_mtd);
+		map_destroy(beech_mtd);
+		iounmap((void *) beech_mtd_map.map_priv_1);
+	}
+}
+
+module_init(init_beech_mtd);
+module_exit(cleanup_beech_mtd);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Bishop Brock, bcbrock@us.ibm.com");
+MODULE_DESCRIPTION("MTD map and partitions for IBM 405LP Beech boards");
diff -Naur --exclude Kconfig --exclude CVS mtd/drivers/mtd/maps/ebony.c linuxppc_2_4_devel/drivers/mtd/maps/ebony.c
--- mtd/drivers/mtd/maps/ebony.c	Thu Jan  1 01:00:00 1970
+++ linuxppc_2_4_devel/drivers/mtd/maps/ebony.c	Mon Jan 27 11:55:18 2003
@@ -0,0 +1,210 @@
+/*
+ * Mapping for Ebony user flash
+ *
+ * Matt Porter <mporter@mvista.com>
+ *
+ * Copyright 2002 MontaVista Software Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/mtd/partitions.h>
+#include <linux/config.h>
+#include <asm/io.h>
+#include <asm/ibm440.h>
+#include <platforms/ebony.h>
+
+static struct mtd_info *flash;
+
+static __u8 ebony_read8(struct map_info *map, unsigned long ofs)
+{
+	return __raw_readb(map->map_priv_1 + ofs);
+}
+
+static __u16 ebony_read16(struct map_info *map, unsigned long ofs)
+{
+	return __raw_readw(map->map_priv_1 + ofs);
+}
+
+static __u32 ebony_read32(struct map_info *map, unsigned long ofs)
+{
+	return __raw_readl(map->map_priv_1 + ofs);
+}
+
+static void ebony_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
+{
+	memcpy_fromio(to, map->map_priv_1 + from, len);
+}
+
+static void ebony_write8(struct map_info *map, __u8 d, unsigned long adr)
+{
+	__raw_writeb(d, map->map_priv_1 + adr);
+	mb();
+}
+
+static void ebony_write16(struct map_info *map, __u16 d, unsigned long adr)
+{
+	__raw_writew(d, map->map_priv_1 + adr);
+	mb();
+}
+
+static void ebony_write32(struct map_info *map, __u32 d, unsigned long adr)
+{
+	__raw_writel(d, map->map_priv_1 + adr);
+	mb();
+}
+
+static void ebony_copy_to(struct map_info *map, unsigned long to, const void *from, ssize_t len)
+{
+	memcpy_toio(map->map_priv_1 + to, from, len);
+}
+
+static struct map_info ebony_small_map = {
+	name: "Ebony small flash",
+	size: EBONY_SMALL_FLASH_SIZE,
+	buswidth: 1,
+	read8: ebony_read8,
+	read16: ebony_read16,
+	read32: ebony_read32,
+	copy_from: ebony_copy_from,
+	write8: ebony_write8,
+	write16: ebony_write16,
+	write32: ebony_write32,
+	copy_to: ebony_copy_to,
+};
+
+static struct map_info ebony_large_map = {
+	name: "Ebony large flash",
+	size: EBONY_LARGE_FLASH_SIZE,
+	buswidth: 1,
+	read8: ebony_read8,
+	read16: ebony_read16,
+	read32: ebony_read32,
+	copy_from: ebony_copy_from,
+	write8: ebony_write8,
+	write16: ebony_write16,
+	write32: ebony_write32,
+	copy_to: ebony_copy_to,
+};
+
+static struct mtd_partition ebony_small_partitions[] = {
+	{
+		name: "OpenBIOS",
+		offset: 0x0,
+		size: 0x80000,
+	}
+};
+
+static struct mtd_partition ebony_large_partitions[] = {
+	{
+		name: "fs",
+		offset: 0,
+		size:   0x380000,
+	},
+	{
+		name: "firmware",
+		offset: 0x380000,
+		size: 0x80000,
+	}
+};
+
+#define NB_OF(x)  (sizeof(x)/sizeof(x[0]))
+
+int __init init_ebony(void)
+{
+	u8 fpga0_reg;
+	unsigned long long small_flash_base, large_flash_base;
+
+	fpga0_reg = readb(ioremap64(EBONY_FPGA_ADDR, 16));
+
+	if (EBONY_BOOT_SMALL_FLASH(fpga0_reg) &&
+			!EBONY_FLASH_SEL(fpga0_reg))
+		small_flash_base = EBONY_SMALL_FLASH_HIGH2;
+	else if (EBONY_BOOT_SMALL_FLASH(fpga0_reg) &&
+			EBONY_FLASH_SEL(fpga0_reg))
+		small_flash_base = EBONY_SMALL_FLASH_HIGH1;
+	else if (!EBONY_BOOT_SMALL_FLASH(fpga0_reg) &&
+			!EBONY_FLASH_SEL(fpga0_reg))
+		small_flash_base = EBONY_SMALL_FLASH_LOW2;
+	else
+		small_flash_base = EBONY_SMALL_FLASH_LOW1;
+			
+	if (EBONY_BOOT_SMALL_FLASH(fpga0_reg) &&
+			!EBONY_ONBRD_FLASH_EN(fpga0_reg))
+		large_flash_base = EBONY_LARGE_FLASH_LOW;
+	else
+		large_flash_base = EBONY_LARGE_FLASH_HIGH;
+
+	ebony_small_map.map_priv_1 =
+		(unsigned long)ioremap64(small_flash_base,
+					 ebony_small_map.size);
+
+	if (!ebony_small_map.map_priv_1) {
+		printk("Failed to ioremap flash\n");
+		return -EIO;
+	}
+
+	flash = do_map_probe("map_rom", &ebony_small_map);
+	if (flash) {
+		flash->module = THIS_MODULE;
+		add_mtd_partitions(flash, ebony_small_partitions,
+					NB_OF(ebony_small_partitions));
+	} else {
+		printk("map probe failed for flash\n");
+		return -ENXIO;
+	}
+
+	ebony_large_map.map_priv_1 =
+		(unsigned long)ioremap64(large_flash_base,
+					 ebony_large_map.size);
+
+	if (!ebony_large_map.map_priv_1) {
+		printk("Failed to ioremap flash\n");
+		return -EIO;
+	}
+
+	flash = do_map_probe("cfi_probe", &ebony_large_map);
+	if (flash) {
+		flash->module = THIS_MODULE;
+		add_mtd_partitions(flash, ebony_large_partitions,
+					NB_OF(ebony_large_partitions));
+	} else {
+		printk("map probe failed for flash\n");
+		return -ENXIO;
+	}
+
+	return 0;
+}
+
+static void __exit cleanup_ebony(void)
+{
+	if (flash) {
+		del_mtd_partitions(flash);
+		map_destroy(flash);
+	}
+
+	if (ebony_small_map.map_priv_1) {
+		iounmap((void *)ebony_small_map.map_priv_1);
+		ebony_small_map.map_priv_1 = 0;
+	}
+
+	if (ebony_large_map.map_priv_1) {
+		iounmap((void *)ebony_large_map.map_priv_1);
+		ebony_large_map.map_priv_1 = 0;
+	}
+}
+
+module_init(init_ebony);
+module_exit(cleanup_ebony);
+
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Ebony flash map");

Re: PATCH: support for Arctic/Beech/Ebony

[Joakim Tjernlund]

Hi

> Hello,
> 
> attached is a patch that adds MTD support for a couple of PowerPC
> boards based on the IBM440GP CPU. It also clean up the PPC
> section in the mapping drivers Config.in, making it more robust
> against configuration errors.
> 
> All code was taken directly from linuxppc_2_4_devel, and I didn't
> write it. I shall add commandline paritioning support some time soon,
> though.
> 
> If nobody objects, I will commit it to the repository.

2 comments:
  - You don't need mb() since ioremap will add the
     GUARDED attribute to the mapping.

 - Add support for point()/unpoint().

   Jocke

Re: PATCH: support for Arctic/Beech/Ebony

[David Woodhouse]

On Wed, 29 Jan 2003, Joakim Tjernlund wrote:

>  - Add support for point()/unpoint().

True, but none of the other map drivers have it yet either -- didn't we 
already do them once? What happened to it?

-- 
dwmw2

Re: PATCH: support for Arctic/Beech/Ebony

[Joakim Tjernlund]

> On Wed, 29 Jan 2003, Joakim Tjernlund wrote:
> 
> >  - Add support for point()/unpoint().
> 
> True, but none of the other map drivers have it yet either -- didn't we 
> already do them once? What happened to it?

Someone has to be first(OK I have them already in my map). I did not "do them one", maybe
you are thinking of someone else?

Re: PATCH: support for Arctic/Beech/Ebony

[David Woodhouse]

On Thu, 30 Jan 2003, Joakim Tjernlund wrote:

> Someone has to be first(OK I have them already in my map). I did not "do
> them one", maybe you are thinking of someone else?

I thought you'd added it to at least physmap.c when you committed the core 
support. I must have been imagining it -- obviously someone else hasn't 
committed it either :)

-- 
dwmw2

Re: PATCH: support for Arctic/Beech/Ebony

[Joakim Tjernlund]

> On Thu, 30 Jan 2003, Joakim Tjernlund wrote:
> 
> > Someone has to be first(OK I have them already in my map). I did not "do
> > them one", maybe you are thinking of someone else?
> 
> I thought you'd added it to at least physmap.c when you committed the core 
> support. I must have been imagining it -- obviously someone else hasn't 
> committed it either :)
Sorry, I was pressed for time when I added point support, so I never got around to it.
I can add it now, but I can't test it. OK?

          Jocke

Re: PATCH: support for Arctic/Beech/Ebony

[Joakim Tjernlund]

> 
> 
> > On Thu, 30 Jan 2003, Joakim Tjernlund wrote:
> > 
> > > Someone has to be first(OK I have them already in my map). I did not "do
> > > them one", maybe you are thinking of someone else?
> > 
> > I thought you'd added it to at least physmap.c when you committed the core 
> > support. I must have been imagining it -- obviously someone else hasn't 
> > committed it either :)
> Sorry, I was pressed for time when I added point support, so I never got around to it.
> I can add it now, but I can't test it. OK?

point/unpoint commited to physmap.c

Re: PATCH: support for Arctic/Beech/Ebony

[Marius Groeger]

On Wed, 29 Jan 2003, Joakim Tjernlund wrote:

> 2 comments:
>   - You don't need mb() since ioremap will add the
>      GUARDED attribute to the mapping.
>
>  - Add support for point()/unpoint().

All right, I did both and have just committed it to CVS.

Thanks,
Marius

-----------------------------------------------------------------------------
Marius Groeger           SYSGO Real-Time Solutions AG       mgroeger@sysgo.de
Software Engineering     Embedded and Real-Time Software    www.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14                 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com

Re: PATCH: support for Arctic/Beech/Ebony

[David Woodhouse]

mag@sysgo.de said:
> attached is a patch that adds MTD support for a couple of PowerPC
> boards based on the IBM440GP CPU. It also clean up the PPC section in
> the mapping drivers Config.in, making it more robust against
> configuration errors.

Please also update Kconfig, and add $Id$ headers to new files.

--
dwmw2

Re: PATCH: support for Arctic/Beech/Ebony

[Marius Groeger]

On Thu, 30 Jan 2003, David Woodhouse wrote:

> Please also update Kconfig, and add $Id$ headers to new files.

Done. I also added an entry for the MBX860 and some "depends on 8xx"
to the Kconfig to match the logic in Config.in.

Regards,
Marius

-----------------------------------------------------------------------------
Marius Groeger           SYSGO Real-Time Solutions AG       mgroeger@sysgo.de
Software Engineering     Embedded and Real-Time Software    www.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14                 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com

RE: PATCH: support for Arctic/Beech/Ebony

[Eugene Surovegin]

At 03:23 AM 1/30/2003, you wrote:
> > Joakim,
> >
> > At 01:46 PM 1/29/2003, you wrote:
> > >   - You don't need mb() since ioremap will add the
> > >      GUARDED attribute to the mapping.
> >
> > Well, this is not quite correct.
> >
> > GUARDED attribute does _NOT_ prevent reordering of loads and stores on PPC
> > (on 4xx at least).
> >
> > See comments in asm-ppc/system.h and also IBM app note "Software
> > consideration when migrating to the PowerPC 440GP from 405GP"
> >
>
>hmm, maybe it's specific to the 8xx family. 860 and 862 does not do
>speculative accesses on GUARDED memory.

It does! But speculative accesses and access reordering are not the same 
thing :)

There is a subtle difference.

>Me wounders what GUARDED is good for if it doesn't prevent reordering.

I think it's a FAQ for PPC devel list :)

Eugene.

Re: PATCH: support for Arctic/Beech/Ebony

[Joakim Tjernlund]

Hi again :-)

> At 03:23 AM 1/30/2003, you wrote:
> > > Joakim,
> > >
> > > At 01:46 PM 1/29/2003, you wrote:
> > > >   - You don't need mb() since ioremap will add the
> > > >      GUARDED attribute to the mapping.
> > >
> > > Well, this is not quite correct.
> > >
> > > GUARDED attribute does _NOT_ prevent reordering of loads and stores on PPC
> > > (on 4xx at least).
> > >
> > > See comments in asm-ppc/system.h and also IBM app note "Software
> > > consideration when migrating to the PowerPC 440GP from 405GP"
> > >
> >
> >hmm, maybe it's specific to the 8xx family. 860 and 862 does not do
> >speculative accesses on GUARDED memory.
> 
> It does! But speculative accesses and access reordering are not the same 
> thing :)

what do you mean, does or does not do speculative accesses?

> 
> There is a subtle difference.

Yes I understand now, but I discussed this with my HW contact at Motorola and he agreed
that it was OK to remove the mb(). Maybe he was wrong or perhaps non speculative accesses
on mpc 860/862 also disables reorder? I can not find any statement that confirms this.

Howerver I have been running our boards without the mb()'s for months now, no problem with
it so far.

   Jocke

PS.
      Does the PREEMPT patch still work for you? I havn't seen any problems here yet.
 

Re: PATCH: support for Arctic/Beech/Ebony

[Eugene Surovegin]

At 02:37 PM 1/30/2003, Joakim Tjernlund wrote:

> > > > >   - You don't need mb() since ioremap will add the
> > > > >      GUARDED attribute to the mapping.
> > > >
> > > > Well, this is not quite correct.
> > > >
> > > > GUARDED attribute does _NOT_ prevent reordering of loads and stores 
> on PPC
> > > > (on 4xx at least).
> > > >
> > > > See comments in asm-ppc/system.h and also IBM app note "Software
> > > > consideration when migrating to the PowerPC 440GP from 405GP"
> > > >
> > >
> > >hmm, maybe it's specific to the 8xx family. 860 and 862 does not do
> > >speculative accesses on GUARDED memory.
> >
> > It does! But speculative accesses and access reordering are not the same
> > thing :)
>
>what do you mean, does or does not do speculative accesses?

Sorry for being unclear.

If I remember correctly, cache inhibited + guarded is enough for 8xx to 
prevent both speculative access and load/store reordering.
But this is not true for ALL PPC processors, 440GP is an example when this 
is not enough


> >
> > There is a subtle difference.
>
>Yes I understand now, but I discussed this with my HW contact at Motorola 
>and he agreed
>that it was OK to remove the mb(). Maybe he was wrong or perhaps non 
>speculative accesses
>on mpc 860/862 also disables reorder? I can not find any statement that 
>confirms this.
>
>Howerver I have been running our boards without the mb()'s for months now, 
>no problem with
>it so far.

Well, patch we are discussing is for 4xx, not for 8xx.

Eugene.

Re: PATCH: support for Arctic/Beech/Ebony

[Joakim Tjernlund]

> At 02:37 PM 1/30/2003, Joakim Tjernlund wrote:
> 
> > > > > >   - You don't need mb() since ioremap will add the
> > > > > >      GUARDED attribute to the mapping.
> > > > >
> > > > > Well, this is not quite correct.
> > > > >
> > > > > GUARDED attribute does _NOT_ prevent reordering of loads and stores 
> > on PPC
> > > > > (on 4xx at least).
> > > > >
> > > > > See comments in asm-ppc/system.h and also IBM app note "Software
> > > > > consideration when migrating to the PowerPC 440GP from 405GP"
> > > > >
> > > >
> > > >hmm, maybe it's specific to the 8xx family. 860 and 862 does not do
> > > >speculative accesses on GUARDED memory.
> > >
> > > It does! But speculative accesses and access reordering are not the same
> > > thing :)
> >
> >what do you mean, does or does not do speculative accesses?
> 
> Sorry for being unclear.
NP
> 
> If I remember correctly, cache inhibited + guarded is enough for 8xx to 
> prevent both speculative access and load/store reordering.

OK, thanks.

> But this is not true for ALL PPC processors, 440GP is an example when this 
> is not enough
> 
> 
> > >
> > > There is a subtle difference.
> >
> >Yes I understand now, but I discussed this with my HW contact at Motorola 
> >and he agreed
> >that it was OK to remove the mb(). Maybe he was wrong or perhaps non 
> >speculative accesses
> >on mpc 860/862 also disables reorder? I can not find any statement that 
> >confirms this.
> >
> >Howerver I have been running our boards without the mb()'s for months now, 
> >no problem with
> >it so far.
> 
> Well, patch we are discussing is for 4xx, not for 8xx.

Yes, so the mb()'s should be put back.

Marius, sorry for the noise.

   Jocke
> 
> Eugene.

Re: PATCH: support for Arctic/Beech/Ebony

[Marius Groeger]

On Fri, 31 Jan 2003, Joakim Tjernlund wrote:

> Yes, so the mb()'s should be put back.
>
> Marius, sorry for the noise.

No worries. It's back in there. :-)

Regards,
Marius

-----------------------------------------------------------------------------
Marius Groeger           SYSGO Real-Time Solutions AG       mgroeger@sysgo.de
Software Engineering     Embedded and Real-Time Software    www.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14                 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com