From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 15 19:13:17 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54A0FAAD; Fri, 15 Nov 2013 19:13:17 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1841D2F42; Fri, 15 Nov 2013 19:13:16 +0000 (UTC) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 6FE809869; Fri, 15 Nov 2013 20:13:15 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 682D73086; Fri, 15 Nov 2013 20:13:15 +0100 (CET) Date: Fri, 15 Nov 2013 20:13:15 +0100 From: Kristof Provost To: Ian Lepore Subject: Re: Incorrect struct onfi_params definition Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1384537153.31172.398.camel@revolution.hippie.lan> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 User-Agent: Mutt/1.5.22 (2013-10-16) 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:13:17 -0000 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. Regards, Kristof