* [ECOS] Is cache disabling necessary during flash programming/erase cycles?
@ 2007-03-30 13:44 Lars Povlsen
2007-03-30 13:56 ` Gary Thomas
0 siblings, 1 reply; 4+ messages in thread
From: Lars Povlsen @ 2007-03-30 13:44 UTC (permalink / raw)
To: eCos Discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] Is cache disabling necessary during flash programming/erase cycles?
2007-03-30 13:44 [ECOS] Is cache disabling necessary during flash programming/erase cycles? Lars Povlsen
@ 2007-03-30 13:56 ` Gary Thomas
2007-03-30 14:15 ` Lars Povlsen
0 siblings, 1 reply; 4+ messages in thread
From: Gary Thomas @ 2007-03-30 13:56 UTC (permalink / raw)
To: Lars Povlsen; +Cc: eCos Discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] Is cache disabling necessary during flash programming/erase cycles?
2007-03-30 13:56 ` Gary Thomas
@ 2007-03-30 14:15 ` Lars Povlsen
2007-03-30 14:35 ` Gary Thomas
0 siblings, 1 reply; 4+ messages in thread
From: Lars Povlsen @ 2007-03-30 14:15 UTC (permalink / raw)
To: eCos Discuss; +Cc: Gary Thomas
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] Is cache disabling necessary during flash programming/erase cycles?
2007-03-30 14:15 ` Lars Povlsen
@ 2007-03-30 14:35 ` Gary Thomas
0 siblings, 0 replies; 4+ messages in thread
From: Gary Thomas @ 2007-03-30 14:35 UTC (permalink / raw)
To: Lars Povlsen; +Cc: eCos Discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-03-30 14:15 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-30 13:44 [ECOS] Is cache disabling necessary during flash programming/erase cycles? Lars Povlsen
2007-03-30 13:56 ` Gary Thomas
2007-03-30 14:15 ` Lars Povlsen
2007-03-30 14:35 ` Gary Thomas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).