[Z690] UEFI Setup Screen Enhancements

[Firminator]

A few suggestions:

Upper right side of the screen:

• Show if DDR4 or DDR5 RAM
• Show if SPD or XMP is used
• Show RAM SPD default manufacturer timings
• If XMP is used show RAM XMP timings
• show how many RAM slots are being used (4x 8192MB or 2x 16GB or similar)

Upper left side of screen:

• change from 'MS-7D25' to 'MSI Pro Z690A WIFI (MS-7D25)'
• add Intel CPU codename e.g. (Alder Lake) or (Raptor Lake)
• add date to Dasharo release version, e.g. v1.1.3 (2024-01-??)

Add the complete version history/Changelog with ISO 8601 dates (YYYY-MM-DD) into the Dasharo System Features menu or elsewhere where appropriate.

[Firminator]

Any comments? Further ideas or suggestions to these cosmetic changes?

[pietrushnic]

I see no issues with those suggestions. @miczyg1 ?

[miczyg1]

Upper right side of the screen

Front page has already too little space to fit more details.

Show if SPD or XMP is used

It is not straightforward to tell if XMP is used or not. It is pure request via variable set in other submenu.

All of these requests for memory information is a lot of work and parsing. XMP specification is not even public. It all sounds simple, but it is not. If anything it would be better to have a separate menu for memory information and details. Still it is probably days if not weeks worth of work.

change from 'MS-7D25' to 'MSI Pro Z690A WIFI (MS-7D25)'

It currently displays the SMBIOS type 1 Product name. It can be changed to display, e.g., type 2 Product name (for MSI, it would result in a string you request without the manufacturer, though). Different platforms may have different product names in type 1 and type 2. We change it here, then somebody else will complain that the strings are not to their liking... I am not sure about this change. because it is purely personal view what string should be displayed. Again, it may be included in a separate menu, where both type 1 and type 1 product name could be displayed at once.

add Intel CPU codename e.g. (Alder Lake) or (Raptor Lake)

This is too much. This information cannot be extracted in a deterministic manner. The codename is just a thought up name by Intel and not included in the silicon (CPUID does not have this information). One would have to include a truth table for all 12th, 13th and 14th gen processors. And what about others, older and newer processors? The truth table would grow forever each year to an enormous size. This is a NO from my side. Adding a truth table for P/E cores disabling was already enough pain, because CPUID also does not allow to read the amount of cores of each type...

add date to Dasharo release version, e.g. v1.1.3 (2024-01-??)

Release date is a part of different SMBIOS field. Release version format is fixed and won't be changed. Release date may be added in some different place. Like I said, there is not much free space on front page.

I would opt for a separate submenu with platform/firmware information. The number of requests will only grow and the setup front page size is limited.

Add the complete version history/Changelog with ISO 8601 dates (YYYY-MM-DD) into the Dasharo System Features menu or elsewhere where appropriate.

What kind of changelog? The changelog of the whole firmware? Again, it is not generic and including all changelogs for all platforms (or different changelogs depending on platform) in the payload is huge boilerplate...

Further ideas or suggestions to these cosmetic changes?

Cosmetic changes... Cosmetic changes are usually trivial. All those requests are a ton of work with almost no gain, just to display information available elsewhere.

I'm not saying these are not good ideas, but people are forgetting one simple fact. Having all those information and features is good for target-oriented BIOS which is developed for one platform on a separate branch. And only things applicable to that platform are included. In such cases it works well, despite it does not propagate to other platforms/portability is low and painful. coreboot and UEFI Payload are solutions which support multiple platforms and must be as generic as possible (except where it is not possible, e.g. for silicon initialization). Payload has to be even more generic than coreboot itself. So adding anything that cannot be obtained easily at runtime is problematic, because adding something not generic has to be handled and tested separately for all supported platforms.

[Firminator]

Awesome. Thanks for providing this insight. I agree that the work involved in this outweighs the benefit. Thanks for taking the time to explain.