System Firmware Windows 10 — что это? (Asus)

Сразу коротко ответ: обновление, которое представляет из себя новую прошивку BIOS, установка подразумевает автоматическое обновление биоса.

Внимание: устанавливать обновление нежелательно, если компьютер функционирует корректно. Могут легко появиться проблемы.

Разбираемся

Точной информации об этом нет вообще.

По поводу биоса — да, именно, имеется ввиду обновление того самого биоса, который содержит множество настроек железа (при помощи которых иногда и разогнать комп можно):

PS: в BIOS обычно можно попасть если при включении ноута зажимать кнопку F1 / F2 / Del — какую именно, это уже зависит от модели устройства (смотрите инструкцию).

Однако в интернете нашел картинку, оказывается под данным названием может быть устройство в диспетчере:

Вот свойства устройства:

Из чего можно сделать такие выводы:

1. Встроенное ПО — означает что устройство представляет из себя какой-то чип, который распаян на материнской плате ASUS, и этот чип имеет свое программное обеспечение (ПО). Вполне возможно, что данный чип — область, где записана микропрограмма BIOS.
2. Изготовитель ASUSTeK COMPUTER INC — говорит о том, что это девайс от Асус, а не левое устройство/ПО.
3. Размещение на Microsoft UEFI-совместимой системе — упоминается UEFI, снова видим что опять имеет отношение к BIOS.

Если у вас появилось устройство System Firmware — мое мнение не удалять его и вообще ничего с ним не делать. Лучше написать по возможности в поддержку Асус. Потому что.. вы можете его удалить, а потом вообще операционная система не загрузки. Это конечно лично моя рекомендация.

Также название System Firmware упоминалось на форуме 4PDA в ветке про ноутбук ASUS TUF Gaming FX505GT, там сказано, что это — обновление биоса. То есть прошивка, которую можно скачать с офф сайта Асус, потом поставить и биос будет обновлен. Однако данный процесс необходимо выполнять только при соответствующих знаниях, ведь BIOS — дело серьезное.

Также у вас System Firmware может упоминаться в названии одного из обновлений, например в приложении Windows Update MiniTool:

Некоторые пользователи пишут — устанавливать обновление не нужно, после него может не запуститься компьютер. Неудивительно, ведь дело касается обновления биоса.

Также обновление может прилететь и через Windows Update. После установки его — тоже могут быть проблемы.

Выводы

Итак, теперь сделаем выводы:

1. Под названием System Firmware подразумевается в большинстве случаев системная прошивка, это может быть компонент обновления биоса, может быть само обновление в Центре обнов Windows (которое тоже нужно для обновления BIOS).
2. Компонент System Firmware обновляет BIOS. Хорошо ли это? Да, но при условии что он обновиться корректно. А если будет ошибка — то Windows может вообще не запуститься, и даже нельзя исключать обращение в сервисный центр.
3. Поэтому, по возможности — отложите обновление биоса, постарайтесь не устанавливать System Firmware, если ПК/ноут работает корректно и вас все устраивает.

Вот например у меня материнская плата ASUS Gryphon Z87. Обновление биоса вышло уже давно. Но я его не ставил, потому что материнка работает стабильно и без глюков. Также и вам советую — если устройство функционирует стабильно то не советую ставить новый биос)) только если в этом есть крайняя необходимость)

Надеюсь данная информация оказалась полезной. Удачи и добра, до новых встреч друзья!

How to Find Your Firmware Revision for Windows ®

To find out which firmware revision your SSD is running, follow these steps:

Windows 7 and earlier:

1. Click on the Start menu
2. Open Control panel>System>Hardware
3. Select Device Manager
4. Expand Disk drives
5. Right-click on the drive and select Properties
6. Select the Details tab and select Hardware lds from the drop down menu. The firmware version will be displayed on the far right.

1. Click on Desktop
2. Move the mouse cursor to the upper right corner, then down to click Settings
3. Click Control Panel
4. Select Device Manager
5. Expand Disk drives
6. Right-click on the SSD and select Properties
7. Select the Details tab and then select Hardware lds from the drop down menu. The firmware version will be displayed on the far right.

1. Right-click on your start button then select Device Manager from the pop up menu.
2. Expand Disk Drives
3. Right-click on the SSD and select Properties
4. Select the Details tab then select Hardware lds from the drop down menu.
5. The firmware revision will be listed at the end of the SSD part number on the top line.

The property fields in Device manager may cut off characters if too many are present with both the SSD part number and firmware revision displayed. For example, an MX500 running firmware revision M3CR023 will apear as «CT500MX500SSD1M3CR.»

An alternative to Device Manager is to check the firmware revision installed on the SSD by downloading our free Storage Executive software (compatible with Windows 7 and newer versions and supports Crucial MX-series, BX-series, M550, and M500 SSDs).

If you want to know how to find this information on a Mac® system, go to this article.

If you want to know how to update the firmware to the latest revision, we have guides as well as firmware download links on our SSD Support page.

Component Firmware Update (CFU) firmware implementation guide

Component Firmware Update (CFU) is a protocol and a process for submitting new firmware images to be installed on the target device.

CFU is available in Windows 10, version 2004 (Windows 10 May 2020 Update) and later versions.

CFU submissions to the resident firmware are file pairs, one file is the offer part, the other file is the content part. Each CFU submission (each offer and content pair) is required to be created off-line before the submission is sent to the firmware that implements the CFU process.

In the sample Firmware source code in the CFU repository on GitHub, the general implementation agnostic common code for CFU is contained in ComponentFwUpdate.c . All other files are helper files that can be updated or modified to the developer’s unique implementation.

Contents

The offer and content parts

The offer and content make up a pair of files in the CFU schema.

The offer part is simply a 16 byte long file that maps to the FWUPDATE_OFFER_COMMAND structure outlined below.

The content part, the actual firmware to be updated is in the format dictated by the end-user developer. The provided CFU sample code uses SREC files for firmware content.

The offer is a 16 byte sequence. This offer structure is put into the offer file. It is essentially binary data, not text, because the offer contains bit fields of specific meaning.

The offer that is represented in the file maps to this C structure:

From low address to high address, the first byte of the offer is a segment number.

From high address to low address:

Offer register details

The Product ID. A unique product ID value for this CFU image can be applied to this field.

The milestone of the firmware the offer’s content represents. Milestones could be different versions of the HW build, for example, EV1 build, EV2 build, and so on. Milestone definition and value assignment are left to the developer.

If the firmware is intended for a specific bank — the 2-bit field supports four banks. The use of a bank register is included in the format of the offer because there are instances where the target devices uses banked firmware regions.

If that were the case, and the offer was meant to update a bank in use, the firmware that implements CFU on the target can reject the offer. Else, the firmware on the target implementing CFU can take other action as warranted.

If banking of firmware images is NOT in the design of the end-user firmware, then it is reasonable to ignore this field (set to whatever values that are convenient, but the value in the bank field is optional and depends on the way in which the on target firmware implements CFU).

The protocol version of the CFU protocol used is in 4 bits.

The bitmask corresponding to all unique HW this firmware image can operate on. For example, the offer may signify it can run on verX of HW but not on verY of HW. Bit definition and value assignment are left to the developer.

The version of the firmware being offered.

A byte token to identify the user specific software making the offer. This is intended to differentiate between drivers and tools that may both be trying to update the same running firmware. For example, a CFU update driver may be assigned token 0xA and a development updater tool may be assigned 0xB. Now the running firmware can selectively choose to accept or ignore commands based on which process is trying to update it.

The component in the device to apply the firmware update.

offer interpretation flags: If we want the in situ firmware to ignore version mismatch (older on top of newer) then set the bit to force Ignore Version.

Forcing immediate reset is asserted with one bit. If that bit is asserted, the host software expects the in situ firmware cause the device to perform a reset. The actions of the reset are platform specific. The device’s firmware may choose to take action which swaps banks to make freshly updated firmware the active in situ firmware. Or not. It’s left up to the implementation of the firmware. The expectation usually is that if the force immediate reset is asserted, that the device will do whatever is necessary to cause the firmware to make the new bank updated become the active firmware running on the target device.

In the event that the content portion of the offer and content pair involves multiple parts of content.

Processing offers

The ProcessCFWUOffer API accepts two arguments:

In this use case, assume the user software sends data bytes to the running firmware, then the first message is the offer message.

The offer message is a 16 byte message described above (the FWUPDATE_OFFER_COMMAND structure).

That offer message is the data used by the running firmware to disposition the offer.

During the disposition of the offer, the running firmware notifies the sender by populating fields in the FWUPDATE_OFFER_RESPONSE structure.

Interpreting the offer

The running firmware should keep track of it’s state in CFU process. It may be ready/waiting to accept an offer, in the middle of a CFU transaction, or waiting to swap banks between active/inactive firmware.

If the running firmware is in the middle of a CFU transaction — don’t accept/process this offer and notify host accordingly.

The component ID field of the offer may be used to signal the running firmware that a special action is requested from the running firmware. In the example CFU code, a special offer command is used by the host to retrieve the status of the CFU engine — whether the running software is capable and ready to accept CFU Offers.

Finally, a check is made if there is a bank swap pending. The bank swap refers to the firmware persisting the information as to whether or not it is still in the process of switching from the running, active application to the newly download image.

How and where bank switching is performed is an implementation specific task for the embedded firmware. The CFU protocol and process allows for information to be exchanged between the remote user application conducting the CFU and the in situ firmware that is running.

Finally, if the state of the running firmware is not busy, and the componentId is not a special command and there is no bank swap pending — THEN we can process this offer.

Processing an offer involves, but is not limited to, the four steps outlined below:

Step 1 — Check bank

Check the bank of the running application to the bank in the offer. Are they the same or different?

If the same, then reject the offer (we don’t want to overwrite the running/active image).

Step 2 — Check hwVariantMask

The running firmware checks the hwVariantMask in the offer against the HW it is running on. This allows the embedded firmware to reject an offer if the offer is invalid for the target. (ex. if the running firmware is on an old HW build and the new offered firmware is meant for a newer, HW build — then the running firmware should reject this offer)

If invalid, then reject the offer.

Step 3 — Check firmware version

Check if the version of the firmware content offered has a version older or newer than the current application firmware.

It is left up to the users implementation to decide how to check which firmware is greater than another and if to allow the ‘forceIgnoreVersion’ field in the offer to be used. Typical firmware development would allow the ‘forceIgnoreVersion’ field to be used during product development and in debug versions of the firmware but disallowed (not allowing older firmware to be updated on top of new firmware) in product/release firmware.

If this check failed, then reject the offer.

Step 4 — Accept offer

The offer is good. Accept the offer with a response that is tailored for the way messages and status are returned by the firmware to the remote user-application. The so-called «response» is data (a packed data structure as shown in the demonstration header files) and this data is written out to the user-application by the appropriate means for the device.

Process the content

The processing of the content is usually a multi step process. The multiple steps refers to the capability of the firmware to accept the firmware image in parts, also known as «blocks» of data. It is not always feasible to send the entire image at once to the embedded firmware, so it’s realistic to expect the implementation of the CFU protocol and process to accept content in small pieces.

This discussion uses tha assumption when describing the process of the CFU content.

The state machine of the content processing involves three states.

The state of processing the first block.

The state of processing the last block.

The state of processing any block in between first and last.

The structure of the content command

Like the offer, the content has a structure with fields that are used by the CFU algorithms in the demonstration.

The structure of the content command is simpler than the offer structure. The content is defined as a sequence of bytes to be written into memory. The preamble of the content is this structure’s fields:

UINT8 flags Denotes if the content «block» is the first, last or other.

UINT8 length Marks the length of the pData field. In the demonstration code for CFU, the limit on the size of the pData is 255 bytes. Other implementations may vary the maximum size of the «block».

UINT16 sequenceNumber Marks the index counter of which block is being submitted as content.

UINT32 address The address offset of the block. In the demonstration of CFU of this release, the implementation has predefined information about the physical address of each App region. For example, a two bank firmware implementation may have App1 begin at address 0x9000 and App2 begin at address 0xA0000 . So, depending on how the firmware image was prepared (S-Records) the address in the SREC may be either the physical address or an offset. In any case, there needs to be a shared understanding between the preparation of the content and the implementation specific routines of the CFU content processing to determine the true physical address of where to write the block in memory. It is left up to the firmware developer to adopt best practices and do checks for valid address ranges for each content blog. For example, the CFU code demonstrates a check made if perhaps App1 (meant for 0x9000 ) has addresses that overlap into App2, and so on.

UINT8 pData[MAX_UINT8] — This is the raw bytes of the firmware image block. Care is taken in the user-application to only put length bytes into the complete byte stream of the content block.

There are no bit fields used in the content structure as per the CFU demonstration from the code provided.

The first block

The first block starts the download of the firmware contents. The firmware running attempts to write the block into non-volatile memory. Of course the content «block» contains information about where in memory the block should be written, how much data to write and other fields.

Each componentID target device is different and there are multiple methods to persist the data into memory. For example, one componentId could require writing to internal flash, another componentId may write to an external SPI flash or another may utilize another IC’s I2C protocol to update it’s image. The demonstration included with this document highlights the use of a function called ICompFwUpdateBspWrite which each unique firmware must implement with knowledge of the underlying non-volatile memory I/O functions of the target it was designed for.

Any other block except first or last

The process of accepting new blocks continues when the user-application delivers another block, again with meta data in the message for the address of where the block should be written, how many bytes are contained, and other fields.

The in situ firmware would treat this just like a first block scenario.

However, it should be noted that at any time the system fails to capture and persist the block into memory, it is up to the in situ firmware to respond with a failure code.

The last block

The last block presents a challenge only if the in situ firmware needs to do tasks to validate the image that was just written to the memory.

First, the last block is written to memory.

Then, at a minimum, a CRC check should be made between the data already written to memory (from the first to last blocks) compared to the CRC field in the last block. It is left to each implementation firmware to know how to acquire the CRC for the downloaded image.

Keep in mind that the execution of the CRC check does take time. Unlike the normal flow of the execution of the CFU for offer and block submission. The last block submission, if it includes a CRC check, will have a certain delay involved just for the fact that the CRC check is potentially examining a large region of memory. Depending on the target device and other factors this may not be a concern.

The CRC check of the incoming image is optional and may be commented out. However, best practices should be put into place to at least adopt this check. It is strongly recommended that at this point in the CFU process, other actions are taken to ensure the integrity of the downloaded image. Some of these actions could include verify a ‘signed’ portion of the image and/or check certificate chains of trust or other best practice approaches to ensuring a secure firmware image. These are left up to the firmware developer.

Clean up after last block

Now that the last block is written, and the CRC check is complete, the firmware may respond with a failure if any part of the validation failed.

Otherwise, the expectation is that the CFU process in the firmware will respond with a successful status.

Forced reset checked

The forced reset flag in the offer is used to determine if the MCU of the target shall undergo a reset (user defined reset).

Typically when a reset is forced, the intent is to cause the MCU to do a reset in order to cause the App bank to switch. Updating persistent variables to denote what firmware image to boot into on reset is left to the firmware developer.