Based on 9G20EK. In fact, this board is the same board as our 9260 product, just diff proc and power supply parts.

Running out of Dataflash:
- at91Bootstrap works.
- u-boot(1.1.5) that works on 9260 proc works, except for network
- u-boot(1.3.4) built for 9G20 hangs in NAND init, though my debugging tells me that its getting stuck in the call to READID.

Running out of NAND:
- neither at91bootstrap OR u-boot work (No bootstrap debug messages)

sam-ba (2.10) doesn't indicate any issues during programming of either dataflash or nand.

Any thoughts on why NAND is messing up? Remember, this circuitry's reference design is the 9260EK board, only the procs and associated power supply thingies have been changed.

The board I've worked on evolved in a similar way. Pretty much pin-for-pin compatible, except all the power supply stuff.

I guess you should double check all the supplies to the NAND (presumably a 3.3V rather than 1.8V). I've had to add support in AT91Boot for the ST and Micron NAND's we're using. If a BGA part you might want to probe the circuit (perhaps on the solder sample, look for opens, short, unconnected nets), and xray to double check the soldering. BGA's can be very problematic with via-in-pad, non-uniform fill, or solder-mask shrink. Check the pad voltages on a board without the NAND populated. Revisit any DRC failures for the schematic, revisit the nets in case you've created any unconnected islands, powers, and grounds.

Check power supply sequencing, and resets.

The fact ROMBoot can't use the part suggests the problem is pretty fundamental, rather than some random flakiness.

For the 9260 and 9G20's I've written diagnostic apps I can run/debug in SRAM or SDRAM from within Keil, and those can either test the NAND array or SDRAM.

You could write some code to read the NAND array, try some commands, check there are no stuck-at problems with the data bus or addressing.

Thanks for the pointers. I'm not sure what that tells me though, when I can access NAND using our existing "9260" dataflash version of u-boot versus the 9G20 version. About the only thing different is the clock setup.

And if I use the 9260 u-boot and bootup to a u-boot prompt, I can test nand and everything. I can't tftp any kernel images up to store there though since networking doesn't seem to work. Is there something different to watch for regarding networking? Remember, its the same base board we use successfully with the 9260.

It's a different PCB though, right? With a different solder stencil, BOM, pick-n-place?
Check the components, fit/no-fit, and that the new PCB is actually electrically sound.

Pretty sure in my discussions with the board guys, that the 9260 and 9G20 while similiar had all the supply pins juggled up, so it wasn't a matter of swapping regulators. The supply side was a complete do-over.

If it's not booting from NAND, and you think it is a software problem make sure you are writing the AT91BootStrap with the "write boot" option, not the generic write.

You can download the NAND AT91BootStrap code directly into SRAM and run it using SAM-BA to see if it works. You could also download/debug it with suitable gear. You could also download uBoot code into SDRAM.

Check your MCLK and PCLK init code, along with the SDRAM init code. Try building your 9G20 code to only run at 200 MHz, rather than 400 MHz. The AT91BootStrap is the only code that sets the processor clock, and SDRAM, in most applications.

The ethernet might also fail if the clocks are wrong, but our problems there related to critical missing parts.

From what I understand, its the same exact PCB only with different parts stuffed for the power supply(ies).

If I build the 9G20 bootstrap and u-boot to run at 200MHz instead of 400, and it runs right, what does that tell me? The PCB runs great when run with 9260, all peripherals work fine. In all honesty, the stock 9g20 bootstrap and uboot from at91.com/linux4sam should run on this hardware but they don't.

I was originally thinking maybe the nand had some timing issues because of the faster processor but that should all be taken care of internally to the software.

Your memory buses are presumably running at 100 or 133 MHz, based on your PLLs, clocks and prescalers. If you have these right the SDRAM and NAND should operate exactly the same between parts, and CPU clocks.

If the PLL is not working properly, you'll need to double check it's supplies (multiple VDDPLL, GNDPLL pins/balls), there is no PLLRCA filter on the 9G20 (ball T1), it is represented as a No Connect, so verify you don't still have anything hanging off it.

Thanks for the help. I'm talking to the HW guy now. It looks like ball T1 still has the two caps connected, the resistor has been pulled. I don't know if that's the cause of my problems or not but something doesn't seem right.