Cosa fare quando una xbox FAT non glitcha

[diotta]

Poichè mi trovo in condizione di avere una jasper 16 mb che non vuole sapere di glitchare ho deciso di raccolgiere un post riassunto di mille altri post similari che ci sono sul forum in modo che possa servire a chi si troverà in queste condizioni in futuro e a me visto che con quello che riassumerò in questo post ancora non ho risolto. Ho utilizzato il colore blu per commenti diretti alla comunità.

FIX HARDWARE POSSIBILI SIA PER CHIP PROPRIETARI CHE AUTOCOSTRUITI

1)Modificare o aggiungere una capacità verso massa su PLL-Bypass a partire da un valore di 470pF a crescere fino ad un valore di 100nF. A crescere significa che se si aumenta la capacità finche in teoria non glitcha.

2)Allungare il cavo di cpurst a 32 cm. alcune varianti dicono di fare 7 + 32 cm. Il + corrisponde a una saldatura intermedia. (Su questo punto mi pacerebbe confrontarmi con voi a riguardo)

3)Aggiungere una capacita in serie da 20p a 50p su cpurst: quindi pin40-->capacita-->>cpurst

4) aggingere o modifcare la capacità verso massa su cpurst in un arco di valori che va da 220pF a 470pF

5)Provare fili "stranded" e non monofilo e provare percorsi diversi soprattutto il CPU_RST,solitamente lontano ma a volte vicino/sopra/dentro i toroidi.

6)Diminuire la resistenza da 22k sul PLL-BYPASS

FIX HARDWARE POSSIBILI PER CHIP AUTOCOSTRUITI


1) Differnti pareri si leggono riguardo il diodo che che congiunge il pin 15 del CPLD al pin 7. Riferendosi allo schema light che è stato discusso in questo forum qualcuno afferma di averlo fatto funzionare sostituendo quel diodo con un pezzo di filo, altri affermano che funziona con il diodo. Prego di chiarire questo punto ma direi che l'utilità del diodo è portare a 1,5 la tensione sul pin 7. Tuttavia per quel che ho potuto sudiare fino qui direi che oltre un certo valore di corrente la caduta sarà di 0,6-0,7V portando sul 7 1,2-1,3V.

FIX SOFTWARE


1)Provare timings differenti sul chip

DIAGNOSTICA


Per capire cosa sta succedendo nella vostra xbox quando questa non vuole glitchare

1) Capire se avete distrutto qualche piazzola o componente: rifleshando la nadn originale e staccando l'alimentazione del vostro CPLD vedere se parte l'xbox. IMPORTANTE: quando si fanno queste prove di accesione, attesa di glitch etc, e bene come minimo montare il convogliatore per raffreddare cpu e gpu. Io preferisco appoggiare due voentole esterne tipo PC su i relativi dissipatori per garantire una temepratura confortevole senza bsiogno di quel pezzo di plastica odioso.

2)Ricontrollare saldature

3)Verificare di utilizzare strumenti gusti per creare ecc e stare attenti al log che scrive durante il calcolo per vedere se ci sono errori

• verificare di non avere CB 6751 con 360 flashtool, nel caso si usi python classico l'ecc viene creato comunque ma è errato, bisogna usare multibuilder 0.7 mettendo solo il nanddump.bin.
• Non avere un cb 5772 se è una falcon ed in caso usare un cb donor se il tool che si usa non lo fa in automatico.
• Sulle falcon che non glitchano usare i timing Opus.

4)Verificare che il CPLD funzioni e sia stato programmato correttamente: vorrei il vostro aiuto per sviluppare questo punto insieme a voi in particoare utilizzando un oscilloscopio vorrei poter capire se ho programmato bene il mio CPLD e lui fa il suo dovere o meno. Magari è fallato, rotto o mal programmato. Chiedo a chi può spiegarmelo quale deve essere il comportamento all'accensione dei pin cpu_rst pllbypass e postbit.

5)Montare debug led su pin 27 (normalmente):il debug led deve essere bello acceso per circa mezzo secondo. Un flash fioco significa saldature/punti sbagliate.

Inutile dire che questa è una bozza di un articolo secondo me molto utile non per quello che contine ma per il fatto di contenerlo tutto insieme. Mi piacerebbe portare avanti la parte di diagnostica sia sul chip sia sull'xbox guardando il bus POST_bit, a riguardo ho letto qualcosa qui sul forum ma non ho ancora studiato per poterlo riscrivere qui. Chiedo a voi di leggerlo e correggermi dove potrei aver sbagliato e di aiutarmi sulla parte di diagnostica CPLD.

Un saluto
Diotta

Aggiornato con il contirbuto di Raiden, guerrierodipace, The Pusher, X-ray, rf1911.

[Raiden]

Direi anche...

verificare di non avere CB 6751 con 360 flashtool, nel caso si usi python classico l'ecc viene creato comunque ma è errato, bisogna usare multibuilder 0.7 mettendo solo il nanddump.bin

[guerrierodipace]

aggiungerei di provare fili "stranded" e non monofilo e provare percorsi diversi soprattutto il CPU_RST,solitamente lontano ma a volte vicino/sopra/dentro i toroidi.
Infine provare timings differenti sul chip

[vikviper]

Ci vorrebbe una discussione del genere anche per le Slim, se posso suggerire l'ovvio. =)
Poi cancellate pure questo messaggio che è inutile ai fini della discussione stessa.
Grazie

[The Pusher]

Non avere un cb 5772 se è una falcon ed in caso usare un cb donor se il tool che si usa non lo fa in automatico

[rf1911]

Io dico di non mettere MAI un condensatore in serie al CPURST. Sul glitchmod light il diodo porta a 1.4 prendendo l'alimantazione 1.8 dalla piastra. Altra prova è diminuire la resistenza da 22k del pll. Per prima cosa no debug led no party. Il debug led deve essere bello acceso per circa mezzo secondo. Un flash fioco significa saldature/punti sbagliate. Nel caso di debug led ok e niente glitch controllare il cpurst. Usare sempre il tester. Il CPURST deve dare circa 1.1v e tornare a 0 ad ogni rst. Il postout deve dare da 0 a 1.1 circa. Il pll deve dare 0 e se avete un tester "veloce" vedrete che da 3.3 insieme ad dbg led. L'hana clk deve dare da 1.4 a 1.8.

[X-ray]

sulle falcon che non glitchano usare i timing Opus

[ilario]

Per quanto riguarda il punto 4: I tools di programmazione (Impact, 360gcprog e urjtag sono quelli che usato fino ad adesso, ma anche gli altri dovrebbero funzionare così perché sono le specifiche JTAG ad essere così) ti dicono se la programmazione è andata a buon fine o meno e non è che si possono sbagliare perché sanno i bit di programmazione che hanno inviato e controllano sul tdo che escano gli stessi bit.
Riassumendo: Se il tools di programmazione vi dicono che il CPLD è stato programmato correttamente vuol dire che è così.

[diotta]

Io penso che ci sia qualcosa che non va nel cpld, non ho un led da mettere sul pin 27 ma mettendo l'oscilloscopio vedo un impulso da 10 ms ogni 5 secondi di 1.10V. Guardando cpurst si resetta ogni 5 secondi per 100ms e penso che sia l'smc non riesco però a vedere il reset di 100nS. Quanto dovrebbe scendere? Chiarmanete non fino a 0 giusto? Avete qualche consiglio?

[ilario]

sul led di debug dovrebbe darti 3.3V

[rf1911]

Mettendo l'oscilloscopio su DB6E3 (devi togliere il dissipatore CPU) che frenquenze leggi durante il glitch?

[diotta]

Come fa a darmi 3.3 se lo alimento solo con 1,8?
Non vorrei tirare giù il dissipatore, per capire se viene downclockato non basta vedere pllbypass? ancora non ho capito bene quale deve essere il suo comprotamento.

In particolare:
"cjak found that by asserting the CPU_PLL_BYPASS signal, the CPU clock is slowed down a lot, there's a test point on the motherboard that's a fraction of CPU speed, it's 200Mhz when the dash runs, 66.6Mhz when the console boots, and 520Khz when that signal is asserted. "

Cosa vuol dire il seganle asserito?

[ilario]

Se lo alimenti con solo 1.8 è normale che non ti funziona, al chip servono sia gli 1.8v che i 3.3v ed anche i 1.5 (1.4) che crei col diodo.

[diotta]

Intendi che è normale che non mi funziona il led di debug?
Se invece intendi il chip ti posso dire che gli servono solo 1.8 per funzionare.

Ad ogni modo sono riuscito a vedere anche il segnale di rst di 100nS vi allego l'immagine. Quindi il cpld sembra funzionare correttamente. Mi chiedevo se è normale che dopo il rst la tensione rimanga più alta di 170mV. Ho letto quacosa riguardo la forma di questo impulso, dal qaule dipende poi la riuscita o meno del glitch. Faccio riferimento spero senza infragere regole ad un post fatto da un utente di questo forum su un altro forum [url=http://www.xboxhacker.org/index.php?topic=17429.msg131393#msg131393]CPU_RST signal waveform[/url]

Sembra che per far andare le cose al meglio serva quella piccola sovrelongazione a fine impulso che io non ho.

[D@rio]

Intendi che è normale che non mi funziona il led di debug?
Se invece intendi il chip ti posso dire che gli servono solo 1.8 per funzionare.

questo è quello che trovi nel file di configurazione .ucf nel progetto di ISE della slim rilasciato da gligli

#PACE: Start of PACE I/O Pin Assignments
NET "CLK" LOC = "P29" | IOSTANDARD = LVCMOS33 ;
NET "CPU_RESET" LOC = "P8" | IOSTANDARD = LVCMOS18 ;
NET "DBG" LOC = "P27" | IOSTANDARD = LVCMOS33 ;
NET "POSTBIT" LOC = "P40" | IOSTANDARD = LVCMOS18 ;
NET "SCL" LOC = "P19" | IOSTANDARD = LVCMOS33 ;
NET "SDA" LOC = "P18" | IOSTANDARD = LVCMOS33 ;

serve aggiungere altro per dimostrare che servono anche i 3.3V per il corretto funzionamento del CPLD?

[ilario]

Intendi che è normale che non mi funziona il led di debug?
Se invece intendi il chip ti posso dire che gli servono solo 1.8 per funzionare.

Guarda non la prendere a male, ma io so benissimo quale tensione serve al chip per funzionare, se no non ne avrei progettato uno mio.
Come ti ha allegato anche D@rio servono tutte e 3 le tensioni che ti ho elencato per far funzionare correttamente il glitch chip. Gli 1.8V servono solo per far andare il core del chip la parte logica mentre i 3.3v ed i 1.5v per far andare gli i/o. se tu non alimenti gli i/o è chiaro che non ti funziona.
Infatti ti da 1.1v perché non è alimentato correttamente e preleva corrente dal core e non dal banco di i/o.

[diotta]

Hai perfettamente ragione, ti ho risposto così perchè ne ho fatte due alimentando solo con 1,8 e funzionano ma funzionano perchè come dici tu le uscite che servono per l'hack vanno a 1,8. altre come il led di debug a 3.3 e infatti non mi funzionavano. D'ora in avanti collego anche 3.3.
Per risolvere al fatto che non glitchava ho dovuto sostituire la resistenza su pllbypass con una da 1 kohm e tutto ha cominciato magicamente a funzionare.
Ora parte e tutto ok tuttavia le ventole accellerano abbastanza velocemente e arrivano a livelli parecchio spinti, non vorrei che lasciandola aperta per qualche giorno e smanigandoci il dissipatore non aderisca più bene alla pasta termica.
Forse dovrei smontarli sostituire la pasta e rimontarli?
Voi di norma quando fate un rgh sostitutite anche la pasta?
Mi sono accorto che disancorando le xclamps dalla scocca il dissipatore ha un gioco di 2-3 mm il che lo porta forse a scollarsi dalla cpu.

[rf1911]

Confermo che l'1.8 basta. Se si vuole aggiungere il condesatore sul pll e il debug led è necessario il 3.3v sul pin 26, mentre in programmazione il 3.3v va sul pin 35. Il primo glitchmod "light" risale a diversi mesi fa..

[pocoyo2]

Confermo che l'1.8 basta. Se si vuole aggiungere il condesatore sul pll e il debug led è necessario il 3.3v sul pin 26, mentre in programmazione il 3.3v va sul pin 35. Il primo glitchmod "light" risale a diversi mesi fa..

Esattamente. I 3,3v li utilizzo solo per la programmazione.
Solo in un caso, su una jasper256, mi è sembrato di avere dei miglioramenti aggiungendo anche i 3,3v.. ma credo sia stato un "effetto placebo" in quanto la stessa console aveva sempre funzionato egregiamente solo con l'1,8v.
Io e rf1911 abbiamo testato abbastanza a fondo il comportamento dei vari componenti, fino alla "pubblicazione" della glitchboard light

[diffusore]

perche' con cb 6751 e 5772 la procedura RGH si "complica"????