* LPC2xxx internal flash driver @ 2011-02-22 12:13 John Dallaway 2011-02-22 13:03 ` Sergei Gavrikov 0 siblings, 1 reply; 4+ messages in thread From: John Dallaway @ 2011-02-22 12:13 UTC (permalink / raw) To: Sergei Gavrikov, eCos development list; +Cc: Hans Rosenfeld Hi Sergei 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)? FYI, the driver uses a buffer ending at 0x40004000 in internal SRAM. John Dallaway eCos maintainer http://www.dallaway.org.uk/john ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: LPC2xxx internal flash driver 2011-02-22 12:13 LPC2xxx internal flash driver John Dallaway @ 2011-02-22 13:03 ` Sergei Gavrikov 2011-02-22 19:19 ` Sergei Gavrikov 0 siblings, 1 reply; 4+ messages in thread From: Sergei Gavrikov @ 2011-02-22 13:03 UTC (permalink / raw) To: John Dallaway; +Cc: eCos development list I'm sorry for double post ( by mistake I rejected ecos-devel from CC ) John Dallaway wrote: > Hi Sergei > > 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)? > > FYI, the driver uses a buffer ending at 0x40004000 in internal SRAM. Hi John, 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. Sergei > John Dallaway > eCos maintainer > http://www.dallaway.org.uk/john ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: LPC2xxx internal flash driver 2011-02-22 13:03 ` Sergei Gavrikov @ 2011-02-22 19:19 ` Sergei Gavrikov 2011-02-23 8:50 ` John Dallaway 0 siblings, 1 reply; 4+ messages in thread From: Sergei Gavrikov @ 2011-02-22 19:19 UTC (permalink / raw) To: John Dallaway; +Cc: eCos development list > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: LPC2xxx internal flash driver 2011-02-22 19:19 ` Sergei Gavrikov @ 2011-02-23 8:50 ` John Dallaway 0 siblings, 0 replies; 4+ messages in thread From: John Dallaway @ 2011-02-23 8:50 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: eCos development list Hi Sergei Sergei Gavrikov wrote: > 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. Thank you for looking into this. It seems that a flash v2 version of the package with dummy block-locking functions would be desirable. Maybe someone in the eCos community will be interested in developing support for LPC2xxx internal flash along these lines. For avoidance of doubt, I will not add the existing package to any LPC2xxx target definitions. John Dallaway eCos maintainer http://www.dallaway.org.uk/john ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-02-23 8:50 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-02-22 12:13 LPC2xxx internal flash driver John Dallaway 2011-02-22 13:03 ` Sergei Gavrikov 2011-02-22 19:19 ` Sergei Gavrikov 2011-02-23 8:50 ` John Dallaway
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).