ppz

Parce que je suis un peu fou, j'ai enlever le max77621 qui est sous le soc:

il n'y as plus aucune doute c'est 100% vérifié !! le max 77621 sous le soc est bien la cause de cette erreur.

je passe le sujet en résolu.

Bref, dans ton cas, on voit qu'il n'arrive pas à calculer cette variable "mtc_tables_size = ulzman(mtc_sdram_lzma, mtc_sdram_lzma_size, NULL, 0);"

Donc une piste pourrait être un problème au niveau de la SDRAM.

 

Je peux pas trop t'en dire plus, si ce n'est que tu peux sans doute limiter ton scope de recherche au boot CPU, à la IRAM/SDRAM et tout ce qui est alimentation.

Car les programmes tels que Hekate ou memloader ne tournent que sur le CCPLEX (le boot CPU) et font le minimum d'init hardware. En tout cas beaucoup moins que tout ce qui tourne sur le main CPU comme HOS, Atmosphère, etc.

La IRAM , je ne connaissait pas en fait c'est une mémoire intégrer au soc , il est possible qu'une ligne de tension sur 3 du max77621 soit pour la IRAM. j'ai pas le pinout du soc et c'est bien dommage !!
dans ce cas les processeur ne sont peut être pas actif mais la IRAM si , (hypothese). sa ne change rien mais j'aime bien savoir et La je n'aurai jamais la réponse!.

en tout cas sa m'a fait plaisir, c'est toujours sympas de réparer un truc en panne

Merci à vous et encore merci pour le taf que vous faite pour la communauté! Bravo a vous!
 

Bon finalement même si mon tegra que j'ai réinstaller a une ligne usb HS (pas de chance) je sait qu'il est fonctionnel et est capable de booter sur sa nand .

Donc j'ai vérifier sur une non patché , le max 77621 des cpu ( le max en dessous du soc ) est démarrer sur ses 3 lignes à 0.9V lorsque memloader est chargé , cela indique que le CCPLEX (le boot CPU merci eliboa) doit certainement laisser sa place au cpu(s) pour certaine fonction .

Cela est valable pour meloader , hekaté, et aussi lockpick.

Jai changer le max 77621 sur la carte mère en défaut et maintenant elle boot et fonctionne correctement , je ne peut malheureusement pas testé memloader a cause de la partie usb qui est hs sur le soc mais je garanti à 100% que cela fonctionnerai!
 
et voila panne trouver , max 77621 en dessous du soc!

Bonsoir , il me semblait avoir répondu mais je n'ai pas du valider le message.
La nand va directement au soc + alim 3.3V et 1.8V.
il y a peut être un problème de connections soc/ram ou soc/nand mais j'en doute.

Après peut-être que ça vient aussi de la communication entre un composant et l'USB, perso j'en doute mais bon ça peut être aussi une piste. 

 l'usb ( data line D+/D-) tres simple : un filtre puis directement au soc.. parfois il y a des fusible ESD (électricité statique) , le reste de lusb c'est pour le dock avec P13USB et il n'a aucune influence sur le boot. aucun composant ne discute avec l'usb ( a part le soc )

mais par contre un composant qui discute mal avec le soc oui je valide l'idée , par exemple le composant de la jauge de batterie (max 17050) si il est absent la switch ne boot pas cela fait un ecran noir. mais les tension soc etc sont présente , il me semble que BQ24193 cela fait aussi un écran noir ( c'est le gestionnaire de charge et il fait aussi gestion d’énergie entre batterie / chargeur ) mais si il est hs il n'y a quasiment aucune tension. par contre peut être qu'il fonctionne mais discute mal avec le soc ( si il discute ensemble ).

j'imagine quand même plus l’alimentation CPU ou GPU défaillante , se sont les max 77621 situé a gauche du soc et en bas du soc , il me semble que celui du bas gere le cpu.
peut etre que a un moment donnée dans les payload on active le cpu (donc son alimentation) et que sa plante.
car en fait en rcm ni le cpu et ni le gpu ne sont actif , il s'agit (et je ne sait comment trop l'expliquer) d'une sorte de microcontrôleur de base qui est actif dans le soc.

quoi qu'il en soit je vient d'avoir une carte mère avec piste usb hs mais elle est fonctionnel et hackable, je vait donc installer le soc et sa nand sur la carte mère défaillante et reprendre mes investigation bientôt , en espérant trouver d’où cela provient.

Bye