HII Save, Callback, and Reset Flow in BIOS Setup

In BIOS Setup, a user changes an option, the callback prints a log, and the UI shows the new value, but the value is gone after reboot. Or the callback writes NVRAM immediately when the user only selects an option, then the user presses Cancel, but the setting is already saved. These are typical bugs in the HII save, callback, and reset flow.

The key point is: Callback does not mean Save. Browser state does not mean NVRAM. Reset required does not mean reset already happened.

General flow

Open Setup page
  -> Browser calls ExtractConfig or loads current VarStore data
  -> User changes a Question
  -> Browser updates browser state
  -> Browser may call Callback with an action
  -> User chooses Save
  -> Browser calls RouteConfig
  -> Driver validates and commits data
  -> Driver may call SetVariable
  -> Browser or driver requests reset if needed

There are multiple copies of the same setting in this path: the UI value, Browser state, driver private data, the UEFI variable in NVRAM, and the value that the real boot path reads after reboot.

Actions that are easy to misunderstand

Names vary by EDK II and browser implementation, but you often need to reason about these phases:

CHANGING      user is about to change a value
CHANGED       value changed in browser state
SUBMITTED     user submitted or saved a form/question
RETRIEVE      browser asks for the current value
DEFAULT       browser asks for a default value
FORM_OPEN     form is opened
FORM_CLOSE    form is closed

Not every action should write NVRAM. In many projects, the callback only validates input, updates dynamic UI, or sets an ActionRequest. The real commit usually happens in RouteConfig().

RouteConfig is usually the save path

RouteConfig() is where the Browser routes the new configuration back to the driver. The driver may parse the config string, update a buffer, validate policy, and then call SetVariable() or write another backend storage.

If the callback sees the right value but reboot loses it, check RouteConfig() before blaming NVRAM. If RouteConfig() writes correctly but boot behavior is still wrong, check the consumer that reads the setting after reboot.

Reset flow

Some settings need reset before they take effect, such as device enablement, boot mode, SATA mode, Secure Boot policy, or debug level. The driver or Browser may request reset through an action request or an equivalent flag.

But “reset required” is only a policy request. The platform still needs a path to process it: showing a prompt, setting a reset flag, calling reset service at the right time, or resetting after user confirmation.

Real debug case: saved value is lost after reboot

When Save seems to work but the value is lost, check this sequence:

1. What value does ExtractConfig() return when the form opens?
2. Which callback action arrives, and with which value?
3. Is Browser state correct after the user changes the option?
4. Is RouteConfig() called on Save?
5. Does RouteConfig() parse the config string correctly?
6. What status does SetVariable() return?
7. After reboot, what value does GetVariable() read?
8. Does any default, migration, or policy code override the value?

If the user presses Cancel but the value persists, the code probably wrote NVRAM too early in the callback.

What to look for in source

HII save/callback/reset checklist

Separate temporary callback behavior, real commit, and reset request.

• Find the QuestionId and callback action sent by the Browser.
• Check whether the callback writes NVRAM directly or only updates browser/private state.
• Find RouteConfig and the config string parsing path.
• Log old value, new value, browser value, and committed value.
• Check SetVariable status, attributes, variable name, and vendor GUID.
• Find ActionRequest or reset flags for options that require reset.
• After reboot, log the consumer-side value in the real boot path.

Useful logs

FormId / QuestionId
Callback Action
Browser value
Private data value
Config string from RouteConfig
Parsed value
SetVariable status
ActionRequest / reset required flag
Value before reboot
Value after reboot
Consumer-side value during boot

Without RouteConfig logs, you often cannot tell whether Save actually ran.

Firmware and security angle

Do not trust the UI value blindly. The backend should validate ranges, enums, dependencies, and lock state before committing. For sensitive settings, the callback should be a coordination point, not the only security boundary.

Related notes

• What is ConfigAccess Protocol?
• What is the Setup Browser?
• What is a Question in VFR?
• What is VarStore?
• BIOS Setup in UEFI HII

Found this article useful?

Share it with someone learning firmware, BIOS/UEFI, or embedded systems, or support the author.

Share Feedback ☕ Support

Nội dung liên quan

Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.

Ghi chú/HII Setup

HII/VFR Element Cheat Sheet for BIOS Setup

VFR/HII cheat sheet: FormSet, Form, Question, OneOf, CheckBox, VarStore, DefaultStore, SuppressIf, GrayOutIf, and setup debugging.

October 28, 2025Read →

Ghi chú/HII Setup

HII Architecture Overview in UEFI

A practical map of HII: drivers, package lists, HII Database, Setup Browser, ConfigAccess, and variable storage.

October 28, 2025Read →

Blog/BIOS / UEFI

What is BIOS Setup: from the classic blue screen to HII and modern NVRAM

Modern BIOS Setup is built on HII: VFR, VarStore, NVRAM. Why adding a field in the middle of a struct can break a system, and how to debug settings that don't persist.

June 10, 2026Read →

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.

Đọc blog Xem notes khác