The specific case is code that is technical debt for *two* steppings (B and C2) of *one* instance of a CPU (P54C). There's no need to keep that around, especially since, as pointed out in the CL, it's causing trouble.
I +2'ed the CL based on this discussion.
On Wed, Oct 6, 2021 at 5:27 AM Peter Stuge peter@stuge.se wrote:
ron minnich wrote:
same applies to new software applied to antiques.
While you are correct for some software and some antiques I find this premise completely unacceptable. This attitude may be convenient for developers but it only further normalizes planned obsolecense. Not OK!
Software can make it a high priority to be compatible. Windows is a great example of that, and I'm sure that backwards compatibility (has) contributes significantly to its success.
Hardware is no different and can of course also make it a priority to be backwards compatible. If we consider the x86 instruction set in isolation then that's another great example.
I don't see this problem as lack of compatibility but more as lack of transparency, openness and/or collaboration - those are the ingredients for a general hardware initialization software without all the ridiculous fights that coreboot must endure to this day.
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org