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
Quoted 3 lines · Rui Sousa
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,
Quoted 7 lines · Rui Sousa
Quoted 3 lines
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.
Quoted 6 lines
And it would be nice to have just one
addr2info implementation, right Tolunay? ;-)Best regards,
ladis
Rui
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 3 lines · Rui Sousa
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
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de What is tolerance? -- it is the consequence of humanity. We are all formed of frailty and error; let us pardon reciprocally each other's folly -- that is the first law of nature. - Voltaire
Quoted 6 lines · Wolfgang Denk
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 3 lines · Rui Sousa
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).
Quoted 7 lines
Quoted 3 lines
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.
Signature · 2 lines
Hardware, n.:
The parts of a computer system that can be kicked.On Wednesday 23 May 2007 16:27, Andrew Dyer wrote:
Hi Andrew,
Quoted 7 lines · Wolfgang Denk
Quoted 6 lines
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 3 lines · Rui Sousa
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).
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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.
Quoted 3 lines
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
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 4 lines
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
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de An Elephant is a mouse with an Operating System. - Knuth
Quoted 4 lines · In message <[email protected]> you…
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
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "Stupidity, like virtue, is its own reward" - William E. Davidsen
Quoted 6 lines · In message <[email protected]> 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.
Quoted 1 line
Is someone else already working on a solution?
Not that I know of.
Quoted 1 line
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.
Quoted 1 line
Unfortunately this only takes care of writting operations. Support for read
That's the main problem.
Quoted 2 lines
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
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Another megabytes the dust.
Quoted 12 lines · Wolfgang Denk
Quoted 5 lines · In message <[email protected]> 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.
Quoted 1 line
Is someone else already working on a solution?
Quoted 7 lines
Not that I know of.
Quoted 1 line
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.
Quoted 4 lines
Quoted 2 lines
Unfortunately this only takes care of writting operations. Support for read
That's the main problem.
Yes. I know :-(
Quoted 5 lines
Quoted 2 lines
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.
Quoted 2 lines
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).
Quoted 3 lines
Best regards,
Wolfgang Denk
Thanks for the feedback,
Rui
PATCH 1/1 Complex MAPPING support on CFI driver
In reply to Rui SousaOn Wednesday 23 May 2007 12:58, Rui Sousa wrote:
...
Quoted 7 lines
My plan was:
1. Add a newCFG_FLASH_COMPLEX_MAPPINGoption to U-boot.
2. Create map structure to contain functions pointers to flash read/write functions.
3. Modifyflash_info_tstructure and add a pointer to map structure (ifCFG_FLASH_COMPLEX_MAPPINGis defined).
4. Add genericmap_read(),map_write()functions to CFI driver.
Quoted 8 lines
5. Modify CFI driver to access flash using map_read()/map_write() functions. 6. If
CFG_FLASH_COMPLEX_MAPPINGis not defined the map_read()/map_write() are simple inline functions that access memory directly.
7. IfCFG_FLASH_COMPLEX_MAPPINGis defined it's up to the board specific code to initialize the map structure pointer inflash_info_tand 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfi.patch
Type: text/x-diff
Size: 14470 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070523/a9815ce0/attachment.patch