shadow256

Clairement en ce moment ça se déchaîne sur Switch.

On va reclarifier, si le nombre d'Efuses grillés est inférieur au nombre d'Efuses requis l'OFW démarrera en grillant les Efuses manquants, en fait c'est le fonctionnement normal pendant une mise à jour. Puis bon un outil incontournable faut pas déconner, c'est un outil qui peut être utile tout au plus, non vraiment la rédaction des news par l'IA sans relecture c'est vraiment pas une bonne chose.

@agpixel : Pour un débutant un bon pack est se qu'il y a de mieux justement, ça évite l'approximation des installations. De plus ça peut permettre aussi la simplification de beaucoup de dépannages en intégrant des outils qui oui ne sont pas souvent utilisés mais qui sont très pratiques quand on en a besoin et quand on aide un utilisateur ça fait souvent gagner un temps précieux. Alors oui je suis d'avis que les utilisateurs devraient un peu mieux essayer de comprendre le hack mais sur Switch faut aussi reconnaître que ça prend du temps. Entre les puces, les consoles patchées ou non, l'emunand, les Efuses, les sig_patches, les payloads, les homebrews, les modules, les overlays, etc... ça fait beaucoup de notions à comprendre et à intégrer. Enfin dans un pack il est tout à fait possible de mettre en place des procédures de nettoyage plus ou moins automatisées, c'est ainsi que mon switch_AIO_LS_pack est pensé pour couvrir une grande majorité de configurations. Après le défaut que je trouve au pack présenté dans la new est qu'il a bien trop de modules par défaut et les modules sont la principale cause d'erreurs lors de mises à jour, après c'est un pack orienté overclock donc pour ça il contient se qu'il faut.

Pour créer un forwarder pour un homebrew Switch Sphaira le fait très bien à même la console, ainsi pas besoin de s'emmerder avec les paramètres et autres infos demandées par les autres logiciels permettant de créer des forwarders.

@xmoutonx : Non pas de shop intégré et non on ne te donnera pas d'adresse ou de nom de shop ici, se serait hors charte.

Merci du conseil je compte poser la puce moi même j'ai les outils et connaissances. Merci encore une fois

OK. Du coup fais aussi attention au firmware qui sera sur la puce, il te faut le 2.80 pour que tout soit bien stable, au pire tu peux le flasher quoi qu'il arrive ça ne coûtera pas grand chose:
https://github.com/rehius/usk/releases

Tu branches juste la puce en USB au pc et tu fais un copier-coller du fichier ".uf2" à la racine de la puce qui va redémarrer et être mise à jour. Ou sinon tu peux le faire via le payload picofly_toolbox en démarrant la console en maintenant l'une des touches de volume (je ne sais plus laquelle) pour que la puce passe en mode flash, il te faudra aussi mettre le fichier d'update de la puce au format bin à la racine de la SD.

@Umixas77 Picofly. Par contre si tu ne fais pas la pose toi-même n'achètes pas la puce, d'une part tu n'économisera rien et en plus le technicien qui te fera la pose risque de te refuser la moindre garantie.

@tosuya86 Le boot un peu long à l'allumage est je pense plus lié au glitch de la puce plutôt qu'à mon pack, aucune raison que mon pack ait un tel comportement.

Atmosphere c'était effectivement du 48 heures s'il n'y avait pas de modifications majeures mais là c'était le cas (la release pour le firmware 21.0.0 n'avait pas été facile non plus et ça avait pris pas mal de temps à se stabiliser). Et puis c'est quand même très difficile aussi de reprendre un projet aussi complexe, faut se familiariser avec (même si la team était déjà assez au fait du développement d'Atmosphere c'est pas la même quand on le reprend), de plus il faut aussi décider de quelle façon il faut continuer le projet. Bref trois semaines pour une reprise de ce genre c'est plutôt très acceptable en fait, les gens ne se rendent vraiment pas compte.

- Erreur critique (fusibles insuffisants) : démarrage OFW impossible

Ceci est faut, si les Efuses sont insuffisants alors ça brûle les Efuses nécessaires pour que ça match, c'est une erreur dans le payload d'afficher ce cas ainsi, chose que j'ai d'ailleurs corrigé dans la fonction du même genre dans mon payload LockSmith-RCM.

Là ça se voit vraiment que la new est rédigée par IA, l'outil peut être pratique dans certains cas mais très très loin d'être indispensable.

Deux beaux projets à suivre, pour l'instant les inconvénients sont quand même assez pénibles pour un usage utilisateur, vraiment pour l'instant c'est à mettre en place pour ceux qui souhaitent tester et faire des retours de bugs.

Merci pour la new mais à reclasser dans la catégorie "NDS" et non "PSP".

Pourquoi tu t'emmerdes avec DBI Backend, utilises plutôt le mode MTP qui fonctionne tout aussi bien et n'a pas besoin de drivers ni de logiciel spécifique pour le transfert, juste faire un copier-coller du contenu à installer dans le lecteur de DBI qui s'affichera lors du lancement du mode MTP, dans le dossier "5 - sd install" ou "6 - nand install" et basta. D'habitude j'ai pas trop tendance à dire de faire autre chose pour répondre à une question mais là franchement selon moi c'est une perte de temps de tenter de comprendre pourquoi dans ton cas ça ne fonctionne pas alors que des solutions bien plus simples existent.

Les clés évoquées dans le readme se sont effectivement des clés spécifiques aux consoles Mariko mais ce dump à part existe depuis les versions originales de LockPick-RCM. Le projet ici n'améliore rien part rapport au projet original, juste il maintien la continuité en mettant à jour les éléments nécessaires aux dumps pour les nouveaux firmwares.

- Améliorations liées aux clés spécifiques aux consoles Mariko.

A aucun moment c'est précisé dans les changelogs ça, juste c'est mis à jour pour supporter les dernières clés c'est tout.