From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 18 14:12:46 2014 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 85FAD623 for ; Tue, 18 Mar 2014 14:12:46 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4D50874C for ; Tue, 18 Mar 2014 14:12:46 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id as1so7196921iec.31 for ; Tue, 18 Mar 2014 07:12:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HBmcIw3LZ4EjkVlLH1RaV0D8UnviVEG9mKTIXdDbpts=; b=WcmwFtL3YkbNZHT3EA7FFNRlm00xbo01xjnj/omlb38ll2mgq/GxQKnb06p/gC7jfF k+50pzOg+5SI+9+6/e1D8u7YUq8vIxv/gjKKovMqDcNu1ch3rhFaSvwPSFpWrSwJegmy 40I+nDZTNcM5/xi2ji9L3N0J1btbsvnC7TnVLP/YQc3z6O6wzAur0LRGGKDYyc3CnG/u TJ7ze2TR2dNqGRsdtr4VFDpAq5/JsL2iVgHEycJ0qBnkkghYwBa5WB3y5NNu5zPrPQVd w6fkrtlk8v/QxeCSakjF3fNLeaajlJx9pGgAyUY8o84nqJtDIt5eSNJsdu4F8vrf9Qzr qupA== X-Gm-Message-State: ALoCoQnnRBv/B72UDln692Qca2s1i7phxNbPA6IrxIk83kfVbAtcT0Q1ZeFtbe3TWDm8SBe/8NG2 X-Received: by 10.43.137.5 with SMTP id im5mr6864901icc.55.1395151964893; Tue, 18 Mar 2014 07:12:44 -0700 (PDT) Received: from [172.29.91.92] (63-156-62-129.dia.static.qwest.net. [63.156.62.129]) by mx.google.com with ESMTPSA id m6sm27142425igx.9.2014.03.18.07.12.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 07:12:44 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: nand controller - how should one handle controllers that want the command+address bits together? From: Warner Losh In-Reply-To: Date: Tue, 18 Mar 2014 08:12:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5BF1217D-6423-443B-A3AB-1722CDDDAD74@bsdimp.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1874) Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 14:12:46 -0000 On Mar 18, 2014, at 6:55 AM, Adrian Chadd wrote: > .. wow. So, this gets even more problematic. >=20 > The AR934x NAND controller does DMA for the read/program phases as > well as command results (eg READID.) Now, I can likely easily hack > around it for simple commands like READID by overloading the > nfc_start_command() method. Quite ugly, yes. > For the read phase, I'd have to do a copy out of the buffer into the > buffer supplied to the NAND bus code. Cool, that's just highly > inefficient (why aren't we doing buffer IO here again? Bueller?) but > that's a different story. Since most of this stuff was bit-banged or PIOd out, who cares if = there=92s a copy... > For the write phase though, it's totally horrible. I'd have to buffer > the command byte(s), the address byte(s) and the NAND bus write (which > would copy it into the outgoing buffer), then issue it all at once. That=92s not the worst of it. that=92s child=92s play, really. > So, at first glance: >=20 > * why aren't these (command; address; address; start) method runs just > wrapped up into a command method that looks vaguely like (command, > command2, row, column, id, buffer) and let the controller code either > unravel it into serialised writes out, or in the case of the ar934x > NAND controller, use all that information to setup a DMA transfer; Because the state machines needed for different NAND types more or less require the =91low level=92 interface that we have today. The = different phases in setting up a transaction vary somewhat between the different types of NAND, and we have no real knowledge of that in the NAND layer today. It was written 4 years ago when most controllers on the market did little more than bit-bang and/or module the signals to the NAND = since the interfaces at the time were little more than fancy memory mapped memory controllers. > * .. and for reads/writes, the buffer is supplied here, so they can > also be used to setup the DMA transfer, else they're just serialised > out via port banging for dumber NAND controller latches. Yes. > I really want to try and bring this flash chip up (even without > hardware ECC) but I'm kinda worried that in order to do this cleanly > I'm going to have to overhaul nandbus/nfc and a couple of NAND > controllers I don't have (and currently don't want) hardware for. I=92ve also been looking towards this area as well, given my recent NAND history. In fact, I=92ve been putting together a talk for BSDcan on what needs to be done to make the NAND layer sane, cool and groovy. > So, any help/ideas? You already layer it out: You have to be ugly. BTW specifically, what NAND are you talking to? Warner > On 18 March 2014 04:35, Adrian Chadd wrote: >> Hiya, >>=20 >> I've got the atheros ar934x nand controller bits looking like they're >> working on freebsd-head enough to send/receive a READID command with >> an address of 0x0. However, the NAND controller sends commands with >> the cmd and address phases as part of the command, rather than = calling >> send_command / send_address methods called multiple times. >>=20 >> It seems like our nandbus and nand controller layer is a very thin >> shim over what the NAND control messages look like, rather than some >> higher level 'thing' that allows for slightly more intelligent (read: >> DMA/ECC capable) hardware. >>=20 >> So, what gives? >>=20 >>=20 >> -a > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to = "freebsd-embedded-unsubscribe@freebsd.org"