Re: [PATCH] MTD for Taco

Stefan Roese wrote:

On Saturday 05 January 2008, Sean MacLennan wrote:
  

quoted

This patch adds the maps for the taco. It also gets the ndfc.c NAND
driver in a compilable state. The map is guaranteed to change since the
exact NOR/NAND flash configuration is in flux right now when we found
the 256M NAND flash won't boot properly.

Currently it configures the NOR in a reasonable fashion and leaves the
NAND as one honkin' parition.
    

<snip>

  

quoted

diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 1c0e89f..f5e93cf 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c

@@ -24,11 +24,6 @@
 #include <linux/platform_device.h>
 
 #include <asm/io.h>
-#ifdef CONFIG_40x
-#include <asm/ibm405.h>
-#else
-#include <asm/ibm44x.h>
-#endif
    

You do break arch/ppc support with this patch. We have to still support
arch/ppc a few month, so please don't break this support for now.
  

Gotcha. Is CONFIG_PPC_MERGED the right flag for things like this?

quoted

 struct ndfc_nand_mtd {
        struct mtd_info                 mtd;

@@ -110,6 +105,40 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
        return 0;
 }
 
+#ifdef CONFIG_TACO
+/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
+ * the taco!
+ */
    

We definitely don't want to see such board specific stuff in the common
NDFC driver. And I really doubt that you need this change for your board.
We are using this ndfc driver on multiple boards, and all have no
problems accessing the controller with 32bit read/writes. So you most
likely have a problem with your board port. Perhaps something with
with the EBC setup. Please re-check and compare with boards that are know
to work, like Sequoia.

  

Does the Sequoia use a Rev C chip? We had to modify u-boot the same way. 
As soon as we do an 8-bit access we get a machine check exception.

To be honest, I don't know what more to check.

quoted

+static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+       struct ndfc_controller *ndfc = &ndfc_ctrl;
+       uint8_t *p = (uint8_t *) buf;
+
+       for(;len > 0; len -= 1)
+               *p++ = __raw_readb(ndfc->ndfcbase + NDFC_DATA);
+}
+
+static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int
len) +{
+       struct ndfc_controller *ndfc = &ndfc_ctrl;
+       uint8_t *p = (uint8_t *) buf;
+
+       for(;len > 0; len -= 1)
+               __raw_writeb(*p++, ndfc->ndfcbase + NDFC_DATA);
+}
+
+static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int
len) +{
+       struct ndfc_controller *ndfc = &ndfc_ctrl;
+       uint8_t *p = (uint8_t *) buf;
+
+       for(;len > 0; len -= 1)
+               if (*p++ != __raw_readb(ndfc->ndfcbase + NDFC_DATA))
+                       return -EFAULT;
+
+       return 0;
+}
+#else
    

<snip>

  

quoted

+++ drivers/mtd/maps/taco.c     2008-01-02 13:07:43.000000000 -0500

@@ -0,0 +1,140 @@
+/*
+ * $Id: $
+ *
+ * drivers/mtd/maps/taco.c
+ *
+ * Mapping for PIKA Taco flash
    

I'm pretty sure that you don't need a board specific mapping driver
for NOR flash. physmap_of should be exactly what you need. You just need
to fill the device tree properties correctly.
  

Yes, this was copied straight from the PPC port. The whole NOR/NAND 
flash is in flux. Marketing really really wants to drop NOR for price 
reasons. So I will probably leave this until a final decision is made.

BTW: I noticed you are using the boot wrapper approach. This is not
necessary anymore, since the latest U-Boot version has flattened
device tree support included for 4xx too. Let me know if you have any
questions about this.
  

I did this port over Christmas and had no access to the hardware guys so 
I stayed away from u-boot since I had no way to recover from mistakes. I 
hope to make towards the tree image approach but for now the in-kernel 
version is much easier for me to work with.

Cheers,
    Sean