On Monday 16 November 2009, Dean Glazeski wrote: > Hi all, > > I wanted to check on something. I've got my AT91SAM9260 reading from a NAND > flash device and I wanted to make sure the configuration interface wasn't > too ridiculous. Here is the current set of commands to properly configure > an Olimex SAM9-L9260 board for flashing (the code to initialize the > peripherals to talk to NAND is ommitted and is just a set of mww in the > reset-init script).
Glad to see such code appearing. It's kind of finicky. :) > nand device at91sam9 at91sam9260.cpu 0x40000000 ;# create controller with > NAND data address at 0x40000000 > at91sam9 cle 0 22 ;# address line 22 is the command latch enable line > at91sam9 ale 0 21 ;# address line 21 is the address latch enable line > at91sam9 rdy_busy 0 0xfffff800 13 ;# ready/~busy input comes from pin 13 of > PIOC > at91sam9 ce 0 0xfffff800 14 ;# chip enable output connected at pin 14 of PIOC > > Does this seem reasonable? I'd be tempted to feed all the params in via "nand device", so they can't get lost. That "0" is to specify NAND chip 0, yes? That will also be implicit in "nand device". Maybe use "name=value" syntax to avoid being as opaque as many other drivers. The messy bits are needing to specify GPIOs for RDY_BUSY and CE. And I think to do that generically you'd have to use that same kind of "controller base, bit number" addressing. > Would this work for the majority of SAM9s out there? The ones I happen to have seen, yes. But isn't this driver going to be misnamed? Same driver should work for SAM3, yes? So it should be "at91sam". Or ... since the same thing will work for AVR32, if we ever get that support into OpenOCD, maybe just "atmel_nand". - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
