receive the terminal output of my action to reflash the Master BIOS chip of the forenamed Motherboard, according to the advice in this output.
After acquiring a Gigabyte GA-F2A88XM-DS2P from mercadoactual.es, I equipped it with an AMD Athlon X4 845 Carrizo/Excavator and a pair of 4GB DDR3 1600MHz RAM (1.35V) bars together with an older GeForce NVIDIA 512MB graphics card of Chinese production. All did work very well over the Thursday evening, Friday and a weekend and I had the benefit of several kernel compilations for which I recommend this composition of Hardware. After a long session, wherein the OpenSuSE Leap 42.3 and the XUbuntu-17.10.1 installations were updated and I did experiment with the BIOS settings, I encountered the board going on in endless idle reboots after reaching the Gigabyte UEFI BIOS screen, in the next morning after switching the system on again, attempting to compile the x86-64 arch version of the kernel with enabled AVX2 instructions. For all fury and rage, the regular methods of hard resetting the BIOS to the factory defaults showed no effect. Short cutting the CMOS-Reset pin pair showed no effect and then removing the battery with short cutting the contacts without and under voltage, with running ventilator or switched off with power supply on, neither.
I passed the board to the local hardware supporter for examination and remedy if possible.
During the following days when I did notify the support of mercadoactual and had to support a stressing and time taking communication, I had to notice that an arbitrary administrative intervention on my publications in the github.com site did falsely edit some of the update comments, appearing behind changed sections of the contents. The communication with the mercadoactual stuff was awful and led me to the assumption that they are not authorized resellers who can merge the board into a technical support procedure of Gigabyte. Gigabyte's web support is from Google and Facebook protected and shows no local national settlement address.
I did get the board returned to my hands with the unaltered symptom of endless idle looping reboot at UEFI screen and the confirmation of the symptoms, two days before the conceded 14 days of customers devolution end. A call to the Gigabyte support in Hamburg/Germany ended after some authoritative advises, that all were already anticipated by my work prudence, with no further information helping to resolve the problem.
With the FLASHROM utility of free and open source software, using a CH341A USB to SPI programmer together with a clip to seize the pins of the master MX25L6406E chip, it was possible to reset the BIOS to a reusable state. Thereafter, the BIOS did not reboot itself in an endless idle loop and the Gigabyte Dual BIOS mechanism did detect a corrupt primary BIOS on the UEFI screen and prompted for to over program the primary from the backup BIOS. After answering yes and awaiting the copy progress to finish, the Motherboard did work alike from the first moments on. I did flash in the regular and for now only one version from Gigabyte support directly from the web pages of gigabyte.com showing the technical descriptions of the GA-F2A88XM-DS2P.
It remains unclear whether the FLASHROM utility does respect and handle protected areas sufficiently correct and whether the error messages do mean only the confirmation of a necessary erase to restore the BIOS by interrupting a skip over instead of erase to the sections that are zeroed or oned out.
Therefore it is not comprehensible that the second and backup BIOS differs from the first and used one and I do not know what happened if I had answered the question of the DualBIOS mechanism with NO, neither what will happen if the copied BIOS contains the same corrupt sections that led to symptoms described above.
It is necessary to forward the fore standing facts not only to the FLASHROM developers but also to Gigabyte support. Who will hook in to Facebook to roll out the necessary remedy? I don't want to.
The sold hardware in use is hard to change physically to a mechanism that fully complies with the MX25L6406E BIOS chip design's architectural intentions. The BIOS has to be revised and reprogrammed, shall be edited and should contain at least a feature to seek for a connected FAT32 USB memory stick containing an original BIOS binary file, After a certain number of boot attempts to a defined boot procedure level, that binary should be reflashed to the primary BIOS chip.
The technical supporter and I did encounter a restriction in the BIOS that does prohibit the use of older Radeon graphic cards. This should be alleviated.
Further, it is necessary to raise the evidence level by the quality and amount of documentation to the FLASHROM utility.
'And now they stand no more to cheat on others, but ask each other "How up!" '