- 06 4月, 2017 1 次提交
-
-
由 Alexandre Courbot 提交于
Change the secboot and msgqueue interfaces to take a mask of falcons to reset instead of a single falcon. The GP10B firmware interface requires FECS and GPCCS to be booted in a single firmware command. For firmwares that only support single falcon boot, it is trivial to loop over the mask and boot each falcons individually. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 07 3月, 2017 2 次提交
-
-
由 Alexandre Courbot 提交于
On some secure boot instances (e.g. gp10x) the load and unload blobs do not run on the same falcon. Support this case by introducing a new member to the ACR structure and making related functions take the falcon to use as an argument instead of assuming the boot falcon is to be used. The rule is that the load blob can be run on either the SEC or PMU falcons, but the unload blob must be always run on PMU. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
Add support for running the ACR binary on the SEC falcon. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 17 2月, 2017 6 次提交
-
-
由 Alexandre Courbot 提交于
The WPR and LSB headers, used to generate the LS blob, may have a different layout and sizes depending on the driver version they come from. Abstract them and confine their use to driver-specific code. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
Split the act of building the ACR blob from firmware files from the rest of the (chip-dependent) secure boot logic. ACR logic is moved into acr_rxxx.c files, where rxxx corresponds to the compatible release of the NVIDIA driver. At the moment r352 and r361 are supported since firmwares have been released for these versions. Some abstractions are added on top of r352 so r361 can easily be implemented on top of it by just overriding a few hooks. This split makes it possible and easy to reuse the same ACR version on different chips. It also hopefully makes the code much more readable as the different secure boot logics are separated. As more chips and firmware versions will be supported, this is a necessity to not get lost in code that is already quite complex. This is a big commit, but it essentially moves things around (and split the nvkm_secboot structure into two, nvkm_secboot and nvkm_acr). Code semantics should not be affected. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
The init() hook is called by the subdev's oneinit(). Rename it accordingly to avoid confusion about the lifetime of objects allocated in it. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
Since GR has moved to using the falcon library to start the falcons, this function is not needed anymore. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
Use the falcon library functions in secure boot. This removes a lot of code and makes the secure boot flow easier to understand as no register is directly accessed. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
These functions should use the nvkm_secboot_falcon enum. Fix this. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 14 7月, 2016 3 次提交
-
-
由 Alexandre Courbot 提交于
Defer the loading of firmware files to the chip-specific part of secure boot. This allows implementations to retry loading firmware if the first attempt failed ; for the GM200 implementation, this happens when trying to reset a falcon, typically in reaction to GR init. Firmware loading may fail for a variety of reasons, such as the filesystem where they reside not being ready at init time. This new behavior allows GR to be initialized the next time we try to use it if the firmware has become available. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 20 5月, 2016 1 次提交
-
-
由 Ben Skeggs 提交于
These are now specified directly in the MC subdev. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 14 3月, 2016 1 次提交
-
-
由 Alexandre Courbot 提交于
On GM200 and later GPUs, firmware for some essential falcons (notably GR ones) must be authenticated by a NVIDIA-produced signature and loaded by a high-secure falcon in order to be able to access privileged registers, in a process known as Secure Boot. Secure Boot requires building a binary blob containing the firmwares and signatures of the falcons to be loaded. This blob is then given to a high-secure falcon running a signed loader firmware that copies the blob into a write-protected region, checks that the signatures are valid, and finally loads the verified firmware into the managed falcons and switches them to privileged mode. This patch adds infrastructure code to support this process on chips that require it. v2: - The IRQ mask of the PMU falcon was left - replace it with the proper irq_mask variable. - The falcon reset procedure expecting a falcon in an initialized state, which was accidentally provided by the PMU subdev. Make sure that secboot can manage the falcon on its own. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-