From owner-freebsd-embedded@FreeBSD.ORG  Fri Nov 15 19:13:17 2013
Return-Path: <owner-freebsd-embedded@FreeBSD.ORG>
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 <kristof@sigsegv.be>
To: Ian Lepore <ian@FreeBSD.org>
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 <gber@FreeBSD.org>, freebsd-embedded@FreeBSD.org
X-BeenThere: freebsd-embedded@freebsd.org
X-Mailman-Version: 2.1.16
Precedence: list
List-Id: Dedicated and Embedded Systems <freebsd-embedded.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-embedded>, 
 <mailto:freebsd-embedded-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-embedded/>
List-Post: <mailto:freebsd-embedded@freebsd.org>
List-Help: <mailto:freebsd-embedded-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-embedded>, 
 <mailto:freebsd-embedded-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Nov 2013 19:13:17 -0000

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.

Regards,
Kristof