EEPROM unsupported - rather failed to read out, because SFDP deviceID is unsupported
created a chain that causes wrong falcon version to be loaded, creates a chain that falcon can not do anything
~failure~
Soo the issue is the GopUpdater, how ever they control at target GOP package , falcon ID
Idk how.
But i've never seen this.
Or ....
It can be those small EEPROMs that 3090 FE's had - which where completely unsupported.
In any case, GOP loaded unknown falcon version, and GPU didnt know what to do ~ soo like a pyramid, everything failed past that.
No falcon, no flashing.
Very bizarre.
Can you try to find a bios on techpowerup with the same subsystem ID , pretty much a copy but with an earlier vbios version ?
Then try to normally flash that ?
I can not differentiate "strange foreign eeprom" vs "strange GOP that was not made for this device"
It can be that eeprom is pulled high and so is undetected till X. It's not uncommon.
omgvflash tried to detect it then as erased eeprom and still flash, but falcon could not be initialized as model detected for it simply was the wrong
Soo flash was halted as Falcon was halted and your flash command result in ~nothing~
Super bizarre, but i don't think it was nvflash's fault here.
I think it was the file reporting and requesting something strange.
We could also lean extremely far out of the window, put tinfoil hat's on
And say that GOP was expecting falcon v7, which didn't exist on current nvflash & nothing can be done
Any case, target falcon fw version was not found
Soo everything past that failed like a pyramid scheme ~ as it loaded falcon v4 for target SKU, but could not do anything because it targeted a strange new version.
Super bizarre.
No idea what's exactly going on. I would need to speak with the Dev, how he updated it and what he pulled.
But i blame the GOP for 75-80% , and strange eeprom as rather 20% chance ~ to be what's going on here.
I need more information about the card, to make up my mind
It wouldn't be unlikely that Nvidia™ proactively tries to prevent all options past their breach-accident and rewrite everything.
Although we don't work against them, it wouldn't honestly wonder me. Depends on GOP date and everything around it.
Update:
View attachment 311058
So indeed it can be the file maker that is to blame
and what happens is it roundrobin increasing version from ucode0-5 ~ still fails detection as interface is on another hub
Then falling back on SKU identification which is ucode4 , thinking eeprom is just erased hence failed detection ~ moving on but still failing.
Somebody needs to ping or pull GopUpdater dev
To change register in ROM to SPI1, from 0
or from 2 to 1
Very likely its that
Rom not recognizing EEPROM location, due to bug? useredit or due to strange too new (unfitting) GOP blob.
Nevertheless try to flash something else on your GPU - that is as close as possible , like a VBIOS downgrade or upgrade
@PanosX
Just to factcheck. Of course with -L log.txt
https://lore.kernel.org/lkml/abf7dc0e-df13-25ae-83b7-204eee0189d4@linaro.org/T/ SFDP is an interface for SPI lookup. // Serial Flash Discoverable Parameter