LPC2xxx internal flash driver

LPC2xxx internal flash driver

[John Dallaway]

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

Re: LPC2xxx internal flash driver

[Sergei Gavrikov]

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

Re: LPC2xxx internal flash driver

[Sergei Gavrikov]

> 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

Re: LPC2xxx internal flash driver

[John Dallaway]

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