[ECOS] Problem with Flash drivers, RedBoot, and Flash high in the memory map

Gary Thomas gthomas@redhat.com
Tue Jan 15 07:21:00 GMT 2002

On Tue, 2002-01-15 at 08:09, Paul Fine wrote:
> I am porting the Flash drivers to the Motorola MPC8260 Voyager Advanced 
> Development Board.  This board puts the Flash in the last 8M of the 32 bit 
> memory map.  I have run into trouble getting the fis commands to work due 
> to the fact that many of the functions to manipulate the flash use as the 
> address of the end of the Flash
> end_addr = Flash_start_addr + length(Flash)
> In my case, the end_addr wraps around so the value is 0x0, so any compares 
> to see if my working address is greater than the end_addr always are true.
> I am now going through the code to find all the places where I need to 
> subtract 1 from my end_addr and change the compares from "<" to "<=".
> Has anyone else encountered this issue, or am I the first one to use Flash 
> at the high end of the memory map, or am I missing a switch, CDL option, or 
> something else obvious?

This would seem to be a reasonable approach to solving the wrap problem.
Probably best to take care in how you adjust things though.  I'd write:
  end_addr = Flash_start_addr + (length(Flash)-1)
to avoid any math/wrap problems.

> In a somewhat related issue, the Sharp Flash memory that is on the board 
> supports locking of the Flash blocks.  The way it works is that you can 
> individually lock a 256K block, but unlocking affects all 32 blocks.  In 
> order to use locking, I will implement the unlock function as a three step 
> process:
> 1)  Query Flash to determine which blocks are locked.
> 2)  If the block I want to unlock is locked, unlock all blocks (its the 
> only choice I have)
> 3)  Go back and relock the blocks that were originally locked.

Look at the other FLASH drivers.  I seem to recall having to have done
this sort of thing already [but that may have been in a previous life]

> Does the Intel implementation of this Flash standard implement individual 
> block unlocking?


More information about the Ecos-discuss mailing list