BIOS và UEFI khác nhau như thế nào?

Nếu bạn từng tự lắp PC, cài Windows, dual boot Linux, hoặc đơn giản là lên mạng tìm cách sửa lỗi máy không nhận ổ cứng, rất có thể bạn đã gặp câu này:

“Vào BIOS chỉnh lại thử.”

Nghe thì đơn giản. Nhưng BIOS là cái gì mà lỗi gì cũng có người bảo vào đó? Muốn đổi thứ tự boot cũng vào BIOS. Bật TPM cũng vào BIOS. Sửa Secure Boot cũng vào BIOS. Bật XMP cho RAM, chỉnh fan, đổi SATA mode, tắt USB boot, rất nhiều thứ cũng lại nằm trong cái màn hình mà mọi người quen gọi là BIOS.

Nếu bạn từng dùng máy tính từ những năm 2000 trở về trước, có lẽ bạn còn nhớ hình ảnh này: vừa bật máy lên thì nhấn Del hoặc F2, sau đó một màn hình xanh hoặc xám hiện ra, toàn chữ trắng, dùng phím mũi tên để di chuyển, Enter để chọn, + và - để đổi giá trị. Không có chuột, không có giao diện đẹp, không có animation.

Đó là hình ảnh rất quen thuộc của Legacy BIOS Setup.

Nhưng nếu để ý kỹ hơn, bạn sẽ thấy một điều hơi lạ: máy tính hiện nay phần lớn không còn dùng BIOS theo nghĩa cũ nữa. Bên trong chúng thường là UEFI. Dù vậy, từ thợ sửa máy, người dùng Windows, người build PC, cho đến nhiều kỹ sư, mọi người vẫn quen miệng gọi chung là “BIOS”.

Vậy BIOS là gì? UEFI là gì? Nếu máy hiện nay dùng UEFI, tại sao chúng ta vẫn nói “vào BIOS”? Và hai thứ này khác nhau ở đâu, ngoài chuyện một cái nhìn cũ hơn, một cái nhìn hiện đại hơn?

Để thấy rõ điều này, mình muốn bắt đầu từ góc nhìn quen thuộc nhất với mình: firmware nhúng.

Khi mới chuyển từ embedded sang làm firmware PC, mình cũng từng nghĩ BIOS và UEFI chỉ khác nhau ở giao diện. BIOS là màn hình xanh chữ trắng. UEFI thì có chuột, có hình ảnh, có màu sắc đẹp hơn.

Sau một thời gian đọc log boot, đọc source driver, rồi debug những lỗi kiểu “máy thấy SSD nhưng không lên boot menu”, mình mới nhận ra mình đã nhìn sai vấn đề.

Khác biệt thật sự không nằm ở giao diện.

Nó nằm ở cách firmware tự tổ chức để dựng một chiếc PC từ trạng thái gần như chưa có gì: RAM chưa sẵn sàng, chipset chưa cấu hình, PCIe chưa enumerate, storage chưa xuất hiện, OS cũng chưa có ở đó để giúp mình.

Với embedded firmware, mình thường viết code cho một hệ thống đã tương đối rõ hình dạng. Còn với BIOS/UEFI, firmware phải tạo ra hình dạng đó trước, rồi mới bàn giao cho hệ điều hành.

Bài này sẽ đi từ những thứ quen thuộc như boot USB, Secure Boot, Windows Boot Manager, ổ cứng không lên boot menu, rồi mới đi vào kiến trúc bên dưới. Nếu bạn chưa quen với các khái niệm như Boot####, Device Path, Protocol, HII hay NVRAM, không sao. Đọc xong bài này, bạn sẽ có bức tranh nền. Các bài notes đi kèm phía dưới sẽ giải thích từng phần kỹ hơn.

Firmware PC khác firmware nhúng thông thường ở chỗ nào?

Nếu bạn đã làm embedded, bạn quen với mô hình này:

01 Power

Bật nguồn

CPU/MCU bắt đầu chạy từ reset vector

02 Reset

Reset handler

Copy .data, zero .bss, chuẩn bị môi trường C

03 main()

Chạy main

Khởi tạo GPIO, UART, peripheral

04 Loop

Main loop / RTOS

Firmware bắt đầu chạy logic chính

Hệ thống đã tồn tại sẵn. Flash đã có. RAM đã có. Bạn chỉ cần viết code điều khiển chúng.

Firmware PC, dù là Legacy BIOS hay UEFI, không có điều kiện đó. Khi CPU vừa reset, không có gì đáng tin cậy cả: DRAM chưa được khởi tạo, chipset chưa được cấu hình, tất cả thiết bị đều chưa được enumerate. Firmware phải tự tạo ra hệ thống trước khi có thể dùng hệ thống đó.

Firmware nhúng giống một nhân viên vận hành máy: máy đã có sẵn, họ chỉ cần điều khiển.

Firmware PC giống một kỹ sư xây dựng nhà máy. Nhà máy chưa tồn tại, họ phải xây từ đầu, đảm bảo mọi thứ hoạt động đúng thứ tự, rồi mới bàn giao.

Sự khác biệt này bắt nguồn từ phần cứng.

MCU thường tích hợp flash, RAM và peripheral trong một chip. Bật lên là chạy được ngay ở một mức nào đó. CPU x86 thì khác. Nó cần DRAM ngoài, chipset, PCIe, storage, controller, firmware policy và rất nhiều bước cấu hình nền tảng. Mọi thứ phải được dựng theo đúng thứ tự thì OS mới có thể chạy được.

Nhìn từ đường boot: hai tư duy khác nhau

Cách nhanh nhất để thấy sự khác biệt giữa Legacy BIOS và UEFI là nhìn vào đường boot.

Legacy BIOS làm mọi thứ theo trình tự khá tuyến tính:

01 Power On

POST

Power-On Self Test, kiểm tra phần cứng cơ bản

02 Boot Device

Tìm boot device

Quét danh sách thiết bị boot theo priority order

03 MBR

Đọc boot sector

Đọc 512 byte đầu của thiết bị. First-stage boot code bắt đầu từ đây, thường load tiếp stage sau

04 Bootloader

Chạy bootloader

First-stage bootloader trong MBR, ví dụ GRUB stage 1 hay Windows boot code, rồi load tiếp stage sau

05 OS

Vào OS

Quyền điều khiển chuyển sang kernel

UEFI nhìn hệ thống theo các phase rõ ràng hơn. Mỗi phase có trách nhiệm riêng và tạo nền cho phase sau:

01 SEC

Security Phase

CPU reset, temporary memory, thiết lập môi trường cực sớm. Một số platform thực hiện xác minh ban đầu ở đây

02 PEI

Pre-EFI Init

Khởi tạo DRAM, build HOB list, bàn giao data sang DXE

03 DXE

Driver Execution

Load driver, publish protocol, enumerate toàn bộ device

04 BDS

Boot Device Select

Đọc Boot####, resolve Device Path, load OS loader

05 OS Loader

ExitBootServices

OS loader lấy memory map, gọi EBS, chuyển quyền cho kernel

Sự khác biệt không chỉ là thêm bước. Ở mỗi phase UEFI, tài nguyên có sẵn thực sự khác nhau.

SEC chưa có DRAM nên không thể dùng heap như bình thường. PEI bắt đầu dựng DRAM và truyền thông tin qua HOB. DXE mới có đủ điều kiện để chạy driver model đầy đủ. BDS dùng các protocol và boot variable đã được dựng từ trước để chọn OS loader.

Chia phase không phải để làm phức tạp thêm. Nó là cách tổ chức bắt buộc khi bạn phải dựng một platform lớn từ trạng thái gần như chưa có gì.

Legacy BIOS: làm được việc nhưng không mở rộng được

Legacy BIOS phục vụ tốt trong nhiều thập kỷ. Nó làm đúng việc của thời đó: khởi tạo phần cứng cơ bản, chạy POST, tìm boot device, đọc MBR và nhảy vào bootloader.

Nhưng thiết kế ban đầu của Legacy BIOS không được xây dựng để mở rộng theo kiểu PC hiện đại cần:

• Không có driver model chuẩn. Mỗi vendor viết theo cách riêng, khó tái sử dụng
• MBR partition scheme giới hạn ổ đĩa dưới 2TB và tối đa 4 primary partition
• Boot sector chỉ có 512 byte. First-stage bootloader phải bắt đầu từ đây, thường load tiếp stage sau
• Gần như không có bảo mật boot. Bất kỳ code nào trong MBR đều có thể được thực thi
• Code thường monolithic, không có interface chuẩn giữa các component
• Mở rộng network boot, storage mới, firmware update hay security policy rất khó làm sạch

Khi bạn muốn thêm network boot, RAID, Secure Boot, firmware capsule update, hay support hàng trăm loại NVMe controller, vấn đề bắt đầu lộ ra. Legacy BIOS không có cơ chế đủ sạch để mở rộng theo kiểu đó.

UEFI: kiến trúc, không chỉ tính năng

UEFI (Unified Extensible Firmware Interface) không phải là Legacy BIOS với thêm vài tính năng. Nó được thiết kế lại như một firmware platform có driver model.

Điểm khác biệt cốt lõi: trong UEFI, các module firmware giao tiếp với nhau qua protocol, được định danh bằng GUID.

Ví dụ, một storage driver có thể publish Block I/O Protocol lên một handle:

gBS->InstallProtocolInterface(
    &Handle,
    &gEfiBlockIoProtocolGuid,
    EFI_NATIVE_INTERFACE,
    &BlockIoProtocol
);

Sau đó, filesystem driver hoặc BDS có thể tìm và dùng protocol đó:

gBS->LocateProtocol(
    &gEfiBlockIoProtocolGuid,
    NULL,
    (VOID **)&BlockIo
);

Storage driver không cần biết filesystem driver sẽ dùng nó thế nào. Filesystem driver không cần biết storage là SSD, NVMe, SATA hay USB. BDS không cần biết chi tiết bên dưới là controller nào. Nó đi qua các protocol đã được publish.

Với boot từ ESP, filesystem driver cung cấp Simple File System Protocol để BDS mở file .efi. Mỗi layer chỉ biết interface. Đây là điểm khiến UEFI trở nên modular theo nghĩa thực sự.

Cái màn hình “BIOS Setup” thật ra là gì?

Đến đây quay lại câu hỏi đời thường lúc đầu: khi bạn “vào BIOS” để đổi boot order, bật TPM, tắt Secure Boot, chỉnh SATA mode, bật XMP, thì bạn đang vào đâu?

Với máy cũ, đó có thể là Legacy BIOS Setup thật. Nhưng với phần lớn máy hiện đại, đó là UEFI Setup. Người dùng vẫn gọi là BIOS vì thói quen, nhưng kiến trúc bên trong đã khác.

Trong UEFI, màn hình setup hiện đại thường được xây bằng một kiến trúc tên là HII, viết tắt của Human Interface Infrastructure.

Nếu Legacy BIOS Setup giống một đoạn code vẽ trực tiếp lên màn hình, thì UEFI HII là một pipeline có cấu trúc. Nó tách riêng phần mô tả giao diện, string đa ngôn ngữ, storage, callback và nơi lưu giá trị cuối cùng.

01 VFR

Form source

Mô tả form, question, điều kiện hiển thị

02 UNI

String package

Chuỗi hiển thị đa ngôn ngữ

03 HII DB

HII Database

DXE driver install form package vào database

04 Browser

Setup Browser

Đọc IFR, render UI, xử lý input

05 VarStore

Backing storage

Dữ liệu tạm hoặc buffer map vào setting

06 NVRAM

Persistent storage

Giá trị được lưu qua UEFI variable path

Điểm hay của HII là mỗi DXE driver có thể tự đưa thêm form vào Setup mà không cần sửa toàn bộ Setup Browser. Browser chỉ đọc HII Database và render. Nó không cần biết có bao nhiêu driver đang cung cấp form.

Đây là lý do một menu Setup trên laptop hoặc server hiện đại có thể có rất nhiều option, nhiều tab, nhiều submenu, nhiều ngôn ngữ, nhưng codebase vẫn có cấu trúc.

Từ một option trong Setup đến NVRAM

Khi bạn vào Setup và đổi một option, ví dụ đổi SATA Mode từ AHCI sang RAID, điều đó không đơn giản là UI đổi một dòng text.

Bên dưới, option đó thường map vào một field trong VarStore. Khi user nhấn Save, firmware cần lưu giá trị mới xuống NVRAM hoặc storage tương đương. Lần boot sau, PEI hoặc DXE driver đọc lại setting này và cấu hình controller theo giá trị đã lưu.

Flow thực tế có thể hình dung như sau:

01 User

Đổi option

Ví dụ đổi SATA Mode sang RAID

02 Browser

Giữ giá trị tạm

Setup Browser update browser storage, chưa chắc đã ghi NVRAM ngay

03 Callback

Validate / notify

Driver có thể xử lý callback nếu đăng ký Config Access

04 Save

Save & Exit

Browser gọi RouteConfig() trên driver sở hữu FormSet

05 NVRAM

SetVariable()

Driver ghi setting xuống variable store

06 Next Boot

PEI/DXE đọc lại

Consumer đọc setting và cấu hình phần cứng

Bước dễ bị hiểu nhầm là: Browser không nhất thiết ghi NVRAM ngay khi user thay đổi option. Nhiều flow giữ giá trị trong buffer tạm. Chỉ khi Save & Exit thì RouteConfig() và SetVariable() mới quyết định dữ liệu có thật sự được lưu hay không.

Nếu SetVariable() fail, UI có thể đã hiển thị giá trị mới, nhưng NVRAM vẫn giữ giá trị cũ. Reset xong mọi thứ quay lại như trước.

Phần này đủ để hiểu bức tranh tổng quan. Chi tiết về VFR, IFR, VarStore offset, Config Access callback và migration nên tách sang bài riêng về BIOS Setup/HII.

Khác nhau ở artifact thực tế

Sự khác biệt kiến trúc giữa Legacy BIOS và UEFI hiện ra rất rõ ở những thứ bạn thật sự gặp khi làm việc:

Windows, Linux, macOS liên quan gì đến UEFI?

Những thứ ở trên không chỉ tồn tại trong spec. Chúng xuất hiện trực tiếp trong các hệ điều hành bạn dùng hằng ngày.

Windows hiện ra UEFI qua Windows Boot Manager, Secure Boot, TPM, Boot####/BootOrder và phân vùng ESP. Khi bạn thấy “Windows Boot Manager” trong boot menu, khi bật/tắt Secure Boot trong firmware setup, hoặc khi Windows không boot sau khi clone disk, bạn đang debug UEFI artifact chứ không chỉ debug Windows.

Linux hiện ra UEFI qua GRUB, systemd-boot, shim, efibootmgr, ESP và EFI boot stub. Một bản Linux có thể boot qua bootloader như GRUB, hoặc trong một số cấu hình, kernel được build với EFI boot stub để firmware load trực tiếp như một EFI application. Khi dual boot bị mất GRUB, khi Secure Boot chặn kernel hoặc module, hoặc khi efibootmgr không ghi được Boot####, vấn đề nằm ở ranh giới giữa Linux và UEFI firmware.

macOS cần tách rõ hai nhánh: Intel Mac có boot process gần với EFI world hơn, còn Apple Silicon dùng boot chain riêng của Apple với Boot ROM và security policy riêng. Không nên mô tả nó như PC UEFI thông thường. Nhưng macOS vẫn là ví dụ tốt cho cùng một nguyên lý: trước khi OS chạy, luôn có một firmware/security chain chịu trách nhiệm xác minh, dựng môi trường và chuyển quyền điều khiển.

Nói cách khác, UEFI không phải thứ chỉ firmware engineer mới gặp. Người dùng Windows gặp nó khi sửa Secure Boot hay Windows Boot Manager. Người dùng Linux gặp nó khi dual boot, shim, ESP hay efibootmgr lỗi. Khác nhau ở implementation, nhưng bài toán nền vẫn giống nhau: firmware phải dựng một đường boot đáng tin cậy trước khi OS được phép chạy.

Bảng so sánh nhanh

Tiêu chí	Legacy BIOS	UEFI
Kiến trúc	Monolithic	Chia phase, module hóa
Driver model	Không có chuẩn	Protocol + Driver Binding
Boot	MBR boot sector	EFI application, Boot Manager
Disk	Giới hạn bởi MBR	GPT, vượt xa giới hạn MBR trong thực tế
Setup UI	Text setup cổ điển	HII, VFR/IFR, Setup Browser
Setting storage	CMOS/NVRAM kiểu cũ tùy platform	UEFI variable, VarStore, NVRAM
Bảo mật	Rất hạn chế	Secure Boot, Measured Boot, TPM
Extensibility	Khó mở rộng	Protocol cho phép mở rộng theo module
Source structure	Khó hệ thống hóa	INF/DEC/DSC/FDF rõ ràng trong EDK II world

Sự khác biệt hiện ra khi debug như thế nào?

Đây là phần mình thấy quan trọng nhất, vì hiểu kiến trúc chỉ có giá trị nếu nó thay đổi được cách bạn tiếp cận vấn đề.

Case 1: Máy không boot sau khi clone disk

Với Legacy BIOS mindset, bạn sẽ kiểm tra MBR có hợp lệ không, partition có active không.

Với UEFI mindset, bạn kiểm tra: ESP có được tạo đúng trên disk mới không? Boot#### trong NVRAM có Device Path trỏ đúng disk/partition mới không? Khi clone hoặc restore disk, GPT partition GUID hoặc device path có thể thay đổi hoặc bị duplicate. Boot#### cũ vẫn trỏ theo Device Path cũ, nên boot option trở thành stale.

Case 2: Device có mặt trong hệ thống nhưng không lên boot menu

Với Legacy BIOS mindset, bạn kiểm tra disk có phải boot device không.

Với UEFI mindset, bạn trace theo chain: bus driver có enumerate device và tạo child handle không? Block I/O Protocol có được publish không? Partition driver có bind và tạo partition handle không? Filesystem driver có install Simple File System Protocol không? BDS có tìm thấy handle với SFSP không?

Đứt ở bước nào thì fix ở bước đó.

Case 3: Setting lưu trong BIOS nhưng reboot mất

Với Legacy BIOS mindset, bạn nghĩ đến CMOS battery hoặc CMOS clear.

Với UEFI mindset, bạn nghĩ đến NVRAM variable store và HII save flow: RouteConfig() có chạy không? SetVariable() có trả lỗi không? Variable có đúng attribute không? Variable store có bị full không? Platform policy có block write không? SMM variable path có hoạt động đúng không? Consumer thật sự có đọc đúng GUID, name và offset không?

Case 4: Thêm một option mới xong máy không thấy ổ cứng

Đây là case rất firmware. UI vẫn hiện option bình thường, build không lỗi, flash xong máy vẫn vào Setup được. Nhưng sau reboot, storage behavior sai.

Lúc này không nên chỉ nhìn giao diện. Cần kiểm tra struct layout, VarStore offset, NVRAM cũ, default path và module thật sự đọc setting đó. Một byte lệch trong SETUP_DATA có thể làm một field hoàn toàn khác bị hiểu nhầm là SATA mode, TPM flag hoặc boot policy.

Ba case đầu giúp bạn thấy UEFI khác Legacy BIOS ở đường boot. Case thứ tư cho thấy “vào BIOS chỉnh setting” trong thế giới UEFI thật ra đi qua một pipeline khá dài: UI, HII, VarStore, callback, NVRAM và consumer.

Vì sao người làm embedded nên quan tâm?

Nếu bạn chỉ làm STM32 hay MCU đơn giản, có thể UEFI ít liên quan trực tiếp. Nhưng nếu bạn làm firmware cho POS terminal, kiosk, payment device, industrial PC, thin client, mini PC hay bất kỳ hệ thống nào chạy trên x86, đây là kiến thức làm việc hàng ngày.

Ngay cả khi chỉ làm embedded thuần, hiểu cách UEFI tổ chức firmware vẫn giúp bạn nghĩ tốt hơn về:

• Bootloader staging: phân tách early init và main firmware, giống SEC/PEI boundary
• Memory init sequence: làm gì được và không được trước khi có full stack
• Driver init order: dependency giữa driver, giống DEPEX trong UEFI
• Interface-first design: code theo protocol thay vì direct call, dễ swap implementation
• Persistent config: setting không chỉ là biến global, nó cần storage, versioning và migration
• Handoff giữa stage: HOB pattern, truyền data qua boundary an toàn

Những pattern này không phải đặc thù của UEFI. Chúng là cách tổ chức firmware phức tạp một cách có hệ thống. UEFI là một trong những ví dụ lớn nhất và được document tốt nhất về cách làm điều đó.

Những hiểu nhầm phổ biến

“UEFI chỉ là BIOS có giao diện đẹp hơn”

Giao diện là phần nhỏ nhất. Khác biệt thật sự là driver model, protocol system, boot manager, HII, NVRAM variable và cách source code được tổ chức. Bạn có thể viết UEFI firmware không có UI đồ họa nào cả, và nó vẫn là UEFI đầy đủ.

“Vào BIOS là đang chỉnh trực tiếp phần cứng”

Không hẳn. Trong UEFI hiện đại, bạn thường đang chỉnh một setting trong Setup UI. Setting đó được lưu vào NVRAM hoặc một storage tương đương. Ở lần boot sau, PEI hoặc DXE driver đọc setting đó rồi mới cấu hình phần cứng. UI chỉ là phần nổi.

“BIOS/UEFI không liên quan đến embedded”

Nếu bạn làm MCU đơn giản, đúng là ít liên quan trực tiếp. Nhưng nếu bạn làm bring-up bo mạch x86 hoặc firmware cho thiết bị chạy trên PC platform, đây là kiến thức làm việc hàng ngày. Ngay cả với embedded thuần, boot staging, config storage, driver dependency và handoff giữa các phase vẫn là những pattern rất đáng học.

“Học UEFI chỉ cần học boot flow”

Boot flow là điểm bắt đầu. Nhưng làm việc thực tế với UEFI cần hiểu thêm nhiều layer: Protocol, Handle Database, GUID, Driver Model, Boot Services, Runtime Services, HII/Setup, NVRAM variable, Device Path và SMM. Mỗi layer có cách debug riêng. Boot flow chỉ cho bạn biết thứ tự, không cho bạn biết khi nào thì đứt và đứt ở đâu.

Học từ góc debug

Nhiều tài liệu UEFI bắt đầu từ spec và định nghĩa. Cách đó đúng, nhưng chậm, đặc biệt khi bạn đang có một cái máy không boot và cần hiểu chuyện gì đang xảy ra.

Cách mình thấy hiệu quả hơn là bắt đầu từ câu hỏi debug thực tế:

• “Tại sao device này có trong hệ thống nhưng không lên boot menu?”
• “Tại sao setting này lưu rồi nhưng reboot lại mất?”
• “Tại sao máy reset loop sau khi flash firmware mới?”
• “Tại sao thêm một option nhỏ trong Setup lại làm storage behavior thay đổi?”

Mỗi câu hỏi đó dẫn bạn vào đúng layer cần hiểu. Khi bạn hiểu tại sao lỗi xảy ra, bạn cũng hiểu cách hệ thống hoạt động đúng.

Nhìn lại quá trình học, điều quan trọng nhất không phải là nhớ được UEFI có bao nhiêu phase hay Legacy BIOS có hạn chế gì.

Mà là hiểu được một điểm chuyển tư duy:

Trong embedded, chúng ta viết firmware cho một hệ thống đã tồn tại.

Trong firmware PC, firmware chính là thứ tạo ra hệ thống đó.

Và trong UEFI hiện đại, cái màn hình mà mọi người quen gọi là “BIOS” chỉ là một cánh cửa nhỏ dẫn vào cả một kiến trúc lớn hơn phía sau.

Tài liệu tham khảo

• UEFI Specification
• EDK II Project
• EDK II HII Database modules
• Linux kernel EFI stub documentation
• Microsoft Secure Boot overview
• Apple Platform Security: Boot process

Đọc tiếp

• UEFI Boot Flow: từ Reset Vector đến ExitBootServices
• DXE Phase: Driver, Protocol và cách debug khi mọi thứ không chạy
• BIOS Setup, HII và NVRAM hoạt động như thế nào?
• SEC là gì?
• PEI là gì?
• DXE là gì?
• BDS là gì?
• Protocol trong UEFI là gì?
• Handle Database là gì?
• HII Architecture Overview
• VarStore là gì?
• NVRAM là gì?

Thấy nội dung này hữu ích?

Lưu lại hoặc chia sẻ cho người cũng đang học firmware, BIOS/UEFI và embedded systems.

Chia sẻ Copy link

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.

Blog/BIOS / UEFI

BIOS Setup là gì: từ màn hình xanh cổ điển đến HII và NVRAM hiện đại

BIOS Setup hiện đại được xây dựng trên HII: VFR, VarStore, NVRAM. Tại sao thêm field vào giữa struct phá hỏng hệ thống và cách debug setting không lưu được.

10 tháng 6, 2026Đọc tiếp →

Blog/BIOS / UEFI

UEFI Boot Flow: từ Reset Vector đến ExitBootServices

Không phải học để thuộc tên phase. Học boot flow để biết máy đang chết ở đâu, và debug theo hướng nào: từ SEC đến Runtime.

2 tháng 5, 2026Đọc tiếp →

Blog/BIOS / UEFI

ACPI là gì: tại sao firmware không nên tắt máy bằng cách toggle GPIO

Tại sao firmware không nên dùng GPIO trực tiếp để tắt máy? ACPI là hợp đồng firmware viết, OS đọc: table, AML, power state và cách debug sleep/wake sai.

10 tháng 6, 2026Đọc tiếp →

Đọc thêm về BIOS/UEFI

Khám phá các bài viết về BIOS/UEFI, embedded firmware, debugging và system-level thinking.

Đọc thêm bài BIOS/UEFI Xem projects