Paul
Tue Dec 18 10:06:38 PST 2007
Not directly. There's still some time in the chat. If I don't see you
there, I'll try to get the question asked. As you might expect, developers
spending all their time doing support is a recipe for disaster in project
schedules...
Paul T.
"Hector Bujanda" <hector_bujanda@digi.com> wrote in message
news:ePEaZ2ZQIHA.2268@TK2MSFTNGP02.phx.gbl...
> Is it possible to reach those Filesystem guys on a newsgroup??? I only see
> Microsoft.public.windows.file_system; not any embedded.
>
>
>
> I've also suspected from time to time on the filesystem. But I've even
> deactivate the block device driver so I'm sure there is no any other
> persistent storage where to keep another registry.
>
>
>
> Thank, Buji
>
>
>
> "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
> com> wrote in message news:OI7NxgZQIHA.5264@TK2MSFTNGP02.phx.gbl...
>> My guess would be that yes, they've added something to detect when you're
>> trying to load a registry not intended for your hardware. This would be
>> a good question for the Windows CE 6 chat that is supposed to be going on
>> right now, although I think there's a problem with it. The filesystem
>> guys would probably know the answer off the top of their heads...
>>
>> Paul T.
>>
>> "Hector Bujanda" <hector_bujanda@digi.com> wrote in message
>> news:OsIfhBZQIHA.2376@TK2MSFTNGP02.phx.gbl...
>>> Hi Paul,
>>>
>>>
>>>
>>> I know it's difficult to help. It was just in case you knew some
>>> miraculous trick J
>>>
>>>
>>>
>>> I'm trying to recover a registry saved with the same kernel. Just invoke
>>> RegFlushKey from an application and make a cold reset. After reset, I
>>> read the registry, the checksums are OK and I provide to the kernel the
>>> pieces of registry as it ask for them... but when the device stats I
>>> always get the default registry (not the changes I made before
>>> RegFlushKey).
>>>
>>>
>>>
>>> With porting to another platform I mean:
>>>
>>> - We had that functionality working for a different BSP (different
>>> hardware, and WinCE6.0 BSP).
>>>
>>> - No we have a new hardware and a new WinCE BSP (Samsung SMDK2443)
>>>
>>>
>>>
>>> The library that implements the OEM function to read and write the
>>> registry from/to the nand is almost hardware independent.
>>>
>>> So I suspect mainly of an OS miss-configuration. Might be the kernel be
>>> checking some timestamp, boot argument (like
>>> IOCTL_HAL_GET_HIVE_CLEAN_FLAG - I know that HIVE should not be important
>>> while using RAM-BASED) so it refuses the new registry???
>>>
>>>
>>>
>>>
>>>
>>> Regards, Buji
>>>
>>>
>>>
>>>
>>> "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
>>> DOT com> wrote in message news:uvuNvsYQIHA.3676@TK2MSFTNGP06.phx.gbl...
>>>> Are you trying to load the registry saved with a different OS into a
>>>> new OS that's configured differently? It didn't used to care, but
>>>> maybe CE6 is more-careful about doing that now. It's hardly ever
>>>> correct.
>>>>
>>>> If that's not what you're doing, please give us some more information
>>>> on what you mean by, "Now I'm porting that functionality to another
>>>> platform". "Platform" is grossly overused in CE development...
>>>>
>>>> Paul T.
>>>>
>>>> "Hector Bujanda" <hector_bujanda@digi.com> wrote in message
>>>> news:%23antIfWQIHA.1184@TK2MSFTNGP04.phx.gbl...
>>>>> Hi mates,
>>>>>
>>>>>
>>>>>
>>>>> We successfully implemented one year ago a RAM-BASED persistent
>>>>> registry solution on one platform that keeps the registry in a flash
>>>>> when RegFlushKey is called and recovers it during boot.
>>>>>
>>>>> As you can imagine, to implement it we developed OEM functions for
>>>>> reading and writing the registry and filled with them following
>>>>> pointers in OEMInit: g_pOemGlobal->pfnReadRegistry ,
>>>>> g_pOemGlobal->pfnWriteRegistry
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Now I'm porting that functionality to another platform and it's not
>>>>> working.
>>>>>
>>>>>
>>>>>
>>>>> - We make a checksum of the registry in pfnWriteRegistry and verify in
>>>>> pfnReadRegistry. And I've verified that I provide to the kernel in
>>>>> pfnReadRegistry exactly what the kernel gives us in pfnWriteRegistry.
>>>>> I've also tested to move the storage to SRAM to discard any flash
>>>>> algorithm error.
>>>>>
>>>>>
>>>>>
>>>>> - I also see all the sequence of the kernel calling pfnReadRegistry a
>>>>> couple of times with the REG_READ_BYTES_START flag and many more with
>>>>> no flags until we return 0. The size seems to be reasonable.
>>>>>
>>>>>
>>>>>
>>>>> - Both platforms are ARM based running WinCE6.0.
>>>>>
>>>>>
>>>>>
>>>>> - So I'm quite sure that we are providing a good registry BUT the
>>>>> kernel doesn't use it and uses the default (default.fdf)
>>>>>
>>>>>
>>>>>
>>>>> - I've also played a little bit with the NKForceCleanBoot and other
>>>>> boot flags with no success.
>>>>>
>>>>>
>>>>>
>>>>> ANY Suggestion????
>>>>>
>>>>> Why the kernel doesn't want my registry???
>>>>>
>>>>>
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>>
>>>>>
>>>>> Buji
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>