Reply to post: Too many moving parts

Too many moving parts

To start, let me preface by saying I have worked in QA roles for the last 30 years for all of the above mentioned companies in some capacity, and still do today.

The reasons for SPI read/write access is that newer systems Don't have battery backed CMOS (it is used for the RTC). Instead, bios settings are stored in a mapped section of the firmware device (now known as the Intel/integrated Firmware Interface or IFWI), and contains uEFI bios, Management Engine (ME), firmware settings, boot order, secure boot keys, etc. Firmware updates will now update the ME along with FRU/SRU data (hardware specific settings for the ME), along with the bios. In some systems, the bios update is stored in a temporary location and flashed in by the ME on reboot.

As to the OS needing access to this, it really depends on the manufacturer's implementation. Windows has separate drivers for every brand of every device that has to be separately loaded to configure the OS. Linux uses a more generic approach, with some device configurations determined by the driver when it loads (hence the aforementioned CD firmware issue).

So, who to blame? Sadly, it really ends up being the vast majority of consumers, by driving demands for newer more powerful systems, and manufacturer's trying to meet the needs of the many. As also stated, no one manufacturer can fully test every possible scenario. When I worked in Intel's Processor Validation (1996-2004), one of our general managers told the press that even with the hundreds of thousands of test hours run on pre silicon and post silicon across a vast mix of system configurations, it is nearly impossible to retest more than ~20% of all possible combinations, and that was just the cpu. Ubuntu has it much harder, as they are tasked with trying to release a combination oftested code bases (think of all of the different programs that make up a distribution release) on a vast combination of old and new hardware, with different architectures, vendors, combinations, etc. The best any of us QA folks can do is rely on the wider picture of testing that goes on globally by other users, manufacturer's, and even competitors.