28 replies to this topic

[psyko_chewbacca]

Bonjour, j'ai une Falcon que je dois glitcher en RGH2.0

Le hic c'est que je n'ai qu'un de ces boad générique XC2C64A d'eBay (créé par ngzhang pour les connaisseur!). J'ai fais le montage pour une FAT sur ce board mais ce moment à été conçu initialement pour un RGH1.0...

Je sais que ce n'est pas le même board, le mien est vert mais c'est le plus ressemblant que j'ai pu trouver comme image...


Donc il n'est surement plus adapté pour un RGH2.0...

Pour l'instant j'ai évidement retiré la résistance de 22K puisque le PLL_BYPASS n'est plus utilisé. J'ai aussi ajouté une résistance de 10ohm sur le CPU_RST et j'ai soudé les lignes I2C aux bon points en me fiant au diagramme d'installation SLIM pour ces puces.

Quelles sont les autres modifications que je devrais intégrer?
Un condensateur de 220pF entre CPU_RST et la masse?
Est-ce que les diodes et le circuit RC sont encore utiles?
Je vois beaucoup parler d'un ajout d'une résistance de 3.3k sur les x360 Glitchip, devrais en faire de même? Si oui, où est-ce que je la soude?

Merci de bien vouloir m'aider!

Ce message a été modifié par psyko_chewbacca - 16 April 2013 - 13:03.

[Hackstore59]

Pourquoi faire simple quand on peut se compliquer la vie, rgh2 falcon + une puce peu connu^^

Je te souhaite bon courage

[acide0]

Surtout avec les freezes récurant sur falcon en rgh2, bonne chance.

[psyko_chewbacca]

Bon est-ce qu'une version plus récent du RGH pourrait limiter ce problème de freeze? À ce moment je comprend que je devrais peut-être investire dans une puce dédiée à ce genre de fonction!

[Gagny-Tech]

Prend une glitchip 2.2

[M@DBoX]

C'est un Xilinx Coolrunner II XC9500 ?

 

 

http://libx.juvsoft....ttach=196;image

 

 

 

 

[nako05]

Si ton kernel est 15772+, tu auras moins de chance d'avoir des freezes qu'en 14717/14719, mais le risque n'est pas réduit à zéro.

 

Sinon pour le montage + passage des fils, ce topic m'a beaucoup aidé http://www.logic-sun...ster-chez-vous/

 

De plus si tu intègres un ocsilliateur 48 mhz à ton montage, tu pourras te passer du point le plus dur, celui du chip hana

[psyko_chewbacca]

C'est un Xilinx Coolrunner II XC9500 ?

 

 

http://libx.juvsoft....ttach=196;image

Non c'est quand même une XC2C64A mais c'est vrai que la puce elle même est montée sur un PCB originalement pour XC9500. Ton image contient justement le module que j'ai en ma possession!

 

Si ton kernel est 15772+, tu auras moins de chance d'avoir des freezes qu'en 14717/14719, mais le risque n'est pas réduit à zéro.

 

Sinon pour le montage + passage des fils, ce topic m'a beaucoup aidé http://www.logic-sun...ster-chez-vous/

 

De plus si tu intègres un ocsilliateur 48 mhz à ton montage, tu pourras te passer du point le plus dur, celui du chip hana

Merci je vais mettre ma console à jour vers 15772. J'ai déja suivi un bon nombre de conseil de ce topic. Je pourrais essayer d'installer le 3.3V sur le MOSFET mais je crains que ce ne soit pas mon problème pour le cas. J'ai laissé ma console un bon 30 minutes et elle n'a jamais démarrée en XeLL... Je crois donc que c'est un montage inadéquat sur le module CPLD qui est mon problème principal. Une fois que j'aurai confirmé qu'elle est au  moins capable de booter je me lancerai dans le tweaking.

 

Merci

[tibo94]

Abandonne et prend une vraie puce
Déjà que c'est pas gagner avec des puces glitch mais alors la

[M@DBoX]

C'est un Xilinx Coolrunner II XC9500 ?
 
 http://libx.juvsoft....ttach=196;image

Ton image contient justement le module que j'ai en ma possession!

 
Alors c'est tout simple :

Suis le schéma pour la modification phat (ligne rose).
Appart le PLL_Bypass qui ne sera pas nécessaire pour toi.
Il faudra prendre les signaux I2C à la place.
 
Oublie pas de retirer les résistances et de placer le shunt sur R2.
 
Pas besoin du 220pF pour le cpu rst.
Installe à la place un 680pf en série sur le point avec une résistance en // de 3k3ohm.

Ensuite flash ton cpld avec le timing RGH2 "Falcon" de la Tx ou le timing "E" de 360gcprog.
Câble le tout au plus court sauf le cpu_rst (un morceau de 32cm au dessus du tunnel en plastique pour commencer).
Et normalement ça devrait booter.
 
 Après à toi d'optimiser.

[psyko_chewbacca]

 
Alors c'est tout simple :

Suis le schéma pour la modification phat (ligne rose).
Appart le PLL_Bypass qui ne sera pas nécessaire pour toi.
Il faudra prendre les signaux I2C à la place.
 
Oublie pas de retirer les résistances et de placer le shunt sur R2.
 
Pas besoin du 220pF pour le cpu rst.
Installe à la place un 680pf en série sur le point avec une résistance en // de 3k3ohm.

Ensuite flash ton cpld avec le timing RGH2 "Falcon" de la Tx ou le timing "E" de 360gcprog.
Câble le tout au plus court sauf le cpu_rst (un morceau de 32cm au dessus du tunnel en plastique pour commencer).
Et normalement ça devrait booter.
 
 Après à toi d'optimiser.

Cool, merci beaucoup pour les explications! Juste pour être complêtement béton:

 

Sur la face du bas (bottom) du module, je ne soude pas le jumper bleu entre C3 et C4 destiné au SLIM?

Est-ce que je garde quand même la résistance de 10ohms sur le CPU_RST en la mettant en série avec le condensateur de 680pF et la 3.3k en parallèle?

 

Merci encore pour les explications concrètes!

[M@DBoX]

Aucune idée à quoi peut servir ce jumper entre C3 et C4, il faudrait suivre la piste jusqu'au xilinx.

Dans un premier temps, je laisserai le cpld en mode phat.

 

Et pour la résistance de 10 omh, il faudra tester avec et sans. 

 

 

ps : pense aussi à installer une led debug, pour voir l'activité de la puce.

[psyko_chewbacca]

Merci pour les conseils. J'ai réussi a faire démarrer XeLL sur ma falcon.

 

Entre 10 secondes et 3-4 minutes pour le boot. Je me lance donc sur l'optimisation.

 

Quels sont les paramètres sensibles pour optimiser le boot?

 

Pour l'instant voici ma config:

 

Falcon avec RGH2 sur module CPLD générique

CPLD programmé avec falcon_RGH2.xsvf de la TX (archive de J-Runner). Celle-ci semble donner les meilleurs résultats.

Cable +3.3V et GND très court de bon calibre en pur cuivre

Même chose pour les lignes I2C

Même cable pour le POST_OUT mais un peu plus long vous comprendrez. Il est au plus court possible quand même

Câble solid core 30AWG pour STBY_CLK, très court. Le signal d'horloge est très clean au CPLD en regardant avec mon oscilloscope.

Finalement CPU RST: Cable multi-brin (sans blindage) de 32cm dans l'ordre suivant: Module CPLD ----> combo 680pF et 3.3K en // ----->fil de 32cm ----> résistance de 10ohms ---->CPU_RST

 

 

Le 680pF et 3.3k sont des résistances surface mount 0805 alors que la 10ohms est une grosse résistance typique 1/4W.

 

Donc je pensais jouer sur les paramètres suivants:

combo 680pF et 3.3K : changer les valeurs (mais dans quelle plage?)

Résistance de 10ohms (varier un peu les valeurs ou ne pas en mettre)

Cable CPU_RST : changer la longueur ou changer pour du cable RF 50ohms double blindage.

 

Donc sur quoi devrais-je m'attaquer en premier pour maximiser mes chances d'améliorer la constance de mes temps?

 

Merci

[M@DBoX]

Le plus rapide est de tester sans la résistance de 10 ohms pour voir ce que ça donne.

 

Ensuite tu peux essayer le câble blindé sans le raccorder à la masse.

Teste un morceau de 32cm et un autre de 60cm.

 

Et comme fix de remplacement, essaye un condensateur de 1nF avec une 4600 ohm en parrallèle.

 

[acide0]

Y a toujours la technique du câble de 55cm que l on diminu peu a peu en le passant au dessu du tunnel d air. Tu sais pour le rgh2 c est comme ça faut y aller par essaie erreur surtout que tu pars avec une puce pas trop commune pour le rgh2.

[psyko_chewbacca]

OK merci je vais essayer tout ça! Pour le câble blindé, est-ce que je devrais le faire passer par dessus ou par dessous le tunnel d'air?

[M@DBoX]

Pour le câble au dessus enfin le plus haut possible ^^

 

Et si tu veux pousser dans tes testes

Installe un quartz (oscillator) sur la puce pour le signal d'horloge (clk).

Ca va booster tes temps de boot.

 

A condition de prendre un quartz de qualité avec une très faible tolérance.

Tolérence exprimée en % ou en ppm.

[psyko_chewbacca]

J'ai une commande à passer sur Digikey, je vais peut-etre commander un oscillateur.

 

Merci, j'imagine que la hauteur du fil c'est pour éviter les champs électromagnétiques produits des ferrite coils plus bas.

 

Une chose que je ne comprend pas c'est de ne pas relier le blindage du cable à la masse. De ce que j'ai retenu de mes cours d'électromagnétisme, le théorème de Gauss indique qu'une charge électrique traverse un volume fermé en suivant l'addition de toutes les charges impliquées dans le système. Pas de masse au blindage, pas d'opposition de charges. Les signaux parasites pouront donc affecter le signal CPU_RST quand même.

 

À moins que le blindage ne soit utilisé pour ralentir la propagation du signal RST dans le cable. Alors là ça fait du sens. Mais dans ce cas le câble devrait être beaucoup plus petit non?

[acide0]

Le probleme avec la Xbox c est que dans certain cas si tu relis le blindage a la masse tu n as aucun reset et ce a cause de la masse flottante de la Xbox.

[Hackstore59]

Si tu passes une commande profites en pour te prendre une puce^^

Au moins tu te prendras moins la tête.