Documentation/gpu/nova/core/vbios.rst

Source file repositories/reference/linux-study-clean/Documentation/gpu/nova/core/vbios.rst

File Facts

System
Linux kernel
Corpus path
Documentation/gpu/nova/core/vbios.rst
Extension
.rst
Size
15330 bytes
Lines
241
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)

==========
VBIOS
==========
This document describes the layout of the VBIOS image which is a series of concatenated
images in the ROM of the GPU. The VBIOS is mirrored onto the BAR 0 space and is read
by both Boot ROM firmware (also known as IFR or init-from-rom firmware) on the GPU to
bootstrap various microcontrollers (PMU, SEC, GSP) with critical initialization before
the driver loads, as well as by the nova-core driver in the kernel to boot the GSP.

The format of the images in the ROM follow the "BIOS Specification" part of the
PCI specification, with Nvidia-specific extensions. The ROM images of type FwSec
are the ones that contain Falcon ucode and what we are mainly looking for.

As an example, the following are the different image types that can be found in the
VBIOS of an Ampere GA102 GPU which is supported by the nova-core driver.

- PciAt Image (Type 0x00) - This is the standard PCI BIOS image, whose name
  likely comes from the "IBM PC/AT" architecture.

- EFI Image (Type 0x03) - This is the EFI BIOS image. It contains the UEFI GOP
  driver that is used to display UEFI graphics output.

- First FwSec Image (Type 0xE0) - The first FwSec image (Secure Firmware)

- Second FwSec Image (Type 0xE0) - The second FwSec image (Secure Firmware)
  contains various  microcodes (also known as an applications) that do a range
  of different functions. The FWSEC ucode is run in heavy-secure mode and
  typically runs directly on the GSP (it could be running on a different
  designated processor in future generations but as of Ampere, it is the GSP).
  This firmware then loads other firmware ucodes onto the PMU and SEC2
  microcontrollers for gfw initialization after GPU reset and before the driver
  loads (see devinit.rst). The DEVINIT ucode is itself another ucode that is
  stored in this ROM partition.

Once located, the Falcon ucodes have "Application Interfaces" in their data
memory (DMEM). For FWSEC, the application interface we use for FWSEC is the
"DMEM mapper" interface which is configured to run the "FRTS" command. This
command carves out the WPR2 (Write-Protected Region) in VRAM. It then places
important power-management data, called 'FRTS', into this region. The WPR2
region is only accessible to heavy-secure ucode.

.. note::
   It is not clear why FwSec has 2 different partitions in the ROM, but they both
   are of type 0xE0 and can be identified as such. This could be subject to change
   in future generations.

IFR Header
----------
On Kepler and later GPUs, the ROM begins with an Init-from-ROM (IFR) header
rather than a standard PCI ROM signature (0xAA55). The driver must parse the
IFR header to find where the PCI ROM images actually start.

Init-from-ROM (IFR) is a special GPU feature used for power management
on some Nvidia GPUs.  It references data in the VBIOS for its operation,
but for drivers the important piece is a header that precedes the
VBIOS PCI Expansion ROM.

Most such GPUs do not need to parse the IFR header in order to find the
VBIOS, but the Nvidia GA100 is the exception.  GA100 lacks a display engine,
so the PRAMIN method (which reads the VBIOS from VRAM via display hardware)
is unavailable, forcing the driver to read the ROM directly via PROM.
On other similar GPUs, either PRAMIN succeeds before PROM is tried, or the
IFR hardware has already applied the ROM offset so that PROM reads
transparently skip the IFR header.

The driver should first check for the standard 0xAA55 signature at offset 0.
If found, there is no IFR header and the PCI ROM images start at
offset 0. If not found, check for the IFR signature and parse the header to

Annotation

Implementation Notes