On 1/26/07, Ulf Samuelsson ulfs@atmel.com wrote:
No, but you started off by saying you specifically are focusing on dataflash, and then you need to test on the primary target for the dataflash which is the AT91 series.
Then I apologies and ask for forgiveness. I want to see some of the crazy side cases removed from the generic routines (and replaced with generic hooks where appropriate).
Why? Have you done any cost benefit analysis to the rest of the community? What will the world gain by such a change?
Simpler code, easier to maintain code, easier to add new storage devices, easier to have boards with multiple different storage technologies, smaller u-boot binaries.
Let me flip the question around: Do you like the current implementation where each storage technology (MMC, memmapped flash, and DataFlash; see my reply to Wolfgang) has it's own set of hooks in each memory access command?
How about this: 1. start with *not* changing the mmi and u-boot continues to pretend that DataFlash and MMC devices are memmapped. I may not like it, but I understand your position on this. 2. add a common interface for non-RAM and non-memorymapped devices that provides a single interface for commands like cp, md, bootm, etc to find out if an address is 'special' and what routines it should call to access them. 3. First migrate memmapped flash devices to the new interface to prove it is workable. 4. Second migrate over either MMC or DataFlash devices; based on who is able to provide test support (this does *not* touch the low level code. It introduces a shim between the commands and the device routines) 5. Migrate the remaining hooks. At this point, all the command functions should only have a single hook for access non-memmapped, non-RAM devices. All commands should now work on all devices. ie. md command can access MMC devices, something it cannot do now.
Of course there is design work that needs to be done, but in this stages approach, the first patch will show how the common interface is designed.
I should have couched it more in those terms when I first brought it up.
From my point of view, dataflash is the main case, and
everything else is a side case.
I only see it as a side case due to the way it is implemented. Now that I've looked deeper into the other commands, the same argument goes for MMC devices. If the implementation changes to use a common interface for these similar devices then it's not a side case any longer in my mind.
I do not see any benefit in changing the MMI for dataflash. I rather see changes which will make dataflash more similar in use to std parallell flash. In my u-boot I can compare dataflash to SDRAM etc.
Fair enough
Cheers, g.