Bear_ku 0 17 января, 2020 Опубликовано 17 января, 2020 · Жалоба 1 hour ago, Jury093 said: вопрос к сигналу reset_n от lan78 к 1512, по докам от LAN минимум прописан 1мкс, а что там по факту? т.к. у 1512 д.б. не менее 10мс, у марвелла с этим строго.. Сброс 2мс. Спасибо, попробую проверить сейчас этот вариант. 40 minutes ago, sasamy said: Еще номиналы подтяжек на MDIO проверить - неизвестно что там реально запаяно. Соответствуют ДШ, 2.2 кОм. Когда экспериментировал, пробовал менять номиналы подтяжек и добавлял их еще на MDC, ничего не дало. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jury093 2 17 января, 2020 Опубликовано 17 января, 2020 · Жалоба 46 минут назад, sasamy сказал: Если больше ничего в схеме не перепутано это по-моему единственное логическое объяснение. Можно попробовать разорвать линию RESETn, еше попробовать вручную сделать длитеьный сброс - вставить задержку на пару секунд перед вызовом phydev = phy_find_first(dev->mdiobus); и кратковременно проводком замкнуть на землю RESETn. Еще номиналы подтяжек на MDIO проверить - неизвестно что там реально запаяно. угу, при текущих симптомах отсекаем последовательно - питание, частота, тайминги ну и для phy я в marvell_phy.h прописал #define MARVELL_PHY_ID_88E1512 0x01410dd1 и поковырялся в marvell.c Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gosha-z 1 17 января, 2020 Опубликовано 17 января, 2020 · Жалоба Драйвер Marvell PHY в ядре 4.19 точно имеет правильные PHY ID's - проверено "на себе". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Bear_ku 0 17 января, 2020 Опубликовано 17 января, 2020 · Жалоба Драйвер должен быть рабочим. Коллега на работе уже имел с ним дело, но он подключался напрямую к FPGA Xilinx. Т.е. его опыт мне не помог ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Bear_ku 0 17 января, 2020 Опубликовано 17 января, 2020 · Жалоба По поводу сброса. Сигнал сброса PHY_RESET_N LAN7801 как уже выше написал висит 2 мс, хотя в ДШ сказано минимум 4 мс. По простому это время увеличить не удалось (хотел периодически устанавливать флаг сброса). Соединил сигналы сброса RESET_N у микросхем MAC и PHY с кнопкой сброса, результат не изменился. Или MAC обязательно должен сам сбросить PHY? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jury093 2 17 января, 2020 Опубликовано 17 января, 2020 · Жалоба 3 часа назад, Bear_ku сказал: По поводу сброса. Сигнал сброса PHY_RESET_N LAN7801 как уже выше написал висит 2 мс, хотя в ДШ сказано минимум 4 мс. По простому это время увеличить не удалось (хотел периодически устанавливать флаг сброса). Соединил сигналы сброса RESET_N у микросхем MAC и PHY с кнопкой сброса, результат не изменился. Или MAC обязательно должен сам сбросить PHY? для паранойи - у вас контакт 46 (lan7801) - test висит в воздухе, что достаточно криминально, из доки: Test pin. This pin is used for internal purposes only and must be connected to ground for proper operation. на схеме кита https://www.microchip.com/Developmenttools/ProductDetails/EVB-KSZ9897-1 он пулдауном на 10kOhm придавлен на gnd.. и еще, я полистал драйвер, там есть: /* define external phy id */ #define PHY_LAN8835 (0x0007C130) #define PHY_KSZ9031RNX (0x00221620) что немного настораживает о способности lan7801 работать нормально с другими phy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Bear_ku 0 21 января, 2020 Опубликовано 21 января, 2020 · Жалоба Всем спасибо. Проблема была все-таки в тактовой частоте. На выходе LAN7801 она появлялась только после поиска имеющихся PHY, соответственно ничего найти и не получалось. После исправления данного явления нужные дрова для PHY подтянулись без каких-либо дополнительных манипуляций. Осталось разобраться как осуществляется переключение с меди на оптику. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jury093 2 21 января, 2020 Опубликовано 21 января, 2020 · Жалоба 35 минут назад, Bear_ku сказал: Осталось разобраться как осуществляется переключение с меди на оптику. за давностью лет не помню, что там крутить, но при наличие документации всё вполне заработало Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Bear_ku 0 30 января, 2020 Опубликовано 30 января, 2020 · Жалоба В целом все работает, но далеко не так как задумано. IP адрес и маска заданы вручную и не меняются. При включении сеть определяется, пинги идут. Достаточно достать/вставить кабель и работа останавливается. На пинг того же ПК получаю "From 192.168.1.104 icmp_seq=1 Destination Host Unreachable". Ниже результат команд после данной манипуляции. $ ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.104 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::b9:96ff:feab:6d88 prefixlen 64 scopeid 0x20<link> ether 02:b9:96:ab:6d:88 txqueuelen 1000 (Ethernet) RX packets 45 bytes 3746 (3.6 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 53 bytes 5778 (5.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 $ ethtool eth0 Settings for eth0: Supported ports: [ TP MII FIBRE ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Cannot get wake-on-lan settings: Operation not permitted Current message level: 0x00000007 (7) drv probe link Link detected: yes В то же время если убрать связь по MDIO между PHY/MAC работает все криво и косо, зато манипуляция с проводом не приводит к таким последствиям. Может подскажете куда копать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 11 30 января, 2020 Опубликовано 30 января, 2020 (изменено) · Жалоба 2 hours ago, Bear_ku said: Достаточно достать/вставить кабель и работа останавливается. Так у вас судя по схеме не подключена линия запроса на прерывание от PHY к MAC - подключите и должно работать. Со встроенными MAC проще - там поллинг включается если явно не указана в DT линия IRQ, с USB MAC такое не прокатит скорей всего - драйвер MAC всегда регистрирует прерывание и ожидает его от PHY, хотя я не уверен https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/lan78xx.c#n2974 посмотрите что пишет ядро когда интерфейс поднимается, например тут поллинг Quote SMSC LAN8710/LAN8720 30be0000.ethernet-1:00: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL) и есть ли в логах отклик от драйвера при отключении/включении кабеля наподобие этого Quote fec 30be0000.ethernet eth0: Link is Down fec 30be0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx Изменено 30 января, 2020 пользователем sasamy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Bear_ku 0 30 января, 2020 Опубликовано 30 января, 2020 · Жалоба При отключенных прерываниях ситуация отличается, но результат в итоге тот же. Все что написано в посте выше проделывалось при подключенных прерываниях. При отключении/включении кабеля никаких новых сообщений в dmesg не появляется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jury093 2 30 января, 2020 Опубликовано 30 января, 2020 · Жалоба 12 минут назад, Bear_ku сказал: При отключенных прерываниях ситуация отличается, но результат в итоге тот же. Все что написано в посте выше проделывалось при подключенных прерываниях. При отключении/включении кабеля никаких новых сообщений в dmesg не появляется. как я понимаю, у вас проблемы при оптическом соединение? посмотрите бит 10 в Page 1 Register 16 - для Normal Operation он д.б. 0, если там 1, то это блокирует анализ линка и он всегда "link up" и статусный бит 10, Page 1 Register 17 - он отображает в real time статус линка линк должен падать при пропадание сигнала на RX и при переключение среды передачи вроде надо программный ресет делать phy через регистр Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Bear_ku 0 30 января, 2020 Опубликовано 30 января, 2020 · Жалоба Оптика вообще печаль. На данный момент она вообще не пашет. Ее проверяю коммутатором, у которого загораются светодиодики при нормальном подключении, в моем случае - нет. При включении/отключении кабеля смотрел шину MDIO, там байтики бегают. Пока правда корректность не проверял их. У меня в силу отсутствия опыта общения с линуксом и сетевыми соединениями вообще волосы дыбом встают от происходящего. Скорее всего все решается в пару движений, но вот совершить их я не могу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jury093 2 30 января, 2020 Опубликовано 30 января, 2020 · Жалоба В 21.01.2020 в 12:23, Bear_ku сказал: нужные дрова для PHY подтянулись без каких-либо дополнительных манипуляций. вот тут туманно - чьи драйвера в результате прибиндились в качестве phy? по идее, это где-то тут решается - static struct phy_device *lan7801_phy_init(struct lan78xx_net *dev) дело в том, что для marvell при работе с медью или оптикой в драйвере переключаются обращения к разным страницам, это можно посмотреть к похожим phy в marvell.c для работы внешнего прерывания в 1512 надо разрешить его работу page 3 register 18 бит 7, а там по дефолту 0 а как справедливо посоветовал sasamy надо смотреть в логе ядра режим работы "poll или interrupt" для отладки надо включить в ядре вывод отладочной информации и отладку сети, и смотреть в логах, что происходит ну и проследить движуху статусного бита link_on в драйвере lan78xx.c, потрассировать функцию phy_read_status - куда лазит и что вычитывает из phy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Bear_ku 0 30 января, 2020 Опубликовано 30 января, 2020 · Жалоба Дрова marvell, смена страниц в протоколе обмена присутствует (наблюдал вживую), прерывания в PHY инициализируются и работают (после срабатывания прерывания идет общение mac-phy по mdio). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться