Re: Flash driver for MSys DOC2000

[Iztok Zupet <iz at vsr dot si>]

On Friday 14 June 2002 14:02, Jonathan Larmour wrote:
> 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

As for MTD, I first thouht of extending the generic flash driver by somehow 
adding a read entry point, only that the driver should work with the DOC in 
MTD like manner.

There's one problem using DiskOnChip in not MTD like manner. The device must 
be always read from in 512 byte blocks in order that the ECC logic in there 
works.

I used the Linux DOC driver as the base for  my first version of block device 
driver (that was my only version until RedBoot), that's true.

iz