[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <45BE5CD4.3090306 at comcast.net> you wrote:
> 
> I understand your point. Similar conditions apply to memory-mapped 
> control and status registers. However, there is still an asymmetry 
> between mw and cp. mw feeds the data directly to the chip, no matter 
> what kind of chip/address is used (which is useful). cp "cooks" the data 
> sent to flash chips so that it will actually write into the chips. 
> (Granted it is cooked very rare, but still it is cooked)  This is also 
> desired behavior, but not the same behavior.

Correct. But "cp" is not a "m*" command, then :-)

> We agree here, I just was not very precise. The trick  is that if you 
> allow mapping an IDE disk as memory, you could copy from one part of the 

I don't want to do this. Not in a boot loader.

> operand of the cp command must be on the CPU memory bus) We also both 
> agree we don't want to do this as part of the cmd_mem.c interface!

I don't want to do this at all. I want to be able to read  and  write
from resp. to disk, that's all.

> >No - if flash regions are mapped contiguously, a "cp" should be  able
> >to cross device boundaries transparently.
>
> Actually, what I said above is wrong. The flash_write code DOES allow 
> crossing  flash type boundaries. What is not allowed in the flash_write 
> routine is starting in flash and ending in non-flash. This throws an 
> error. Starting in flash,  intervening ram, ending in flash would not 
> work properly. Holes in the memory map between flash regions also would 

You are right. But anybody who is crazy enough to come up with such a
memory map should fix his design before complaining that U-Boot  does
not support all possible pathologic cases.

> not work properly. This  may be defined as an error, but  you don't get 
> an error  message in these cases as near as I can tell. Rather, the code 

There are many other misconfigurations  that  result  in  non-working
systems  without useful error message (in most cases because the code
crashes long before it can send any messages at all).

> seems to do something untoward in the next flash bank. It would be 
> trivial to detect and throw an error for these cases, but the current 
> code does not.  Also, there are several places in the current code where 

As mentioned before: I tend to consider this as a design error  which
is not worth the code for runtime error checking.

> it is assumed that if the initial destination address is in ram, the 
> entire operation is in ram. This can be false if ram and flash are 
> contiguously mapped. IMNSHO this condition should either work or be an 
> error that is detected.

If you look close enough, you can find many problematic situations  -
eception vectors, malloc arena, stack, U-Boot code, data and BSS etc.
are  not  protected  in  RAM  - you can easily overwrite any of these
without any protection.

You can do a lot more mess when meddeling with PCI memory.

U-Boot does not attampt to prevent all possible kind of user errors.
It was designed to be small, powerful, and easy to port.

Here is one of my favorite quotes which fully applies to U-Boot, too:

"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn

> There is also a semantic question regarding the meaning of the size part 
> of the cp.X command when the destination operand is flash. If the 
> destination operand is in flash, the size of the operand for both the 
> source and destination addresses is not enforced. The size of access is 
> enforced if the destination is ram. This may be a bit of a nit, but I 

Sorry, I cannot parse this. Please explain.

> bring it up for completeness. cp.l commands that look like they for sure 
> should generate an alignment exception will not do so if the destination 
> is flash.

Why should they? 

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
A committee is a life form with six or more legs and no brain.
                              -- Lazarus Long, "Time Enough For Love"