flash_olpcx2294_v2 package

Sergei Gavrikov sg@belvok.com
Tue Dec 2 07:25:00 GMT 2008


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lpc2xxx_var.diff
Type: text/x-diff
Size: 1985 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/ecos-patches/attachments/20081202/8988e4b1/attachment.bin>


More information about the Ecos-patches mailing list