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


doh!  the calling of FLASH_MAP() might be confusing given what i've tried to explain, masking the block isn't really the right thing to do, i just stuck something in there as a placeholder since i don't care about the flash address....

> -----Original Message-----
> From: ecos-devel-owner@sources.redhat.com
> [mailto:ecos-devel-owner@sources.redhat.com]On Behalf Of Daly, Jeffrey
> Sent: Wednesday, January 14, 2004 4:43 PM
> To: Gary Thomas
> Cc: aarichar@cisco.com; ecos-devel@sources.redhat.com
> Subject: 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]