This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
Re: flash_olpcx2294_v2 package
- From: Sergei Gavrikov <sg at belvok dot com>
- To: Andrew Lunn <andrew at lunn dot ch>
- Cc: eCos patches list <ecos-patches at ecos dot sourceware dot org>
- Date: Tue, 2 Dec 2008 09:26:24 +0200
- Subject: Re: flash_olpcx2294_v2 package
- References: <20081130122309.GA15263@ubuntu.local> <20081130124943.GA16517@ubuntu.local> <20081202061808.GL27015@lunn.ch> <20081202065654.GB8635@sg-ubuntu.local>
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.