Aller au contenu


xvassor

Inscrit(e) (le) 08 nov. 2011
Déconnecté Dernière activité janv. 22 2019 22:47
-----

Messages que j'ai postés

Dans le sujet : [résolue]RGH2 sur jasper16 avec coolrunner rev b.(xell ok)

27 juin 2012 - 14:37

si tu dessoudes le CPU_RESET celui va rester dans un etat indéterminé donc pas bon du tout, dessoudes juste POST_OUT1
ainsi tu aura ton CPU_RESET non parasité et ton CPLD ne produira plus de Glitch car il ne détectera plus rien ...

3 Leds rouges ca veut dire qu'il a raté tous ces essaies de boot donc passe en RROD au bout de 30s environs.
Deux reset sont espacés d'environs 7s

Dans le sujet : kernel pour hack reset glich

14 juin 2012 - 15:01

@benkenoby : Exact...

Il ne faut pas faire attention à xvassor qui ne lit qu'à moitié !
D'ailleurs, pour preuve, il intervient alors que spectre59 évoque le kernel 12146 qui n'existe pas XD

Sinon, le squirt est bien programmé ? ;)


J'ai mal lu le topic, j'etais sur du RGH2 d’où mon erreur, je confirme que le CB est bien splité qu'a partir du kernel 14717.
Je laisse super Yoshee te régler ton problème, je pense que c'est l'homme de la situation.

Dans le sujet : 2boot .

14 juin 2012 - 14:48

On refait une nand retail que lorsque le dump de la nand d'origine n'est pas bon sauf la partie KV sinon c'est mort !
La partie KV est encodé avec la clé CPU donc si tu la reprends telquel tu n'a pas besoin de ta clé CPU.
Tu prends une donor NAND (nand pour le même type de console, compatible hardware) auquel tu injectes ton KV voir aussi ta config si tu l'as aussi.

en principe tu n'as pas besoin de rebuilder ta nand d'origine puisque tu en a mis 2 voir 3 copies de coté ... (étape 0 le dump de la nand)
sinon tu as mis la charrue avant le flash :)

Dans le sujet : 2boot .

13 juin 2012 - 10:17

quand tu relies le blindage de ton CPU_RESET a la masse dans certains cas ça peut tout simplement empêcher celui ci de marcher en le forçant a '0'.
Court circuit dirons nous.

Vérifie que ton signal CPU_REST change bien de tension (volte mètre) :

console en veille tu dois avoir entre 1,2V et 1,8V sur CPU_RESET (je me rappels plus bien la valeur)
lors d'un reset de la console la tension doit chuter vers 0v.

Même vérif à faire sur POST_OUT1.

Si ton CPLD est bien programmé et tourne bien, sa sortie debug du Xilinx doit passer a '1' durant quelques secondes chaque fois que le CPLD
décode correctement le post_out1 et généré son glitch sur CPU_RESET.
SI tu ne vois pas passer le sortie debug a '1' c'est que le post_OUT1 est mal decodé => Pb de soudure sur ce file ou de VCCIO1 qui n'est pas bon.

si tout ça est Ok et que ça ne marche pas:
- problème de timing
ou
- problème de propreté du glitch sur CPU_RESET (oscillo pour contrôler sinon c'est au pifomètre ...)
donc bouge ton file ou change le ou rajoute un filtre RC au niveau de la CM et non du CPLD.

Bonne pêche !

Dans le sujet : kernel pour hack reset glich

11 juin 2012 - 22:17

mise a jour faite en 12146 dump nand a 3 repris creation fichier ecc pareil pas de boot sur xell


c'est une grosse erreur d'avoir fait la mise a jour !
Le hack RGH2 est beaucoup plus difficile a faire tourner que la version 1.
De plus pourque ca marche tu dois souder deux files en plus (I2C signaux) et retirer PLL_BYPASS et reprogrammer ton CPLD avec les nouveaux JED/SVF ...
et changer ton ECC

Bref tout refaire ....
même le dump bien sur ...