[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <1170285215.21572.20.camel at elrond.sweden.atmel.com> you wrote:
>
> > 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?

To access memory.

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

Because these devices are not directly addressable in the processors
address space, i. e. they are not memory.

Everything is fine as long as the "md" command in U-Boot and the "md"
command at my BDI2000's telnet prompt show the same results  for  the
same  address ranges. When this is NOT the case, something is broken.
Here, it is the U-Boot implementation.

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

Nobody is going to take away the function from you. Just  the  inter-
face will have to cahcne, as the current implementation is broken.

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

But they are already doing this all the time, right?

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

For me this is a very important issue: when  U-Boto  and  a  hardware
debugger  start  behaving  differently,  I  consider  this  a serious
problem. U-Boot is a boot loader, and as such mostly a hardware debug
tool.

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

You can keep the function, but not  in  the  context  of  the  memory
commands.


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
Mistakes are often the stepping stones to utter failure.