This is the mail archive of the ecos-devel@sources.redhat.com 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: Flash mapping questions


here's some sample snippets so you can get a feel for it....
the FLASH_MAP macro in a 'paged flash' implementation would take a flash address and set the appropriate 'page bits' in a register or something to make that particular addres show up in the flash window, essentially setting the upper address bits of the flash.  my implementation doesn't strictly need to do that since i've got a 32MB window and a 16MB flash device, but i do need the oddball endianness switching.

this is what's defined in flash_ixmb995e.h:
#define FLASH_MAP( _a_ ) (*IXP2000_SP_FRM = 1)
#define FLASH_UNMAP( _a_ ) (*IXP2000_SP_FRM = 0)

#define CYGNUM_FLASH_DEVICES    (1)
#define CYGNUM_FLASH_BASE_MASK  (0xFF000000u) // 16Mb

#define CYGNUM_FLASH_BASE       (0xC4000000u)
#define CYGNUM_FLASH_WIDTH      (8)
#define CYGNUM_FLASH_BLANK      (1)

etc, in addition to all the strata.h stuff.

and the diffs for flash_erase_block.c

--- intel/strata/current/src/flash_erase_block.c        Wed Jan 14 16:36:33 2004
+++ arm/ixmb995e/current/src/flash_erase_block.c        Mon Jan 12 13:41:50 2004
@@ -50,7 +50,7 @@
 //
 //==========================================================================

-#include "strata.h"
+#include "flash_ixmb995e.h"

 #include <pkgconf/hal.h>
 #include <cyg/hal/hal_arch.h>
@@ -65,6 +65,8 @@
     int len, block_len, erase_block_size;
     volatile flash_t *eb;

+    FLASH_MAP(CYGNUM_FLASH_BASE_MASK & (unsigned int)block);
+
     // Get base address and map addresses to virtual addresses
     ROM = FLASH_P2V(CYGNUM_FLASH_BASE_MASK & (unsigned int)block);
     eb = block = FLASH_P2V(block);
@@ -112,5 +114,7 @@
         if (len == 0) stat = 0;
     }

+    FLASH_UNMAP( CYGNUM_FLASH_BASE_MASK & (unsigned int)block );
+
     return stat;
 }

> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Wednesday, January 14, 2004 4:22 PM
> To: Daly, Jeffrey
> Cc: aarichar@cisco.com; ecos-devel@sources.redhat.com
> Subject: RE: Flash mapping questions
> 
> 
> 
> Daly, Jeffrey said:
> > nope, i started fresh from the 2.0 CVS sources circa 
> Oct-Nov 2003.  i've solved my problem by
> > copying all the strataflash support over into the 
> devs/flash/arm/ixmb995e/current directory
> > (ixmb995e is my platform) and modifying those sources to 
> handle the FLASH_MAP/UNMAP that i
> > proposed in my original mails and to add a flash_read_buf() 
> function to handle the problem with
> > the backwards endianness issue.  the only problem i ran 
> into was that defining
> > CYGSEM_IO_FLASH_READ_INDIRECT  conflicts with 
> CYGBLD_BUILD_REDBOOT_WITH_ZLIB.  removing the _ZLIB
> > from the configuration clears things up (not sure what that 
> option buys you anyways).
> >
> 
> Having "zlib" included let's you keep compressed images in 
> FIS.  It's also necessary
> if you want to download compressed images and have RedBoot 
> uncompress them on the fly.
> It's probably not too hard to get around this problem, I just 
> didn't have the time when
> I added the "indirect" support.
> 
> I'd be interested in seeing what you changed - maybe we can 
> see how to make this
> generic so it's not necessary to use such a big hammer to 
> solve the problem...
> 
> > the good news is that the port currently has most things 
> working: booting, PCI config, i82559 NIC,
> > flash, download and execute Linux without any kludgey hacks 
> in the main sources ala the ixdp2400
> > v1_24 code.  less important stuff like SRAM config will 
> follow after some cleanup, properly
> > separating architecture and platform specifics.
> >
> > my intent is to release the code back to eCos.
> >
> >> -----Original Message-----
> >> From: Aaron Richardson [mailto:aarichar@cisco.com]
> >> Sent: Wednesday, January 14, 2004 3:43 PM
> >> To: Daly, Jeffrey; ecos-devel@sources.redhat.com
> >> Subject: Re: Flash mapping questions
> >>
> >>
> >> Are you starting with the Intel redboot version taken from 1_24?
> >>
> >> It appears that Intel has changed at least their licensing at
> >> the following
> >> link from what I started from.
> >>
> >> http://developer.intel.com/design/network/swsup/bootmonitor.htm
> >>
> >> I started from the v1_24 redboot and was able to get roughly
> >> 80%-90% of the
> >> code ported so that it would work with ecos and would compile
> >> with the newer
> >> ecos/redboot.
> >>
> >> I do remember that the flash was a problem.  And I dont think
> >> I fixed it
> >> fully.  I have since been moved to another project and the
> >> ecos port remains
> >> shelved currently.  I might have time to figure out what I
> >> did to the flash
> >> if you havent fixed it yet.
> >>
> >> Are you planning on releasing your port back to ecos?
> >>
> >> Aaron
> >>
> >>
> >>
> >> On Wednesday 07 January 2004 03:34 pm, Daly, Jeffrey wrote:
> >> > Hi there, I'm in the process of implementing flash support for my
> >> > platform, Intel IXP2800 (XScale) and having some problems
> >> deciding how
> >> > to implement it correctly.  Basically my problem is that
> >> the IXP2800 has
> >> > 2 modes of accessing the flash address space....(We only
> >> support 8 bit
> >> > flash)  The first mode is '32 bit' mode, where 4 byte
> >> accesses are made
> >> > and byte packed for each fetch in order to return an ARM
> >> instruction.
> >> > This is always done LE, in other words, for a fetch of an
> >> instruction
> >> > from address 0x0, address 0x0,0x1,0x2,0x3 are fetched and
> >> are packed in
> >> > the order: 0x3:0x2:0x1:0x0 to go back to the NPU.  This 
> is fine for
> >> > running in both LE/BE mode, the code just needs to be
> >> programmed into
> >> > the flash correctly (may need byte swapping depending on 
> the mode of
> >> > programming, XScale or external programmer)  The second mode of
> >> > operation is what we call 'byte read mode' where only a 
> single byte
> >> > operation happens for a given access.  This is not a problem when
> >> > running code in LE mode (haven't done it yet, but I'm
> >> pretty confident)
> >> > However, as this is a networking platform and mostly 
> needs to access
> >> > network data BE, the default support is for BE.
> >> >
> >> >
> >> >
> >> > The issue is how the io/flash subsystem works.  The code is
> >> executing
> >> > out of flash (and thus in my system needs to be in '32 bit
> >> mode') until
> >> > the actual flash operations happen.  The actual flash
> >> manipulation code
> >> > is linked to run from RAM space.  Everything here is 
> cool too, the
> >> > problem is that the '8 bit' mode of flash in order to
> >> program the flash
> >> > writes to the correct physical address requested, but when
> >> we go back to
> >> > 32 bit mode, the endianness is always LE.  So for BE code,
> >> when we want
> >> > to say copy 4 bytes of flash from address 0x10000 to flash
> >> at address
> >> > 0x0, let's say the data is 0x00112233, the 0x00 data is
> >> written to flash
> >> > byte address 0x0, 0x11 written to 0x11, etc.....  But as
> >> stated above,
> >> > when we switch back to 32 bit mode (in order to continue to
> >> be able to
> >> > execute from ROM) reading flash address 0x0 (memcmp() for
> >> example) will
> >> > return: 0x33221100.
> >> >
> >> >
> >> >
> >> > My initial problem is that I want to use the stock strata
> >> flash code,
> >> > but I need to have a 'FLASH_MAP/FLASH_UNMAP' macro in the
> >> device code
> >> > for the flash operations to switch into and out of 8 bit
> >> read mode for
> >> > programming, etc.  I don't want to add platform specific
> >> hacks into the
> >> > generic device code, but I could make the argument that some
> >> > implementations of flash will have a smaller window into
> >> the flash space
> >> > then the actual device size and would require a 'paging' 
> register or
> >> > something to be able to get to all of flash (I don't know
> >> how prevalent
> >> > this case is, but I've had personal experience on at 
> least 4 systems
> >> > doing it this way in my career).  Having this in the
> >> generic code would
> >> > be helpful to me.  The other way is to basically copy the
> >> strata support
> >> > into my own platform flash support directory and add the macros.
> >> > Doesn't seem really worth it, especially from a maintenance
> >> standpoint.
> >> > The macros could by default define to nothing for nearly 
> everyone.
> >> >
> >> >
> >> >
> >> > The other problem related to this is that as said before, for BE
> >> > platform with this (admittedly oddball) mapping issue is
> >> that I probably
> >> > need to define the 'READ_INDIRECT' method for flash_read()
> >> (assuming I
> >> > stay with the generic strata code).  Is this just 
> implementing the
> >> > flash_read_buf() function in a file and adding it to the
> >> platform flash
> >> > support directory.
> >> >
> >> >
> >> >
> >> > Sorry for the long message ;-)
> >>
> >>
> >
> >
> 
> 
> 
> 


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