zackwarrior

Si tu es débutant, je ne te conseil pas du tout de t'attaquer au RGH 2.0, il nécessite pas mal d'optimisation et de connaissance sur le fonctionnement du RGH pour être optimisé

Personnellement je n'ai eu aucuns soucis à ce niveau là sur falcon, il faut récupérer tous les fichiers de base du kernel 14719 ensuite y intégré les fichiers pour lié au rgh2 et créer la nand freeboot avec xebuild en ligne de com. Le seul soucis c'est le SMC hacké, on en a pas encore du coup c'est un smc clean qui est utilisé, vous pouvez vérifier le log lors de la création du freeboot: ------ Encrypting and finalizing bootloaders ------ encoding smc.bin size 0x3000 SMC checksum: 1d0c613e known clean SMC found, type: Falcon v3.1(1.06) ******* ERROR: clean SMC found? you should use a hacked smc for glitch images. Du coup la console va ce comporter comme d'origine et effectuer 4 sessions de boot (~30sec), si le glitch ne passe pas pendant cette période, la console fera 3 led rouge et erreur 0022 D'où l'utilité d'optimisé son montage par rapport à sa console afin d'avoir un boot avant que la console fasse 3 leds rouge Avec un montage optimisé on peut avoir des boot ~5sec sans erreur 0022

Le RGH 2 n'est pas reellement un nouveau RGH, c'est seulement le portage du RGH 1 slim (split cb) pour qu'il fonctionne sur les FAT kernel 14717/14719 et furbished cb. Il n'est pas du tout optimisé et de base les boot sont super long ~3m et certains sous 10m. Pour fonctionner sur ta carte mère, cela demande beaucoup de temps et pas mal d'optimisations.... Avec le RGH2 ne vous attendez pas à avoir des boot super rapide "juste comme cela", il faut modifier la résistance en série avec CPU_RST et modifier la tension de référence du xilinx jusqu'à trouver la bonne valeur pour votre carte mère. Personnellement je n'ai eu aucuns soucis à ce niveau là sur falcon, il faut récupérer tous les fichiers de base du kernel 14719 ensuite y intégré les fichiers pour lié au rgh2 et créer la nand freeboot avec xebuild en ligne de com. Le seul soucis c'est le SMC hacké, on en a pas encore du coup la console va effectué 4 sessions de boot (~30sec) et si le glitch ne passe pas pendant cette période, la console fera 3 led rouge erreur 0022 D’où l'utilité d'optimisé son montage par rapport à sa console afin d'avoir un boot avant que la console fasse 3 leds rouge Tel quel le RGH2 n'est pas du tout optimisé

MagicSeb, le RGH 2.0 n'a RIEN A VOIR avec le RGH 1 au niveau temps de boot, les boot de base sont > 3m et encore certains tourne autour des 10m. D’ailleurs ce n'est pas vraiment le RGH 2, c'est juste le portable du RGH 1 slim (split cb) sur FAT afin de faire le RGH 1 sur les kernel 14717/14719, le "RGH 2.0" n'est pas du tout optimisé... Fait un rgh 2 tu verra bien, le RGH 2 n'est pas aussi stable ni aussi abouti que le RGH 1, sauf en faisant pas mal d'optimisations comme celle que l'on a indiqué pour la glitch360key

Ca va après il a editer sa réponse en indiquant que c'est sympa et que certains testeurs seront content des informations que j'ai donné. Mais dans tous les cas c'est vrai que ubergeek n'a vraiment aucuns respect, tout ce qui est dit il le prend comme une atteinte à l'image de TX... lol :s

C'est en usine

Bon alors je fais un petit retour. La méthode fonctionne, avec un peu de travail et de tests j'ai descendu les temps de boot sur falcon à 20-30sec. Astuces (dans mon cas pour falcon): De 1: Faite attention à utilisé du bon gros cable pour GND et le 3,3v cela à vraiment changer les temps de boot. De 2: La valeur de la résistance est à modifié cela votre console. Personnellement avec 16~18 Ohm exactement j'ai maintenant de très bon temps de boot (alors que j'avais 3m au début), l'idéal est d'utiliser un potentiomètre 47 ou 22ohm. De 3: Mettez votre puce en mode slim et faite en sorte que le condensateur qui est connecté sur CPU_RST ne soit pas connecté De 4: Le fait d'avoir la cage métallique et d'avoir une bonne propagation de la masse joue aussi pas mal, donc pensez à mettre la CM dans sa cage + la coque (partie métallique) De 5: Après avoir obtenu le xell et récupéré vos clés, pour la création du dash, pensez à ajouter +1 au LDV et modifiez en conséquence cfldv dans option.ini EDIT (pour ceux qui s'y connaissent): En ajustant la tension référence de sortie sur le xilinx avec un montage de régulation variable (régulateur + résistance variable + 2 condensateurs) pour envoyé exactement 1.65v, j'obtiens des boot de l'ordre de 5 sec.

En optimisant le montage avec du bon cable et tout je suis passé à +/- 30sec mais j'ai aussi des boot à 3-4m. Ce glitch est bien pire niveau temps de boot... Ya du taff. Par contre nous on reste sur notre idée de nouvelle puce avec nouveau chip.

Fonctionne en suivant les instructions mais il faut un nand x pour programmer votre puce avec les fichiers xsvf Par contre niveau boot, c'est long....

Les svf fournit ne fonctionnent que avec leur squirter BGA 1.2 à base de XC2C64A-7CPG56C, alors que les autres puces glitch sont à base XC2C64A-7VQG44C "The SVF files present in this package are working ONLY on XILINX BGA version part no.XC2C64A-7CPG56C" Après techniquement c'est le même type de puce donc à tester... En plus apparemment la "trouvaille" de la team squirter viendrait d'un leak d'information de la team TX... (info ou intox, on connait tx hein.... drama les feux de l'amour :s) http://www.team-xecuter.com/forums/showpos...amp;postcount=1 EDIT: Fonctionne pas mais fonctionne surement que avec le squirter BGA .... Contrairement au fichiers de la team TX qui eux fonctionnent correctement et peuvent être utilisé sur n'importe quelles puces

Ils ont fait vite lol...

Je suis les explications de la Team TX, nous de notre coté suite à nos recherches on a aussi envisagé une nouvelle puce (à base de CPLD Altera Max3000) pour le nouveau RGH sur fat et qui aurait assez d'espace pour un possible code pour corona lorsque ce sera trouvé (car actuellement le xilinx est plein à craquer) . En ce qui concerne le portage du glitch (slim) première version sur FAT, je ne sais pas ce que cela va donner honnêtement, est ce que cela sera fiable et rapide ? surtout pour les jaspers récalcitrante... A voir

C'était à prévoir vu que la jasper est celle qui ce rapproche le plus de la slim, j'attends de voir pour la falcon... La team tx avait trouvé la solution mais je pense qu'elle ne l'a pas sortie surement pour essayé de privatisé le truc avec j-runner :s Même si cela utilise le code fait pour slim c'est cool de partager leurs découvertes

On est le 12 , suite aux tests du dernier prototype A2, nous avons du modifier certaines choses concernant l'usb, il ne sera pas possible d'utiliser le port usb de la console comme cela a été fait avec le Glitch360Spi 2.0 qui est en full-speed. Le shark travail sur du Hi-Speed qui est sensible à différentes perturbations, chez certains il y a des interférences entre le shark et le southbridge, cela dépend de 1 du câble usb utilisé et de 2 du pc lui même, à part en utilisant un cordon usb blindé bien spécifique (cela ne vaut pas le coup car assez cher). Afin de sortir un produit totalement fonctionnel pour tout le monde, il y aura donc un petit pcb externe avec le connecteur usb. Le reste des spécifications du produit ne changent pas.

Non car cela demandera surement un nouveau cpld et un nouveau montage, nous préférons voir comment avance le hack sur corona avant de faire n'importe quoi... En tout cas à l'heure actuelle personne ne peut décemment affirmer qu'une puce existante serait compatible corona

Bizarre, soit disant ils passent à la v4 (qui n'était soit disant pas encore prête) et surtout le coup du mot de passe avec le texte "the king is dead", après bon c'est facile de récupérer sont domaine et son ftp... Et puis ils vont pas dire qu'ils ce sont faire piraté... Et aujourd'hui, apparemment leurs ligne téléphonique serait HS... On dirait vraiment une attaque contre logic sunrise

Vidéo en cours

Peut-être le passage à la v4 du site... Mais bon bizarre le message, puis pourquoi mettre ce genre de message si c'est une mise à jour du site Façon vu le warez qu'ils font aussi.... Puis toutes les magouilles (sur les taxes, la société à hond kong, les procès, etc...), un jour ou l'autre ils auront des soucis

Pour info tu sais acide, des composants électronique tu peux en avoir des vraiment PAS CHER via des brokers, par contre les conditions de conservation de ses composants sont pourrit. Les composants fonctionnent mal et ne dureront certainement pas longtemps, ils sont conservé dans des conteneurs à 50-60°, il y a un bail j'ai vu une video le mec reçoit des cartons avec des composants en vrac, les cartons bouffé par des souris etc... Ok comme tu dis certains font fabriqué en chine, mais attention c'est toujours avec des composants de bonne qualité avec des exigences bien précises, des normes de vérifications et de qualité... Si tu veux un bon produit à la limite tu fais fabriquer en chine mais tu n'achète surtout pas des composants au normes chinoises (pas cher) sinon ton produit sera pourrit (dsl mais c'est vrai) Tu sais quand il y a une différence de prix entre 1 composants et un autre c'est pas pour rien

Oui c'est compatible

Je redonnai l'information juste au cas ou Car sur certains forum apparemment le coup du câble blindé serait une découverte made in TX lol

Après il y a un moyen simple de faire un fil blindé contre les interférences. Il suffit de prendre 2 fils, de les tresser ensemble, un des fils sera le CPU_RST et l'autre le blindage qu'il suffira de raccordé à la masse. Ce 2e fil raccordé à la masse fera office de blindage, il captera les perturbations et les enverra à la masse. Mais bon c'est sur que ce n'est pas aussi performant que du câble blindé, mais cela fait parfaitement l'affaire pour l'utilité qu'on à besoin

Exact c'est pareil pour moi, l'ampérage sur l'alimentation correspondait à une corona (9,6A) pourtant c'était bien inscrit 10,83A au dos de la console

Moi je suis déjà tomber sur une slim 21 novembre 2011 et c'était une trinity, par contre c'est TRES rare qu'après septembre 2011 on trouve des trinity

Super tuto! Par contre pourquoi rogner le clip ? De base il ne ce connecte pas correctement sur la nand ?