[U-Boot-Users] Atmel DataFlash hooks.

J. William Campbell
2007-01-29T23:03:19Z

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