Check the BIOS version of a Framework Laptop on Linux (dmidecode)

Before updating firmware — or when filing a support ticket, or simply checking whether you are exposed to a known firmware bug — you need the exact BIOS version currently running on your Framework Laptop. On Linux the canonical tool is dmidecode, which reads the firmware’s own SMBIOS/DMI tables (a structured description the BIOS publishes in memory at boot). This guide installs it, runs it, and explains what every line means, then shows how to act on the result.

Why not just “look in the BIOS”? Entering the firmware setup (F2 at boot) shows the version too, but it forces a reboot and reads nothing scriptable. dmidecode gives you the same value from a running session, in one command, and lets you compare it against Framework’s release notes without leaving your desktop.

Notation: commands prefixed with sudo need root because the raw DMI tables live in /dev/mem. Where a non-root path exists it is called out explicitly.

1. Check whether dmidecode is already installed

It ships by default on many desktop installs, so check before installing anything:

command -v dmidecode && dmidecode --version

If this prints a path (e.g. /usr/sbin/dmidecode) and a version → skip to step 3.
If it prints nothing (or command not found) → install it in step 2.

On some distros dmidecode lives in /usr/sbin, which is not always on a normal user’s $PATH. If command -v finds nothing but you suspect it is present, try ls -l /usr/sbin/dmidecode. Running it through sudo (step 3) puts /usr/sbin on the path anyway.

2. Install dmidecode

Pick the line for your distribution. dmidecode is a tiny, dependency-light package — there is no risk in installing it.

Ubuntu / Debian / Pop!_OS (apt):

sudo apt update
sudo apt install -y dmidecode

Fedora (dnf):

sudo dnf install -y dmidecode

Confirm it is now available:

dmidecode --version

3. Read the BIOS information

The DMI tables are split into numbered types. The BIOS lives in type 0, and dmidecode accepts the friendly alias bios for it:

sudo dmidecode -t bios

Typical output on a Framework Laptop 16 (AMD):

BIOS Information
        Vendor: INSYDE Corp.
        Version: 03.06
        Release Date: 04/23/2026
        Address: 0xE0000
        Runtime Size: 128 kB
        ROM Size: 32 MiB
        ...
        BIOS Revision: 3.6
        Firmware Revision: 3.6

What each field means

Field	Meaning	Why it matters
Vendor	The firmware vendor. On Framework laptops this is `INSYDE Corp.` — Framework builds its UEFI on the Insyde H2O codebase, so this is expected, not a sign of a third-party BIOS.	Confirms it’s genuine Framework firmware.
Version	The human-facing BIOS version, e.g. `03.06`. This is the number you compare against Framework’s release notes.	The single value you actually came here for.
Release Date	Build date of this firmware (`MM/DD/YYYY`).	Quick sanity check that the version string and date agree with the Framework changelog.
ROM Size	Physical size of the SPI flash chip holding the firmware (e.g. `32 MiB`).	Informational; confirms the flash part, not how full it is.
BIOS / Firmware Revision	The same version expressed as numeric major.minor.	Some tooling reads these instead of the `Version` string.

The Version is the key line. Note it down (here: 03.06, dated 04/23/2026).

Want the version and nothing else? Filter the one line:
Terminal window
sudo dmidecode -s bios-version
-s (string keyword) prints a single value with no decoration — ideal for scripts. Related keywords: bios-release-date, bios-vendor. List them all with dmidecode -s (no argument).

4. Confirm which model and CPU you’re on (type 1 + type 4)

The BIOS version only makes sense alongside the system model and processor, because Framework ships different BIOS lines per platform (FW13 Intel, FW13 AMD, FW16 AMD…). Pull the system and CPU tables:

sudo dmidecode -t system -t processor

Relevant fields:

System Information
        Manufacturer: Framework
        Product Name: Laptop 16 (AMD Ryzen 7040 Series)
        ...
Processor Information
        Manufacturer: Advanced Micro Devices [AMD]
        Version: AMD Ryzen AI 9 HX 370 w/ Radeon 890M

A friendlier, color-formatted view of the same hardware comes from lshw:

# Ubuntu/Debian:  sudo apt install -y lshw
# Fedora:         sudo dnf install -y lshw
sudo lshw -class processor

*-cpu
     product: AMD Ryzen AI 9 HX 370 w/ Radeon 890M
     vendor: Advanced Micro Devices [AMD]
     physical id: 4
     bus info: cpu@0
     version: 26.36.0

Decoding `version: 26.36.0`

That triplet is family.model.stepping, read straight from the CPU’s CPUID, not a firmware version:

26 = CPU family 0x1A → AMD Zen 5 generation
36 = model 0x24 → the Strix Point die used in the Ryzen AI 300 series
0 = silicon stepping

This is useful when a BIOS changelog says “fixes X on stepping Y” or when checking that a microcode/AGESA update in a BIOS release actually targets your silicon. It does not change when you update the BIOS — only the SMBIOS BIOS Version does.

5. No-root alternative (sysfs)

If you can’t (or don’t want to) use sudo, the kernel already exposes the most-used DMI strings as world-readable files under /sys/class/dmi/id/:

cat /sys/class/dmi/id/bios_version
cat /sys/class/dmi/id/bios_date
cat /sys/class/dmi/id/bios_vendor
cat /sys/class/dmi/id/product_name
cat /sys/class/dmi/id/sys_vendor

Same 03.06 / 04/23/2026, no privileges, no extra package — the kernel parsed the DMI tables at boot and cached them here. The trade-off is that sysfs exposes only a curated subset; for ROM size, revisions, or the full table you still need dmidecode.

6. Act on it — compare with the latest release via fwupd

Knowing the version is only half the job; the point is usually “am I up to date?”. On Linux, Framework distributes BIOS and Embedded Controller (EC) updates through LVFS/fwupd, so you can check and apply them without a USB stick or Windows.

fwupd is preinstalled on Fedora and on Ubuntu desktop; if missing: sudo dnf install -y fwupd / sudo apt install -y fwupd.

# Refresh the metadata from LVFS, then list what fwupd sees:
sudo fwupdmgr refresh --force
fwupdmgr get-devices

Look for the System Firmware device — its Current version should match the 03.06 you read with dmidecode. Then ask LVFS whether anything newer is published:

fwupdmgr get-updates
fwupdmgr update          # only if you decide to flash — schedules the update on next reboot

Cross-reference the version and changelog against Framework’s official BIOS guide for your exact model (the per-model “BIOS releases” / “BIOS Guide” pages in the Framework Knowledge Base) before flashing. Not every Framework model ships every BIOS revision through LVFS yet — if fwupdmgr shows nothing while the Knowledge Base lists a newer version, the manual EFI-shell/Windows updater on Framework’s download page is the fallback.

Always plug in the charger before any firmware update. A BIOS/EC flash interrupted by a dead battery can brick the board.

Troubleshooting

/dev/mem: Operation not permitted or empty output — you’re not root; prefix with sudo, or use the sysfs path in step 5. On a Secure-Boot + lockdown kernel, raw /dev/mem access can be blocked entirely — sysfs and fwupd still work.
dmidecode: command not found even after install — it’s in /usr/sbin; call it as sudo dmidecode or /usr/sbin/dmidecode.
Version shown looks “wrong” / older than expected — DMI is populated at boot. If you just flashed, fully reboot (a suspend/resume won’t refresh the tables) and re-check.
Vendor: INSYDE Corp. surprises you — that’s normal for Framework. The OEM/system vendor is Framework (see sys_vendor / type 1); Insyde is only the firmware codebase.

Quick reference

# 1. Present?
command -v dmidecode || sudo dnf install -y dmidecode   # or: sudo apt install -y dmidecode

# 2. The version you came for
sudo dmidecode -s bios-version
sudo dmidecode -s bios-release-date

# 3. Full BIOS table + which machine/CPU it belongs to
sudo dmidecode -t bios
sudo dmidecode -t system -t processor

# 4. No root needed
cat /sys/class/dmi/id/bios_version

# 5. Up to date? (Framework via LVFS)
sudo fwupdmgr refresh --force && fwupdmgr get-updates