From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 15 19:47:54 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C2D26DA; Fri, 15 Nov 2013 19:47:54 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6276A2124; Fri, 15 Nov 2013 19:47:54 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VhPMv-0001dO-BP; Fri, 15 Nov 2013 19:47:53 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rAFJlouT075245; Fri, 15 Nov 2013 12:47:50 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18r3+LV5bbLsqdp1OtBL0nd Subject: Re: Incorrect struct onfi_params definition From: Ian Lepore To: Kristof Provost 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> Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Nov 2013 12:47:50 -0700 Message-ID: <1384544870.31172.420.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Grzegorz Bernacki , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 19:47:54 -0000 On Fri, 2013-11-15 at 20:13 +0100, Kristof Provost wrote: > On 2013-11-15 10:39:13 (-0700), Ian Lepore 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