[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

ons 2007-01-31 klockan 22:55 +0100 skrev 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?

I know that I am the only one, but on the other hand
there are also no dataflash users which has said
that they are of another opinion.

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

Our customers.

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


Can you explain why you need to have the memory commands at all?
Then please continue to explain why, when you are doing exactly
the same manouvers, but use a serial flash, you do not need the
commands.

Why do you think it is not neccessary to compare the
written dataflash with the SDRAM?

Why do you think dataflash users will appreciate to have to copy
to SDRAM every time they do something?



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

The concept to map an address is not at all hard to explain.
Even so, I have never had the question in over 100 projects.


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

There is a very big difference in "cleaning" something up
and removing most of the functionality,because
You dont use it, and find it irritating to see it in the code.


My proposal will remove the need for ifdefs, and
will allow the writer of the driver to implement either
the proposed prefix, or the mapped address.




> 
> Best regards,
> 
> Wolfgang Denk
>