This is the mail archive of the ecos-discuss@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: Supporting Paged Flash in eCos/RedBoot


> 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.

OK -- I have started to modify all the flash_* functions to take a
'struct flash_info *' as their first parameter and to make all offsets
into unsigned longs, they are currently mostly void*. I will also add a
flash_read and make redboot use only the API. I'll let you know how I
get on.

> 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 'make all of your offsets be just that' bit is a part of what I am
doing above -- once I have completed that I will start to look into
supporting the paged stuff.

I'm toying with the idea a splitting the structure into the driver
specific bits (flash_drv_info?) and the device specific bits (currently
flash_info). 

For example the current page or physical base etc would go in
flash_drv_info and be provided by the HAL flash driver e.g.
devs/flash/arm/* while things like the number of blocks and their sizes
come from the type of flash device e.g. devs/flash/intel/strata and go
in the current flash_info. But -- we'll see how I get on, maybe I'm
wrong.

> > 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.

I'm a bit concerned that all flash drivers present a flash_query() etc,
but I think we can resolve that when it comes to it without any trouble.

Ian.

-- 
Ian Campbell
Design Engineer

Arcom Control Systems Ltd,			Direct: +44 (0)1223 403465
Clifton Road,					Phone:  +44 (0)1223 411 200
Cambridge CB1 7EA				E-Mail: icampbell@arcom.com
United Kingdom					Web:    http://www.arcom.com




________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]