Jonathan McDowell wrote:
> On Thu, Mar 26, 2009 at 10:31:35PM +0000, Chris Jones wrote:
> 
>> - are we currently trying to run NAND bus cycles too fast? This is
>> moderately unlikely since we slowed it down hugely to make the minipug
>> LCDs work over Samosa, unless Jim was running an old bootldr.
> 
> As Jim has said, he wasn't running the new bootldr, so it's quite
> possible that would have sorted things out.

I had a look at the data sheet for the NAND chips and they seem to be
able to cope with nRE and nWE pulse lengths of 15ns, compared with the
200+ns that the minipugs need, so I doubt we're at risk of running the
bus too fast with them!

>> - do we want to observe NAND_RNB in hardware (thus locking up the bus
>> while the NAND gets its act together) or in software? I'm not even
>> sure that this is an appropriate question to ask, but someone else may
>> have a quick answer before I go and grub around in data sheets and
>> kernel source.
> 
> Hooking up support for a NAND ready line in the kernel mtd driver is
> easy; I hadn't realised we weren't already doing that. I can't actually
> see where NAND_RNB gets mapped to for reading though?

Again, my look at the data sheet shows that NAND_RNB really means 'this
chip is doing something time-consuming internally' rather than 'hold the
bus while I sort my registers out', so it should be observed in
software, not VLIO hardware.

At the moment, NAND_RNB goes precisely nowhere in the hardware,
according to the VHDL I'm looking at. We can fix that. It appears that
the CPLD/FPGA doesn't have a readable control register, so we'll have to
give it one. This may be an opportunity to make some of the other
control signals (NAND/IO parking and so on) read-back-able, too, though
at the risk of introducing firmware version/kernel version nightmares.

Chris

-- 
Chris Jones - chris@martin-jones.com
Martin-Jones Technology Ltd, makers of Solidlights
148 Catharine Street, Cambridge, CB1 3AR, UK
Phone +44 (0) 1223 655611 Fax +44 (0) 870 112 3908
http://www.solidlights.co.uk/