[U-Boot-Users] Atmel DataFlash hooks.
ulfs at atmel.com
Sat Jan 27 10:44:43 CET 2007
Grant Likely wrote:
> On 1/26/07, Ulf Samuelsson <ulfs at atmel.com> wrote:
>>>> No, but you started off by saying you specifically are focusing on
>>>> 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).
>> 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
> 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
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
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'
More information about the U-Boot