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


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]