The board is based on what looks like a custom SIP including the iMX6, RAM and storage - so two different versions of the core module on the same breakout dev board.
I feel like I’m missing something blazingly obvious but given eMMC is basically managed NAND flash, with everything else the same, it’s $4 more for 16x the storage! So, given the investment Seeed have done to produce a NAND version, has anyone got a use case where they would use the NAND version over the eMMC? I’ve never needed it personally, but I’m curious as to when the pro’s of using unmanaged NAND, especially in a SIP like this come into consideration
It’s only recently that eMMC has been at anything near price parity with raw NAND. You can save a few bucks at high volumes if you know you’ll need less nonvolatile storage by going raw NAND. Since most raw NAND uses the ONFI bus standard, it’s less risk to swap to a smaller part after using a board like this as a reference.
Raw NAND also has some slight reliability advantages to eMMC. You can only achieve the density available in eMMC by using MLC or TLC Flash technology, which is inherently less reliable than SLC. They also require smaller process nodes to fabricate. In NAND world, smaller process == less reliability. Always.
Related to reliability - raw NAND gives you more control over your choice of embedded filesystem and, by extension, error correction scheme. All of that stuff is more or less “behind the curtain” in an eMMC. Something like jffs or ubifs gives you more control over error correction, and fixing single bit errors in a corrupted NAND page. It also allows for compatibility to a legacy file system or error correction topology, if you need it.
There’s a whole lot of fun stuff down the path of error correction. You get into Hamming distance and error correction codes. I had to go down that rabbit hole for a job once. Lots of fun information theory down there!
@nrc.reilly Cheers mate - that agrees with what I had thought - I might have to start playing with raw NAND and see what I’ve been missing! But I might have just lucked out that I’ve hit the right time when eMMC is financially viable in a design that it’s an easy choice
If anyone has real world projects where raw nand has been the preferred option I’d love to hear about them
On the same topic if you haven’t read Bunnie Huang’s blog posts on hacking SD cards, supply chain issues and security, I highly recommend them (links to Bunnie’s blog - bunniestudios.com)
@cbrake - thanks, the NPi is a means to an end to be honest, I have a need to get better aquatinted with the iMX6, and this board popped up cheap, but I’ll check out the link you mention. But really this post is more about being more aware of other parts and use-cases. I’ve always just gone for eMMC - it meets my design requirement (and it helps to not have to worry about managing the storage myself if you’re in the mood to be lazy…) but if anyone can expand my horizons, I maybe should be using unmanaged NAND instead?
From an old memory. For the OLPC XO-1 we used raw NAND with jffs2. For the OLPC XO-1.5 we switched to microSD. For the OLPC XO-1.75 and XO-4 we switched to eMMC. We watched Bunnie’s findings with interest. I remember we had teething troubles with jffs2 until it settled down, and teething troubles with power sequencing with microSD and eMMC, including not knowing when it had finished any wear-leveling undertaken after the last system directed I/O. I don’t think we were ever entirely happy with the response of eMMC to sudden power loss, and we had a user-removable battery so it was a risk that could not be easily controlled for. For the storage sizes we were aiming for later in progression, I suspect eMMC won on price or physical layout space, but I can’t remember for sure.
Yes, I’ve deployed several products using raw NAND over the years (10,000+ units) using JFFS2 and lately UBIFS. They have all worked fine – never any serious flash/file system problems. I also recently deployed a system with eMMC using the ext4 file system. (several hundred units in the field), and it has been reliable as well through one season.
I can’t really say if raw NAND is more reliable than eMMC as both seem pretty reilable. eMMC is potentially less work as you don’t have to deal with UBI layout, etc. One thing with eMMC is the devices are so large you likely never wear them out as most applications (where you could use NAND as well) will only use a tiny fraction of the eMMC space. So even though UBIFS uses better algorithms than ext4 on eMMC, it practice it may not matter if you have loads of flash.
One thing we typically do is have a bridge battery or super cap in the design that gives the system time to power down properly if power is removed. I can’t say if this is absolutely required, but it has been working so we tend to keep doing what has worked rather than take chances with having problems in the field.
Brownout protection is also important to ensure the processor/flash is in reset when the power is marginal.
There are many aspects of system reliability – you have to cover them all, because the system is only as good as the weakest part.
If you’re doing a small run, and your budget supports eMMC, there is no reason not to use it. You only start getting into statistically significant failure rates when you’re shipping 100k plus units a year. NAND vendors really did the world a favor when they pulled the ECC and wear leveling algos inside the chip!
@quozl - I also have gone from jffs2 to ubifs. ubifs solves nearly every problem with jffs2. It was very robust in embedded Linux, and relatively easy to figure out what went wrong in the rare instances where it went sideways. Would recommend!
@cbrake - you raise a great point with brownout protection. The most surefire way to screw up raw NAND is to shut it off mid operation. For maximum fun (read: headache), turn off during an erase. A brownout detector that immediately locks out future NAND accesses, and allows an in-progress NAND access to terminate, is a great solution. (In hardware, this can be a simple comparator on the input power rail that triggers an ISR via GPIO input to the main MCU/SoC. My counterparts in system software land typically achieved this with a dead end while (1) {} thread.) Like you suggest, you’ll need to be sure you have enough capacitance to get your NAND across the finish line. Longest operating cycle is an erase, and that’s on the order of 5-10ms worst case if memory serves.
Thanks all for the informative answers. Whilst out for a walk today it occurred to me that one possible reason to prefer nand was cost, especially in large quantity products.
But thanks again for sharing your experience for the gain of others.