This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Supporting Paged Flash in eCos/RedBoot
- From: "Gary D. Thomas" <gary dot thomas at mind dot be>
- To: Ian Campbell <icampbell at arcom dot com>
- Cc: eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: 17 Feb 2003 10:44:50 -0700
- Subject: Re: [ECOS] Supporting Paged Flash in eCos/RedBoot
- References: <1045503372.23218.38.camel@linuxdev.icampbell.arcom.cc>
On Mon, 2003-02-17 at 10:36, Ian Campbell wrote:
> Hi,
>
> I am porting eCos (RedBoot in particular) to a target board which uses
> pages flash. That is, the flash appears as a 16k window at 0xD0000 which
> you can point to different offsets in the physical flash device[0].
>
> My aim is to properly support the full flash on this target (and
> probably several more in the future), especially RedBoot fis and flash
> config support, and I would like to do it in a way which the eCos
> maintainers would be happy accepting a patch back into eCos -- since it
> is likely to touch a fair amount of code in the flash driver and redboot
> etc and I don't really want to maintain a huge out of tree patch if I
> can avoid it.
>
> Currently all flash access is done by directly reading and writing
> though pointers into the flash region and by using memcpy etc. My
> current thinking is to define a set of macros in the HAL,
> HAL_FLASH_{READ,WRITE}{8,16,32} and HAL_FLASH{COPY_FROM,COPY_TO} which
> would take an offset into the flash device (rather than a literal
> address which is what is currently used). For backward compatibility
> these macros could default back to directly accessing flash using direct
> pointer dereferences and memcpy on those platforms which have linear
> flash (that is, most of them). Once these macros were in place I would
> need to modify places which use flash to use them instead of directly
> accessing flash, this would include the flash drivers and the users
> (i.e. redboot).
>
> Other options might be to create a full blown 'flash' device layer, or
> even better porting the Linux MTD to eCos. I haven't looked into this,
> so I'm not entirely sure this is possible -- although JFFS2 has been
> ported so maybe it is.
>
> So, what do the maintainers think of this plan -- what sort of solution
> would be most acceptable to you?
>
> Cheers,
> Ian.
>
> [0] The boards are like this to support ROM-DOS, it's a royal pain. But
> I'm stuck with it on several of our products since there was no room
> left to make Linear vs. Paged flash an option.
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.
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.
--
.--------------------------------------------------------.
| 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