search for: fecs_sig

....bin | Bin 0 -> 10144 bytes nvidia/gm200/acr/ucode_unload.bin | Bin 0 -> 1440 bytes nvidia/gm200/gr/fecs_bl.bin | Bin 0 -> 576 bytes nvidia/gm200/gr/fecs_data.bin | Bin 0 -> 1968 bytes nvidia/gm200/gr/fecs_inst.bin | Bin 0 -> 16271 bytes nvidia/gm200/gr/fecs_sig.bin | Bin 0 -> 76 bytes nvidia/gm200/gr/gpccs_bl.bin | Bin 0 -> 576 bytes nvidia/gm200/gr/gpccs_data.bin | Bin 0 -> 2056 bytes nvidia/gm200/gr/gpccs_inst.bin | Bin 0 -> 9768 bytes nvidia/gm200/gr/gpccs_sig.bin | Bin 0 -> 76 bytes nvidia/gm200/gr/sw_...

...00/acr/ucode_load.bin | Bin 0 -> 9632 bytes nvidia/gp100/acr/ucode_unload.bin | Bin 0 -> 1440 bytes nvidia/gp100/gr/fecs_bl.bin | 1 + nvidia/gp100/gr/fecs_data.bin | Bin 0 -> 2028 bytes nvidia/gp100/gr/fecs_inst.bin | Bin 0 -> 20955 bytes nvidia/gp100/gr/fecs_sig.bin | Bin 0 -> 76 bytes nvidia/gp100/gr/gpccs_bl.bin | 1 + nvidia/gp100/gr/gpccs_data.bin | Bin 0 -> 2080 bytes nvidia/gp100/gr/gpccs_inst.bin | Bin 0 -> 12458 bytes nvidia/gp100/gr/gpccs_sig.bin | Bin 0 -> 76 bytes nvidia/gp100/gr/sw_bundle_init.bin...

...rks and fbconsole on VT1-VT6 works too. CONFIG_EXTRA_FIRMWARE="nvidia/gp104/gr/sw_nonctx.bin nvidia/gp104/gr/sw_ctx.bin nvidia/gp104/gr/sw_bundle_init.bin nvidia/gp104/gr/sw_method_init.bin nvidia/gp104/gr/fecs_bl.bin nvidia/gp104/gr/fecs_inst.bin nvidia/gp104/gr/fecs_data.bin nvidia/gp104/gr/fecs_sig.bin nvidia/gp104/gr/gpccs_bl.bin nvidia/gp104/gr/gpccs_inst.bin nvidia/gp104/gr/gpccs_data.bin nvidia/gp104/gr/gpccs_sig.bin nvidia/gp104/sec2/image.bin nvidia/gp104/sec2/desc.bin nvidia/gp104/sec2/sig.bin nvidia/gp104/acr/ucode_load.bin nvidia/gp104/acr/ucode_unload.bin nvidia/gp104/acr/bl.bin nvi...

...directly loaded. However for the current GR firmware we took the approach of splitting the bl, code and data sections into their own files, and building the image and descriptor on-the-fly, as you can see from gm200/gr: gm200/gr/fecs_bl.bin gm200/gr/fecs_data.bin gm200/gr/fecs_inst.bin gm200/gr/fecs_sig.bin The bl, data, and inst files are loaded and combined into an image while the corresponding descriptor is built. This is done in the ls_ucode_img_build() function. The main reason for doing this is there is that for a given GPU generation, the _bl and _inst files are very likely going to be...

...k the approach of splitting the bl, code and >> data sections into their own files, and building the image and descriptor >> on-the-fly, as you can see from gm200/gr: >> >> gm200/gr/fecs_bl.bin >> gm200/gr/fecs_data.bin >> gm200/gr/fecs_inst.bin >> gm200/gr/fecs_sig.bin >> >> The bl, data, and inst files are loaded and combined into an image while the >> corresponding descriptor is built. This is done in the ls_ucode_img_build() >> function. >> >> The main reason for doing this is there is that for a given GPU generation, &g...

...;> data sections into their own files, and building the image and descriptor >>>> on-the-fly, as you can see from gm200/gr: >>>> >>>> gm200/gr/fecs_bl.bin >>>> gm200/gr/fecs_data.bin >>>> gm200/gr/fecs_inst.bin >>>> gm200/gr/fecs_sig.bin >>>> >>>> The bl, data, and inst files are loaded and combined into an image while >>>> the >>>> corresponding descriptor is built. This is done in the >>>> ls_ucode_img_build() >>>> function. >>>> >>>&...

...>>>>> descriptor >>>>>> on-the-fly, as you can see from gm200/gr: >>>>>> >>>>>> gm200/gr/fecs_bl.bin >>>>>> gm200/gr/fecs_data.bin >>>>>> gm200/gr/fecs_inst.bin >>>>>> gm200/gr/fecs_sig.bin >>>>>> >>>>>> The bl, data, and inst files are loaded and combined into an image >>>>>> while >>>>>> the >>>>>> corresponding descriptor is built. This is done in the >>>>>> ls_ucode_img_...

...e current GR firmware we took the approach of splitting the bl, code and > data sections into their own files, and building the image and descriptor > on-the-fly, as you can see from gm200/gr: > > gm200/gr/fecs_bl.bin > gm200/gr/fecs_data.bin > gm200/gr/fecs_inst.bin > gm200/gr/fecs_sig.bin > > The bl, data, and inst files are loaded and combined into an image while the > corresponding descriptor is built. This is done in the ls_ucode_img_build() > function. > > The main reason for doing this is there is that for a given GPU generation, > the _bl and _inst fil...

...>>> and >>> data sections into their own files, and building the image and descriptor >>> on-the-fly, as you can see from gm200/gr: >>> >>> gm200/gr/fecs_bl.bin >>> gm200/gr/fecs_data.bin >>> gm200/gr/fecs_inst.bin >>> gm200/gr/fecs_sig.bin >>> >>> The bl, data, and inst files are loaded and combined into an image while >>> the >>> corresponding descriptor is built. This is done in the >>> ls_ucode_img_build() >>> function. >>> >>> The main reason for doing th...

...building the image and >>>>> descriptor >>>>> on-the-fly, as you can see from gm200/gr: >>>>> >>>>> gm200/gr/fecs_bl.bin >>>>> gm200/gr/fecs_data.bin >>>>> gm200/gr/fecs_inst.bin >>>>> gm200/gr/fecs_sig.bin >>>>> >>>>> The bl, data, and inst files are loaded and combined into an image >>>>> while >>>>> the >>>>> corresponding descriptor is built. This is done in the >>>>> ls_ucode_img_build() >>>>...

gp104 refuses to switch to "graphic" mode and show anything past this line: fb0: switching to nouveaufb from EFI VGA Machine is fine, as it I can press Ctrl+Alt+Delete and reboot it normally. 5.5 is OK. 5.6 is broken. Bisecting is kinda painful with miscompilation and init/main.c breakage. BTW do I need all those megabytes of firmware? [ 0.923273] fb0: switching to nouveaufb

https://bugs.freedesktop.org/show_bug.cgi?id=100567 Bug ID: 100567 Summary: Nouveau system freeze fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

...ad.bin"); +MODULE_FIRMWARE("nvidia/gm200/acr/ucode_unload.bin"); +MODULE_FIRMWARE("nvidia/gm200/gr/fecs_bl.bin"); +MODULE_FIRMWARE("nvidia/gm200/gr/fecs_inst.bin"); +MODULE_FIRMWARE("nvidia/gm200/gr/fecs_data.bin"); +MODULE_FIRMWARE("nvidia/gm200/gr/fecs_sig.bin"); +MODULE_FIRMWARE("nvidia/gm200/gr/gpccs_bl.bin"); +MODULE_FIRMWARE("nvidia/gm200/gr/gpccs_inst.bin"); +MODULE_FIRMWARE("nvidia/gm200/gr/gpccs_data.bin"); +MODULE_FIRMWARE("nvidia/gm200/gr/gpccs_sig.bin"); +MODULE_FIRMWARE("nvidia/gm200/gr/sw_...

Hi everyone, Apologies for the big patchset. This is a rework of the secure boot code that moves the building of the blob into its own set of source files (and own hooks), making the code more flexible and (hopefully) easier to understand as well. This rework is needed to support more signed firmware for existing and new chips. Since the firmwares in question are not available yet I cannot send

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

https://bugs.freedesktop.org/show_bug.cgi?id=101887 Bug ID: 101887 Summary: gtx 970 black screen Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

GP10B is the chip used in Tegra X2 SoCs. This patchset adds support for its base engines after reworking secboot a bit to accomodate its calling convention better. This patchset has been tested rendering simple off-screen buffers using Mesa and yielded the expected result. Alexandre Courbot (15): secboot: allow to boot multiple falcons secboot: pass instance to LS firmware loaders secboot: