Re: flash_olpcx2294_v2 package

[Sergei Gavrikov <sg at belvok dot com>]

Sergei Gavrikov wrote:
> Andrew Lunn writes:
> > On Sun, Nov 30, 2008 at 02:49:43PM +0200, Sergei Gavrikov wrote:
> > > Sergei Gavrikov wrote:
> > > > Hello
> > > > 
> > > > This is flash v2 driver for Olimex LPC-X2294 boards on top of strata_v2
> > > > flash driver. Tested on Olimex LPC-H2294 board. Redboot's FIS works fine
> > > > with the driver.
> > > > 
> > > > SYNOPSYS
> > > > 
> > > > 	ecosconfig remove flash_olpcx2294
> > > > 	ecosconfig add strata_v2 flash_olpcx2294_v2 flash
> > > > 
> > > > RFC: I described and the bottom boot blocks in the driver. What is a
> > > > practic, to hide or show it? It seemed for me what I could describe
> > > > flash geometry and as 64 x 0x10000.
> > > 
> > > I forgot ask about the second commentary. To compile v2 flash driver
> > > it's need to define CYGARC_UNCACHED_ADDRESS macro. I put that in the
> > > targets plf_io.h, but, it seems, that macro can be placed in lpc2xxx
> > > variant, but, where to place the macro? I see 2 places: either var's
> > > hal_cache.h or var_io.h. What will be the best a place? What is your
> > > opinion?
> > 
> > packages/hal$ find . -name "*.h" | xargs grep -l CYGARC_UNCACHED_ADDRESS
> 
> I'm sorry. I told badly about. Find? I did it :-) The main part of the
> question was, variant or target io.h?  It seemed for me that do tweak of
> every plf_io.h is not good idea (perhaps it is a wrong guess). 
> 
> I thought, if I will place the lines the below in
> lpc2xxx/var/currunt/include/var_io.h
> 
> #define CYGARC_CACHED_ADDRESS(x)                       (x)
> #define CYGARC_UNCACHED_ADDRESS(x)                     (x)
> #define CYGARC_PHYSICAL_ADDRESS(x)                     (x)
> #define CYGARC_VIRTUAL_ADDRESS(x)                      (x)
> 
> Does a chance exist to break something?

..Hm, and this morning it seemed for me that the best place would be
var_arch.h. lpc2xxx's var_io.h has a lot of defines and those in mainly
are I/O macros. IMHO, memory access is something another, isn't it? If
my morning opinion is right, a patch is provided.

Sergei

Index: hal/arm/lpc2xxx/var/current/ChangeLog
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/arm/lpc2xxx/var/current/ChangeLog,v
retrieving revision 1.9
diff -u -5 -r1.9 ChangeLog
--- hal/arm/lpc2xxx/var/current/ChangeLog	22 Jul 2008 18:52:16 -0000	1.9
+++ hal/arm/lpc2xxx/var/current/ChangeLog	2 Dec 2008 07:21:36 -0000
@@ -1,5 +1,9 @@
+2008-12-02  Sergei Gavrikov  <sergei.gavrikov@gmail.com>
+
+	* include/var_arch.h: Memory access macros added.
+
 2008-07-21  Uwe Kindler <uwe_kindler@web.de>
 
 	* cdl/hal_arm_lpc2xxx.cdl: Added option
 	CYGHWR_HAL_ARM_LPC2XXX_VARIANT_VERSION to identify the variant version 
 	because some on-chip peripherals changed slightly in newer veriants.
Index: hal/arm/lpc2xxx/var/current/include/var_arch.h
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/arm/lpc2xxx/var/current/include/var_arch.h,v
retrieving revision 1.2
diff -u -5 -r1.2 var_arch.h
--- hal/arm/lpc2xxx/var/current/include/var_arch.h	7 May 2006 18:36:18 -0000	1.2
+++ hal/arm/lpc2xxx/var/current/include/var_arch.h	2 Dec 2008 07:21:40 -0000
@@ -51,10 +51,19 @@
 //
 //=============================================================================
 
 #include <pkgconf/hal.h>
 #include <cyg/hal/hal_io.h>
+
+//--------------------------------------------------------------------------
+// Memory access macros
+
+#define CYGARC_CACHED_ADDRESS(x)                       (x)
+#define CYGARC_UNCACHED_ADDRESS(x)                     (x)
+#define CYGARC_PHYSICAL_ADDRESS(x)                     (x)
+#define CYGARC_VIRTUAL_ADDRESS(x)                      (x)
+
 //--------------------------------------------------------------------------
 // Idle thread code.
 // This macro is called in the idle thread loop, and gives the HAL the
 // chance to insert code. Typical idle thread behaviour might be to halt the
 // processor. These implementations halt the system core clock.