Date: Fri, 15 Nov 2013 12:47:50 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Kristof Provost <kristof@sigsegv.be> Cc: Grzegorz Bernacki <gber@FreeBSD.org>, freebsd-embedded@FreeBSD.org Subject: Re: Incorrect struct onfi_params definition Message-ID: <1384544870.31172.420.camel@revolution.hippie.lan> In-Reply-To: <20131115191315.GF58987@vega.codepro.be> References: <1383782353.31172.183.camel@revolution.hippie.lan> <1384381960-98851-1-git-send-email-kristof@sigsegv.be> <1384537153.31172.398.camel@revolution.hippie.lan> <20131115191315.GF58987@vega.codepro.be>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2013-11-15 at 20:13 +0100, Kristof Provost wrote: > On 2013-11-15 10:39:13 (-0700), Ian Lepore <ian@FreeBSD.org> wrote: > > On Wed, 2013-11-13 at 23:32 +0100, kristof@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1384544870.31172.420.camel>