Jump to content

    

alvy

Участник
  • Content Count

    67
  • Joined

  • Last visited

Community Reputation

0 Обычный

About alvy

  • Rank
    Участник
  • Birthday 08/12/1983

Контакты

  • Сайт
    http://zaval.tomsk.ru
  • ICQ
    0

Информация

  • Город
    Томск
  1. Имеется отладочная плата с TMS320C6A8168 на борту + JTAG emulator (XDS100). Устанавливаю последний CCS v5, создаю проект, пытаюсь залить его в плату, но при создании ccxml файла конфигурации не вижу среди "Board or Device" Cortex-A8 ядра - как мне добавить его поддержку?
  2. Выбираю ОС для TMS320C6A8168 - для ARM ядра (на DSP скорее всего будет SYS/BIOS). Требования - реал тайм, но при этом требуется организовать доступ через Ethernet (telnet'ом, например). У TI есть Network Development Kit, который предоставляет такую функциональность, но семейство Integra не поддерживается. Какие возможные пути решения / альтернативные ОС?
  3. А если при установке CCS передвинуть дату очень сильно вперед, а после установки вернуть назад - триальный период увеличится?
  4. TMDXEVM8168DDR2

    Цитата(SimpleSoft @ Aug 12 2011, 00:21) Нет такого. На карточке CCSv5 (Linux & Windows версии), Linux и всё. А какая лицензия идет у CCSv5? Тестовая ограниченная по времени или по коду? Есть ли в природе принципиальная схема этой отладочной платы? Если кто таковой располагает, буду очень признателен за нее (можно на почту av[ собака ]nikor.tsk.ru )
  5. TMDXEVM8168DDR2

    С отладочной платой идет дистрибутив линукса, соответственно должна еще быть документация по его развертыванию и особенностям.
  6. Доброго времени суток! Разыскивается документацию к TMDXEVM8168 - как минимум интересно глянуть на pdf, как максимум - все содержимое SD карты, идущей в комплекте. Плата идти будет долго, а поизучать документацию хотелось бы пораньше. Заранее огромное спасибо!
  7. LPC3250 S1Loader

    Проверить регионы размещения S1L - расписать, где хранится kickstart, где S1L, в каких секторах хранятся настройки S1L, не перезаписываются ли они u-bootником поверх... Когда ковырялся с LPC3250, все проблемы были либо от другого типа используемой NAND/SDRAM, либо от пересечения регионов в NAND
  8. KSZ8841 и Ethernet CRC

    Цитата(iosifk @ Apr 15 2011, 16:25) Потому что Вы ее передаете как данные. И она показывается как данные... В том то и дело, что в логах ее видно не как данные - появляется отдельная строчка типа Frame check sequence: 0xc94dafdf [incorrect, should be 0xdee9ac72] Собственно это и сбило с толку. А поскольку опыта работы на этом уровне Ethernet еще не очень много, то и возникли вопросы )
  9. KSZ8841 и Ethernet CRC

    Цитата(Rst7 @ Apr 15 2011, 15:16) Я просил .pcap-файл, в котором есть все данные, а не текст. Кстати, что за версия WireShark? Извиняюсь, не заметил сразу. С Wireshark'ом работаю всего несколько дней, с ходу не совсем понял, как получить этот самый pcap файл. Как только мне отдадут оборудование постараюсь сделать такой лог. Версия 1.4.4 Только что ответили из Micrel: ЦитатаWireshark does not capture FCS field of a packet. See FAQ 7.9 and 7.10 for detail information. http://www.wireshark.org/faq.html#q7.9 Так что похоже, что действительно все нормально формируется. Как доберусь до оборудования буду проверять. Все, всем спасибо за правильные вопросы и участие - Wireshark действительно не показывает контрольную сумму, НО почему-то есил ее продублировать, то он ее покажет... В общем, CRC микросхемой формируется, пакеты до программы доходят. Тему можно закрывать.
  10. KSZ8841 и Ethernet CRC

    [attachment=55583:log.7z] Там очередность пакетов такая же: сначала пакеты с неправильной контр. суммой, потом с отсутствующей, потом с правильной.
  11. KSZ8841 и Ethernet CRC

    Цитата(Rst7 @ Apr 15 2011, 13:44) Собственно говоря, лог Wireshark'а в студию. 1. пакет с неправильной CRC32 (должен быть отброшен сетевой картой). KSZ8841 было указано отправить 112 байт, последними 4 байтами отправлена контрольная сумма (Frame check sequence): КодFrame 1: 112 bytes on wire (896 bits), 112 bytes captured (896 bits) Ethernet II, Src: OrientPo_01:23:45 (00:13:37:01:23:45), Dst: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)     Destination: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)     Source: OrientPo_01:23:45 (00:13:37:01:23:45)     Type: IP (0x0800)     Frame check sequence: 0xc94dafdf [incorrect, should be 0xdee9ac72] Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.100 (192.168.0.100) User Datagram Protocol, Src Port: terabase (4000), Dst Port: newoak (4001) Data (66 bytes) 0000  00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f   ................ 0010  10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f   ................ 0020  20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f    !"#$%&'()*+,-./ 0030  30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f   0123456789:;<=>? 0040  40 41                                             @A 2. пакет с отсутствующей контрольной суммой (так же должен быть отброшен сетевой картой). KSZ8841 было указано отправить 108 байт, бит TXCE Transmit CRC Enable взведен, но контрольной суммы нет: КодFrame 13: 108 bytes on wire (864 bits), 108 bytes captured (864 bits) Ethernet II, Src: OrientPo_01:23:45 (00:13:37:01:23:45), Dst: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)     Destination: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)     Source: OrientPo_01:23:45 (00:13:37:01:23:45)     Type: IP (0x0800) Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.100 (192.168.0.100) User Datagram Protocol, Src Port: terabase (4000), Dst Port: newoak (4001) Data (66 bytes) 0000  00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f   ................ 0010  10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f   ................ 0020  20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f    !"#$%&'()*+,-./ 0030  30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f   0123456789:;<=>? 0040  40 41                                             @A 3. пакет с правильной контрольной суммой (принят и сетевой картой и программой). Все так же как и в первом случае: КодFrame 14: 112 bytes on wire (896 bits), 112 bytes captured (896 bits) Ethernet II, Src: OrientPo_01:23:45 (00:13:37:01:23:45), Dst: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)     Destination: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)     Source: OrientPo_01:23:45 (00:13:37:01:23:45)     Type: IP (0x0800)     Frame check sequence: 0xdee9ac72 [correct] Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.100 (192.168.0.100) User Datagram Protocol, Src Port: terabase (4000), Dst Port: newoak (4001) Data (66 bytes) 0000  00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f   ................ 0010  10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f   ................ 0020  20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f    !"#$%&'()*+,-./ 0030  30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f   0123456789:;<=>? 0040  40 41                                             @A Как написано в Wikipedia про Wireshark ЦитатаПрограмма позволяет пользователю просматривать весь проходящий по сети трафик в режиме реального времени, переводя сетевую карту в неразборчивый режим (англ. promiscuous mode).
  12. KSZ8841 и Ethernet CRC

    Цитата(iosifk @ Apr 15 2011, 12:38) Вы смотрите "принятые правильно пакеты" или "поголовно все пакеты, в том числе и неправильные"? Если же Вы делаете "контрольную сумму в ПЛИС", то это возможно трактуется как данные... Проверьте сколько байт данных считывается в этом случае... Wireshark показывает все пакеты, даже с неправильными контрольными суммами в заголовках и неправильным или отсутствующим совсем CRC32. Сейчас получается: передаю микросхеме общую длину пакета с заголовками, но без CRC32 - до сетевой карты доходит все, но без CRC. Пробовал указывать длину пакета + 4 пустых (0x00) байта под CRC - в таком же нулевом виде они и показываются в Wireshark'е. Такое ощущение, что микросхема вообще игнорирует указанный в первом посте бит. В случае, когда я сам формирую CRC и добавляю ее в конце пакета, сетевая карта принимает пакет и успешно передает его программе на ПК. Понятно, конечно, что в крайнем случае вариант с ручным подсчетом контрольной суммы вполне подходит, но хотелось бы все таки заставить считать ее в KSZ8841. Обратился в службу техподдержи Micrel, но уже полтора дня ответа не приходит.
  13. Имеется KSZ8841-16MVLI. Задача - передать через нее UDP пакет. С самим пакетом проблем нет - заголовки, контрольные суммы в заголовках - все проверено на приемной стороне Wireshark'ом. Проблема возникла с контрольной суммой CRC32, которая следует после данных, в конце пакета. В даташите на микросхему есть регистр Transmit Control Register (банк 16, адрес 0), в котором, в частности, есть бит "TXCE Transmit CRC Enable". При инициализации записываю в этот бит 1. Но при отправке пакета в Wireshark'е поле контрольной суммы не появляется. Сейчас временно формирую контрольную сумму в ПЛИС, но по идее ее должна формировать сама микросхема - у кого-нибудь получилось заставить ее это делать?
  14. LPC32xx ошибки при старте Linux

    Собрал последнюю версию из CVS (Linux version 2.6.34), ошибок JFFS2 на вскидку меньше стало, но там вообще не конфигурируется eth0 - в стартовом логе есть строчка: ... Creating 5 MTD partitions on "lpc32xx_nand": 0x000000000000-0x000000320000 : "ea3250-boot" 0x000000320000-0x000000fa0000 : "ea3250-uboot" 0x000000fa0000-0x000000fe0000 : "ea3250-ubt-prms" 0x000000fe0000-0x0000013e0000 : "ea3250-kernel" 0x0000013e0000-0x000008000000 : "ea3250-jffs2" eth%d: Invalid ethernet MAC address. Please set using ifconfig lpc_mii_bus: probed ... Как такое победить? Попытки установить MAC адрес вручную с помощью ifconfig не принесли успеха