RE: Flash mapping questions

["Gary Thomas" <gary at mlbassoc dot com>]

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