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