From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20364 invoked by alias); 22 Feb 2011 19:19:14 -0000 Received: (qmail 20266 invoked by uid 22791); 22 Feb 2011 19:19:12 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-bw0-f50.google.com (HELO mail-bw0-f50.google.com) (209.85.214.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Feb 2011 19:19:06 +0000 Received: by bwz2 with SMTP id 2so2635332bwz.9 for ; Tue, 22 Feb 2011 11:19:03 -0800 (PST) Received: by 10.204.6.212 with SMTP id a20mr2858986bka.210.1298402343510; Tue, 22 Feb 2011 11:19:03 -0800 (PST) Received: from sg-laptop ([178.123.169.119]) by mx.google.com with ESMTPS id w3sm4748955bkt.17.2011.02.22.11.18.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Feb 2011 11:19:00 -0800 (PST) Date: Tue, 22 Feb 2011 19:19:00 -0000 From: Sergei Gavrikov To: John Dallaway cc: eCos development list Subject: Re: LPC2xxx internal flash driver In-Reply-To: Message-ID: References: <4D63A876.2020706@dallaway.org.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2011-02/txt/msg00007.txt.bz2 > John Dallaway wrote: > > > I note that Hans Rosenfeld's LPC2xxx flash driver package > > (CYGPKG_DEVS_FLASH_ARM_LPC2XXX) is not referenced by any target at > > present. There are 7 LPC2xxx targets which could potentially make use of > > this hardware package. Can you see any reason why we should not add the > > package to the various LPC2xxx target definitions in ecos.db (including > > your own contributed ports)? Sergei Gavrikov wrote: > As far as I can recall the driver was not CDLized much (it was designed > only for lpc22xx parts in a mind (i.e. for its internal flash geometry: > 8x8K + 2x64K + 8x8K and it manages only those last eight 8K sectors). > It seems to me it was implemented before a merge with flashv2 code. I > recall that I played with the driver in RedBoot on Olimex LPC-H2294 > header board, but, I have to re-test it with nowadays CVS stuff. I will > try to do it this evening and let you know. However, I think that driver > can be used on olpch2294, olpcl2294, olpce2294 and phycore229x targets > when eCos legacy flash API is used. Now, after testing, I can say, There is a pitfall, - "Flash legacy API vs. flash v2 API". The Hans Rosenfeld's driver uses flash v1 API, so, it is not possible to add CYGPKG_DEVS_FLASH_ARM_LPC2XXX package for Uwe's target (phycore229x): C CYGHWR_IO_FLASH_DEVICE_LEGACY, "requires" constraint not satisfied: CYGHWR_IO_FLASH_DEVICE_LEGACY <= 1 user should remove then existing flash v1 packages: package -hardware CYGPKG_DEVS_FLASH_AMD_AM29XXXXX current ; package -hardware CYGPKG_DEVS_FLASH_PHYCORE229X current ; The olpc*2294 targets by default use flash v2 API, and we would add the CYGPKG_DEVS_FLASH_ARM_LPC2XXX package for those target templates, but, unfortunately, strata flash drivers are used there do implement CDL interface CYGHWR_IO_FLASH_BLOCK_LOCKING and the Hans driver does not, so, I got a compile error about undefined flash_{un,}lock_block(). Workaround is either to remove the strata parts package -hardware CYGPKG_DEVS_FLASH_STRATA_V2 current ; package -hardware CYGPKG_DEVS_FLASH_ARM_OLPCX2294_V2 current ; or add "fake" implementations to the Hans driver: int flash_lock_block() { return FLASH_ERR_OK; } int flash_unlock_block() { return FLASH_ERR_OK; } NOTE: in fact, a few writes to internal lpc2xxx flash will "lock" that block (sector) and NXP IAP "prepare sector" command "unlocks" the block (sector), but, IMO, that is extra logic in that simple driver. Well, what can I say. I would avoid addition 'flash_arm_lpc2xxx' package by default for mentioned targets in ecos.db, but, this is my view only. Perhaps, I missed something and if Andrew is on the list, he can correct me on the "v1/v2 mix" issue. Regards, Sergei