SYSTEM POWERED OFF VIA ARM7 SPI POWER DEVICE

sauf erreur de ma part, je parviens maintenant à avoir le code de runme qui tourne sur desmume (version 0.9.6-SVN) quand il est compilé avec en mode “dkp-r32”. Par contre, si j’essaie d’utiliser les même outils pour AppleAssault, j’ai droit à un magnifique “SYSTEM POWERED OFF VIA ARM7 SPI POWER DEVICE”. Je soupçonne desmume de couper froidement toute communication avec GDB quand ça se produit, ce qui, du coup, m’empêche d’en chercher la cause >_<

IPC9@201564a send FIFO < 0x480A725C -- size 000 (l 0x8505, tail 00) (r 0x8501, tail 05)
-- IRQ delivering.
IPC7@37ff16a recv FIFO > 0x480A725C -- size 000 (l 0x8401, tail 05) (r 0x8504, tail 01)
IPC9@201564a send FIFO < 0x04010040 -- size 000 (l 0x8505, tail 01) (r 0x8501, tail 08)
-- IRQ delivering.
IPC7@37ff16a recv FIFO > 0x04010040 -- size 000 (l 0x8401, tail 08) (r 0x8504, tail 02)

Evidemment, la version “standard” de desmume (0.9.5, livrée par Ubuntu), elle, coince à l’initialisation du Wifi, et ça ne vaut donc même pas la peine de continuer à chercher.

Je vais donc devoir aller ajouter l’équivalent-émulateur d’un gurumediation dans le code de emu_halt(), voire y ajouter un DEBUG_dumpMemory() …

Après modification, et si j’en crois mon nouvel outil, c’est au niveau de libnds_exit.c que le processeur ARM9 s’est arrèté, juste après un appel à powerOn, qui aurait été appelé quelque part à partir de fifosystem.c (dans la fonction waitBlock, ce qui me paraît on ne peut plus louche …) Le processeur ARM7, lui, s’est bloqué au niveau de writePowerManagement appelé depuis powerValueHandler. Ca, au moins, c’est cohérent. Le dernier message transmis de l’ARM9 vers l’ARM7 est (poétiquement) un 0x04010040, ce que je peux décoder en:

• 0xxx.xxxx : Channel 0 : power management
• x4xx.xxxx : Immediate value (type=4)
• xxx1.xxxx : PM_REQ_ON
• xxxx.0040 : PM_SYSTEM_PWR (?…)

Ma foi, ça me semble être tout à fait la situation découlant d’un appel à systemShutdown, dernière opération de __libnds_exit() lorsque le “retour à hbmenu” a échoué 😛
Bref, heureusement, je m’étais donné un “faux registre” 0x04042000 pour envoyer des mots de 32 bits hors de l’émulateur … ce qui m’amène à la conclusion que mon interception des exceptions C++ s’est fait court-circuiter par un appel “abort()” qui a ordonné la fin du programme … grr.

… et derrière tout ça, l’oubli de –gbaslot-rom, désormais indispensable pour EFS sous desmume >_<.