From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16821 invoked by alias); 30 Mar 2007 14:15:39 -0000 Received: (qmail 16762 invoked by uid 22791); 30 Mar 2007 14:15:35 -0000 X-Spam-Check-By: sourceware.org Received: from 204-133-123-27.dia.static.slbbi.com (HELO mail.chez-thomas.org) (204.133.123.27) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 30 Mar 2007 15:15:23 +0100 Received: by mail.chez-thomas.org (Postfix, from userid 999) id 712EF195029D; Fri, 30 Mar 2007 08:15:21 -0600 (MDT) Received: from [192.168.1.101] (hermes_local [192.168.1.101]) by mail.chez-thomas.org (Postfix) with ESMTP id B930B195008F; Fri, 30 Mar 2007 08:15:17 -0600 (MDT) Message-ID: <460D1B74.80502@mlbassoc.com> Date: Fri, 30 Mar 2007 14:35:00 -0000 From: Gary Thomas User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: Lars Povlsen CC: eCos Discuss References: <376637F07F8A9242AD11921B15FA17DC1E6382@mx-dk.vsc.vitesse.com> <460D1445.3050403@mlbassoc.com> <460D1697.3010902@vitesse.com> In-Reply-To: <460D1697.3010902@vitesse.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Is cache disabling necessary during flash programming/erase cycles? X-SW-Source: 2007-03/txt/msg00186.txt.bz2 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