[U-Boot-Users] [RFC] Complex MAPPING support on CFI driver
Hi,
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.
What I wanted to know: Is someone else already working on a solution? Would such a feature have a chance of being integrated in U-boot?
My plan was: 1. Add a new CFG_FLASH_COMPLEX_MAPPING option to U-boot. 2. Create map structure to contain functions pointers to flash read/write functions. 3. Modify flash_info_t structure and add a pointer to map structure (if CFG_FLASH_COMPLEX_MAPPING is defined). 4. Add generic map_read(), map_write() functions to CFI driver. 5. Modify CFI driver to access flash using map_read()/map_write() functions. 6. If CFG_FLASH_COMPLEX_MAPPING is not defined the map_read()/map_write() are simple inline functions that access memory directly. 7. If CFG_FLASH_COMPLEX_MAPPING is defined it's up to the board specific code to initialize the map structure pointer in flash_info_t and the generic map_read()/map_write() functions will call board_map_read()/board_map_write() (through a function pointer).
Unfortunately this only takes care of writting operations. Support for read would mean further extensive modifications (introduce some flash_read() function and use it from cp, md, jffs2, ... commands).
Thanks, Rui
On Wed, May 23, 2007 at 12:58:45PM +0200, Rui Sousa wrote:
Unfortunately this only takes care of writting operations. Support for read would mean further extensive modifications (introduce some flash_read() function and use it from cp, md, jffs2, ... commands).
Posibly... if addr2info returns structure pointer in question it could also toggle the right gpio line. And it would be nice to have just one addr2info implementation, right Tolunay? ;-)
Best regards, ladis
On Wednesday 23 May 2007 13:48, Ladislav Michl wrote:
Hi Ladislav,
On Wed, May 23, 2007 at 12:58:45PM +0200, Rui Sousa wrote:
Unfortunately this only takes care of writting operations. Support for read would mean further extensive modifications (introduce some flash_read() function and use it from cp, md, jffs2, ... commands).
Posibly... if addr2info returns structure pointer in question it could also toggle the right gpio line.
It doesn't work. For example in do_mem_cp(), addr2info is only called for the destination address. We would need something like the dataflash handling code that also checks the src address.
Jffs2 code simply dereferences the address for NOR flash, addr2info is never called.
... and so on.
And it would be nice to have just one addr2info implementation, right Tolunay? ;-)
Best regards, ladis
Rui
In message 20070523114810.GA7092@michl.2n.cz you wrote:
On Wed, May 23, 2007 at 12:58:45PM +0200, Rui Sousa wrote:
Unfortunately this only takes care of writting operations. Support for read would mean further extensive modifications (introduce some flash_read() function and use it from cp, md, jffs2, ... commands).
Posibly... if addr2info returns structure pointer in question it could also toggle the right gpio line. And it would be nice to have just one addr2info implementation, right Tolunay? ;-)
There is no hook anywhere that would trigger when running a command like
md 0xFF000000 0x100000
which actually might cross "bank" boundaries that require tofggeling of I/O lines. addr2info() is nowhere used in such a szenario. [And it shall not be used, as "md" and friends are supposed to operate on plain memory, exactly as their counterparts in a JTAG debugger would do.]
Best regards,
Wolfgang Denk
On 5/23/07, Wolfgang Denk wd@denx.de wrote:
In message 20070523114810.GA7092@michl.2n.cz you wrote:
On Wed, May 23, 2007 at 12:58:45PM +0200, Rui Sousa wrote:
Unfortunately this only takes care of writting operations. Support for read would mean further extensive modifications (introduce some flash_read() function and use it from cp, md, jffs2, ... commands).
Posibly... if addr2info returns structure pointer in question it could also toggle the right gpio line. And it would be nice to have just one addr2info implementation, right Tolunay? ;-)
There is no hook anywhere that would trigger when running a command like
The OP didn't mention his architecture, but I thought using virtual memory support might allow him to trap on every access to his flash and do the appropriate fixup.
On Wednesday 23 May 2007 16:27, Andrew Dyer wrote:
Hi Andrew,
On 5/23/07, Wolfgang Denk wd@denx.de wrote:
In message 20070523114810.GA7092@michl.2n.cz you wrote:
On Wed, May 23, 2007 at 12:58:45PM +0200, Rui Sousa wrote:
Unfortunately this only takes care of writting operations. Support for read would mean further extensive modifications (introduce some flash_read() function and use it from cp, md, jffs2, ... commands).
Posibly... if addr2info returns structure pointer in question it could also toggle the right gpio line. And it would be nice to have just one addr2info implementation, right Tolunay? ;-)
There is no hook anywhere that would trigger when running a command like
The OP didn't mention his architecture,
It's based on ARM11core.
but I thought using virtual memory support might allow him to trap on every access to his flash and do the appropriate fixup.
Yes, but that seemed overly complex and too expensive (performance wise). We would need to add interrupt handling code and some extra MMU setup functions.
Rui
In message 200705231637.23352.rui.sousa@laposte.net you wrote:
but I thought using virtual memory support might allow him to trap on every access to his flash and do the appropriate fixup.
Yes, but that seemed overly complex and too expensive (performance wise). We would need to add interrupt handling code and some extra MMU setup functions.
Actually all this is easy to get - just boot Linux.
This is just a little boot old bootloader ;-)
Best regards,
Wolfgang Denk
In message c166aa9f0705230727s268a27f4i134147859fc8a171@mail.gmail.com you wrote:
The OP didn't mention his architecture, but I thought using virtual memory support might allow him to trap on every access to his flash and do the appropriate fixup.
Virtual Memory? Definitely not in U-Boot.
Best regards,
Wolfgang Denk
In message 200705231258.45889.rui.sousa@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.
Unfortunately this only takes care of writting operations. Support for read
That's the main problem.
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.
The best you can probably do is provide a "bank switching" command to select one of your banks.
Best regards,
Wolfgang Denk
On Wednesday 23 May 2007 15:51, Wolfgang Denk wrote:
In message 200705231258.45889.rui.sousa@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
On Wednesday 23 May 2007 12:58, Rui Sousa wrote: ...
My plan was:
- Add a new CFG_FLASH_COMPLEX_MAPPING option to U-boot.
- Create map structure to contain functions pointers to flash read/write
functions. 3. Modify flash_info_t structure and add a pointer to map structure (if CFG_FLASH_COMPLEX_MAPPING is defined). 4. Add generic map_read(), map_write() functions to CFI driver. 5. Modify CFI driver to access flash using map_read()/map_write() functions. 6. If CFG_FLASH_COMPLEX_MAPPING is not defined the map_read()/map_write() are simple inline functions that access memory directly. 7. If CFG_FLASH_COMPLEX_MAPPING is defined it's up to the board specific code to initialize the map structure pointer in flash_info_t and the generic map_read()/map_write() functions will call board_map_read()/board_map_write() (through a function pointer).
Basic implementation attached: 1. Only write support is included. 2. Board code is responsible for defining board_map_xxx() functions. 3. No impact is expected if CFG_FLASH_COMPLEX_MAPPINGS is undefined. 4. flash_info_t isn't modified and no function pointers are used, the board_map_xxx() should use the absolut address or information on the info structure to determine which flash chip is being accessed.
Thanks, Rui
participants (4)
-
Andrew Dyer -
Ladislav Michl -
Rui Sousa -
Wolfgang Denk