[an.skornyakov 0]

А в 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]

1) а какая версия ядра?

2) А точно у AM3892 и TI816X все адреса и ресурсы совпадают?

Изменено 18 марта, 2013 пользователем Hoodwin

[an.skornyakov 0]

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]

Можно попробовать установить LOOP в MacControl и посмотреть, увидит ли он сам себя? Ощущение такое, что он просто не видит, что сеть доступна, пакеты в очередь встают, а в сетку их никто не отправляет.

[an.skornyakov 0]

Можно попробовать установить LOOP в MacControl и посмотреть, увидит ли он сам себя? Ощущение такое, что он просто не видит, что сеть доступна, пакеты в очередь встают, а в сетку их никто не отправляет.

 

Хорошая идея, я правильно понимаю, что для того, чтобы включить режим LOOPBACK сначала надо GMIIEN бит снять?

[vpd 0]

Ну вроде да, так пишут в доке. Вполне возможно что там аппаратно стоит блокировка изменения бита loopback при включенном GMIIEN.

 

Да, еще хочу сказать, что у меня сетка поднялась без таких проблем, но были другие. А именно: там не был правильно настроен вызов сброса кэша, поэтому некотрые пакеты бились. Проявлялось это по-разному. В U-Boot это вообще долго чудило и пинг глючил. А в самом линуксе периодически грохались пакеты и не удавалось получить 100% трафика в локальной сети. Но, возможно, проявления зависят от размеров и конфигурации кэша, так что попробуйте проверить, честно ли он сбрасывается перед отправкой данных.

[an.skornyakov 0]

Ну вроде да, так пишут в доке. Вполне возможно что там аппаратно стоит блокировка изменения бита 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]

А схема-то своя или это 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]

А схема-то своя или это 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]

А вы своему PHY часом back-to-back режим не включили? Он в этом режиме начинает слушать и перестает выдавать клок. Сие рулится тремя входами CONFIG, либо управляется битом 7 в регистре 0x16 PHY.

[an.skornyakov 0]

А вы своему 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]

Получилось достучаться до второй PHY, которая на втором EMAC, подняли eth1, пингует, пингуется вроде все хорошо.

На первой физике хоть убей срыв генерации идет, если проц втыкаем, даже без SD-карточки ( с которой грузимся ). Не можем пока понять в чем дело, электронщик волосы рвет, постарел лет на 5 сразу. Выглядит плохо.

[vpd 0]

У вас там клоки через резисторы (т.н. serial trmination) подключены? Если да, то можете попробовать один резистор скинуть и подключить туда нормальный клок со второй физики.

Но без схемы вряд ли смогу что-то более внятное Вам посоветовать. Из общего только попробовать взять другой образец, чтобы исключить дефекты сборки. Ну и питание проверить для порядка прямо на выводах PHY.

Изменено 19 марта, 2013 пользователем Hoodwin

[an.skornyakov 0]

У вас там клоки через резисторы (т.н. 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]

А у Вас там часом пин 21 - INTRP/NAND_Tree# в момент сброса PHY в нуле не пребывает? Такое ощущение, что вы его в состояние теста ножек перевели. Не может быть, что у вас это сигнал с чем-то еще соединен, вроде GPIO и на момент сброса это что-то в нуле?

Еще странно, что бит 4 в даташите моем обозначен как reserved, а он установлен у вас в нерабочем PHY.