On Mon, Mar 8, 2010 at 11:07 AM, Detlev Zundel <d...@denx.de> wrote: > We are a bit reluctant to accept changes here as this is shared code > with the 'dtc' device tree compiler[1].
Understandable. > Also when glancing over the code, it seems like there may be more places > where a corrupt fdt may backfire so this makes me also sceptic if this > single fix is a useful thing. I agree. It looks like there might be more than one case where a non null terminated string could cause problems. > Stepping back a little bit, I don't even know why we should trap such a > problem at all - after all while developing we have quite a few > possibilities to shoot ourselves in the foot. In a production system > such a thing should not happen and if it does, it will be caught by a > sensible infrastructure and e.g. a hardware watchdog. In our environment we have redundant FIT images in flash. This issue was caught by one of our testers who was purposely powering off the device during a firmware upgrade (in order to test the redundancy). The segfault is observed after rebooting to the remaining "good" image and invoking a command that calls fit_check_format(). The issue occurs after the flash has been erased, since in this case the erased flash is all 1's no terminating null character is ever found. My goal is to be able to determine (while in Linux) if one of the two firmware images in flash is corrupt or not. Although our platform supports a hardware watchdog, I am unclear how it could solve this particular problem? Granted, this is a fairly obscure case and it is not likely that users will be powering off hardware during firmware upgrades, but I wanted to at least describe the scenario to see what others might think. I would appreciate any suggestions for other methods of determining if a FIT image in flash is valid or not. > On the other hand if you do insist on your change, then pleas send git > patches as written in the documentation[2]. Sorry about that. I will submit any further patches as per the documentation. Regards, Jon Nalley _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
