1
\$\begingroup\$

I'm familiar with using BODs with microcontroller devices so that the system is safely pulled into reset and started when the supply is normal.

I'm also familiar with projects on SOCs on devices like Raspberry Pi, which can suffer badly when a power outage occurs. I'm assuming what usually happens is file-system corruption? Whatever the cause, it's not uncommon for a Raspberry Pi (BeagleBone, etc) which is suddenly powered off to fail to boot cleanly again when powered up.

But there are many commercial SOC devices in our homes (like routers etc) which run embedded linux and which don't ever seem to suffer from this. I don't have to shut my router or my LTE gateway down before I power them off, but they always seem to boot cleanly. What tricks are used to achieve this and can I incorporate them into my own projects?

Thanks!

\$\endgroup\$
4
  • \$\begingroup\$ Shoddy power sequencing under a pre-bias? It fails to boot again immediately? Or hours/minutes later? \$\endgroup\$ – DKNguyen May 5 '20 at 0:56
  • \$\begingroup\$ Read only file systems help... Are you sure your gateway runs on an SOC? \$\endgroup\$ – Ron Beyer May 5 '20 at 1:08
  • \$\begingroup\$ @DKNguyen as I say in my experience we're talking corruption in the FS rather than shoddy power sequencing. \$\endgroup\$ – Jonathan Musther May 5 '20 at 1:25
  • \$\begingroup\$ @Ron Beyer - yes, it's a full linux system, I have shell access etc \$\endgroup\$ – Jonathan Musther May 5 '20 at 1:25
1
\$\begingroup\$

Aside from using BOD and power monitor circuits there are some things the embedded systems do to help mitigate abrupt power loss situations:

  • Read Only File Systems
    • This means that the file system cannot be corrupted because it is marked explicitly read-only. There may be data that is written to some logs stored in a different partition and some of the other techniques help protect that data.
  • Disable write-caching
    • Mostly used in desktop systems, write caching delays file system writes to a later time when there is a block of data to be written. Disabling this helps make sure that a power-out doesn't miss a cached write.
  • Picking the right disk file system
    • File systems like ext4, yaffs, and ubifs are specifically designed to work well in unreliable systems (although ubifs supports write caching).
  • File System Partitioning
    • Having a read-only partition that contains the kernel and critical programs and another partition that is read/write for non-critical data is a common method.
    • Having full backup copies of the kernel, rootfs, and data partitions.
    • Storing recovery OS on another partition
    • This is used in conjunction with file-system checking on start up. Some file systems run through a check during boot that determines if the partition is damaged or not. The boot system can use this to change to a backup.
  • Avoid storing critical data in memory, write it to storage as quickly as possible.

There are many other ways to help, but it should be noted that Raspbian is not a ruggedized system, just like the out-of-the-box Beaglebone or other "toy" embedded SOC "computers". These are meant to get a basic user up and running as quickly as possible, not to provide them with an industrial solution.

If you want to read more about backup/restoration software, I highly recommend SBabic's swupdate tool, it is extremely well documented and from a high-level goes through different schemes that industrial customers use to partition, backup, restore, and recover.

\$\endgroup\$
1
  • \$\begingroup\$ Much of the actual difference is in the type of storage device used, smaller systems use NOR flash or small NAND with a simple flash translation layer. Larger embedded devices often use eMMC made of NAND with a very robust flash translation layer. Raspberry pi's use cheap multi-level flash cells and an undocumented translation layer in the consumer SD card... With an unknown translation layer doing wear leveling, refreshing, and remapping, os-level strategies like read only file systems are no longer necessarily read only at hardware level, partition boundaries aren't actual boundaries, etc... \$\endgroup\$ – Chris Stratton May 5 '20 at 5:59

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.