[gosha-z 2]

Коллеги, прошу помощи сообщества.

Дано: кастомная плата на ZC7030, FFG676 корпус, наружу выведены оба ENET через MIO в режиме RGMII, подключены к Marvell 88E1512.
Когда я получил эту плату, в нем была уже зашита не совсем свежая версия U-Boot, которая исправно грузит образы как с SDcard,так и с сети по tftp. А вот с Linux - полная засада:

1. Xilinx'овский fork ядра 4.14.0 не стартует вообще, после Starting kernel - тишина.
2. Ядра 4.19.12 и 4.20.0, собранные на том же конфиге, стартуют, но ENETы не появляются ни в логе загрузки ни в ifconfig -a
  При этом есть небольшая разница в конфигурации mdio:
 a) Если mdio расположена в корне, то phy не детектятся вообше:

libphy: Fixed MDIO Bus: probed
CAN device driver interface
libphy: MACB_mii_bus: probedlibphy: MACB_mii_bus: probed

 

 b) Если mdio расположена как Child от GEM0 (как оно и есть по сути с точки зрения схемы), то имеем такую картину:

 

libphy: Fixed MDIO Bus: probed
CAN device driver interface
libphy: MACB_mii_bus: probed
mdio_bus e000b000.ethernet-ffffffff: mdio has invalid PHY address
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 0
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 1
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 2
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 3
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 4
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 5
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 6
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 7
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 8
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 9
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 10
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 11
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 12
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 13
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 14
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 15
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 16
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 17
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 18
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 19
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 20
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 21
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 22
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 23
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 24
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 25
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 26
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 27
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 28
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 29
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 30
mdio_bus e000b000.ethernet-ffffffff: scan phy mdio at address 31
e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
e1000e: Copyright(c) 1999 - 2015 Intel Corporation.

GEMы не появляются в обоих случаях. Нагуглил все, что только можно по этой проблеме, но решения так и нет. Если кто натыкался на подобное - подскажите, куда копать?
 

[Jury093 2]

4 минуты назад, gosha-z сказал:

Коллеги, прошу помощи сообщества.

Дано: кастомная плата на ZC7030, FFG676 корпус, наружу выведены оба ENET через MIO в режиме RGMII, подключены к Marvell 88E1512.
Когда я получил эту плату, в нем была уже зашита не совсем свежая версия U-Boot, которая исправно грузит образы как с SDcard,так и с сети по tftp. А вот с Linux - полная засада:

1. Xilinx'овский fork ядра 4.14.0 не стартует вообще, после Starting kernel - тишина.
2. Ядра 4.19.12 и 4.20.0, собранные на том же конфиге, стартуют, но ENETы не появляются ни в логе загрузки ни в ifconfig -a
  При этом есть небольшая разница в конфигурации mdio:
 a) Если mdio расположена в корне, то phy не детектятся вообше:

 b) Если mdio расположена как Child от GEM0 (как оно и есть по сути с точки зрения схемы), то имеем такую картину:

GEMы не появляются в обоих случаях. Нагуглил все, что только можно по этой проблеме, но решения так и нет. Если кто натыкался на подобное - подскажите, куда копать?
 

для случая Б потыкайте осциллом в сигналы mdc/mdio на момент загрузки ядра и детектирования phy

- если сигналов нет - ищите где ошиблись в написание конфигурации шины mdio

- если сигналы есть, то проверяйте "отпущен ли reset на phy" и приходит ли тактовая на phy

если доступны исходники "несвежего u-boot", то ищите ключевые отличия..

[gosha-z 2]

Клок на phy совсем внешний, так что считаем, что он рабочий, ибо по tftp образ читается без проблем. Насчет ресета у меня была мысль, но вроде как ресет там поднятый (в смысле неактивный), надо в момент опроса phy посмотреть.

[gosha-z 2]

Отвечу сам себе: оказалась работоспособной следующая конструкция:

gem0 {
   phy-handle = <&phy0>;
   phy0: ethernet-phy@0 {
     reg=<0>;
   };
   phy1: ethernet-phy@1 {
     reg = <1>;
   };
};
gem1 {
   phy-handle = <&phy1>;
};

 

[svedach 0]

Добрый день. Столкнулся с проблемой: 88E1512 на 100МБит (принудительно задал) стартует всегда в half-duplex, при этом регистр №4 (Copper Auto-Negotiation Advertisement Register) выставлен в 0x141, т.е. микруха не должна поддерживать 100МБит half-duplex. При этом свич (порт выставлен в автосогласование), в который воткнута сеть, показывает half-duplex (ожидаемо), и позволяет переключить сеть в full-duplex и 88E1512 соединяется и функционирует нормально в full-duplex (что не ожидаемо)...

Периодически проверял регистр "Copper Auto-Negotiation Advertisement Register", записанное значение сохраняется, т.е. 0x141.

По ощущениям скорости передачи данных half-duplex реально есть, при переключении свича в full-duplex скорость обмена ощутимо возрастает.

Может кто сталкивался? Может еще какие регистры надо записать или еще что сделать?

(спрашивал в ветке про интерфейсы - там молчат...)