From owner-freebsd-embedded@freebsd.org Thu Jun 28 23:28:22 2018 Return-Path: Delivered-To: freebsd-embedded@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E776102C5A9 for ; Thu, 28 Jun 2018 23:28:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D98673B1F for ; Thu, 28 Jun 2018 23:28:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id g7-v6so6815860ioh.11 for ; Thu, 28 Jun 2018 16:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Fp/YJ9bVi1tj8CJF0UVD7aoPwbA5CJX76mWyrGpX6Mk=; b=t+Rw4YWOpYe62SNeypqhuLVaV6Gs0FEgiwMAYefl/QnhDR5CZ90Tyf2jagV+aKEyYX yyE8LDY0meiWthf/ddjBz4bm+Qx6Cpx+bVOHUFFhJpxviAHHJSXqJHUYSJOX9vSi3sBK DwyP6sVXwv+gKAng2ZbMMvash9HC3P8mYhhlFsuW3lEdMNp/+aifK5nfbrs549kuxFUz FBqszX3RSGniTNL8BAXp+ISZB6J1S6RxZLdyHZ3V96zqfa3AxbnfILY5S543E4IJiqB5 BdVjlOnx0GtgRqKehoxRsRgB3hC/oSORfd5B3vOx34Ccjea2BPlvbfKwCkI+elw2q+rZ QiRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Fp/YJ9bVi1tj8CJF0UVD7aoPwbA5CJX76mWyrGpX6Mk=; b=Cy/RyR6v9O/bLpPWZSg8iv6tKCS3x4/ESH2ikKZQmT1FBQFEznT1iOtOe7HTuqN/MK DInO0BAm/fA3UmdAvSWBezLa7HtrNPU43WACmpbdb5im3rpDg3llkifutCDYEP/OckET LIkh2NDiGOqWFGY7OUo9+cF5e0r2r9fnX4rmY6T23cTzic8ZIx9XDxBWkLfjYYCjAX7N 6x1XABmKk8io94Vj6p5f1YY8I0L04GFt+BzTAM2LcXpiirFvniNxyukqZBpIq67kFAOQ Tfw0xZ2/yh8hEktCrh4TQYMKlh5O+mV8lJHW/V0R7DmYF4YKbdStqhvKnJV8JXircJqI lOqg== X-Gm-Message-State: APt69E0xNbkEP6PA6h0o5yzxNlciew5qY+izPUJAeli1WsPS/QAvr1sK FL/XVEOjRTcD8jCvXns1Bdb9wueh7WoelYmqhFvadg== X-Google-Smtp-Source: AAOMgpcgIAOZKTJQAhgIVDBFfUUm7z3dnqrX+hYfisvE6gfPnQzuEuCLXvxH0mabro95+YiqC+qvfKMy1NYnqAiRjEM= X-Received: by 2002:a6b:29c4:: with SMTP id p187-v6mr10070625iop.299.1530228501377; Thu, 28 Jun 2018 16:28:21 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 16:28:20 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180629011042.6e72464d7fc3294d96dd093f@bidouilliste.com> References: <20180629011042.6e72464d7fc3294d96dd093f@bidouilliste.com> From: Warner Losh Date: Thu, 28 Jun 2018 17:28:20 -0600 X-Google-Sender-Auth: TBstzIztkOL5HQRG9BaPwJ6Ytkg Message-ID: Subject: Re: Atheros AR93xx NAND support To: Emmanuel Vadot Cc: Adrian Chadd , "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 23:28:22 -0000 On Thu, Jun 28, 2018 at 5:10 PM, Emmanuel Vadot wrote: > On Thu, 28 Jun 2018 14:46:16 -0600 > Warner Losh wrote: > > > If you had good access to datasheets, plus errata, plus vendor support, > you > > might be able to get a quality implementation in 3-4 months time, which > > would include time to revamp our NAND system. It doesn't include time to > > revamp NANDFS, though, which would be another 2-3 months to get rock > solid. > > > > Warner > > I don't know the state of NAND in MIPS world but in the ARM world it's > clearly fading out. But I've always wondered if instead of NANDFS one > could do a geom_ftl (Flash Transision Layer) that will do all the nand > stuff and then we can use UFS on it ? That's logically appealing, but inefficient.The tables needed get kinda big and/or you have to do a lot of NAND I/O to get the mappings since you are hiding things from the UFS layer. NANDFS is a log filesystem, so it knows how about how to interact with the append store that's NAND. It was one of the biggest problems with Fusion I/O's driver: it had to keep this translation table in memory. It made crash recovery difficult. It created points of contention that limited performance. It could be done, but experience suggests caution... Warner