[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson <ulfs@atmel.com>]

Grant Likely wrote:
> 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.
>

Now you are getting there...
This is a workable approach.


>>
>>> 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.

Best Regards,
Ulf Samuelsson
ulf at atmel.com
GSM:  +46 (706) 22 44 57
Tel:     +46  (8) 441 54 22
Fax:     +46 (8) 441 54 29
Mail: Box 2033  174 02 Sundbyberg
Visit: Kavalleriv?gen 24
          174 58 Sundbyberg'
Sweden