[ECOS] Is cache disabling necessary during flash programming/erase cycles?

[ECOS] Is cache disabling necessary during flash programming/erase cycles?

[Lars Povlsen]

Hello folks,
 
Many of the flash_XXX() functions in
.../packages/io/flash/current/src/flash.c have the caches disabled while
accessing the flash.

According to flash.h - and I quote - 

"Execution of flash code must be done inside a
HAL_FLASH_CACHES_OFF/HAL_FLASH_CACHES_ON region - disabling the cache on
unified cache systems is necessary to prevent burst access to the flash
area being programmed. With Harvard style caches, only the data cache
needs to be disabled, but the instruction cache is disabled for
consistency".
 
In our case we have a Harvard style cache running on an ARM9. The
address space covered by the flash is uncached and unbuffered (We're
running ROMRAM), so my question is:

Is disabling of the DCache really needed on such a system?
 
Thx in advance.

Lars Povlsen

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Is cache disabling necessary during flash programming/erase cycles?

[Gary Thomas]

Lars Povlsen wrote:
> Hello folks,
>  
> Many of the flash_XXX() functions in
> .../packages/io/flash/current/src/flash.c have the caches disabled while
> accessing the flash.
> 
> According to flash.h - and I quote - 
> 
> "Execution of flash code must be done inside a
> HAL_FLASH_CACHES_OFF/HAL_FLASH_CACHES_ON region - disabling the cache on
> unified cache systems is necessary to prevent burst access to the flash
> area being programmed. With Harvard style caches, only the data cache
> needs to be disabled, but the instruction cache is disabled for
> consistency".
>  
> In our case we have a Harvard style cache running on an ARM9. The
> address space covered by the flash is uncached and unbuffered (We're
> running ROMRAM), so my question is:
> 
> Is disabling of the DCache really needed on such a system?

Probably not, but not doing so will probably not affect the
performance greatly since you'll still be stuck in those loops
waiting for the device to do its thing.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Is cache disabling necessary during flash programming/erase cycles?

[Lars Povlsen]

Gary Thomas wrote:
>
> Lars Povlsen wrote:
> > Hello folks,
> > 
> > Many of the flash_XXX() functions in
> > .../packages/io/flash/current/src/flash.c have the caches disabled 
> while
> > accessing the flash.
> >
> > According to flash.h - and I quote -
> >
> > "Execution of flash code must be done inside a
> > HAL_FLASH_CACHES_OFF/HAL_FLASH_CACHES_ON region - disabling the 
> cache on
> > unified cache systems is necessary to prevent burst access to the flash
> > area being programmed. With Harvard style caches, only the data cache
> > needs to be disabled, but the instruction cache is disabled for
> > consistency".
> > 
> > In our case we have a Harvard style cache running on an ARM9. The
> > address space covered by the flash is uncached and unbuffered (We're
> > running ROMRAM), so my question is:
> >
> > Is disabling of the DCache really needed on such a system?
>
> Probably not, but not doing so will probably not affect the
> performance greatly since you'll still be stuck in those loops
> waiting for the device to do its thing.
>
Gary,

Problem is not so much the flash performance - its the *rest* of the 
system while the flash is being updated (config update in this case). 
The system becomes very sluggish during the update.

We'll probably do a CDL option to disable the disable (:-) Is a patch of 
interest if it pans out OK?

---Lars

PS: The flash accesses (read as well as write) are guarded by a  mutex  
at system level.

> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Is cache disabling necessary during flash programming/erase cycles?

[Gary Thomas]

Lars Povlsen wrote:
> Gary Thomas wrote:
>>
>> Lars Povlsen wrote:
>> > Hello folks,
>> > > Many of the flash_XXX() functions in
>> > .../packages/io/flash/current/src/flash.c have the caches disabled 
>> while
>> > accessing the flash.
>> >
>> > According to flash.h - and I quote -
>> >
>> > "Execution of flash code must be done inside a
>> > HAL_FLASH_CACHES_OFF/HAL_FLASH_CACHES_ON region - disabling the 
>> cache on
>> > unified cache systems is necessary to prevent burst access to the flash
>> > area being programmed. With Harvard style caches, only the data cache
>> > needs to be disabled, but the instruction cache is disabled for
>> > consistency".
>> > > In our case we have a Harvard style cache running on an ARM9. The
>> > address space covered by the flash is uncached and unbuffered (We're
>> > running ROMRAM), so my question is:
>> >
>> > Is disabling of the DCache really needed on such a system?
>>
>> Probably not, but not doing so will probably not affect the
>> performance greatly since you'll still be stuck in those loops
>> waiting for the device to do its thing.
>>
> Gary,
> 
> Problem is not so much the flash performance - its the *rest* of the 
> system while the flash is being updated (config update in this case). 
> The system becomes very sluggish during the update.
> 
> We'll probably do a CDL option to disable the disable (:-) Is a patch of 
> interest if it pans out OK?

Sure, please send it on.

Note: I think that much of this effort is already present in the
FLASHv2 branch (but I've not used it, so I can't say for sure)

> 
> PS: The flash accesses (read as well as write) are guarded by a  mutex  
> at system level.


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss