From owner-freebsd-arm@freebsd.org Fri Mar 24 02:46:09 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7213BCA2FF7 for ; Fri, 24 Mar 2017 02:46:09 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CB3BBD2 for ; Fri, 24 Mar 2017 02:46:08 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1490323565; l=5497; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=mZkOw0STql0gCbJ+OM3GTnIJeU6ej2S6+dySA3Ofb0I=; b=a5+OcPDiBcxwxhds0ywsdoeSp51CrxR5hqs9JeULQLfq80wQixcbL6mROwThx89X46 DtPWliGCDK14bPFSsbvLXjcCM/bCZYkB5t/264FsOHWQpeugsuB2+HOrpvOqdwBuRgvg wuJR0ND0JEesu0PiVERNg4rsnh+qniTbdmq6s= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0n99Hk6LY= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b8ae.virtua.com.br [187.2.184.174]) by smtp.strato.de (RZmta 40.1 DYNA|AUTH) with ESMTPSA id j04813t2O2k4zMS (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Fri, 24 Mar 2017 03:46:04 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 7B5FB7506DAD for ; Thu, 23 Mar 2017 23:46:01 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black From: "Dr. Rolf Jansen" In-Reply-To: Date: Thu, 23 Mar 2017 23:46:00 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7E957E90-5579-4A7F-83DC-1B5522833EC2@obsigna.com> References: <1489864043.40576.219.camel@freebsd.org> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> <70C95FC9-4B0A-4DA4-9857-EFAF41522D1B@obsigna.com> <1490281652.58015.71.camel@freebsd.org> To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 02:46:09 -0000 Am 23.03.2017 um 17:37 schrieb Warner Losh : > On Thu, Mar 23, 2017 at 8:07 AM, Ian Lepore wrote: >> On Thu, 2017-03-23 at 00:42 -0300, Dr. Rolf Jansen wrote: >>> Am 21.03.2017 um 13:25 schrieb Luiz Otavio O Souza = : >>>> On 19 March 2017 at 18:45, Dr. Rolf Jansen wrote: >>>>>>>>>>=20 >>>>>>>>>> ... ask you for suggestions. >>>> [picking a random message to reply] >>>>=20 >>>> I just saw an email from SanDisk support (whatever this means) >>>> where >>>> they claim the only supported model for this kind of use is the >>>> high-endurance series: >>>> https://www.sandisk.com/home/memory-cards/microsd-cards/high-endura >>>> nce-microsd >>>>=20 >>>> This same email says that running any kind of OS in any of the >>>> other >>>> card models automatically breaks the warranty. >>> Luiz, thank you very much for the note. Do you know, whether this >>> high endurance XC card is compatible with the Beaglebone Black? >>=20 >> I would assume that it is, they're typically just standard sd cards >> with flash arrays based on SLC technology and with a lot of extra = space >> for reassigning bad blocks (a card that claims 8gb capacity could >> actually have 4x that many blocks or more available internally). >=20 > I don't think there's 4x over-provisioning. Where do you get that = figure? >=20 > When I was at Fusion I/O, the designs there were all in the 9-24% > range, and our "intel" on what others were doing showed a range of 5% > to 40% depending on the market segment and type of NAND use. If they > are really using SLC NAND for these cards, the sparing is likely less > because TLC NAND has about a 200-300 endurance rating (program erase > cycles per erase block). MLC is between 3000-5000. SLC is like > 30,000-100,000. SLC has also 10-100x better error rates than MLC which > has 10-100x better than TLC due to how the charge nodes are programmed > and the tolerances associated with that programming. There was > constant pressure to come up with designs that needed less sparing, so > I doubt things have changed to require 4x over provisioning.... What > might be going on when people say that has to due with a feature of > modern NAND chips: they can be programmed as SLC, MLC or TLC often on > a per-erase block basis. In that case, a SLC configuration with a 33% > over provisioning would have a 4x maximum theoretical raw capacity > over the selected size for the drive (so a 8GB drive would have 8GB * > 1.33 (over provisioning: spares and OOB) * 3 (TLC multiplier) or 32GB > of raw capacity). >=20 >> But be aware that high-endurance or industrial-rated cards can be = very >> expensive. I think at work we pay around $40 each for = industrial-rated >> 8gb cards. (One of them was included in those test results I posted, >> and the performance was among the best, at least you get something = for >> all that extra money.) >=20 > Part of the issue is that NAND chips these days can be SLC, MLC or TLC > depending on how you program them (often on an erase-block level).[*] > This means that the 8GB SLC card could also be a 16GB MLC card or a > 24GB TLC card (well, due to sparing it likely wouldn't scale > linearly). So from that perspective, I can see where a 4x number might > come up (high number of bits possible for the die vs capacity > configured for SLC + spares). At 33% sparing, the differences between > the SD presented capacity point of 8GB would have close to 32GB of > potential raw capacity were it run in TLC mode.... In addition, high > endurance cards are often selected from the wafers at manufacturing > time because they have the lowest error rate and other metrics so the > NAND makers know that they will survive (the NAND manufacturing > process isn't too uniform across the wafer due to micro variations in > the wafer and other effects at the nano-scale). Often times these are > also pulled from processes that typically yield better results but are > more expensive. So the relative rarity of the raw dies plus the > increased production cost plus running them in a faster, more reliable > mode all lead to the cards being more expensive.... >=20 > So that's why it's so expensive, especially on the high end: you are > paying extra for quality. Warner and Ian, thank you very much for sharing your much deeper = insights on the matter. I am setting up a prototype for a mostly autonomous measurement device = for an industrial application using the BBB as the controller. For this = reason I am interested in the ti_adc driver, and I was glad that I got = it working. Once the device has been setup, writes to the SD card will be limited to = logging measurement data and activity events besides the normal FreeBSD = logging. The 4 GB internal flash of the BBB would be more than = sufficient to hold everything, however, I was thinking that using an = external SD card in order not to damage the BBB because of flash wear, = would be a good idea. Well, for this kind of application $40 is still in the budget, however, = it comes already close to the cost of the BBB itself. Perhaps, I simply = forget the SD cards and provide to my future customers spare BBB's. Anyway, I guess I need to do some lifetime simulation of the external = flash compared to the internal one, so I could take a more educated = decision based on these results. =20 Best regards Rolf =20=