[U-Boot-Users] Atmel DataFlash hooks.

Tolunay Orkun
2007-02-01T02:46:21Z

Wolfgang Denk wrote:
>> 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.
>

I guess I am OK with either implementation.

I think just because BDI is not capable of handling any address space
besides the processor address space should not mean we should so
restrictive of command line of U-Boot. I think address space tags that I
proposed yesterday could remove the confusion of what address the
command is referring to and it is easy to explain that a BDI could only
access untagged address space directly and everything else are
indirectly accessible memory. This would also enable us to use paged
memory mapped to a small window in processor address space seamlessly.

Anyway, I think either approach is valid and usable. There are pros and
cons with either scheme.

I think it might be easier to educate the user with one set of commands
as opposed to user having to decide which one of several <dev>
read/write commands should be applicable.

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

I see your point. However, with a hardware debugger you are not
currently able to mmc data directly and so you could not be able to
access mmc:0x00112233 either because "mmc:0x00112233" is not an address
that would be valid for BDI. So, I see no difference. It is really
mostly a matter of style rather than function.

Having the capability of u-boot memory commands to access different
address spaces is a convenience feature. When such feature is not
available the read/write commands will bring a chunk to ram and it will
be processed using memory commands again so first one would allow the
two operations combined but not a huge gain or loss either way.

Having said all that, I will concluded that either way is OK for me as
long as we maintain consistent architecture.

Tolunay