This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: Flash driver for MSys DOC2000
- From: Iztok Zupet <iz at vsr dot si>
- To: Jonathan Larmour <jifl at jifvik dot org>
- Cc: ecos-devel at sources dot redhat dot com
- Date: Fri, 14 Jun 2002 13:46:27 +0200
- Subject: Re: Flash driver for MSys DOC2000
- Organization: VSR d.o.o.
- References: <200206051039.25349.iz@vsr.si> <3D09CA6E.7FAC2917@jifvik.org>
- Reply-to: iz at vsr dot si
On Friday 14 June 2002 12:50, Jonathan Larmour wrote:
> Iztok Zupet wrote:
> > Hello:
> >
> > Last Year I.ve written myself a DOC2000 flash driver for the PC target.
> > It works fine with RedBoot and the application. I partitioned the flash
> > disk into two partitions (one for RedBoot and one for application). The
> > system BIOS boots the RedBoot flash image form the first partition (disk
> > like boot).
> >
> > There's one crucial problem using such flash devices in Ecos. The Ecos
> > expects the device to be memory mapped for read access. So my driver
> > maintains a phisycal memory image of the flash disk ( on behalf of
> > application memory).
>
> A fair workaround. But the assumption of the "generic" (high level) flash
> driver is indeed where the problem lies.
>
> > Up to now, it seems to me there's only one solution, namely to use
> > virtual memory (and page fault exeptions), to bring the required flash
> > disk region into memory on memory read reqest. But unfortunately the
> > exeption handling for the PC target isn't done yet, the only exeption
> > handler there is GDB.
>
> That would be quite complex and wasteful - after all once a page is
> allocated it will stay allocated unless you have some complex VM system.
> And you'll have to keep enough memory reserved to cope with allocations.
>
> No, I'm sure the better answer is to modify the generic flash layer by
> adding code that makes it change behaviour according to a #define that may
> be provided by the low level driver.
>
> Jifl
Thought of higher level modifications. By extending the generic flash layer
there is a way of implementing DiskOnChip in eCos and RedBoot like a MTD
device.
Second way of doing it is implementing it like a block device. That's what I
did first. It works fine for apllications, but as far as I know, RedBoot
doesn't support any RW block device filesystem except read only ext2fs on
IDE.
First thing that I'll do will be to try to replace DiskOnChip BIOS with
RedBoot, since they say that is possible and that they've already done it for
GRUB. Next comes the MTD like driver that should "somehow" work with RedBoot
and JFFS2.
Anyhow I'm not sure if changes made to generic flash layer don't involve
changing the RedBoot or JFFS2?
iz