Jump to content

    

Raydan

Участник
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Raydan

  • Rank
    Участник
  • Birthday 09/16/1988

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array
  1. Так дело в том, что я и не хотел, чтобы он бродил по исходникам стандартной библиотеки. При запуске собранной под x86 версии моей программы исходники libstdc++ ведь не требуются, и отладка идет только в рамках моего кода, то есть как я и хочу. Насчет сборки непосредственно на целевой плате -- а я не уверен что у меня будет место для полновесного gdb, когда с отладочной платы перейду на "боевую". Это сейчас я особо не ограничен в ресурсах.
  2. Настроил отладку ядра с помощью KGDB: - ядро собрано с поддержкой отладочных символов, с поддержкой отладки через KGDB, с поддержкой драйвера последовательного порта и т.д. - ноутбук с Debian GNU/Linux соединен с платой по кабелю Defender Serial-To-Usb, на ноуте - /dev/ttyUSB0, на плате /dev/ttyS0 - параметры загрузки ядра - console=ttyS0,115200n81 root=/dev/nfs rw nfsroot=192.168.0.7:/home/raydan/ltib/rootfs ip=192.168.0.10 init=/sbin/init kgdboc=ttyS0,115200 Далее в сессии minicom после появления приглашения оболочки нажимаю Ctrl+Alt+F+G и появляется сообщение: На ноуте выполняю 'gdb vmlinux', затем в gdb оболочке 'set remotebaud 115200' и 'target remote /dev/ttyUSB0'. Появляется сообщение: То есть будто все нормально соединилось и готово к отладке. Но когда пытаюсь выполнить команду 'next', то есть пошагать по ядру, появляется предупреждение При этом в консоли платы никаких сообщений, и gdb на ноуте повисает на неопределенное время. Кто-нибудь работал с подобным? -- С уважением, Дмитрий Винокуров
  3. Есть отладочная плата RDK Phytec LPC3250 с установленным gdbserver и ноутбук с Debian GNU/Linux и arm-linux-gnu-gdb. При отладке функция main "прошагивается" нормально, вход по функциям проходит тоже нормально, а вот при попытке входа на строке типа "obj = new Object();" Eclipse открывает окно с заголовком 2 operator new() new и текстом Can't find a source file at "/home/usb10132/ct1/bin/targets/src/gcc-4.3.2/libstdc++-v3/libsupc++/new_op.cc" Locate the file or edit the source lookup path to include its location. То есть, как я понимаю, вместо того, чтобы войти в конструктор Object, отладчик пытается найти исходник оператора выделения памяти и это у него ну никак не получается. Отладка просто средствами gdb без Eclipse ведет к тем же результатам (впрочем неудивительно). На всякий случай привожу по шагам процесс настройки отладки: Отладочная плата Phytec LPC3250 установлен gdbserver с помощью системы сборки LTIB запущена отлаживаемая программа командой gdbserver 192.168.0.7:6280 где 192.168.0.7 -- ip-адрес ноута, 6280 -- какой-нить незарезервированный порт. Вывод программы следующий: Process m2b created; pid = 374 Listening on port 6280 Ноутбук с Debian GNU/Linux установлены Eclipse и CDT (последних версий на данный момент), система сборки LTIB из CVS, а также отладчик gdb-arm-linux-gnu_6.8-3_i386 отсюда В меню Eclipse Run->Debug Configurations->Debugger проведена следующая настройка: в поле Debugger выбрано 'gdbserver debugger'; в табе Main в поле 'GDB debugger указан путь к установленному ARM-отладчику '/usr/bin/arm-linux-gnu-gdb'; в табе Shared Libraries указан путь к библиотекам платы (у меня это '/home/raydan/ltib/rootfs/lib', подкаталог монтируемой по NFS корневой ФС) в табе Connection выбран тип TCP, указаны ip-адрес платы и порт для соединения Может у кого-то был опыт отладки C++ программ в схожей ситуации, поделитесь пожалуйста. -- С уважением, Дмитрий Винокуров
  4. Возникла похожая проблема - пытаюсь отлаживать программы с помощью собственноручно собранный arm-linux-gdb на хосте + gdbserver из uClinux 20070130 на целевом (EA LPC2468). Соединение как понимаю проходит нормально: root# gdbserver 192.168.0.7:1234 hello Process hello created; pid = 195 Listening on port 1234 Remote debugging from host 192.168.0.7 Но отлаживать не получается: $ arm-linux-gdb hello.gdb GNU gdb 6.8 This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux"... (gdb) target remote 192.168.0.10:1234 Remote debugging using 192.168.0.10:1234 0xa1840050 in ?? () (gdb) b main Cannot access memory at address 0x3c Бинарники собирались в sdk, который поставляют Embedded Artists, Makefile для простенького HW следующий: CC=/home/user/uClinux-dist/tools/ucfront-gcc arm-elf-gcc DEST=/home/user/nfs FLAGS=-Wall CFLAGS=-Os -DEMBED -Dlinux -D__linux__ -Dunix -D__uClinux__ -fomit-frame-pointer -fno-common -fno-builtin LFLAGS=-Wl,-elf2flt="-r" TARGET=hello OBJECTS=$(TARGET).o .PHONY: all all: $(TARGET) $(TARGET): $(OBJECTS) $(CC) $(FLAGS) $(LFLAGS) -o $@ $^ %.o: %.c $(CC) $(FLAGS) $(CFLAGS) -c $^ install: cp $(TARGET) $(DEST) clean: rm -f *~ *.gdb *.o Еще я честно говоря не очень понимаю, каким образом elf файл hello.gdb c отладочной информацией должен согласовываться с flt файлом на целевом. Может у кого-нибудь был опыт отладки в подобных условиях?
  5. Да, верно, спасибо, Dron_Gus. Я уже и сам нашел эту ошибку, внимательней надо мне быть :)
  6. Приветствую. Пытаюсь настроить загрузку корневой файловой системы по протоколу NFS на плате Embedded Artists LPC2468, но после загрузки ядра и initrd в память система виснет. Некоторые подробности: - система uclinux 20070130 - ядро linux 2.6.21, опции CONFIG_ROOT_NFS и CONFIG_ROOT_FS включены - загрузчик U-Boot 1.1.6 - ядро и initrd грузятся по Trivial FTP по адресам 0xa1500000 и 0xa1800000 соответственно, потом загрузка идет с a1500000 - аргументы загрузки root=/dev/nfs initrd=0xa1800000 nfsroot=192.168.0.7:/home/raydan/nfsroot ip=192.168.0.10:192.168.0.7::255.255.255.0::eth0:none где 192.168.0.7 адрес сервера, 192.168.0.10 адрес платы - ари загрузке с аргументами root=/dev/ram initrd=0xa1800000,4000k console=ttyS0,115200N8 все проходит замечательно, NFS-раздел в запущенном uClinux монтируется без вопросов Привожу вывод: Booting from TFTP emac: link status = 100Mbps, full duplex emac: MAC address = 0:1a:f1: 0: 0: 0 TFTP from server 192.168.0.7; our IP address is 192.168.0.10 Filename 'uLinux.bin'. Load address: 0xa1500000 Loading: ################################################################# ################################################################# ################################################################# ########################## done Bytes transferred = 1126975 (11323f hex) TFTP from server 192.168.0.7; our IP address is 192.168.0.10 Filename 'romfs.img'. Load address: 0xa1800000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################ done Bytes transferred = 2074624 (1fa800 hex) ## Booting image at a1500000 ... Image Name: Linux 2.6.21 Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 1126911 Bytes = 1.1 MB Load Address: a0008000 Entry Point: a0008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... Кто-нибудь сталкивался с чем-то подобным? -- С уважением, Дмитрий Винокуров
  7. Сам себе отвечаю :) Все конечно же было просто - нужно было установить драйвер виртуального COM порта.
  8. Оу, глупость-то какая, нельзя же так невнимательно читать help. Спасибо, KRS. А светодиоды при попытке соединения через minicom загорались из-за того, что перемычки, соответствующие этим диодам, должны быть убраны после прошивки. После того, как убрал их, красный гореть перестал. Minicom все равно не работает, разбираюсь с настройками, но это уже к теме не относится
  9. Еще один момент - после выполнения этой команды светодиоды рядом с кнопкой RESET и рядом с P2.10 загораются красным. UPD: и еще один - при попытке соединиться через minicom также загораются эти светодиоды, а на экран minicom выводится строка непечатных символов
  10. При попытке прошивки платы Embedded Artists LPC2468 на системе Arch Linux командой lpcflash -vvv -i /dev/ttyUSB0 -f 12000 -w 0 -l /mnt/sda5/programs/mc\ images/u-boot.bin получаю следующий ответ: Operation WRITE 0x00000000. Set new port name Initializing termios structure. Entering to ISP mode Opening port... Retrive old port attributes... Apply new port attributes... Getting modem control lines state Setting RTS & DTR lines to OFF Opened. Getting modem control lines state Setting DTR line to ON Getting modem control lines state Setting RTS line to ON Getting modem control lines state Setting DTR line to OFF Getting modem control lines state Setting RTS line to OFF Autobaud sequence #1 Wait for response: 'Synchronized ' --> Synchronized Wait for response: 'Synchronized ' Wait for response: 'OK ' --> OK Send frequency (12000 kHz) Wait for response: '12000 ' Wait for response: 'OK ' --> OK Turning echo off... Wait for response: 'A 0 0 ' Request Part ID. Wait for command response with data. Part ID = '100925237 ' LPC2468 detected. Request Boot code version Wait for command response with data. Boot code version = 1 Done Writing memory. W 0 163240 Wait for command response with data. Error response: '3 14 ' Error writing to microcontroller. Closing port... Apply old modem control lines state... Apply old port attributes... Похоже, что инициализация проходит успешно, но потом возникает какая-то ошибка. Кто-нибудь сталкивался с подобным? Может с джамперами что-то напутано (сейчас на ISP установлена перемычка)?
  11. А как Вы закачали u-boot через USB кабель? Насколько я понял, Flash Magic работает с COM портами, и подключенная по USB плата у меня никак не распознавалась.
  12. ну как написано на сайте segger.com, для использования их GDB Server нужно приобрести лицензию, а OpenOCD - все-таки свободно распространяется
  13. Мда, неприятно, что J-Link с OpenOCD подружить не получалось. Хотя еще покопаю конечно. Тогда в рамках этой же темы вопрос: а для прошивки просто по USB проводу той же платы тоже через OpenOCD у кого-нибудь есть пример конфига? Пробовал работать с lpcflash, но хотелось бы с OpenOCD разобраться.
  14. Приветствую. Может кто-нибудь подсказать, какой конфигурационный файл использовать для прошивки платы EA LPC2468 с помощью MT-Link (вроде v 1.2) и openocd 0.1.0? Использовал конфиг отсюда, но openocd при запуске на многие строки выдает ошибки, пытался исправить по примеру других файлов из поставки, но ничего хорошего не получается - сейчас выдает ошибку " JTAG interface has to be specified, see "interface" command", пробовал указать "interface jlink", но та же ошибка.