Ricapitolando
CPU_RST
C7R112
STBY_CLOCK
C3C4
POSTBIT
FT6U7
PLL_BYPASS
R7R17
VCC
J2B1.7
GND
GND
Thanks Rf1911
Messaggio editato dopo segnalazione di rf1911
Visualizzazione Stampabile
Ricapitolando
CPU_RST
C7R112
STBY_CLOCK
C3C4
POSTBIT
FT6U7
PLL_BYPASS
R7R17
VCC
J2B1.7
GND
GND
Thanks Rf1911
Messaggio editato dopo segnalazione di rf1911
CLK
R3B7 Assolutamento no.
[URL="http://imageshack.us/photo/my-images/693/xboxboard2.jpg/"]CPU_RST[/URL] -> C7R112 -> pad destro o sinistro? (non fate caso che è rotto, non è mia la foto)
[URL="http://forums.xbox-scene.com/lofiversion/index.php/t654616.html"]STBY_CLOCK[/URL] -> C3C4 -> l'ho trovato ma non so qual'è il punto esatto... (il C3C4 è in alto a sinistra)
[URL="http://imageshack.us/photo/my-images/694/regfix11.jpg/"]POSTBIT[/URL] -> FT6U7 (vicino al dissipatore CPU, sotto)
[URL="http://img11.imageshack.us/img11/6143/regfix07.jpg"]PLL_BYPASS[/URL] -> R7R17 (mi sa che è il più difficile, sotto)
[URL="http://i39.tinypic.com/693lf5.jpg"]VCC[/URL] -> J2B1.7
GND -> GND (connettore video)
Questo post l'ho fatto un po' per farvi quelle due domande, un po' per ricordarmi poi i pin quando andrò a provare ^^
(non uccidemi per qualche errore XD)
Comunque sono solo questi 6?
alla fine qualcuno ha provato a glitcharla? a dire la verità vorrei condurre questo esperimento sulla xenon con dash 8955 che ho. Mi potreste fornire il file per programmare il chip e ecc.bin? ps ovviamente in PM
:barbershop_quartet_:cool:
Hai trovato il timing? ^^Citazione:
Originariamente Scritto da D@rio
Ci sono news D@rio?
..dario sono stato incasinatissimo.. non mi sono scordato.. appena ho un attimo mi ci rimetto... promesso.. il tuo post analyzer funziona e spero di poterti ripagare presto!
Posso chiedere delucidazioni su come far glitchare una xenon per recuperare una key?...
Attualmente la X lampa 4/5 volte poi fa un lampeggio lungo, e poi ricomincia!
sono gia' 5 tentativi da 15/20 minuti l'uno e non parte, nessun RROD ma neanche Xell...
Lasciala andare... parte anche dopo alcune ore... Io in 6 ore non son riuscito a farla partire...
Ti amo...
Mi hai dato una buona notizia! :)
Lascio il condensatore tra GND e PLL ?? anche se fa questi strani lampeggi??
PS, provo a caricare l'ecc donato da RF??, rogero 0.93 mi diceva che se c'erano problemi di glich bisognava provare con il secondo ecc generato...
12 ore di X accesa, nessun boot, ora stó provando con piu tentativi di "breve " durata
Ne ho anche io una che non parte
inviato da oltre la cortina di ferro
Porca...Citazione:
Originariamente Scritto da guerrierodipace
Posso chiederti la tua config?? Condensatori, cavo RST etc etc etc..
Scusate, ma rimettendo la nand originale anche senza il condensatore su rst dovrebbe ripartire?... parte se scollego il chip,
Invece ho notato che la dash è la 8955, puo essere il motivo dei problemi??
Se si sapete come posso aggiornarla?
No, nn parte se lasci staccato il condensatore.
Il kernel nn centra... è il glitch ad essere penoso
non dovrebbe dare problemi lasciando staccato il condensatore sul CPU_RST
Nel frattempo ho aggiornato (nn troppo :)) a 13604 e ridumpo tutto, inietto un nuovo ecc e vediamo se almeno una schermata blu la vedró!
Comunque vi diró che parte anche senza il condensatore...
La mia nn parte... misteri divini...
È dalla saga zephyr che mi stupisco come riescano a fare X antiglitch senza saperlo...
PS ma che differenza c'è tra il CB1940 e il CB7375 donato da rf??
Perdonatemi, ma continuo a postare qui, non sapendo se conviene aprire 3D a parte, anche se sempre di xenon si parla...
Il led di debug, se ogni 3/4 tentativi si accende fisso per 2 secondi vuol dire che la CPU crasha giusto? in tal caso devo affinare le capacita' che utilizzo oppure e' normale che ogni tanto faccia cosi'??
Grazie!
E' capitato anche a me questa cosa, è normale. Il chip perde la sincronia quando succede, ma si riprende al tentativo successivo.
PS: Non cercate altre spiegazioni riguardo quello che ho detto, perché è una cosa interna al chip e la discussione sarebbe veramente infinita anche con persone che questo lo fanno di lavoro ;)
Capito, rigrazie!
Il fatto che anziché 5 secondi lampeggi ogni 7 credo sia indifferente?
Ragazzoni, più leggo le vostre "discussioni" passate e più mi ingolosisco di conoscenza! :)
Esiste un modo per controllare se la CPU crasha? E magari per verificare se riparte? In questo modo ci si assicura che il cpld faccia il suo dovere, quindi se non boota posso mettermi l'animo in pace...
PS Ho un condensatore in zona CPU che sfrigola fin tanto che permane il 1,1V sul RST... È indicativo??
Riesumo dalla fossa questa discussione in quanto ho deciso di iniziare anche io a fare qualche test su questa board, e chiedo gentilmente a chiunque abbia partecipato "all'epoca" se può darmi dritte o consigli.Citazione:
Originariamente Scritto da rf1911
Sulla scaletta operativa sono già al punto 4 (il punto 1 è un ni, in quanto uso un'architettura diversa), quindi sto misurando la lunghezza della memcmp(full speed, CLK_EN, PLL_BYPASS) per poter aggiustare i timing.
Per ora sono su AVR che, per quanto ottimizzato, penso abbia un certo margine d'errore in eccesso, quindi pensavo di "prendere le misure" direttamente da CPLD.
Se qualcuno vuole darmi una mano...
Queste sono le misurazioni effettuate(in microsec)
CPU_PLL_BYPASS:
CPU_EXT_CLK_EN:
Standard Clock:
Il codice utilizzato è questo:
Codice:void setup() {
for(int i=12;i<4;--i)
{
pinMode(i,INPUT);
}
pinMode(4,OUTPUT);
digitalWrite(4,LOW);
Serial.begin(1000000);
}
bool flag=false;
unsigned long time=0;
void loop() {
if( !(bool)(PIND & (1 << 5))==1 && !(bool)(PIND & (1 << 6))==1 && !(bool)(PIND & (1 << 7))==0 && !(bool)(PINB & (1 << 0))==1 && !(bool)(PINB & (1 << 1))==1 && !(bool)(PINB & (1 << 2))==0&& !(bool)(PINB & (1 << 3))==1 && !(bool)(PINB & (1 << 4))==0)
{
if(flag==false)
{
PORTD |= _BV(4);
time=micros();
flag=true;
}
}
else
{
if(flag==true)
{
unsigned long time2=micros();
time2-=time;
PORTD &= ~_BV(4);
Serial.println(time2);
time=0;
}
flag=false;
}
}
MI dispiac ema io non ti posso aiutare...
Ti do una dritta.. non puoi asserire il pll con la logica dell'rgh1 per glitchare una xenon.
Mmm immaginavo che ci sarebbero state delle complicazioni.
Per ora il RST non l'ho ancora toccato, ma assertando a DA e deassertando a F2 non ho notato crash della CPU.
Ho visto solo che ho una finestra di tempo max(che però non ho ancora calcolato con esattezza) di asserting, oltre la quale (immagino sia un timeout sull'SMC) il sistema si riavvia.
Dovendo downclockare a D8 non so se il tempo a disposizione sia sufficiente, ma ripeto, ho appena iniziato a lavorarci e i test da fare sono ancora parecchi.
Riusciresti a confermare/smentire le mie deduzioni?
Te ne dico un'altra.. non crasha quando asserisci, se crasha crasha quando de-asserisci. Quindi la tua prova non è corretta. Quando vedi 0xF2 sei già in panic e l'smc resetta indipendentemente dal fatto che la cpu sia crashata.
Un'altra, non puoi asserire il PLL sul DA, non avrai MAI un timing costante.
Temo di non essermi spiegato bene:lo so che l'asserting deve essere fatto su D8, sul DA lo facevo solo per misurare la lunghezza della memcmp(come spiegato a suo tempo dallo stesso gligli).
So anche che i problemi sono stati rilevati sul deasserting, ma assertando su D8 e deassertando a D9 mi sembra di non aver notato crash(ma su questo non posso mettere la mano sul fuoco)
Forse non mi è chiara la definizione di crash:quando la CPU entra in questo stato e l'SMC la riavvia e il funzionamento riprende regolarmente oppure rimane freezata(non supera 0x13, come quando si lascia assertato il PLL) fino ad un particolare evento esterno(ad esempio il riavvio completo del sistema)?
Non puoi misurare il DA così, il timing non sarà mai costante. Prova ad asserirlo sul D8 e deasserirlo quando è > di DA. Vedrai che non raggiungerai mai il DA.
PS: Credo sia più giusto dire "asserire" e non assertare.. almeno in italiano.
Ah, io mi ero basato su questo articolo [url=http://www.free60.org/Finding_the_right_timing]Finding the right timing - Free60[/url]
Si, infatti ho notato che assertando a D8 si riavvia da solo poco dopo D9, per questo ho ipotizzato il discorso della finestra temporale, in quanto il riavvio accadeva prima del deassert e quindi non avevo pensato ad un crash.
Farò ulteriori test (anche col CLK_EN, ma dubito risolva qualcosa, sarebbe troppo facile) .
Consiglio spassionato:è solo una questione di tempo da buttarci in prove e timing o è una battaglia persa in partenza?
Non è una battaglia persa, è una battaglia molto lunga. Guarda, personalmente ho già glitchato con successo molte xenon sia rjtag che rgh2. Ne ho pure una con il demon. Il punto è che o funziona perfettamente, o mai. Non sono riuscito a trovare un pattern per identificare con certezza quale revisione non crashi. Probabilmente rilascerò il tutto fra non molto..
In ogni caso, sappi che l'approccio che hai intrapreso è comunque sbagliato. Il codice su free60 serve solo per dare l'idea, infatti non c'è lo slowdown. "PS: Those pseudo-code examples don't show the slowdown code for the sake of clarity."
Hint: La console deve essere già in slowdown quando entra nel DA.
Grazie per l'hint. Quindi immagino che al posto del classico D8 (che da quel che ho capito è troppo "indietro") potrei provare ad asserire a D9 o addirittura in un lasso di tempo compreso tra D9 e DA.
Ho piacere che tu abbia deciso di rilasciare, io continuerò comunque con i miei esperimenti con un altro approccio, alla fine imparo divertendomi.
Grazie per le dritte.
Comunque glitchare la xenon in rgh2 è un po' più rognoso, lungo e noioso.. Spero per te ti sia capitata una xenon che non crasha. Auguri.
quando rilasci pezzi del tuo dna da impiantare su piccoli robot automatici da sfruttare in presenza di console rognose?Citazione:
Originariamente Scritto da rf1911
Dunque, ho fatto un po' di altri test e questi sono i risultati:
Usando il CLK_EN non ho problemi di assert/deassert, posso tranquillamente asserire a D8 e deasserire a D9/DA (ovviamente so che dovrei deasserire dopo, ma per ora devo fermarmi a DA) e la CPU non sembra crashare, mentre col PLL non riesco nemmeno a fare D9->DA.
Tuttavia ho notato che con CLK_EN il passaggio D9->DA (calcolo dell'hash SHA) dura circa 3,8sec...a me sembra un po' esagerato, considerando che con PLL dovrebbe essere circa 10 volte più lenta. Dove sbaglio?
Credi che sia più percorribile la strada PLL (cercando di ritardare il più possibile l'assert) o provare a riscriversi i contatori per lavorare col CLK_EN?
Grazie
Ciccio il PLL se bypassato manda la cpu a 1/128... il timing è altissimo, roba da milioni..
Appunto.
Già col CLK_EN che è 1/10 ci impiega 3sec, col PLL ci dovrebbe impiegare più di 10 volte tanto.Il che mi sembra assolutamente fuori dai tempi di RGH1.