2009/3/26 Jim Rayner <
balloon@jrayner.co.uk>:
>> Out of interest, do you have CPUFREQ enabled? You might want to try
>> disabling it, as it ends up doubling the speed we talk to NAND in a way
>> that didn't happen with the 2.6.25 stuff.
>
> Many thanks, that appears to have done the trick, I've restored my root fs,
> 0 retired blocks, 0 status errors
Another thought: we (I) changed bootldr after the 2.6.29 kernel work
so that it slows down access to the NAND, Samosa and other devices on
nCS4, in order to compensate for the doubled bus speed in the new
kernel. Were you running the latest bootldr, Jim?
It sounds like this has just bumped variable latency IO for the CPLD
address space up the priority chart even further, given what we
discovered about Samosa timings the other week. I think there may be
some design issues to think about:
- 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.
- 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.
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/
(text/plain)