Re: [linuxdc-dev] VMU driver (Better maple)

[Paul M. <pm...@mv...>]

On Sat, Jan 26, 2002 at 05:15:40PM -0800, Fredrik Hubinette wrote:
> Well, I might be reading the whole thing wrong, but as I understand
> the code, it provides both char and block devices for each mtd device.
> However, the mtd map handler has a byte-based interface which seems
> like a lot of extra work to implement. This may however be incorrect.
> I will do some more reading, but maybe someone more knowledge can save
> me some trouble by pointing me in the right direction?
>=20
See my previous mail regarding character/block device access..

As far as sizes are concerned.. take a look at include/linux/mtd/map.h ..

        __u8 (*read8)(struct map_info *, unsigned long);
        __u16 (*read16)(struct map_info *, unsigned long);
	__u32 (*read32)(struct map_info *, unsigned long);

[snip]

        void (*write8)(struct map_info *, __u8, unsigned long);
        void (*write16)(struct map_info *, __u16, unsigned long);
        void (*write32)(struct map_info *, __u32, unsigned long);

So no .. in no way are you limited to 8-bit only access..

> If this is indeed a misunderstanding on my behalf, then I will definitely
> use the MTD subsystem since that is probably where vmus *should* be
> integrated.
>=20
Grab the latest MTD CVS if you really feel like it ..
http://linux-mtd.infradead.org .. and start reading source..

> I have looked at it. I may not understand it properly, but it seems
> very incomplete and based on reading/writing one byte at a time, which
> would be extremely slow. It was part of the reason I thought the mtdmap
> API was byte-based.
>=20
Again.. most proof of concepts aren't meant to be used for production
environments.. I could've sworn we had this same kind of discussion regardi=
ng
the stuff I was doing with maple..

The stuff is incomplete, but it doesn't take much to fix it.. really the
majority of work that needs to be done (especially if you want to deal with
your VMU the way it is) would be to look at writing a linux VMU fs
implementation. This should be feasible as a hack of fat .. but the superbl=
ock
won't reside at the beginning of the flash.. so that'll need some adjustmen=
t.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.