This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: Flash mapping questions
- From: Aaron Richardson <aarichar at cisco dot com>
- To: "Daly, Jeffrey" <jeffrey dot daly at intel dot com>, <ecos-devel at sources dot redhat dot com>
- Date: Wed, 14 Jan 2004 14:42:44 -0600
- Subject: Re: Flash mapping questions
- Organization: Cisco Systems Inc.
- References: <BF1FE1855350A0479097B3A0D2A80EE0F60C04@hdsmsx402.hd.intel.com>
- Reply-to: aarichar at cisco dot com
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 ;-)