Re: KernelFindMemory and cache write-back

Jean-Jacques,

It does look like KernelFindMemory has made the assumption that those pages
aren't dirty in the cache. I have notified the kernel team.

However, it is very atypical for those pages to be dirty. The reason we make
that assumption is because the LogPtr is pointing to an area of RAM that
your .BIN file has designated as belonging to the kernel, so if you OAL or
bootloader is touching it you should (1) be very careful and (2) flush the
cache as you have done.

As Dean points out, you should use NKForceCleanBoot() API if you want to
clear the object store. It touches those pages via uncached address.

Does your bootloader or OEMInit code potentially write to that area? Or do
we have something stranger going on here?


Thanks,
John Eldridge
Supportability Architect | Microsoft Corporation
http://blogs.msdn.com/kitlfirst

KITL ?? ??? ? ??.
KITL ?????. ??KITL, ????.
KITL ????????????????
KITL primero. haga preguntas después.
KITL First. Ask questions later!

Disclaimer: This posting is provided "as is"
with no warranties, and confers no rights.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



"Dean Ramsier" <ramsiernospam@xxxxxxxxxx> wrote in message
news:e5WbfFzdFHA.3040@xxxxxxxxxxxxxxxxxxxxxxx
> I've never seen it, any chance it's a problem with correctly handling a
> clean boot? For example, you need to be calling NKForceCleanBoot() in
> OEMInit() unless you know the object store is valid (warm boot). It deals
> with memory in this area, but I don't know if it would result in your
> problem (haven't looked at the code...)
>
> --
> Dean Ramsier - eMVP
> Vibren Technologies
> http://www.vibren.com/Products/schema_bsp.htm
>
>
> "Jean-Jacques Hiblot" <jjhiblot_NOSPAM_AT_adeneo.adetelgroup.com> wrote in
> message news:unUrbjndFHA.3488@xxxxxxxxxxxxxxxxxxxxxxx
>> Hi,
>>
>>
>>
>> I've found something weird in the WinCe kernel start-up code:
>> In the KernelfindMemory function (that's called right after OEMInit), the
>> kernel sets up some data in the RAM via some uncached access and at the
> end
>> of KernelfindMemory writes-back the whole cache in RAM. The result is
>> that
>> the data that had been set up in RAM may be (and in my case was)
> overwritten
>> with some bad values. I've seen this when running CE 5.0 (and 4.2 as
>> well)
>> on a AT91RM9200 (ARM920T)
>>
>>
>>
>>
>>
>> Here is a sample from the kernelFindMemory function (located in loader.c
> in
>> the private branch)
>>
>> ....
>>
>>
>>
>> // *MUST* make the pointer uncached (thus or in 0x20000000)
>> //
>> // LogPtr at the start of RAM holds some header information
>> //
>> LogPtr = (fslog_t *)PAGEALIGN_UP ((pTOC->ulRAMFree+MemForPT)|
>> 0x20000000);
>> [
>>
>> ..
>>
>> do a lot of things with LogPtr's content...
>>
>> ...
>>
>> ]
>>
>> OEMCacheRangeFlush (0, 0, CACHE_SYNC_WRITEBACK);
>>
>> ...
>>
>> The thing is that it may happen that the cache line where logPtr's
>> content
>> would be located may be in cache and dirty when KernelFindMemory is
> called.
>> In this case, when OEMCacheRangeFlush, we loose the new content of
>> LogPtr.
>> Depending on the mapping of the kernel, it may or may not happen.
>>
>>
>>
>>
>>
>> When the problem happens, the platform stops executing and usually
>> display
>> wrong values in the list of the memory sections (Start value would be
>> 0x000000000 for example instead of something like 0x800xxxxx).
>>
>> The workaround for this is to write back the cache at the end of OEMInit.
>>
>>
>>
>> My question is: Is this something that somebody had already seen? Would
> this
>> happen because we've forgotten to take care of something in our BSP?
>>
>>
>>
>>
>> ----------------------------------------------------------------
>> Jean-Jacques Hiblot
>> ADENEO (ADESET)
>> Windows Embedded Consultant
>> <jjhiblot AT adeneo DOT adetelgroup DOT com>
>> http://www.adeneo.adetelgroup.com
>> Tl : +33 (0)4.72.18.57.77
>> Fax : +33 (0)4.72.18.57.78
>> ----------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>


.

Relevant Pages

  • Re: KernelFindMemory and cache write-back
    ... OEMInit() unless you know the object store is valid. ... > of KernelfindMemory writes-back the whole cache in RAM. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: KernelFindMemory and cache write-back
    ... > end of KernelfindMemory writes-back the whole cache in RAM. ... > <jjhiblot AT adeneo DOT adetelgroup DOT com> ...
    (microsoft.public.windowsce.platbuilder)
  • KernelFindMemory and cache write-back
    ... In the KernelfindMemory function, ... kernel sets up some data in the RAM via some uncached access and at the end ... of KernelfindMemory writes-back the whole cache in RAM. ... The thing is that it may happen that the cache line where logPtr's content ...
    (microsoft.public.windowsce.platbuilder)