[coreboot] [PATCH] [3/7] Roda RK886EX support: SMSC LPC47N227
c-d.hailfinger.devel.2006 at gmx.net
Mon Jan 18 04:45:30 CET 2010
On 18.01.2010 00:57, ron minnich wrote:
> 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.
While this may be true for coreboot, this method caused huge pains in
flashrom because people didn't even read the code before they
copied/modified it. The worst cases were 100% copy-paste jobs where only
a search/replace of the function names had been done. Over time, some of
the copied files got modified and others stayed the same. A sizable
chunk of old drivers contradict the datasheets because people forgot to
actually adapt the driver to the chip after copying. Fortunately, a
detailed analysis of code vs. datasheets allowed us to overcome the
duplication and now ~80% of the old chip drivers can be killed thanks to
the improved infrastructure.
I do recognize that coreboot support for a chipset is way harder to
write and check than flashrom support for flash chips and agree that
"looks safe" changes to unified multi-chipset code in coreboot can be a
huge source of bugs.
What strikes me as odd is the fact that many chipset files in the
coreboot source tree just got a search/replace treatment from another
chipset, even if some feature is not even present on the new chipset.
Would a dedicated "template" chipset directory help people implementing
support for completely new chipsets?
Developer quote of the year:
"We are juggling too many chainsaws and flaming arrows and tigers."
More information about the coreboot