[Success] Soarsea S200H Mini PC Advanced & Chipset Menu Unlock (AMI Aptio V)

The device is basically like a Intel NUC on steroids: in particular, with a CPU that doesn’t suck (mine is a i7-8850H). It’s made by a mysterious manufacturer somewhere in China and has been sold under numerous “brands,” including: EGlobal, Inctel (英科特尔)/Partaker (model B18), or Soarsea (双影王族). Overall it’s a very nice, high-quality unit but the AMI Aptio V BIOS it ships with is hopelessly deprived of all the interesting settings, although a couple of the advanced ones were copied over to the Boot menu (such as for example CPU Turbo options).

Even though it has a Coffee Lake CPU, the chipset is QM175 (Skylake-H). There is also an older generation of this product with previous-generation CPUs using DDR3 memory, I’m not sure if it uses the same BIOS but the steps below should at the very least apply to all the DDR4 versions.

This is a rather niché product but the information might be useful for dealing with similar systems as well.

Flashing

As far as I know no flashable BIOS files are publicly available, so be sure to do a complete backup of whatever the device came with before making any changes. There is also no “official” flash utility (some version of AFUWIN would probably do the job) but the good news is there is also no protection of any kind such as PRR in place, so Intel’s FPT(W64) works great. The interesting bits from a Chipsec report are quoted below:

  • bios_wp

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
     
    [*] running module: chipsec.modules.common.bios_wp
    [x][ =======================================================================
    [x][ Module: BIOS Region Write Protection
    [x][ =======================================================================
    [*] BC = 0x00000A88 << BIOS Control (b:d.f 00:31.5 + 0xDC)
    [00] BIOSWE = 0 << BIOS Write Enable
    [01] BLE = 0 << BIOS Lock Enable
    [02] SRC = 2 << SPI Read Configuration
    [04] TSS = 0 << Top Swap Status
    [05] SMM_BWP = 0 << SMM BIOS Write Protection
    [06] BBS = 0 << Boot BIOS Strap
    [07] BILD = 1 << BIOS Interface Lock Down
    [-] BIOS region write protection is disabled!
     
    [*] BIOS Region: Base = 0x00200000, Limit = 0x007FFFFF
    SPI Protected Ranges
    ------------------------------------------------------------
    PRx (offset) | Value | Base | Limit | WP? | RP?
    ------------------------------------------------------------
    PR0 (84) | 00000000 | 00000000 | 00000000 | 0 | 0
    PR1 (88) | 00000000 | 00000000 | 00000000 | 0 | 0
    PR2 (8C) | 00000000 | 00000000 | 00000000 | 0 | 0
    PR3 (90) | 00000000 | 00000000 | 00000000 | 0 | 0
    PR4 (94) | 00000000 | 00000000 | 00000000 | 0 | 0
     
    [!] None of the SPI protected ranges write-protect BIOS region
     
    [!] BIOS should enable all available SMM based write protection mechanisms or configure SPI protected ranges to protect the entire BIOS region
    [-] FAILED: BIOS is NOT protected completely
     
  • spi_access
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
     
    [*] running module: chipsec.modules.common.spi_access
    [x][ =======================================================================
    [x][ Module: SPI Flash Region Access Control
    [x][ =======================================================================
    SPI Flash Region Access Permissions
    ------------------------------------------------------------
    [*] FRAP = 0x0000FFFF << SPI Flash Regions Access Permissions Register (SPIBAR + 0x50)
    [00] BRRA = FF << BIOS Region Read Access
    [08] BRWA = FF << BIOS Region Write Access
    [16] BMRAG = 0 << BIOS Master Read Access Grant
    [24] BMWAG = 0 << BIOS Master Write Access Grant
     
    BIOS Region Write Access Grant (00):
    FREG0_FLASHD: 0
    FREG1_BIOS : 0
    FREG2_ME : 0
    FREG3_GBE : 0
    FREG4_PD : 0
    FREG5 : 0
    BIOS Region Read Access Grant (00):
    FREG0_FLASHD: 0
    FREG1_BIOS : 0
    FREG2_ME : 0
    FREG3_GBE : 0
    FREG4_PD : 0
    FREG5 : 0
    BIOS Region Write Access (FF):
    FREG0_FLASHD: 1
    FREG1_BIOS : 1
    FREG2_ME : 1
    FREG3_GBE : 1
    FREG4_PD : 1
    FREG5 : 1
    BIOS Region Read Access (FF):
    FREG0_FLASHD: 1
    FREG1_BIOS : 1
    FREG2_ME : 1
    FREG3_GBE : 1
    FREG4_PD : 1
    FREG5 : 1
    [*] Software has write access to Platform Data region in SPI flash (it's platform specific)
    [!] WARNING: Software has write access to GBe region in SPI flash
    [-] Software has write access to SPI flash descriptor
    [-] Software has write access to Management Engine (ME) region in SPI flash
    [-] FAILED: SPI Flash Region Access Permissions are not programmed securely in flash descriptor
     
  • spi_desc
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
     
    [*] running module: chipsec.modules.common.spi_desc
    [x][ =======================================================================
    [x][ Module: SPI Flash Region Access Control
    [x][ =======================================================================
    [*] FRAP = 0x0000FFFF << SPI Flash Regions Access Permissions Register (SPIBAR + 0x50)
    [00] BRRA = FF << BIOS Region Read Access
    [08] BRWA = FF << BIOS Region Write Access
    [16] BMRAG = 0 << BIOS Master Read Access Grant
    [24] BMWAG = 0 << BIOS Master Write Access Grant
    [*] Software access to SPI flash regions: read = 0xFF, write = 0xFF
    [-] Software has write access to SPI flash descriptor
     
    [-] FAILED: SPI flash permissions allow SW to write flash descriptor
     
  • spi_lock
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
     
    [*] running module: chipsec.modules.common.spi_lock
    [x][ =======================================================================
    [x][ Module: SPI Flash Controller Configuration Locks
    [x][ =======================================================================
    [*] HSFS = 0x0010E800 << Hardware Sequencing Flash Status Register (SPIBAR + 0x4)
    [00] FDONE = 0 << Flash Cycle Done
    [01] FCERR = 0 << Flash Cycle Error
    [02] AEL = 0 << Access Error Log
    [05] SCIP = 0 << SPI cycle in progress
    [11] WRSDIS = 1 << Write status disable
    [12] PR34LKD = 0 << PRR3 PRR4 Lock-Down
    [13] FDOPSS = 1 << Flash Descriptor Override Pin-Strap Status
    [14] FDV = 1 << Flash Descriptor Valid
    [15] FLOCKDN = 1 << Flash Configuration Lock-Down
    [16] FGO = 0 << Flash cycle go
    [17] FCYCLE = 8 << Flash Cycle Type
    [21] WET = 0 << Write Enable Type
    [24] FDBC = 0 << Flash Data Byte Count
    [31] FSMIE = 0 << Flash SPI SMI# Enable
    [+] SPI write status disable set.
    [+] SPI Flash Controller configuration is locked
    [+] PASSED: SPI Flash Controller locked correctly.
     

As you can see, the FLOCKDN bit is still set, although it doesn't actually lock down anything.

The FPT utility is part of Intel's CSME System Tools helpfully provided by @plutomaniac in a dedicated thread: Intel Management Engine: Drivers, Firmware & System Tools. Since the chipset is a Skylake-H (QM175), use version 11 (not 12) of the tools. Specifically, I used FPTW64 version 11.8.65.3606, part of Release 28 of 2019-10-27 (the latest at the time):
1
2
3
4
 
% FPTW64.exe -ver
 
Intel (R) Flash Programming Tool. Version: 11.8.65.3606
Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
 

The ME was already disabled on the device when I got it so there is no risk it could interfere with the flashing process:

  • ME Analyzer (1.96.2 Release 175)
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
     
             Family         :       CSE ME
    Version : 11.0.22.1000
    Release : Production
    Type : Region, Extracted
    SKU : Consumer H
    Chipset : SPT-H D
    Security Version Number : 1
    Version Control Number : 20
    Production Ready : Yes
    Lewisburg PCH Support : No
    OEM RSA Signature : No
    OEM Unlock Token : No
    Date : 2016-12-12
    File System State : Configured
    Size : 0x1BF000
    Flash Image Tool : 11.6.0.3307
    Latest : No
     
     
  • ME Info
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
     
    % MEInfoWin64.exe -fwsts -verbose
     
    Intel(R) MEInfo Version: 11.8.70.3626
    Copyright(C) 2005 - 2019, Intel Corporation. All rights reserved.
     
    Windows OS Version : 10.0
     
    [...]
     
    CurrentState: Disabled
    ManufacturingMode: Enabled
    FlashPartition: Valid
    OperationalState: Transitioning
    InitComplete: Initializing
    BUPLoadState: Success
    ErrorCode: Disabled
    ModeOfOperation: Alt Disable Mode
    SPI Flash Log: Not Present
    FPF HW Source value: Not Applicable
    ME FPF Fusing Patch Status: ME FPF Fusing patch NOT applicable
    Phase: BringUp
    ICC: Valid OEM data, ICC programmed
    ME File System Corrupted: No
    PhaseStatus: UNKNOWN
    FPF and ME Config Status: Not committed
     

Physically, the flash chip is a run-of-the-mill Winbond W25Q64JVSIQ. The bad news is that the CH341A programmer (at least the version I have) does not seem to provide enough power to make in-circuit SPI flash programming possible, which makes for a strong incentive not to mess anything up while software-flashing, so that the device doesn't end up bricked. I think it should still be possible to either try programming a live (powered on) system (disconnecting the power from the SOIC8 clip) or, in the worst-case scenario, desoldering the chip to reflash it. Fortunately I did not have to attempt either but the prospect of having to deal with it made me somewhat less adventurous than I would usually be, and double-check everything.

There is also another SPI flash chip present, a Winbond W25Q80DVSIG. I presume it's used by the onboard RTL8168G Ethernet controller.

To dump the BIOS (6,291,456 bytes):
% FPTW64.exe -bios -d BIOS.bin

I also suggest you make a complete dump (8,388,608 bytes) once before making any changes:
% FPTW64.exe -d All.bin

This could be used with a hardware programmer if things go south. My suggestion would be not to flash the full dump with FPTW64 (I did not try it myself but, from the experience with other systems, it could potentially lead to problems, and is in any case superfluous).

Instead, just flash the BIOS portion as follows:
% FPTW64.exe -bios -f BIOS.bin

See the following post on how to come up with a modified BIOS file.

Modification: Scope

There are 3 modules of interest as far as what shows up in the UEFI Setup utility is concerned:

AMI Text Setup Environment (TSE)

GUID: B1DA0ADF-4F77-4070-A88E-BFFE1C60529A
Name: AMITSE
Volume Index: 03:02-03
File Index: 0x10C
Uncompressed Module Size (MMTool): 337,616 B
Headerless PE32 Image Body Size (UEFITool): 337,568 B

Contains, in particular, list of forms that appear in top-level menu.

AMI Text Setup Environment (TSE) Data

GUID: FE612B72-203C-47B1-8560-A66D946EB371
Name: AMITSESetupData
Volume Index: 03:02-03
File Index: 0x10D
Uncompressed Module Size (MMTool): 374,848 B
Headerless Body Size (UEFITool): 374,768 B

Contains menu to submenu and menu item mapping, as well as access restriction data, partly overrides IFR.

Setup Utility

GUID: 899407D7-99FE-43D8-9A21-79EC328CAC21
Volume Index: 03:02-03
File Index: 0x43
Uncompressed Module Size (MMTool): 630,748 B
Headerless PE32 Image Body Size (UEFITool): 630,592 B

Contains UEFI Standard Internal Forms Representation (IFR), partly overriden by AMI TSE Setup Data.

If, while at it, you also want to change the boot logo, here is where it’s located:

Boot Logo

Format: BMP, Uncompressed
GUID: 7BB28B99-61BB-11D5-9A5D-0090273FC14D
Name: Logo.bmp
Color Depth: 4-bit (16 Colors)
Dimensions: 568 × 151 px

Modification: Tools

There is the choice of using either UEFITool (I verified 0.26.0 works fine) or AMI MMTool (5.02.00.24). Note that you do not need a patched version of the latter (since the BIOS is Aptio V not IV), the regular one will do. If using MMTool, note that the extracted modules will have a header, which changes the offset numbers (plus, there is also a footer as well). You should always extract modules for modification as “Uncompressed”, not “As Is.” If using UEFITool, make sure you are always extracting the (headerless) body. Generally, if you mess up some data within the modules, the device will still boot, maybe only the UEFI Setup Utility cannot be accessed or will hang but what could potentially lead to a brick is if one of the modules were accidentally replaced with complete gibberish, so when modifying these files pay attention to all the headers (and footers), and that you are placing correct modules under their respective GUIDs.

I used MMTool for module replacement. As for the boot logo, it appears AMI Change Logo (5.0.0.2) is able to extract it but unable to replace it with a new one. The logo can succesfully be changed with UEFITool. AMI BIOS Configuration Program (BCP) 5.02.0031 can be used to display the menu hierarchy, and AMI DMI Editor (Windows, 64-bit) 5.19 & DMIEdit (GUI) 5.20.0042 also seem to work but I did not try making any changes using them. The ancient version of AMI SCE that I have (2.02.1036) could not even read the settings but, just for the record, if you don’t want to modify the BIOS but still change some settings, it should be possible to do so using a (full) UEFI shell’s dumpvar command, although it’s not really convenient to do so if planning on making more changes regularly.

It’s probably a good idea to understand what you are changing, so I suggest using Donovan’s IFR Extractor and making sure the numbers you are changing are the correct ones in your version of the BIOS. The tool can read an MMTool-extracted Setup module regardless of the header but the offsets will be different, so keep that in mind. The latest version of IFR Extractor (0.7) was helpfully posted by @Lost_N_BIOS here: [Help] Donovan’s EFI Variable Dumper Download.

Module: AMI Text Setup Environment (TSE)

A data structure located within this module contains the list of all forms to be displayed as the top-level menu. Neither Advanced or Chipset are included in the list. Bad news is, generally with this kind of modification, menus can be replaced but not added easily. Good news is, in this particular case there is the space for a menu to be added. Bad news is, there is space to only add 1 menu while 2 menus are hidden. Fortunately, good news is the Main menu is nearly completely useless as it only allows setting the date and changing the language (where English is the only choice anyway), so good riddance. Here’s the patch against AMITSE:

  • Changing the pre-existing 4 menus:

    1
    2
    3
    4
    5
     
    UEFITool  MMTool   From    To      Remark
    0x45AE0 0x45AFC 0x2711 0x2712 Main -> Advanced
    0x45B00 0x45B1C 0x2714 0x2713 Security -> Chipset
    0x45B20 0x45BC3 0x2715 0x2714 Boot -> Security
    0x45B40 0x45B5C 0x2716 0x2715 Save & Exit -> Boot
     
  • Adding the new, 5th menu:
    1
    2
     
    UEFITool  MMTool   From  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  Remark
    0x45B50 0x45B6C To 4A 10 59 7B 0D C0 58 41 87 FF F0 4D 63 96 A9 15 16 27 Save & Exit [New Entry]
     
When applying this and subsequent patches mind the endianness: 0x2712 will appear as "12 27" in the hex editor.

Alternative Approach

As useless as it might be, the Main menu could still be saved. Instead, the only two menu items in the Chipset menu could be moved to Advanced, and the Chipset menu would no longer need to be displayed. The AMITSE patch would then take the following shape:

  • Changing 2 of the 4 pre-existing menus:
    1
    2
     
    0x45B00   0x45B1C  0x2714  0x2712  Security -> Advanced
    0x45B40 0x45B5C 0x2716 0x2714 Save & Exit -> Security
     
  • Adding the new, 5th menu (same as above):
    1
    2
     
    UEFITool  MMTool   From  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  Remark
    0x45B50 0x45B6C To 4A 10 59 7B 0D C0 58 41 87 FF F0 4D 63 96 A9 15 16 27 Save & Exit [New Entry]
     
However, this approach would require also making changes to AMITSESetupData. Let's not get ahead of ourselves then and go through with the simpler patch variant first.

Main Menu Access

As an aside, with the modified BIOS version it's still possible, due to a bug (or a feature, depending how you look at it) to display the now-hidden Main menu, only when entering UEFI Setup by running shutdown /r /fw /t 0 from Windows. The Setup will open with only the Main form visible. The remaining forms can be accessed by pressing Esc twice (after pressing Esc once a list of all forms will be displayed as a regular menu).

Module: Setup

I did not verify if this part is strictly necessary, perhaps not but for completeness it can't hurt to do it as well. The Advanced and Chipset forms are permanently suppressed in the Setup Internal Forms Representation (IFR), and we are going to unhide them.

The relevant snippet from the IFR dump:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
Form: Setup, FormId: 0x2710 {01 86 10 27 07 00}
Ref: Main, VarStoreInfo (VarOffset/VarName): 0xFFFF, VarStore: 0x0, QuestionId: 0x1, FormId: 0x2711 {0F 0F 09 00 02 00 01 00 00 00 FF FF 00 11 27}
 
Suppress If {0A 82}
True {46 02}
Ref: Advanced, VarStoreInfo (VarOffset/VarName): 0xFFFF, VarStore: 0x0, QuestionId: 0x2, FormId: 0x2712 {0F 0F 1F 00 02 00 02 00 00 00 FF FF 00 12 27}
End If {29 02}
 
Suppress If {0A 82}
True {46 02}
Ref: Chipset, VarStoreInfo (VarOffset/VarName): 0xFFFF, VarStore: 0x0, QuestionId: 0x3, FormId: 0x2713 {0F 0F 20 00 02 00 03 00 00 00 FF FF 00 13 27}
End If {29 02}
 
Ref: Security, VarStoreInfo (VarOffset/VarName): 0xFFFF, VarStore: 0x0, QuestionId: 0x4, FormId: 0x2714 {0F 0F 53 00 02 00 04 00 00 00 FF FF 00 14 27}
Ref: Boot, VarStoreInfo (VarOffset/VarName): 0xFFFF, VarStore: 0x0, QuestionId: 0x5, FormId: 0x2715 {0F 0F 21 00 02 00 05 00 00 00 FF FF 00 15 27}
Ref: Save & Exit, VarStoreInfo (VarOffset/VarName): 0xFFFF, VarStore: 0x0, QuestionId: 0x6, FormId: 0x2716 {0F 0F 66 00 02 00 06 00 00 00 FF FF 00 16 27}
End Form {29 02}
 
The way to unhide them is to simply change the two occurences of True {46 02} to False {47 02}. The patch:
1
2
3
 
UEFITool  MMTool   From  To    Remark
0x24860 0x248DC 0x46 0x47 Advanced
0x24875 0x248F1 0x47 0x47 Chipset
 

Purpose

What can be achieved with the unlocked Advanced menus? For me personally the motivation for the unlock was that I am using this device with an external GPU connected through an NVMe M.2 adapter (ADT R43SG), and while it works very well without any noticeable issues, occasionally there are some connection error messages being reported, and Windows’s WHEA-Logger keeps spamming the Event Log with them, which I believe might actually be impacting performance. While it is possible to switch this logging off on the Windows’ side, it’s even better to disable this unnecessary error reporting at the BIOS level. Since the option to do so is no longer hidden, I can now disable Advanced Error Reporting for port #9 in the BIOS so that WHEA-Logger has nothing to report.

Separately, the memory modules I was originally planning to use with this system (G.Skill F4-3200C18D-32GRS) would for some reason not work with the XMP1 profile at 3200 MT/s but revert to their JEDEC defaults at 2400 MT/s only. Out of laziness, I originally “solved” this problem by buying a different set of modules (HyperX HX432S20IBK2-32), which does not suffer from this issue but now that the menus are unlocked I can make both the G.Skill and HyperX run even faster. Unfortunately, the fly in the ointment here is that for some reason memory voltage (VDD) changes are being ignored and the voltage reverts to 1.20V upon reboot, so the overclocking potential is limited. Adding insult to injury, it appears all the other voltages I have no need to adjust in the BIOS (such as VCCIO or VCCSA) can be changed without issues.

Scope for Improvement

As mentioned before, instead of hiding the Main menu a better approach would be to keep the Chipset menu hidden, instead moving (or duplicating) the only two menu items there to the Advanced menu. Helpfully, there are 3 versions of the Trusted Computing menu present in the Setup but since the device in question has no TPM, only one version is ever applicable, and the other two are always suppressed. These could be replaced with the two menus from the Chipset menu. In summary, since for aesthetic reasons the PCH-FW and PCH-IO menus would look better next to each other, the complete patch would involve the following changes:

Thermal Configuration (IFR Form 0x2797, TSE Form 0x19, TSE Form 0x03 [Advanced] Item 0x04) →
→ PCH-IO Configuration (IFR Form 0x2753, TSE Form 0x57, TSE Form 0x40 [Chipset] Item 0x01)

Trusted Computing (IFR Form 0x27C8, TSE Form 0x32, TSE Form 0x03 [Advanced] Item 0x0C)
→ System Agent (SA) Configuration (IFR Form 0x273C, TSE Form 0x42, TSE Form 0x40 [Chipset] Item 0x00)

Trusted Computing [TPM 2.0] (IFR Form 0x27C9, TSE Form 0x33, TSE Form 0x03 [Advanced] Item 0x0D)
→ Thermal Configuration (IFR Form 0x2797, TSE Form 0x19, TSE Form 0x03 [Advanced] Item 0x04)

This involves some more changes to Setup IFR (the easy part) as well as concurrent changes to AMITSESetupData, which is a quagmire. The two data structures exist in parallel and partly overlap each other. The TSE menu structure can be displayed (but not modified) by AMI BIOS Configuration Program (BCP) but it processes the data differently than the UEFI Setup.

A similar change was succesfully attempted by @Mov_AX_0xDEAD and reported here: [Request] How to Access Locked/Hidden BIOS Menu Settings (15), although I don’t know what he changed exactly. He also reverse-engineered and described the format of the data on another forum: https://forums.overclockers.ru/viewtopic.php?f=25&t=599984

I have attempted the modification in a similar spirit and got some partial results but haven’t completed it since I have other things to deal with at the moment, and this is largely a cosmetic endeavor anyway but might revisit it when I have the time. The reason I am bringing this up is to leave a note that I can share more details about it if anybody is interested.