Re: WinCE 5.0 RegFlush on Cold Boot

Yes, a lack of coffee and a poor ability with calculator seems to have
skewed my numbers a bit. Still, based on testing I've done with a constant,
fast as you can, write to flash I've seen a device run for a couple of weeks
before a failure that was bad enough to require a device reboot (which fixed
the error and allowed for a continuation of testing).

I understand the desire to prevent the write - I just think that in the
grand scheme of things there are a lot of other things that have a much
higher risk to the device and application and assuming you have finite
resources and finite time before you need to field the solution, there are
probably better things to spend time testing and worrying about.

IMO, the highest risk when using flash is full corruption due to power
interruption during an erase or write, especially during an erase or write
of the sector containing either the disk FAT (losing all data) or the CE
image itself (turning the device into a brick). Considering and testing for
your exposure to those scenarios is probably a much better use of your
developer resources, especially since I've seen the resulting support costs
of fielding devices when those scenarios weren't considered beforehand.


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com



"Peter K" <anonymous@xxxxxxxxx> wrote in message
news:udvkzmXfIHA.2448@xxxxxxxxxxxxxxxxxxxxxxx
If you do take the worse case of erasing and then writing to a block once
per second it would take:

1000000 / (60 * 60) = 27.77777 hours (just over a day) to wear out a
block.

even once every 10 seconds

(100000 / (60 * 60)) * 10 = 277.7777 hours.

I know that this is not what is happening and I'm sure this registry flush
at boot would not wear out a flash block for years. But like I mentioned
this has become a focus for others and I would like to stop the OS from
doing the flush at boot.

From my log files the RegFlush performs 1017 writes to the flash for a
total of 210635 bytes written and one block erased. That is one sector
(not always the same one with the wear levelling) of flash written and
erased on every boot for no reason.

"<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message
news:ep4irNXfIHA.968@xxxxxxxxxxxxxxxxxxxxxxx
Typical flash life is > 100,000 writes in a sector. If we assume that
wear-levelling isn't used (and it is) then even if they restarted the
device once every second, 24 hours a day, 7 days a week, it would still
take over a year to fail. Most devices I know of can't boot in under 10
seconds, so that means if you cycled it as fast as the device allowed
constantly it would still last a decade before you had a failure.

And still, a failure is most likely to just cause the bad sector to be
quarantined and no longer used, and your FSD would then start writing to
another sector for the next decade.

I'm thinking you might want to spend your time worrying about other
possible failures. What happens if power is cut while any write
operation is happening? There's a lot more risk there than what you're
looking at now.


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com



"Peter K" <anonymous@xxxxxxxxx> wrote in message
news:eIqku5WfIHA.5280@xxxxxxxxxxxxxxxxxxxxxxx
I would have to load a debug image and look for the messages you have
mentioned.

I am sure that the periodic flush is not enabled, this was one of the
first things I looked for when I saw this behaviour.

Our devices are Data Terminals in Taxi cabs and they cold boot every
time. There is some concern that the extra writes to the flash may cause
premature failure to flash blocks in the device. So the many writes to
the flash at boot up has become a focus. I am sure that 1 or 2 boots a
day would not be a problem, but user will try all sorts of things to
cheat a system and one of them is rebooting the device.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message news:unLGJsWfIHA.536@xxxxxxxxxxxxxxxxxxxxxxx
Is there a debug message associated with the registry operation?
Something like "Finalizing registry", for example, maybe just before
the "This device has booted <x> times" message? You're sure that you
don't have the periodic flush thread enabled?

On the assumption that this *is* the intended behavior, what problem is
it causing for you?

Paul T.

"Peter K" <anonymous@xxxxxxxxx> wrote in message
news:Os0FiYWfIHA.5996@xxxxxxxxxxxxxxxxxxxxxxx
I'm using RAM and ROM File System. The nk.bin is loaded into flash
above the bootloader and is XIP.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message
news:OND4HXWfIHA.4728@xxxxxxxxxxxxxxxxxxxxxxx
What filesystem type are you using, RAM/ROM or ROM-only? How is
nk.bin loaded? Flashed into linear flash? Loaded by the bootloader
into RAM from somewhere?

Paul T.

"Peter K" <anonymous@xxxxxxxxx> wrote in message
news:eJJh$SWfIHA.4144@xxxxxxxxxxxxxxxxxxxxxxx
Paul,

I have 2 volumes on the device, one that is bootable and hidden
where the Hive registry files reside and the other for file storage.
The debugging I added shows which volume is being written to.


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no
spam DOT com> wrote in message
news:%23aBmeMWfIHA.2448@xxxxxxxxxxxxxxxxxxxxxxx
How do you know that the command corresponds to a registry write?
It's a hive registry. Any write to the 'disk' would generate some
writes.

Paul T.

"Peter K" <anonymous@xxxxxxxxx> wrote in message
news:%23kWImBWfIHA.5280@xxxxxxxxxxxxxxxxxxxxxxx
Hello,

I have a WinCE 5.00 OS with IPSM 4.0 set up with Hive Registry,
does anyone know how to stop the OS from backing up the Registry
on a cold boot. I believe that it is doing a RegFlushKey when it
update the BootCount in the registry but I can not find any
reference to this in the OS source code.

I have check all my device drivers to see if any of them might be
calling RegFlushKey and they are not.

The reason I know that there is a backup of the registry at boot
up is because I added debugging in the OALIoCtlPsmFlashCmd
function to show when writes and erases occur in the IPSM.

Thanks for the help



















.

Relevant Pages

  • Re: WinCE 5.0 RegFlush on Cold Boot
    ... There's no clean way to prevent the flush, ... I know that this is not what is happening and I'm sure this registry flush ... at boot would not wear out a flash block for years. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: WinCE 5.0 RegFlush on Cold Boot
    ... Typical flash life is> 100,000 writes in a sector. ... Our devices are Data Terminals in Taxi cabs and they cold boot every time. ... Something like "Finalizing registry", for example, maybe just before the ...
    (microsoft.public.windowsce.platbuilder)
  • Re: WinCE 5.0 RegFlush on Cold Boot
    ... I know that this is not what is happening and I'm sure this registry flush ... at boot would not wear out a flash block for years. ... a failure is most likely to just cause the bad sector to be ...
    (microsoft.public.windowsce.platbuilder)
  • Re: WinCE 5.0 RegFlush on Cold Boot
    ... flash chips to avoid repeatedly writing to the same sectors. ... I suppose that, item 2, you could use a RAM-based registry, which I don't ... Paul T. ... Our devices are Data Terminals in Taxi cabs and they cold boot every time. ...
    (microsoft.public.windowsce.platbuilder)
  • BSOD WINXPPRO WILL NOT LOAD
    ... Hello, I have tried many different ways to get the system to boot again, but ... failure) The registry cannot load the hive ...
    (microsoft.public.windowsxp.general)