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 <pe...@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-le...@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
