RE: Flash mapping questions

["Daly, Jeffrey" <jeffrey.daly@intel.com>]

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