[U-Boot-Users] Atmel DataFlash hooks.

Wolfgang Denk
2007-02-01T00:06:04Z

In message <1170285215.21572.20.camel@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.