From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18617 invoked by alias); 22 Aug 2004 13:02:33 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 18598 invoked from network); 22 Aug 2004 13:02:29 -0000 Received: from unknown (HELO hermes.chez-thomas.org) (63.225.98.241) by sourceware.org with SMTP; 22 Aug 2004 13:02:29 -0000 Received: by hermes.chez-thomas.org (Postfix, from userid 2000) id 5606A100011; Sun, 22 Aug 2004 07:02:29 -0600 (MDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by hermes.chez-thomas.org (Postfix) with ESMTP id 8BCEC100010; Sun, 22 Aug 2004 07:02:28 -0600 (MDT) From: Gary Thomas To: Andrew Lunn Cc: Bart Veer , eCos Discussion In-Reply-To: <20040820163721.GW20020@lunn.ch> References: <20040716120045.GE6045@lunn.ch> <20040819152114.D85AEEC10C@delenn.bartv.net> <20040819163844.GO20020@lunn.ch> <20040820144436.43BA0EC10C@delenn.bartv.net> <20040820163721.GW20020@lunn.ch> Content-Type: text/plain Organization: MLB Associates Message-Id: <1093179748.10455.2735.camel@hermes> Mime-Version: 1.0 Date: Sun, 22 Aug 2004 13:02:00 -0000 Content-Transfer-Encoding: 7bit X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hermes.chez-thomas.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: Re: [ECOS] Flash infrastructure rework X-SW-Source: 2004-08/txt/msg00340.txt.bz2 On Fri, 2004-08-20 at 10:37, Andrew Lunn wrote: > On Fri, Aug 20, 2004 at 03:44:36PM +0100, Bart Veer wrote: > > > > >> cyg_flash_code_overlaps(): I am not sure this can be cleanly > > >> defined. For example, consider a platform with one flash chip > > >> that uses bottom boot blocks. If we want to make efficient use > > >> of this chip then we want to place the fis and fconfig data in > > >> these boot blocks. Hence the first boot block will contain some > > >> startup code followed by a jump to later in the flash, then > > >> we'll have the fis and fconfig blocks, and then the rest of the > > >> code. How would cyg_flash_code_overlaps() work with that > > >> scenario? > > > > Andrew> The HAL needs to be able to implement it. That is the only > > Andrew> thing that knows what goes where. I didn't really like > > Andrew> this function to start with, but redboot uses it quite a > > Andrew> lot for user input sanity checking. We could remove it and > > Andrew> hope the user knows what (s)he is doing. > > > > HAL checks may not suffice if the application makes virtual vector > > calls. RedBoot could get much the same functionality by detecting > > CYG_HAL_STARTUP_ROM and looking for an overlap with its own fis entry, > > without needing a dubious flash_code_overlaps() function. That won't > > work 100% on all platforms, e.g. there may be startup types other than > > ROM which also have RedBoot resident in flash, but it will work on > > most. > > OK. Like i said, i didn't like this function, so im happy to remove > it. Gary, what do you say? I don't care what it's called, or how it works, but I firmly believe that RedBoot needs a way to determine if the FLASH operation that the user requests is about to destroy the FLASH/ROM environment. I know that what's in there now is not perfect, but it catches 95%+ of the cases. RedBoot needs some way to ask the FLASH infrastructure "if I let you write/erase , will I wake up in the morning?" -- Gary Thomas MLB Associates -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss