Problema Corona v6 + Squirt 1.2 + fix R1R1

Ciao a tutti, vi elenco la situazione:
- Corona v6 , NAND SKHynix, RAM Samsung, Dash originaria 16547
- Squirt 1.2 (purtroppo non ho altro ed il proprietario ha fretta...), sfv minusone_nr tramite AutoGG 0.9.4 rev88
- postfix adapter TX v2
- Xell avviato dopo 3 glitch
- recuperati dati univoci
- creata Nand Mod (17489) con AutoGG come glitch2m
- scrittura NAND corretta
- reset 55cm, avvolto come in foto
- post saldato sul punto zero dell'adapter
- settaggio condensatore @ 220pF

Misure live:
- 3v3 3.26V
- SDA 3.25
- SCL 3.24
- POST 1.80 (che va a 0.00 al momento opportuno)
- CPU_RST 1.80 (che va a 0.00 al momento opportuno)

Finchè la console era aperta,anche con l'adattatore fakeSD collegato,con o senza HDD interno (aggiunto uno da 1TB), con o senza lettore DVD,
bootava circa 6 volte su 10 entro il 4° tentativo di glitch, se andava oltre il 4° si impallava (nessun altro tentativo di glitch,debug led
spento e sentivo bene il ronzio continuo della ventola),spegnendola dal tasto power lo stesso rimaneva acceso ed a volte riavviandola senza
scollegare l'alimentatore ripartiva con boot "rapido" entro i primi 4.
Pensando che fosse accettabile per una Corona v6,ho chiuso la console,tranne i pannelli superiore ed inferiore, e non ha più bootato,arrivando al 4° o 5° glitch si è sempre impallata.
Ho letto qualche discussione sul nostro forum, in particolare molte che rimandano a questa
http://www.consoleopen.com/forum/sez...-nuove-v6.html
ed ho applicato qualche correzione :

- fix R1R1, sia dissaldandola che collegando il contatto consigliato a GND (il GND + vicino possibile), il debug led lampeggia in maniera diversa,lampi di durata più rapida (meno di un secondo) e non si sente alcun sibilo dalla ventola (strano,la casistica rientrava provo in quella discussione ma nel mio caso non funziona :(

- CPU_RST provato anche su CPU_RST_R
- cambio verso di avvolgimento del CPU_RST
- cambio lunghezza CPU_RST
- eliminato secondo GND a destra,che incrociava il cavo del POST
- settaggio capacità @ 270, 242 e 292

Cercando di capire dove si nasconde il problema,correggetemi se sbaglio...il principio di funzionamento del glitch-chip è:monitorare il codice post x capire quando rallentare il clock tramite SCL e poi sparare il glitch tramite SDA (e se non va bene resettare la cpu con CPU_RST)?
In particolare, come mai secondo voi quando applico il fix R1R1 il glitchip non sembra più operare correttamente?

p.s. il setting della capacità sullo squirt l'ho fatto successivamente alla foto, ed ho dissaldato la qsb

Allegato 19901Allegato 19900

Il fix del r1r1 lo hai fatto, quindi concentrati prima sul chip , ponticella il pad slim tanto per cominiare, e poi abilita 220pf , e provi.
Quel nastro isolante sul punto del post , non e' il massimo....

Se posso...
Pur avendo ram samsung, puoi provare a flashare il freeboot con patch per corona v6 WB; tempo fa ho risolto così problemi di instabilità su una corona v6 del 2014 con ram non Winbond.

Allegato 19904

Rimane il fatto che quello squirt senza ponte su slim e nemmeno un cap attivato e' da sistemare, poi si ragiona anche sul freboot....
comunque si, e' un problema tipico delle v6
Nahhhhh .... io fo esattamente come lui con squirt, non cambia nulla il ponte slim perche' di default prende la 1.8V. Senza cap con plusone va benone su alcune, io proverei fare un FB con glitch2m

Il setting va benone, anche senza cap e ponticello tanto prende la 1.8V di default. Prova a fare un FB con glitch2m :)

Grazie dell'intervento ragazzi!
@Tommino81 : il ponte su slim ed il setting delle capacità l'ho fatto successivamente alla foto (come ho scritto a fine messaggio), provando 220, 270, 242 e 292.
Il nastro isolante l'ho messo per far seguire al filo del postfix il bordo dell'adapter, non so se può essere deleterio tenerlo così o farlo più corto possibile...

@patrickstar : ogni suggerimento è benvenuto! Questa è datata 06-08-2014. Su quella che a te dava problemi, hai applicato il fix R1R1?
Ricordi come si comportava prima e dopo il fix, senza cambiare freebot per wb?

@Thepusher : freeboot glitch2m effettuato dall'inizio ;) Da quel che ho capito, il cap fix dovrebbe servire a migliorare l'efficacia del glitch, ad aumentarne la probabilità di riuscita, ma dopo il fix R1R1 questa non glitcha proprio più...

Non ho cambiato finora timing al cpld, ma da quello che ho letto su altri thread del nostro forum, non sta lì la soluzione...(io ho installato il suggerito minusone_nr).

Mi chiedo però perchè il comportamento del glitchip cambi completamente quando applico il fix della R1R1...e perchè non faccia più lo slowdown (bisognerebbe misurarlo con un oscilloscopio, ma a naso non sentendo più la ventola sibilare durante il tentativo di glitch l'impressione è quella).
Ho visto che il lato della R che ho messo a GND è connesso ad una piazzola alla sinistra della NAND (guardando la scheda così come nella mia prima foto), mi sembra il pin 8 a partire dal basso, ma non so a cosa corrisponda sotto al bga quel pin...qualcuno sa illuminarmi?

Hai fatto un glitch 2m con o senza la resistenza r1d1?
Cambia assai la scrittura dell'smc senza o con. Quindi se lo hai fatto senza riflasha oppure ponticella e poi riflasha

Ah non mi era chiara questa cosa...pensavo che il fix influenzasse solo il glitch nella fase successiva...
Ho scritto il glitch2m con la R1R1 in posizione originale, poi dopo aver visto che cercava di glitchare all'infinito, l'ho tolta, poi rimessa e ponticellata a GND

Ragazzi, la situazione sembra stabilizzata...
Senza cambiare alcuna configurazione di cavi, cap o altro, ho riportato la R1R1 in posizione normale, ho riflashato la nand applicando il suggerimento di patrickstar con il fix per Winbond2K, ma è capitato che su 10 tentativi, in 2 si fosse bloccata come in precedenza con "slowdown infinito" (sentivo il sibilo della ventola di continuo ma nè la console si avviava nè il debug led continuava più ad illuminarsi), al che ho messo un pin della R1R1 a GND (esattamente come avevo fatto in precedenza) ma , diversamente da prima (quando il debug led era molto rapido e non sentivo alcun sibilo della ventola) ora lo squirt non va più in palla al 5° tentativo di glitch ma continua a tentarlo finchè la console non si avvia.
Ho ottenuto questi tempi senza lettore dvd e console aperta:
8-4-6-3-7-2-2-4-10-3
e questi a console chiusa:
7-3-7-8-3-7-3-4-4-6

Ho notato che , con la mod wb2k, il tempo in cui il sibilo è attivo è sensibilmente più lungo , prima circa 2 secondi, ora circa 3...
Una cosa che non avevo scritto prima è che la XCGPU è una D-A02 X818337-003, credo una di quelle nuove, forse per questo, nonostante le ram siano Samsung, la situazione è migliorata.
Spero la mia esperienza possa aiutare altri :)

P.S. Curiosità : sapete x caso a quale pin è connessa la R1R1 sotto il bga della nand?

Un grazie enorme a tutti !