This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: drivers for LPC2xxx on-chip peripherals


On Thu, Jul 12, 2007 at 05:21:52PM +0200, Hans Rosenfeld wrote:
> The attached tarballs contains four new drivers to support the on-chip
> flash memory, RTC (wallclock), I2C and SPI units of the LPC2xxx
> controllers.
> 
Hello Hans,

This weekend I did tried 2 drivers: wallclock and lpc2xxx flash driver.
The built eCos tests/wallclock{,2}.cxx using your HW WALLCLOCK work as I
could expect. Thank you! I'm sorry but I have nor SPI HW neigher I2C HW
to test your I2C/SPI stuff.

> The flash driver is not much more than a wrapper around the IAP routine
> of the boot rom. Since I can't test on other devices, it is currently
> limited to those LPC2xxx variants using two erase block sizes (8k and
> 64k) and containing 256k of flash memory, of which the upper 8x8k are
> usable. This is enough for RedBoot to support FIS and fconfig.

It works too. I built and did play with RedBoot using that driver
(Olimex LPC-H2294 platform). But, it's pitty that has the reffered
limitation. I did build the ROMRAM RedBoot image for that target and I
saw that. It would be nice to have a ROMRAM RedBoot image placed in
external FLASH to upgrade any application reside on-chip LPC flash via
serial channel, wouldn't it? I dislike the dances with a ISP/RUN switch
or JTAG cable :-) More that, it seems, it isn't a deal for any finally
distributed hardware.

> It shouldn't be hard to extend the driver to fully support the simpler
> devices using all 8k blocks.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So, do you have a time to fix it? I did think about one addition, it
would be or something like flash_lpc2xxx_parts.inl source either some
expansion your flash_arm_lpc2xxx.c. As I known, there are 3 kinds of the
LPC2XXX flash geometry. I cut a bit of my code from my own programmer
for LPC2XXX parts (that had been written in Tcl): 

# Flash geometry (type 1): 15 x 8k
set ::flash_geometry1 [list {15 8192} [list]]

# Flash geometry (type 2): 8 x 8k, 2 x 64k, 8 x 8k
set ::flash_geometry2 [list {8 8192} {2 65536} {8 8192} [list]]

# Flash geometry (type 3): 8 x 4k, 14 x 32, 5 x 4k
set ::flash_geometry3 [list {8 4096} {14 32768} {5 4096} [list]]
# }}}

If your flash_hwr_init() will read LPC's firmware ID at once (using IAP
call), the driver will be known about used LPC2XXX CPU and therefore
about it's flash geometry (it's again in Tcl)

switch -exact -- $lpc_variants($id) {
    LPC2104 -
    LPC2105 -
    LPC2106 -
    LPC2114 -
    LPC2119 {
            set lpc(geometry) $flash_geometry1
        }
    LPC2124 -
    LPC2212 -
    LPC2214 -
    LPC2129 -
    LPC2194 -
    LPC2292 -
    LPC2294 {
            set lpc(geometry) $flash_geometry2
        }
    LPC2132 -
    LPC2134 -
    LPC2136 -
    LPC2138 {
            set lpc(geometry) $flash_geometry3
        }
    default {
            error_puts "unknow LPC2XXX variant"
            exit 1
        }
}

and this is the known LPC2XXX IDs:

array set ::lpc_variants [list]
foreach {variant id} {
    LPC2104 0xFFF0FF12
    LPC2105 0xFFF0FF22
    LPC2106 0xFFF0FF32
    LPC2114 0x0101FF12
    LPC2119 0x0201FF12
    LPC2124 0x0101FF13
    LPC2129 0x0201FF13
    LPC2194 0x0301FF13
    LPC2212 0x0401FF12
    LPC2214 0x0601FF13
    LPC2292 0x0401FF13
    LPC2294 0x0501FF13
    LPC2132 0x0002FF11
    LPC2134 0x0002FF12
    LPC2136 0x0002FF23
    LPC2138 0x0002FF25
} {
    set ::lpc_variants([expr {$id+0}]) $variant
}

What do you think about? Can you add same mapper in your flash lpc2xxx
driver code?  Do you have a time for this? It would give us a universal
control for any known LPC2XXX parts.

Thank you, kind regards,

	Sergei


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]