[RISOLTO] Crash installazione RGH su Corona V4 BGA+dashboard 16202

[Babilozzo]

Salve a tutti , volevo aprire una discussione in merito a quello che ho avuto modo di "testare" sulla mia console rgh Corona con nand BGA Samsung che attualmente funziona come un gioiellino, però dopo un mese di infinite prove , durante il quale penso di averla massacrata abbastanza stà povera console.

In parole povere ieri sono giunto alla soluzione definitiva per risolvere i continui crash all'avvio della console con dash 16202 durante la fase di debug , a suo tempo ho fatto anche un video che illustra il problema;

[VIDEO] Cr3 lite mi inchioda la corona.

Bene per farla breve, ieri ho installato 360gcprog 1.6 perchè ero curioso di provare altri timing siccome volevo risolvere stò problema che a volte la console mi bootta da 1 a 3 clicli e a volte inesorabilmente al 4° ciclo crashava, considerando anche il consiglio di Tommino81 di provare a smanettare con i timing , mi metto all'opera e ne provo un pò ... tramite il 360gcprog e il mio squirt slave programmer programmo alla grande... A B C D E F ... stessa solfa la console non gasa. Inesorabilmente crasha al 4° ciclo e si avvia solo dopo molti tentativi a vuoto.

Poi però giungo all'illuminazione definitiva, cioè fare un bel freeboot 14719 .
La console l'ho presa con questa dash originale.

Risultato che ora non crasha più! Apparte il fatto che si avvia sempre precisamente entro il 4° ciclo finora dopo un bel pò di avvi consecutivi sia a caldo che a freddo , la console non và più in crash! Potete immaginare la mia soddisfazione ragà! Anzi a freddo il boot è istantaneo.

Il chip è un cr3 lite ma non ho utilizzato particolari fix, RST corto sul punto FT3T10 setting come da tutorial , dip 3 on su S4 , chip posizionato vicino al dissipatore , sopra il SB.

Quindi ora ho questo dubbio che ci sia una correlazione fra dashboard patchate e versioni di nand diverse fra loro che gestiscono l'rgh in modo "anomalo" purtroppo io non posso confermare questa teoria perchè non ho feedback, avendo fatto solo questa di corona.
Cmq intanto mi tengo stretto questa dashboard anche se è vecchia me ne infischio , cmq i giochi che ho non richiedono dash superiori e dunque sono apposto direi

Mi piacerebbe conoscere un parere dai mod professionisti che di corona ne fanno a bizzeffe Se è significativo questo fatto , oppure è la mia console ad essere veramente sfigata al punto da non digerire la dash 16202.

Per come la vedo io la dash 16202 è stata patchata male e sulle corona con nand bga dà problemi di crash.

In attesa di un Vostro gentile riscontro porgo cordiali saluti

[zeruel85]

Installazione a parte, visto che hai appurato che il problema è di tipo software, se ora ricrei un freeboot 16202, magari con un software differente da quello che avevi utilizzato originariamente, crasha anche luiofunge normalmente?

[Babilozzo]

Grazie per la risposta Zeruel, giustamente come dici tu questa è una cosa che dovrei provare;
finora ho sempre smanettato con JR e mi sono fermato li in quanto quando feci il dump originale usai solo JR e ho visto che AutoGG non mi lascia caricare il dump fatto con JR.

Con il mio dump sfigato, Potrei usare xebuiild gui di swizzy se è sufficentemente aggiornato? Lo script build.py direttamente? (haa bei tempi i primi freeboot lol)
Cosa mi consiglieresti eventualmente?

Grazie ciao.

[zeruel85]

Giustamente il dump fatto da J-Runner non funge su AutoGG (mah!), in quanto i dump di partenza sono di due dimensioni distinte, se fatte coi due programmi... Potresti riprovare con J-Runner, a me i freeboot 16202 di J-Runner non me li ha mai cannati, e se hai una Corona V4 è come se creassi il freeboot per Corona V2, quindi non vedo perché ti debba crashare. Forse è stato solo un caso, un file corrotto o flash andato in modo poco felice, non lo so. Al limite sì, puoi usare xeBuild GUI v2.089 che trovi nel mio thread in rilievo in News, quello in cui ci sono tutti i tool per RGH/Jtag.

Altro non saprei onestamente... Avevi creato il freeboot con le patch di DashLaunch abilitate per caso?

[Babilozzo]

Vedi, di dump originali ne ho solo di un tipo, fatto con JR. Dopo un mese e un centinaio di prove mi sono dimenticato quante volte ho flashato la nand cmq di freeboot ne ho flashati diversi, con e senza DL patch usando simple nand flasher che và benone ma sempre generati con JR alla fine e bene o male sempre 16202 e sempre con la "variabile" del crash. Io escluderei DL fra le cause possibili! quindi ora proverò a smanettare con xebuild gui se mi prende il dump!

Ciao.

[zeruel85]

Secondo me sì, te lo accetta, dovrebbe lavorare con la stessa dimensione di J-Runner.

[lapht]

Leggi la nand di ora con autogg no?

[Babilozzo]

Leggi la nand di ora con autogg no?

Scusa ma qui il discorso verte sul fatto che il freeboot potrebbe essere "patchato male" in congiunzione con il tipo specifico di nand bga potrebbe influire sugli eventuali crash della console in fase di boot. Se vado a leggere una nand già patchata il discorso cambia e avrei una variabile in più da considerare, siccome fra il fatto dell'installazione e i timing già sono impazzito nel cercare di stabilizzare un pò la modifica (che di per sè è instabile volere o volare) allora devo perforza usare il dump originale come base. Mona io che non lho letto la nand prima di sverginarla con vari tool, ma non immaginavo un macello del genere ..un mese fà, anzi ero convinto che non si potesse nemmeno leggere la nand bga..pensa te.

E poi ho staccato il reader e quindi dovrei risaldarlo e flashare la nand originale e poi rileggere ma siccome anche con quelle operazioni ho avuto vari problemi preferirei evitare

Tutto ciò è frutto di una supposizione in base ad alcune prove che ho fatto sulla mia console e non sono assolutamente significative. Può benissimo essere che possegga una console "dura" e quindi non ci sia una soluzione definitiva ai crash che riscontro all'avvio in quanto magari è proprio per il fatto di aver letto la nand all'origine in modo non congruo la causa di questi crash, tuttavia nella situazione attuale il discorso è decisamente migliorato, passando da una dash all'altra, è per questo che mi è venuto il dubbio! Faccio altre prove e vedrò di capire meglio dove stà il "baco" Ciao.

[Babilozzo]

Aggiornamento:

Ho l'impressione di aver scritto un mucchio di cazzabubbole in quanto con mia grande delusione l'rgh su stà corona bga s'inceppa anche con dash differente, quindi sono tornato alla 16202 e pace. Tutti gli altri software che ho provato non gestiscono la creazione del freeboot per corona 4G e non mi sono messo a smanettare manualmente perchè se canno il freeboot mi tocca ri-applicare il r/w kit ed è una cosa che vorrei evitare come la peste.

Tutte le mie prove di smanettamento di nand le ho fatte con JR finora.

Nel frattempo ho di nuovo sostituito i fili e ho usato awg30 multianima flessibile attorcigliati (2x) del tipo che si trova nei vecchi cavi e-ide quelli con il connettore blu ma Rotondi, (che erano una rivoluzione ai tempi dell' ATA 166 hahaha)

Direi che la situazione rimane invariata e invariabile anche così la console s'avvia quando gli pare;

- A volte glitcha anche per un minuto circa 15 cicli e poi parte (il che sarebbe meraviglioso ma lo fà una volta ogni 30 avvii)
- A volte in 2-4 cicli. poi parte e frezza sulla schermata iniziale
- A volte in 2-3 cicli si avvia normale.

- Di solito da fredda al primo ciclo si avvia! Temperature all'accensione cpu basse attorno ai 34/37 c°

- Molto spesso crasha (una volta anche a freddo su 5 tentativi in questi giorni) e il presentimento del crash lo si avverte il glitch prima perchè si sente che il sibilo delle ventole cambia di frequenza e intensità rispetto ai precedenti, e inesorabilmente il glitch dopo crasha.

- Dopo il crash non tolgo l'alimentazione ma riaccendo comunque e spengo prima del quarto ciclo se non si avvia, il boot successivo lo fà sempre al secondo ciclo il più delle volte!

Ho riprovato tutti i timing ed ora quello che mi sembra il più stabile sembra l'E usando 360gcprog prima avevo il D è andata per un paiio di giorni prima ancora l'A ecc sembra che stà minchia di CPU IBM sia autoadattativa e mi voglia rendere la vita un inferno

Ora l'ho spenta dopo averla accesa una sola volta da stamane (avviata all'istante al primo tentativo 1° ciclo è rimasta 6 ore accesa e ferma sulla dash) la riaccendo ed è ripartita temp. cpu 52 C° ma ci ha messo ben 6 cicli, il che è impressionante e cambia tutte le mie teorie fin qui dedotte.

Allora spengo di nuovo stacco tutti i cavi apro il coperchio, faccio una foto richiudo, sono passati circa 2 minuti circa, accendo e bootta in 2 cicli, meraviglioso! ;D

Allego foto dell'ultima modifica all'installazione ora stò valutando di collegarmi al cpu_rst alternativo vicino al foro grande della mb ma faccio ancora qualche giorno di test così com'è finche non si mette a crashare. Bella!

Scusate la qualità ma il cellulare che ho fà pena

[Babilozzo]

Eh no no no no !
Bel sabato oggi da me il tempo è brutto fuori c'è la bufera.. quale momento migliore per aprire di nuovo stà console sfigata e metterci mano . hehehe.

La console si blocca in slowdon in maniera random e io voglio che non si blocchi mai , almeno questo era lo scopo della discussione che ho aperto!

Bene ho intenzione di togliere i ponti su R2C7 & R2C6 e metterci su 2 resistenze come quelle che dovrebbero esserci , siccome non mi piace "trolleggiare" troppo
ho cercato su google questi valori ed è uscito un post molto interessante ..

It also lacks 3 resistors which we know the value,100 ohms for R2C7, R2C6 and R2C10.

da Reset Glitch Hack functional on Corona v4 - News posted on LS - LS forums

Fra un pò con tutta calma mi metto all'opera smonto e faccio questa prova, stasera o domani posto i risultati e spero di risolvere una volta per tutte il problema.

Saluti!

[Babilozzo]

Questo giro penso di aver davvero risolto il problema dei blocchi in slowdown della mia corona 4g! Ora metterò a disposizione la mia esperienza in merito in modo che altri bambini leggendo di seguito possano trarne vantaggio ed illuminazione.

Ieri sono stato 4 ore a mettere su le resistenza da 100 ohm (che guarda caso le ho prese da una scheda madre vecchia , nello stesso punto) in pratica non ho risolto niente anzi, la console si bloccava ancora più di prima! Conclusione, le resistenze non servono. Allora ho tolto tutto e rifatto i collegamenti, purtroppo nell'operazione mi salta la piazzola dell' F3T10 perchè avevo saldato il nuovo filo dritto e mi ha fatto spessore , quando ho girato la scheda mi ha portato via il punto, ok sono un fesso, prendo la penna in fibra di vetro , gratto un pò la pista che parte dalla piazzola ci saldo sopra un filo "capello" , prendo il punto rst alternativo con filo awg30 cortissimo. X fortuna si rimette a glitchare! l'ho scampata bella! Però ancora si blocca, allora ho provato a prendere il 3,3 v alternativo e adesso fila via lisca come un gioiellino! Sono un genio hahah!

Queste sono le foto del fix al punto F3T10 saltato, riparato e funzionante.
usato un pezzo di filo "capello" saldato sopra sul punto precedentemente pulito e grattato la micropista con penna in fibra di vetro.

Questo è il punto di reset alternativo collegato al chip con awg 30 cortissimo.

Questa è la foto dell'installazione ultimata, dove si nota il punto 3,3v è preso da sopra quello normale, è una tensione presente solo quando la console è accesa!

Ho provato a fare almeno una trentina di cicli di accensione ed è bella stabile , nessun blocco dove prima nella migliore delle ipotesi facevo una decina di avvi e poi si bloccava, il ronzio delle ventole è sempre molto stabile e non "oscilla" come faceva all'inizio quando avevo i 3,3 v sul punto originale (tensione che arriva dal southbridge).

Quindi anche per tutti quelli che potrebbero avere problemi analoghi consiglio l'utilizzo del 3,3 v alternativo. UNA BOMBA.

Riferimenti
RGH Alt. 3.3V point improves boot rate ! - Team Xecuter
Schema collegamento tensione alternativa 3,3v (arancione) per tutte le schede madri, fonte Free60

Allego anche un simpatico video, spiegazioni nella pagina youtube..

P.s. potete chiudere la discussione per me.