similar to: demmio

On Tue, Dec 2, 2014 at 8:38 AM, poma <pomidorabelisima at gmail.com> wrote: > Is this expected result for Chipset: G98 (NV98)? Yep, 100% expected. [Perhaps you might glance at the wiki page you got that from for clues as to why.] > > $ modinfo nvidia -F version > 304.123 > > $ stat -c %s mmiotrace.log > 134659197 > > $ file mmiotrace.log > mmiotrace.log: ASCII

On 02.12.2014 14:40, Ilia Mirkin wrote: > On Tue, Dec 2, 2014 at 8:38 AM, poma <pomidorabelisima at gmail.com> wrote: >> Is this expected result for Chipset: G98 (NV98)? > > Yep, 100% expected. [Perhaps you might glance at the wiki page you got > that from for clues as to why.] > "You basically never need to do the mmiotrace, unless you're a nouveau

Hello everyone, GM20B is the GPU of the upcoming Tegra X1 SoC. This series adds initial support for it, based on a rework of the already-supported GK20A. It also introduces support for NVIDIA-provided firmware files, which is why I have added a few NVIDIA people who are relevant to this discussion. The first patch adds support for loading the FECS and GPCCS firmwares from firmware files

Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path if they cannot be found in the new, "official" path. User setups were broken by the switch, which is bad. There are only 4 firmware files we may want to look up that way, so hardcode them into the lookup function. All new firmware files should use the standard "nvidia/<chip>/gr/" path.

Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path if they cannot be found in the new, "official" path. User setups were broken by the switch, which is bad. There are only 4 firmware files we may want to look up that way, so hardcode them into the lookup function. All new firmware files should use the standard "nvidia/<chip>/gr/" path.

This was the first step of the secure boot refactoring - as Ben asked for some fixes, I now submit it as its own series to make it easier to review (and also because rebasing secure boot on top of this takes time and I don't want to do it until this is validated!). This series attempts to factorize the duplicate falcon-related code into a single library, using the existing nvkm_falcon

On 11/02/2016 02:07 PM, Ilia Mirkin wrote: > On Wed, Nov 2, 2016 at 12:54 AM, Alexandre Courbot <acourbot at nvidia.com> wrote: >> Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path >> if they cannot be found in the new, "official" path. User setups were >> broken by the switch, which is bad. >> >> There are only 4

This was the first step of the secure boot refactoring - as Ben asked for some fixes, I now submit it as its own series to make it easier to review (and also because rebasing secure boot on top of this takes time and I don't want to do it until this is validated!). This series attempts to factorize the duplicate falcon-related code into a single library, using the existing nvkm_falcon

Second version of this patchset. Not many changes since first version - I hope this means the changes are not too controversial. Changes since v1: - Removed lookup for previous FW files in "nouveau/" - Went back to using request_firmware() since we only try to load one file Original cover letter follows: GM20B is the GPU of the upcoming Tegra X1 SoC. This series adds initial support

New version of the secure boot code that works with the blobs just merged into linux-firmware. Since the required Mesa patches are also merged, this set is the last piece of the puzzle to get out-of-the-box accelerated Maxwell 2. The basic code remains the same, with a few improvements with respect to how secure falcons are started. Hopefully the patchset is better split too. I have a

On 19 June 2015 at 00:47, Alexandre Courbot <gnurou at gmail.com> wrote: > NVIDIA will officially start providing signed firmwares through > linux-firmware. Change the GR firmware lookup function to look them up > in addition to the extracted firmwares. I wonder if perhaps we should just replace the mechanism entirely, and remove the support for nouveau/fuc* as we add

Any comments? I also think for developers, it's good to be able to see from someone's dmesg output whether or not external firmware was loaded. Unless there is some other way to do that without this log message? -- Dan On Sep 17, 2016, at 02:04 AM, Dan Moulding <dmoulding at me.com> wrote: In previous versions, it used to log an info message when loading external GR firmware. But

This is a highly changed revision of the first patch series that adds secure boot support to Nouveau. This code still depends on NVIDIA releasing official firmware files, but the files released with SHIELD TV and Pixel C can already be used on a Jetson TX1. As you know we are working hard to release the official firmware files, however in the meantime it doesn't hurt to review the code so it

This series fixes two cases where behavior on secure boot errors could be improved: 1) Patch 2 propages secure-boot errors from GR init, making sure initialization fails as it should. Failure to do so results in a black screen during boot, as reported in FD bug 94990. 2) Patches 3-4 make the absence of required secure firmware files a non-fatal error. The previous behavior was to give up

On Fri, Nov 04, 2016 at 06:36:17PM +0900, Alexandre Courbot wrote: > Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path > if they cannot be found in the new, "official" path. User setups were > broken by the switch, which is bad. > > There are only 4 firmware files we may want to look up that way, so > hardcode them into the lookup

On Wed, Nov 2, 2016 at 12:54 AM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path > if they cannot be found in the new, "official" path. User setups were > broken by the switch, which is bad. > > There are only 4 firmware files we may want to look up that way, so > hardcode them

On 25/08/2014 20:58, Christian Costa wrote: > --- > rnndb/memory/nvc0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++--- > 1 file changed, 34 insertions(+), 3 deletions(-) > > diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml > index 500cea9..e006dbe 100644 > --- a/rnndb/memory/nvc0_pbfb.xml > +++ b/rnndb/memory/nvc0_pbfb.xml > @@ -49,23 +49,54 @@

On Tue, Dec 2, 2014 at 8:50 AM, poma <pomidorabelisima at gmail.com> wrote: > On 02.12.2014 14:40, Ilia Mirkin wrote: >> On Tue, Dec 2, 2014 at 8:38 AM, poma <pomidorabelisima at gmail.com> wrote: >>> Is this expected result for Chipset: G98 (NV98)? >> >> Yep, 100% expected. [Perhaps you might glance at the wiki page you got >> that from for clues as

On 02.12.2014 14:52, Ilia Mirkin wrote: > On Tue, Dec 2, 2014 at 8:50 AM, poma <pomidorabelisima at gmail.com> wrote: >> On 02.12.2014 14:40, Ilia Mirkin wrote: >>> On Tue, Dec 2, 2014 at 8:38 AM, poma <pomidorabelisima at gmail.com> wrote: >>>> Is this expected result for Chipset: G98 (NV98)? >>> >>> Yep, 100% expected. [Perhaps you

On 11/02/2016 03:52 PM, Alexandre Courbot wrote: > On 11/02/2016 02:07 PM, Ilia Mirkin wrote: >> On Wed, Nov 2, 2016 at 12:54 AM, Alexandre Courbot <acourbot at nvidia.com> wrote: >>> Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path >>> if they cannot be found in the new, "official" path. User setups were >>>