[U-Boot-Users] Atmel DataFlash hooks.

[J. William Campbell <jwilliamcampbell@comcast.net>]

Wolfgang Denk wrote:
<snip>

>>>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 
>>    
>>
>
>  
>
Actually, I am still wrong. The flash code allows crossing flash chip 
boundaries of the same type. It does not support crossing flash type 
boundaries of different types unless the write_buff routine chosen for 
the target board does some additional de-multiplexing. Thus, if you use 
common/cfi_flash.c, all your flash needs to be cfi flash. Many of the 
flash routines in the board/ directory do support more than one type of 
flash. I just wanted to state this correctly.

>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.
>  
>
OK, that makes sense.

>  
>
>>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).
>  
>
OK, but there are also cases where you DO get an error. I assume it 
depends mostly on the cost of detecting the error and how 
important/probable the error condition may be.

>  
>
>>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.
>  
>
OK. I'm not sure I totally agree, as I think the parameters could easily 
be checked in addr2info in a manner that should not increase the 
footprint much if at all. I will submit a patch and see what you think.  
On the other hand you are quite right that nothing prevents the user 
from copying from non-existent memory to non-existent memory, so other 
address errors are no different.

>  
>
>>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
>  
>
Agreed and understood.

>  
>
>>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?
>
Well, my thought on this is that UNIX (and u-boot) also follows the 
Principle of Least Surprise, namely that like cases tend to work alike. 
If  I type cp.l 0x3 0x10 0x1 on a system that enforces longword (4 byte 
words) to be aligned, it will throw an exception and not work. I would 
therefore also expect cp.l 0x3 <some flash address> 0x1 to also throw an 
exception and not work for the same reason, yet it does not do so. It is 
executed as cp.b 0x3 <some flash address> 0x1, which is not what I asked 
for. Like I said, this is a nit and probably not important. I expect few 
people use cp.l to copy into flash anyway. It was just a difference 
between flash and ram that I noticed.

Best Regards,
Bill Campbell

> 
>
>Best regards,
>
>Wolfgang Denk
>
>  
>