Débogage Du Noyau Android

les questions sur le noyau Android sont rares sur [SO], comme personne d'autre n'a répondu, j'ai fourni mes conclusions sur cette question. Malheureusement, je n'ai pas un nexus un pour tester cela sur donc cette réponse n'est pas destinée à une résolution étape par étape de votre problème, mais devrait vous indiquer dans la bonne direction de l'endroit où regarder.

la seule ressource utile que j'ai trouvé sur ce problème est dans un lkml patch par Dongdong Deng , il est donc peu probable que problème de configuration, car ils sont habituellement abondants et bien connus.

Cela indique qu'il ya un problème avec votre noyau. Je serais tenté de recommencer avec les dernières versions de CM et de voir si le problème vient de là.

sinon, essayez de le signaler à l'équipe de cyanogen et voyez s'il s'agit d'un problème connu ou d'une solution simple.

en dernier recours, vous pouvez essayer le patch si les versions sont compatible. La seule alternative est de retrousser vos manches et de commencer à hacker le noyau CM pour incorporer le patch.

bonne chance.

Je n'ai aucune expérience avec le matériel Android, mais j'ai fait kgdb-compilé le noyau fonctionnant comme client VirtualBox, et de l'hôte se connecter à l'invité via le port série virtuel, et en utilisant gdb (avec la commande" cible à distance " standard) je peux marcher à travers le boot entier du noyau invité virtuel - avec l'aide de kgdbwait. Sans cela, je peux écrire un module du noyau qui ne fait rien à part implémenter un assemblage en ligne appelé "int 13", qui est 0xcc. Une fois chargé, un point de rupture apparaîtra du côté hôte de la connexion série, et ensuite je peux définir le point de rupture et continuer l'excution du noyau. Cela fonctionne parce que kgdb gère l'exception "int 13". Si u crée explicitement un autre type d'exception comme "*p = 0", et que p pointe vers NULL, u obtiendra quand même un point de rupture, mais je doute que u puisse poursuivre l'exécution.

trouvé ce post d'un post lié et voulait dire que je viens de publier un peu de travail que j'ai fait pour obtenir ce travail sur le Nexus 6 Si quelqu'un est intéressé:

http://www.contextis.com/resources/blog/kgdb-android-debugging-kernel-boss /

fait intéressant, le problème de l'OP avec sysrq était un que j'ai également rencontré. La raison de ce comportement est que KGDB n'était pas initialiser correctement ne réussit pas à installer le gestionnaire du déclencheur " g " (kgdb). C'est pourquoi toutes les autres commandes sysrq fonctionnent encore.

explication plus longue (Merci @ Robert):

pour obtenir ce travail j'ai dû faire un câble de débogage UART basé sur ce blog accueillant . Il s'agit d'un circuit assez simple qui se compose D'une sortie de base FTDI 3.3 v (Disponible chez SparkFun au moment de la rédaction), ainsi que de 4 résistances (2 x 1k Ohm, 1 x 1,2 K Ohm et 1 x 100Ohm), et un casque d'écoute à quatre éléments-Manchon annulaire (TRRS) jack. Les résistances sont essentiellement fournir un diviseur de tension pour réduire le 3.3 v à quelque chose d'un peu plus sûr pour votre téléphone. En insérant la prise audio avec l'autre extrémité connectée à votre circuit imprimé, le sous-système audio reconnaît qu'une tension (~2,8 V) sur l'une des broches et il sait fournir une interface UART via ce câble. Le FTDI breakout se connecte à votre PC via USB et d'ici vous pouvez accéder à la console messages via un émulateur de terminal comme minicom. Cependant, vous avez maintenant une interface série via le même mécanisme et c'est ce que nous pouvons utiliser pour une connexion KGDB.

donc, à ce stade, quelques changements relativement mineurs sont nécessaires au conducteur en série du Nexus 6 (msm_serial_hs_lite.c) pour soutenir KGDB (spécifiquement, la capacité d'effectuer des opérations de caractère atomique I/O). Je viens de porter ces modifications du code de la ligne principale du noyau Linux comme un certain Stephen Boyd l'avait fait le dur labeur du pilote en série MSM_SERIAL MSM (Qualcomm) msm_serial.C. Ses modifications peuvent être trouvé ici ou simplement rechercher "msm_serial: ajouter le support pour poll_" sur Google. Le port n'était pas difficile et mon code peut être trouvé sur github .

mis à part que vous devez être en mesure de construire un noyau personnalisé pour votre N6 qui fournit google beaucoup d'informations sur . Vous devez ensuite créer une image de démarrage qui contient les modifications KGDB dans le GitHub repo. J'ai pris le noyau d'origine de https://developers.google.com/android/nexus/images , l'a extrait (en utilisant abootimg-x) et a ensuite utilisé la commande suivante pour le remballer avec mon noyau personnalisé (zImage-dtb) et des paramètres de ligne de commande supplémentaires pour s'assurer que KGDB serait chargé et pointer vers mon port série comme ceci:

abootimg -u boot.img -k zImage-dtb -c 'cmdline=console=ttyHSL0,115200,n8 kgdboc=ttyHSL0,115200 kgdbretry=4'

avec ma botte.img créé j'ai pu démarrer en utilisant la commande fastboot boot boot.img, ouvrez un shell adb puis déclenchez un point de rupture dans le noyau Android en utilisant la commande:

echo -n g > /proc/sysrq-trigger

pour être complet, il est important de mentionner que vous avez besoin des privilèges de super-utilisateur pour accéder à /proc/sysrq-trigger afin d'avoir root.

avec le téléphone arrêté, et votre câble de débogage connecté, lancez une version de GDB pour ARM sur votre PC hôte avec votre noyau non compressé comme argument (par exemple arm-eabi-gdb ./ vmlinux). Note: je suis lancer Ubuntu 14.04 et utiliser arm-eabi-gdb à partir du répertoire 'prebuilts' dans mon dépôt source AOSP. Enfin, entrez les commandes suivantes:

set remoteflow off
set remotebaud 115200
target remote /dev/ttyUSB0

étant donné que tout va bien, cela devrait se casser immédiatement dans le point de rupture kgdb (que votre write to /proc/sysrq-trigger produit) et vous pouvez commencer à déboguer.