Здравствуйте

Такой вопрос есть ли возможность пошаговой отладки удаленной драйвера Linux на уровне исходников для архитектуры arm.

Есть, через kgdb (kgdboc)компорт и gdb. Для atmel я дописывал драйвер uart, Поищите на форуме - в поиске задайте ключевое слово kgdb.

Хе - через поиск форума не находит, нашел через нигму :)
http://starterkit.ru/new/index.php?name=Forums&op=showtopic&id=322

Цитата

Хе - через поиск форума не находит, нашел через нигму :)
http://starterkit.ru/new/index.php?name=Forums&op=showtopic&id=322

При переходе по ссылке выдает You are banned!

Не так давно в основную ветку ядра включили поддержку kgdb. Захотелось посмотреть как работает на нашей плате. После прочтения док сделал все как там написано и обнаружил что ничего не работает :) Прочитал еще раз и понял что драйвер atmel_serial не поддерживает poll ф-ции которые необходимы для отладки через последовательный порт. Посмотрел как это реализовано на других архитектурах, понял что все просто и поправил немного драйвер:
добавил

Код
1
#ifdef CONFIG_CONSOLE_POLL
static int atmel_poll_get_char(struct uart_port *port)
{
while (!(UART_GET_CSR(port) & ATMEL_US_RXRDY));

return UART_GET_CHAR(port);
}

static void atmel_poll_put_char(struct uart_port *port, unsigned char ch)
{
while (!(UART_GET_CSR(port) & ATMEL_US_TXRDY));

UART_PUT_CHAR(port, ch);
}
#endif

и в структуре static struct uart_ops atmel_pops добавил в конце
Код
1
..............
.pm = atmel_serial_pm,
#ifdef CONFIG_CONSOLE_POLL
.poll_get_char = atmel_poll_get_char,
.poll_put_char = atmel_poll_put_char,
#endif
};


Собрал insight (gdb с графическим фронтендом) c параметрами
./configure --prefix=/usr --target=arm-unknown-linux-uclibc
В ядре в строку инициализации добавил
kgdboc=ttyS0 kgdbwait
ядро как и полагается приостановило загрузку для ожидания дебаггера и все заработало. Можно ставить брейкпоинты, смотреть память, регистры, стек, наблюдать за переменными. Ядро пересобрал с поддержкой kgdb и отладочной информацией. В insight нужно загружать полученный большой vmlinux из корневой директории исходников ядра, в плату отправляется маленький zlinux - все как при обычной загрузке. В gdb (insight) указал параметры удаленного подключения - порт тот же на котором висит minicom (у меня это /dev/ttyUSB0) и скорость 115200 - то же что и в minicom. minicom номармально делит и порт и консоль с gdb.
Нужно отключать терминал после того как ядро пишет что ожидает подключения gdb и после этого устанавливать соединение из gdb иначе потом все глючит. В общем лучше бы вообще консоль на другой порт перевести - но у нас это не так просто.

У меня что то с первого раза не получилось, вот мой конфиг ядра

Код

# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_SELFTEST=y
CONFIG_DEBUG_OBJECTS_FREE=y
CONFIG_DEBUG_OBJECTS_TIMERS=y
CONFIG_DEBUG_OBJECTS_WORK=y
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400
# CONFIG_DEBUG_KMEMLEAK_TEST is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
CONFIG_DEBUG_KOBJECT=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_WRITECOUNT=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_LIST=y
CONFIG_DEBUG_SG=y
CONFIG_DEBUG_NOTIFIERS=y
CONFIG_DEBUG_CREDENTIALS=y
CONFIG_FRAME_POINTER=y
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_KGDB_TESTS=y
CONFIG_KGDB_TESTS_ON_BOOT=y
CONFIG_DEBUG_USER=y
.........................................................................
CONFIG_CMDLINE="mem=64M console=ttyS0,115200 initrd=0x23100000,0x800000 root=/dev/ram0 rw kgdboc=ttyS0 kgdbwait"

собрал insight, так же ./configure --prefix=/usr --target=arm-unknown-linux-uclibc, при попытке открыть vImage выдается сообщение

Invalid .debug_ranges data (no base address)
DW_AT_name

при попытке подключения зависает на минуту, потом выдает сообщение
unrecognized item "timeout" in "gSupported" response

Цитата

собрал insight, так же ./configure --prefix=/usr --target=arm-unknown-linux-uclibc

А у вас тулчейнт случайно не codesourcery ? тут нужно указывать префикс тулчайна.

Цитата

при попытке подключения зависает на минуту, потом выдает сообщение

Начиная с ветки ядра 2.6.35 что то поменяли, так что это описания для ядер не старше 2.6.34 если что. У меня сразу все тогда заработало.

Все нормально заработало, такой вопрос, не нашел в документации можно ли сделать так что бы можно было прервать ожидание подключения gdb и ядро продолжило работу без отладки.

Из параметров запуска ядра убрать kgdbwait, ядро можно остановить потом из терминала нажатием комбинации клавиш - я не помню ее.