[Switch] N'utilisez pas ChoiDuJour-NX sur les consoles équipées de puces SX Core/SX Lite
[PS3/Vita/Switch] ezRemote Client v1.07 disponible[PS3] CFW Evilnat 4.91.2 Beta 15 disponibleUne information commence à apparaître pour ceux utilisant une puce SX Core ou SX Lite sur leur console, il n'est pas possible d'utiliser ChoiDuJour-NX pour mettre à jour le firmware de la sysnand ou de l'emunand sous peine de brick, brick qui sera en plus très difficile voir impossible à réparer, on en parle dans ce sujet sur le forum.
Du coup en plus de ne pouvoir lancer d'autres payloads que celui démarrant SX OS, cette limitation vient s'ajouter et celle-ci est plutôt gênante, espérons donc que la TX propose une solution rapidement ou que Rajkosto mette à jour ChoiDuJour-NX pour palier à ce problème.
Donc utilisateurs des puces SX Core et SX Lite, surtout faites un dump de votre nand avant toute chose, ceci pourrait vraiment sauver votre console (ceci dit ce conseil est aussi valable pour ceux n'utilisant pas ces puces, dumper votre nand est un prérequis important avant de commencer le hack).
Disons qu’ils sont les 1ers à permettre le hack sur les nouvelles consoles, fatalement on découvre au fur et à mesure les applications qui ne fonctionnent pas et qui doivent être mises à jour pour fonctionner avec ces nouvelles consoles ! Si lockpickRCM ne fonctionne pas, ce n’est peut être pas surprenant que choidujourNX ne fonctionne pas ! On peut récupérer les biskey aujourd’hui sur ces consoles ? Quand j’aurais reçu mes puces et que j’aurais installé tout ça, je ferais des essais en tout casJe resterai modéré pour éviter un procès des fervents défenseures inconditionnel de la TX ,mais ça commence a faire beaucoup quand même je trouve...
Merci pour l'info
(après avoir dumpé ma flash hein)
Disons qu’ils sont les 1ers à permettre le hack sur les nouvelles consoles, fatalement on découvre au fur et à mesure les applications qui ne fonctionnent pas et qui doivent être mises à jour pour fonctionner avec ces nouvelles consoles ! Si lockpickRCM ne fonctionne pas, ce n’est peut être pas surprenant que choidujourNX ne fonctionne pas ! On peut récupérer les biskey aujourd’hui sur ces consoles ? Quand j’aurais reçu mes puces et que j’aurais installé tout ça, je ferais des essais en tout casJe resterai modéré pour éviter un procès des fervents défenseures inconditionnel de la TX ,mais ça commence a faire beaucoup quand même je trouve...
Merci pour l'info
Y'a pas du avoir des testes poussé des beta testeur.
Je vois pas en quoi sa serait volontaire : c'est contre productif pour TX.
Y'a pas du avoir des testes poussé des beta testeur.
Je vois pas en quoi sa serait volontaire : c'est contre productif pour TX.
@overload de souvenir les 1er version de SXOS avait eu aussi le lot de brick avec ChoiDuJour-NX .
Idem pour les Payload populaire : Leur prise en charge c'est des demande d'utilisateurs donc a mon avis comme tout nouveau produit il faudra s'assurer de la stabilité et du fonctionnement ...
@overload de souvenir les 1er version de TX avait eu aussi le lot de brick avec ChoiDuJour-NX .
Idem pour les Payload populaire : Leur prise en charge c'est des demande d'utilisateurs donc a mon avis comme tout nouveau produit il faudra s'assurer de la stabilité et du fonctionnement ...
ben evidementQuestion SVP : Pour ma Switch V1 non patchée en Trinket M0 je peux continuer de mettre a jour Via choixdujourNX ? merci pour l'infos
Ok car j'ai eu peur que ayant une V1 non patchée et avec ma TrinketM0 que choixdujourNX me brick ma v1 , donc a ce que je comprends c'est que les sx core et lite de concerné , mais c'est pas bon dutout ça pour ceux qui ont une puce lite et core , mais ils ont fait quoi la , donc ça reviens a dire mieux vaux une V1 @cedsaill
Ok car j'ai eu peur que ayant une V1 non patchée et avec ma TrinketM0 que choixdujourNX me brick ma v1 , donc a ce que je comprends c'est que les sx core et lite de concerné , mais c'est pas bon dutout ça pour ceux qui ont une puce lite et core , mais ils ont fait quoi la , donc ça reviens a dire mieux vaux une V1 @cedsaill
Perso je préfère une meilleure autonomie grâce au SoC gravé plus finement et un écran mieux calibré + SX core
Perso je préfère une meilleure autonomie grâce au SoC gravé plus finement et un écran mieux calibré + SX coreOk car j'ai eu peur que ayant une V1 non patchée et avec ma TrinketM0 que choixdujourNX me brick ma v1 , donc a ce que je comprends c'est que les sx core et lite de concerné , mais c'est pas bon dutout ça pour ceux qui ont une puce lite et core , mais ils ont fait quoi la , donc ça reviens a dire mieux vaux une V1 @cedsaill
Après l'argument de l'autonomie se discute suivant l'usage , si c'est pour jouer toujours en dock sur TV il disparait carrément , par contre pour cette histoire de calibrage écran , j'en ai pas entendu parler perso , ya une réelle différence ?
En dehors de l'autonomie qui n'est qu'une conséquence, il y a la chaleur dégagée. Moins de chaleur = meilleure durée de vie (et pas que du SoC vu qu'il chauffe inévitablement les composants autour également).
Regardez comment varie un MTBF avec seulement 5 degrés de température supplémentaires :
https://www.eeweb.co...and-temperature
Pour l'écran ça dépend peut-être des fournisseurs, en tout cas pour avoir vu une v1 et une v2 côte à côte, il n'y a pas photo entre les deux pour moi. L'écran de la v2 que j'ai vu était plus agréable (+Lumineux et colorimétrie à mon goût). Source qui confirmerait :
https://www.frandroi...modele-original
donc perso je préfère de loin une V2.
oui vive les v1 comme tu dit , la mienne est équipée d'une Trinket M0 heureusement j'ai une V1 , mais pour ceux en V2 c'est les boules çaVive la v1 en faites.
Autant chercher une v1 en occase bon marché que de se taper tous ce schmilblick.
Ok car j'ai eu peur que ayant une V1 non patchée et avec ma TrinketM0 que choixdujourNX me brick ma v1 , donc a ce que je comprends c'est que les sx core et lite de concerné , mais c'est pas bon dutout ça pour ceux qui ont une puce lite et core , mais ils ont fait quoi la , donc ça reviens a dire mieux vaux une V1 @cedsaill
Perso je préfère une meilleure autonomie grâce au SoC gravé plus finement et un écran mieux calibré + SX core
Après l'argument de l'autonomie se discute suivant l'usage , si c'est pour jouer toujours en dock sur TV il disparait carrément , par contre pour cette histoire de calibrage écran , j'en ai pas entendu parler perso , ya une réelle différence ?
Ok car j'ai eu peur que ayant une V1 non patchée et avec ma TrinketM0 que choixdujourNX me brick ma v1 , donc a ce que je comprends c'est que les sx core et lite de concerné , mais c'est pas bon dutout ça pour ceux qui ont une puce lite et core , mais ils ont fait quoi la , donc ça reviens a dire mieux vaux une V1 @cedsaill
Perso je préfère une meilleure autonomie grâce au SoC gravé plus finement et un écran mieux calibré + SX core
Après l'argument de l'autonomie se discute suivant l'usage , si c'est pour jouer toujours en dock sur TV il disparait carrément , par contre pour cette histoire de calibrage écran , j'en ai pas entendu parler perso , ya une réelle différence ?
En dehors de l'autonomie qui n'est qu'une conséquence, il y a la chaleur dégagée. Moins de chaleur = meilleure durée de vie (pas que du SoC vu qu'il chauffe les composants autour également).
Pour l'écran ça dépend peut-être des fournisseurs, en tout cas pour avoir vu une v1 et une v2 côte à côte, il n'y a pas photo entre les deux pour moi. L'écran de la v2 que j'ai vu était plus agréable (+Lumineux et colorimétrie à mon goût).
Regardez comment varie un MTBF avec seulement 5 degrés de température supplémentaires :
https://www.eeweb.co...and-temperature
PAs entendu parlé non plus de calibrage écran.
Par contre la V2 Mariko est nettement mieux côté autonomie.
Elle bat même la version Lite.
On va pas se mentir, le principal intérêt de la console est sa portabilité.
J'ai mis à jour mon post avec une source + mon expérience (qui ne confirme rien sur le fait que ça concerne toutes les Switch mais qui étaye quand même la source).
ok je ne savais pas qu'il y avait une telle différence d’écran , on en apprend tout les jours ^^ merci pour cette info intéressante c'est sympa
EDIT :
Oui il est indéniable que les dégagement de chaleur et les finesse de gravure joue un rôle important dans la durée de vie d'un appareil , après quand on vois des vieux processeur de 30 ans grossièrement gravé tourner encore très bien , ou mème plus généralement des appareil entier fonctionner encore très bien (je pense au magnétoscope VHS , je sais je suis vintage remarque je sais pas quelle age t'as , tu l'ai peut être aussi) il ne faut pas non plus tomber dans une parano a ce sujet, la durée de vie est quand mème énorme en règle général , d'ailleurs en qui concerne les processeurs je n'en ai jamais vu d'HS perso , ça me semble increvable ^^
Les processeurs d'il y a 30 ans n'étaient pas sollicités comme aujourd'hui, en plus leur boîtier était bien plus gros donc meilleure RTH.
D'ailleurs il n'y avait pas beaucoup de refroidissement actifs à l'époque
On est d'accord que le processeur a sûrement un excellent MTBF mais les composants autour pas forcément (surtout les condensateurs et les régulateurs). C'est un fait, une v2 à théoriquement un meilleur MTBF qu'une v1. Après est-ce que c'est sur 5 ans, 10 ans 30 ans qu'on le verra je n'en sais rien
+1 j'en ais une neuve une deuxième de coté aussi en trinketm0 j'avais prévus a l'époque , car j'avais un gros bon d'achat au magasin du coup j'en avais pris deux neuvesMoi je me dis que les V1 seront amener à être une denrée rare, car d'ici 1 ans ou 2 elles auront disparu du marcher de l'occasion pour y etre remplacer par les V2, les dernière commercialiser en neuf était fin 2018 !
Même si des milliers de console ce sont vendue, il n'y reste pas moins que entre les jeunes qui les casses (j'en vois beaucoup dans mon travail), les soucis de surchauffe et l'usure avec le temps elles seront amener à être diminuer en quantité !
Le mieux c'est d'en avoir 1 de plus de coté pour le " au cas ou "
ok je ne savais pas qu'il y avait une telle différence d’écran , on en apprend tout les jours ^^ merci pour cette info intéressante c'est sympa
EDIT :
Oui il est indéniable que les dégagement de chaleur et les finesse de gravure joue un rôle important dans la durée de vie d'un appareil , après quand on vois des vieux processeur de 30 ans grossièrement gravé tourner encore très bien , ou mème plus généralement des appareil entier fonctionner encore très bien (je pense au magnétoscope VHS , je sais je suis vintage remarque je sais pas quelle age t'as , tu l'ai peut être aussi) il ne faut pas non plus tomber dans une parano a ce sujet, la durée de vie est quand mème énorme en règle général , d'ailleurs en qui concerne les processeurs je n'en ai jamais vu d'HS perso , ça me semble increvable ^^
Les processeurs d'il y a 30 ans n'étaient pas sollicités comme aujourd'hui, en plus leur boîtier était bien plus gros donc meilleure RTH.
D'ailleurs il n'y avait pas beaucoup de refroidissement actifs à l'époque
On est d'accord que le processeur a sûrement un excellent MTBF mais les composants autour pas forcément (surtout les condensateurs et les régulateurs). C'est un fait, une v2 à théoriquement un meilleur MTBF qu'une v1. Après est-ce que c'est sur 5 ans, 10 ans 30 ans qu'on le verra je n'en sais rien
aucuns véritable soucis de ma V1 depuis presque 2 ans et un pote non plus , ont les avais acheté ensemble et la sienne tourne souvent il a aucuns soucis depuis 2 ans
ha ok ça les brick avec ces nouvelles puces que en cas d'activation d'auto RCM dans choixdujourNX ?Y a pas de question à se poser tout simplement que le processus est différent donc les outils ne sont pas compatible.
Choidujour brick uniquement en cas d’utilisation de l’autoRCM !
Suffit juste de faire des test avec une 2ème Nand
Y a pas de question à se poser tout simplement que le processus est différent donc les outils ne sont pas compatible.
Choidujour brick uniquement en cas d’utilisation de l’autoRCM !
Suffit juste de faire des test avec une 2ème Nand
Il me semble que c'est pas le seul problème ici justement, après comme on a vraiment des infos au compte gouttes de la part des testeurs c'est difficile de savoir qu'est-ce qui pose problème ou non. Après si c'est qu'un problème d'auto-RCM alors devrait pas y avoir de souci à utiliser ChoiDuJour-NX sur l'emunand. Et sur la sysnand, même si l'auto-RCM est activé, c'est toujours possible de réécrire BOOT0 pour retirer l'auto-RCM via une console non patchée par exemple (bon par contre pour les Switch Lite là je sais pas trop se qu'il serait possible de faire). De plus, ChoiDuJour-NX intègre déjà une protection pour empêcher l'activation de l'auto-RCM sur les consoles patchées au moins donc pourquoi ces rapports de brick à cause de ChoiDuJour-NX?
Du coup si quelqu'un possède les compétences pour changer la nand d'une console à une autre, une console Mariko avec une SX Core avec un dump clean de la nand et une console non patchée pour débricker en cas de souci moi je veux bien jouer les assistants de tests logiciels car de toute évidence beaucoup de testeurs étaient des techniciens et ces derniers sont souvent plutôt moyen quand il s'agit de choses logiciels justement, chacun son travail après tout et il serait temps d'avoir de vrai tests fiables. Si ça vous intéresse, contactez-moi par MP.
Evidemment que sa marche pas deja est ce que les update sont les même si non sa revient comme 3ds ou on met pas l update new3ds sur la simple 3ds la ses update mariko sur mariko ect vu qu il n y avait rien personne ne savait dumper une maj des lite et mariko pour comparer si même que les autre ou pas si ses pas le cas ses normal que sa brick donc choix du jour y est peut être pour rien ou si s est chois du jour vu que sa a eter programmer pour les autre ses 2 switch différent vous pouvez dire se que vous voulez tant qui a pas eu des vérification et de l adaptation ses normal que sa n ira pas (et se pour beaucoup de chose qui allait avant) les code/securiter des switch sont normalement différente des v1 a v2 et se même si l update est le même (et aussi ceux des puce diffère des switch d ailleurs)
mais tout sa ses pas dit on crashe direct tx (je dit pas que tx n a pas mit une telle limitation ni qu ils l ont fait)
je souligne un point crucial avant de dire si y a limitation/bug ou pas
Silien3 c est pas faux effectivement il y a peut etre des firmwares differents en fonctionne des patche et non patche
J ai hate de voir les tests en approfondi.
Mais ta piste me semble tres judicieux
la puce est récente ont sera quoi bien assez tot comme dit see you soon lol
Tkt trantor, cela ne concerne que les switchs patchées.
Je suis d'accord avec TheDark91, les béta-testeurs de la puce auraient quand même pu remonter l'info! Quand on teste, on teste à fond, pas simplement avoir une puce gratuite et faire la pose et l'utilisation de base, mais plutôt pousser à l’extrême, chercher les limites.. 10.0.3 est sorti le 26 mai, 10.0.4 le 05 juin.. Ça fait 2 semaines quand même.
Y a pas de question à se poser tout simplement que le processus est différent donc les outils ne sont pas compatible.
Choidujour brick uniquement en cas d’utilisation de l’autoRCM !
Suffit juste de faire des test avec une 2ème Nand
Y a pas de question à se poser tout simplement que le processus est différent donc les outils ne sont pas compatible.
Choidujour brick uniquement en cas d’utilisation de l’autoRCM !
Suffit juste de faire des test avec une 2ème Nand
C’est pas juste l’autorcm hihi, t’a pas vu ce que tx avait inscrit ?
Je comprends pas pourquoi les utilisateurs ce sont rush sur ces puces ...(plus général sur toute les nouvelle façon de hack une console)
Je peux comprends qu'on veut hack la console mais quand il s'agit d'une nouveau puce sur des console non hackable de base il vaut mieux attendre quelques semaine de plus et ne rien "casser, brick"(ça fait cher 300€ + ~60€) le temps que tous les outils sorte correctement ou soit fixe. On le sait la TX a sortie les puces un peu prématurément pour ce faire de l'argent et sûrement à cause des leak/Nintendo donc on le sait aussi que c'est fonctionnelle mais pas opérationnelle à 100%.
Bref dans 1 mois atmosphère et les homebrew seront compatible à se moment là pour les utilisateur lambda ça sera utile de les faire poser avant c'est vraiment "idiot".
l'idéal pour vérifier tout sa serais de faire un topic sur forum et de tout complété au fur et a mesure comme la FAQ pour les V1 (rédigé par shadow qui plus est)
Je pense que se sujet peut être ajouter à la FAQ après faudra voir si il y a une différence dans les futur outils entre les V1 ou les mariko pour créer une FAQ à part.
pour ceux en sx lite et core obligé via serveur nintendo pour mettre a jour et si ils ce font ban pfiou ?Salut,
Oui hélas pour celles&ceux qui ont une puce sxos pour l'instant mise a jour via wifi uniquement (donc via serveur nintendo)
Note: Je pense que ces une sécurité de la team xecuteur ou alors un oublie dans le logciel de leurs puces.
Sans avoir besoin de faire un backup de la NAND :
1. création de l'EmuNAND en fichiers depuis la microSD
2. sauvegarde des fichiers de l'EmuNAND sur l'ordi
3. faîtes n'importe quoi sur l'EmuNAND (mise à jour ou autre)
4. en cas de problème restauration des fichier de l'EmuNAND
5. zéro problème de brickage de la console possible
Merci, aurevoir.
PS: Si c'est l'activation de l'auto RCM qui est en cause c'est un autre problème.
Oui mais non en fait, c'est pas si simple car si t'as une mauvaise détection de quelques chose même l'exécution d'un outil sur l'emunand pourrait bricker la sysnand (sur le principe ça ne devrait pas être le cas mais dans les faits on en sait rien), ta méthode n'est pas du tout prudente. En plus qui te dit que l'emunand sur ce type de console n'est pas différente de la sysnand sur quelques tout petits points, faut aussi vérifier çà avant. Quand on fait des tests on les fait vraiment en suivant une méthodologie la plus précise possible, pas n'importe comment en ne se basant que sur des suppositions, la méthode que je propose est la seule garantie sans risque de brick logiciel impossible à résoudre (pour les bricks matériels là c'est différent). Et puis bon un technicien qui conseil implicitement de ne pas faire le dump de la nand franchement c'est pas terrible quand même.
@silien3 : Se qui est certains c'est que les consoles patchées sur un firmware 5.X.X et supérieurs génèrent autrement leurs Bis keys (voir un des changelogs d'Atmosphere récent, je ne me souviens plus lequel), chose qui n'est pas prévu par ChoiDuJour-NX. Autre chose, les clés Mariko sont aussi différentes des clés Erista donc ça non plus ChoiDuJour-NX ne le gère pas, j'ai déjà pu vérifier que les fichiers des firmwares 6.2.0 et supérieurs possèdent des fichiers identiques mais nommés différemment, probablement que cela a un lien avec les clés uniques à chaque console. Bref, il est clair que se sont les homebrews qui sont en cause car ils doivent être adaptés tout comme les payloads.
Sans avoir besoin de faire un backup de la NAND :
1. création de l'EmuNAND en fichiers depuis la microSD
2. sauvegarde des fichiers de l'EmuNAND sur l'ordi
3. faîtes n'importe quoi sur l'EmuNAND (mise à jour ou autre)
4. en cas de problème restauration des fichier de l'EmuNAND
5. zéro problème de brickage de la console possible
Merci, aurevoir.
PS: Si c'est l'activation de l'auto RCM qui est en cause c'est un autre problème.
Bonsoir,Sans avoir besoin de faire un backup de la NAND :
1. création de l'EmuNAND en fichiers depuis la microSD
2. sauvegarde des fichiers de l'EmuNAND sur l'ordi
3. faîtes n'importe quoi sur l'EmuNAND (mise à jour ou autre)
4. en cas de problème restauration des fichier de l'EmuNAND
5. zéro problème de brickage de la console possible
Merci, aurevoir.
PS: Si c'est l'activation de l'auto RCM qui est en cause c'est un autre problème.
Hello,
Comment fait on un backup de l'EmuNAND ?
J'ai une puce sur une V1 avec SXOS, faut-il faire ce backup juste après la pause de la puce ? ou on peut le faire après du moment que la console fonctionne bien ?
Merci pour ton aide.
Evidemment que sa marche pas deja est ce que les update sont les même si non sa revient comme 3ds ou on met pas l update new3ds sur la simple 3ds la ses update mariko sur mariko ect vu qu il n y avait rien personne ne savait dumper une maj des lite et mariko pour comparer si même que les autre ou pas si ses pas le cas ses normal que sa brick donc choix du jour y est peut être pour rien ou si s est chois du jour vu que sa a eter programmer pour les autre ses 2 switch différent vous pouvez dire se que vous voulez tant qui a pas eu des vérification et de l adaptation ses normal que sa n ira pas (et se pour beaucoup de chose qui allait avant) les code/securiter des switch sont normalement différente des v1 a v2 et se même si l update est le même (et aussi ceux des puce diffère des switch d ailleurs)
mais tout sa ses pas dit on crashe direct tx (je dit pas que tx n a pas mit une telle limitation ni qu ils l ont fait)
je souligne un point crucial avant de dire si y a limitation/bug ou pas
C’est chaud pour mettre à jour sa Switch avec cette puce
Oui mais non en fait, c'est pas si simple car si t'as une mauvaise détection de quelques chose même l'exécution d'un outil sur l'emunand pourrait bricker la sysnand (sur le principe ça ne devrait pas être le cas mais dans les faits on en sait rien), ta méthode n'est pas du tout prudente. En plus qui te dit que l'emunand sur ce type de console n'est pas différente de la sysnand sur quelques tout petits points, faut aussi vérifier çà avant. Quand on fait des tests on les fait vraiment en suivant une méthodologie la plus précise possible, pas n'importe comment en ne se basant que sur des suppositions, la méthode que je propose est la seule garantie sans risque de brick logiciel impossible à résoudre (pour les bricks matériels là c'est différent). Et puis bon un technicien qui conseil implicitement de ne pas faire le dump de la nand franchement c'est pas terrible quand même.
Depuis l'arrivée de l'EmuNAND, je n'ai pas vu l'utilité, en effet, de réaliser un dump de la NAND sur une console équipée de ce système.
Outre le temps à y consacrer, il ne s'est jamais posé la question jusqu'à présent aux utilisateurs de ce système de s'occuper de la NAND car on ne fait que bidouiller sur l'EmuNAND.
D'ici quelques temps on y verra plus clair dans ces histoires de bricks, d'ici là on peut toujours conseiller aux utilisateurs de puces TX de dumper la NAND par prudence c'est sûr.
Est-ce que le problème de CDJNX est lié au SX Core ou a Mariko ? Est-ce que les fichiers de fw sont les mêmes pour Erista et Mariko ???
Pareil pour le problème d'incognito ou quelque outil qui lit/modifie CAL0. N'est-ce pas là une protection mise en place par Nintendo ?
Attendons de savoir avant de tirer des conclusions, il se pourrait bien que le SX Core n'ait rien à voir là-dedans.
Aussi, pour être certain que la NAND est vraiment brickée, il faudrait retirer la puce et tester.
Ce qu'on sait par hexkyz c'est que la puce flashe une custom BCT de BOOT0 mais il y a des backups (4 BCT au total). Mais la puce re-route vers le bootloader SX après le glitch donc impossible je pense de lancer le mode récupération des BCT qui est fait par le bootloader officiel. En retirant la puce, ça pourrait peut-être fonctionner.
Utilise hekate. Ton trinket boot direct sur sx ? Ou sur un menu, style argon-nx, qui te laisse le choix ? Si direct sur sx, est ce que tu as un dossier 0 et un fichier start.bin à la racine de ta carte microsd ? Si oui, télécharge le payload d'hekate, renomme le en start.bin et remplace celui existant (conserve le tout de même pour le rechanger après le dump). N'oublie pas aussi de coller hekate sur la microsd.Hello,
Quelle application utilisez vous pour backupez votre sysnand emunand svp ?
J'utilise une v1 en trinlet M0 avec SXOS.
Merci.
Initialement il aurait fallu choisir l'option n°2 lors de la création de l'EmuNAND (files on microSD).Hello,
Quelle application utilisez vous pour backupez votre sysnand emunand svp ?
J'utilise une v1 en trinlet M0 avec SXOS.
Merci.
Initialement il aurait fallu choisir l'option n°2 lors de la création de l'EmuNAND (files on microSD).
Ainsi tu peux copier directement depuis l'ordi le contenu du dossier sxos/emunand où se trouves les fichiers.
Pas de backup de l'EmuNAND en fait juste un copié/collé suffit.
Pour la SysNAND, l'option "NAND -> backup" du menu du SX OS est le système le plus simple.
Une emuNAND fichier sera toujours plus lente qu'une emunand en partition. Personnellement je recommande plutôt de créer cette dernière.
NxNandManager permet de faire facilement un backup d'une emuNAND en partition avec la carte SD insérée dans l'ordinateur. Il est donc maintenant assez facile d'en faire un backup.
Il est vrai qu'une emuNAND fichier reste plus pratique à déplacer mais c'est le seul avantage et ça ne justifie pas son utilisation selon moi.
Sinon pour faire un backup de la sysNAND avec un switch Erista, il vaut mieux utiliser Hekate car SX OS est très très lent (plus d'une heure contre 20 minutes environ via Hekate).
Une emuNAND fichier sera toujours plus lente qu'une emunand en partition. Personnellement je recommande plutôt de créer cette dernière.
NxNandManager permet de faire facilement un backup d'une emuNAND en partition avec la carte SD insérée dans l'ordinateur. Il est donc maintenant assez facile d'en faire un backup.
Il est vrai qu'une emuNAND fichier reste plus pratique à déplacer mais c'est le seul avantage et ça ne justifie pas son utilisation selon moi.
Sinon pour faire un backup de la sysNAND avec un switch Erista, il vaut mieux utiliser Hekate car SX OS est très très lent (plus d'une heure contre 20 minutes environ via Hekate).
J'ajoute juste qu'en plus via Hekate on sait les vérifications faites pour vérifier l'intégrité du dump (avec le niveau de vérification maximal c'est quasiment impossible d'avoir une erreur qui passerait à la trappe) alors qu'avec SX OS non.
Hello,
Quelle application utilisez vous pour backupez votre sysnand emunand svp ?
J'utilise une v1 en trinlet M0 avec SXOS.
Merci.
bon vent !Disons qu’ils sont les 1ers à permettre le hack sur les nouvelles consoles, fatalement on découvre au fur et à mesure les applications qui ne fonctionnent pas et qui doivent être mises à jour pour fonctionner avec ces nouvelles consoles ! Si lockpickRCM ne fonctionne pas, ce n’est peut être pas surprenant que choidujourNX ne fonctionne pas ! On peut récupérer les biskey aujourd’hui sur ces consoles ? Quand j’aurais reçu mes puces et que j’aurais installé tout ça, je ferais des essais en tout casJe resterai modéré pour éviter un procès des fervents défenseures inconditionnel de la TX ,mais ça commence a faire beaucoup quand même je trouve...
Merci pour l'info
C'est peut être volontaire.... quand on vois la restriction pour atmosphère, inadmissible selon moi , surtout pour un hack payant, pour moi TX c'est fini je ne les suivraient pas sur leur politique, trop d'histoire sur cette gen, entre vol de code , restriction abusive et maintenant brick, le temps de la 360 et de leur outils est loin maintenant, pour moi concernent la switch pour le moment c'est V1 ou rien
@eliboa Sous Sxos l'emunand fichier est tout ausi rapide que l'emunand partition. Après tout dépend de ta carte SD !
C'est l'impression que ça peut donner mais c'est techniquement impossible puisqu'une emunand fichier est stockée de manière fragmentée alors que l'emunand partition c'est de la mémoire contiguë donc plus rapide à lire/écrire. Même si la mémoire n'est pas fragmentée, ce qui peut être le cas, le driver devra passer par la FAT pour lire/écrire ton emuNAND, ce qui forcément est un petit peu plus long.
Après sur SX OS, si tu utilises que des XCI, tu verras sans doute pas la différence effectivement (peu d'accès à la NAND). Pour installer des NSP par contre, c'est différent.
En faite on a jamais pu vraiment tester ?
Et si même AMS avaient trouvé une solution on aurai probablement ce même soucis avec CDNX ?
Juste pour éviter de coller une étiquette gratos pour rien
Le problème viens d'une protection de ce FW et pas du contournement...
Merci @eliboa d'être aussi clairvoyant
Merci @shadow256 pour la mise en garde
Oui, se sont probablement les soft qui doivent être adaptés pour les nouveaux systèmes et avec Atmosphere le problème aurait possiblement été le même sauf qu'on aurait été prévenu par le développeur à mon avis. Comme l'a très justement dit @fatiguant, le problème est que la TX n'a donné aucun outil de débogage ni de débrickage aux beta testeurs, en gros ils ont eu la puce gratos mais s'ils brickent la console bah c'est pour leur poire et ils n'ont aucun outil à disposition pour essayer de relancer la machine, c'est clair que du coup ça ne motive pas trop à faire des tests poussés.
@Linkynimes : C'est une idée mais je pense que le problème risque d'être le même, il faut adapter le software aux nouvelles sécurités/clés des consoles patchées (Erista/Mariko) et la dernière version de SX Installer date un peu. De plus j'ai déjà vu des bricks via cette méthode pour les consoles non patchées donc bon perso je ne me risquerai pas à ce genre de tests sur les consoles patchées.
En faite on a jamais pu vraiment tester ?
Et si même AMS avaient trouvé une solution on aurai probablement ce même soucis avec CDNX ?
Juste pour éviter de coller une étiquette gratos pour rien
Le problème viens d'une protection de ce FW et pas du contournement...
Merci @eliboa d'être aussi clairvoyant
Merci @shadow256 pour la mise en garde
Oui, se sont probablement les soft qui doivent être adaptés pour les nouveaux systèmes et avec Atmosphere le problème aurait possiblement été le même sauf qu'on aurait été prévenu par le développeur à mon avis. Comme l'a très justement dit @fatiguant, le problème est que la TX n'a donné aucun outil de débogage ni de débrickage aux beta testeurs, en gros ils ont eu la puce gratos mais s'ils brickent la console bah c'est pour leur poire et ils n'ont aucun outil à disposition pour essayer de relancer la machine, c'est clair que du coup ça ne motive pas trop à faire des tests poussés.
@Linkynimes : C'est une idée mais je pense que le problème risque d'être le même, il faut adapter le software aux nouvelles sécurités/clés des consoles patchées (Erista/Mariko) et la dernière version de SX Installer date un peu. De plus j'ai déjà vu des bricks via cette méthode pour les consoles non patchées donc bon perso je ne me risquerai pas à ce genre de tests sur les consoles patchées.
J'avais oublier cette méthode mais techniquement on peu update une console même sous puce SXCore avec les NSP fournis par la TX ?
https://repo.xecuter.rocks/fwpacks/
Un testeur a déjà pu vérifier cela ?
Très belle trouvaille, félicitations.
Content de voir que la Team apporte ses propres solutions d'update pour son système.
Par contre il n'y pas le choix de la version (FAT32 ou exFAT) à priori.
Peut-être est-ce d'emblée du exFAT, je vais tester...
PS: L'installation a échoué (message d'erreur) via SX Installer v3.0.2 sans conséquence pour la console (j'ai un modèle HAC-001 Tegra X1)
Initialement il aurait fallu choisir l'option n°2 lors de la création de l'EmuNAND (files on microSD).Hello,
Quelle application utilisez vous pour backupez votre sysnand emunand svp ?
J'utilise une v1 en trinlet M0 avec SXOS.
Merci.
Ainsi tu peux copier directement depuis l'ordi le contenu du dossier sxos/emunand où se trouves les fichiers.
Pas de backup de l'EmuNAND en fait juste un copié/collé suffit.
Pour la SysNAND, l'option "NAND -> backup" du menu du SX OS est le système le plus simple.
