Flash mapping questions

["Daly, Jeffrey" <jeffrey dot daly at intel dot com>]

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