Jump to content

    

MAC + PHY

1 hour ago, Jury093 said:

вопрос к сигналу reset_n от lan78 к 1512, по докам от LAN минимум прописан 1мкс, а что там по факту? т.к. у 1512 д.б. не менее 10мс, у марвелла с этим строго..

Сброс 2мс. Спасибо, попробую проверить сейчас этот вариант.

 

40 minutes ago, sasamy said:

Еще номиналы подтяжек на MDIO проверить - неизвестно что там реально запаяно.

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

Share this post


Link to post
Share on other sites
46 минут назад, sasamy сказал:

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


phydev = phy_find_first(dev->mdiobus);


 

и кратковременно проводком замкнуть на землю RESETn.

Еще номиналы подтяжек на MDIO проверить - неизвестно что там реально запаяно.

 

угу, при текущих симптомах отсекаем последовательно - питание, частота, тайминги

ну и для phy я в marvell_phy.h прописал

#define MARVELL_PHY_ID_88E1512          0x01410dd1

и поковырялся в marvell.c

Share this post


Link to post
Share on other sites

Драйвер Marvell PHY в ядре 4.19 точно имеет правильные PHY ID's - проверено "на себе".

Share this post


Link to post
Share on other sites

Драйвер должен быть рабочим. Коллега на работе уже имел с ним дело, но он подключался напрямую к FPGA Xilinx. Т.е. его опыт мне не помог ) 

Share this post


Link to post
Share on other sites

По поводу сброса. Сигнал сброса PHY_RESET_N LAN7801 как уже выше написал висит 2 мс, хотя в ДШ сказано минимум 4 мс. По простому это время увеличить не удалось (хотел периодически устанавливать флаг сброса).

Соединил сигналы сброса RESET_N у микросхем MAC и PHY с кнопкой сброса, результат не изменился. Или MAC обязательно должен сам сбросить PHY? 

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
35 минут назад, Bear_ku сказал:

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

за давностью лет не помню, что там крутить, но при наличие документации всё вполне заработало

Share this post


Link to post
Share on other sites

В целом все работает, но далеко не так как задумано. 

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

Может подскажете куда копать?

Share this post


Link to post
Share on other sites
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

 

 

 

Edited by sasamy

Share this post


Link to post
Share on other sites

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

При отключении/включении кабеля никаких новых сообщений в dmesg не появляется.

Share this post


Link to post
Share on other sites
12 минут назад, Bear_ku сказал:

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

При отключении/включении кабеля никаких новых сообщений в dmesg не появляется.

как я понимаю, у вас проблемы при оптическом соединение?

посмотрите бит 10 в Page 1 Register 16 - для Normal Operation он д.б. 0, если там 1, то это блокирует анализ линка и он всегда "link up"

и статусный бит 10, Page 1 Register 17 - он отображает в real time статус линка

линк должен падать при пропадание сигнала на RX

и при переключение среды передачи вроде надо программный ресет делать phy через регистр

Share this post


Link to post
Share on other sites

Оптика вообще печаль. На данный момент она вообще не пашет. Ее проверяю коммутатором, у которого загораются светодиодики при нормальном подключении, в моем случае - нет.

При включении/отключении кабеля смотрел шину MDIO, там байтики бегают. Пока правда корректность не проверял их.

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

 

 

 

Share this post


Link to post
Share on other sites
В 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

Share this post


Link to post
Share on other sites

Дрова marvell, смена страниц в протоколе обмена присутствует (наблюдал вживую), прерывания в PHY инициализируются и работают (после срабатывания прерывания идет общение mac-phy по mdio).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now