Some of us are old enough to have developed firmware with 8080/8085 before BIOS was invented. When BOIS came along, it provided requirements for what to initialize in hardware. The lack of structure within BIOS code was perceived as a plus. We weren’t told how to develop a BIOS and, of course, we were developing in assembly language which abhors structure.
As hardware became more complex and the number of add-in cards grew, the BIOS became unmanageable. So UEFI (Universal Extensible Firmware Interface) came to the rescue. It provided for C development and structure. For a UEFI compliance badge, you had to conform to the UEFI requirements, and everyone was keen to get with the program. While UEFI was gaining traction, processor and chipset complexity was exploding, and firmware was also because it had to keep up with the growing hardware requirements of multi-core, multi-processor, etc. The debug effort to keep up with multi-core and multi-threaded software has grown at an exponential rate.
Multi-threaded software problems seem to be insidious and follow the 80/20 rule — you spend 80 percent of your time debugging 20 percent of the code. Management really doesn’t understand how the code can be in the “home stretch” of development, yet the project’s schedule is slipping from one day to the next. At this juncture, the quality and sophistication of your tools will either shine or not. It is critical to have the correct tools to take advantage of the processor’s on-die resources to unravel the mysteries of how the code is executing. The simple paradigm of setting a breakpoint, running the code until hitting the breakpoint, single stepping and between steps conducting code inspection won’t find these execution problems.
Trace is now a critical capability for debugging UEFI code. What you need is a suite of tools that integrates the simple paradigm with UEFI knowledge and trace. These tools must keep up with ever changing on-die capabilities to maximize the debug potential for the software developer. With the recent merger of ASSET and Arium, we have the tools to address this complex debug problem. For a deeper dive into using trace as an integrated element in debugging UEFI code, see our eBook:
