Débogage du noyau d'Android

Question

J'ai essayé d'obtenir kgdb pour faire fonctionner le Nexus One.

J'ai retiré le noyau de https://Android.googlesource.com et a permis de tout faire pour kgdb y compris kgdbts l'essai en utilisant menuconfig . J'ai construit avec succès le noyau et l'ai flashé sur l'appareil (qui est débloqué, enraciné et fonctionne avec CyanogenMod 7).

J'ai également suivi les instructions trouvées sur http://bootloader.wikidot.com/Android:kgdb pour permettre à la connexion usb d'agir comme une connexion série, comme l'exige le système de gestion de la sécurité. kgdb (et des communications testées de ttyACM0 a ttyGS0 avec succès).

Les dossiers suivants existent et indiquent que kgdboc y kgdbts ont été intégrées au noyau :

/sys/modules/kgdboc/parameters
/sys/modules/kgdbts/parameters

Voici la sortie de dmesg montrant l'état de l'installation. kgdbts les tests effectués montrent ce que (je pense) est une réussite des tests :

# dmesg | grep kgdb
<6>[   12.974060] kgdb: Registered I/O driver kgdbts.
<6>[   12.981781] kgdbts:RUN plant and detach test
<6>[   12.995178] kgdbts:RUN sw breakpoint test
<6>[   13.002441] kgdbts:RUN bad memory access test
<6>[   13.010864] kgdbts:RUN singlestep test 1000 iterations
<6>[   13.019042] kgdbts:RUN singlestep [0/1000]
<6>[   13.077850] kgdbts:RUN singlestep [100/1000]
<6>[   13.132720] kgdbts:RUN singlestep [200/1000]
<6>[   13.187500] kgdbts:RUN singlestep [300/1000]
<6>[   13.242370] kgdbts:RUN singlestep [400/1000]
<6>[   13.297149] kgdbts:RUN singlestep [500/1000]
<6>[   13.351928] kgdbts:RUN singlestep [600/1000]
<6>[   13.406829] kgdbts:RUN singlestep [700/1000]
<6>[   13.461578] kgdbts:RUN singlestep [800/1000]
<6>[   13.516540] kgdbts:RUN singlestep [900/1000]
<6>[   13.570922] kgdbts:RUN do_fork for 100 breakpoints
<6>[   21.117645] kgdb: Unregistered I/O driver kgdbts, debugger disabled.

Je crois que le problème que je rencontre est de faire en sorte que le noyau déclenche kgdb .

# echo -n g > /proc/sysrq-trigger

Le résultat est de me ramener à l'invite de commande et (je pense) qu'elle est supposée tout geler et envoyer une invite via usb qui est utilisée comme un pseudo port série puisque le téléphone n'en a pas de réel.

D'après ce que j'ai compris de mes recherches, cette invite est censée être le déclencheur qui me permettra d'émettre

(gdb) target remote /dev/ttyACM0

Et se connecter à une session de débogage avec le noyau.

J'ai également testé /proc/sysrq-trigger con b y c Je confirme juste que je suis capable de passer certaines commandes à sysrq .

Donc ma question, suite à ma longue tentative de fournir autant d'informations que possible, est la suivante : pourquoi l'industrie de l'énergie est-elle si importante ? g ne déclenche pas le débogueur ?

C'est ma première tentative de débogage du noyau sur n'importe quel système et je ne sais plus comment formuler ma recherche sur Google, alors je me tourne vers vous. Merci !

(J'ai aussi essayé de mettre kdgbwait dans la ligne de commande du noyau sans succès car je crois que ce n'est pas encore supporté par le noyau Android).

Answer 1

Les questions sur le noyau Android sont rares sur [SO], mais comme personne d'autre n'a répondu, j'ai fourni mes conclusions sur ce problème. Malheureusement, je n'ai pas de Nexus One pour le tester, donc cette réponse n'est pas destinée à résoudre votre problème étape par étape, mais devrait vous indiquer où chercher.

La seule ressource utile que j'ai trouvée sur ce problème se trouve dans un document intitulé Patch LKML par Dongdong Deng Il est donc peu probable qu'il s'agisse d'un problème de configuration, car ils sont généralement nombreux et bien connus.

Cela indique qu'il y a un problème avec la construction de votre noyau. Je serais tenté de recommencer avec les dernières versions de CM et voir si le problème disparaît.

Sinon, essayez de signaler ce problème à l'équipe de Cyanogen et voyez s'il s'agit d'un problème connu ou s'il existe une solution de contournement simple.

En dernier recours, vous pouvez essayer le patch si les versions sont compatibles. La seule alternative est de retrousser vos manches et de commencer à pirater le noyau CM pour intégrer le patch.

Bonne chance.

Answer 2

J'ai trouvé ce message d'un poste connexe et je voulais dire que je viens de publier le travail que j'ai fait pour que cela fonctionne sur le Nexus 6 si quelqu'un est intéressé :

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

Il est intéressant de noter que le problème de l'OP avec sysrq est un problème que j'ai également rencontré. La raison de ce comportement est que KGDB ne s'est pas initialisé correctement et n'a pas réussi à installer le gestionnaire pour le déclencheur 'g' (kgdb). C'est pourquoi toutes les autres commandes sysrq fonctionnent toujours.

Explication plus longue (merci @Robert) :

Pour que cela fonctionne, j'ai dû fabriquer un câble de débogage UART basé sur ce blog d'Accuvant . Il s'agit d'un circuit assez simple qui consiste en un breakout FTDI 3.3v basic (disponible chez SparkFun au moment de la rédaction), ainsi que 4 résistances (2 x 1K Ohm, 1 x 1.2K Ohm et 1 x 100Ohm), et une prise casque Tip-Ring-Ring-Sleeve (TRRS) à 4 éléments. Les résistances fournissent essentiellement un diviseur de tension pour réduire la tension de 3,3 V à un niveau 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 une tension (~2.8V) sur l'une des broches et sait qu'il doit fournir une interface UART via ce câble. Le breakout FTDI se branche sur votre PC via USB et de là vous pouvez accéder aux messages de la console 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 pilote série du Nexus 6 (msm_serial_hs_lite.c) pour supporter KGDB (spécifiquement, la capacité d'effectuer des opérations d'E/S de caractères atomiques). Je viens de porter ces changements à partir du code principal du noyau Linux, car un type appelé Stephen Boyd avait fait le travail difficile sur le pilote série MSM (Qualcomm) complet msm_serial.c. Ses changements sont les suivants trouvé ici ou recherchez simplement "msm_serial : add support for poll_" sur Google. Le portage n'a pas été difficile et mon code peut être trouvé sur github .

En plus de cela, vous devez être capable de construire un noyau personnalisé pour votre N6, ce que google fournit. beaucoup d'informations sur . Vous devez ensuite créer une image de démarrage qui contient les modifications KGDB dans le repo github. J'ai pris le noyau de base de https://developers.google.com/Android/nexus/images Je l'ai extrait (en utilisant abootimg -x) et j'ai ensuite utilisé la commande suivante pour l'empaqueter avec mon noyau personnalisé (zImage-dtb) et des paramètres de ligne de commande supplémentaires pour m'assurer que KGDB serait chargé et pointerait 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 mon boot.img créé, j'ai pu démarrer dans celui-ci en utilisant la commande fastboot boot boot.img, ouvrir un shell adb et ensuite déclencher un point d'arrêt dans le noyau Android en utilisant la commande :

echo -n g > /proc/sysrq-trigger

Il est utile de mentionner pour être complet que vous avez besoin des privilèges de superutilisateur pour accéder à /proc/sysrq-trigger donc vous devez 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 sous Ubuntu 14.04 et j'utilise arm-eabi-gdb du répertoire 'prebuilts' dans mon dépôt de sources AOSP. Enfin, entrez les commandes suivantes :

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

Si tout va bien, cela devrait immédiatement donner lieu au point d'arrêt kgdb (que votre écriture dans /proc/sysrq-trigger a produit) et vous pouvez commencer à déboguer.

Answer 3

Je n'ai pas d'expérience avec le matériel Android, mais j'ai fait un noyau compilé par kgdb fonctionnant comme client VirtualBox, et depuis l'hôte, je me connecte à l'invité via un port série virtuel, et en utilisant gdb (avec la commande standard "target remote"), je peux suivre tout le démarrage du noyau de l'invité virtuel - avec l'aide de kgdbwait. Sans cela, je peux écrire un module de noyau qui ne fait rien d'autre que d'implémenter une assemblée en ligne qui appelle "int 13", qui est 0xcc. Une fois chargé, un point d'arrêt apparaîtra du côté hôte de la connexion série, et je pourrai alors fixer le point d'arrêt et continuer l'exécution du noyau. Cela fonctionne parce que kgdb gère l'exception "int 13". Si vous créez explicitement un autre type d'exception comme "*p = 0", et que p pointe vers NULL, vous obtiendrez toujours un point d'arrêt, mais je doute que vous puissiez continuer l'exécution.