A path to supply the nvflash with maybe an auto downloader/compiler (linux) for public nvflash & modified // this includes working on a patch-file like you wanted early on
. An nvflash downloader/patcher. I will not distribute nvflash itself, but I will distribute patchfiles within nvflashk (or whatever I call it) which can patch versions you provide.
Uh ?
Yes yes, go for a patch file if you are able to offset this.
Better for the longevity - and less maintenance.
You do not plan to keep it open as a path , do you ?
Everyone who works on the nvidia project at any time can disappear
I hope the GUI has several fallback options, and doesn't only rely to be hosted on github.
I do also hope that its codebase doesn't remain closed source.
Just speaking out of the past, the amount of threads and projects that vanished from the net and archives.
Be it by the dev themselves.
I started from scratch instead of using the old C# editors
hm ?
3. Safer flashing mechanisms.
Define "safe".
The safe-procedure is handled by Falcon.
Users guardkeeping adds layers of security which turn into an obstacle once user abandons the project or X company puts money in their pocket.
Unsure what layer of security to add, ontop of currently existing ones by the NV devs
Its not like you'd want to remake the whole flashing procedure and input checks that already exist. That's too much work.
A compatibility scoring system based on the reported success of others and BIOS version matching
Needs a database no ?
Please no telemetry tracking or online persistency.
Auto backup and auto restore. If you can POST but have no graphics, it will auto-flash back to the original GPU upon logging in if you not confirm success. (Think of what Windows does when you change resolution).
Indeed telemetry and persistency . Please give an opt-out of this. Boardvendors WPBT spyware is enough.
You can make it easier ~ on CID rebrands (if ever) you simply lose the output, as past a flash falcon will soft reboot the card.
This includes matrix i/o missmatches.
There mid procedure, well past flash pre reboot - can be noticed and tracked.
Shouldnt be too much work, nor be able to be titled as persistent spyware.
Good idea, but downsides exist.
Indeed telemetry and persistency . Please give an opt-out of this.
With your idea, another flaw is - that you can not restore the card itself ~ once UEFI detects it as softbricked.
Like S.M.A.R.T ~ it will refuse to init, nor be mapped out in ACPI table.
Your tool will then wait to reflash it , and actually reflash the first (backup) card that you input.
// as you have to use a known-good card to restore your bad card which is moved to another slot aka index
Sure you can add even more checks - but this bloats code, is complicated for identification, and going around a problem that shouldn't be created in the first place.
Having a persistent tracking + reflash
Is 6/7 points a trouble cause and will not help at all.
Tracking card reinit ability past falcon's reboot , past the flash
is a not bad idea ~ but on the other points , it is simply not gonna work out.
Now aside that nobody wants even more autostart programs' or services. Let alone Ring0/1 kernels.
EDIT ~ Why it also won't work Part2:
Outside if having basic Post (Init) issues past the flash
Outside of having TPM as variable past a flash (2 stage flash)
A soft-bricked card will never init.
On ACPI table, a Card will take over/replace the same anchor point that the previous card had
You can probe it, sure ~ but a restore ability past flash , is worthless
It will only ask for bugs
Sure there is a method, but it costs you kinda (wasted) time, to implement checks, against , well - basically not a functionality that will work out
A bricked card will not init
The only place to repair it, is pre flash , past flash - pre reboot
Past a reboot its too late.
On a flash, that causes a blackscreen - you don't have that much time either, before the OS shuts down
But you do have a chance to catch it before system shuts down.
