.png){kind=small}
Introduction
Again, thank everyone who contributed to this release, including the Dasharo community and the Dasharo Team. Your continuous efforts and collaboration have led to this exciting update. As previously announced, this release is also a Dasharo Entry Subscription Release. If you missed our recent blog post about v1.1.2, be sure to read it to catch up with the versioning strategy and what Dasharo Entry Subscription Release is.
After nearly three months, we are back with yet another update, bringing several improvements and fixes to enhance the user experience and system performance. Let’s delve into what’s new in this release.
Key Changes in the New Release
Since the last release we have been working mainly on new features and bug fixes. Here are the critical updates:
Added
Memory overclocking support with XMP profiles
Probably the most popular features request in community. Allows one to select a different (typically better performance-wise) memory profile called Extreme Memory Profile via firmware setup. These profiles are used as input parameters to the memory training algorithms to configure the memory controller to operate at higher clock speeds, which as a result increases memory performance. The configured memory speed is also displayed now on the main page of firmware setup.
Compatibility with Raptor Lake Refresh CPUs
In the meantime, between the last release and v1.1.3, Intel released the next generation Intel Core processors, which are the refreshed versions of 13th generation. Taking advantage of the opportunity, we have added the 14th generation compatibility in coreboot We also updated Management Engine and microcode versions to ensure seamless operation of new processors.
Selective Option ROM loading
OptionROMs have always been a security concern. OptionROMs are executable binaries embedded into the peripheral devices on PCI/PCI Express buses. In order to perform device-specific initialization, firmware/BIOS unconditionally loads and executes such OptionROM from the device. If such device is malicious, it can contain an OptionROm with malware for example. To limit the attack vector from OptionROMs, we have added a setup option to select which OptionROMs can be run: all, none or display devices only.
Serial Console Redirection option
For boards with serial port it can be used to access firmware using a serial connection. The option controls whether the console should be redirected to serial port or not. As the MSI boards have only TX signal routed, such console serves only debugging purposes (mainly Dasharo validation).
Power state after power fail option
Depending on an application, some machines may be used as a home servers, which should always be up. This option allows to set what should happen after power returns when power failure/shortage occurs. One may select to turn the machine power on or off or keep its previous state. Previously the machine was hardcoded to be powered off whenever the power is restored. The option offers flexibility of the machine usage.
Option for Resizable BARs enabling
Resizable BARs is a PCI Express device capability to decode its full resources in the system. For example, a discrete GPU card may advertise only 256MB of its memory resource, which during firmware operation is enough to get the display working. But modern cards have gigabytes of VRAM, so the resource restricted to 256MB may limit the performance of such card. With Resizable BARs the device can advertise bigger resources that can be allocated for the device, and for example a GPU with 4GB VRAM may advertise 512MB, 1GB, 2GB and 4GB resource. BIOS may select based on its policies which size to choose. We have implemented a runtime option to control whether Resizable BARs should be enabled and used during PCI enumeration or not. The maximum Resizable BAR configured for now is 128GB in Dasharo.
Also thanks to the community we have discovered bugs in upstream coreboot regarding the PCI Express Resizable BAR programming and the Intel ARC A750 PCI resource allocation when Resizable BAR is enabled.
ESP partition scanning in look for grubx64.efi or shimx64.efi or Windows bootmgr
Migrating a disk with a pre-installed OS may be troublesome. Per UEFI
specification it may not always be recognized as bootable, due to how boot
options are created (e.g. BOOTX64.EFI files are meant to be bootable files
on removable media, OSes often do not provide such). This is where ESP
scanning feature comes into play. Dasharo scans the EFI partitions on storage
devices and checks for known bootloaders, and if present, creates a boot
option for them. As a result whenever one plugs a disk with an pre-installed
OS, a boot option is automatically created for it.
Automatic fan control
Automatic fan control seems to be one of the features typically implemented from the beginning. A fan noise may drastically reduce the user experience and usability of the machine. However, our full PC build were shipped with very silent Noctua fans, which did not make a noise, even on full speed. The reason of the automatic fan control appearing so late is the lack of documentation. MSI boards use Nuvoton NCT6687D as a Super I/O and Hardware Monitor, which does not have public datasheets. Fortunately there are NCT6686D datasheets available, which were close enough to their successor to implement the open-source driver in coreboot. Another reason is the complexity of such driver. The datasheets have over 500 pages together and a mass amount of registers. Understanding how the chip should operate and how it should be programmed was very time-consuming and resulted in nearly 2800 lines of code added to coreboot. Now CPU fans should run quietly as long as the CPU temperature is not high.
One can now observe the Hardware Monitor readings using:
- nct6687d module on Linux
- MSI Center on Windows
Support for taking screenshots in the firmware
Taking screenshots may be very useful, especially in the firmware where there is no fancy GUI like in OS. Sometimes catching an unexpected event or a bug may require taking a screenshot. Doing it with a phone will result in bad quality. On the other hand capturing the content directly from framebuffer will result in 1 to 1 reflection of what is in the screen. Here is a short guide how to take screenshots.
Implementation is based on CrScreenshotDxe
RAM Disk support (EXPERIMENTAL)
OVMF in EDK2 supports RAM Disks for some time already. As the community expressed a need for RAM Disk support, we have added an experimental support for it in our Dasharo firmware. There is no documentation associated with the feature, so we looking forward for community contributions in that matter.
Changed
Switched to the Raptor Lake-S Client FSP; refer to SBOM section below
Intel released the new FSP for 13th generation Intel Core processors on 19th September. For even better compatibility with 14th generation processors we decided to switch to the new FSP on both Z690 and Z790 boards.
Get SMBIOS serial number and UUID from ROMHOLE region instead of CBFS
The unique SMBIOS data like serial numbers and UUID is stored in the MSI ROMHOLE region. The same region which was required for FlashBIOS feature to work. When using M-Flash or FlashBIOS button, the ROMHOLE region is copied/preserved during update. This ensures the unique data is not lost. We have added support in coreboot for reading serial numbers and UUIDs from the ROMHOLE. Previous support for Serial Number and UUID in CBFS has been disabled.
Rebased coreboot on 4.21 tag
Previous releases were based on coreboot 4.18. We have rebased the coreboot repository to 4.21 to ensure we are up to date with other developments and bug fixes for our platforms.
Reduced the amount of microcode blobs included in the build, due to redundancy
The reduced amount of microcode blobs does not always mean lesser CPU compatibility. Intel CPU microcode containers may support multiple CPUIDs. Such situation takes place with 12th, 13th and 14th generation of Intel processors. The files on Intel microcode repository designated for different generations of processors have the same SHA sum (i.e. they are identical), so the redundant blobs have been dropped to save flash space.
UEFI Secure Boot improvements
A small redesign of UEFI Secure Boot menu has been conducted during Qubes OS Summit 2023. The main goal was to improve the user experience of enabling the feature and managing the keys.
Additionally we have implemented a detection of booting with default
configuration (e.g. first boot after deployment or full update) and enroll
default UEFI Secure Boot keys in such case. Previously one had to enter Secure
Boot menu and select Reset Secure Boot keys option in order to enroll the
keys and unlock the Secure Boot enable option, which was not intuitive.
We have also added the new Microsoft and Windows 2023 UEFI Secure Boot certificates to our Dasharo images to ensure compatibility with the most recent bootloaders and shims.
Scope of reset to default hotkey to global in firmware setup
Previously the behavior of F9 key used to reset the settings was working only in a scope of a currently browsed form. It means that pressing F9 did not reset all settings, but only a handful, e.g. only Dasharo System Features (while Boot Timeout was unaffected). It has been changed to restore defaults globally.
Fixed
No audio playback via headset
It has been observed that sometimes the machines boot with to OS without audio output. We have added the missing audio device initialization bits to coreboot, which fixed the problem.
Auto Boot Time-out is reset to 0 when F9 is pressed
A small bug that caused the boot timeout value to be reset to 0 when F9 was pressed to restore defaults. The default value for boot timeout was not provided to the forms, that is why the incorrect value was restored.
Some RPL-S CPUs ( 0xB06F2 (RPL-S C0) or 0xB06F5 (RPL-S H0)) have a problem with booting on v1.1.2
This is one of the most serious problems of v1.1.2 release. Depending on the CPU model used, it could or could not work. The 13th generation CPUID recognition has been fixed, which resolved the issue.
Change boot order menu is confusing
A trivial bug where current boot order was not displayed on the 4K screens when trying to change the boot order. The solution was pretty unexpected, since it was related to the maximum string length. The list of boot option in the boot order is preallocated for 100 entries. The maximum length of each entry to be displayed is dependent on the screen resolution. With 4K resolution the total list length was over default allowed 10000000 characters (1MB long string). The limit has been increased to accommodate the list on 4K displays.
The setup menu does not issue a reset, resulting in saved but unapplied settings
Another improvement to firmware setup. This time we have added flags to options that require a reset in order to b applied properly. Now when some options are changed, firmware will refuse to continue booting and enforce a reset first.
P2SB BAR not properly reserved in ACPI
A bug detected by coreboot developer, where one of the chipset devices did not reserve its resources in ACPI. The resource has been properly added in coreboot.
Power LED not blinking during S3 sleep
Dasharo support S3 sleep for quite long time already on MSI boards. However, visually it was no different from a powered off state. All LEDs were going off during sleep, like on shutdown. It was impossible to determine whether the PC was sleeping or simply shut down, unless one remembered putting the machine to sleep. Now the power LED will be blinking when the machine is put to sleep.
PS/2 controller not enabled at first boot after flashing
Due to incorrect default value for PS/2 controller option, the PS/2 keyboard and mice did not work at first boot. Proper default has been applied to coreboot, which fixed the problem.
Incorrect C-states reported in ACPI unsupported by HW
Fixes a bug where Linux dmesg would say: [Firmware Bug] ACPI MWAIT C-state not supported by HW. The proper supported C-state is now reported in ACPI and the message is now gone.
Incorrect first timestamp format in ACPI FPDT
coreboot uses TimeStampCounter (TSC) to measure the coreboot’s boot performance. EDK2 UEFIPayload will use whatever timer library was compiled for the performance measurement libraries. This caused a mismatch in the timestamps between coreboot and EDK2 resulting in incorrect performance reported in ACPi FPDT table. The solution was to use the CPU timer library in EDK2 (which relies on TSC too).
Upstream
Raptor Lake-S CPU support
A part of the work for the previous v1.1.2 release was the upstream process of 13th generation Intel Core processors support. We have successfully merged the patch series enabling the CPU support in coreboot.
MSI PRO Z790-P board support
The v0.9.0 Dasharo release compatible with MSI PRO Z790-P is the first open-source firmware release running on that board. The support has also been upstreamed to official coreboot repository in this patch.
Conclusion
Each feature in the v1.1.3 release compatible with MSI PRO Z690-A is crafted with the user’s experience at the forefront, aiming to bring value by enhancing the reliability, security, and user-friendliness of your system. We invite you to explore these features and experience the tangible benefits they offer in optimizing your system’s performance and safeguarding its operations.
We encourage users to explore these new features and share feedback through GitHub issues, or Dasharo HCL reports via DTS.
We look forward to hearing your experiences with this new release and remain committed to fostering a collaborative and innovative environment. Thank you for being a part of the Dasharo Community.
