Имеется плата собственной разработки с 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.

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

Дальнейшие изыскания показали, что если задать вручную 100Мбит или 10Мбит, то пакеты выходят как в соответствующий порт назначения

Если скорость порта 1000Мбит, то исходящие пакеты в такой порт не выходят, но при этом входящие беспрепятственно входят внутрь, как описано в предыдущем посте

Насколько помню у данного свича не все порты могут быть гигабитовыми и медными, то есть какие то могут быть гигабитными медными какие то оптическими. Это как примечание. Могу так же быть не прав, давно было.
Также можете попробовать поставить зеркалирование входного потока на другой порт
Сам я не работал с этим чипом, но на плате стоял поэтому кое какая информация до меня доходила...

Те порты, которые задействованы, могут быть гигабитными медными (Если верить доке, то имеется всего 6 портов, из них 5 могут быть гигабитными медными - они то как раз и задействованы, на всех из них аналогичное поведение)

Отзеркалировать поток на другой порт можно попробовать, но скорее всего это ни к чему новому не приведет, так как:
1) порты идентичные в плане базового функционала
2) все задействованные порты ведут себя одинаково, т.е. исходящие пакеты зависают где-то на стыке mac и phy, если скорость линка 1000Мбит
3) зеркалирование по сути перенаправит входящий поток на зеркальный порт, и это будет происходить внутри ядра

Есть еще у кого-то идеи? Быть может возникали похожие проблемы на похожих устройствах от марвела?

возможно общая скорость как то лимитирована
я уже к сожалению деталей не помню было больше 5 лет назад

Да, похоже, что MAC просто не видит готовности PHY к передаче.

У нас было что-то напоминающее ваш случай, только на процессоре от Фрискейла, когда пытались перевести порт из SGMII в 1000BASE-X.
Пока не нашли нужный битик в настрйке, MAC упорно чего-то ждал от битов состояния несуществующего внешнего PHY.

В общем проблема решилась.

У данного чипа среди всех питаний имеются два пина:
1) P4_AVDDS - питание SERDES порта 4
2) P5_AVDD - питание SERDES порта 5 и main clock interface

Как сказано в даташите, питание на P4_AVDDS подавать необязательно, если на 4-м порту SERDES не используется, и этот пин может быть посажен на землю для экономии энергии, а P5_AVDD должен быть запитан от 1.8В вне зависимости от того, используется SERDES на 5-м порту или нет, иначе не будет запитан main clock interface

В общем, в процессе рисования схемы, я как раз сделал все с точностью наоборот, т.е. посадил на землю P5_AVDD и подал 1.8В на P4_AVDDS. Таким образом main clock interface был не запитан, и возникали вышеописанные симптомы.

Что за main clock interface можно только гадать, так как в даташите про него ничего более не сказано )