.png){kind=small}
Introduction
Firstly, kudos to everybody who contributed to this release (in random order): zirblazer, marmarek, collector-ynh, renehoj, micmarluc, the whole Dasharo community and the Dasharo Team.
New year and new exciting news. Dasharo Team has just released a new version of Dasharo firmware compatible with MSI PRO Z690-A. Last v1.1.0 version was released on 22th of November 2022, and after three months, the time has come for v1.1.1. Let’s see what’s new.
Why v1.1.1 and not v1.2.0?
Last time we bumped the minor version from v1.0.0 to v1.1.0, it was dictated by the coreboot base revision change, which could make a significant impact on the platform operation. Despite a huge changelog of the v1.1.0 version, the coreboot revision change was the main reason why the minor version of the release was updated. This time we did not change the coreboot base revision and introduced fixes and features to the existing base. Thus only the patch version has been updated from v1.1.0 to v1.1.1. We expect the next minor version change to v1.2.0 when the coreboot base revision is updated to contain Raptor Lake-S support in the near future.
Key changes in the new release
The past three months were mostly spent on debugging and resolving issues
reported by the community on Matrix and
GitHub. By the
way, if you haven’t joined our
Matrix Dasharo space yet, do it
quickly! There are over 100 people in the General channel, and still growing.
This is where all interesting stuff happens, like various technical discussions,
hardware setups, firmware configurations, and encountered issues.
Let’s have a look at the changelog.
Added
Early boot DMA protection menu option
Many people reported various issues when DMA protection was introduced in v1.1.0. Apparently, certain GPU cards contain broken OptionROMs which cause DMA errors and display initialization problems. Thus the firmware setup will now contain an option to enable/disable the DMA protection on-demand (with the default state being disabled to avoid problems with dGPUs). Additionally, an option to keep IOMMU enabled during OS control hand-off (actually during the UEFI Exit Boot Services) has been added. This setting may be especially interesting for people seeking the most secure configuration of the firmware. But keep in mind that Windows will not boot if you enable this option! Refer to our firmware setup documentation for more details.
ACPI PCI interrupt routing for CPU PCIe Root Ports
The CPU PCI Express root ports had no interrupt routing information reported in ACPI. Just a small fix.
OC Watchdog ACPI device as in MSI firmware
Original MSI firmware has been reporting an ACPI device describing the overclocking watchdog. This watchdog has been used by overclocking platforms since the 6th generation of Intel Core processors. The same ACPI device has been added to Dasharo to keep consistency. Possibly Windows overclocking tools may depend on it.
Changed
Updated SMMSTORE driver to upstream version in UEFI Payload
An update to the driver serving as a backend to write variables to the SPI flash
from UEFI Payload. The change was introduced due to problems with variable
updates on other Dasharo platforms. The advantage of the update is a cleaned-up
code with better quality. It also resulted in better reliability of efibootmgr
calls under QubesOS.
Improved visual comfort in the boot manager
One of the laptop users who could not distinguish the entries in the Boot Manager boot device selection window reported a minor visual improvement suggestion. Now the currently selected device is indicated by an arrow and highlighted with blue color.
Fixed
MSI PRO Z690-A WIFI DDR4 doesn’t initialize IGP on certain Processors models
This fix is a crucial one in this release. Many users reported non-working
on-board displays with different CPUs than those which were tested in 3mdeb lab.
All Alder Lake-S graphics devices should be initialized properly now and give
firmware output on the screen. If you are unable to boot the DTS to provide
HCL report,
then try using fwdump-docker image or
cbmem from the
following guides.
MSI PRO Z690-A WIFI DDR4 with two Video Cards (2x Radeon 5600XT) has issues related to MMIO resource allocation
A quite specific issue with board configuration overloaded with GPU cards in the community. As such configuration is uncommon, the debugging involved the issue reporter cooperation by flashing custom binaries and providing debug logs from Dasharo firmware. It happened that the memory requested by both of the cards was too big to fit into the 32-bit space. The fix for this one required reserving much more room for devices' memory in the 32-bit space by shifting some of the usable RAM from 32-bit space to 64-bit space. Such change let the firmware allocate all memory resources required by both GPUs.
Suspend doesn’t work in Qubes OS with v1.1.0
Another issue discovered by the community. One of Dasharo Team members' changes introduced a regression in the suspend/resume feature. All OSes were affected. Fix has been applied, and the suspend/resume should now work on all OSes. The tests have also been extended with multiple suspend/resume cycles to avoid such problems in the future.
Intel XTU on Windows reports “The platform does not support overclocking” on the MSI PRO Z690-A WIFI DDR4 with a K-series Processor
The issue was reported by community in the first days after v1.0.0 release. Surprisingly the Intel XTU utility reported that the platform does not support overclocking, despite the fact that all components had all the overclocking capabilities. The culprit was the OC lock bit being set by default in FSP, which prevented Intel XTU from modifying any settings from the Windows level, so it reported the platform as unsupported. The OC lock changes the initialization path inside FSP, so you may encounter unexpected CPU configuration changes compared to the previous release. Please do not hesitate to report them using GitHub issues system or providing Dasharo HCL report via DTS. One of such unexpected changes was an override of CPU turbo limits and causing the CPU frequency to be lower than the maximum default value (and so the performance was degraded).
SATA ports malfunction or Hot-Plug function disabled
A feature request from the community to enable SATA hot-plug functionality.
Platform sometimes automatically powers on after power off
Noticed by one of the Dasharo Team developers when dGPUs are plugged in. It happened that the dGPUs were sending ACPI SCI interrupts which are not currently handled by ACPI code, and it resulted in the instant wake up of the board when powering off. The SCI interrupts have been disabled on all PCI Express Root Ports until proper handling of SCI is implemented to fix the problem.
GPIO controller ACPI device yellow bang in Windows device manager
Despite previous attempts to fix the yellow bang of the GPIO controller in
Windows Device Manager, the issue persisted. The ACPI GPIO controller device had
all the definitions of GPIOs for Alder Lake-S, but apparently, Windows was
unable to properly initialize the GPIO because of the silent dependency on the
ACPI path of the device in the Windows GPIO driver. While Linux had no problems
with the previous ACPI path, but Windows could not properly load drivers in the
correct sequence. Thus the ACPI path had to be changed from \_SB.PCI0.GPIO to
\_SB.GPIO so that Windows will not depend on enumeration and initialization of
\_SB.PCI0 ACPI device. Similar issues were observed with the TPM2 device ACPI
path. If set wrong, the Windows 11 installer would not work. Now the yellow bang
in Device Manager should be gone for good.
Resource conflicts: Chipset’s P2SB PCI device incorrectly defined in coreboot
Issue observed during the 2x dGPU memory allocation problems and GPIO allocation problems. It occurred that coreboot did not reserve proper memory range for one of the chipset’s internal PCI devices resulting in resource conflicts and issues with the overall operation of conflicting devices. The issue could have been detected earlier if not the FSP which hides this internal device during the silicon initialization phase. The hidden device could not be detected by coreboot resource allocator, and thus the reserved memory for this device was not accounted for.
Reset button hanging the platform for up to 2 minutes due to watchdog bug
Noticed by the Dasharo Team developer and also reported by the Qubes OS community. Not exactly a regression, but a bug in the OC watchdog hardware which did not allow setting a small timeout to expire the watchdog after an unexpected reset (a reset button press, for example). Initially, the OC watchdog was designed to detect unstable overclocking configurations. When such a board unexpectedly reset, the BIOS was supposed to detect it and act per policy to restore safe configuration. Dasharo intended to use it in the same way, but the timeout not updating bug in the watchdog hardware caused the firmware to wait whole 2 minutes for watchdog expiration after the reset button press. Now Dasharo firmware does not detect unexpected resets and simply initializes the watchdog by programming the timeout. Tge watchdog expiration is not handled in any way.
Current state of Qubes OS R4.1.2 on MSI PRO Z690-A with Dasharo firmware
Here is a short demo of Qubes OS R4.1.2-rc1 running on the newest Dasharo v1.1.1
compatible with MSI PRO Z690-A. This Qubes OS instance has the kernel-latest
package installed to make suspend/resume working properly, because the Linux
kernel installed by default does not have the latest Intel graphics driver. In
the dmesg you can notice:
|
|
It means that when your are going out of suspend you display may stop working. To get it fixed, simply issue
|
|
Then reboot the device and boot with the latest kernel. You should then see a
kernel version of 6.x in the output of the uname -sr command, e.g.:
|
|
How to get the firmware update?
Please refer to the Firmware Update documentation and follow the instructions. Usage of automatic update via DTS is RECOMMENDED.
GPU compatibility in open-source firmware
Issues described above (and also a few issues resolved before, e.g. this one) showed us that GPU compatibility in open-source firmware is a serious problem.
So one of the Dasharo Team members, miczyg, equipped himself with two additional GPUs to test more hardware and detect other possible issues lurking out there. But these GPUs were selected with care and balance in mind. And there is no better balance in the world and in the universe than RGB! So the choice was:
- MSI Radeon RX 6500 XT MECH 2X OC 4GB GDDR6
- MSI GeForce RTX 3060 GAMING Z TRIO LHR 12GB GDDR6
- and the integrated Intel graphics for perfect balance :)
RGB as in red/green/blue, the three basic colors, ingredients that can create any other possible color; RGB as the pixel layout in graphics framebuffers; RGB altogether creates a white light, a sunlight; and sunlight means life…
Ok enough poetry… To prove that these are not empty words, here’s a photo of the mentioned setup:
WARNING: LOTS OF RAINBOWZZZZZ
The Nvidia RTX 3060 is sooo big that it covered the AMD Radeon RX 6500 XT, which is connected underneath. Sometimes bigger means beefier:
But size doesn’t matter, right? … Right?! :)
Summary
Open project tracking on GitHub
Dasharo v1.1.1 is definitely not the last release for the MSI PRO Z690-A platform. If you would like to track what is planned for the next release, please visit Dasharo GitHub. We are going to create an open project with milestones indicating the scope of new features and fixes for a given release. An example project in such fashion has already been prepared for Supermicro X11SSH board, which you can check out here.
Dasharo User Group Community Call (DUG) & Developers vPub
Join us for the upcoming Dasharo User Group Community Call (DUG) & Developers vPub on March 16th at 5 PM UTC! During the call, you’ll have the opportunity to connect with other community members, ask questions, and provide feedback on our current activities. You’ll also be the first to hear about exciting updates and new developments around MSI PRO Z690-A, what are the plans for next features, etc.
Interested in our services?
Unlock the full potential of your hardware and secure your firmware with the
experts at 3mdeb! If you’re looking to boost your product’s performance and
protect it from potential security threats, our team is here to help.
Schedule a call with us
or drop us an email at contact<at>3mdeb<dot>com to start unlocking the hidden
benefits of your hardware. And if you want to stay up-to-date on all things
firmware security and optimization, be sure to
sign up for our newsletter.
Don’t let your hardware hold you back, work with 3mdeb to achieve more!
