Glitchare una Xenon

[andreagtr]

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!

[ilario]

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

[andreagtr]

Capito, rigrazie!
Il fatto che anziché 5 secondi lampeggi ogni 7 credo sia indifferente?

[andreagtr]

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??

[DrSchottky]

Ragazzi.. il problema è complesso. Per prima cosa con il 3.3 sul pll si abbassa la velocità a 520hz. E' vero che l'altro punto porta a 6.2mhz, ma la finestra si abbassa di più di 10 volte!!

1) Fare il porting del glitch su ARM7 (Tipo Olimex)
2) Modificare build.by per accettare CB/CD della xenon
3) Patchare SMC xenon
4) Trovare il timing

Il tutto senza che ovviamente la console si pianti mai. Quindi la vedo dura.... Ora si potrebbe ovviare ai punti 1 4 andando a provare dei valori, magari iniziando da una media dei tempi di glitch delle altre -50. Ma ciò significherebbe che ad ogni cambio di timing è necessario riprogrammare il chip.

Se qualcuno di voi ha tanto, ma tanto, tempo posso vedere di modificare il build.by e trovare la patch per l'smc. Posso cioè fornire un ecc che dovrebbe permettervi di provare il glitch. Poi posso anche spiegarvi come ricompilare i jed. Si potrebbe anche pensare di installare un cristallo da 48mhz sul chip in modo da avere un clock più stabile.

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.
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...

[DrSchottky]

Queste sono le misurazioni effettuate(in microsec)

CPU_PLL_BYPASS:

7136

7064

6888

6884

6996

6972

7308

7280

7220

7216

CPU_EXT_CLK_EN:

588

600

576

604

604

596

596

588

608

612

596

Standard Clock:

56

56

56

64

56

52

60

60

60

Il codice utilizzato è questo:

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;
  }

}

[Titty]

MI dispiac ema io non ti posso aiutare...

[rf1911]

Ti do una dritta.. non puoi asserire il pll con la logica dell'rgh1 per glitchare una xenon.

[DrSchottky]

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?

[rf1911]

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.

[DrSchottky]

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)?

[rf1911]

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.

[DrSchottky]

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?

[rf1911]

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.

[DrSchottky]

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.

[rf1911]

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.

[Rockever82]

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?

[DrSchottky]

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

[rf1911]

Ciccio il PLL se bypassato manda la cpu a 1/128... il timing è altissimo, roba da milioni..

[DrSchottky]

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.