- une exception "page fault" arrive sur le CPU vers cpm_uart_start_tx+0x4c (c'est là que Linux est sensé mettre à jour les structures de données de la MMU pour mapper la page à laquelle on veut accéder).
- Pour une raison qui m'échappe (je ne connais pas cette architecture), la demande de map est jugée mauvaise et donc handle_page_fault appelle bad_page_fault (par l'intermédiaire de do_page_fault).
- c'est ce bad_page_fault qui affiche "kernel access of bad area" (arch/ppc/mm/fault.c).
- linux termine le processus fautif (init) en lui envoyant un SIGSEGV (11)
- il est tout à fait possible que le comportement que tu observes seulement avec le process init et pas avec ton petit programme vienne de l'initialisation du port série faite par init (genre le set_termios là) ce qui pourrait mettre le driver dans un état différent que ton petit test.
- une question un peu naïve, mais on tente : es-tu sûr d'avoir toute les pages dont tu as besoin pour accéder au hard mappées ? je ne connais pas du tout ce hard, mais par exemple les registres auxquels on accède par la structure smc_t sont-ils sur la même page que le registre tx ?
- System.map permet de déduire les symboles dans lequel tu es si tu veux faire le décodage à la main, mais là, comme tu compiles avec les symboles de debug, le plus sage est de penser que ta pile est morte lorsqu'il essaye de décoder les derniers symboles
- Enlever ce warning : "WARNING: no UART devices found on platform bus!" en définissant le platform_device qui va bien pour ton SoC, il me semble que dans cettre structure il y a aussi les pages physiques que linux doit mapper pour ton device
- Il y a l'air d'avoir quelques versions différentes de l'UART cpm, bien s'assurer que l'on compiler le noyau avec la bonne config pour ton hard (cpm1, cpm2, ?)
- Le driver cpm_uart à l'air d'avoir pas mal changé entre la version 2.6.19 et la version actuelle, mettre à jour ce driver peut être une bonne idée ?
# Quelques pistes
Posté par Damien Lespiau . En réponse au message Kernel oops lors de init (busybox) sur powerquicc. Évalué à 2.
- Pour une raison qui m'échappe (je ne connais pas cette architecture), la demande de map est jugée mauvaise et donc handle_page_fault appelle bad_page_fault (par l'intermédiaire de do_page_fault).
- c'est ce bad_page_fault qui affiche "kernel access of bad area" (arch/ppc/mm/fault.c).
- linux termine le processus fautif (init) en lui envoyant un SIGSEGV (11)
- il est tout à fait possible que le comportement que tu observes seulement avec le process init et pas avec ton petit programme vienne de l'initialisation du port série faite par init (genre le set_termios là) ce qui pourrait mettre le driver dans un état différent que ton petit test.
- une question un peu naïve, mais on tente : es-tu sûr d'avoir toute les pages dont tu as besoin pour accéder au hard mappées ? je ne connais pas du tout ce hard, mais par exemple les registres auxquels on accède par la structure smc_t sont-ils sur la même page que le registre tx ?
- System.map permet de déduire les symboles dans lequel tu es si tu veux faire le décodage à la main, mais là, comme tu compiles avec les symboles de debug, le plus sage est de penser que ta pile est morte lorsqu'il essaye de décoder les derniers symboles
- Enlever ce warning : "WARNING: no UART devices found on platform bus!" en définissant le platform_device qui va bien pour ton SoC, il me semble que dans cettre structure il y a aussi les pages physiques que linux doit mapper pour ton device
- Il y a l'air d'avoir quelques versions différentes de l'UART cpm, bien s'assurer que l'on compiler le noyau avec la bonne config pour ton hard (cpm1, cpm2, ?)
- Le driver cpm_uart à l'air d'avoir pas mal changé entre la version 2.6.19 et la version actuelle, mettre à jour ce driver peut être une bonne idée ?
Bon courage !