On Dec 16, 2006, at 12:18 PM, Pantelis Antoniou wrote:
As the guy that did the original implementation, my intent was to keep theDTB along with u-boot. I don't know where you get the idea that it's more "flexible" or "cleaner" tohave it on a different partition.
The problem is the dtb is still, and probably always be changing. My concern is even if you put the dtb into u-boot, the next version of kernel will probably not boot properly because the information needed will be different. So, to boot new kernels you need to then update u-boot, which is something no one is going to risk in a product.
We do update u-boot in field, no mishaps yet since 2001. Probably due to a very controlled update procedure.
All of these ideas are great when you are sitting in a lab with an evaluation board, you can update u-boot at will, or constantly change other items in the flash. In a real product, no one is going to risk a software update that could turn millions of working systems into doorstops. Field upgrades of existing Linux systems are already quite complicated, and the last thing we need are even more variables to cause problems or to track for recovery procedures.
These changes that add size and maintenance complexity to Linux aren't popular for embedded products. People are starting to look again at other, even proprietary solutions, due to overall cost and lifetime product risk. If we keep this up, we are going to have the best over-engineered and unused software around.
I don't get you point w.r.t subject at hand, do you or don't you support a OF tree compiled into u-boot?
Jocke