"NAND on UPM" and related patches

Hi all,

Here are patches to support NAND on UPM. That driver is generic for all processors with FSL UPMs. And because of that, few more patches are needed -- GPIO API and generic FSL UPM functions.

This is early RFC, all patches are in single thread, so everyone could make up overall picture of what is going on. I'll split the thread by topics after that RFC.

Ok, the patches and what they are for:

1,2,3,4. GPIO API:
------------------
Usually NAND chips exports RNB (Ready-Not-Busy) pin, so drivers could read it and get a hint when chip is ready.

Often, WP (write protect) pin is also connected to GPIO. So, GPIO API is mandatory for generic drivers.

OF device tree GPIOs bindings are similar to IRQs:

node {
	gpios = <bank pin bank pin bank pin>;
	gpio-parent = <&par_io_controller>;
};

"bank pin" scheme is controller specific, so controllers that want to implement flat mappings or any other could do so.

So far I implemented GPIO API for QE and CPM2 chips.

QE GPIO API tested to work with FSL UPM NAND driver and MPC8360E-RDK (STMicro NAND512W3A2BN6E).

CPM2 GPIO API tested to work with MPC8555E+Samsung HY27UF081G6 (LP).

GPIO API is described in Documentation/gpio.txt, and these patches are tend to support most of it.

As an additional bonus, PowerPC now gets access to few pleasing drivers:

- drivers/leds/leds-gpio.c (we could use it to play with on-board LEDs);
- drivers/i2c/busses/i2c-gpio.c (generic I2C bit-banging driver);
- drivers/input/keyboard/gpio_keys.c - gpio keys (requires gpio_to_irq, so far not implemented);
- Could be more (I named the ones I knew about).

Also, in the upcoming kernels, there will be GPIOLIB[1] addition to the generic GPIO API, to support off-chip GPIO expanders (like MFDs on I2C/LBC).

[1] http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/generic-gpio-gpio_chip-support.patch

But so far we support on-chip GPIOs only.

5 - FSL UPM infrastructure:
---------------------------
UPM address register is shared among UPMs, so we have to do proper locking. On the other hand, if we know that specific board using only one UPM we could bypass locking, and gain some performance win.

6. FSL UPM NAND driver:
-----------------------
It's using FSL UPM functions and GPIO API. It does not implement device tree partitions parsing. That issue is completely other matter, that is, I have to factor out parsing functions from physmap_of.c. This desires separate patch on top of the whole series. If anyone currently working on this, let me know.

7. Example of usage.
--------------------
MPC8360E-RDK as an example.

I would appreciate any comments and suggestions, thanks!

Anton Vorontsov
email: [email protected]
backup email: [email protected]
irc://irc.freenode.net/bd2

This patch implements GPIO API as described in Documentation/gpio.txt. Two calls unimplemented though: irq_to_gpio and gpio_to_irq.

I'm also providing OF helpers.

---
 arch/powerpc/Kconfig             |    4 +++
 arch/powerpc/kernel/prom_parse.c |   50 +++++++++++++++++++++++++++++++++++++
 include/asm-powerpc/gpio.h       |   51 ++++++++++++++++++++++++++++++++++++++
 include/asm-powerpc/prom.h       |   23 +++++++++++++++++
 4 files changed, 128 insertions(+), 0 deletions(-)
 create mode 100644 include/asm-powerpc/gpio.h

index 232c298..596982f 100644
@@ -73,6 +73,10 @@ config GENERIC_FIND_NEXT_BIT
 	bool
 	default y
 
+config GENERIC_GPIO
+	bool
+	default n
+
 config ARCH_NO_VIRT_TO_BUS
 	def_bool PPC64
 

index 925e2d3..019af61 100644
@@ -326,6 +326,29 @@ extern int of_irq_to_resource(struct device_node *dev, int index,
  */
 extern void __iomem *of_iomap(struct device_node *device, int index);
 
+/**
+ * __of_parse_gpio_bank_pin - Helper function to translate "bank pin" GPIOs
+ * @np:		device node to get GPIO from
+ * @index:	index of the GPIO
+ * @bank_width:	pins per bank
+ * @max_bank:	maximum value to represent a bank
+ *
+ * Returns GPIO number to use with Linux generic GPIO api, or
+ * one of the errno value on the error condition.
+ */
+extern int __of_parse_gpio_bank_pin(struct device_node *np, int index,
+				    int bank_width, int max_bank);
+
+/**
+ * of_get_gpio - Translate GPIO number given in the device tree
+ * @np:		device node to get GPIO from
+ * @index:	index of the GPIO
+ *
+ * Returns GPIO number to use with Linux generic GPIO API, or
+ * one of the errno value on the error condition.
+ */
+extern int of_get_gpio(struct device_node *np, int index);
+
 /*
  * NB:  This is here while we transition from using asm/prom.h
  * to linux/of.h

1.5.2.2

Thanks, fill fix.

This is low-level helper/library function, used by gpio controllers to parse "bank pin" gpio = <> scheme. To denote that this isn't some kind of API leading underscores are used.

Because <asm/gpio.h> should be used by all architectures to match generic GPIO API. asm-sh/gpio.h asm-arm/gpio.h asm-avr32/gpio.h and so on.

The only thing I can place into of.h is
- - - -
/*
* OF specific gpio_chip handler.
*/

struct of_gpio_chip {
        int (*xlate)(struct device_node *np, int index);
};

- - - -

But frankly speaking, of_gpio_chip could be architecture-specific too.

Anton Vorontsov
email: [email protected]
backup email: [email protected]
irc://irc.freenode.net/bd2

---
 arch/powerpc/platforms/Kconfig     |    1 +
 arch/powerpc/sysdev/qe_lib/qe_io.c |   93 +++++++++++++++++++++++++++++++++++-
 2 files changed, 92 insertions(+), 2 deletions(-)

index ea22cad..3d9ff27 100644
@@ -265,6 +265,7 @@ config TAU_AVERAGE
 config QUICC_ENGINE
 	bool
 	select PPC_LIB_RHEAP
+	select GENERIC_GPIO
 	help
 	  The QUICC Engine (QE) is a new generation of communications
 	  coprocessors on Freescale embedded CPUs (akin to CPM in older chips).

1.5.2.2

---
 arch/powerpc/platforms/Kconfig    |    1 +
 arch/powerpc/sysdev/cpm2_common.c |  142 +++++++++++++++++++++++++++++++++++++
 2 files changed, 143 insertions(+), 0 deletions(-)

index 3d9ff27..cc2d54e 100644
@@ -277,6 +277,7 @@ config CPM2
 	default n
 	select CPM
 	select PPC_LIB_RHEAP
+	select GENERIC_GPIO
 	help
 	  The CPM2 (Communications Processor Module) is a coprocessor on
 	  embedded CPUs made by Freescale.  Selecting this option means that

1.5.2.2

Hi Anton,

Yup, found this just after posting. ;-) I've tried to move as much as possible out of spinlocked section, but done it obviously wrong. Will fix.

Anyhow, much thanks for looking into this.

Anton Vorontsov
email: [email protected]
backup email: [email protected]
irc://irc.freenode.net/bd2

---

Hello David,

I'm interested in your opinion about that patch. You're also Cc'ed to patch that using that feature.

I know, currently that patch will conflict with GPIOLIB patches in -mm, so this is only RFC.

 include/asm-generic/gpio.h |   47 ++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 47 insertions(+), 0 deletions(-)

index 2d0aab1..cf76a69 100644
@@ -1,6 +1,53 @@
 #ifndef _ASM_GENERIC_GPIO_H
 #define _ASM_GENERIC_GPIO_H
 
+#ifndef CONFIG_GENERIC_GPIO
+
+/*
+ * Drivers could be gpio api aware, and at the same time, some
+ * of them can live without it, or support call-backs approach
+ * in addition. Let them link.
+ */
+static inline int gpio_request(unsigned int gpio, const char *label)
+{
+	return -ENOSYS;
+}
+
+static inline void gpio_free(unsigned int gpio)
+{
+}
+
+static inline int gpio_direction_input(unsigned int gpio)
+{
+	return -ENOSYS;
+}
+
+static inline int gpio_direction_output(unsigned int gpio, int value)
+{
+	return -ENOSYS;
+}
+
+static inline int gpio_get_value(unsigned int gpio)
+{
+	return -ENOSYS;
+}
+
+static inline void gpio_set_value(unsigned int gpio, int value)
+{
+}
+
+static inline int gpio_to_irq(unsigned int gpio)
+{
+	return -ENOSYS;
+}
+
+static inline int irq_to_gpio(unsigned int irq)
+{
+	return -ENOSYS;
+}
+
+#endif /* CONFIG_GENERIC_GPIO */
+
 /* platforms that don't directly support access to GPIOs through I2C, SPI,
  * or other blocking infrastructure can use these wrappers.
  */

1.5.2.2

The point of CONFIG_GENERIC_GPIO is to be *the* conditional used to tell whether that programming interface is available ... starting from "#include <asm/gpio.h>", and including all gpio_*() calls.

So my first reaction is to not like this patch. It changes semantics in an incompatible way. And AFAICT, needlessly so.

What other options did consider? Like, why not #ifdef the GPIO parts of that NAND driver, or have the whole driver depend on GENERIC_GPIO?

- Dave

Why incompatible? gpio-aware drivers will get -ENOSYS on gpio_request, thus they will not do anything wrong. GPIO-only drivers could still depend on GENERIC_GPIO, and their behaviour will not change.

Hehe, it's used to avoid #ifdef hell indeed. ;-) And no-op wrappers like that I purposed is widely used to avoid #ifdefs. They will just optimize away.

Well, this is an option, and I was considering this. Further more, I implemented gpio api for all platforms which currently using fsl upm nand, so in theory I can add "depends on GENERIC_GPIO".

But the thing is: some drivers don't actually *require* gpios, they can use it, but at the same time they might live without it.

As for fsl upm nand (the user of that change), it can poll status from the nand chip instead of looking for RNB gpio. So, strict depending on GENERIC_GPIO looks weird in that case.

Thanks,

Anton Vorontsov
email: [email protected]
backup email: [email protected]
irc://irc.freenode.net/bd2

If you still want this, I think a better approach would be:

http://marc.info/?l=linux-kernel&m=120295461410848&w=2

That is, #include <linux/gpio.h> and have *that* do the relevant switch, based on GENERIC_GPIO. No semantic changes at all, if one discounts the implicit switch to <linux/gpio.h> (important for platforms that don't *have* any <asm/gpio.h> header), which won't affect any existing code.

So your NAND code could use that, and work equally well on SOC variants that have generic GPIOs and those that don't.

Comments?

- Dave

I like it. :-) Thanks.

p.s. would be great to see this in 2.6.25, so we can start use this include for the new code.

Anton Vorontsov
email: [email protected]
backup email: [email protected]
irc://irc.freenode.net/bd2

Here are few routines needed to manage FSL UPMs properly. FSL UPM infrastructure also supports lockless variant, to use when we're pretty sure that only one UPM is used on the board.

---
 arch/powerpc/Kconfig          |    7 +++
 arch/powerpc/sysdev/Makefile  |    1 +
 arch/powerpc/sysdev/fsl_upm.c |   74 +++++++++++++++++++++++++++++
 include/asm-powerpc/fsl_upm.h |  102 +++++++++++++++++++++++++++++++++++++++++
 4 files changed, 184 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/sysdev/fsl_upm.c
 create mode 100644 include/asm-powerpc/fsl_upm.h

index 596982f..1d47a35 100644
@@ -464,6 +464,13 @@ config FSL_PCI
  	bool
 	select PPC_INDIRECT_PCI
 
+config FSL_UPM
+	bool
+
+config FSL_UPM_LOCKLESS
+	depends on FSL_UPM
+	bool
+
 # Yes MCA RS/6000s exist but Linux-PPC does not currently support any
 config MCA
 	bool

index 99a77d7..98dbfdd 100644
@@ -12,6 +12,7 @@ obj-$(CONFIG_U3_DART)		+= dart_iommu.o
 obj-$(CONFIG_MMIO_NVRAM)	+= mmio_nvram.o
 obj-$(CONFIG_FSL_SOC)		+= fsl_soc.o
 obj-$(CONFIG_FSL_PCI)		+= fsl_pci.o
+obj-$(CONFIG_FSL_UPM)		+= fsl_upm.o
 obj-$(CONFIG_TSI108_BRIDGE)	+= tsi108_pci.o tsi108_dev.o
 obj-$(CONFIG_QUICC_ENGINE)	+= qe_lib/
 obj-$(CONFIG_PPC_BESTCOMM)	+= bestcomm/

1.5.2.2

It's using FSL UPM infrastructure. So far only 8 bit accessors are implemented.

---
 drivers/mtd/nand/Kconfig   |    7 +
 drivers/mtd/nand/Makefile  |    1 +
 drivers/mtd/nand/fsl_upm.c |  310 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 318 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/nand/fsl_upm.c

index 246d451..910b4d5 100644
@@ -306,4 +306,11 @@ config MTD_ALAUDA
 	  These two (and possibly other) Alauda-based cardreaders for
 	  SmartMedia and xD allow raw flash access.
 
+config MTD_NAND_FSL_UPM
+	tristate "MTD driver for NAND on Freescale UPM"
+	depends on MTD_NAND && FSL_UPM
+	help
+	  Enables support for NAND Flash wired to Freescale processors'
+	  localbus with pre-programmed User-Programmable Machine.
+
 endif # MTD_NAND

index 3ad6c01..d553ea3 100644
@@ -29,5 +29,6 @@ obj-$(CONFIG_MTD_NAND_CM_X270)		+= cmx270_nand.o
 obj-$(CONFIG_MTD_NAND_BASLER_EXCITE)	+= excite_nandflash.o
 obj-$(CONFIG_MTD_NAND_PLATFORM)		+= plat_nand.o
 obj-$(CONFIG_MTD_ALAUDA)		+= alauda.o
+obj-$(CONFIG_MTD_NAND_FSL_UPM)		+= fsl_upm.o
 
 nand-objs := nand_base.o nand_bbt.o

1.5.2.2

---
 arch/powerpc/boot/dts/mpc836x_rdk.dts     |   24 +++++++++++++++++++++++-
 arch/powerpc/platforms/83xx/Kconfig       |    2 ++
 arch/powerpc/platforms/83xx/mpc836x_rdk.c |    1 +
 3 files changed, 26 insertions(+), 1 deletions(-)

index a1b2da6..f57ba53 100644
@@ -115,7 +115,7 @@
 			device_type = "ipic";
 		};
 
-		par_io@1400 {
+		qe_pio: par_io@1400 {
 			reg = <0x1400 0x100>;
 			num-ports = <7>;
 		};

@@ -229,4 +229,26 @@
 			interrupt-parent = <&ipic>;
 		};
 	};
+
+	localbus@e0005000 {
+		#address-cells = <2>;
+		#size-cells = <1>;
+		compatible = "fsl,mpc8360erdk-localbus",
+			     "fsl,mpc8360e-localbus",
+			     "fsl,pq2pro-localbus";
+		reg = <0xe0005000 0xd8>;
+		ranges = <1 0 0x60000000 1>;
+
+		nand-flash@1,0 {
+			compatible = "STMicro,NAND512W3A2BN6E", "fsl,upm-nand";
+			reg = <1 0 1>;
+			upm = "A";
+			upm-addr-offset = <16>;
+			upm-cmd-offset = <8>;
+			gpios = <4 18>;
+			gpio-parent = <&qe_pio>;
+			wait-pattern;
+			wait-write;
+		};
+	};
 };

index 98f6358..2fc60c1 100644
@@ -54,6 +54,7 @@ config MPC836x_RDK
 	bool "Freescale/Logic MPC836x RDK"
 	select DEFAULT_UIMAGE
 	select QUICC_ENGINE
+	select FSL_UPM_LOCKLESS
 	help
 	  This option enables support for the MPC836x RDK Processor Board,
 	  also known as ZOOM PowerQUICC Kit.

@@ -82,4 +83,5 @@ config PPC_MPC836x
 	bool
 	select PPC_UDBG_16550
 	select PPC_INDIRECT_PCI
+	select FSL_UPM
 	default y if MPC836x_MDS || MPC836x_RDK

index be9e2fd..4288e16 100644
@@ -27,6 +27,7 @@ static struct of_device_id mpc836x_rdk_ids[] = {
 	{ .type = "soc", },
 	{ .compatible = "soc", },
 	{ .type = "qe", },
+	{ .compatible = "fsl,pq2pro-localbus", },
 	{},
 };
 

1.5.2.2

Nope, 4KB min, IIRC.

Here, actually yes. The device just 8 bits wide. Reading next 8 bits will return the same value, obviously. ;-)

But points taken. I should not derivate chip width from the ranges/reg. This looks unusual indeed, will implement chip-width property.

Thanks,

Anton Vorontsov
email: [email protected]
backup email: [email protected]
irc://irc.freenode.net/bd2

It might be safest to do as is done for interrupts, and not define the internal format at all. The gpio within the gpio controller would be defined by a gpio-descriptor whose format is determined by the controller. You would need to add a #gpio-cells property in this case, so you can at least determine the size of the descriptors associated with a particular gpio controller.

David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

This is how it is done already. Take a look into second and third patches:

+static int par_io_xlate(struct device_node *np, int index) +{
+ return __of_parse_gpio_bank_pin(np, index, 32, num_par_io_ports);
+}
+
+static struct of_gpio_chip of_gpio_chip = {
+ .xlate = par_io_xlate,
+};

__of_parse_gpio_bank_pin() is helper function, I just factored it out, because both QE and CPM2 using same format.

But generally, controllers are encouraged to do their own xlates.

Or am I missing the point?

Anton Vorontsov
email: [email protected]
backup email: [email protected]
irc://irc.freenode.net/bd2

Right, but you are assuming a fixed size (2 cells?) for the bank/pin information, arent' you - I didn't see any #gpio-cells or similar looking property. I'm wondering if some gpio controllers might want less (only one bank) or more (bank, pin, polarity/flags perhaps).

David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

On Tue, Dec 11, 2007 at 11:36:47AM +1100, David Gibson wrote:
[...]

Nope, of_get_gpio() doesn't assume that, but per-controller's .xlate() is free to assume (and check) that, right.

Well, per-controller .xlate() is checking for correct cell count (just reminding -- __of_parse_gpio_bank_pin is helper function, controllers are free to implement their own):

int __of_parse_gpio_bank_pin(struct device_node *np, int index,
int bank_width, int max_bank)
{
...

        gpios = of_get_property(np, "gpios", &len);
        len /= sizeof(u32);

        if (len < 2 || len % 2 || index > len / 2 - 1)
                return -EINVAL;

...
}

On the other hand, I might indeed introduce #gpio-cells, and move that check into generic of_get_gpio(), which will use #gpio-cells. I think this is good idea anyway, so I'll just do it. ;-)

Yup, they might. With #gpio-cells or without. The matter of where to place sanity checks.

Much thanks,

Anton Vorontsov
email: [email protected]
backup email: [email protected]
irc://irc.freenode.net/bd2

Ah, ok, I see. I think doing this without an explicit '#gpio-cells' is not a great idea, though. It would be nice to be able to sanity check the "gpio descriptors" without having to deduce the correct format from the controller's "compatible" property.

David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

I've got a patch coming for that.

-Scott

Not enough to be worth the complexity compared to the overhead of NAND access -- especially in the likely case of a non-SMP build.

-Scott

I'm allowing UPM access from the IRQ handlers (because nothing prevents this, so why deny?). Thus locks are needed even on non-SMP build, on UP they aren't thrown away. Lockless variant occupy less than 30 lines of code, so I'd rather keep it.

Anton Vorontsov
email: [email protected]
backup email: [email protected]
irc://irc.freenode.net/bd2

No, it just needs to disable interrupts. Which is what locks do on non-SMP. The overhead of this is not worth 30 lines of code to avoid.

-Scott

Well, speaking of overhead. There could be a lot of fsl_upm_run_pattern calls between _start and _end. In NAND case it's maximum 3, plus they're indirect (i.e. NAND layer calls them via pointers to cmdfunc, and cmdfunc calls run_patterns). Each out_X is another sync, and all that time we're holding a lock with local IRQs disabled.

fsl upm infrastructure isn't only for NAND though, so I might imagine use cases when there might be more run_patterns between start and end.

As the compromise I might suggest this: forbid pattern_start/pattern_end from the ISRs (by marking them as might_sleep()), and replace _irqsave spinlock with simple spinlock.

That way on UP we don't lose anything, but on SMP we still have an overhead in case of single used UPM. :-/

Given that, personally I'd want to lockless variant to stay.

So, you still want to get rid of it?

Much thanks,

Anton Vorontsov
email: [email protected]
backup email: [email protected]
irc://irc.freenode.net/bd2

No, you cannot use a bare spinlock with IRQs enabled. You'll deadlock on SMP, and you'll have races with preemption enabled.

Yes, in the absence of benchmarking that shows it makes a real difference. Premature optimization being the root of all evil, and what not.

-Scott

Sorry, brain fart... obviously, with preemption on it'd disable preemption even with a plain spinlock, and on SMP without preemption it's not an issue.

Still, all you're getting rid of is the MSR twiddling, which should be pretty minor.

-Scott

On Wed, Dec 12, 2007 at 03:06:54PM -0600, Scott Wood wrote:
[...]

Benchmarking shows no difference in throughput between lock and lockless variants. This is expected of course, flashes are slow, so I can't really benchmark anything with it.

;-) Will remove it, thanks!

Anton Vorontsov
email: [email protected]
backup email: [email protected]
irc://irc.freenode.net/bd2

Hi Anton,

Apologies for not getting back sooner to comment...

We've been using a home-brewed UPM driver for our NAND for a while now. There's several issues we've hit that I figured I would share. The issues involve deficiencies of both the UPM and the NAND part itself.

We modeled our driver loosely after the suggestions in this white paper:
http://www.freescale.com/files/32bit/doc/white_paper/NANDFLASHWP.pdf?fpsp=1&WT_TYPE=WhitePapers&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation
We also connected the NAND according to the suggestions in the above document.

Something that you should be made aware of right away about the UPM - you do not have control of the logic lines all of the time. You only can control them during a transaction (in our case, a byte transaction). In other words, the time that is between reading/writing bytes, or putting the address on the bus, or asserting commands you are not able to hold the lines to a certain state. Most of the control lines coming from the UPM default to a logic 1 when unused (I believe only one defaults to a logic 0).

The first issue is timings between versions of processors. We've got one board using an MPC8349 running a 1Gb ST micro part (NAND01G-B). Another board is an MPC8347 using the same 1Gb ST micro part. After much time analyzing logic analyzer captures we found that write pulses with the 8349 had to be shifted to the left a half clock in order to properly latch the data on the bus. This was unexpected given the two boards are very similar and the processors are in the same family. I suppose the fix was easy enough, we just had to make a new version of the microcode. What's interesting is that Freescale said that there's nothing different between the two processors' UPMs. Yet there is a distinct difference between local bus behavior on the 2 cpus, our LA captures prove it.

The second issue was with interrupts during reads. We noticed that some of our boards experienced ECC errors while reading the NAND. Logic analyzer captures and debugging revealed that when an interrupt happened while the driver's read code was executing, the UPM went into an idle state, and the chip select of the part went high. This may not be a problem for other NAND parts, but for our ST Micro parts, the spec says that if CS is held high for more than 100us, the part will exit page read mode. The default state of the UPM pins are high, so when the UPM is idle all the signals are at logic 1.

Anyways, when the interrupt had completed, or driver wasn't aware that an interrupt had occurred, so it continued to do it's read loop. The ST Micro part was now in an undefined state. The page read appeared to continue just fine, but we almost always had one or more bits corrupted for the very first resuming data byte.

The fix that we ultimately did was to move the chip select control from the UPM to a GPIO from the processor. This forced the chip to never "sleep" during an interrupt, because we could keep the chip select low for the entire page read transaction. This brought up other minor issues. You must make sure that your boot loader (U-Boot in our case) sets the GPIO data BEFORE it sets the GPIO direction. Otherwise the NAND will automatically enter a start up read condition that will drive the local bus, causing anything else on the local bus (such as a NOR flash) to be useless...

The latest version of the app note online (link above) does not mention the problem you may experience with interrupts. I requested from our Freescale support contact that Freescale document this fact and make it available to others such that they won't bump into the same problems we did!

The THIRD issue we had (actually, are having) is very related to our second issue. Our customer now wants a 2Gb NAND on our board. We swapped the chip out. We included one more address byte transaction that is needed with the larger part in the driver. And it doesn't work. The part is considered to be the "bigger brother" to the 1Gb part, but apparently enough of it's state machine has changed that it doesn't tolerate the AL and CL lines going high while chip select is low. Incidentally, when debugging our second issue we were told by ST Micro support that the only time AL and CL were sampled by the NAND was when W# and R# were driven low. Had we known that the 2Gb part wouldn't have worked, we would have done much more major reworking to the NAND subsystem when we respun our board.

This mail isn't meant to be a rant. Everyone knows that this kind of low-level hardware/software work is difficult. This mail is meant to caution you against using the NAND with the UPM. Freescale may say that it works, and present you a pretty looking white paper, but it's really kludgy and you are pretty guaranteed to have problems. Please encourage your board designers to hook the NAND to some sort of CPLD device rather than the UPM. At least with a CPLD you have some real control over the state of the control lines.

If you for whatever reason are stuck with the UPM...
1.) Get your hardware people to stick inverters on the AL and CL lines. Adjust your UPM microcode accordingly.
2.) Put your CS under control of a GPIO pin.
3.) Buy a nice logic analyzer, because you're going to need it!!!

I hope this helps someone out there... I've been spending a lot of time on-and-off on this. Every time we think we have it right one little seemingly benign change throws the whole thing out the window...

Okie, happy coding,

Chris Fester