From: Joel Fernandes <joelagnelf@nvidia.com>
To: Danilo Krummrich <dakr@kernel.org>,
Alexandre Courbot <acourbot@nvidia.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Jonathan Corbet" <corbet@lwn.net>,
"John Hubbard" <jhubbard@nvidia.com>,
"Ben Skeggs" <bskeggs@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
"Shirish Baskaran" <sbaskaran@nvidia.com>
Subject: Re: [PATCH v3 16/19] nova-core: Add support for VBIOS ucode extraction for boot
Date: Tue, 20 May 2025 03:55:06 -0400 [thread overview]
Message-ID: <4fee85be-a8c5-4a99-8397-c93e79d72d15@nvidia.com> (raw)
In-Reply-To: <aCN_PIYEEzs73AqT@pollux>
Hi Danilo,
On 5/13/2025 1:19 PM, Danilo Krummrich wrote:
> On Wed, May 07, 2025 at 10:52:43PM +0900, Alexandre Courbot wrote:
>> From: Joel Fernandes <joelagnelf@nvidia.com>
>>
>> Add support for navigating and setting up vBIOS ucode data required for
>> GSP to boot. The main data extracted from the vBIOS is the FWSEC-FRTS
>> firmware which runs on the GSP processor. This firmware runs in high
>> secure mode, and sets up the WPR2 (Write protected region) before the
>> Booter runs on the SEC2 processor.
>>
>> Also add log messages to show the BIOS images.
>>
>> [102141.013287] NovaCore: Found BIOS image at offset 0x0, size: 0xfe00, type: PciAt
>> [102141.080692] NovaCore: Found BIOS image at offset 0xfe00, size: 0x14800, type: Efi
>> [102141.098443] NovaCore: Found BIOS image at offset 0x24600, size: 0x5600, type: FwSec
>> [102141.415095] NovaCore: Found BIOS image at offset 0x29c00, size: 0x60800, type: FwSec
>>
>> Tested on my Ampere GA102 and boot is successful.
>>
>> [applied changes by Alex Courbot for fwsec signatures]
>> [applied feedback from Alex Courbot and Timur Tabi]
>> [applied changes related to code reorg, prints etc from Danilo Krummrich]
>> [acourbot@nvidia.com: fix clippy warnings]
>> [acourbot@nvidia.com: remove now-unneeded Devres acquisition]
>> [acourbot@nvidia.com: fix read_more to read `len` bytes, not u32s]
>>
>> Cc: Alexandre Courbot <acourbot@nvidia.com>
>> Cc: John Hubbard <jhubbard@nvidia.com>
>> Cc: Shirish Baskaran <sbaskaran@nvidia.com>
>> Cc: Alistair Popple <apopple@nvidia.com>
>> Cc: Timur Tabi <ttabi@nvidia.com>
>> Cc: Ben Skeggs <bskeggs@nvidia.com>
>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>> drivers/gpu/nova-core/firmware.rs | 2 -
>> drivers/gpu/nova-core/gpu.rs | 3 +
>> drivers/gpu/nova-core/nova_core.rs | 1 +
>> drivers/gpu/nova-core/vbios.rs | 1147 ++++++++++++++++++++++++++++++++++++
>> 4 files changed, 1151 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/nova-core/firmware.rs b/drivers/gpu/nova-core/firmware.rs
>> index 1eb216307cd01d975b3d5beda1dc516f34b4b3f2..960982174d834c7c66a47ecfb3a15bf47116b2c5 100644
>> --- a/drivers/gpu/nova-core/firmware.rs
>> +++ b/drivers/gpu/nova-core/firmware.rs
>> @@ -80,8 +80,6 @@ pub(crate) struct FalconUCodeDescV3 {
>> _reserved: u16,
>> }
>>
>> -// To be removed once that code is used.
>> -#[expect(dead_code)]
>> impl FalconUCodeDescV3 {
>> pub(crate) fn size(&self) -> usize {
>> ((self.hdr & 0xffff0000) >> 16) as usize
>> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
>> index ece13594fba687f3f714e255b5436e72d80dece3..4bf7f72247e5320935a517270b5a0e1ec2becfec 100644
>> --- a/drivers/gpu/nova-core/gpu.rs
>> +++ b/drivers/gpu/nova-core/gpu.rs
>> @@ -9,6 +9,7 @@
>> use crate::firmware::Firmware;
>> use crate::regs;
>> use crate::util;
>> +use crate::vbios::Vbios;
>> use core::fmt;
>>
>> macro_rules! define_chipset {
>> @@ -238,6 +239,8 @@ pub(crate) fn new(
>>
>> let _sec2_falcon = Falcon::<Sec2>::new(pdev.as_ref(), spec.chipset, bar, true)?;
>>
>> + let _bios = Vbios::new(pdev, bar)?;
>
> Please add a comment why, even though unused, it is important to create this
> instance.
>
> Also, please use `_` if it's not intended to ever be used.
If I add a comment, it will simply be removed by the next patch. I can add that
though so it makes it more clear.
[...]
>> +impl<'a> Iterator for VbiosIterator<'a> {
>> + type Item = Result<BiosImage>;
>> +
>> + /// Iterate over all VBIOS images until the last image is detected or offset
>> + /// exceeds scan limit.
>> + fn next(&mut self) -> Option<Self::Item> {
>> + if self.last_found {
>> + return None;
>> + }
>> +
>> + if self.current_offset > BIOS_MAX_SCAN_LEN {
>> + dev_err!(
>> + self.pdev.as_ref(),
>> + "Error: exceeded BIOS scan limit, stopping scan\n"
>> + );
>> + return None;
>> + }
>> +
>> + // Parse image headers first to get image size
>> + let image_size = match self
>> + .read_bios_image_at_offset(
>> + self.current_offset,
>> + BIOS_READ_AHEAD_SIZE,
>> + "parse initial BIOS image headers",
>> + )
>> + .and_then(|image| image.image_size_bytes())
>> + {
>> + Ok(size) => size,
>> + Err(e) => return Some(Err(e)),
>> + };
>> +
>> + // Now create a new BiosImage with the full image data
>> + let full_image = match self.read_bios_image_at_offset(
>> + self.current_offset,
>> + image_size,
>> + "parse full BIOS image",
>> + ) {
>> + Ok(image) => image,
>> + Err(e) => return Some(Err(e)),
>> + };
>> +
>> + self.last_found = full_image.is_last();
>> +
>> + // Advance to next image (aligned to 512 bytes)
>> + self.current_offset += image_size;
>> + self.current_offset = self.current_offset.align_up(512);
>> +
>> + Some(Ok(full_image))
>> + }
>> +}
>> +
>> +pub(crate) struct Vbios {
>> + pub fwsec_image: Option<FwSecBiosImage>,
>
> Please use pub(crate) instead or provide an accessor.
>
> Also, this shouldn't be an Option, see below comment in Vbios::new().
Ok, I just removed pub altogether, since the users all within this module.
>> +}
>> +
>> +impl Vbios {
>> + /// Probe for VBIOS extraction
>> + /// Once the VBIOS object is built, bar0 is not read for vbios purposes anymore.
>> + pub(crate) fn new(pdev: &pci::Device, bar0: &Bar0) -> Result<Vbios> {
>> + // Images to extract from iteration
>> + let mut pci_at_image: Option<PciAtBiosImage> = None;
>> + let mut first_fwsec_image: Option<FwSecBiosImage> = None;
>> + let mut second_fwsec_image: Option<FwSecBiosImage> = None;
>> +
>> + // Parse all VBIOS images in the ROM
>> + for image_result in VbiosIterator::new(pdev, bar0)? {
>> + let full_image = image_result?;
>> +
>> + dev_info!(
>
> Let's use dev_dbg!() instaed.
Done.
>
>> + pdev.as_ref(),
>> + "Found BIOS image: size: {:#x}, type: {}, last: {}\n",
>> + full_image.image_size_bytes()?,
>> + full_image.image_type_str(),
>> + full_image.is_last()
>> + );
>> +
>> + // Get references to images we will need after the loop, in order to
>> + // setup the falcon data offset.
>> + match full_image {
>> + BiosImage::PciAt(image) => {
>> + pci_at_image = Some(image);
>> + }
>> + BiosImage::FwSec(image) => {
>> + if first_fwsec_image.is_none() {
>> + first_fwsec_image = Some(image);
>> + } else {
>> + second_fwsec_image = Some(image);
>> + }
>> + }
>> + // For now we don't need to handle these
>> + BiosImage::Efi(_image) => {}
>> + BiosImage::Nbsi(_image) => {}
>> + }
>> + }
>> +
>> + // Using all the images, setup the falcon data pointer in Fwsec.
>> + // We need mutable access here, so we handle the Option manually.
>> + let final_fwsec_image = {
>> + let mut second = second_fwsec_image; // Take ownership of the option
>> +
>> + if let (Some(second), Some(first), Some(pci_at)) =
>> + (second.as_mut(), first_fwsec_image, pci_at_image)
>> + {
>> + second
>> + .setup_falcon_data(pdev, &pci_at, &first)
>> + .inspect_err(|e| {
>> + dev_err!(pdev.as_ref(), "Falcon data setup failed: {:?}\n", e)
>> + })?;
>> + } else {
>> + dev_err!(
>> + pdev.as_ref(),
>> + "Missing required images for falcon data setup, skipping\n"
>> + );
>> + return Err(EINVAL);
>
> This means that if second == None we fail, which makes sense, so why store an
> Option in Vbios? All methods of Vbios fail if fwsec_image == None.
>
Well, if first and pci_at are None, we will fail as well. Not just second. But
we don't know until we finish parsing all the images in the prior loop, if we
found all the images. So we store it as Option during the prior loop, and check
it later. Right?
>> + }
>> + second
>> + };
>
> I think this should be:
>
> let mut second = second_fwsec_image;
>
> if let (Some(second), Some(first), Some(pci_at)) =
> (second.as_mut(), first_fwsec_image, pci_at_image)
> {
> second
> .setup_falcon_data(pdev, &pci_at, &first)
> .inspect_err(|e| {
> dev_err!(pdev.as_ref(), "Falcon data setup failed: {:?}\n", e)
> })?;
>
> Ok(Vbios(second)
> } else {
> dev_err!(
> pdev.as_ref(),
> "Missing required images for falcon data setup, skipping\n"
> );
>
> Err(EINVAL)
> }
>
> where Vbios can just be
>
> pub(crate) struct Vbios(FwSecBiosImage);
But your suggestion here still considers second as an Option? That's why you
wrote 'Some(second)' ?
>
>> +
>> + Ok(Vbios {
>> + fwsec_image: final_fwsec_image,
>> + })
>> + }
>> +
>> + pub(crate) fn fwsec_header(&self, pdev: &device::Device) -> Result<&FalconUCodeDescV3> {
>> + let image = self.fwsec_image.as_ref().ok_or(EINVAL)?;
>> + image.fwsec_header(pdev)
>> + }
>> +
>> + pub(crate) fn fwsec_ucode(&self, pdev: &device::Device) -> Result<&[u8]> {
>> + let image = self.fwsec_image.as_ref().ok_or(EINVAL)?;
>> + image.fwsec_ucode(pdev, image.fwsec_header(pdev)?)
>> + }
>> +
>> + pub(crate) fn fwsec_sigs(&self, pdev: &device::Device) -> Result<&[u8]> {
>> + let image = self.fwsec_image.as_ref().ok_or(EINVAL)?;
>> + image.fwsec_sigs(pdev, image.fwsec_header(pdev)?)
>> + }
>
> Those then become infallible, e.g.
>
> pub(crate) fn fwsec_sigs(&self, pdev: &device::Device) -> &[u8] {
> self.0.fwsec_sigs(pdev, self.fwsec_header(pdev))
> }
>
Nope, I think you are wrong there. fwsec_sigs() of the underlying .0 returns a
Result.
Also in Vbios::new(), I extract the Option when returning:
Ok(Vbios {
fwsec_image: final_fwsec_image.ok_or(EINVAL)?,
})
But fwsec_header() still has to return a Result:
pub(crate) fn fwsec_header(&self, pdev: &device::Device) ->
Result<FalconUCodeDescV3> {
self.fwsec_image.fwsec_header(pdev)
}
thanks,
- Joel
next prev parent reply other threads:[~2025-05-20 7:55 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-07 13:52 [PATCH v3 00/19] nova-core: run FWSEC-FRTS to perform first stage of GSP initialization Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 01/19] rust: dma: expose the count and size of CoherentAllocation Alexandre Courbot
2025-05-13 12:15 ` Danilo Krummrich
2025-05-07 13:52 ` [PATCH v3 02/19] gpu: nova-core: derive useful traits for Chipset Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 03/19] gpu: nova-core: add missing GA100 definition Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 04/19] gpu: nova-core: take bound device in Gpu::new Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 05/19] gpu: nova-core: define registers layout using helper macro Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 06/19] gpu: nova-core: fix layout of NV_PMC_BOOT_0 Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 07/19] gpu: nova-core: move Firmware to firmware module Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 08/19] rust: make ETIMEDOUT error available Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 09/19] gpu: nova-core: wait for GFW_BOOT completion Alexandre Courbot
2025-05-13 14:07 ` Danilo Krummrich
2025-05-16 12:16 ` Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 10/19] gpu: nova-core: add DMA object struct Alexandre Courbot
2025-05-13 14:25 ` Danilo Krummrich
2025-05-07 13:52 ` [PATCH v3 11/19] gpu: nova-core: register sysmem flush page Alexandre Courbot
2025-05-13 14:47 ` Danilo Krummrich
2025-05-07 13:52 ` [PATCH v3 12/19] gpu: nova-core: add helper function to wait on condition Alexandre Courbot
2025-05-13 14:50 ` Danilo Krummrich
2025-05-07 13:52 ` [PATCH v3 13/19] gpu: nova-core: add falcon register definitions and base code Alexandre Courbot
2025-05-13 16:19 ` Danilo Krummrich
2025-05-16 12:19 ` Alexandre Courbot
2025-05-16 12:26 ` Danilo Krummrich
2025-05-07 13:52 ` [PATCH v3 14/19] gpu: nova-core: firmware: add ucode descriptor used by FWSEC-FRTS Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 15/19] rust: num: Add an upward alignment helper for usize Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 16/19] nova-core: Add support for VBIOS ucode extraction for boot Alexandre Courbot
2025-05-13 17:19 ` Danilo Krummrich
2025-05-20 7:55 ` Joel Fernandes [this message]
2025-05-20 9:30 ` Danilo Krummrich
2025-05-20 13:43 ` Joel Fernandes
2025-05-20 15:01 ` Danilo Krummrich
2025-05-20 15:11 ` Joel Fernandes
2025-05-20 15:36 ` Danilo Krummrich
2025-05-20 16:02 ` Joel Fernandes
2025-05-20 18:13 ` Joel Fernandes
2025-05-20 21:32 ` Dave Airlie
2025-05-21 3:17 ` Joel Fernandes
2025-05-14 16:23 ` Danilo Krummrich
2025-05-19 22:59 ` Joel Fernandes
2025-05-20 7:18 ` Joel Fernandes
2025-05-16 20:38 ` Timur Tabi
2025-05-20 6:35 ` Joel Fernandes
2025-05-07 13:52 ` [PATCH v3 17/19] gpu: nova-core: compute layout of the FRTS region Alexandre Courbot
2025-05-13 16:41 ` Danilo Krummrich
2025-05-17 13:42 ` Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 18/19] gpu: nova-core: extract FWSEC from BIOS and patch it to run FWSEC-FRTS Alexandre Courbot
2025-05-14 16:38 ` Danilo Krummrich
2025-05-19 14:24 ` Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 19/19] gpu: nova-core: load and " Alexandre Courbot
2025-05-14 16:42 ` Danilo Krummrich
2025-05-13 13:10 ` [PATCH v3 00/19] nova-core: run FWSEC-FRTS to perform first stage of GSP initialization Danilo Krummrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4fee85be-a8c5-4a99-8397-c93e79d72d15@nvidia.com \
--to=joelagnelf@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bskeggs@nvidia.com \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sbaskaran@nvidia.com \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).