RE: Flash mapping questions

RE: Flash mapping questions

[Daly, Jeffrey]

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).  

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 ;-)
> 
> 

RE: Flash mapping questions

[Gary Thomas]

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 ;-)
>>
>>
>
>

Re: Flash mapping questions

[Jonathan Larmour]

Gary Thomas wrote:
> [CYGSEM_IO_FLASH_READ_INDIRECT conflicts with CYGBLD_BUILD_REDBOOT_WITH_ZLIB ]
> 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.

[Old mail I know, I'm just going through my old stuff a bit]

This particular port aside, not supporting compressed FIS images is fair 
enough, but preventing compressed download should be easy to avoid, as per 
the attached patch. It's so easy I feel I'm missing something? Let me know 
if not and I'll commit :-).

Jifl

2004-02-11  Jonathan Larmour  <jifl@eCosCentric.com>

	* cdl/redboot.cdl: Bring CYGNUM_REDBOOT_LOAD_ZLIB_BUFFER under
	CYGBLD_BUILD_REDBOOT_WITH_ZLIB. Add CYGPRI_REDBOOT_ZLIB_FLASH to
	control whether decompression can be used with flash images.
	* src/flash.c: Use CYGPRI_REDBOOT_ZLIB_FLASH instead of
	CYGPKG_COMPRESS_ZLIB.
	* src/load.c: Use CYGBLD_BUILD_REDBOOT_WITH_ZLIB in place of
	CYGPKG_COMPRESS_ZLIB.
	* src/main.c: only set fis_zlib_common_buffer if
	CYGPRI_REDBOOT_ZLIB_FLASH.

Index: cdl/redboot.cdl
===================================================================
RCS file: /cvs/ecos/ecos/packages/redboot/current/cdl/redboot.cdl,v
retrieving revision 1.62
diff -u -5 -p -r1.62 redboot.cdl
--- cdl/redboot.cdl	4 Feb 2004 15:44:15 -0000	1.62
+++ cdl/redboot.cdl	11 Feb 2004 01:59:33 -0000
@@ -159,20 +159,41 @@ cdl_package CYGPKG_REDBOOT {
                supported by the platform.  If the value is greater than 1, 
then
                a platform specific function must provide information about the
                additional segments."
          }

-        cdl_option CYGBLD_BUILD_REDBOOT_WITH_ZLIB {
+        cdl_component CYGBLD_BUILD_REDBOOT_WITH_ZLIB {
              display       "Include support gzip/zlib decompression"
              active_if     CYGPKG_COMPRESS_ZLIB
-## FIXME!
-            requires      { !CYGSEM_IO_FLASH_READ_INDIRECT }
-## FIXME!
-            no_define
              default_value 1
              implements    CYGINT_COMPRESS_ZLIB_LOCAL_ALLOC
              compile       decompress.c
+
+            cdl_option CYGNUM_REDBOOT_LOAD_ZLIB_BUFFER {
+                display       "Size of zlib decompression buffer"
+                flavor        data
+                default_value 64
+                legal_values  5 to 256
+                description   "
+                    This is the size of the buffer filled with incoming data
+                    during load before calls are made to the decompressor
+                    function. For ethernet downloads this can be made bigger
+                    (at the cost of memory), but for serial downloads on slow
+                    processors it may be necessary to reduce the size to
+                    avoid serial overruns. zlib appears to bail out if 
less than
+                    five bytes are available initially so this is the 
minimum."
+            }
+
+            cdl_option CYGPRI_REDBOOT_ZLIB_FLASH {
+                 display       "Support compression of Flash images"
+                 active_if     CYGPKG_REDBOOT_FLASH
+                 active_if     !CYGSEM_IO_FLASH_READ_INDIRECT
+                 calculated    1
+                 description   "
+                        This CDL indicates whether flash images can
+                        be decompressed from gzip/zlib format into RAM."
+            }
          }

          cdl_option CYGBLD_BUILD_REDBOOT_WITH_XYZMODEM {
              display       "Include support for xyzModem downloads"
              doc           ref/download-command.html
@@ -501,26 +522,10 @@ cdl_package CYGPKG_REDBOOT {
                This option controls the timeout period before the
                command processing is considered 'idle'.  Making this
                number smaller will cause idle processing to take place
                more often, etc.  The default value of 10ms is a reasonable
                tradeoff between responsiveness and overhead."
-        }
-
-        cdl_option CYGNUM_REDBOOT_LOAD_ZLIB_BUFFER {
-            display       "Size of zlib decompression buffer"
-            active_if     CYGPKG_COMPRESS_ZLIB
-            flavor        data
-            default_value 64
-            legal_values  5 to 256
-            description   "
-                This is the size of the buffer filled with incoming data
-                during load before calls are made to the decompressor
-                function. For ethernet downloads this can be made bigger
-                (at the cost of memory), but for serial downloads on slow
-                processors it may be necessary to reduce the size to
-                avoid serial overruns. zlib appears to bail out if less than
-                five bytes are available initially so this is the minimum."
          }

          cdl_option CYGSEM_REDBOOT_VALIDATE_USER_RAM_LOADS {
              display       "Validate RAM addresses during load"
              flavor        bool
Index: src/flash.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/redboot/current/src/flash.c,v
retrieving revision 1.62
diff -u -5 -p -r1.62 flash.c
--- src/flash.c	24 Nov 2003 12:17:51 -0000	1.62
+++ src/flash.c	11 Feb 2004 01:59:34 -0000
@@ -96,11 +96,11 @@ local_cmd_entry("delete",
                  fis_delete,
                  FIS_cmds
      );

  static char fis_load_usage[] =
-#ifdef CYGPKG_COMPRESS_ZLIB
+#ifdef CYGPRI_REDBOOT_ZLIB_FLASH
                        "[-d] "
  #endif
                        "[-b <memory_load_address>] [-c] name";

  local_cmd_entry("load",
@@ -984,21 +984,21 @@ fis_load(int argc, char *argv[])
      struct option_info opts[3];
  #ifdef CYGPKG_REDBOOT_FIS_CRC_CHECK
      unsigned long cksum;
  #endif
      int num_options;
-#ifdef CYGPKG_COMPRESS_ZLIB
+#ifdef CYGPRI_REDBOOT_ZLIB_FLASH
      bool decompress = false;
  #endif
      void *err_addr;

      init_opts(&opts[0], 'b', true, OPTION_ARG_TYPE_NUM,
                (void **)&mem_addr, (bool *)&mem_addr_set, "memory [load] 
base address");
      init_opts(&opts[1], 'c', false, OPTION_ARG_TYPE_FLG,
                (void **)&show_cksum, (bool *)0, "display checksum");
      num_options = 2;
-#ifdef CYGPKG_COMPRESS_ZLIB
+#ifdef CYGPRI_REDBOOT_ZLIB_FLASH
      init_opts(&opts[num_options], 'd', false, OPTION_ARG_TYPE_FLG,
                (void **)&decompress, 0, "decompress");
      num_options++;
  #endif

@@ -1019,11 +1019,11 @@ fis_load(int argc, char *argv[])
      if (!valid_address((void *)mem_addr)) {
          diag_printf("Not a loadable image - try using -b ADDRESS option\n");
          return;
      }
  #endif
-#ifdef CYGPKG_COMPRESS_ZLIB
+#ifdef CYGPRI_REDBOOT_ZLIB_FLASH
      if (decompress) {
          int err;
          _pipe_t fis_load_pipe;
          _pipe_t* p = &fis_load_pipe;
          p->out_buf = (unsigned char*) mem_addr;
@@ -1328,11 +1328,11 @@ do_flash_init(void)
          flash_end = (void *)((CYG_ADDRESS)flash_end - 1);
          flash_get_block_info(&flash_block_size, &flash_num_blocks);
  #ifdef CYGOPT_REDBOOT_FIS
          fisdir_size = CYGNUM_REDBOOT_FIS_DIRECTORY_ENTRY_COUNT * 
CYGNUM_REDBOOT_FIS_DIRECTORY_ENTRY_SIZE;
          fisdir_size = ((fisdir_size + flash_block_size - 1) / 
flash_block_size) * flash_block_size;-# ifdef 
CYGOPT_REDBOOT_FIS_ZLIB_COMMON_BUFFER
+# if defined(CYGPRI_REDBOOT_ZLIB_FLASH) && 
defined(CYGOPT_REDBOOT_FIS_ZLIB_COMMON_BUFFER)
  	fis_work_block = fis_zlib_common_buffer;
  	if(CYGNUM_REDBOOT_FIS_ZLIB_COMMON_BUFFER_SIZE < fisdir_size) {
              diag_printf("FLASH: common buffer too small\n");
              return false;
  	}
Index: src/load.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/redboot/current/src/load.c,v
retrieving revision 1.37
diff -u -5 -p -r1.37 load.c
--- src/load.c	2 Dec 2003 14:40:19 -0000	1.37
+++ src/load.c	11 Feb 2004 01:59:34 -0000
@@ -72,11 +72,11 @@
  #include <net/http.h>
  #endif
  #endif

  static char usage[] = "[-r] [-v] "
-#ifdef CYGPKG_COMPRESS_ZLIB
+#ifdef CYGBLD_BUILD_REDBOOT_WITH_ZLIB
                        "[-d] "
  #endif
                        "[-h <host>] [-m <varies>] "
  #if CYGNUM_HAL_VIRTUAL_VECTOR_NUM_CHANNELS > 1
                        "[-c <channel_number>] "
@@ -106,11 +106,11 @@ struct {
      int (*fun)(char *, int len, int *err);
      unsigned char  buf[BUF_SIZE];
      unsigned char *bufp;
      int   avail, len, err;
      int   verbose, decompress, tick;
-#ifdef CYGPKG_COMPRESS_ZLIB
+#ifdef CYGBLD_BUILD_REDBOOT_WITH_ZLIB
      int (*raw_fun)(char *, int len, int *err);
      _pipe_t load_pipe;
      unsigned char _buffer[CYGNUM_REDBOOT_LOAD_ZLIB_BUFFER];
  #endif
  } getc_info;
@@ -154,11 +154,11 @@ redboot_getc(void)
      }
      getc_info.avail--;
      return *getc_info.bufp++;
  }

-#ifdef CYGPKG_COMPRESS_ZLIB
+#ifdef CYGBLD_BUILD_REDBOOT_WITH_ZLIB
  //
  // Called to fetch a new chunk of data and decompress it
  //
  static int
  _decompress_stream(char *buf, int len, int *err)
@@ -209,11 +209,11 @@ redboot_getc_init(connection_info_t *inf
      getc_info.avail = 0;
      getc_info.len = BUF_SIZE;
      getc_info.verbose = verbose;
      getc_info.decompress = decompress;
      getc_info.tick = 0;
-#ifdef CYGPKG_COMPRESS_ZLIB
+#ifdef CYGBLD_BUILD_REDBOOT_WITH_ZLIB
      if (decompress) {
          _pipe_t* p = &getc_info.load_pipe;
          p->out_buf = &getc_info.buf[0];
          p->out_size = 0;
          p->in_avail = 0;
@@ -245,11 +245,11 @@ redboot_getc_terminate(bool abort)

  static void
  redboot_getc_close(void)
  {
      (getc_info.io->close)(&getc_info.err);
-#ifdef CYGPKG_COMPRESS_ZLIB
+#ifdef CYGBLD_BUILD_REDBOOT_WITH_ZLIB
      if (getc_info.decompress) {
          _pipe_t* p = &getc_info.load_pipe;
          int err = getc_info.err;
          if (0 != err && p->msg) {
              diag_printf("decompression error: %s\n", p->msg);
@@ -568,11 +568,11 @@ load_srec_image(getc_t getc, unsigned lo
  //
  // 'load' CLI command processing
  //   -b - specify a load [base] address
  //   -m - specify an I/O stream/method
  //   -c - Alternate serial I/O channel
-#ifdef CYGPKG_COMPRESS_ZLIB
+#ifdef CYGBLD_BUILD_REDBOOT_WITH_ZLIB
  //   -d - Decompress data [packed via 'zlib']
  #endif
  //
  void
  do_load(int argc, char *argv[])
@@ -629,11 +629,11 @@ do_load(int argc, char *argv[])
  #ifdef CYGPKG_REDBOOT_NETWORKING
      init_opts(&opts[num_options], 'h', true, OPTION_ARG_TYPE_STR,
                (void **)&hostname, (bool *)&hostname_set, "host name or IP 
address");
      num_options++;
  #endif
-#ifdef CYGPKG_COMPRESS_ZLIB
+#ifdef CYGBLD_BUILD_REDBOOT_WITH_ZLIB
      init_opts(&opts[num_options], 'd', false, OPTION_ARG_TYPE_FLG,
                (void **)&decompress, 0, "decompress");
      num_options++;
  #endif

Index: src/main.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/redboot/current/src/main.c,v
retrieving revision 1.53
diff -u -5 -p -r1.53 main.c
--- src/main.c	11 Feb 2004 01:25:45 -0000	1.53
+++ src/main.c	11 Feb 2004 01:59:35 -0000
@@ -295,11 +295,11 @@ cyg_start(void)
      // Nothing has ever been loaded into memory
      entry_address = (unsigned long)NO_MEMORY;

      bist();

-#ifdef CYGOPT_REDBOOT_FIS_ZLIB_COMMON_BUFFER
+#if defined(CYGPRI_REDBOOT_ZLIB_FLASH) && 
defined(CYGOPT_REDBOOT_FIS_ZLIB_COMMON_BUFFER)
      fis_zlib_common_buffer =
      workspace_end -= CYGNUM_REDBOOT_FIS_ZLIB_COMMON_BUFFER_SIZE;
  #endif

  #ifdef CYGFUN_REDBOOT_BOOT_SCRIPT

-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
Visit us at Embedded World 2004, Nürnberg, Germany, 17-19 Feb, Stand 12-449
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: Flash mapping questions

[Gary Thomas]

On Tue, 2004-02-10 at 19:05, Jonathan Larmour wrote:
> Gary Thomas wrote:
> > [CYGSEM_IO_FLASH_READ_INDIRECT conflicts with CYGBLD_BUILD_REDBOOT_WITH_ZLIB ]
> > 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.
> 
> [Old mail I know, I'm just going through my old stuff a bit]
> 
> This particular port aside, not supporting compressed FIS images is fair 
> enough, but preventing compressed download should be easy to avoid, as per 
> the attached patch. It's so easy I feel I'm missing something? Let me know 
> if not and I'll commit :-).

I'm happy with this.  Perhaps someday, someone will find the time to 
allow compressed images in NAND FLASH as well.

Please commit.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates

RE: Flash mapping questions

[Daly, Jeffrey]

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 ;-)
> > >>
> > >>
> > >
> > >
> > 
> > 
> > 
> > 
> 

RE: Flash mapping questions

[Daly, Jeffrey]

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 ;-)
> >>
> >>
> >
> >
> 
> 
> 
> 

Re: Flash mapping questions

[Aaron Richardson]

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 ;-)

Flash mapping questions

[Daly, Jeffrey]

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 ;-)