If a tool exists that is forced to bypass options ~ like modify Falcon, even if its not nvlfash's work;
Then it will get taken down. Sad for the community, but community often doesn't care.
If i publish how to talk with falcon or let alone reflash, outside of above , i get in trouble. Community still wouldn't care.
// code exists to respond a talk with falcon, no code exists to modify falcon. Neither drivers nor programming tools.
The tool forces a flash and bypasses ROM check on the card you currently run.
Without this ability, nvflash is weak. Without this ability only engineering cards got full access with engineering roms inside.
Tool's work is to check host, set permissions, check file, set permissions, send to falcon and request flash.
Nvflash's work is not to command falcon. It's work is to talk with it IF you pass all checks beforehand.
All checks beforehand are lifted, but i know i forgot file checksum check. This is not so bad, as bad file integrity won't ever boot.
Files with bad header/bottom do flash, but result in code 43. This is ok how it is. It gives secureness on the user not bricking their card upon user-error.
There are couple of improvements i need to work on. An update will be pushed once they are done.
Just want to remind - the tolerance level is small. I know what to do and what i should not do.
The ability to work on modding is given. It is on you guys to make a Viewer & Editor for not messing up file-integrity.
And it is on you guys to explore falcon. Ability exists ~ but it will not come from me
1000-2000 Series fail, because you don't supply a correct file. Not because nvflash limits.
3000-4000 Series fail on CID rebrands because falcon denies you. Not because nvflash limits.
What tool also can do, is lift SW Protection forced by Falcon due to new bioses.
This lock is not bypassable even with official signed bioses. And SPI flash is again not a full flash.
Some EEPROMs and versions make still issues and bugs are to fix ~ but main post stays true to its words.
I should soon rewrite it slightly, with a bugfixed version. To make it read & follow better.
It was never pretendet to be. Falcon edit is one way and blows fuse.
Falcon modification is not done via nvflash at all.
Hex editing is the way to go for everything, unless you can compile the source. Sorry i dont understand.
Again big claims, no contribution.
Not nvflash's work.
Tool here already sends full flash command , if you pass the very basic file integrity check i forgot to remove.
1000/2000 is not cert locked, so it's not tools flaw that falcon denies you.
Just not it's work.
I don't know how else to explain, i'm sorry.
It never was its work. A flash is a multi-stage procedure.
You potentially can create software that jumps and forces flash.
But then you can call it the GPU-Brick flasher.
Just because one can write "anything" to GPU, doesn't mean it will even turn on.
This ideology also slows down research, because user doesn't know if file will ever boot.
I think i set the foundation right, its on the community to continue work.
if falcon denies your rom-edit, so it is
File integrity checks exist for good.
Maybe less good if nvflash expects engineers to use it, but access to mostly-full nvflash is given now.
I will consider what we need and not need for the next update. For sure bug fixing some incompatible cards.
EDIT:
You guys make a viewer & editor (from 1000-4000 series)
~ then on successful Pascal/Turing flash with current edition, i will consider opening it up slightly more & fix CID rebrand issues.
It currently makes no sense to help you brick your GPUs. Force flash files that will fail to boot, is ~ embarrassing
Also, as long as secret is not out ~ i can not help. I can not talk about things that are not my own findings.
You guys figure out why flashing fails and i'll make sure to be there for you ~ assisting with more flash ability