The company I work for is manufacturing a device with ARM processor and embedded Linux. At the time of the project (a few years ago) our consultants relied on NAND flash chips with UBIFS as filesystem, due to project constraints:

  • The device must always be bootable even after a power cut.
  • The boot time of the device must always be the same, even after a power cut.

Unfortunately, power cut is the "normal" way our customers shut down their devices.
Unfortunately, the flash chip is no longer in production, so we are reassessing other alternatives: MMC embedded or SATA SSD. Something, in short, that if it goes out of production, we can find a replacement while maintaining the same identical FW.

I wonder if today the hw (ssd, eMMC, etc.) and sw (mainly filesystems) technologies allow me to stay within the constraints with devices other than NAND flash chips.

  • 2
    \$\begingroup\$ How big does it need to be? For smaller embedded system images booting from an SPI NOR flash and uncompressing to a RAM disk can be very nice. \$\endgroup\$ – Chris Stratton Mar 10 '18 at 22:52
  • \$\begingroup\$ between 512MB and 1GB. The devices must store a lot of information, provided by the user, necessary for the operation of the device itself The current implementation includes booting from NOR flash and saving the info on NAND flash. \$\endgroup\$ – mastupristi Mar 10 '18 at 23:07
  • \$\begingroup\$ It would actually be a good idea to bring in the flash vendors and have them present their solutions. \$\endgroup\$ – mkeith Mar 10 '18 at 23:10
  • 1
    \$\begingroup\$ Does the NAND flash chips have a standard interface? Can you user a different perhaps higher capacity NAND chip that is still in production? \$\endgroup\$ – crj11 Mar 10 '18 at 23:41
  • 1
    \$\begingroup\$ You could put a CPLD between the device and the storage to provide a consistent interface even though the memory changes with time. \$\endgroup\$ – crj11 Mar 11 '18 at 16:39

I think it's a multi part answer.

  1. I'd assume here that if a unit fails in the field you simply swap it out. The decision to scrap that board is then yours (how long do you WANT to keep the boards circulating). For your current boards you should have stock on hand of the NAND chips to allow for board failures and repair.

  2. You'd produce future firmware that can support the 16bit NAND interface and whatever new storage interface you choose. For example in UBoot (if that's what you are using) you introduce the required drivers for the boot path.

  3. I'd suggest using the SD/MMC interface (of which e.MMC is just one variant) since that can use a single lane to simplify changes. While speed is the concern for most MMC usage, it may be that you can tolerate a slower speed as long as it's consistent. You could use a single lane interface over SPI as an interface (about as simple as you can get). This might get you started thinking about it. Certainly this would seem to minimize changes to your PCB.

  • \$\begingroup\$ I am frightened by a thought that I tried to arrange with the two following sentences (questions): Let's suppose that under normal conditions, the boot time is x seconds. How long could the boot time be in the worst case after a power cut? Is it always possible to complete the device boot after a power cut? \$\endgroup\$ – mastupristi Mar 18 '18 at 14:22
  • \$\begingroup\$ Only you can know the boot time after a power failure, you are writing the software/firmware. \$\endgroup\$ – Jack Creasey Mar 18 '18 at 14:39
  • \$\begingroup\$ I'll give an example: if I chose eMMC with EXT4 I'd be quite sure that after a power cut the boot time would be much higher and moreover there would be the risk that the system wouldn't even be able to complete the boot. The only thing we have control over is choosing the filesyetm. That's why I wondered which block device filesystem guarantees boot times after a power cut, about the same as normal boot. \$\endgroup\$ – mastupristi Mar 18 '18 at 16:51
  • \$\begingroup\$ No matter the file system used, the system can be guaranteed to boot at least through the bootloader ...the real question is can the OS recover from any FS damage that occurs during power fail. That's a different question entirely, unrelated to your question on NAND flash implementations. You could start looking at fsck performance here: thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times \$\endgroup\$ – Jack Creasey Mar 18 '18 at 18:23
  • 1
    \$\begingroup\$ @mastupristi: What makes file system recovery really slow is high number of files in complex tree structures. If the filesystem is read-only, no data will ever be changed, and a power cut will never require a recovery. One could make a read-only operating system partition, and one with all files being written by the device. This reduces recovery time a lot. But you didn't say what type of data is in on the memory. \$\endgroup\$ – sweber Dec 23 '18 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.