Marvell 88E6165, помогите разобраться Опции

[kamil_yaminov]

Имеется плата собственной разработки с Marvell 88e6165 на борту и stm32, который осуществляет управление свичом по MDIO. Возникли проблемы с включением устройства.

Постараюсь описать как устроен девайс и какого рода проблемы возникли.

Процессор управляет питаниями и сбросом 88e6165. Подача питания и сброса следующим образом:
По включении платы подается питание VDDO 2.5В на свич, после этого процессор включает аналоговое питание AVDD 1.8В и последним питание ядра VDDO_CORE 1В. Когда все питания включены формируется сброс длительностью 100мс (надо не менее 10мс, а я так, чтобы наверняка).

Есть один момент с питаниями. В даташите на 88e6165 оговорено, что если VDDO_CORE превысит AVDD более чем на 0.5В, то «damage will be result», аналогичное сказано про AVDD и VDDO. Из-за того, что я допустил некоторые огрехи в схеме, при первых включениях AVDD и VDDO_CORE подавались как придется. В общем, огрехи исправлены, сейчас все питания формируются как надо. Собственно не очень понятно, насколько это важно, и действительно ли может привести к каким-то неисправностям. Сейчас будет собираться второе устройство, где последовательность включения напряжений будет изначально правильной.

Далее, есть функционирующий MDIO, по которому идет обмен, читаются и пишутся внутренние регистры свича. Свич сконфигурирован в single-chip addressing mode.

Следующим шагом после того как был поднят MDIO, стало включение PHY. Здесь нареканий нет: auto-negotiation проходит, скорости, дуплексы устанавливаются правильные. Включение line loopback показало, что пакеты исходящие с хоста, заворачиваются обратно. Также посмотрел при помощи wireshark, что приходят все пакеты, сгенерированные генератором пакетов, встроенным в PHY.

Далее включив для начала PHY на двух портах, переключил PortState для этих двух портов в Forwarding. Ingress и Egress policies не трогал, они вроде бы по умолчанию ничего не должны блокировать. Также проверил, что Port Based VLAN Map и Port Association Vector в правильных значениях (т. е. В первом выставлены все биты, кроме бита данного порта, во втором наоборот).

Когда в порт прилетают пакеты, счетчики (MAC Based) меняются, более того, в ATU появляются записи, с соответствующими MAC-адресами и векторами портов. Но при этом пакеты не уходят далее, как положено, в порты назначения.

Дальнейшее разбирательство показало несколько фактов:
Допустим, заходят пакеты в порт 0, которые должны далее перенаправлены в порт 1. При этом количество задействованных выходных буферов порта 1 увеличивается по мере поступления пакетов. Также возникает egress watchdog event. Я сначала предположил, что возможно egress policies неправильно настроены и пакеты наружу не проходят, однако, при этом должны меняться Policy Based счетчик порта, чего не происходит — значение счетчика всегда нулевое. MAC Based счетчики исходящих данного порта тоже нулевые. Однако стоит, допустим, сделать soft-reset для PHY данного порта, MAC Based счетчики исходящих увеличиваются ровно на размер одного пакета, входящего в порт 0 и предназначенного выйти в порт 1. В общем у меня подозрение, что проблема где-то на стыке MAC и PHY.

В какой-то момент вспомнил, что у свича есть тестовый режим. Попробовал его запустить в тестовом режиме, однако ничего нового не произошло. Подозреваю, что в тестовом режиме просто включаются все PHY и состояния всех портов устанавливается в Forwarding.

Самому пока разобраться не получается, поэтому прошу помощи, тех кто работал с данным кристаллом. Остается ждать, когда будет спаяна следующая плата и надеяться, что проблема не в недокументированных особенностях свича.