[U-Boot-Users] [RFC] Complex MAPPING support on CFI driver

[Rui Sousa]

On Wednesday 23 May 2007 15:51, Wolfgang Denk wrote:
> In message <200705231258.45889.rui.sousa at laposte.net> you wrote:
> > To support the flash one of our boards (no integrated in U-Boot) I need
> > to implement something similar to Linux MTD complex mappings option in
> > the CFI driver. In my case I have a NOR flash chip with an address line
> > connected to a GPIO pin. The GPIO pin needs to be set correctly at each
> > access to the flash.
>
> I guess you lose... You probably can tweak U-Boot into thinking these
> are different flash banks, but that's about all.
>
> > Is  someone else already working on a solution?
>
> Not that I know of.
>
> > Would such a feature have a chance of being integrated in U-boot?
>
> If a clean implementation was possible, yes, definitely. But I cannot
> see how this could be done. We don;t have a driver  level  to  access
> raw memory.

IMHO, I can come up with a clean implementation for the write part. Would that 
be accepted? I'm mainly trying to avoid supporting a big patch outside of the 
tree that will break at each re-sync with upstream releases.

> > Unfortunately this only takes care of writting operations. Support for
> > read
>
> That's the main problem.

Yes. I know :-(

> > would mean further extensive modifications (introduce some flash_read()
> > function and use it from cp, md, jffs2, ... commands).
>
> And here it all breaks down. You cannot do this without messing with
> lots of code.

I know. I just pointed it out for completeness. I didn't want to mislead 
anyone.

> The best you can probably do is provide a "bank switching" command to
> select one of your banks.

Yes for the md, cp, ... basic commands that's probably the best solution.

In our platform I have to support a jffs2 image that crosses the "bank 
boundary". I figured this can easily be supported with a local patch for 
get_fl_mem()/put_fl_mem() (making get_fl_mem_nor() more like 
get_fl_mem_nand()). The other memory related commands we will probably not 
support (for read operations).

> Best regards,
>
> Wolfgang Denk

Thanks for the feedback,
Rui