xvassor

Bon j'ai un seul test renommer le nom du disque de mon install qui marche nickel et ca marche encore nickel donc c'est pas le truc .... j'y croyais vraiment ... Faut que je regarde les sources de ce FSD car j'y comprends rien a leur usine a gaz ...

c'est intéressant comme information mais je pense que le problème est pas loin de ce que tu dis. C'est bien un probleme de disque .... Je m'explique Supposons que FSD utilise le nom de la partition du disque dans sa combinaison pour définir le chemin ou se trouve un jeu. si tu dupliques ou pas ton install de FSD de HDD1 mais si tu as le malheur de dupliquer ton disque dur USB sur un autre disque, le simple fait de changer de disque fait que ca ne marchera pas si le volume du disque a changé lui aussi. >>>> C'est peut être ça le problème ! <<<< La je ne sais plus vu que j'ai fais mes tests sur un seul disque puis 2 deux différents ... c'est peut être ça le véritable probleme ... un problème de nommage du volume du disque dur. Merci pour cette piste en tout cas ... Pour vérifier cela: - Tester une install de fsd qui marche bien avec un disque USB qui a pour label TOTO par exemple - Dupliquer le contenu de toto sur un nouveau disque dur qui a pour label TITI - Lancer FSD et regarder si celui ci voit bien ses jeux (réponse non normalement) - changer le nom du disque TITI par TOTO - re lancer FSD puis Tester, si tout est revenu a la normal, si c'est bien cela, ça doit marcher ! cette technique du nom de volume est utilisé par les logiciel de synchronisation de données, ils ne mémorisent pas la lettre du lecteur externe e: par exemple mais son nom logique (volume XBOX360_GAMES par exemple), pourquoi car la lettre peut changer si tu as branché d'autres disques USB avant Sur xbox360 si tu as au moins usb0 et usb1 donc si tu utilises deux disques dans ce cas ton disque de jeux peut être soit sur usb0 soit sur usb1 dans tous les cas il faut que FSD soit capable de le retrouver ... a tester !

j'ai cru comprendre que c’était une eMMC (embeded MMC) donc ce n'est plus une NAND serie qu'on adresse via un SPI mais une carte flash type SD donc on doit lui parler via un controleur MMC, c'est ce que doit faire le phison d'ailleur SD et MMC c'est même combat, ca marche avec des commande qu'on envoie et c'est la carte MMC qui lui repond ensuite .... Si c'est bien une MMC like ???

Ca marche peut être sur une petite config mais chez moi c'est une explosion de popup windows me demandant d'envoyer des emails a son créateur pour lui expliquer tous mes problemes. D'ailleurs seul un Kill process permet d'arreter ces ouvertures infinies de boites de messages d'erreurs ... donc inutilisable pour l'instant ....

merci pour vos réponses mais personne ne sait pourquoi ça ne marche pas ! Je recherche la méthode qui va me permettre de dupliquer mon install et non comment faire une install from scratch. En effet pour une install qui marche il faut faire un clean de la base de donnee via FSD puis se connecter a internet puis telecharger les images ... Mais moi je ne veux pas .... Je veux juste dupliquer mon installation ... Franchement je n'arrive pas a voir quel truc est manquant, surement un fichier qui est recopier dans hdd1:\content mais quoi ? Un petit challenge .....

Bonjour, J'aimerai savoir si quelqu'un a réussie à dupliquer une installation de FSD avec sa base de données. Je m'explique j'ai deux consoles: Un slim qui est connecté au net par wifi au salon et une jasper qui n'a pas internet ni réseau dans ma chambre. J'ai: - Tous mes jeux sur mon disque dur externe USB que je branche soit au salon soit dans ma chambre. - FSD installé sur HDD1 de chaque console. J'ai fais une copie exacte du repertoire FSD de la slim vers la jasper Quand je lance FSD depuis la slim, je vois bien tous mes jeux (chemin des jeux bien visible dans settings et mes jaquettes qui sont toutes visibles) Quand je lance FSD depuis la jasper, je vois aucun de mes jeux (chemins des jeux effacés donc aucune jaquette de visibles) note: si je connecte ma jasper a internet et essaye de mettre a jour le chemin des jeux, la c'est la cata .... je vois certains jeux mais pas tous, aucune jaquette bref FSD en re-scannant a détruit sa base de donnée ..... ca bug dur dur ..... il est complétement aux fraises le petit !) Question: FSD doit recopier des données autre part que dans son répertoire d'installation (ici HDD1:\Applications\FSD\...) ou ils ont codés comme des cochons en prenant en compte des parametres propre a chaque console comme le numero de la console ou je ne sais quoi d'autre. Peut être y a t'il des fichiers dans hdd1:\Content\ .... Je recupere bien dans settings certains paramètres comme le nom de la console (xbox360 name for samba) mais pas tous comme le Chemins des jeux et les info de connexion du plugin ConnextX par exemple Quelqu'un a une idée ? Merci

Ce soft est beau, assez complet mais malheureusement tout bogué donc inutilisable ! Pour faire reconnaitre sa base il faut pointer sur le répertoire FSD et non les sous repertoires: ex: hdd1:\Applications\FSD usb0:\Applications\FSD ensuite il faut importer les données sur le PC mais la impossible a faire ça plante dur dur .... quand vous avez beaucoup de données ... il gère mal les chemins long, les grandes listes bref c'est pas du tout testé ! Bien dommage car pourrait être super bien, notamment pour réparer une base de donnée FSD bancale/cassée ... voir pour cloner une installe !

sinon les freezes c'est au démarrage ou c'est durant un jeux ou a un lancement d'un nouveau jeux ? Je dis ca car j'avais la console qui plantait au lancement d'un 2eme jeux. Le probleme a ete corrigé en updatant daslaunch, je pense que ca venait de l'incompatibilité du format des patchs JTAG/RGL chose qui a été changé sur les dernières versions ...

pour répondre OUI les condensateurs céramique servent ici de filtrage , ils vont donc améliorer la qualité/la forme du signale en virant les impulsions parasites. Pour ceux qui ne le savent pas un Glitch c'est une impulsion parasite qui vient déformer un signal en s'y rajoutant. Du coup il peut y avoir un risque de désynchronisation/mal fonctionnement du système harware au niveau des fronts montant/descendant car il va prendre le glitch (l'intrus) pour quelque chose qu'il attendait alors que c'est faux. Bref si c'est une synchro qu'il attendait alors ca sera une mauvaise synchro qu'il ferra a cause du glitch car il la ferra trop tôt. Le condo sert a realiser un filtre passe-bas (RC) Lorsque la fréquence augmente, une plus grande partie de l'énergie est dirigée vers la masse et la tension de sortie diminue progressivement. Le filtre laisse passer les fréquences basses et atténue les fréquences hautes. c'est le rôle de ce filtre ...

un condo de 220 ohm, tu veux dire une résistance de 220 ohm ? Certaines personnes parle du point A et du point F, en faite ils parlent tous du même point mais font référence a leur carte respective. Sur la X360Glitchip de Librasoft (carte FR) c'est le point F et sur la Matrix Glitcher 360 (carte US) c'est le point A Signal CPU_RST: J8C1.2 sur PHAT et FT4R2 sur Slim Sinon le condo sur Slim et Phat c'est primordial ! Pour la Phat si tu la cable comme sur mes photos avec le CPLD que tu veux ça ne peut que marcher ! Courage ...

Même combat pour la slim: Allez hop voici un 2eme retour d’expérience: donc effectivement comme sur jasper tout est dans la qualité des fils et de la capa qui est reliée a la masse: Donc prendre du multi-brins et non kynar30. sur slim tout peut se faire sans kynar30. Plus la peine de mesurer la longueur du fils qui est reliée a FT4R2, il faut juste le faire passer par le petit trou qui est juste a côté et de faire le tour du ventillo dans le sens inverse des aiguilles d'une montre (sens trigo) donc tous les fils au plus court, pour cela placer le cpld a cote du radiateur (voir photo) Pour C3B10 comme sur Jasper j'utilise toujours le point alternatif qui est situé sous la carte mère plus facile a souder et moins sensible aux bruits (je pense que oui) Pour répondre à certains point alternatif=même chose que point original (resistance de 0 ohm si vous voulez contrôler a l'ohmetre) Capa de 270pf au lieu de la 220pf initiale. version 50v (plus précise que la 500v ou 1000v pour répondre à certains) ci joint mes photos du montage: http://img841.images...6/img0251ko.jpg http://img835.images...8/img0252hu.jpg http://img694.images...8/img0256rd.jpg Ca boot en moins de 20s 90% du temps !

Bonjour, après avoir aussi longtemps perdu mon temps a essayer de faire booter 3 jasper 16MO en moins de 30 secondes j'ai enfin trouvé la méthode qui permet de le faire en moins de 10s ! Méthode qui reprend ce qui a été lu sur tous les sites mais je résume le tout en modifiant un peu la méthode. Il y a 5 points a respecter - 1) de la patience - 2) savoir souder propre - 3) choisir le bon condensateur qui devra être relié à la sortie de la résistance de 22K qui va vers CPU_PLL_BYPASS - 4) Bien choisir le type de fil a utiliser en fonction du point a souder. - 5) Bien placer ses fils (1) + (2) => c'est OK pour tout le monde ! reste (3),(4),(5) .... Pour le (3) moi je n'utilise pas de 680pf mais une 100nf. Il n'y a pas photo avant en 680pf je bootais (quand ca voulait bien) en environs 30s au mieux sur une console 2 fois a froid puis plus jamais sur deux autres consoles. Avec la 100nf soit ca marche au 1er reset soit eu deuxieme (10s maxi) Pour le (4) - Mais la valeur de la capa ne suffit pas pour obtenir un boot parfait ! Il faut utiliser du multi-brins la ou c'est possible et éviter le kynar au maximum ! - Partout du multi-brins sauf la ou c'est trop dur a souder c'est a dire uniquement pour CPU_PLL_BYPASS, le point en dessous de R7R17 (face arrière) - Pour STBY_CLK (C3B2) j'utilise le point alternatif qui se trouve en face arrière et qui est facile a souder, ce qui permet d'utiliser du multi-brins sans problème. Pour le (5) La capa et le multibrins c'est bien mais c'est encore mieux si vous placez vos fils la ou ils seront le moins parasité ! j'ai trois fils en face arrière qui remontent ensuite au CPLD et tous les autres sur la face avant. donc on regarde les photos et ont fait pareille. Attention le faite de rajouter trop de silicone ça va modifier le comportement du glitch donc ne pas trop en abuser. ci joint les photos du montage: http://img43.imageshack.us/img43/7762/img0301km.jpg http://img838.imageshack.us/img838/9890/img0238c.jpg http://img856.imageshack.us/img856/5743/img0240mox.jpg http://img828.imageshack.us/img828/7228/img0302l.jpg J'ai testé ce montage sur 2 types de CPLD, le Cool Runner II C-MOD de Digilent et le Cool Runner II version chinoise de ngzhang. Pour moi tous les CPLD sont identiques si ce n'est les valeurs des capas et resistances qui gravitent autour. Mais en faisant les ponts qui vont bien nous devons tous arriver au même schema vu que le fpga est le même. La réussite est dans la manière de - placer ses fils - quel type de fils il faut prendre - quelle capa choisir

bon échec cuisant ... la capa sur CPU_PLL_BYPASS n'a rien fait. Comme j'avais pas de capa correpondant j'ai mis des capas de 220 en parallele connecte sur la masse. J'ai essaye pour une valeur total de 220,440 et 660pf mais aucun effet positif. ensuite j'ai fait en plus la technique de la capa de 470pf en serie entre CPU_RST et le CPLD et rien aucun changement ... Tout ce que j'ai constate comme beaucoup d'autre c'est que la console boot a froid instantanement du 1er coup ! a chaud jamais ... Je parle pour une JASPER 16MO nouveau southbridge Je comprends plus rien car il ya trop d'info contradictoire: - cas 1: POST_OUT1 de 32 cm (ou 50 cm) - cas2: CPU_RST de 32 cm (ou 50 cm) - cas3: CPU_PLL_BYPASS avec capa de 680pf en // connecte sur la masse le tout en serie avec la 22K - cas4: capa de 470pf en serie sur CPU_RST Moi je prends le 1.8v directement sur le regulateur de la CM, peut etre que les autres y arrivent avec les 3 diodes et R + C ? J'avais fait ce montage mais j'avais constate que la tension n'etait pas de 1.8v mais bien plus élevé donc j'avais tout viré. Tout ce qui est sur a 100% c'est que les signaux sont hyper sensibles aux perturbations pour CPU_PLL_BYPASS et CPU_RST et POST_OUT1 (en gros tous sauf les alims quoi que ...) donc l'emplacement du passage des fils est important. Pour la slim la technique du fil autour du ventillo semble la meilleur technique pour CPU_RST (a moins que j'ai confondu avec POST_OUT1 ?) J'ai doublé CPU_PLL_BYPASS et je constate que mon ventillo fait moins de bruit de ronronnement (cable tjs au même endroit) donc je pense que c'est un + Mais bon ca marche pas bien ....

j'ai vu sur XBH qu'en mettant une capa de 680pf entre la masse et CPU_PLL_BYPASS ca faisait booter le xell en moins de 10 secondes !!! Ca marcherait aussi avec des capas de 220/270pf Il faut donc essayer a 220pf puis monter progressivement jusqu'a 1nf Tester avec succes sur Jasper 16MO et 512MO J'essaye ce soir moi aussi ...... Je confirme que les signaux sont bien parasités par la CM et que le faite de rallonger un fil pour le sortir de la CM ne fait que repousser le probleme. CPU_RESET est tres sensible donc pour moi il doit etre au plus court ! Plus c'est long plus il va faire antenne et risque de choper encore plus de parasites (je vais donc le cabler au plus court en laissant le CPLD sur le dessus du connecteur video) Je pense qu'on ai sur la bonne voie ....

J'utilise le CPLD du pere Gligli donc la programmation de la puce c'est bibi qui l'a fait donc le probleme ne vient pas de ca. En revanche j'ai constaté que ce probleme etait pour une jasper 16 mo nouveau Southbridge peut être est ce pas le cas pour l'ancien Southbridge? Pour tester chez vous j'explique la manip pour avoir l'info: Il existe 2 types de jasper 16MO l'ancien et le nouveau pour savoir qu'elle version on a il suffit de verifier 2 choses: Si Jasper 16MB alors vérifier si version 1 ou 2 ? Si Jasper 16MB avec nouveau SouthBridge on doit avoir: flashconfig=00023010 orig.bin offset 0x071 => 0x01 (ou 0x00 je crois bien pour l'ancien SB) orig.bin offset 0x4400 (correspond au rawkv.bin offset 0x200) => 0x00,0x01,0x00 (new SB) au lieu de 0x01,0x00,0x00 (ancien SB)

logiquement tu flashes ton lecteur en premier car si j'ai bien compris le nouveau custom firmware du lecteur dvd va se proteger des eventuelles reflashage forcer de la part du kernel qui lui voudra mettre le sien l'officiel compatible xgd3 et de t’empêcher aussi de récupérer ta cle dvd si ce n'est deja fait mais bon avec le hack tu peux la récupérer d'une autre maniéré.

Donc 32 cm pour FT5R2 (POST_OUT1) et 20 cm pour FT4R2 (CPU_RST) pour une X360Glitchip. Les autres au plus court ou peu importe (dans la limite du raisonnable) Une autre personne a t'il tester ces valeurs sur d'autres mod-chip comme le CPLD de Gligli ? Moi j'ai un dump de slim 4go identique a celui d'acid0 cb 9188 avec un cb2 qui a un PD (pairing data) sans valeur comme le sien aussi Merci pour vos réponses.

J'ai fais deux diff entre le RGL de la slim qui marche et celle qui ne marche pas: Les deux log du build du gg glitch sont 100% identique le diff des 2 SMC.bin: Offset , NOK, OK 00000000: E6 1E 00000001: 92 B1 00000002: 1B 80 00000003: 4E B9 ici j'ai E6921B4E au debut du smc.bin de la slim qui ne boot pas sur le xell ci quelqu'un sait a quoi correspond ses 4 premiers octets je suis preneur ! le diff du CB_A 00000010: F0 AC 00000011: BC 9B 00000012: 38 88 00000013: C5 8B 00000014: E1 25 00000015: 0E 9E 00000016: 29 74 00000017: 4B B8 00000018: DE A1 00000019: 37 7A 0000001A: 82 2C 0000001B: 97 69 0000001C: E7 65 0000001D: D8 30 0000001E: 1C 6A 0000001F: 12 44 qui veut dire que le HMAC salt (used for decrypting the loader) est different sur les 2 CB_A pourquoi pas .... par contre mes deux CB_B sont bien different de l'offset 10 jusqu'a la fin mais ca c'est normal car le CB_B present dans le output folder est en mode crypté (sauf erreur de ma part ?) et si je me rappel bien il l'est a l'aide de la cle CPU (CB_B is RC4 crypted, the key comes from the CPU key) comme c'est le CB_A qui est glitché et non le CB_B donc a ce que je peux comprendre tout est normal j'ai bien le même CB_A seul mon CB_B est crypté différemment donc le timing du hack devrait etre bon . Bon c'est le montage qui doit merder ou c'est la carte mere qui est legerement differente ? par contre j'ai le Pairing data du CB_2 qui est non renseigné (champ vide) donc null je pense, comme j'ai jamais vu ça ailleurs je m'inquiète sur la cette version de CB_2 !!! log.txt

Si on parle de l'archive de gligli "reset-glitch-hack-v1.1" et non de ggbuild "ggbuild-0.33b" non le CB n'est pas fournie seul le CD est fournie. En revanche j'ai bien après le build du hack gligli dans mon "output" folder deux fichiers "CB_A.bin" et "CB_B.bin" qui ont étés extraits de ma nand d'origine (ainsi que le SMC.bin). J'ai déjà réalisé avec succès le Reset Glitch Loader sur une autre Slim peut etre que si je reprend son CB ca pourrait marcher ?

Même problème le Hack ne veut pas prendre la main. J'ai fais une slim 4go qui a marché du 1er coup, boot en moins de 30 secondes chaques fois mais cette 2eme slim est recalcitrante ... J'ai remarqué que le PD du CB2 etait NULL !!! Est ce bien normal ? Ci joint les Infos J'ai fais 2 dumps identiques donc je ne pense pas qu'ils soivent tous les deux nazes avec un spi flasher custom qui a toujours marché nickel. Le ventillo est relancé dirons nous toutes les 5 secondes donc le CPLD et la NAND sont correctement flashés Montage vérifié 10x (connection, soudures, continuité) Il me reste deux pistes: - Soit le code du CB 9188 est différent des autres ce qui expliquerait que la tempo n'est plus en phase donc glitch impossible a réaliser. - Soit c'est cette histoire de longeur de fils mais la on ne parle pas d'optimisation du temps de boot mais bien de disfonctionnement ! J'utilise une capa de 220pf (pas de 270pf sous la main) car la 220pf marchait bien sur la 1ere slim.... avec le meme CPLD que gligli (version US non chinoise) Vcc et masse en fils normal mono brin (diametre des trous des connecteurs servant a la lecture de la nand) et le reste en kynar AVEZ VOUS DEJA EU un PD (Pairing Data) avec une valeur vide (NULL je pense) Merci pour votre aide

Idem pour moi sur une jasper 16mo, la console boot mais au bout d'un temps incertain. Ca peut aller de 5 secondes a 16 minutes ! Rien a voir avec la longeur du cable qui va diminuer le temps de boot de 2-3 min maxi Je pense plus au diametre du fil utiliser qui n'est pas bon ... Si quelqu'un a eu ce probleme et qu'il a corrige le tir je suis preneur ... ce probleme sur les jasper 16 mo j'ai du le voir sur differents topic au moins 5 fois !

Pour savoir si ta carte CPLD est bien programmé si tu n'a pas cable jtag a relier a ton PC il faudrait espionner la sortie qui genere le glitch c'est a dire de voir si cette sortie toogle de temps en temps si l'impulsion sort bien du chip (la pin du reset) mais bon il te faudrait un oscillo car le pulse est super cours. note que si les sorties bougent c'est qu'il y a bien quelqu'un a l'interieur qui pedale pour toi ... Pour la capa (condo ceramique) si tu as un CPLD tout fait (produit commercial) tu ne peut avoir ce probleme logiquement sauf si vraiment la poisse s'acharne sur toi .. et la capa ne concerne que les SLIM par les PHAT.

Tu peux avoir 3 problemes: - Le reset glitch hack de gligli n'est pas bien ecrit dans ta nand - Ton cpld n'est pas bien programmé - ton cablage est merdique si c'est Ok tu dois voir clignoter une led en vert et voir ton ventilo demarrer puis reprendre de temps en temps si c'est le cas c'est que le hack essaye de prendre la main. Ensuite pour les slims si la capa n'est pas bonne ta console ne glitchera jamais. Donc essayer avec une autre capa de marque differente la 220pf de la doc de gligli marche sur a 100% pas forcement optimal (tot de reussite) mais marche sur. Tester si le 3.3v arrive bien au CPLD et qu'on a bien une tension de 1.8v en 5 pour les phat

Oui en effet certains sujet son sensible dirons nous ... A l'origine les hackers ne divulguaient pas leurs infos car ca fermait les failles de securites mais la on ne parle pas de divulguer une faille mais d'expliquer comment marche les choses ...