Re: [ECOS] Supporting Paged Flash in eCos/RedBoot

["Gary D. Thomas" <gary dot thomas at mind dot be>]

On Tue, 2003-02-18 at 03:21, Ian Campbell wrote:
> > Yes, I've already thought about this and have a plan (but no time to
> > implement it)
> > 
> > FLASH 'writing' is already done via a function.  All we really need
> > is a function to read data.
> > 
> > I'd much prefer if your FLASH driver provided a virtual address
> > range (not virtual in the sense of MMU, just a range 0..N).  Then
> > make the read/write/erase functions work on this virtual offset.
> > They already work like this for everything except reading FLASH
> > data.
> 
> 'My' flash driver is just the strataflash driver, but working on paged
> flash. So I should change the strataflash driver to work on offsets 0..N
> into flash rather than raw memory addresses within flash
> (FLASH_VIRT+0..N), and make sure that RedBoot etc use offsets into flash
> rather than literal addresses -- which I think it will if the
> get_flash_limits function returns 0..N, rather than FLASH_VIRT+(0..N).
> Then I add a flash_read function and make sure redboot (and eCos) use
> it. Sounds like a good plan.
> 
> Now in order to make the strataflash driver generic, I still need to
> work out what the best way for the driver to access the physical device
> is, in order to support linear and paged flash. The flash driver needs
> to either implement paging itself in order to access the physical
> device, or it needs to access the flash via the HAL which implements the
> abstraction of the the flash device. I would suggest going via the HAL
> using HAL_FLASH_READ/WRITE and friends. What do you think?
> 

Actually what I've thought about is that all of the information 
describing the FLASH would be kept in a structure.  There already
is such a beast (flash_info), but it's not being used very well.
Once the routines are updated to *pass* this around (rather than
assume the existence of a global variable), then we can make the
whole API more flexible.  The physical base address, or information
like which page is currently within the window, etc, can all be
stored within the structure.  RedBoot (or other users of the FLASH
drivers) would then just pass the structure and provide offsets.

A first step might be for you to extend the flash_info data structure
(under appropriate CDL control) for your needs.  Then add a routine
to read FLASH from a particular offset.  Make all of your offsets be
just that - "virtual".  Update RedBoot to not access the FLASH directly
but rather use the API and I think you'll be running.

> > The only other thing would be to identify the [very small] handful
> > of places within RedBoot (or eCos) that access the FLASH directly.
> > 
> > Adding this support would also make it possible for RedBoot to
> > use NAND flash without too much trouble.
> 
> At some point in the future I am going to have to try and get RedBoot to
> understand a board which has a 1M AMD boot flash and a 64M strataflash
> data partition. I suspect/hope this work will make that a whole lot
> easier as well... 
> 

Once there is a well thought out API (no more global variables), I think
we can handle such multiple FLASH systems.  note: this interests me as
well.


-- 
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss