# AMI Aptio ## Identification [[UEFI BIOS Updater|UBU]] is a community toolset historically used to inspect or update option ROMs, EFI drivers, and CPU microcode inside certain firmware images. [[AMI Aptio|AMI Aptio]] is an AMI UEFI firmware platform; [[CPU microcode|CPU microcode]] supplies processor corrections loaded by firmware or the OS. Community firmware tools can parse and rebuild images, but platform signatures, Intel Boot Guard, image layout, and vendor capsules can make apparently successful edits unbootable. ## Notebook evidence - [[Scanned_20260730-1719#PDF page 46 — UBU, MMTool, microcode, and AMI Aptio BIOS modding|PDF page 46: UBU, MMTool, microcode, and AMI Aptio BIOS modding]] — The author is researching repeatable module-level firmware maintenance: identify versions, extract components, replace option ROMs or microcode, and rebuild. This is a much more consequential form of “software update” than the Android app list on page 14. - [[Scanned_20260730-1719#PDF page 47 — Ozmosis tooling and firmware image references|PDF page 47: Ozmosis tooling and firmware image references]] — The page ties a specific firmware image/toolchain to a user application. This is important: the firmware work may not be abstract experimentation; it may be in service of preserving a creative software environment. - [[Scanned_20260730-1719#PDF page 48 — MMTool/Ozmosis and RetroArch|PDF page 48: MMTool/Ozmosis and RetroArch]] — The page pairs a firmware-compatible macOS system with a concrete workload: PlayStation emulation. This may explain later BIOS-file references. - [[Scanned_20260730-1719#PDF page 50 — AMI Aptio firmware modules and UEFITool|PDF page 50: AMI Aptio firmware modules and UEFITool]] — The author wants firmware that can understand more filesystems and emulate missing services before an OS loads. This is the architectural center of the Ozmosis section: move compatibility functions into UEFI modules so multiple boot paths can use them. - [[Scanned_20260730-1719#PDF page 51 — Ordered UEFI modules in a Z77/Ozmosis firmware image|PDF page 51: Ordered UEFI modules in a Z77/Ozmosis firmware image]] — This is a reverse-engineering observation: the author inspected a working image and recorded the module sequence as a template for another build. - [[Scanned_20260730-1719#PDF page 52 — RetroArch BIOS, PlayStation firmware, and Ozmosis modules|PDF page 52: RetroArch BIOS, PlayStation firmware, and Ozmosis modules]] — The page juxtaposes two boot-ROM layers: console firmware required by an emulator and PC firmware required to launch the host environment. The parenthetical “cmos-to-post” shows the author thinking about the chain from persistent settings through hardware initialization to an application’s virtualized console. - [[Scanned_20260730-1719#PDF page 53 — Ozmosis build components, PXE, and Kext-to-FFS conversion|PDF page 53: Ozmosis build components, PXE, and Kext-to-FFS conversion]] — The intended firmware is not merely “Mac compatible.” It is a universal pre-OS service layer capable of local filesystem access, Mac identity support, shell access, and network boot. - [[Scanned_20260730-1719#PDF page 55 — Windows installation media, AMI setup, and administrator shell|PDF page 55: Windows installation media, AMI setup, and administrator shell]] — The page connects three control planes: boot from Windows installation media, inspect/configure AMI firmware, and query the installed machine from an elevated shell. ## Relationships and overlays The source places this note in a shared evidence cluster with [[American Megatrends|American Megatrends]] · [[Beetle PSX HW|Beetle PSX HW]] · [[Btrfs|Btrfs]] · [[CPU microcode|CPU microcode]] · [[Enhanced FAT UEFI driver|Enhanced FAT UEFI driver]] · [[exFAT|exFAT]] · [[FakeSMC|FakeSMC]] · [[Ozmosis firmware|Ozmosis firmware]] · [[Preboot Execution Environment|Preboot Execution Environment]] · [[RetroArch|RetroArch]] · [[Sibelius|Sibelius]] · [[UEFI BIOS Updater|UEFI BIOS Updater]] · [[UEFI Shell|UEFI Shell]]. Within the larger collection, this evidence extends [[Vendor-Agnostic Recovery|vendor-agnostic recovery]] and [[Continuity Architecture|continuity architecture]] by showing how software, hardware, identity, and pre-OS control depend on recoverable interfaces. ## Evidentiary status and open leads Distinguish vendor-supported capsule updates from community image rebuilding. Require full-chip backup, hardware recovery, signed hash manifest, and board-specific validation. ## Source - [[Scanned_20260730-1719|Scanned_20260730-1719]]