an.skornyakov 0 18 марта, 2013 Опубликовано 18 марта, 2013 · Жалоба А в U-boot сетка работает? тоже нет.. Ну то есть оно хватает пачку прерываний и без разбору пихает их в общий обработчик. Стоило стараться разводить их по разным линиям аппаратно, чтобы потом программисты снова все смешали! :) Проверьте, что у вас platform device регистрирует весь диапазон прерываний. Да вроде весь, на каждый EMAC по 4 прерывания. static struct resource ti816x_emac1_resources[] = { { .start = TI816X_EMAC1_BASE, .end = TI816X_EMAC1_BASE + 0x3FFF, .flags = IORESOURCE_MEM, }, { .start = TI816X_IRQ_MACRXTHR0, .end = TI816X_IRQ_MACRXTHR0, .flags = IORESOURCE_IRQ, }, { .start = TI816X_IRQ_MACRXINT0, .end = TI816X_IRQ_MACRXINT0, .flags = IORESOURCE_IRQ, }, { .start = TI816X_IRQ_MACTXINT0, .end = TI816X_IRQ_MACTXINT0, .flags = IORESOURCE_IRQ, }, { .start = TI816X_IRQ_MACMISC0, .end = TI816X_IRQ_MACMISC0, .flags = IORESOURCE_IRQ, }, }; Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vpd 0 18 марта, 2013 Опубликовано 18 марта, 2013 (изменено) · Жалоба 1) а какая версия ядра? 2) А точно у AM3892 и TI816X все адреса и ресурсы совпадают? Изменено 18 марта, 2013 пользователем Hoodwin Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
an.skornyakov 0 18 марта, 2013 Опубликовано 18 марта, 2013 (изменено) · Жалоба 1) а какая версия ядра? 2.6.37 2) А точно у AM3892 и TI816X все адреса и ресурсы совпадают? Ну прям так утверждать не могу, конечно, но электронщик заявляет, что да. Судя по их хедеру и моему даташиту, что касается конкретно прерываний EMAC, то да, совпадают. #define TI816X_IRQ_MACRXTHR0 40 #define TI816X_IRQ_MACRXINT0 41 #define TI816X_IRQ_MACTXINT0 42 #define TI816X_IRQ_MACMISC0 43 #define TI816X_IRQ_MACRXTHR1 44 #define TI816X_IRQ_MACRXINT1 45 #define TI816X_IRQ_MACTXINT1 46 #define TI816X_IRQ_MACMISC1 47 У меня обработчик прерываний emac_irq() только с прерыванием MACTXINT0 вызывается (receive pending interrupt). Изменено 18 марта, 2013 пользователем vardik Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vpd 0 18 марта, 2013 Опубликовано 18 марта, 2013 · Жалоба Можно попробовать установить LOOP в MacControl и посмотреть, увидит ли он сам себя? Ощущение такое, что он просто не видит, что сеть доступна, пакеты в очередь встают, а в сетку их никто не отправляет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
an.skornyakov 0 18 марта, 2013 Опубликовано 18 марта, 2013 · Жалоба Можно попробовать установить LOOP в MacControl и посмотреть, увидит ли он сам себя? Ощущение такое, что он просто не видит, что сеть доступна, пакеты в очередь встают, а в сетку их никто не отправляет. Хорошая идея, я правильно понимаю, что для того, чтобы включить режим LOOPBACK сначала надо GMIIEN бит снять? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vpd 0 18 марта, 2013 Опубликовано 18 марта, 2013 · Жалоба Ну вроде да, так пишут в доке. Вполне возможно что там аппаратно стоит блокировка изменения бита loopback при включенном GMIIEN. Да, еще хочу сказать, что у меня сетка поднялась без таких проблем, но были другие. А именно: там не был правильно настроен вызов сброса кэша, поэтому некотрые пакеты бились. Проявлялось это по-разному. В U-Boot это вообще долго чудило и пинг глючил. А в самом линуксе периодически грохались пакеты и не удавалось получить 100% трафика в локальной сети. Но, возможно, проявления зависят от размеров и конфигурации кэша, так что попробуйте проверить, честно ли он сбрасывается перед отправкой данных. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
an.skornyakov 0 18 марта, 2013 Опубликовано 18 марта, 2013 · Жалоба Ну вроде да, так пишут в доке. Вполне возможно что там аппаратно стоит блокировка изменения бита loopback при включенном GMIIEN. Да, еще хочу сказать, что у меня сетка поднялась без таких проблем, но были другие. А именно: там не был правильно настроен вызов сброса кэша, поэтому некотрые пакеты бились. Проявлялось это по-разному. В U-Boot это вообще долго чудило и пинг глючил. А в самом линуксе периодически грохались пакеты и не удавалось получить 100% трафика в локальной сети. Но, возможно, проявления зависят от размеров и конфигурации кэша, так что попробуйте проверить, честно ли он сбрасывается перед отправкой данных. Ну вроде получилось loopback выставить, по прежнему ничего не работает, и временами выдает предупреждение с дампом и бектрейсом. На всякий случай я его полностью приведу, вдруг еще чего в глаза бросится. Мне непонятно почему глазки на физике не горят, хотя линк вроде как есть. net eth0: EMAC Basic registers net eth0: EMAC: EmuControl:00000000, FifoControl: 00020018 net eth0: EMAC: MBPEnable:00002020, RXUnicastSet: 00000001, RXMaxLen=000005F2 net eth0: EMAC: MacControl:00000203, MacStatus: 00000000, MacConfig=18440203 net eth0: EMAC Statistics net eth0: EMAC: rx_good_frames:0 net eth0: EMAC: rx_broadcast_frames:0 net eth0: EMAC: rx_multicast_frames:0 net eth0: EMAC: rx_pause_frames:0 net eth0: EMAC: rx_crcerrors:0 net eth0: EMAC: rx_align_code_errors:0 net eth0: EMAC: rx_oversized_frames:0 net eth0: EMAC: rx_jabber_frames:0 net eth0: EMAC: rx_undersized_frames:0 net eth0: EMAC: rx_fragments:0 net eth0: EMAC: rx_filtered_frames:0 net eth0: EMAC: rx_qos_filtered_frames:0 net eth0: EMAC: rx_octets:0 net eth0: EMAC: tx_goodframes:0 net eth0: EMAC: tx_bcastframes:0 net eth0: EMAC: tx_mcastframes:0 net eth0: EMAC: tx_pause_frames:0 net eth0: EMAC: tx_deferred_frames:0 net eth0: EMAC: tx_collision_frames:0 net eth0: EMAC: tx_single_coll_frames:0 net eth0: EMAC: tx_mult_coll_frames:0 net eth0: EMAC: tx_excessive_collisions:0 net eth0: EMAC: tx_late_collisions:0 net eth0: EMAC: tx_underrun:0 net eth0: EMAC: tx_carrier_sense_errors:0 net eth0: EMAC: tx_octets:0 net eth0: EMAC: net_octets:0 net eth0: EMAC: rx_sof_overruns:0 net eth0: EMAC: rx_mof_overruns:0 net eth0: EMAC: rx_dma_overruns:0 net eth0: CPDMA: state: active net eth0: CPDMA: txidver: 4ec0020e net eth0: CPDMA: txcontrol: 1 net eth0: CPDMA: txteardown: 0 net eth0: CPDMA: rxidver: 0 net eth0: CPDMA: rxcontrol: 1 net eth0: CPDMA: softreset: 0 net eth0: CPDMA: rxteardown: 0 net eth0: CPDMA: txintstatraw: 0 net eth0: CPDMA: txintstatmasked: 0 net eth0: CPDMA: txintmaskset: 1 net eth0: CPDMA: txintmaskclear: 1 net eth0: CPDMA: macinvector: 0 net eth0: CPDMA: maceoivector: 2 net eth0: CPDMA: rxintstatraw: fe00 net eth0: CPDMA: rxintstatmasked: 0 net eth0: CPDMA: rxintmaskset: 1 net eth0: CPDMA: rxintmaskclear: 1 net eth0: CPDMA: dmaintstatraw: 0 net eth0: CPDMA: dmaintstatmasked: 0 net eth0: CPDMA: dmaintmaskset: 2 net eth0: CPDMA: dmaintmaskclear: 2 net eth0: CPDMA: dmacontrol: 0 net eth0: CPDMA: dmastatus: 0 net eth0: CPDMA: rxbuffofs: 0 net eth0: channel 0 (tx 0) state active net eth0: hdp: 4a103000 net eth0: cp: 4a103080 net eth0: stats head_enqueue: 14 net eth0: stats tail_enqueue: 1143 net eth0: stats pad_enqueue: 0 net eth0: stats misqueued: 0 net eth0: stats desc_alloc_fail: 9 net eth0: stats pad_alloc_fail: 0 net eth0: stats runt_receive_buff: 0 net eth0: stats runt_transmit_buff: 1009 net eth0: stats empty_dequeue: 5 net eth0: stats busy_dequeue: 8 net eth0: stats good_dequeue: 5 net eth0: stats requeue: 0 net eth0: stats teardown_dequeue: 1024 net eth0: channel 32 (rx 0) state active net eth0: hdp: 4a102000 net eth0: cp: 3fa053fa net eth0: rxfree: 80 net eth0: stats head_enqueue: 1 net eth0: stats tail_enqueue: 127 net eth0: stats pad_enqueue: 0 net eth0: stats misqueued: 0 net eth0: stats desc_alloc_fail: 0 net eth0: stats pad_alloc_fail: 0 net eth0: stats runt_receive_buff: 0 net eth0: stats runt_transmit_buff: 0 net eth0: stats empty_dequeue: 0 net eth0: stats busy_dequeue: 0 net eth0: stats good_dequeue: 0 net eth0: stats requeue: 0 net eth0: stats teardown_dequeue: 0 ------------[ cut here ]------------ WARNING: at drivers/net/davinci_cpdma.c:890 cpdma_chan_stop+0xbc/0x164() Modules linked in: ipv6 Backtrace: [<c0049bb8>] (dump_backtrace+0x0/0x110) from [<c0385ea8>] (dump_stack+0x18/0x1c) r7:00000000 r6:c024a380 r5:c046c6bf r4:0000037a [<c0385e90>] (dump_stack+0x0/0x1c) from [<c006c6cc>] (warn_slowpath_common+0x54/0x6c) [<c006c678>] (warn_slowpath_common+0x0/0x6c) from [<c006c708>] (warn_slowpath_null+0x24/0x2c) r9:c051abcc r8:c051afcc r7:c04b4000 r6:c052db04 r5:d6764480 r4:d675ea80 [<c006c6e4>] (warn_slowpath_null+0x0/0x2c) from [<c024a380>] (cpdma_chan_stop+0xbc/0x164) [<c024a2c4>] (cpdma_chan_stop+0x0/0x164) from [<c02492b0>] (emac_dev_tx_timeout+0x50/0x68) r5:d6563340 r4:d6563000 [<c0249260>] (emac_dev_tx_timeout+0x0/0x68) from [<c031a0ac>] (dev_watchdog+0x164/0x234) r5:00000000 r4:d6563000 [<c0319f48>] (dev_watchdog+0x0/0x234) from [<c0076f9c>] (run_timer_softirq+0x148/0x1e4) r6:c0319f48 r5:00000100 r4:c051a1c0 [<c0076e54>] (run_timer_softirq+0x0/0x1e4) from [<c007183c>] (__do_softirq+0x80/0x108) [<c00717bc>] (__do_softirq+0x0/0x108) from [<c007190c>] (irq_exit+0x48/0x94) [<c00718c4>] (irq_exit+0x0/0x94) from [<c003b080>] (asm_do_IRQ+0x80/0xa0) [<c003b000>] (asm_do_IRQ+0x0/0xa0) from [<c0387ef4>] (__irq_svc+0x34/0xa0) Exception stack(0xc04b5f48 to 0xc04b5f90) 5f40: 81600281 40000013 c04b5f90 00000814 c04b4000 c04f8f00 5f60: c002e2c0 c04b8074 80000000 413fc082 0000001f c04b5f9c c04b5f90 c04b5f90 5f80: c0046f8c c0046f90 80000013 ffffffff r5:fa200000 r4:ffffffff [<c0046f44>] (default_idle+0x0/0x54) from [<c0047534>] (cpu_idle+0x50/0x90) [<c00474e4>] (cpu_idle+0x0/0x90) from [<c0381244>] (rest_init+0x60/0x78) r5:c04f8f00 r4:c051d13c [<c03811e4>] (rest_init+0x0/0x78) from [<c0008cc4>] (start_kernel+0x270/0x2c8) [<c0008a54>] (start_kernel+0x0/0x2c8) from [<80008048>] (0x80008048) ---[ end trace 57992c7a3c2d3abb ]--- Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vpd 0 18 марта, 2013 Опубликовано 18 марта, 2013 · Жалоба А схема-то своя или это EVM? Еще как вариант нужно проверить: 1) PINMUX регистры. Действительно ли у вас там все настроена именно на ваш вариант схемы (MII, RMII, GMII, RGMII, SGMII, etc) 2) что подана тактовая на EMAC. Конкретно сигналы TXCLK и RXCLK, либо MTCLK и MRCLK, в соответствии с 6.2 из sprugx7. судя по дампу, оно в очередь пакет в DMA поставило, а DMA трансфер завис, после чего его срубил dev_watchdog, проще говоря, таймаут. Который мог быть по одной из двух причин. либо он не види прерываний от DMA, либо сам автомат DMA не клочится со стороны EMAC, и поэтому данные не выкачиваются. В обоих случаях кончится дело таймаутом. Ну а линк он сам по себе живет, он же за несущей смотрит в сети, ему все равно, чем там EMAC дышит. Как вариант, глазки у него не горят по той же причине, что они тактируются со стороны EMAC, а там клока нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
an.skornyakov 0 18 марта, 2013 Опубликовано 18 марта, 2013 · Жалоба А схема-то своя или это EVM? Своя, что касается EMAC'a, ethernet и т д - отличия небольшие: - другая PHY, 100 Mbps (на EVM гигабитная стоит) - 4 пина Rx и 4 пина Tx, висят в воздухе у нас, так как на 100 mbps они не используются - пин GMTCLK не подключен, тоже потому что физика 100 mbps судя по дампу, оно в очередь пакет в DMA поставило, а DMA трансфер завис, после чего его срубил dev_watchdog, проще говоря, таймаут. Который мог быть по одной из двух причин. либо он не види прерываний от DMA, либо сам автомат DMA не клочится со стороны EMAC, и поэтому данные не выкачиваются. В обоих случаях кончится дело таймаутом. Ну а линк он сам по себе живет, он же за несущей смотрит в сети, ему все равно, чем там EMAC дышит. Как вариант, глазки у него не горят по той же причине, что они тактируются со стороны EMAC, а там клока нет. Да, электронщик говорит, что клоки изначально есть и глазки горят, но потом, во время загрузки клоки пропадают и одновременно с этим гаснут глазки (возможно пропадают уже при загрузке u-boot'a). Очень, очень похоже, на то, что вы пишете. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vpd 0 18 марта, 2013 Опубликовано 18 марта, 2013 · Жалоба А вы своему PHY часом back-to-back режим не включили? Он в этом режиме начинает слушать и перестает выдавать клок. Сие рулится тремя входами CONFIG, либо управляется битом 7 в регистре 0x16 PHY. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
an.skornyakov 0 18 марта, 2013 Опубликовано 18 марта, 2013 (изменено) · Жалоба А вы своему PHY часом back-to-back режим не включили? Он в этом режиме начинает слушать и перестает выдавать клок. Сие рулится тремя входами CONFIG, либо управляется битом 7 в регистре 0x16 PHY. Да, мы смотрели насчет back-to-back, CONFIG подтянуты к 0 все, а регистр надо посмотреть будет. Мы начали копать насчет клоков и получилась интересная картинка. У нас сейчас на устройстве две физики запаяны одинаковые, на MDIO 0:01 и 0:02, первая на emac0 заведена, 2ая на emac1. 1) Включаемся без проца генерация отличная на обоих PHY, 25 МГц (100 mbps) 2) Включаемся с процессором, но не грузимся на первой физике сбивается генерация, там порядка 1.5 МГц на осциллографе на второй физике все нормально Разбираемся, что сбивает генерацию на первой физике. Изменено 18 марта, 2013 пользователем vardik Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
an.skornyakov 0 19 марта, 2013 Опубликовано 19 марта, 2013 · Жалоба Получилось достучаться до второй PHY, которая на втором EMAC, подняли eth1, пингует, пингуется вроде все хорошо. На первой физике хоть убей срыв генерации идет, если проц втыкаем, даже без SD-карточки ( с которой грузимся ). Не можем пока понять в чем дело, электронщик волосы рвет, постарел лет на 5 сразу. Выглядит плохо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vpd 0 19 марта, 2013 Опубликовано 19 марта, 2013 (изменено) · Жалоба У вас там клоки через резисторы (т.н. serial trmination) подключены? Если да, то можете попробовать один резистор скинуть и подключить туда нормальный клок со второй физики. Но без схемы вряд ли смогу что-то более внятное Вам посоветовать. Из общего только попробовать взять другой образец, чтобы исключить дефекты сборки. Ну и питание проверить для порядка прямо на выводах PHY. Изменено 19 марта, 2013 пользователем Hoodwin Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
an.skornyakov 0 19 марта, 2013 Опубликовано 19 марта, 2013 · Жалоба У вас там клоки через резисторы (т.н. serial trmination) подключены? Если да, то можете попробовать один резистор скинуть и подключить туда нормальный клок со второй физики. Но без схемы вряд ли смогу что-то более внятное Вам посоветовать. Из общего только попробовать взять другой образец, чтобы исключить дефекты сборки. Ну и питание проверить для порядка прямо на выводах PHY. Да в любом случае большое спасибо за помощь, со многим получилось разобраться, либо подтвердить наши догадки/соображения. Мы сравнили регистры на обоих физиках и есть небольшие различия.. Регистр Рабочая физика Нерабочая физика 0x16 0x201 0x230 0x17 0x5e01 0x3E10 Получилось что на рабочей физике (16 регистр) включен бит "Override strap-in for MII mode", а на нерабочей физике вместо него стоит бит "Override strap-in for NAND Tree mode". А в 17 регистре стоят соотвественно разные статусы strap-in. Может это быть причиной нашей проблемы? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vpd 0 19 марта, 2013 Опубликовано 19 марта, 2013 · Жалоба А у Вас там часом пин 21 - INTRP/NAND_Tree# в момент сброса PHY в нуле не пребывает? Такое ощущение, что вы его в состояние теста ножек перевели. Не может быть, что у вас это сигнал с чем-то еще соединен, вроде GPIO и на момент сброса это что-то в нуле? Еще странно, что бит 4 в даташите моем обозначен как reserved, а он установлен у вас в нерабочем PHY. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться