drivers for LPC2xxx on-chip peripherals

drivers for LPC2xxx on-chip peripherals

[Hans Rosenfeld]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

The attached tarballs contains four new drivers to support the on-chip
flash memory, RTC (wallclock), I2C and SPI units of the LPC2xxx
controllers.

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 shouldn't be hard to extend the driver to fully support the simpler
devices using all 8k blocks.


-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

[-- Attachment #2: lpc2xxx_drivers.diff --]
[-- Type: text/plain, Size: 3150 bytes --]

Index: packages/ChangeLog
===================================================================
RCS file: /cvs/ecos/ecos/packages/ChangeLog,v
retrieving revision 1.181
diff -u -w -r1.181 ChangeLog
--- packages/ChangeLog	3 Jul 2007 14:42:17 -0000	1.181
+++ packages/ChangeLog	12 Jul 2007 14:25:13 -0000
@@ -1,3 +1,8 @@
+2007-07-12  Hans Rosenfeld  <rosenfeld@grumpf.hope-2000.org>
+
+	* ecos.db: added drivers for LPC2xxx on-chip flash, RTC, I2C and
+	SPI units
+
 2007-07-02   uwe.kindler <uwe.kindler@cetoni.de>
 
 	* ecos.db CAN driver for LPC2xxx. Updated entry for loop
Index: packages/ecos.db
===================================================================
RCS file: /cvs/ecos/ecos/packages/ecos.db,v
retrieving revision 1.167
diff -u -w -r1.167 ecos.db
--- packages/ecos.db	3 Jul 2007 14:42:18 -0000	1.167
+++ packages/ecos.db	12 Jul 2007 14:25:21 -0000
@@ -197,6 +197,16 @@
            This package contains generic support for FLASH memory."
 }
 
+package CYGPKG_DEVS_FLASH_ARM_LPC2XXX {
+        alias           { "Support for the internal flash memory of LPC2xxx devices" flash_arm_lpc2xxx }
+        directory       devs/flash/arm/lpc2xxx
+        script          flash_arm_lpc2xxx.cdl
+        hardware
+        description     "
+           This package contains hardware support for the internal
+           flash memory of the LPC2xxx devices."
+}
+
 package CYGPKG_DEVS_FLASH_ARM_AAED2000 {
 	alias 		{ "Support for flash memory on Agilent AAED2000 board" flash_aaed2000 }
 	directory	devs/flash/arm/aaed2000
@@ -1973,6 +1983,16 @@
            also necessary to select an actual driver implementation."
 }
 
+package CYGPKG_DEVICES_WALLCLOCK_ARM_LPC2XXX {
+        alias           { "Wallclock driver for LPC2xxx RTC module" }
+        directory       devs/wallclock/arm/lpc2xxx
+        script          lpc2xxx_wallclock.cdl
+        hardware
+        description "
+           This package provides a wallclock driver implementation for the
+           LPC2xxx RTC module."
+}
+
 package CYGPKG_DEVICES_WALLCLOCK_SH3 {
 	alias		{ "Wallclock driver for SH3 RTC module" devices_wallclock_sh3 device_wallclock_sh3 }
 	directory	devs/wallclock/sh/sh3
@@ -2208,6 +2228,15 @@
     description   "Atmel AT91EB55 spi devices."
 }
 
+package CYGPKG_DEVS_SPI_ARM_LPC2XXX {
+    alias         { "LPC2xxx SPI driver" }
+    hardware
+    directory     devs/spi/arm/lpc2xxx
+    script        spi_lpc2xxx.cdl
+    description "This package provides a driver for the I2C unit of the LPC2xxx
+                 controller family."
+}
+
 package CYGPKG_IO_SPI {
         alias      { "Generic SPI support" spi io_spi spi_io }
         directory  io/spi
@@ -2231,6 +2260,15 @@
             support for bit-banged I2C buses."
 }
 
+package CYGPKG_DEVS_I2C_ARM_LPC2XXX {
+    alias           { "LPC2xxx I2C driver" }
+    hardware
+    directory       devs/i2c/arm/lpc2xxx
+    script          i2c_lpc2xxx.cdl
+    description "This package provides a driver for the I2C unit of the LPC2xxx
+                 controller family."
+}
+
 package CYGPKG_DEVS_I2C_MCF52xx {
 	alias		{ "MCF52xx I2C driver" devs_i2c_mcf52xx mcf52xx_i2c_driver }
 	hardware

[-- Attachment #3: lpc2xxx_drivers.tar --]
[-- Type: application/x-tar, Size: 92160 bytes --]

Re: drivers for LPC2xxx on-chip peripherals

[Sergei Gavrikov]

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

Re: drivers for LPC2xxx on-chip peripherals

[Hans Rosenfeld]

On Mon, Aug 13, 2007 at 12:31:39AM +0300, Sergei Gavrikov wrote:
> > It shouldn't be hard to extend the driver to fully support the simpler
> > devices using all 8k blocks.

Implementing this is really simple, I can do it but someone would have
to test it. This would also involve some checking of the exact LPC2xxx
variant, but I think I could do that at compile time since the HAL
#defines this.

> 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): 
> 
> [snipped]
>
> 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.

The real problem behind this is that the flash code does AFAIK not
directly support flash memories with more than one erase block size.
So for those devices I would have to either pretend that all blocks:
- use the larger block size, 4 blocks of 64k,
  that wouldn't be useful and would introduce further problems because
  the last 8k of flash are reserved on those LPCs I know, or
- use the smaller block size,
  this would cause a dependency on malloc() or would introduce a large
  static buffer for copying stuff around for every erase cycle, and
  this would also cause a lot of unnecessary wear through extra
  erase/write cycles.

I could probably implement the latter in a very simplistic way, not
copying stuff around when erasing, and just document the odd behaviour,
but that doesn't seem right to me. I'm also not sure that it would work
at all with the current flash implementation. It would be better to
rework the flash code to support multiple erase block sizes.


-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

Re: drivers for LPC2xxx on-chip peripherals

[Andrew Lunn]

> The real problem behind this is that the flash code does AFAIK not
> directly support flash memories with more than one erase block size.

Take a look at the flash_v2 branch in CVS. It supports different size
blocks. I hope to someday soon get this merged into the trunk.

        Andrew

Re: drivers for LPC2xxx on-chip peripherals

[Sergei Gavrikov]

On Mon, Aug 13, 2007 at 01:56:52AM +0200, Hans Rosenfeld wrote:
> The real problem behind this is that the flash code does AFAIK not
> directly support flash memories with more than one erase block size.
> So for those devices I would have to either pretend that all blocks:
> - use the larger block size, 4 blocks of 64k,
>   that wouldn't be useful and would introduce further problems because
>   the last 8k of flash are reserved on those LPCs I know, or
> - use the smaller block size,
>   this would cause a dependency on malloc() or would introduce a large
>   static buffer for copying stuff around for every erase cycle, and
>   this would also cause a lot of unnecessary wear through extra
>   erase/write cycles.
> 
> I could probably implement the latter in a very simplistic way, not
> copying stuff around when erasing, and just document the odd behaviour,
> but that doesn't seem right to me. I'm also not sure that it would work
> at all with the current flash implementation. It would be better to
> rework the flash code to support multiple erase block sizes.

I would prefer to have more fake oper. cycles than any malloc(64*1024).
But that's just my opinion. And I did think yesterday even about "virtual
sector" stuff in 4 or 8K to resolve this issue. I.e. to introduce a
virtual erasing == a writing of 0xFF there (I talk about IAP oper. "Copy
RAM to Flash"). So, we would have (at first, no having the 'flash_v2'
features) a _slow_ but the _linear_ flash model.

Andrew, Does such a simplification go a far outside the eCos flash
standards?

And another solution would be to put in devs/flash/arm/lpc2xxx a generic
stub (variant low-level driver) which uses NXP IAP calls to operate with
on-chip lpc2xxx flash and a platform related code will be to use those
weak calls.

Well, it seems to me, to have anything in devs/flash/arm/lpc2xxx is the
better than to have nothing :-)

	Sergei

Re: drivers for LPC2xxx on-chip peripherals

[Hans Rosenfeld]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

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.

I just noticed that I forgot to include a patch against
hal/arm/lpc2xxx/var/current/include/var_io.h to export the I2C bus.


-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

[-- Attachment #2: lpc2xxx_drivers_i2c_var_io.diff --]
[-- Type: text/plain, Size: 688 bytes --]

Index: var_io.h
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/arm/lpc2xxx/var/current/include/var_io.h,v
retrieving revision 1.2
diff -u -r1.2 var_io.h
--- var_io.h	7 May 2006 18:36:18 -0000	1.2
+++ var_io.h	20 Aug 2007 16:23:07 -0000
@@ -54,6 +54,11 @@
 #include <cyg/hal/plf_io.h>
 
 //=============================================================================
+// I2C bus
+#define HAL_I2C_EXPORTED_DEVICES \
+ extern cyg_i2c_bus cyg_i2c_lpc2xxx_bus;
+
+//=============================================================================
 // Watchdog (WD)
 
 #define CYGARC_HAL_LPC2XXX_REG_WD_BASE                   0xE0000000

Re: drivers for LPC2xxx on-chip peripherals

[Daniel Néri]

Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org> writes:

> I just noticed that I forgot to include a patch against
> hal/arm/lpc2xxx/var/current/include/var_io.h to export the I2C bus.

I don't agree with this one. HAL_I2C_EXPORTED_DEVICES belongs in the
platform HAL.


Regards,
-- 
Daniel Néri <daniel.neri@sigicom.se>
Sigicom AB, Stockholm, Sweden

Re: drivers for LPC2xxx on-chip peripherals

[Hans Rosenfeld]

On Tue, Aug 21, 2007 at 09:15:01AM +0200, Daniel Néri wrote:
> I don't agree with this one. HAL_I2C_EXPORTED_DEVICES belongs in the
> platform HAL.

I don't think so. AFAIK all LPC2xxx variants have the I2C unit. If a
platform really doesn't support it, the I2C package can still be left
out from the target.

After all, whats the point of having a variant HAL if the variant
specific stuff is replicated in all the platform HALs?


-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

Re: drivers for LPC2xxx on-chip peripherals

[Daniel Néri]

Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org> writes:

> I don't think so. AFAIK all LPC2xxx variants have the I2C unit. If a
> platform really doesn't support it, the I2C package can still be left
> out from the target.

Yes, but HAL_I2C_EXPORTED_DEVICES is used to export I2C device instance
names too. Also a platform might have multiple I2C buses/controllers.


Regards,
-- 
Daniel Néri <daniel.neri@sigicom.se>
Sigicom AB, Stockholm, Sweden