David Woodhouse <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] said:
> > 'm headed that way for most uses, but it isn't always the best way to
> > go. The biggest reason is that inspite of how simple I think it is to
> > create a map driver for the MTD stuff, there seems to be no
> > documentation on how to do it.
>
> Heh. Mea Culpa, I suppose.
>
> map_rom isn't a map driver - it's a 'chip driver'.
>
> The CFI modules, amd_flash.c, jedec.c, map_rom and map_ram are capable of
> driving particular types of memory chip if they're given functions to
> actually _access_ the chip. Those functions are provided by the map driver.
>
> For an example of a reasonably simple map driver which has to handle paging
> to access different regions of the chips to which it's providing access, see
> octagon-5066.c or vmax301.c.
>
> You just provide {read,write}{8,16,32} and copy_{from,to} functions for
> your board, then call the appropriate {cfi,jedec,map_r[ao]m}_probe function
> to probe the chips it contains. That'll return you an MTD device, which you
> either register whole with add_mtd_device() or with in partitions by making
> an array of struct mtd_partitions and using add_mtd_partitions().
Do you know the support status of the jedec driver? I wound up rewriting
it when I was working on the alpha. Partly because I suspected it for
bugs that were actually in my map driver, partly because of actual
bugs, and partly because it is so over compilicated.
In practice if something like the jedec is going to be provided it
probably should work like the cfi driver and pass control over to the
to the command set drivers. I don't think AMD and Intel actually
changed their command sets when moving to cfi. At least nothing
beyond extending them.
Eric
