Today’s article unfortunately shows once again how wide the gap is between manufacturer claims, marketing, paid influencer culture, support, and reality. In such cases (when a long-standing member of the community contacts me and, exasperated, offers all documents and correspondences to warn against certain approaches in support) I ultimately don’t care who or what it is about, when the customer is so clearly in the right. It could have affected any manufacturer equally in this case, but silence helps no one.
Important preface – Be sure to read it first!
I want to make one thing clear in advance: this is NOT a rant against a specific product or Gigabyte in general today, but it shows the helplessness of two parties who could not find common ground in the end. The inquiring and helpful customer is almost driven to madness by a helpless German product support. But for a better understanding, I must mention beforehand that the customer, who paid nearly 600 euros for the product at that time, has more knowledge of the matter at hand than some employees at Gigabyte seem to have (but should actually have). Ok, the support cannot know this in advance, but they should have been able to notice it during the course of the conversation.
I also don’t want to discuss the built-in escalation levels of the support in general, which filter in advance which problem is ultimately still brought to the attention of the headquarters because many things can be clarified in advance using a checklist. This is correct and customary. However, a mistake like today’s definitely does not belong in this area but should be promptly brought to the attention of the UEFI developers and not just any FAE. And that is exactly where the support is needed, to recognize and act accordingly. The actual problem of today’s article is a communication chain that did not work.
Because even if the UEFI has a factory interface error, it is not a big problem to fix something like this and to help the customer (and their product). I discussed this with my acquaintances from the development departments of various motherboard manufacturers, and there was complete incomprehension everywhere as to how a manufacturer can cut itself off from the flow of information that it urgently needs through such ignorance at the first escalation levels. That should suffice for now, but I also wanted to put the correspondence in the right light.
AMI Aptio and Errors in UEFI Customization
For understanding and as a term explanation for outsiders: AMI Aptio refers to a family of UEFI firmware BIOS solutions for modern PC motherboards developed by the company AMI (American Megatrends Inc.). UEFI stands for “Unified Extensible Firmware Interface” and is the successor to the traditional BIOS (“Basic Input/Output System”) used in older PCs. AMI Aptio utilizes the UEFI specifications, which offer enhanced features and security attributes compared to the conventional BIOS. It also facilitates manufacturers to tailor their firmware according to their specific requirements. And that is precisely the problem we are dealing with today.
The so-called Human Interface Infrastructure (HII) provides standards for communication between humans and machines, in this case, e.g., with expansion cards for the PC or server. And it is precisely at this point that the Gigabyte X670E Aorus Master has a severe deficiency:
The board is unable to cleanly and fully display the HII interface of most non-Intel expansion cards in the UEFI, allowing them to be conveniently and problem-free configured directly in the UEFI (a security feature!). It is completely incomprehensible why such fundamental information was not only not prioritized but the customer was ignored and left standing in the rain with a now useless 600-euro brick at the end. Unfortunately, it also reflects a certain mentality of refusing to address problems to minimize one’s effort.
In the picture, we see the customer’s test field (from left to right) and what worked or mostly didn’t: Broadcom P225P (firmware up to date!), next to it the top row with the OEM i210, OEM x550 T2L, and Intel X710 T2L (no OEM, original from Intel) and the bottom row with Emulex OCE14102 (10GbE RJ45) (firmware up to date), Emulex OCE14xxx (10GbE SFP ), Emulex OCE11xxx (10GbE SFP ) (firmware up to date, very old, but with UEFI support and HII) as well as an LSI Megaraid (ACAGO/ Broadcom 9271 4i with supercapacitor).
For RAID controllers, this is important or interesting in order to be able to create RAID volumes directly in UEFI. With network cards, as in our case, it refers to configuring features such as nPar/SR-IOV or the manner in which the NIC reports itself to the OS (hardware features/device type) etc., if it is supported. Firmware updates are also possible (as in the case of an Emulex OCE14102 T2) directly in the UEFI, without having to create any boot drives or USB sticks with the EFI shell.
Partially, there are even features that only work or can be set in a UEFI environment. So, it does not help, for instance, to go into the ROM in legacy mode on an LSI Megaraid and activate the support for large address ranges there. This will be (logically) deactivated immediately, as this does not work under the legacy boot. Here, the absence of the HII interface is even detrimental to performance and indeed relevant to security!
It did work once before (not)
What gave the customer pause: they still own a Gigabyte X299 Aorus Master and the same error occurred initially on this board. The HII interface was then silently added back through a BIOS update sometime later, without explicitly appearing in the change logs. So, Gigabyte has encountered this problem before and is aware of it, yet the support team is not even capable of profitably categorizing such information for the company. A FAE should have known this.
293 Antworten
Kommentar
Lade neue Kommentare
Neuling
Veteran
Urgestein
Urgestein
Urgestein
Urgestein
1
1
Urgestein
1
Urgestein
Urgestein
Urgestein
Urgestein
Urgestein
Veteran
Neuling
Urgestein
Urgestein
Alle Kommentare lesen unter igor´sLAB Community →