ManiAk Avci

Bonjour,

La seule puce à ce jour est l hwfly pour ta console ou alors trouver quelqu un qui aurait un sx core lite dans ses tiroirs.
Et pour le cfw atmosphere.
Il y a ce qu il fait sur le forum.
Ps : pas de demande de liens pour achat de puce ici

Bonjour,

Dans ce sujet je vais tenter de résumer les diverses infos concernant le fonctionnement des puces SX Core/Lite selon les différents modèles de consoles sur lesquelles elles peuvent être posées.

Attention: Ce sujet n'est là que pour donner des infos et non pour répondre aux questions sur l'installation d'Atmosphere ou la création d'emunand par exemple. Cependant si vous avez des informations complémentaires ou des suggestions à apporter à ce sujet (notamment pour la pose de la puce ou les infos concernant les codes couleurs de celle-ci car c'est un sujet que je ne maîtrise pas du tout) elles seront les bienvenues.

Le fonctionnement basique de la puce avec son firmware d'origine

De base, la puce recherche le fichier "boot.dat" à la racine de la SD et tente de l'exécuter. Ce fichier ne peut être que le "boot.dat" de SXOS ou celui du SX Gear, ces fichiers sont trouvables via cette page.

Le fonctionnement basique de la puce avec le firmware Spacecraft

Avec ce firmware, la console recherche un payload nommé "payload.bin" placé à la racine de la SD et tentera de le lancer. Personnellement, je recommande d'utiliser Hekate comme payload de lancement car il permettra ensuite d'avoir accès aux payloads placés dans le dossier "bootloader\payloads" sur la SD.

Attention: Avec le firmware Spacecraft, la licence SXOS livrée avec la puce ne fonctionnera plus.

Le lancement d'un payload via le menu de SXOS

En maintenant le bouton "volume +" de la console au démarrage du premier menu de SXOS, un menu apparaitra. Outre la possibilité de lancer le CFW ce menu contient un menu "options" qui est très pratique (permet de dumper la nand, de créer une emunand ou encore de lancer un payload placé à la racine de la SD).

Pour lancer un payload il faut donc passer par ce menu d'options puis pour les consoles Erista uniquement aller dans le menu "SX Core" et faire "Clean Up" et accepter de faire le nettoyage et enfin revenir une fois en arrière, aller dans les payloads et lancer le payload souhaité. La phase "Clean Up" est très importante et à faire à chaque fois que la console est redémarrée grâce à la puce sur les consoles Erista qui peuvent facilement griller des Efuses si cette étape n'est pas respectée.

Note: Pour les consoles Mariko c'est un peu différent, la phase "clean up" doit être faite une fois puis lancer Hekate et enfin Atmosphere. Normalement cela ne fonctionnera pas donc il faut éteindre la console, mettre en place les fichiers du SX Gear pour lancer Hekate au démarrage de la console et enfin lancer Atmosphere. J'ai encore des difficultés à identifier le fonctionnement exact de cette procédure mais il faut tenter ce genre de choses et essayer les différentes façons de lancer Atmosphere, une fois que ça passe ça fonctionnera sans problème.

Personnellement, le seul payload que je conseil de lancer via cette méthode est Hekate puis ensuite de lancer le payload voulu (pour rappel les payloads sont à mettre dans le dossier "bootloader\payloads") car SXOS a une façon de lancer les payloads qui peut souvent causer des problèmes, par exemple Lockpick-RCM fonctionne souvent mal en le lançant via SXOS directement et Atmosphere à partir de la version 0.20.0 pose aussi des soucis.

Note pour les consoles Mariko: Sur ces consoles le redémarrage à chaud sur un payload n'est pas possible (on ne peut par exemple pas utiliser le homebrew Payload_launcher), de fait certains homebrews ne fonctionneront pas pour lancer un payload avec ces versions de consoles (par exemple Haku33, il faut donc utiliser des techniques un peu détournées comme expliqué sur ce sujet.

Utiliser le fichier "boot.dat" du SX Gear (console Mariko uniquement)

Ici nous avons donc le fichier "boot.dat" qui remplace celui de SXOS qui est lié à un fichier "boot.ini" qui contient le chemin du payload à lancer, par défaut il s'agit du payload nommé "payload.bin" et placé à la racine de la SD.

Pour utiliser cette méthode de lancement, remplacer les fichiers sur la SD pour mettre en place les fichiers du SX Gear, ni plus ni moins. Une fois cela fait le payload pointé par le fichier "boot.ini" se lancera.

Comme pour la section concernant le lancement de payload, je conseil d'utiliser Hekate au lancement puis de lancer le payload souhaité (voir la section de lancement de payloads de ce sujet pour plus de détails).

Les choses à ne pas faire

• Ne jamais activer l'auto-RCM.
• Ne pas utiliser ChoiDuJour-NX (à remplacer par Daybreak qui n'est lançable que via Atmosphere par contre), particulièrement pour les consoles Mariko pour lesquelles il pose des soucis avec la partition "BOOT0", empêchant Atmosphere de fonctionner correctement ensuite.
• Ne pas utiliser Incognito (méthode via Tinfoil, Incognito-RCM, Incognito ou encore NXNandManager) sur les consoles Mariko car cela brick la partition PRODINFO et empêche la console de démarrer. La seule méthode est, pour Atmosphere, d'utiliser le fichier "exosphere.ini" placé à la racine de la SD et de le configurer comme suit:
  

  [exosphere]
  blank_prodinfo_emummc=1
  blank_prodinfo_sysmmc=1

• Pour les consoles Erista, ne pas faire le "Clean Up" avant de lancer autre chose que SXOS (à faire à chaque redémarrage de la console si celle-ci redémarre grâce à la puce), exception faite si vous avez flashé Spacecraft.
• Ne pas faire le dump de la nand et des clés.
• Ne pas utiliser d'emunand, ceci n'est pas obligatoire mais est très vivement recommandé (emunand via "hidden partition" recommandée).
• Ne pas lancer Android ou Linux sur une console Mariko, pour l'instant ces systèmes ne sont pas adaptés pour ces consoles et risquent d'endommager le matériel plus qu'autre chose.

Je n'arrive plus à booter en firmware normal alors que je suis sous la dernière version de celui-ci

Ici il est très probable qu'un bug d'Efuses se soit produit (en lançant un payload incorrectement par exemple), regardez donc avec Hekate le nombre d'Efuses grillés (menu "Console infos" puis "Fuses" et regarder le nombre contenu dans "burn fuses"). Si vous avez un nombre du genre "15 - 0" alors cela signifie que vous êtes en firmware 12.0.2 et ceci est normal, par contre si vous voyez un nombre du genre "15 - 10" alors un problème s'est produit et il est donc peu probable que vous puissiez un jour redémarrer la console en mode officiel (sauf en passant par l'option "stock" de Hekate, c'est pas parfait mais bon faute de mieux...

J'ai utilisé ChoiDuJour-NX sur ma console Mariko et je n'arrive pas à lancer Atmosphere

La solution ici est de refaire une partition BOOT0 adaptée aux consoles Mariko, par exemple à l'aide du logiciel EmmcHaccGen et des clés de la console puis de la flasher sur la nand.

Si ChoiDuJour-NX n'a été utilisé que sur l'emunand et que la sysnand se trouve sur le même firmware, il est possible de dumper le BOOT0 de la sysnand et de remplacer la partition BOOT0 de l'emunand par celui-ci.

Si aucune des solutions ci-dessus n'a fonctionné, il faudra trouver un dump de BOOT0 d'une console Mariko sur le firmware à lancer pour le remplacer.

Comment reconstruire une nand

Ici on va partir du fait que la nand est totalement HS et qu'aucun dump n'est à disposition, si vous avez certains des éléments certaines choses ne sont donc pas à faire ou peuvent un peu différer.

Bon déjà, il faut savoir que la console ne pourra plus jamais se connecter aux serveurs de Nintendo car le PRODINFO est perdu.

Commençons par le dump des clés, le mieux étant de posséder une autre console sur un firmware supérieur ou égal au firmware 7.0.0 et du même type que la console ciblé (Erista pour Erista, Mariko pour Mariko car si on inverse ça risque de ne pas fonctionner correctement). Si vous en possédez une, mettre la nand de l'autre console sur la console à réparer et dumper les clés via Lockpick-RCM (ne pas oublier le "Clean Up" sur les consoles Erista avant de lancer le payload et passer par Hekate si passage via le menu de SXOS). Si vous n'avez pas d'autre console à disposition, il faudra générer un firmware supérieur ou égal au firmware 7.0.0 grâce à EmmcHaccGen (attention à bien générer des firmwares pour le type de console ciblé) puis flasher les partitions "BOOT0", "BOOT1" et les partitions "BCPKG*" sur la nand (ces partitions ne nécessitent pas de clés car elles ne sont pas chiffrés) puis dumper les clés (même règles sur le "Clean Up" qu'énoncées un peu avant). Je ne détaillerai pas comment flasher ces éléments, regardez le Github de Hekate pour savoir comment faire.

Une fois les clés dumpées le débrickage se passe comme pour n'importe quel autre console, par exemple via cette méthode sauf qu'au lieu d'utiliser ChoiDuJour on utilisera EmmcHaccGen (attention encore une fois à bien générer un firmware pour le type de console ciblé) et un firmware égal à celui se trouvant sur la nand qui a servie à dumper les clés (cette seconde condition ne semble pas obligatoire mais je n'ai pas pu faire de tests assez avancés pour éliminer totalement ceci, la chose certaine est qu'il faut flasher un firmware supérieur ou égal au firmware 7.0.0). Un autre point qui diffère, Memloader ne fonctionne pas sur ces consoles donc on pourra utiliser TegraExplorer pour copier les fichiers au bon endroit sur la nand.

Si les clés posent un souci, là l'opération est plus délicate car il faut avoir un dump d'une nand déchiffrée, le chiffrer avec les bonnes clés et enfin le réinjecter puis effectuer l'étape précédente. Dans ce cas et si on a plus le PRODINFO original de la console (autrement il suffit juste de le réinjecter sur la nand), il y a également autre chose à faire, regénérer un PRODINFO pour la console grâce au payload ProdinfoGen. Pour cela on a donc deux possibilités:

• Si on dispose d'un PRODINFO doneur (par exemple celui d'une console déjà bannie), on le déchiffre puis on le renomme "donor_prodinfo.bin" et on le met dans le dossier "switch" de la SD; on y mettra également le fichier "prod.keys" de la console s'il ne s'y trouve plus. On lance le payload ProdinfoGen puis on utilise l'option "Generate from donor". Si tout se passe bien, un fichier "generated_prodinfo_from_donor.bin" est créé, on le chiffre avec les clés de la console et on le réinjecte sur la nand.
• Si on ne dispose pas d'un PRODINFO donneur, on mettra juste le fichier "prod.keys" de la console dans le dossier "switch", on lance le payload ProdinfoGen, on utilise l'option "Generate from scratch", on chiffre le fichier "generated_prodinfo_from_scratch.bin" généré par le payload avec les clés de la console et enfin on injecte ce fichier sur la nand.

Je rappel que pour beaucoup de ces actions vous pouvez utiliser mon Ultimate-Switch-Hack-Script (peut créer un firmware avec EmmcHaccGen facilement, chiffrer/déchiffrer une nand ou parties d'une nand, etc...).

Débricker une puce

Si un problème survient, par exemple durant le flashage du firmware Spacecraft (voir cette page pour plus d'infos sur ce firmware, la puce peut être totalement brickée (d'ailleurs merci le connecteur USB tout pourrit de la puce).

Pour l'instant je ne vais donner que les sujets en anglais car je n'ai pas encore testé par moi-même, on a donc ce sujet qui contient des infos intéressantes et cette vidéo.

Conclusion

Je rappel que je n'indique ici que se qui diffère entre une console équipées d'une puce SX Core/Lite d'une console non patchée non équipée d'une puce SX Core, pour le reste cela fonctionne de la même façon donc les infos de la FAQ ou de ces infos de base restent globalement valables, notamment celles concernant la création d'une emunand ou l'installation d'Atmosphere ou d'installation de contenus.

Pour les anglophones, voici cette page qui explique comment installer Atmosphere selon différentes configurations possibles.

Encore une fois, si vous avez des suggestions ou améliorations à apporter n'hésitez pas à m'en faire part, j’essaierai de mettre à jour les informations.

Les NSP créés par NRO2NSP ne fonctionnent plus avec les dernières versions d'Atmosphere (à partir de la version 0.19.0), maintenant il y a ceci.

Bonjour oui nro to nsp.

https://github.com/R....6.-.Beta.4.zip

Tu change ton image de nsp et tu la colle sur ta sd.

J'ai jamais eu ce genre de soucis. Pour commencer, si tu désinstalles le jeu et tout son contenu lié (mise à jour, DLCs) via DBI ou Goldleaf est-ce que le problème persiste? Si oui je pense qu'il faudra que tu refasses ton emunand.

Autre piste, est-ce qu'un fichier de log se cré dans le dossier "atmosphere\creport" (ou dans un autre des dossiers d'erreurs du dossier "atmosphere") quand la console fait cette erreur? Si oui fais un copier/coller du texte de ce fichier pour voir si un éventuel module pose problème.

OK donc c'était un problème de sigpatch
Bon jeux

Il faut que tu configure les plugin correctement mais fais aussi attention il y'a certains jeux notament comme mgs et vandal heart qui necessitent des patchs speciaux pour etre lu comme pour la gravure va sur psxrenzokuken il y a tout y compris une section pour les patch etc...

Edit

Pas bon en quoi?
La batterie se videra plus vite sinon je vois pas.
Les réglages en mode portable:
cpu: 1020 --> 1785
GPU: 307 --> 921
RAM: 1331 --> 1600
Ce sont des valeurs que la tegra peut atteindre sans soucis.

La batterie aura une durée de vie un peu moins longue mais je doute voir la différence.

Vaux mieux mourir que lire des betises pareille .... deja l overclock est dangereux c est bien precisé quand tu le fais tu pousse le cpu et gpu en dehors de ses frequences et ca le rends carement instable c est meme precisé que ca peut occasioné des freeze de plus d'ou tu as vu qu'il y'a besoin d overcloquer pour la psx serieux faut arreter 2 min 2 post 2 réponse de ta part 2 conneries le post de miguel il demande a passer sous ams tu lui envoi un lien avec aucune info sur sa question y'a un moment ou si tu connais pas le sujet dit rien c est preferable tu vas lui faire overcloquer sa switch inutilement et si ca lui cause des soucis car le tegra de la switch etant deja pas super fiable vu tout les souci d ecran bleu et ... c'est pas toi qui va devoir casquer derriere ..... y'a des personnes assez qualifiés ici pour répondre a ce genre de sujet .....

Le problème avec Deepsea est sont fichiers "bootloader\hekate_ipl.ini" qui n'est pas correctement configuré, ceci est expliqué dans ce tuto dans la section "Atmosphere via Hekate". Sinon il faut lancer Atmosphere via Fusee-primary et pas via les configurations de Hekate.

Salut,

Ta essayer avec deepsea ici:

https://github.com/T...eepSea/releases

Prend la version normal et réesaye.


Sinon test avec les sigpatch mis sur logicsunrise.



Sinon il faudrait passer par Hekate. (au lieux de deepsea).



Il faut ce renseigner auprès de @lemmej ou @shadow256

Bonjour, peut être aussi un problème de clefs ? As tu refais un coup de "lockpick".

Parfois c'est uniquement le compte ...

Essaye déjà de te réinscrire avec un autre pseudo, si tu as toujours le même problème alors c'est ton IDPS de la console qu'il faudra changer.

 

Pour faire cela il te faut obligatoirement une console en CFW ce qui est le cas, ensuite il existe plusieurs façon de débanir effectivement la console, en permanence ou en leurrant celle-ci. 

Comme dit plus haut il faudrait changer le cID, mais si tu dis qu'elle est bannie depuis 1 an, j'ai des doutes sur ça.

 

Avant ils bannissaient l'adresse MAC de la console, maintenant le cID. Là comme ça c'est un peu dur de savoir lequel des deux est banni.

 

Sinon tu le sais rapidement si c'est la console ou le compte qui est ban. En principe tu as le message "L'accès au PSN pour ce *compte* ou *système* a été temporairement *blablabla*