bonx

cela signifie que de décaler le déclenchement du pulse de reset 1 cycle d'horloge avant ou après n'améliore pas le boot. Et c'est tout à fait exact, j'avais essayé comme beaucoup d'autres de décaler le pulse et de tester sur différentes cartes mères de slim et de phat, c'est très aléatoire.

ne mélanges pas mo et mb, 16Mo = 128Mb

complètement d'accord, cela a bien changé !

Ah ok je comprend mieux., c'est normal, les paramètres du smc pour la gestion de la nand sont certainement différents et non compatibles d'une version V2 à V1 (un peu comme sur les fat quand la nand est foirée et que le module spi ne peut plus rien lire) Quand je pensai au déssoudage de la nand je pensai à la lecture sur puce infectus par exemple (un truc du genre http://www.xavboxwii.com/fr/nand-flash-en-externe.php)

en fait le hana contient un synthétiseur pll. il génère plusieurs signaux d'horloge à partir du quartz de 27Mhz, a savoir: - clock cpu : 100Mhz - clock gpu : 100Mhz - stdby clock (le point que l'on utilise pour 'alimenter' la puce glitch (nécéssaire pour un cpld) : 48Mhz (et dans le code version slim, les fronts montants et descendants sont utilisés ce qui fait un fonctionnement à 96Mhz) - sata clock: 25Mhz et 100Mhz - pci clock : 100Mhz - audio clock : 24 Mhz - ethernet clock 25Mhz

La tournure de la news et les mots employés portent à confusion et laissent croire par extrapolation (visiblement comme dans ton cas) que la Corona a été glitchée et justement, c'est loin d'être le cas. C'est un peu pour imager, comme si un constructeur de voiture annoncait une voiture H2O Ready en expliquant qu'il a ajouté un réservoir d'eau sur la voiture (chose indispensable), en ajoutant qu'il ne reste plus qu'à trouver le réglage des injecteurs, et du coup les gens croient que la voiture va pouvoir rouler à l'eau.

Je pense que la fonction de contrôleur de nand précédemment dans le hana est maintenant gérée par le physon. Les fonctions du composants hana ont été réparties sur les autres composants. exact je suis en train de regarder pour m'équiper ou construire un espion i2c et spi pour comparer entre les cartes mères. Je pense plus que les adresses des registres pour lire la nand ont changé mais c'est à explorer. Sur ce point je suis surpris, je la déssoude ce we et je vérifie. Il me semble qu'un dump a déjà été fait puisqu'apparemment le CB est passé en 13121 ?

Personnellement je n'ai pas la science infuse, je passe de nombreuses heures à lire et apprendre. Ah oui ?! Personne ne sait si le cpu acceptera le pulse ou même d'être sous clocké (pour rappel cela ne marche pas sur xenon) Et juste au passage, si tu avais essayé de compiler le code du cpld, tu aurais vu qu'il est plein à craquer, donc si le ralentissement du cpu demande plus de code, c'est mort pour le x2c64a qui équipe toutes les puces actuelles. En tous cas chapeau sur le coté com et marketing.

Sérieusement, tu crois vraiment en ce que tu écris ?! c'est pourtant tellement ridicule. L'ajout d'un oscillateur ne permet en rien de prétendre à être "Corona ready" ni "d'être une exclu mondiale" Pour écrire des trucs pareils, je me dis sérieusement que tu n'as rien compris au fonctionnement d'une puce glitch As tu au moins jeté un oeil sur le code source de la puce et essayé d'en comprendre le contenu ?! Et "les temps de boot impressionnants. (10s, 15s, 7s et 12s)" Tu trouves cela impressionnant ? et tu crois réellement que l'oscillateur externe y fait quelque chose ? On en reparlera dans quelques temps !

+ 1 Le réel défi dans le glitch corona, va consister à : - faire marcher le dump de la nand - accèder aux bons registres i2c pour changer les paramètres du pll (d'autant plus que le quart du southbridge est passé de 27 à 25Mhz) - trouver le bon timing du glitch - faire un CB adapté - vérifier si le cpu n'a pas changé (le glitch ne marche peut être pas dessus) Alors c'est clair qu'un pauvre oscillateur de 48Mhz, c'est pas ça qui va tout solutionner !

Carrément ! Et franchement la possibilité d'ajouter d'un oscillateur est une évidence depuis le début, cela n'a pas été choisi par le concept original de GliGli pour des questions de simplification du design. De là à croire et annoncer que c'est prêt pour la Corona, cela relève soit de l'hyprocrosie soit de l'incompétence la plus totale. Bravo à toi Seb117 pour la démonstration.

eh ben si ! http://www.xavboxforum.com/index.php/topic...uces-en-soldes/

j'ai du fil blindé pour signaux radio, je vais essayer j'ai testé du fil multi-brin pour comparer au kynar que j'utilise toujours, pas de différences. je reste donc en kynar, c'est plus propre. Le tactac vient du signal reset en permance à 0v, le cpu enchaîne les resets en boucle.

c'est vrai, mais sur la corona, pas de risques, le point d'horloge n'est pas présent du tout !

le passage des fils est effectivement très important, spécialement le fil bypass dont le rôle est de ralentir très forteent l'horloge du cpu. ce signal est normalement à 0v, si il chope des interférences, cela peut engendrer des ralentissements du cpu (et non du reste de la carte mère) donc des freeze ou bloquages)

un peu plus et tu étais bon pour jeter ta console !

j'ai testé ce montage sur une jasper v4 très capricieuse, elle boote nickel à chaque coup (avec un condo entre 2 et 6 de 100nf et idem avec un 68nf) je regarderai à l'oscilloscope l'impact que cela a eu sur les signaux pour comprendre. pour la tresse, tu peux utiliser de la tresse à déssouder que tu allonges pour réduire son diamètre . @+

c'est surtout qu'il n'ont pas la même valeur (680pf et 680nf)

Désolé c'est inexact. Suivant les versions, il y a des différence sur l'utilisation ou non de l'usb de la console, le montage en carte fille, les tensions de fonctionnement, etc ../ cdt

non, pas de soucis sur les slims. il faut dire que quand j'ai fait le proto, j'avais une slim vraiment capricieuse dans les mains. Merci ! ok je vais regarder cette piste. je te dirai ce que ca donne !

Ce n'est pas la première remarque du genre que je lis (j'en ai lu aussi sur le mode dual nand) et je devrai effectivement penser à copyrighter... Pour information, je travaillais sur la version olimex et j'ai publié un article en septembre 2009 http://www.xavbox360.com/fr/jtag-programmation-nand.php puis j'ai travaillé le bonx spi v1 fin 2009 pour aboutir à un module fini en mars 2010 voir http://www.xavbox360.com/fr/module-usb-spi.php A l'époque le glitch n'existait pas. Et lorsque j'utilise quelque chose fait par une autre personne, je le cite et ne me l'approprie pas (Le schéma du module, le programme pour le microcontrôleur et le source ont été créés et mis à disposition par DarkstarTM en août 2009) et tous les modules spi ne sont que des copies de son travail sans l'avoir jamais cité. N'étant pas fan de découpe de console, j'avais exploré la solution de se brancher sur l'usb de la console, puis ajouté des fonctionnalités dans le microcontroleur, utilisé un concept de carte enfichable, etc ... Et pour le dual nand, je travaillai dessus juste ......... euuuuuhhhhhh ........... en 2007 ....... http://gbonx.free.fr/spip.php?article13 Je ne suis donc pas en mal d'inspiration Pour la désactivation du port usb je l'ai testé plus d'une fois et c'est facile à vérifier: il suffit de laisser le câble usb branché entre la console et le pc et d'allumer la console: le module disparait des périphériques et réapparait lorsque la console est éteinte. J'ai aussi travaillé sur le niveau de tension de fonctionnement du module v2 qui fonctionne en 3.3V (donc sans les résistances d'adaptation de 5v à 3.3V qui ne fonctionnent pas correctement car les niveaux des signaux mesurés envoyés à la console sont de 4.2V, donc en surtension) Ça aussi je ne me suis pas inspiré d'un autre module, je n'ai d'ailleurs pas vu d'autre modules fonctionner en 3.3v Cordialement

Bonjour, J'ai fait deux vidéos de démarrage du Xell, une sur Fat et une sur Slim Les vidéos sont faites avec 10 démarrages consécutifs, ce qui n'est absolument pas représentatif d'une utilisation normale, les condensateurs de la console n'étant pas déchargés de la même manière avec l'enchainement des démarrages / arrêt. La mesure du temps a été faite entre l'appui sur le bouton power et l'apparition du Xell (cela inclus donc le temps de boot propre à la console) On peut voir le glitch lorsqu'il a réussi faire un clignotement de la led centrale. En attendant qu'elles soient uploadées, voici les temps de boot relevés: FAT 1 : 8.2s 2 : 10.7s 3 : 9.5s 4 : 9.3s 5 : 9.2s 6 : 16.5s 7 : 23.8s 8 : 9.3s 9 : 9.4s 10: 16.4s SLIM 1 : 14.2s 2 : 14.4s 3 : 14.0s 4 : 9.0s 5 : 25.8s 6 : 9.0s 7 : 14.2s 8 : 12.8s 9 : 19.1s 10: 9.0s Il faut maintenant que je m'attaque à certaines Japser capricieuses (les 16mo marchent nickel mais les 256mo et 512 sont plus longues) Cordialement

Difficile à dire, je suis dans la réalisation d'une petite présérie pour tests. je dirai d'ici 3 semaines. Pour le prix cela dépendra du prix des composants et des circuits imprimés. Dès que j'ai regardé, je ne manquerai pas d'apporter plus de précisions. Cordialement De rien

Bonjour, Pour répondre aux différentes questions posées, voici quelques infos complémentaires: Ce ne sera pas un seul module mais 3 modules distincts interconnectables. - Le premier module "Spi" est une évolution d'un module existant (Module usb spi bonx) Ce module aura les fonctionnalités suivantes: * Lecture/programmation nand de la 360 * Compatible nandpro 2.0e / Xavprog * Fonctionnement par connexion usb sur la console ou fonctionnement en autonome * Capable de reprogrammer les modules glitchs (toutes version à base de xc2c64) à partir de fichiers svf (plus tard avec les fichiers jed) en moins de 4s * Détection mode démarrage de la console (via le bouton power ou autre mode) * Activation / désactivation module glitch (compatible tout module glitch) * Choix d'une nand en cas de dual boot (compatible cygnos et module nand bonx) Ce module pourra donc être installé dans la console, utilisé indépendemment comme programmateur de nand ou de module glitch (plus besoin de programmateur sur port parallèle ou usb) - Le deuxième module "BonxGlitch" permet de réaliser le glitch hack sur fat et slim. il est compatible avec les programmes gligli standards mais aussi avec des versions améliorées utilisables via le module spi. - Le troisième module nand sera un module avec une deuxième nand tel que le module cygnos, compatible fat et slim Ce module sera de dimensions réduites pour être soudable sur carte mère fat et slim, il n'aura pas de quicksolder points afin d'avoir une version compatible avec les différentes cartes mères. En découpant en trois modules, cela laissera le choix à toutes les possibilités (glitch seul, glitch + spi, glitch + spi + dual nand) @+++ Bonx

Hello, quand je parlais de permutation de la nand et de la mémoire spi, je parlai des composants de la carte du lecteur, pas de la carte de la ps3. Permuter les nand de la carte mère de la ps3 ne marchera pas, car une partie des données est probablement cryptée avec une clé stockée dans le cpu comme c'est le cas sur la 360. Il faut donc commencer par permuter la mémoire spi sur la carte du lecteur puis la nand si cela ne suffit pas. Dès que j'ai un peu de temps, je regarderai pour déssouder la nand de la carte du lecteur et repérer les pistes. Je verrai ensuite pour modifier mon soft qui utilise l'infectus et ainsi voir si je peux gérer la nand du lecteur. Si cela marche, il sera alors possible de lire et de repogrammer une carte de lecteur en conectant une infectus sur la carte du lecteur, ce qui éviterait de déssouder et ressouder ces composants. @+