On 4/19/2017 7:04 PM, Randy Yates wrote:> Allan Herriman <allanherriman@hotmail.com> writes: > >> On Wed, 19 Apr 2017 01:35:11 -0700, robert bristow-johnson wrote: >> >>> On Tuesday, April 18, 2017 at 10:40:36 AM UTC-4, Randy Yates wrote: >>>> >>>> This paper pretty much eliminated any faith I might have in the cards, >>>> unless you can avoid abrupt power-offs: >>>> >>>> https://cseweb.ucsd.edu/~swanson/papers/DAC2011PowerCut.pdf >>>> >>>> >>> geez, what does this mean? that we need to, with a large capacitor, >>> keep the CPU and flash alive after the appliance is switched OFF so >>> that, before the CPU dies, it can gracefully complete it's flash card >>> operations and go into an idle state so that no flash operations occur >>> as the power dies? is that what they're saying? > > Robert: yeah, that's my take-away. > >>> r b-j >> >> >> I'm typing this post on an old Dell laptop that contains an Intel 320- >> series SSD which supposedly contains a capacitor bank for that very >> purpose. Intel call it "Enhanced Power Loss Data Protection". >> >> I decided to fork out the extra $ after an earlier SSD (from OCZ) bricked >> itself going into (or coming out of) standby. I guess it's not such a >> good idea to store the internal SSD firmware in the nand Flash array. > > Allan, one thing I wanted to ask you is this: what would you use > to replace flash? There are no more 2732 UV EPROMS, no more PROMs, > etc. > > Even if you went to the trouble (and expense) to design in a bunch of > DRAM and load the NV stuff on power-up, what type of device would you > load it FROM? >These issues are all relevant to various types of NAND Flash. NOR Flash is the modern replacement for EPROM and is much more robust than NAND flash. <https://en.wikipedia.org/wiki/Flash_memory#NOR_memories> Rob.
OT: Flash Memory
Started by ●April 13, 2017
Reply by ●April 20, 20172017-04-20
Reply by ●April 20, 20172017-04-20
On Wed, 19 Apr 2017 22:04:18 -0400, Randy Yates wrote:> Allan Herriman <allanherriman@hotmail.com> writes: > >> On Wed, 19 Apr 2017 01:35:11 -0700, robert bristow-johnson wrote: >> >>> On Tuesday, April 18, 2017 at 10:40:36 AM UTC-4, Randy Yates wrote: >>>> >>>> This paper pretty much eliminated any faith I might have in the >>>> cards, >>>> unless you can avoid abrupt power-offs: >>>> >>>> https://cseweb.ucsd.edu/~swanson/papers/DAC2011PowerCut.pdf >>>> >>>> >>> geez, what does this mean? that we need to, with a large capacitor, >>> keep the CPU and flash alive after the appliance is switched OFF so >>> that, before the CPU dies, it can gracefully complete it's flash card >>> operations and go into an idle state so that no flash operations occur >>> as the power dies? is that what they're saying? > > Robert: yeah, that's my take-away. > >>> r b-j >> >> >> I'm typing this post on an old Dell laptop that contains an Intel 320- >> series SSD which supposedly contains a capacitor bank for that very >> purpose. Intel call it "Enhanced Power Loss Data Protection". >> >> I decided to fork out the extra $ after an earlier SSD (from OCZ) >> bricked itself going into (or coming out of) standby. I guess it's not >> such a good idea to store the internal SSD firmware in the nand Flash >> array. > > Allan, one thing I wanted to ask you is this: what would you use to > replace flash? There are no more 2732 UV EPROMS, no more PROMs, etc. > > Even if you went to the trouble (and expense) to design in a bunch of > DRAM and load the NV stuff on power-up, what type of device would you > load it FROM?I don't replace Flash. I just had to understand its limitations and failure modes and learn how to work around them. In another post Rob Doyle suggested nor Flash. I don't use it (too small, too expensive), but it does avoid most of the problems with nand Flash. I've done a variety of things on my products: Raw nand Flash. I choose SLC rather than MLC. SLC Flash is getting hard to obtain, but Micron still have some older (and smaller) parts on their longevity program. With raw nand Flash, one has complete control over the wear levelling, etc. For the filesystem we use UBIFS, which manages all that. Earlier products had used YAFFS2. YAFFS has the advantage that a blank Flash device is a valid format (i.e. it's good from the get-go) whereas UBIFS requires every block on the device to be written during a formatting operation, which takes some tens of minutes. The production staff hate that. I don't have solid statistics, but anecdotally it does seem that YAFFS2 was more reliable that UBIFS. Some products use eMMC. In all cases we're running a root filesystem that's mounted readonly except during software upgrades, with only a small R/W partition for the user configuration. Under normal operating conditions there should be no writing at all. We keep two copies of the root filesystem on different partitions. There's also a hash (like a CRC but stronger) of each file. This is checked at boot time. There's a scrubber which slowly reads every file (or is it every page?) in the background. This means that an error on any page will be picked up while it's still correctable. There are tradeoffs though - it will fill the disk cache (in RAM) with unwanted stuff, reducing performance. Also, on Flash, reads can cause errors in unrelated pages. It's a soft error (not a wear issue), but it does mean we don't want the scrubber to run too fast. We have a generous amount of RAM, meaning that most read operations hit the disk cache and don't actually affect the Flash at all. The RAM has ECC (you knew I was going to say that). We also scrub the RAM. When the products were new there was plenty of free space (about 50%, which is good) but several years of feature creep and bloat has made them about 70% full, which is starting to worry me. Future work may include things I mentioned in an earlier post, e.g. changing to BTRFS, which can handle the mirroring and file integrity checks by itself. Regards, Allan
Reply by ●April 20, 20172017-04-20
Thanks much Allan for all these ideas! --Randy Allan Herriman <allanherriman@hotmail.com> writes:> On Wed, 19 Apr 2017 22:04:18 -0400, Randy Yates wrote: > >> Allan Herriman <allanherriman@hotmail.com> writes: >> >>> On Wed, 19 Apr 2017 01:35:11 -0700, robert bristow-johnson wrote: >>> >>>> On Tuesday, April 18, 2017 at 10:40:36 AM UTC-4, Randy Yates wrote: >>>>> >>>>> This paper pretty much eliminated any faith I might have in the >>>>> cards, >>>>> unless you can avoid abrupt power-offs: >>>>> >>>>> https://cseweb.ucsd.edu/~swanson/papers/DAC2011PowerCut.pdf >>>>> >>>>> >>>> geez, what does this mean? that we need to, with a large capacitor, >>>> keep the CPU and flash alive after the appliance is switched OFF so >>>> that, before the CPU dies, it can gracefully complete it's flash card >>>> operations and go into an idle state so that no flash operations occur >>>> as the power dies? is that what they're saying? >> >> Robert: yeah, that's my take-away. >> >>>> r b-j >>> >>> >>> I'm typing this post on an old Dell laptop that contains an Intel 320- >>> series SSD which supposedly contains a capacitor bank for that very >>> purpose. Intel call it "Enhanced Power Loss Data Protection". >>> >>> I decided to fork out the extra $ after an earlier SSD (from OCZ) >>> bricked itself going into (or coming out of) standby. I guess it's not >>> such a good idea to store the internal SSD firmware in the nand Flash >>> array. >> >> Allan, one thing I wanted to ask you is this: what would you use to >> replace flash? There are no more 2732 UV EPROMS, no more PROMs, etc. >> >> Even if you went to the trouble (and expense) to design in a bunch of >> DRAM and load the NV stuff on power-up, what type of device would you >> load it FROM? > > > I don't replace Flash. I just had to understand its limitations and > failure modes and learn how to work around them. > > > In another post Rob Doyle suggested nor Flash. I don't use it (too > small, too expensive), but it does avoid most of the problems with nand > Flash. > > > I've done a variety of things on my products: > > Raw nand Flash. I choose SLC rather than MLC. SLC Flash is getting hard > to obtain, but Micron still have some older (and smaller) parts on their > longevity program. > With raw nand Flash, one has complete control over the wear levelling, > etc. > For the filesystem we use UBIFS, which manages all that. Earlier > products had used YAFFS2. YAFFS has the advantage that a blank Flash > device is a valid format (i.e. it's good from the get-go) whereas UBIFS > requires every block on the device to be written during a formatting > operation, which takes some tens of minutes. The production staff hate > that. > > I don't have solid statistics, but anecdotally it does seem that YAFFS2 > was more reliable that UBIFS. > > > Some products use eMMC. > > In all cases we're running a root filesystem that's mounted readonly > except during software upgrades, with only a small R/W partition for the > user configuration. Under normal operating conditions there should be no > writing at all. > We keep two copies of the root filesystem on different partitions. > > There's also a hash (like a CRC but stronger) of each file. This is > checked at boot time. > > There's a scrubber which slowly reads every file (or is it every page?) > in the background. This means that an error on any page will be picked > up while it's still correctable. There are tradeoffs though - it will > fill the disk cache (in RAM) with unwanted stuff, reducing performance. > Also, on Flash, reads can cause errors in unrelated pages. It's a soft > error (not a wear issue), but it does mean we don't want the scrubber to > run too fast. > > We have a generous amount of RAM, meaning that most read operations hit > the disk cache and don't actually affect the Flash at all. > The RAM has ECC (you knew I was going to say that). We also scrub the > RAM. > > > When the products were new there was plenty of free space (about 50%, > which is good) but several years of feature creep and bloat has made them > about 70% full, which is starting to worry me. > > Future work may include things I mentioned in an earlier post, e.g. > changing to BTRFS, which can handle the mirroring and file integrity > checks by itself. > > Regards, > Allan-- Randy Yates, Embedded Firmware Developer Garner Underground, Inc. 866-260-9040, x3901 http://www.garnerundergroundinc.com
Reply by ●April 20, 20172017-04-20
Rob Doyle <radioengr@gmail.com> writes:> On 4/19/2017 7:04 PM, Randy Yates wrote: >> Allan Herriman <allanherriman@hotmail.com> writes: >> >>> On Wed, 19 Apr 2017 01:35:11 -0700, robert bristow-johnson wrote: >>> >>>> On Tuesday, April 18, 2017 at 10:40:36 AM UTC-4, Randy Yates wrote: >>>>> >>>>> This paper pretty much eliminated any faith I might have in the cards, >>>>> unless you can avoid abrupt power-offs: >>>>> >>>>> https://cseweb.ucsd.edu/~swanson/papers/DAC2011PowerCut.pdf >>>>> >>>>> >>>> geez, what does this mean? that we need to, with a large capacitor, >>>> keep the CPU and flash alive after the appliance is switched OFF so >>>> that, before the CPU dies, it can gracefully complete it's flash card >>>> operations and go into an idle state so that no flash operations occur >>>> as the power dies? is that what they're saying? >> >> Robert: yeah, that's my take-away. >> >>>> r b-j >>> >>> >>> I'm typing this post on an old Dell laptop that contains an Intel 320- >>> series SSD which supposedly contains a capacitor bank for that very >>> purpose. Intel call it "Enhanced Power Loss Data Protection". >>> >>> I decided to fork out the extra $ after an earlier SSD (from OCZ) bricked >>> itself going into (or coming out of) standby. I guess it's not such a >>> good idea to store the internal SSD firmware in the nand Flash array. >> >> Allan, one thing I wanted to ask you is this: what would you use >> to replace flash? There are no more 2732 UV EPROMS, no more PROMs, >> etc. >> >> Even if you went to the trouble (and expense) to design in a bunch of >> DRAM and load the NV stuff on power-up, what type of device would you >> load it FROM? >> > > These issues are all relevant to various types of NAND Flash. > > NOR Flash is the modern replacement for EPROM and is much more robust > than NAND flash. > > <https://en.wikipedia.org/wiki/Flash_memory#NOR_memories>Hi Rob, Thanks for replying. I wrote "EPROM" with my tongue in my cheek. What you state is true, but it is going to be EXPENSIVE for any significant amount (8GB?) of memory. -- Randy Yates, Embedded Firmware Developer Garner Underground, Inc. 866-260-9040, x3901 http://www.garnerundergroundinc.com
Reply by ●April 20, 20172017-04-20
On 2017-04-13 16:03, Randy Yates wrote:> Gentle comp.dsp People, > > I've been involved on several projects over the past few years that > utilize flash memory in microSD form, and several times they have > inquired about problems with lifetime of such cards. My employer > recently tasked me with investigating the alleged write lifetime issue.AFAIK, microSD are designed for "write once read many" (WORM). It means, they're supposed to be filled once with data and then stored in the closet... bye, -- piergiorgio
Reply by ●April 20, 20172017-04-20
Allan Herriman wrote:> On Wed, 19 Apr 2017 01:35:11 -0700, robert bristow-johnson wrote:<snip> > I guess it's> not such a good idea to store the internal SSD firmware in the nand > Flash array. > > Regards, Allan ><https://s-media-cache-ak0.pinimg.com/564x/02/97/39/0297393410218209b9f90fb4fb15a6a3.jpg> -- Les Cargill
Reply by ●April 21, 20172017-04-21
Piergiorgio Sartor <piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de> writes:> On 2017-04-13 16:03, Randy Yates wrote: >> Gentle comp.dsp People, >> >> I've been involved on several projects over the past few years that >> utilize flash memory in microSD form, and several times they have >> inquired about problems with lifetime of such cards. My employer >> recently tasked me with investigating the alleged write lifetime issue. > > AFAIK, microSD are designed for "write once > read many" (WORM). > > It means, they're supposed to be filled once > with data and then stored in the closet...That is certainly not the task to which they have been applied by folks like Adafruit. They are being used as small (in capacity and physical size) hard drives. -- Randy Yates, Embedded Firmware Developer Garner Underground, Inc. 866-260-9040, x3901 http://www.garnerundergroundinc.com
Reply by ●April 21, 20172017-04-21
On 2017-04-21 15:16, Randy Yates wrote:> Piergiorgio Sartor > <piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de> writes: > >> On 2017-04-13 16:03, Randy Yates wrote: >>> Gentle comp.dsp People, >>> >>> I've been involved on several projects over the past few years that >>> utilize flash memory in microSD form, and several times they have >>> inquired about problems with lifetime of such cards. My employer >>> recently tasked me with investigating the alleged write lifetime issue. >> >> AFAIK, microSD are designed for "write once >> read many" (WORM). >> >> It means, they're supposed to be filled once >> with data and then stored in the closet... > > That is certainly not the task to which they have been applied by folks > like Adafruit. They are being used as small (in capacity and physical > size) hard drives.Well, it seems, in certain cases, abuses do not bring criminal charges, even if they should... :-) Jokes apart, the specific Adafruit case relates more to toys, I would say. bye, -- piergiorgio
Reply by ●May 6, 20172017-05-06
