[U-Boot-Users] AMCC 440EP Nand flash Problem

[Bradley Remedios]

Hello All,

I am having a rather curious problem with using NAND flash on the AMCC 440EP.

My platform boots entirely from NAND Flash, as such, I have modified
U-Boot to run from SDRAM and created a small Bootloader that
initializes the board and loads U-Boot from NAND to SDRAM where it
sets U-Boot running.

I've gotten it to a state where I can load U-Boot via a debugger
(RiscWatch) into SDRAM and program NAND with both my small bootloader
and U-Boot.  This all works.

Now when U-Boot is loaded from NAND to SDRAM using a small bootloader
it cannot read the Manufacturer or Chip ID from the NAND flash chip so
it bails out.  This does not happen when loading the exact same U-Boot
image from the RiscWatch to SDRAM and running it.

Using a LogicAnalyzer, I have narrowed down the problem to something
that has me stumped that I hope someone here can help me with or point
me in the right direction.

The Code in common/cmd_nand.c that identifies the chip basically does
the following:

Resets NAND.
Waits for NAND to become READY
Write READ ID Command
Writes Address byte 0
Read Manfacturer ID
Read Chip ID

When loaded under the RiscWatch we see the following:
   CLE pulses as WE pulses [Reset of NAND Chip]
   READY goes low
   READY goes high (approx 120ns after going low)
   CLE pulses as WE pulses [READ ID Command]
   ALE pulses as WE Pulses [Write Address byte 0]
   2 Read Pulses

This is as expected and all works.

When loaded under the bootloader from NAND we see the following:
   4 Read Pulses
   CLE pulses as WE pulses [Reset of NAND Chip]
   READY goes low
   READY goes high (approx 120ns after going low)
   CLE pulses as WE pulses [READ ID Command]
   ALE pulses as WE Pulses [Write Address byte 0]

This is un-expected and does not work.  I did not expect the 4 read
pulses, and there are absolutly no read pulses (like the 2 expected)
after we write the address byte 0.

Does anyone have any ideas as to what could be going wrong?  Any help
is greatly appreciated.
-- 
Bradley Remedios
bremedios at gmail.com