Ron Minnich wrote:
This has actually happened on coreboot. Older boards with older via NB or SB parts stopped working when those chips were modified with newer boards. It's very easy to break chip support with innocent-looking changes that "can't hurt". Chips are prone to change from rev to rev or part to part. Chips are not software.
Absolutely.
I think for chip support forking the support software may look bad from a "software engineering" point of view, but is at times the only practical option because (to be as polite as possible) the implementation of many of these chips is not that great.
We should also keep in mind that these problems occur because people make newer versions of their chips in a way comparable to how software designers write software.... If I remember, unix libraries libfoo.so.1 and libfoo.so.2 may have a different API while libfoo.so.1.0 and libfoo.so.1.1 should not change the API. Just that the API for them is features of the hardware and electronical attributes. In the cases of our closed source antagonists, the silicon vendor usually writes the silicon support code (aka initialization code/BIOS), too. Because of that they see no significant advantage in making their chips compatible on an initialization code level across generations. I think the hilarious part of this is that hardware designers want to make their hardware as generic as possible and that's what causes work on the firmware side. We shouldn't lose the twinkle in the eye if we call that "a hardware design issue"....
Stefan