800 réponses à ce sujet

[shadow256]

@Linkynimes :

Perso avec les copies d'écrans je ne peux pas aider, faut me recopier le texte des erreurs directement sinon je ne pourrais pas faire avancer ton souci.

Ceci dit quelques choses m'intéressent, est-ce que tu as toujours la même erreur de montage avec Memloader et si oui quel est le texte de cette erreur, quelle est l'erreur retournée par Hekate, que donne un dump des clés via Lockpick-RCM et que donne le lancement de TegraExplorer?

[Linkynimes]

Avec memloader v3 :

attempting to communicate with USB host... try 1 (last retVal 0 xfer'd 0 bytes)
RECV 0x00000056 bytes -> 0x00100000
RECV 0x0006e13f bytes -> 0x801100000

 

BOOT0 section 'RCM'

                pc=0x801100000
[MTC_Load] Error during lzma decompression, got 246400 instead of 4294967295 bytes out !
(j'ai utilisé ton script)

Avec Hekate (en 4.6 uniquement en 5.3 j'ai rien)

Initializing...

Identified pk91 ('20180220163747')
keyblob version 4

Loaded pk91 and keyblob
Decrypted and unpacted pk91

Patching Warnboot
Patching Security Monitor
Loaded warnboot.bin and secmon
Read pk92

Paserd ini1
Patching kernel initial processes
rebuilt and loaded pk92

booting...
Puis écran noir

Avec lockpick_RCM

MMC Init.... done in 8652 us
TSEC key(s)... done in 10699 us
Master keys... done in 1828 us
Decrypt pk92... done in 34337 us
Decompress fs... done in 126872 us
FS keys... done in 6313 us
Sector cache... done in 16071 us
ES & SSL keys... done in 159022 us
SD Seed... done in 16334 us
Titlekeys... 100%
common... done in 84900 us
                  100%
Personalized... done in 193016 us
Found 12 titlekeys
Found 113 keys.
Lockpick totally done in 666676 us
Found Throught masterkey_5 (il détecte bien le fait que j'ai utilisé la 5.1.0)

Pas d'erreur pour lockpick

avec TegraExplorer

Pas d'erreur particulière sur TegraExplorer et la NAND semble correct

Modifié par Linkynimes, 21 juillet 2020 - 17:54.

[shadow256]

Ouai c'est bien se que je craignait via Memloader, c'est une erreur que j'ai rencontrée plusieurs fois et j'ai jamais réussi à réparer les consoles ayant ce problème, ceci dit tu viens de m'apprendre que le mode USB Tools de Hekate permet tout de même de réécrire la nand des consoles ayant ce problème se qui personnellement n'a jamais fonctionné pour moi. Tu tentes bien le lancement du CFW via une SD en FAT32 (c'est mieux histoire d'être certain de ne pas être emmerdé)? Après si tu veux on peut voir çà ensemble en vocal, dans ce cas précis je ne te demanderai pas de compensation financière car déjà on a très peu de chances de pouvoir réparer la console et en plus le problème est très spécifique et donc intéressant pour moi; si tu veux qu'on voit ça comme çà contactes-moi en MP.

@eliboa : Si tu sais qu'est-ce qui peux provoquer cette erreur dans Memloader au niveau matériel ça m'intéresse fortement.

Modifié par shadow256, 21 juillet 2020 - 18:07.

[Linkynimes]

Ouai c'est bien se que je craignait via Memloader, c'est une erreur que j'ai rencontrée plusieurs fois et j'ai jamais réussi à réparer les consoles ayant ce problème, ceci dit tu viens de m'apprendre que le mode USB Tools de Hekate permet tout de même de réécrire la nand des consoles ayant ce problème se qui personnellement n'a jamais fonctionné pour moi. Tu tentes bien le lancement du CFW via une SD en FAT32 (c'est mieux histoire d'être certain de ne pas être emmerdé)? Après si tu veux on peut voir çà ensemble en vocal, dans ce cas précis je ne te demanderai pas de compensation financière car déjà on a très peu de chances de pouvoir réparer la console et en plus le problème est très spécifique et donc intéressant pour moi; si tu veux qu'on voit ça comme çà contactes-moi en MP.

@eliboa : Si tu sais qu'est-ce qui peux provoquer cette erreur dans Memloader au niveau matériel ça m'intéresse fortement.

je n'ai pas encore essayer en fat32 je comptais essayer un peu plus tard, je vais prendre contact avec toi via MP aussi ^^

[eliboa]

@eliboa : Si tu sais qu'est-ce qui peux provoquer cette erreur dans Memloader au niveau matériel ça m'intéresse fortement.

Côté memloader, il y a un truc qui me semblait être un piste dans l'erreur :

[MTC_Load] Error during lzma decompression, got 246400 instead of 4294967295 bytes out !

4294967295 c'est 0xFFFFFFFF, ce qui est la valeur max d'un entier non signé sur 32bits (u32). En général c'est que la variable u32 a été alimentée avec un entier plus grand que 0xFFFFFFFF (4Gb) ou que la variable n'est pas initialisée et allouée avec des 0xFF.

Je pense donc que cette variable est fausse et je suspecte que les 246400 bytes eux sont correct. 

Ensuite cette erreur est à un seul endroit dans le code de memloader, dans mtc.c (minerva training). Elle intervient lors de la décompression (lzma) des tables mtc qui sont contenues dans mtc_sdram.lzma, fichier ajouté au binaire de memloader lors de la compilation.

Bref, l'erreur est liée à minerva, ça pourrait venir du build de memloader utilisé dans ton script (peut-être), ou dans le mien si tu utilises toujours celui de tegrarcmgui, ou même celui de rajkosto.

Ce qui est bizarre c'est que la variable mtc_sdram_lzma_size qui contient la valeur 0xFFFFFFFF ne semble alimentée nul part dans le code de memloader, ce qui expliquerait logiquement cette erreur.

Bon cette erreur n'a pas l'air bloquante donc je pense que le programme plante plus tard, mais sans faire de print. Je pense que cette erreur n'est pas significative de toute façon. memloader fonctionne quand même sans faire de training de la sdram.

 

Sinon pour en revenir au pb de Linkynimes, le fait que locpick semble bien dumper toutes les clés exclu à mon avis un problème sur les partitions BOOT (pkg1) ou BCPKG2 (pkg2).

Ca semble être plus en aval dans le processus de boot. Peut-être côté HOS, si Linkynimes ne voit pas le bootlogo HOS.

Peut-être que c'est lié à SYSTEM ou USER ?

 

Tenez-moi au courant si vous trouvez la soluce en MP

Modifié par eliboa, 21 juillet 2020 - 18:42.

[Linkynimes]

Côté memloader, il y a un truc qui me semblait être un piste dans l'erreur :

[MTC_Load] Error during lzma decompression, got 246400 instead of 4294967295 bytes out !

4294967295 c'est 0xFFFFFFFF, ce qui est la valeur max d'un entier non signé sur 32bits (u32). En général c'est que la variable u32 a été alimentée avec un entier plus grand que 0xFFFFFFFF (4Gb) ou que la variable n'est pas initialisée et allouée avec des 0xFF.

Je pense donc que cette variable est fausse et je suspecte que les 246400 bytes eux sont correct. 

Ensuite cette erreur est à un seul endroit dans le code de memloader, dans mtc.c (minerva training). Elle intervient lors de la décompression (lzma) des tables mtc qui sont contenues dans mtc_sdram.lzma, fichier ajouté au binaire de memloader lors de la compilation.

Bref, l'erreur est liée à minerva, ça pourrait venir du build de memloader utilisé dans ton script (peut-être), ou dans le mien si tu utilises toujours celui de tegrarcmgui, ou même celui de rajkosto.

Ce qui est bizarre c'est que la variable mtc_sdram_lzma_size qui contient la valeur 0xFFFFFFFF ne semble alimentée nul part dans le code de memloader, ce qui expliquerait logiquement cette erreur.

Bon cette erreur n'a pas l'air bloquante donc je pense que le programme plante plus tard, mais sans faire de print. Je pense que cette erreur n'est pas significative de toute façon. memloader fonctionne quand même sans faire de training de la sdram.

 

Sinon pour en revenir au pb de Linkynimes, le fait que locpick semble bien dumper toutes les clés exclu à mon avis un problème sur les partitions BOOT (pkg1) ou BCPKG2 (pkg2).

Ca semble être plus en aval dans le processus de boot. Peut-être côté HOS, si Linkynimes ne voit pas le bootlogo HOS.

Peut-être que c'est lié à SYSTEM ou USER ?

 

Tenez-moi au courant si vous trouvez la soluce en MP

Effectivement aucun bootlogo, j'ai pourtant bien copié les fichier SYSTEM et USER et de ce que j'ai cru voir avec lockpick j'ai bien la bonne masterkey, reste a savoir ce qui bloque dans le boot de HOS

[shadow256]

Le truc bizarre c'est que sur une console fonctionnelle cette erreur ne se d’éclanche pas alors que là si et sur toutes les consoles ayant affichées cette erreur (bon quand on a "got 246400 instead of 4294967295 bytes out" le premier nombre peut être différent selon la console) j'ai jamais réussi le moindre débrick, bon après on va chercher un peu car pouvoir écrire la nand avec le mode USB Tools de Hekate va pouvoir changer mon approche, je tiendrais au courant des résultats dès qu'on en saura plus.

[Linkynimes]

Le truc bizarre c'est que sur une console fonctionnelle cette erreur ne se d’éclanche pas alors que là si et sur toutes les consoles ayant affichées cette erreur (bon quand on a "got 246400 instead of 4294967295 bytes out" le premier nombre peut être différent selon la console) j'ai jamais réussi le moindre débrick, bon après on va chercher un peu car pouvoir écrire la nand avec le mode USB Tools de Hekate va pouvoir changer mon approche, je tiendrais au courant des résultats dès qu'on en saura plus.

Je t'ai MP j'attend ta réponse et merci de ton aide

[eliboa]

Le truc bizarre c'est que sur une console fonctionnelle cette erreur ne se d’éclanche pas alors que là si et sur toutes les consoles ayant affichées cette erreur (bon quand on a "got 246400 instead of 4294967295 bytes out" le premier nombre peut être différent selon la console) j'ai jamais réussi le moindre débrick, bon après on va chercher un peu car pouvoir écrire la nand avec le mode USB Tools de Hekate va pouvoir changer mon approche, je tiendrais au courant des résultats dès qu'on en saura plus.

Je me dis que cette erreur s'affiche peut-être tout le temps sur toutes les consoles mais que tu ne la vois pas car non persistante. Comme elle n'est pas bloquante, dans le cas d'une NAND non brickée, memloader va ensuite lancer uboot (c'est uboot qui monte ensuite la mmc). A ce moment ta console va rebooter et réinitialiser le hardware donc l'écran (et le framebuffer). Ca serait donc logique que tous les print de memloader disparaissent à ce moment là, même obligatoire.

En y repensant je me suis toujours dis que l'implémentation de minerva ne provoquait aucune augmentation de perf de memloader. Si effectivement le chargement des tables mtc plante systématiquement, c'est pas étonnant ^^.

In fine, j'ai vraiment l'impression que cette erreur est une fausse piste. Si vraiment on veut en avoir le cœur net il faudrait modifier le code source de memloader pour stopper l'exécution à ce moment précis du programme et prouver que cette erreur s'affiche tout le temps.

 

edit : memloader est vraiment à laisser tomber mainteant qu'hekate a implémenté l'UMS. Côté perf c'est le jour et la nuit.

Modifié par eliboa, 21 juillet 2020 - 19:08.

[eliboa]

Effectivement aucun bootlogo, j'ai pourtant bien copié les fichier SYSTEM et USER et de ce que j'ai cru voir avec lockpick j'ai bien la bonne masterkey, reste a savoir ce qui bloque dans le boot de HOS

 

Ca peut valoir le coup d'ouvrir ta NAND via NxNandManager (en la montant d'abord via Hekate) et en renseignant préalablement les clés dans NxNandManager (tu peux le faire via la script de shadow aussi). Ca te permettrait de voir si USER et SYSTEM sont bien identifiés et que le file system est OK sur ces deux partitions. Ca exclurait un problème de partitions non chiffrées ou mal chiffrées par ex.

Modifié par eliboa, 21 juillet 2020 - 19:10.

[shadow256]

Ca peut valoir le coup d'ouvrir ta NAND via NxNandManager (en la montant d'abord via Hekate) et en renseignant préalablement les clés dans NxNandManager (tu peux le faire via la script de shadow aussi). Ca te permettrait de voir si USER et SYSTEM sont bien identifiés et que le file system est OK sur ces deux partitions. Ca exclurait un problème de partitions non chiffrées ou mal chiffrées par ex.

C'est prévu dans les tests, probablement un des premiers d'ailleurs comme je le fais à chaque fois une fois les clés dumpées.

[Linkynimes]

Malgré les différents test hier soir aucun changement sur le fonctionnement de la console avec sont black screen.
- On a vérifier avec NXNandManager, comme je m'en doutais le firmware d'origine était en 10.X (10.0.3) en revanche il trouvais cette version malgré le flash en 5.1.0
- On a essayer avec le script de shadow et TegraExplorer en 6.1.0, des erreurs dans USER, et NXNandManager ne trouve plus le firmware avec l'erreur keyset needing
- On a essayer avec plusieurs versions d'Hekate, de réparé la GPT aucun changement

Précision supplementaire :
J'ai tester le démarrage de SXOS, hier avant les tests SXOS ce bloquais sur le logo et ne voulais pas allez jusqu'au option de première configuration.
Aujourd'hui après les manipulations il ne démarre plus du tout sur SXOS cela reste sur un black screen.
Lockpick affiche des erreurs qu'il ne donnais pas auparavant.
Depuis les manipulations la console ne veux pas toujours allez en RCM (faut la forcer)

Aujourd'hui j'ai tester autre chose, a l'aide de cela https://github.com/s...accGen/releases et https://suchmememany...mid-boot-errors
J'ai pu essayer l'installation du firmware 10.0.4, toujours le même résultat un black screen que ce soit avec Hekate ou Fusee Primary
Je continue de regarder de mon côté en lisant les docs sur internet mais j'ai peu d'espoir de la refaire tourner d'autant qu'elle refuse d'allez tout le temps en RCM...

[eliboa]

La raison pour laquelle NxNM t'affiche un fw en 10.x alors que tu as downgrade est que le programme utilise plusieurs méthodes pour retrouver le firmware, notamment une qui inspecte les journaux (logs) dans SYSTEM et que ces derniers ne sont pas effacés lors de la maj du fw.

C'est d'ailleurs étonnant que tu aies encore ces journaux. SYSTEM (après ChoiDuJour) ne devrait plus contenir de logs... As-tu formaté SYSTEM avant de restaurer les fichiers générés par CDJ ?

 

Que veux-tu dire par la console ne veux pas toujours aller en RCM ? Et tu entends quoi par "faut la forcer" ?

J'ai du mal à croire que le pb pourrait être hardware car tu as réussi hier à dumper toutes les clés via Lockpick et que donc ça a lancé Sept qui load le fw du TSEC. Donc je pense qu'il n'y a pas de problème niveau TSEC ni côté mmu ou SDRAM sinon tout ça fonctionnerait pas.

 

Quelles sont les nouvelles erreurs remontées par TegraExplorer dans USER ? Logiquement tu devrais pouvoir aussi formater cette partition, ça ne devrait pas empêcher de lancer HOS.

 

[Linkynimes]

 

Que veux-tu dire par la console ne veux pas toujours aller en RCM ? Et tu entends quoi par "faut la forcer" ?

J'ai du mal à croire que le pb pourrait être hardware car tu as réussi hier à dumper toutes les clés via Lockpick et que donc ça a lancé Sept qui load le fw du TSEC. Donc je pense qu'il n'y a pas de problème niveau TSEC ni côté mmu ou SDRAM sinon tout ça fonctionnerait pas.

Je pense qu'il y a un souci avec la puce qui gère le port USB-C, déjà malgré toute les manipulations et l'auto RCM désactivé elle continue de clignoté a l'infinie sur le dock
Ensuite oui comme je l'ai dit je n'arrive plus a la passé en RCM (j'ai bien pensé a enlevé l'auto RCM bien sur et j'ai la batterie est a fond) j'ai beau faire + et power Tegra ne réagis pas.
+ Le fait que quand je test de la branche sur mon HUB 3.0 cela coupe mon casque ce que je trouve bizarre (tester avec 3 câble)

 

 

C'est d'ailleurs étonnant que tu aies encore ces journaux. SYSTEM (après ChoiDuJour) ne devrait plus contenir de logs... As-tu formaté SYSTEM avant de restaurer les fichiers générés par CDJ ?

Yep je l'ai refait ce matin avec le tuto indiquer plus haut avec le firmware 10.0.4 quand j'arrivais encore a démarré le mode RCM
et cela n'a rien changé sur NXNandManager j'ai toujours keyset needind
PS : Le script de shadow n'indiquer pas non plus la version après retest

 

 

Quelles sont les nouvelles erreurs remontées par TegraExplorer dans USER ? Logiquement tu devrais pouvoir aussi formater cette partition, ça ne devrait pas empêcher de lancer HOS.

je n'ai pas pu vérifier vue que je n'arrive plus a passé en RCM pour l'instant je sais simplement qu'elle c'est mal faite quand je l'ai appliqué avec Shadow absolument tout ce le script sur TegraExplorer faisait était rouge. (Il n'a rien réussie a faire)

 

 

J'ai du mal à croire que le pb pourrait être hardware

J'ai plus vraiment de solution, le RCM ne veux plus ce lancé sauf quand j'appuie longtemps sur power et encore sa ne marche plus depuis 1h.
Et je vois vraiment pas ce qui pourrais bloquer l'éxécution d'Atmosphère ou de l'OFW après restauration.

Shadow va me proposé une reconstruction de la NAND a partir du boot0 / boot1 / prodinfo / prodinfof et du prod.keys mais il n'est pas très confiant sur la remise en marche de la console.
Une connaissance ma envoyé ceci qu'il a trouvé sur gbatemp

Je suis pas spécialiste dans ce type d'information j'attendrais donc ton avis vue que tu est plus calé que moi dans cette partie.

Edit 11h45 : J'ai finalement réussie a la repassé en RCM et j'ai remis l'auto RCM pour qu'elle ne ce bloque plus sur le démarrage de la console ou autre.
J'ai démarré TegraExplorer est j'ai accédé a la partition USER mais je ne vois rien d'anormal
Edit : 11h50 : Retest avec le firm 10.0.4 sur Lockpick_RCM et encore plus d'erreur notamment avec le package2 mais il arrive bien a me dump le prod.keys
PS2 : Impossible de démarré Ubuntu (ce qui était possible hier) black screen également

Modifié par Linkynimes, 22 juillet 2020 - 10:53.

[milerwan]

@shadow256

Pourquoi ne préconises-tu pas le mode recovery de la Nintendo Switch pour réinitialiser complètement la console ?
 

1. Appuyez et maintenir les boutons de volume (+) et de volume (-), puis appuyez sur le bouton POWER pour allumer la console.

2. Maintenir les boutons de volume enfoncés jusqu'à ce que le menu du Mode restauration s'affiche.

3. Une fois dans le Mode restauration, sélectionner "Réinitialiser la console" -> "Continuer" et refuser tout ce qui conseille de réaliser une connexion préventive aux serveurs de Nintendo pour désappairer le compte Nintendo de l'utilisateur de la console (si préalablement enregistré).
 

Ca me semble plus simple à réaliser, non ?!?

Modifié par milerwan, 22 juillet 2020 - 10:52.

[Linkynimes]

@shadow256

Pourquoi ne préconises-tu pas le mode recovery de la Nintendo Switch pour réinitialiser complètement la console ?
 

1. Appuyez et maintenir les boutons de volume (+) et de volume (-), puis appuyez sur le bouton POWER pour allumer la console.

2. Maintenir les boutons de volume enfoncés jusqu'à ce que le menu du Mode restauration s'affiche.

3. Une fois dans le Mode restauration, sélectionner "Réinitialiser la console" -> "Continuer" et refuser tout ce qui conseille de réaliser une connexion préventive aux serveurs de Nintendo pour désappairer le compte Nintendo de l'utilisateur de la console (si préalablement enregistré).
 

Ca me semble plus simple à réaliser, non ?!?

cela ne supprime pas les logs dans la partition USER si je me souvient bien

Modifié par Linkynimes, 22 juillet 2020 - 11:06.

[eliboa]

Effectivement c'est bizarre ton histoire de RCM. Il y a plusieurs façon d'activer le mode RCM :

- En cas de corruption des BCT (autoRCM par ex)

- Via la combinaison de touche et court-circuit joycon

- Via un bit positionné dans un registre scratch du PMC (power management control). Il faut déjà un programme qui tourne sur le BPMP (boot CPU) pour faire le scratch (c'est ce que fait hekate pour rebooter en mode RCM).

Dans ton cas, si tu avais l'autoRCM tu devais passer par la méthode 1 avant alors que maintenant c'est la méthode 2. L'explication la plus logique est que le court-circuit ne se fait pas bien mais effectivement ça pourrait être un composant matériel.
Après recherche aussi sur gbatemp, effectivement on voit que d'autres personnes ont déjà eu ce problème. Si en plus tu as un problème de charge ou de niveau de batterie alors effectivement il semble qu'il faille remplacer le chip BQ24193. Apparemment ça peut aussi venir du M92T36 (quand pas de problème de niveau de charge).

Bah tu vois j'aurai pas imaginé un problème hw lié à l'alimentation. Sans doute que l'ancien proprio a utilisé un chargeur défecteux ou non homologué sur la console.

Je pense que tu devrais pas en avoir pour trop cher de réparation si c'est bien ça mais bon je m'avance pas c'est pas mon domaine ^^

[Linkynimes]

Effectivement c'est bizarre ton histoire de RCM. Il y a plusieurs façon d'activer le mode RCM :

- En cas de corruption des BCT (autoRCM par ex)

- Via la combinaison de touche et court-circuit joycon

- Via un bit positionné dans un registre scratch du PMC (power management control). Il faut déjà un programme qui tourne sur le BPMP (boot CPU) pour faire le scratch (c'est ce que fait hekate pour rebooter en mode RCM).

Dans ton cas, si tu avais l'autoRCM tu devais passer par la méthode 1 avant alors que maintenant c'est la méthode 2. L'explication la plus logique est que le court-circuit ne se fait pas bien mais effectivement ça pourrait être un composant matériel.
Après recherche aussi sur gbatemp, effectivement on voit que d'autres personnes ont déjà eu ce problème. Si en plus tu as un problème de charge ou de niveau de batterie alors effectivement il semble qu'il faille remplacer le chip BQ24193. Apparemment ça peut aussi venir du M92T36 (quand pas de problème de niveau de charge).

Bah tu vois j'aurai pas imaginé un problème hw lié à l'alimentation. Sans doute que l'ancien proprio a utilisé un chargeur défecteux ou non homologué sur la console.

Je pense que tu devrais pas en avoir pour trop cher de réparation si c'est bien ça mais bon je m'avance pas c'est pas mon domaine ^^

La batterie ce recharge bien par contre (en tout d'après Hekate + le câbe j'ai 0 souci), mais en effet un souci peut-être lié a l'alimentation, ayant très peu de connaissance hardware je sais pas si ce sera possible de la réparé

Edit : En effet la puce M92T36 serais bien la cause du soucis en regardant de plus près sur internet

Modifié par Linkynimes, 22 juillet 2020 - 11:58.

[eliboa]

La batterie ce recharge bien par contre (en tout d'après Hekate + le câbe j'ai 0 souci), mais en effet un souci peut-être lié a l'alimentation, ayant très peu de connaissance hardware je sais pas si ce sera possible de la réparé

Oui moi non plus j'y connais pas grand chose en hardware. Un technicien devrait pouvoir t'aider je pense, au moins pour le diagnostic.

Ça vaut peut-être le coup de continuer sur la voie du software et exclure toutes les possibilités avant d'envoyer ta console en réparation.

Pour voir si tu peux avoir des problèmes de batterie, apparemment il faut faire plusieurs mesures de ta jauge de batterie après plusieurs reboot d'hekate et s'assurer que le niveau est toujours cohérent / ne varie pratiquement pas.

 

Maintenant qu'on entrevoit un possible problème hardware d'alimentation j'imagine mieux pourquoi hekate tourne mais pas HOS. Le bootloader (officiel ou hekate) ne tourne que sur le BPMP (le CPU dédié au boot). A ce stade, le CPU principal (CCPLEX) ne tourne pas encore. Ce n'est qu'après chargement du bootloader (pour lancement de HOS) qu'il est lancé et requiert sans doute d'autre config du PMIC et des regulateurs de tension. Peut-être que c'est la que ça plante à cause du problème hardware, ce qui expliquerai que tout fonctionne niveau bootloader (dont lockpick et sept). A moins qu'hekate puisse voir le problème mais reste silencieux. Il faudrait tracer Hekate puis AMS pour voir exactement à quel moment ça plante. Je crois que ces deux programmes savent tracer via le port serie (UART) mais j'ai jamais utilisé perso (il faut recompiler les programmes en mode debug/trace). 

Pour le problème de SDRAM qui serait liè au problème vu avec l'erreur memloader, pourquoi pas, mais ça doit être indirect car hekate utilise aussi la sdram et locpick sauvegarde la config sdram avant de lancer sept (et ça semble bien fonctionner pour toi).

[shadow256]

Juste pour info la recréation d'un dump complet de la nand est faite, plus qu'à faire un zip puis à l'uploader se qui va me prendre un peu de temps. Une fois ce dernier test effectué j'aurais épuisé toutes les tentatives de restauration logiciel que je connais.