Conversation
Using the Ubuntu configuration on the test branch is a known good general starting point. This configuration will be pared down and refined in future commits in order to reduce build time while still retaining some degree of hardware flexibility for the test cluster. Signed-off-by: Edwin Peer <epeer@nvidia.com>
Signed-off-by: Edwin Peer <epeer@nvidia.com>
For convenience of the reader: now you can directly see the sizes of
each range. It is suprising just how much this helps.
Sample output (using an Ampere GA104):
NovaCore 0000:e1:00.0: FbLayout {
fb: 0x0..0x3ff800000 (16376 MB),
vga_workspace: 0x3ff700000..0x3ff800000 (1 MB),
frts: 0x3ff600000..0x3ff700000 (1 MB),
boot: 0x3ff5fa000..0x3ff600000 (0 MB),
elf: 0x3fb960000..0x3ff5f9000 (60 MB),
wpr2_heap: 0x3f3900000..0x3fb900000 (128 MB),
wpr2: 0x3f3800000..0x3ff700000 (191 MB),
heap: 0x3f3700000..0x3f3800000 (1 MB),
vf_partition_count: 0x0,
}
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
A tiny simplification: now that FbLayout uses its own specific FbRange type, add an FbRange.len() method, and use that to (very slightly) simplify the calculation of Frts::frts_size initialization. Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Hopper (GH100) and Blackwell identification, including ELF .fwsignature_* items. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
…tion() Keep Gsp::new() from getting too cluttered, by factoring out the selection of .fwsignature* items. This will continue to grow as we add GPUs. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Instead of long, exhaustive lists of GPUs ("Chipsets"), use entire
GPU Architectures, such as "Blackwell" or "Turing", to make HAL choices.
A tiny side effect: moved a "use" statement out of function scope, in
each file, up to the top of the file, as per Rust for Linux conventions.
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
As per [1], we need one "use" item per line, in order to reduce merge conflicts. Furthermore, we need a trailing ", //" in order to tell rustfmt(1) to leave it alone. This does that for commands.rs, which is the only file in nova-core that has any remaining instances of the old style. [1] https://docs.kernel.org/rust/coding-guidelines.html#imports Signed-off-by: John Hubbard <jhubbard@nvidia.com>
This removes a "TODO" item in the code, which was hardcoded to work on Ampere and Ada GPUs. Hopper/Blackwell+ have a larger width, so do an early read of boot42, in order to pick the correct value. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Up until now, only the GSP required parsing of its firmware headers. However, upcoming support for Hopper/Blackwell+ adds another firmware image (FMC), along with another format (ELF32). Therefore, the current ELF64 section parsing support needs to be moved up a level, so that both of the above can use it. There are no functional changes. This is pure code movement. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Factor out a chunk of complexity into a new subroutine. This is an incremental step in adding ELF32 support to the existing ELF64 section support, for handling GPU firmware. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Add ElfHeader and ElfSectionHeader traits to abstract out differences between ELF32 and ELF64. Implement these for ELF64. This is in preparation for upcoming ELF32 section support, and for auto-selecting ELF32 or ELF64. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Add Elf32Hdr and Elf32SHdr newtypes, implement the ElfHeader and ElfSectionHeader traits for them, and add elf32_section(). This mirrors the existing ELF64 support, using the same generic infrastructure. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Add elf_section() which checks the ELF magic and class byte to automatically dispatch to elf32_section() or elf64_section(). Update existing callers to use elf_section() instead of calling elf64_section() directly. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
…of FSP FSP is a hardware unit that runs FMC firmware. Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Add the FSP (Firmware System Processor) falcon engine type that will handle secure boot and Chain of Trust operations on Hopper and Blackwell architectures. The FSP falcon replaces SEC2's role in the boot sequence for these newer architectures. This initial stub just defines the falcon type and its base address. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Add external memory (EMEM) read/write operations to the GPU's FSP falcon engine. These operations use Falcon PIO (Programmed I/O) to communicate with the FSP through indirect memory access. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Add the FSP messaging infrastructure needed for Chain of Trust communication on Hopper/Blackwell GPUs. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Various "reserved" areas of FB (frame buffer: vidmem) have to be calculated, because the GSP booting process needs this information. The calculations are const, so a new const-compatible alignment function is also added to num.rs, in order to align the reserved areas. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Hopper, Blackwell and later need to reserve more memory than previous GPUs did. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Add the FSP (Firmware System Processor) module for Hopper/Blackwell GPUs.
These architectures use a simplified firmware boot sequence:
FMC --> FSP --> GSP, with no SEC2 involvement.
This commit adds the ability to wait for FSP secure boot completion by
polling the I2CS thermal scratch register until FSP signals success.
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Add the data structures for FSP Chain of Trust communication. These include the FMC signature container (hash, public key, signature) and the NVDM payload structures for sending COT messages and receiving responses. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Add extract_fmc_signatures_static() to parse cryptographic signatures from FMC ELF firmware sections. This extracts the SHA-384 hash, RSA public key, and signature needed for Chain of Trust verification. Also exposes the elf_section() helper from firmware.rs for use by FSP. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Add send_sync_fsp() which sends an MCTP/NVDM message to FSP and waits for the response. This handles the low-level protocol details including header validation, error checking, and timeout handling. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Add the boot functions that construct FMC boot parameters and send the Chain of Trust message to FSP. This completes the FSP communication infrastructure needed to boot GSP firmware on Hopper/Blackwell GPUs. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Hopper, Blackwell and later require more space for the non-WPR heap. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Hopper, Blackwell and later GPUs require a larger heap for WPR2. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Extract the SEC2 booter loading sequence into a dedicated helper function. This is a pure refactoring with no behavior change, done in preparation for adding an alternative FSP boot path. Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Hopper and Blackwell GPUs use FSP-based secure boot and do not require waiting for GFW_BOOT completion. Skip this step for these architectures. Signed-off-by: John Hubbard <jhubbard@nvidia.com>
ec59f53 to
fdea910
Compare
4be6b4c to
5fddb26
Compare
fc0344e to
b56cdcc
Compare
be6932a to
5ba69f3
Compare
Owner
Author
|
/build |
1 similar comment
Owner
Author
|
/build |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Applying John's patches for test