[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/26/07, Ulf Samuelsson <ulfs at 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.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195