I have not done this for linux, but I have done it for other embedded
OSes. We get a power down interrupt, stash everything of importance,
lose power, restore power, restore the machine state, and then do a
return from interrupt.
When you do a hot start, you also have to re-initialize the hardware
back to the state it was in before the power down. This means, for
example, you have to stash the configuration of the serial ports so
that you know what baud rate it was set to when you lost power. This
is potentially a big problem for linux: you will have to examine and
probably modify all the device drivers you use. If you have a fairly
fixed configuration (e.g. the baud rate is always 19200) and/or you
have a limited number of drivers, this becomes easier.
A problematic area is interrupts: if you are in the middle of a serial
send (to continue on the serial example), you will have a buffer full
of data an an interrupt that you expect to happen soon or that is
pending at the point of the power down. When you do your hot start,
you have to figure out what to do. The easiest thing is to ignore the
problem: the serial send driver will (if coded properly) time out on
the send and the upper layers (if coded properly) will do an
appropriate error recovery (resend the message or drop it, as required
by your protocol or application).
More problematic are things outside of your CPU that have smarts, like
disk drives. If you don't have a controlled power down, you might have
been in the middle of a sector write... you just trashed a
sector. Note that hard drives have caches in them, seek latencies, and
rotational latencies, which could interfere with your controlled
shutdown -- it is hard to guarantee when a sector written to the drive
actually gets written to the platter and will vary between disk drive
types. You can compensate for this by saving the last sector(s)
written and rewrite them on a hot power up. In our systems, we don't
have hard drives, but we have flash and EEPROM. We make our power
supply people give us enough warning to complete a worst case write
operation.
The disk drive problem is typical of anything outside of your CPU that
has smarts and/or a state associated with it.
Nothing insurmountable, just things to think about. When you get it
all working right, it is really cool. The application code thinks that
it just had a _really_ long interrupt, it cannot tell differently. Oh,
that is another problem area. If your application uses time or date in
some manner, it may get confused when it goes around the loop the next
time and all of a sudden it is three years in the future :-).
gvb
At 03:48 AM 3/8/00 -0600, Chae-seok Im wrote:
>Hello.
>I'm developing arm7 processor board, specifically
>cirrus logic ep7212. The expression, 'hot boot' is
>named by myself. You know 'cold boot' and 'warm boot'
>already? 'hot boot' means the functionality like this:
>
>When you power up a system, it reloads its previous
>working environment or context, as quick as possible.
>
>I think, in embedded linux system, this could be implemented
>like this:
>
>1. When you power down a system, it stores the values of its
>registers to some location.
>2. Contents of DRAM is reserved by back-up batteries.
>3. When you power up again, it reloads saved values to the
>original register.
>4. Progress jobs at the points saved previously.
>
>I know this kind of function is implemented in some popular PDAs,
>like Palm pilot, ... But I don't know it is implemented in any
>embedded linux system. If you have any information,
>could you tell me how to support this?
>I expect your kind answer. Bye.
--
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the command "unsubscribe linux-embedded" in the message body.
For more information, see <http://waste.org/mail/linux-embedded>.
