This is the mail archive of the ecos-devel@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: Flash driver for MSys DOC2000


Iztok Zupet wrote:
> 
> 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.

We do intend to do something about this, but as with everything right now
on the ex-Red Hat side, there's no longer any timetable.

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

I'm sure it does, certainly for RedBoot. And if you are talking about the
JFFS2 support for eCos here, that has been explicitly divorced from the
Linux MTD driver. 

But in any case, in the area we are interested in, there's no real
advantage of the MTD interface over the existing generic flash interface.
Unless you want to use the Linux DOC driver (which is fully GPL'd I should
point out).

Jifl
-- 
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


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