"Non-volatile" OS ?

back to eprom?

The idea is to save the state of all active processes running in RAM on power interruption, and resume on power-up, quickly and smoothly....

You have essentially described a small PC --- so why not use one? Modern ones and their OSes all support some "hibernation" (also known as sleep-to-disk) mode. That's doing exactly what you're asking for.

That's a good question. I need suspend and resume times in large numbers of milliseconds, whereas (for example) my XP machine takes many many seconds to suspend and to resume. Any suggestions as to OS that can do this in sub-second time ? Thanks !

A Pocket PC kind of does this (Windows CE). That is, when you turn your PDA off the OS and apps are still intact when you turn it back on. All a PDA doing is battery backing it's RAM. The OS will last weeks on a charge and a lot more with a slightly bigger battery.

Thomas

You can't save only the state of all processes you must also save all variables otherwise you will have an erratic behaviour to put it nicely.

This is very interesting topic. until now, I didn't see any REAL OS which can support this feature. Though Non-volatile memory hasn't developed so mature as well. It is potentially big change for OS. I would like to know more people's points regarding this.

OK lets see what are options are...an OS typically resides in a non-volatile form of memory when it is powered down like a hard disk or Flash in a PDA. Upon power up, portions of the OS are moved to a form of memory with quick read/write times, typically RAM. The problem is that RAM is volatile.

If you replaced the RAM with Flash you would run into problems. However, the read/write speed of Flash isn't one of them. In theory, running multiple Flash chips in parallel could achieve read/write speeds equal to or better than RAM. The real problem is that Flash has a limited amount of read/write cycles. Typically "up to 100000". Exceed this limit and sectors would drop and the computer would soon fail.

Ramtron has non-volatile memory with access speeds like RAM called FRAM (Ferroelectric non-volatile RAM). It has an unlimited amount of read/write cycles. However, the chips MByte capacities are currently small and real haven't been designed with this application in mind. It probably would work, but I don't know what the end cost to a consumer would be.

My personal belief is that certain kinds of RAM don't require much current to back-up, so get the UPS guys and the PC guys to agree on a standard that supplies DC power from the UPS to the PC in order to back up the RAM. Then your OS is non-volatile and you don't have to wait for that ever growing length of time it takes for a PC to boot. Laptops already have batteries to back-up the RAM and could be set as a user option at the cost of killing your battery if left unplugged for a while.

Thomas

The "state of all processes" includes the state of all RAM used by the process plus any OS resources used by the process (things like file handles, or the state of an OS call in progress at shutdown, all need to remain valid)....

FRAM is still very expensive. Static RAM, while easy to back up with low power consumption, is much more expensive than dynamic RAM. However, the OS still needs to be able to tolerate turning off and on (reinitialization of low-levels without disruption of any processing in progress during suspend-resume). Flash lifetime wouldn't be a problem with the number of cycles my particular application requires, however the best would be a serial-flash that has onboard wear-leveling and error-correction.

Whats a good question? You must include context in your articles. There is no guarantee that any previous article is available to the reader at any time. Instructions for doing this on even the foul google usenet interface are in my sig, below.

If you have peripherals that are powered down and up some processes can be in a state not consistent with the state of the hardware that will have to be reinitialized.

Even if the processes receive a message in order to reinitialize you can have transient states where processes will expect the hardware to be in a running state.

You could perhaps use exceptions in order to force the processes to reinitialize immediately. But what is the advantage over reinitializing the whole application ?

In the days of core memory, such features were common. When the AC was lost, the power fail interrupt was activated, which saved the CPU registers as well as the peripheral register contents into core memory and then halted the processor.

Upon power restoration, the power fail interrupt was executed again, restoring the registers just as returning from the interrupt. Some operations might need retrying (such as disk access), but that would be the case even if the processor was halted and then resumed or single stepped..

Even with dynamic-RAMs, the memory could be maintained with battery power, that powered the memory chips and the refresh circuit to refresh the chips every 2 ms, which did not consume a lot of power.

Paul

File handles ? - you mean this has to survive a power fail during a file write - to what HDD/FlashDrive/USB Drive... ?

First, you need a Board/BIOS that can start quickly, and the more complex that is, the less likely you are to control that. [Your mention of USB and File handles makes this sound a little scary...]

Next, you need to define the data-sets of all processes, ie Sizes/Content/Integrity checks, and the risk/consequence of any errors.

If you have control on the HW, then you should look to use FRAM or MRAM (or BB SRAM), and map all those data-sets into the NV space.

On startup, your SW needs to check validity of the datasets, and decide if a full-init is needed, or if a quick-go is OK. The OS cannot do this for you. It has no idea of the HW and real world changes that may, or mat not, affect your code.

An alternative approach, is to use Microcontrollers for the Real-World IO stuff, and they CAN re-start very quickly indeed, then run safely whilst they wait for an update from the slower OS. There are plenty of uC now, with large resource sets :

Maxim have an interesting MAX3420 SPI-USB device, that looks to be able to add 12Mbd USB to almost any small uC. SPI to the uC makes sense here; much faster than the RS232-USB devices, and fewer pins than the FIFO USB devices.

-jg

Sure. Assume there's an embedded flash file system, and another file system plugged in on a USB key. For the first, the supercap is sized to guarantee completion of an IO operation and leaving the device in a sane state. For the second, it might fail, and return an IO error to the app (just like if the user unplugs the thing while its in use).

Right, this is what I did in the OS I wrote. If there wasn't a smooth shutdown (integrity check failed), it did a cold-start. Of course that never happens (it really does not happen).

The OS can ensure that a sane shutdown was performed, such that it is safe to restart all processes, then perform any required low-level HW reinit, then restart all processes and message them that a restart happened.

The low-level stuff is easy; what I'm looking for is safe save/restart of the larger high-level stuff (whose context is large and thus obnoxious to serialize and restart from at the app level).

Hope I'm explaining clearly... Thanks for the thoughts ! Best Regards, Dave

Similarly, I've used a warm-start system that looks like: - on failing power, save context, and shut-down cleanly - on start-up and stable power, re-initialise hardware, then restore context if possible (validated etc); else do hard restart

Which seems to be what the OP wants. The difficulty is in defining "context", and validating that context at power-up.

With a dedicated product, it's easy enough - decide which parameters/states are expensive to restart, and store these at power-down in non-vol memory. Do some sanity-checks at power-up, and you're done.

With a general-purpose RTOS, if you're trying to keep the RTOS task states during power-down, it's a different ballgame, and I'm not convinced it's either desirable or necessary as a general OS feature - the *actual* physical context may be entirely different when the system wakes up, seconds, hours, years later. Hardware will need re-initing anyway. Seems to me better to store "hints" as to initial context, than to depend on an OS to (effectively) pick up after an indefinite pause in a now-different hardware environment with no insight into what's changed.

YMMV.

Steve

Many PDP-11 and VAX processors had the option of supplying the DRAM from a battery and since the operating systems dated from the core memory days, they could handle the power failures quite nicely as long as the battery power lasted.

It depends how the real time clock behaves. As long as the I/O requests timeout immediately after restoration of power, the operation can be retried immediately.

For control loops, it might be a good idea e.g. to reinitialize the PID-controllers, but you would need this feature anyway to handle an intermittent sensor failure. Thus, it would be enough for the sensor driver to report "sensor failure" for a few cycles after power-up, which would also reinitialize the PID controller.

Paul

Thanks all for the comments ! However, I don't think anyone has suggested a real-life-available COTS OS that has the required features, other than possibly Windows CE (which probably doesn't meet the toolchain requirements).

Any other ideas ? Any OS-vendors out there ready to chime in ?

Thanks in advance for your comments, Best Regards, Dave

What about Symbian OS ? AFAIK one can use the gcc toolchain. It is 32-bit, and runs in fairly small memory footprint. About the USB support I am not so sure, but I think it would be available.

Regards Anton Erasmus