Hi,
I have two questions that I can't answer by my own. I tried to look at
FAQ and documentation on MTD website but found no answer.
First question is about size of flash. I have a Intel strataflash
whose size is 32MB but because of a buggy platform hardware I can't
access to the last 64KB of the flash. How can I make MTD module aware
of this new size. The restricted map size is initialized by my driver
but it doesn't seem to be used by MTD.
The second question is about the "cacheable" mapping field in map_info
structure. I looked at others drivers and this field seems to be
optional. Does this field, if set, improve flash access a lot ? Should
I set up a cacheable mapping ?
Thanks
--
Franck
On 11/22/05, Franck <[email protected]> wrote:
> Hi,
>
> I have two questions that I can't answer by my own. I tried to look at
> FAQ and documentation on MTD website but found no answer.
>
> First question is about size of flash. I have a Intel strataflash
> whose size is 32MB but because of a buggy platform hardware I can't
> access to the last 64KB of the flash. How can I make MTD module aware
> of this new size. The restricted map size is initialized by my driver
> but it doesn't seem to be used by MTD.
The chip driver will detect a 32MiB chip from the CFI probe. The map
size isn't really used by the chip driver, it's just needed to ensure
that the area is accessible. What you could try doing is adding a
cfi_fixup function that changes the CFI data read in to remove the
last 64KiB of the chip... not sure if that will work though.
> The second question is about the "cacheable" mapping field in map_info
> structure. I looked at others drivers and this field seems to be
> optional. Does this field, if set, improve flash access a lot ? Should
> I set up a cacheable mapping ?
Usually this isn't something you want to do especially with flash. If
a cache line is flushed back to the chip it's probably not going to
work. The cacheable mappings work for RAM based devices though.
josh
On Tue, 22 Nov 2005, Franck wrote:
> Hi,
>
> I have two questions that I can't answer by my own. I tried to look at
> FAQ and documentation on MTD website but found no answer.
Please consider using the MTD mailing list next time (you certainly read
about it on the MTD web site).
> First question is about size of flash. I have a Intel strataflash
> whose size is 32MB but because of a buggy platform hardware I can't
> access to the last 64KB of the flash. How can I make MTD module aware
> of this new size. The restricted map size is initialized by my driver
> but it doesn't seem to be used by MTD.
The easiest thing to do is to define MTD partitions, the last one being
the excluded flash area.
> The second question is about the "cacheable" mapping field in map_info
> structure. I looked at others drivers and this field seems to be
> optional.
It is.
> Does this field, if set, improve flash access a lot ?
Yes. It was tested on ARM only though. Some architectures like i386
for example might need special tricks to implement this.
> Should I set up a cacheable mapping ?
Consider the comment for the inval_cache method in
include/linux/mtd/map.h and look at lubbock-flash.c for example.
Nicolas
Hi.
2005/11/22, Nicolas Pitre <[email protected]>:
> Please consider using the MTD mailing list next time (you certainly read
> about it on the MTD web site).
>
I did....
> Yes. It was tested on ARM only though. Some architectures like i386
> for example might need special tricks to implement this.
>
do you know why ? What was the gain on ARM ?
Thanks
--
Franck
On Thu, 24 Nov 2005, Franck wrote:
> > Yes. It was tested on ARM only though. Some architectures like i386
> > for example might need special tricks to implement this.
> >
>
> do you know why ?
Apparently i386 might have issues having two virtual mappings for the
same physical address range. This can be worked around in the map
driver by relying on the knowledge of flash aliases on the bus.
> What was the gain on ARM ?
The ability to use burst transfers which are only activated with cached
memory, hence twice the read speed or more.
Nicolas