ZYNQ Ethernet через EMIO, Проблема: пакеты не попадают в PS из PL Опции

[Gothard]

Всем доброго времени суток!

Пытаюсь пробросить один из Ethernet интерфейсов Zynq через PL(EMIO) на PHY (88E1512). Т.е. PHY подключен к плисовой части Zynqа, необходимо чтобы он был доступен через MAC процессорной части.

Добился некоторого успеха - PHY управляется по MIIM, пакеты выдаются в сеть через PHY (на текущий момент только ARP...). Пакеты из сети в плисовую часть попадают, но такое ощущение, что в процессорную не попадают или где-то прибиваются.
Наблюдаю чипскопом сигналы, которые подключены к RX процессорной части - все ок, пакеты есть, содержимое совпадает с тем, что вижу в WireShark, вот только что CRC пока не проверял.
Еще немного подробностей - линк гигабитный, уже дошел до того, что пересинхронизую пакеты от PHY на внутренние 125 МГц, сформированные в плисе, те же, что используются и для выдачи TX - ситуация не меняется.

Видимо не хватает какой-то магии.

Плис грузится из FSBL, проверяю из U-Bootа пингами.
Проект плиса в Vivado 2014.2
FSBL собирался из SDK 2013.3 по данным из Vivado (может тут нестыковочка?... но рабочий FSBL в 2014.2 у меня так и не собрался пока)
Интерфейс с PHY - RGMII, используется блок, проверенный в других проектах.

Буду очень благодарен за советы. Спасибо!

p.s. на сигнал RX_ERR в GMII интерфейсе процессорной подается 0, но я так понимаю что с этим все должно быть ОК
p.s.2: пытался в Block Design подключить IP_CORE "GMII_to_RGMII" от LogiCore к Zynq_Processing_System, он вроде бы как раз для этих целей, но Vivado выдает ошибку при генерации обертки для Block Design, поэтому не удалось проверить в такой конфигурации.
p.s.3: на этой же плате есть второй PHY, который напрямую подключен к Zynq. Так вот с ним все замечательно работает. Ожидал, что в проекте Vivado переключу тот же самый MAC с внешнего PHY на EMIO, и будет достаточно только пересобрать FSBL, не меняя U-Boot (ну и плисовую часть собрать соответственно). Видимо не все так просто...

[dm.pogrebnoy]

По теме ничего сказать могу пока, но уже страшно. У меня плата сейчас скоро подоспеет с двумя такими контроллерами висящими на логике.

[Gothard]

Проверяю регистры процессорной части.
Судя по дампу регистров MAC в него не приходило ни байта , что в общем не удивительно.

Из документации не нашел через какой регистр определяется к чему подключен MAC - к MIO или EMIO
В TRM есть пол странички по настройке GMII через EMIO - в этой полстраничке описана настройка LevelShifters и Software reset.

Настройка LevelShifterов вроде бы выполнена, судя по значениям регистра. Единственное не очень мне понятный момент - в качестве Software reset там дергается FPGA_RST (то, что выводится из PS в PL в качестве пинов FCLK_RSTN[..]). Есть подозрение, что это необходимо только для корки LogiCore GMII-to-RGMII. Пока не знаю, выполняет ли это действие FSBL и насколько это критично, буду искать дальше...

P.S.:
Нашел, что slcr.GEM0_RCLK_CTRL выбирает не только источник синхросигнала RX, но и заодно управления и данных (тем же самым битом)... и настроен он правильно (0x11).
slcr.GEM0_CLK_CTRL настроен на прием опорной частоты из EMIO, не понял только через что она туда заходит? такой ножки вроде бы не было выведено...загадка

Попробовал включить loopback в gem0.netctrl - в результате пинги на себя самого прошли! (это из U-Boot), т.е. все остальное-то получается правильно настроено? Статистика по принятым пакетам/байтам адекватно отразилась.

Попробовал разрешить прием пакетов с неправильной преамбулой, с плохим FCS, игнорировать RX_ER, одновременный прием и передачу в полудуплексе - в общем все, что можно было сделать, чтобы пакеты так прошли, но результата - 0...

В общем теряюсь в догадках, что не так.... пошел собирать поток с loopback в плисовой части...

P.P.S:
С loopback в плисовой части не заработало Решил поменять местами ER и DV - тоже не помогло... (а вдруг Xilinx чего напутали)....
Соединения проверял по схеме после раскладки потока - все подключено куда нужно...
От безысходности пробую собрать поток в 2014.1, потом может и 2013.3 попробую...

[Gothard]

В обсчем паника отменяется

Посыпаю свою голову пеплом.... U-boot при операциях с сетевым интерфейсом производит полную его реинициализацию, и включая настройку того самого регистра sclr.GEM0_RXCLK_CTRL. При этом значение использовать MIO или EMIO определяется из board.c при вызове zynq_gem_initialize.
А board.c был на базе стандартного, который шел под Xilinx ZC702, вот он и указывал, что надо использовать MIO....А регистр sclr.GEM0_RXCLK_CTRL я проверял по началу лишь до того, как U-boot чего-то сделал с интерфейсом, и на тот момент там все было правильно (спасибо FSBL не подвел). Не ожидал от него такой подставы...

Теперь все ОК, топик видимо можно закрывать

[dm.pogrebnoy]

Приветствую. Собрали мы наконец плату.

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

Я запускаю пока стандартный пример xemacps_example_intr_dma. Пока что поменял только значение slcr.GEM0_CLK_CTRL.SRCSEL на 0x4 что бы включить такт передатчика с EMIO. После этого начали отправляться пакеты через loop в PHY, и на компьютере я его вижу если отключить закольцовку.

slcr.GEM0_RCLK_CTRL выставлен в 0x11 что вроде бы правильно, но прерывания на прием пакета не случается. Так и не понял чем дело у вас закончилось. Использую GMII2RGMII корку.