Power off with non-ACPI compliant system.

[Ryan Belcher]

Hello All,

We're developing hardware and a "groundwork" XPe image for a customer
of ours. The motherboard we have to use does not have APM Power off
(nor an ATX power supply). It will not respond to the PowerOff BIOS
call.

The system is a regular X86 platform with a plenty of CF space and
lots of RAM and we can't use the EWF to get around a "surprise"
poweroff.

We're already committed to developing hardware to satisfy our
customers requirements so implementing a hardware and software
capability doesn't scare us too much.

We've got full access to the PC/104 (ISA and our preferred bus) and/or
the PC/104+ (PCI avoid if we can bus) buses.

Since ACPI and APM is a BIOS capability and *I think* is something we
can't cheat and get a hardware device to overlay with, I'm pretty sure
we're stuck with putting circuitry on there with a device at xxx I/O
address. The problem we're running into is figuring out when to tell
our circuitry to cut power. I presume this can only be accomplished
by a driver since it would be one of the first things to start up and
one of the last things to shut down, but we're still concerned that we
may cut power too soon e.g. driver exit and there's still stuff that
XP is doing.

We've got plenty of ugly ideas and a few inelegant ones, but I'd love
to know if anyone here has a truly beautiful idea for this.

TIA,

Ryan

 

[Doug Hoeffel]

Ryan:

Why can't you use the EWF?

.... Doug

 

[Kesavan]

hi Ryan,

Can you please give more detail on the surprise poweroff u were
talking about.Does this have something to do with the hardware unit...
!!!

 

[Ryan Belcher]

Doug, Kesavan,

Can't use the EWF because the customer's application is using MSMQ,
some form of database, event log, and needs write access to the O/S
files without downtime.

The systems are going to be protected by a battery and generator
system so I'm not too worried about random power loss, but what I am
worried about are the "surprise" poweroffs that impatient technicians
have a propensity to cause if the unit seems to be taking longer to
shut down than they think is proper. I'd like to make it difficult
for the technician to errantly kill power without having to rummage
through the back end of a rack (where the "big red switch" is) and
allow the O/S and our hardware to gracefully poweroff the system via a
homebrew softswitch on the front panel.

My ideal situation is to figure out how to allow our hardware with a
software backing basically make the equivalent to an ATX/APM/ACPI
softswitch.

Ryan

 

[Doug Hoeffel]

Ryan:

You could move the event log files to a partition not protected by EWF.
Refer to:
http://groups.google.com/[email protected]&rnum=1

What other OS files do you need write access too? Hosts file? or others?

WHat database are you using? SQL Server?

And for MSMQ, I ran up against that with EWF as well on a project that never
got off the ground. It's an issue with EWF if you want persistant MSMQ
queues. Maybe someone else in the group has solved it?

HTH... Doug

 

[Brad Combs]

Ryan,

How about something like this...

http://www.linuxfocus.org/English/January2001/article186.shtml

HTH,
--
Brad Combs
Imago Technologies, LLC

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Ryan Belcher]

Brad and Doug,

Brad:
I don't have good information regarding what our customer needs to
write to on what would be protected by the EWF (If I had my way...),
so I don't really know what would need to be offloaded to a non-EWF
volume. All I know is they don't want to mess with the EWF.. I do
know they want the MSMQ and some form of DB (still haven't found out
which they've decided on).

Doug:
As for the serial port driven switch. That's what we're going
towards, but the problem is the fact that the motherboard doesn't
support APM power off. If I had access to the code for the APM
(ACPI?, other?) driver in Windows, I could easily modify it to talk to
one of the registers on the hardware we're implementing, but (insert
obvious problem here). We're already writing a driver to service the
other functions of the hardware we're implementing, but the problem
that we're running into, is how do we make absolutely certain that all
other processes that Windows is going through for a shut down have
completed and our drivers exit/unload (when the "cut power" is sent to
our hardware), really is the last thing to happen.

Thanks,

Ryan