[U-Boot-Users] Atmel DataFlash hooks.

Ulf Samuelsson
2007-01-27T09:44:43Z

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