[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <007201c7455f$aebb2b20$01c4af0a at atmel.com> you wrote:
>
> But we dont all agree,
> I only see a bunch of non-data flash users that agree
> that dataflash users do not need to do memory commands.

How many dataflash *users* have voiced their opinion here?

> Memory commands are used to handle flash and DRAM.

... and other memory ranges that are mapped into the address sapce of
the processor.

> Please explain to me why the users should care about
> that you do not like the internal implementation?

Where are those users?

> A perfectly good implementation would let the memory commands
> (after translation of environment variables)
> send the parameters to a validation routine for each supported memory.

I disagree here. You are talking about storage devices,  not  memory.
Can  we  agree  that  "memory" shall be considered something which is
directly addressable in the processors address space? So ROM, RAM and
NOR flash are memory, but NAND flash, data flash, an EEPROM with  I2C
interface,  USB,  IDE,  etc.  are  *not* memory? Once we have such an
agreement, then you will understand what the  memory  commands  shall
support (memory), and what not (storage devices).

I am sorry that I did not catch this when dataflash support was added
initially, or when MMC support was added. My fault.

> The validation routine  would return an accept or reject.
> If accepted, then for you would call a probe routine
> for any memorty read, which would return a pointer to a valid block
> of memory containint minimum n valid bytes.

And how do you explain to a user, that the "cp" or "md"  command  can
read  valid  data  from  some magic address, while accessing the same
addresses in a JTAG debugger does not work at all?

Sorry, this *is* conceptually broken. I agree that this needs  to  be
cleaned up.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are two ways of constructing a software design. One way  is  to
make  it  so  simple that there are obviously no deficiencies and the
other is to make it so complicated that there are  no  obvious  defi-
ciencies.                             - Charles Anthony Richard Hoare