[Demande] aide passage sxos vers atmosphere

[arb974]

Bonjour à tous.
Je viens vers vous car je suis un peu paumé depuis quelques jours.

j'ai une switch pucée avec une sx core
version logicielle de la console 11.0.0
version logicielle de la puce 3.1.0

je voudrais la basculer sur atmosphére pour les derniers jeux.
avant de vous déranger, j'ai cherché et lu pour finalement m'arrêter sur ce Tuto :  https://hackintendo.com/tutoriaux/switch/emummc_hekate/

Pour l'occasion, vue son age, j'ai acheté une nouvelle SD sandisk sur laquelle j'ai décompressé les archives du Tuto , à savoir
Atmosphere 1.6.2
Hekate 6.1.0
sigpatches 1.6.2

j'ai suivi le tuto (j'ai fait toutes mes sauvegardes sysmmc et emu mmc avant) et je bloque au moment de lancer Atmosphere.

J'ai un message d'erreur :
" Wrong PKG1 flashed:
Erista pkg1 on Mariko
Fail to launch HOS! "

Et là, je ne trouve pas de solution 
Je peux toujours démarrer en CFW via SXOS 

l'un d'entre vous pourrait-il me corriger ou m'indiquer mon erreur SVP ?
d'avance merci pour vos réponses ( ou remarques , oui vous avez le droit de dire que je suis nul   )

PS/ j'ai essayé d'être complet mais une donnée peut peut-être encore manquer ( pardon)

 

[badablek]

salut,

tu utilises quelle méthode pour démarrer Hekate et/ou Atmosphère ? Tu passes par le loader de SXOS ?

il est préférable de passer par SX Gear, qui permet de rediriger vers le payload de son choix (par défaut, PAYLOAD.BIN à la racine...ce peut être fusee ou hekate)


Le mieux étant, évidemment, de reflasher la puce avec Spacecraft-NX, qui peut charger directement payload.bin.

ps : et si tu avais une emuMMC sous SXOS, tu ne peux pas la démarrer telle quelle sous Atmosphère. Il faut utiliser Hekate pour migrer l'emuMMC spécifiquement pour Atmo.

[arb974]

bonjour Badablek

tout d'abord merci d'avoir pris le temps de me répondre

je passe effectivement par le loader de SXOS

je regarde pour reflasher la puce avec Spacecraft et je reviens donner le verdict

Encore Merci Badablek

[badablek]

avant de reflasher, tu peux déjà voir avec SX Gear, histoire d'être fixé.

(De mémoire, la méthode utilisée par SXOS pour booter fusée est obsolète, pour ça qu'il faut passer par SX Gear)


N'oublie pas que reflasher ta puce t'obligera à utiliser Atmosphère, puisque SXOS ne démarrera plus.

[arb974]

je vais essayer ce topic alors
https://www.hackintendo.com/forum/viewt ... 2908#p2908
je prends le firmware 17.0.1 sauf erreur et je teste ca 

[arb974]

bonjour
avant de faire une betise , les progressions dans les jeux (checkpoints ) sont-ils bien les fichiers dans le dossier "emutendo\save" de la carte sd ?
juste histoire qu'il n'ait pas à tout recommencer

[badablek]

je ne connais pas parfaitement SXOS, mais comme sa base est une copie d'Atmosphère, je dirais que les sauvegardes sont stockées dans l'emuMMC (donc directement dans le fichier de 29Go) et non pas dans le dossier save

le mieux est évidemment de garder une copie de l'intégralité de la microSD avant d'aller plus loin !

[arb974]

Bonjour
oui , effectivement, c'est ce dont je me suis aperçu ( j'ai copié le dossier save sur la nouvelle micro SD et pas de sauvegarde en vue)

comme je change de carte SD au passage ( l'ancienne a déjà 4 ans), je peux donc me lancer les yeux fermés
j'ai donc suivi le topic que j'ai cité au dessus (une de tes réponses d'ailleurs  )  avec une SD vierge et neuve

La console démarre directement sur Hekate mais ensuite impossible de lancer atmosphere
voici les étapes de ton tuto suivies :

1. décompresser SX Gear à la racine de la microSD
   
2. décompresser Atmosphère + Sigpatches à la racine de la microSD
   
3. décompresser Hekate à la racine de la microSD
   
4. décompresser fusee.bin à la racine de la microSD
   
5. renommer hekate_ctcaer_x.x.x.bin en payload.bin
   
6. placer le ffirmware 17.0.1 à la racine de la microSD
   
7. chapitre 3 de ton tuto sur Hekate pour paramétrer le fichier hekate_ipl.ini (j'ai pris la première version pour hekate_ipl.ini)
   
8. démarrer ma console, qui va faire SX Gear → Hekate
   

et là quand je lance atmosphère , j'ai toujours le même message d'erreur qu'à l'initial

Je pense donc que je vais devoir utiliser spacecraft pour reflasher ma puce et en attendant ta confirmation, je vais chercher la manipulation à faire pour cela
 

[badablek]

effectivement, la puce ne semble pas injecter le nécessaire pour booter Atmosphère correctement.

pour reflasher, la manipulation n'a rien de bien compliqué du moment où tu as bien gardé l'adaptateur USB de ta puce SX. spacecraft-nx est fourni avec un petit batch pour reflasher les deux sections de la puce (bootloader + firmware).

Attention, il se peut que la seconde partie ne fonctionne pas, parce que la fonction "timeout" utilisée dans le batch, entre les deux commandes, pour ajouter un intervalle de 15 secondes entre les deux processus, n'est pas forcément compatible avec tous les versions de Windows. Pour ma part, en voulant reflashant ma SX Lite, j'ai été confronté au problème (TIMEOUT ne fonctionnant pas, le batch flashait le firmware quasi en même temps que le bootloader, la puce n'aimait pas du tout). Pour info, j'ai reflashé celle-ci sous Windows 10

Si tu as le moindre souci lors de la conversion (le processus te dit "Spacecraft-NX DFU not found!", voir captures en bas de mon message), je te conseille d'ouvrir le batch et de le séparer en deux :

1. Un premier avec la première phase : BootloaderUpdater.exe bootloader.bin
   
2. Un second avec la deuxième phase : FirmwareUpdater.exe firmware.bin
   

Nota : il est aussi tout à fait possible d'ouvrir un terminal dans le dossier contenant spacecraft-nx (préalablement décompressé), et copier/coller les commandes, en attendant 15 secondes entre la partie 1 (bootloader) et la partie 2 (firmware).

flash qui s'est "mal" passé (pas de risque, ça ne bricke pas la puce pour autant) :

erreur DFU.png (8.6 Kio) Vu 523 fois

flash OK :

flash fini.png (12.1 Kio) Vu 523 fois

(ne pas tenir compte de la première commande, je m'étais emmêlé les pinceaux et j'avais commencé par le firmware puis le bootloader    )

[arb974]

c'est là que je vais certainement coincer 
la puce a été installée en magasin
je n'ai pas de cable qui m'a été remis mais je vais chercher si je peux en otenir un
 

[badablek]

ah oui là c'est une grosse erreur de leur part !

si ce n'est pas pressant : aliexpress (2ème option : USB For COREOLED)
bien moins cher (pas de frais de port) : aliexpress (3ème option : USB For COREOLED)

[arb974]

oh Merci !!!!
je commande de suite

[ Edit du 25/03] les joies d'Aliexpress font que je n'ai toujours pas reçu le produit ( le vendeur ne l'a toujours pas envoyé) 
je reviens répondre ici dès que possible
 

[arb974]

yes, enfin de retour.

je passe les péripéties avec Aliexpress

du coup, ce matin , dès livraison, direction les tournevis.
Console ouverte pour le flashage avec spacenx

après avoir compris que je devais entrer l'adresse complète des 4 fichiers pour le batch, le flashage s'est fait sans soucis

j'ai donc préparé de nouveau la SD

mais je dois vraiment être une buse car j'ai toujours le message d'erreur 

[badablek]

je vais poser une question peut-être bête...mais j'ai eu exactement ce message en puçant une V2 avec picofly, très récemment...donc peut-être pas si bête que ça :

ta sysMMC et ton emuMMC sont à niveau niveau firmware ?

J'ai eu le cas quand j'ai tenté une emuMMC dès déballage (la console était en 14.0.1, de mémoire, à ce moment). Sauf qu'avant de booter hacké...j'ai eu la très bonne idée de démarrer normal, faire la mise à jour (17.0.1 au moment de la pose de la puce). Et quand j'ai enfin voulu lancer l'emuMMC (14.0.1), j'ai eu exactement le même message que toi !

J'ai donc refait une emuMMC de zéro, à partir de la sysMMC (cette fois-ci en 17.0.1) et depuis, plus de souci, ça démarre très bien.


Je ne sais pas si c'est le fruit du hasard, je n'ai que cette console pour tester, je n'ai pas pu reproduire le "bug" plusieurs fois.


ps : le problème semble venir de boot0/1. je me demande si la puce SX n'a pas bidouillé dedans (j'ai une puce convertie, et dans mon dump sysMMC clean, sur boot0, j'ai un tag "Team Xecuter"...donc c'est certain que SXOS fait des choses pas très morales).

As-tu un dump sysMMC (rawNAND + BOOT0 + BOOT1) clean sous la main ?

sinon il existe un moyen de régénérer BOOT0/1, en regardant ici (en dernier recours, et APRÈS avoir fait un dump complet RAWNAND.BIn+BOOT0+BOOT1 pour revenir en arrière le cas échéant.

[arb974]

Coucou.
Merci pour ta réponse
Je vais tester tout ça demain, à tête reposée devant mon pc et la console ( au boulot toute la journée )

[arb974]

bonjour
alors, dans l'ordre :
le sysMMC doit être ancien ( s'il s'agit bien du firmware car je n'ai jamais mis la console à jour depuis la pose de la puce) et le emuMMC est basé sur ce même firmware (je l'ai créé après le flashage de la puce avec spacenx avant hier)
j'ai essayé de trouver le numéro de la version mais la console refuse de démarrer en OFW (je ne saurais te dire si c'était déjà le cas avant de flasher la puce) et je ne vois pas l'info sur Hekate.

je ne sais si c'est important mais j'ai vu sur hekate dans l'onglet USB tools que je suis en read only "allows you to mount eMMC/emuMMC"

j'ai un Dump qui date d'il y a 2 ans mais pas sûr qu'il soit sain ( enfin si par rawnand on parle bien des fichiers bin type full00,.... ).

j'espère être assez clair dans mes explications

[badablek]

c'est normal que Hekate soit par défaut en lecture seule...faudrait pas formater une partition système ou supprimer par inadvertance des fichiers.


avec ton dump qui date de 2 ans (si tu as bien les BOOT0/1 correspondants), tu peux tout à fait générer une emuMMC avec NXNandManager (et ton fichiers de clés dumpé avec lockpick_rcm). Ça te permettrait déjà de valider ou pas que ça fonctionne.

Et si les résultats sont OK en emuMMC, tu pourrais par la suite réinjecter ce dump dans ta sysMMC, pour retomber sur tes pattes.


Par contre tu n'avais jamais précisé que ta console ne démarrait plus non plus en retail original...c'est un paramètre très important. Et il faut savoir aussi que les puces nécessitent que la sysMMC fonctionne (électroniquement parlant). La puce vient en "surimpression" à cette sysMMC. Tu as peut-être un souci hardware.

[arb974]

Pardon, après vérification avec ma fille, j'ai dit une bêtise : elle démarrait en OFW avant le flash de la puce il y a 2 jours ( perso, j'étais pas sûr mais elle m'a rappelé une fois ou justement j'avais dû redémarrer la console car elle avait démarré en OFW)

[badablek]

ok, c'est une bonne nouvelle du coup 

tu peux donc tenter de générer une emuMMC avec NXNandManagger, et tester ça tranquille sans jamais risquer de flinguer quoi que ce soit. Ton boot0 doit avoir un problème.

[arb974]

Première bonne nouvelle:

tu avais bien vu le fichier Boot0 n'etait pas valide ( j'ai eu un message d'erreur avec NXnand)

cela m'a forcé à chercher un peu ( d'ou mon silence) mais j'ai finalement carrément retrouvé les fichiers boot0 et boot1 d'origine après pose de la puce ( et ils sont valides)

du coup, je viens de lancer la création d'emunand avec NXNand et après le repas je teste ça

[arb974]

j'ai utilisé ce topic : https://hackintendo.com/tutoriaux/switc ... ndmanager/

malheureusement, j'ai là aussi des soucis :
j'utilise les fichiers issus de la même sauvegarde ( d'après NXnand, la version du firmware est en 10.2.0 pour cette sysnand)
SDformattée en fat32
je sélectionne les fichiers et vers les 40% j'ai un message d'erreur qui apparait : " An error occured during copy "
j'ai essayé en NTFS pour la sd, j'ai essayé avec le sysnand actuel de la switch ( 11.0.0) tout en gardant boot0 et boot1 originaux
ça plante toujours vers 40/41%

[badablek]

1/ alors, déjà, ce qui est sûr, c'est que si la Switch était compatible NTFS, ça se saurait (depuis longtemps) 
FAT32 ou exFAT, et rien d'autre.

2/ ensuite, le format de partition n'a que peu d'importance, puisque NXNandManager découpe en quartiers de 4Go si FAT32 (et pas de limitation en exFAT)

3/ Enfin, si ça plante à 40%, la bonne nouvelle dans ton malheur, c'est que ça correspond à la partition USER (qui est le plus gros morceau du backup de 29Go). Autrement dit, le truc dont on se fiche royalement ! Ce que je vais te dire ci-dessous, tu le fais sur une copie de ton backup, pas directement sur le backup (on ne sait jamais) :
 

• Il faut que tu ouvres la copie de ton backup avec NXNandManager, tu renseignes les clés pour pouvoir en lire le contenu. Tu cliques droit sur la partition USER, et tu formates. Tu enregistres (je ne me souviens pas s'il fait la modification directement dans le fichier ou s'il faut l'enregistrer, d'où ma prudence à te conseiller de le faire sur une copie).
  
• Une fois que c'est fait, tu génères ton emuMMC à partir de ce dump "corrigé". Je pense qu'il y a une corruption de données (ou un dump incomplet), et le logiciel n'est pas prévu pour corriger ça (ou te proposer de formater la partition USER).
  
• Logiquement, avec la partition USER formatée (26Go sur les 29Go du backup), il ne devrait plus y avoir de bug à 40%
  

4/ en mode "kamikaze", tu pourrais tenter une réinjection de ton dump 10.2.0 avec Hekate. Le seul risque étant le même plantage à 40% MAIS tu pourrais simplement faire un reset usine (depuis le menu dédié à cette tâche), ce qui aurait pour effet de formater la partition USER.
Il serait également possible de monter ta sysMMC (réinjectée) sous Hekate, en mode USB, et d'y accèder via NXNandManager pour formater la partition USER.

Bref, ce dump providentiel, même incomplet ou potentiellement corrompu, contient néanmoins un firmware 10.2.0 fonctionnel. Et accompagné de ses boot0/1 officiels, c'est du caviar.

[arb974]

1/ alors, déjà, ce qui est sûr, c'est que si la Switch était compatible NTFS, ça se saurait (depuis longtemps)
FAT32 ou exFAT, et rien d'autre.

dans le genre j'y connais pas grand chose, je me pose là

Par contre, je suis très attentif et j'ai horreur des mauvaises surprises. Du coup, depuis le début, je ne travaille que sur des copies et non sur les originaux:)

[*]Il faut que tu ouvres la copie de ton backup avec NXNandManager, tu renseignes les clés pour pouvoir en lire le contenu. Tu cliques droit sur la partition USER, et tu formates. Tu enregistres (je ne me souviens pas s'il fait la modification directement dans le fichier ou s'il faut l'enregistrer, d'où ma prudence à te conseiller de le faire sur une copie).
[*]Une fois que c'est fait, tu génères ton emuMMC à partir de ce dump "corrigé". Je pense qu'il y a une corruption de données (ou un dump incomplet), et le logiciel n'est pas prévu pour corriger ça (ou te proposer de formater la partition USER).

partition User effacée,
j'ai voulu sauvegarder (file\save as (rawdump) mais là aussi cela plante à 41% et idem si je tente de créer l'emunand

[badablek]

ce qui voudrait dire que ça ne vient pas du dump alors...parce que là, c'est juste impossible que ça plante pile au même endroit alors que les 26Go (sur 29) sont vierges.

perso je ferais le mode kamikaze là : dump de la sysMMC actuelle (rawnand.bin + boot0/1) puis réinjection du dump 10.2.0 (rawnand.bin + boot0/1)


l'autre solution, plus rapide et moins "dangereuse" serait de générer les fichiers de mise à jour 11.0.0 avec emmchaccgen de manière à générer Boot0/1 (le reste on s'en fiche), puis tenter de réinjecter uniquement Boot0/1 (encore une fois, après avoir dumpé les versions actuelles !). Parce que dans ton cas, ce qui coince, ce n'est pas la sysMMC dans son entièreté, mais uniquement boot0/1 (probablement modifié par SXOS comme il aime bien le faire)

[arb974]

je tente la moins risquée en premier ( générer les fichiers avec emmchaccgen)

au passage, un grand merci à toi pour ta patience et ton aide:)

suite de mes péripéties page 2