From owner-freebsd-embedded@FreeBSD.ORG Sun Mar 14 17:55:03 2010 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E69C106566B for ; Sun, 14 Mar 2010 17:55:03 +0000 (UTC) (envelope-from loos.br@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id DF7F68FC08 for ; Sun, 14 Mar 2010 17:55:02 +0000 (UTC) Received: by gyf2 with SMTP id 2so1295002gyf.13 for ; Sun, 14 Mar 2010 10:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=DXrtwgGuvENav1rpRmcpV2JbAOsAmKJILqvRovX1pAI=; b=AW/EZL9aebRJqmfuFlz5pYP/TlHDeBV1NZrh3sDXZ9h2PJKOqaR6BfGNxWySvC8pcL U525Me8+kJPml4rOn5lroEsTsWyC9pPpv5PYKPypsD3nS6xhBlSJOl+kllnyuOQ6Hi0F KkpOIl6HvWGH5uGTjWLgkGLvRFNSNgPgEOzr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=JYd77M7/vPxDsknf8FgE13zYwJ4qgXcvwOMe7smAezQAMOolr3/0pfxEZINVSsuitQ lTpQ+MRX7UAj/edYYavsTqqfzC0YMMutH5DXuOnujqGZnOGd0zj5bi1OEl0dS7fYX+7M ld5oKXP48RifzuL25Q8nq+kTht7KyJKd5f/18= Received: by 10.101.155.13 with SMTP id h13mr1988510ano.46.1268589301990; Sun, 14 Mar 2010 10:55:01 -0700 (PDT) Received: from [192.168.0.86] ([187.39.15.241]) by mx.google.com with ESMTPS id 22sm1125697yxe.55.2010.03.14.10.55.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 14 Mar 2010 10:55:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Luiz Otavio O Souza In-Reply-To: <20100314165825.121d346b@fubar.geek.nz> Date: Sun, 14 Mar 2010 14:54:57 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0AE04EFA-A3EB-4939-BD81-607C00355B67@semihalf.com> <20100314165825.121d346b@fubar.geek.nz> To: Andrew Turner X-Mailer: Apple Mail (2.1077) Cc: embedded@freebsd.org, Grzegorz Bernacki Subject: Re: NAND Flash Framework for review X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 17:55:03 -0000 On Mar 14, 2010, at 4:58 AM, Andrew Turner wrote: > On Tue, 9 Mar 2010 00:28:53 +0100 > Rafal Jaworowski wrote: >> We are looking for review, comments and any other feedback. >=20 > Below is my first set of notes from reading the code. I haven't ported > the driver to my hardware yet so these are only from using with = nandsim. >=20 > Chip drivers: > - lnand and snand have magic numbers to figure out which drive to use. > We should move these to a flag in the chip parameters. We just need to add the chip size in nand_params and based on that we = can calculate the number of address cycles (see below) and the type of = chip (if chip >=3D 128MB and pagesize > 512 then you have a large page = device). > - nand_read_pages should be a device method so we can customise how we > handle reading of pages. > - Split nand_generic into separate files with different device options > so we can compile only the one we need. > - nand_generic.c should be split into multiple files to allow us to > support only the chips we have. - Fixed number of address cycles (and wrong count for large page = devices). - Address cycles should not be sent by "driver" (this need to be moved = up). - No support to read the ready/busy nand pin. - Bad block table for generic devices. I'm not sure about slipt nand_generic.c, actually we can use the same = kernel with different kind of chips (exactly what i'm doing here). Also = there are only a few functions for each case. > nandbus: > - nandbus should not know what commands to send to nand chips. These > requests should be moved up to the chip driver. > - Why is nandbus not exposing it's interface via NEWBUS? > - Where is nandbus_destroy used? > - Why is malloc called with M_NOWAIT when allocating the nandbus ivar? > - What should happen when nandbus_send_command, nandbus_send_address, > nandbus_start_command, nandbus_read_buffer or nandbus_write_buffer > fail? > - Why does nandbus need to know if we are an ONFi part or not? We > can push the check into the onand driver's probe function. - nandbus have nandbus_select_cs() but not the equivalent = nandbus_deselect_cs(). >=20 > nandsim: > - nandsim sample config has invalid time values (too small. > - There is a kernel crash in nandsim_log. >=20 > General: > - malloc with M_WAITOK will always succeed, no need to check return > value. > - Should define our own malloc type. >=20 > Ideas: > - Can we move ecc and bbt handling into GEOM? This will allow us to > bypass them when required. This is a mandatory feature (disable ecc and may be the bbt checks) if = you need to deal with some kind of unknown nand FS or unknown nand oob = layout (like make a backup of your unknown nand data before erase it). We also need userland tools to erase nand contents (erase all blocks of = a device or slice), read and write raw pages (so you can make the full = backup/restore of nand contents or write a yaffs like image - which = already contains all the oob data). Luiz=