Incorrect struct onfi_params definition

[Ian Lepore]

On Fri, 2013-11-15 at 20:13 +0100, Kristof Provost wrote:
> On 2013-11-15 10:39:13 (-0700), Ian Lepore <ian at FreeBSD.org> wrote:
> > On Wed, 2013-11-13 at 23:32 +0100, kristof at sigsegv.be wrote:
> > > Hi Ian,
> > > 
> > > Here's my attempt at a cleaned up patch series.
> > > 
> > > It doesn't include the delay modifications from your nand2.diff, as that
> > > didn't actually work for me.  On my OpenRD is appears that the time tick is
> > > started after the NAND initialisation, leading to infinite delays.  
> > > 
> > 
> > I'm interested in hearing more about this.  I don't quite understand
> > what you mean by "time tick is started after...".  The delay-related
> > changes should completely remove all use of clocks or timing.  What it
> > does instead is repeatedly issue "get status" commands to the chip until
> > the chip says it's done with the previous operation and ready to
> > continue.  
> > 
> Actually, it's probably a combination of two problems.
> 
> I get a timeout while reading the parameter page, or rather, I'm
> supposed to get a timeout, but nandbus_wait_ready() uses getmicrotime(),
> which always returns 0. In effect it creates an infinite loop.
> 
> The fact that there's never a NAND_STATUS_RDY after the
> NAND_CMD_READ_PARAMETER is interesting, but not really the point here.
> 
> As I understand it getmicrotime() (at least when FFCLOCK is not defined)
> is not updated until after inittimecounter(), which is done after the
> nand initialisation.

Oh.  Hmm, I had forgotten I put a timeout in that loop.  Shame on me, I
guess, for trying to base it on an actual clock instead doing the usual
"count down from a number with an arbitrary number of zeroes at the end"
that doesn't scale properly across the range of processor speeds we
support today. :)  I'll ponder a good fix (maybe keep using the clock
but fall back to a counter if the clock isn't running).

You're right, the real question is why you never get the ready status.
The timeout logic is just a crisis fallback, because I hate drivers that
lock up forever on the assumption that something "can't fail."  But
getting the status really shouldn't fail.

Is it only the parameter-read that has this problem, or do regular reads
and writes fail to get status too?  Maybe there's something in the
marvell nand flash interface that leads to this; I did my work on an
Atmel SoC (but I do have a Dreamplug here that has nand flash on it,
it's sort of a Guruplug in a Dreamplug case; not many were shipped).

-- Ian