Jump to content

    

Bear_ku

Участник
  • Content Count

    182
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Bear_ku

  • Rank
    Частый гость

Recent Profile Visitors

2556 profile views
  1. Простите, погорячился. Ответ крылся в файле: arch/arm/mach-bcm2708.c
  2. Пытаюсь заставить работать mini Uart на ядре линукса 3.18. Написал простой модуль для передачи байт, проверил на ядре 5.хх - работает. А вот на ядре 3.18 работать не хочет, нет перехода в обработчик прерываний. В исходниках нашел номер прерывания для UART, но это PL011 UART. Как узнать для miniUart?
  3. Столкнулся с той же проблемой . На ПК порт открывался и принимались данные если в МК использовалась только функция CDC_Transmit_FS. Как только добавлял свои обработчики в CDC_TransmitCplt_FS или CDC_Receive_FS то порт на ПК не открывался "Error in OpenPort: Internal Error when initializing COM3". Решение проблемы нашел тут: https://stackoverflow.com/questions/40597612/stm32-usb-vcp-virtual-com-port. А точнее: // usbd_cdc_if.c static int8_t CDC_Control_FS(uint8_t cmd, uint8_t* pbuf, uint16_t length) { static uint8_t tempbuf[7]; /* USER CODE BEGIN 5 */ switch(cmd) { // ... case CDC_SET_LINE_CODING: memcpy(tempbuf, pbuf, sizeof(tempbuf) / sizeof(tempbuf[0])); break; case CDC_GET_LINE_CODING: memcpy(pbuf, tempbuf, sizeof(tempbuf) / sizeof(tempbuf[0])); break; // ... } return (USBD_OK); /* USER CODE END 5 */ } Windows 10 Mcu: STM32F405RGTx. Firmware: STM32Cube FW_F4 V1.25.1
  4. MAC + PHY

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

    Оптика вообще печаль. На данный момент она вообще не пашет. Ее проверяю коммутатором, у которого загораются светодиодики при нормальном подключении, в моем случае - нет. При включении/отключении кабеля смотрел шину MDIO, там байтики бегают. Пока правда корректность не проверял их. У меня в силу отсутствия опыта общения с линуксом и сетевыми соединениями вообще волосы дыбом встают от происходящего. Скорее всего все решается в пару движений, но вот совершить их я не могу.
  6. MAC + PHY

    При отключенных прерываниях ситуация отличается, но результат в итоге тот же. Все что написано в посте выше проделывалось при подключенных прерываниях. При отключении/включении кабеля никаких новых сообщений в dmesg не появляется.
  7. MAC + PHY

    В целом все работает, но далеко не так как задумано. 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 работает все криво и косо, зато манипуляция с проводом не приводит к таким последствиям. Может подскажете куда копать?
  8. MAC + PHY

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

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

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

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

    Делал. Никакого отличия. Но в случае модуля я знаю как посмотреть его загрузку, а вот если включить в ядро - нет )
  13. MAC + PHY

    Драйвера на MAC смотрел, но сильно глубоко не копался. Как раз исходя из них и сделал вывод, что надо где-то указать используемый PHY. С включением питания надо разбираться отдельно, но при перезагрузке дело доходит до сообщения: ... phydev = phy_find_first(dev->mdiobus); if (!phydev) { ... } else { if (!phydev->drv) { netdev_err(dev->net, "no PHY driver found\n"); return NULL; } } Т.е. сам МАС "найден", а вот драйверы для него - нет. При этом в структурах сидят следующие значения: phydev->phy_id = 0 phydev->mdio->addr = 0 Значение в phy_id на сколько я понимаю должно соответствовать 88E1512, что явно далеко до истины. Вот разводка данной части, сигналы MDIO и MDC снизу, отдельно выделены. Слои TOP - зеленый, BOTTOM - желтый, GND - внутренний слой земли. Единственное что сигналы изначально на схеме были перепутаны и их пришлось перекинуть проводами, но тут не те скорости чтобы это на что-то повлияло. Подтяжка к питанию осталась на MDIO. Ресет проверю. А вот usb 3.1 тут по факту не используется, т.к. USB HUB 2.0. Или все равно это может на что-то повлиять?
  14. MAC + PHY

    Не разбираясь в вопросе, сложно собрать сразу всю необходимую информацию. PHY вообще не грузится, просто понимает это драйвер LAN7981 только после перезагрузки и тогда сетевое соединение уже не появляется в системе. При сборке ядра были добавлены модули: Deivice Drivers ---> Network device support ---> PHY Device support and Infrastructure ---> <M> Marvell PHYs USB Network Adapters ---> <M> Microchip LAN78XX Based USB Ethernet Adapters Вот модуль драйвера marvell на загруженной системе: pi@raspberrypi:/lib/modules/4.19.71-rt24-v7+/kernel/drivers/net/phy$ ls marvell.ko mdio-bitbang.ko Список загруженных системой модулей одинаковый при включении и перезагрузке: Module Size Used by sha256_generic 20480 0 cfg80211 626688 0 rfkill 28672 2 cfg80211 8021q 32768 0 garp 16384 1 8021q stp 16384 1 garp llc 16384 2 garp,stp lan78xx 49152 0 bcm2835_codec 36864 0 snd_bcm2835 24576 1 bcm2835_v4l2 45056 0 v4l2_mem2mem 24576 1 bcm2835_codec bcm2835_mmal_vchiq 32768 2 bcm2835_codec,bcm2835_v4l2 raspberrypi_hwmon 16384 0 v4l2_common 16384 1 bcm2835_v4l2 hwmon 16384 1 raspberrypi_hwmon videobuf2_dma_contig 20480 1 bcm2835_codec snd_pcm 98304 1 snd_bcm2835 videobuf2_vmalloc 16384 1 bcm2835_v4l2 videobuf2_memops 16384 2 videobuf2_dma_contig,videobuf2_vmalloc videobuf2_v4l2 24576 3 bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem videobuf2_common 45056 4 bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem,videobuf 2_v4l2 snd_timer 32768 1 snd_pcm snd 69632 5 snd_timer,snd_bcm2835,snd_pcm videodev 184320 6 bcm2835_codec,v4l2_common,videobuf2_common,bcm28 35_v4l2,v4l2_mem2mem,videobuf2_v4l2 media 36864 3 bcm2835_codec,videodev,v4l2_mem2mem vc_sm_cma 36864 1 bcm2835_mmal_vchiq uio_pdrv_genirq 16384 0 uio 20480 1 uio_pdrv_genirq fixed 16384 0 ip_tables 24576 0 x_tables 32768 1 ip_tables ipv6 454656 22 Т.е. видно что драйвер marvell даже и не думал грузиться. По крайней мере мне сказали что если модуль был загружен, то вряд ли его кто-то выгружал. Про питание уже писал, оно соответствует ДШ. Тактирование в норме. По отдельности обе микросхемы работают. Про MDIO уже выше писал, сигнал с LAN7981 идет, а вот ответа от PHY нет, по крайней в том запросе что ловится осциллографом. При этом если подключиться к этой шине (к выводам RPi), то регистры с PHY считываются без проблем. В схеме ничего секретного нет ( IM_61850.pdf ). Задавая тут вопрос, не думал что кто-то реально полезет со всем этим разбираться, просто надеялся на имеющийся опыт. А как может повлиять на MDIO разводка, вообще не представляю. Вырезки из логов выкладывал, вроде в dmesg ничего больше дела не касалось, но можно приложить и всю портянку. И о каких настройках идет речь? В системе все по умолчанию на данный момент, первое что начал делать это device tree, изменения в котором выложил выше.
  15. MAC + PHY

    Сейчас у меня к базовой плате подключено два одинаковых модуля. На одном адрес PHY "0", на другом "1". После включения (на пойманном осциллографе сообщении адрес 0, загрузились eth0 и eth1): [ 3.162884] usb 1-1.1: New USB device found, idVendor=0424, idProduct=7801, bcdDevice= 3.00 [ 3.177790] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 3.266887] usb 1-1.2: new high-speed USB device number 4 using dwc_otg [ 3.365955] usb 1-1.2: New USB device found, idVendor=0424, idProduct=7801, bcdDevice= 3.00 [ 3.380600] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 ... [ 10.741131] libphy: lan78xx-mdiobus: probed [ 10.741223] lan78xx 1-1.1:1.0 (unnamed net_device) (uninitialized): int urb period 64 [ 10.967083] libphy: lan78xx-mdiobus: probed [ 10.967241] lan78xx 1-1.2:1.0 (unnamed net_device) (uninitialized): int urb period 64 [ 10.998643] usbcore: registered new interface driver lan78xx При перезагрузке (на пойманном осциллографе сообщении адрес 1, загрузился только один eth0): [ 3.170826] usb 1-1.1: New USB device found, idVendor=0424, idProduct=7801, bcdDevice= 3.00 [ 3.185233] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 3.211023] systemd[1]: System time before build time, advancing clock. [ 3.273810] usb 1-1.2: new high-speed USB device number 4 using dwc_otg [ 3.372948] usb 1-1.2: New USB device found, idVendor=0424, idProduct=7801, bcdDevice= 3.00 ... [ 9.754045] libphy: lan78xx-mdiobus: probed [ 9.754149] lan78xx 1-1.1:1.0 (unnamed net_device) (uninitialized): int urb period 64 [ 10.007435] libphy: lan78xx-mdiobus: probed [ 10.007467] lan78xx 1-1.2:1.0 (unnamed net_device) (uninitialized): int urb period 64 [ 10.015888] lan78xx 1-1.2:1.0 eth1: no PHY driver found [ 10.015902] lan78xx 1-1.2:1.0 eth1: lan7801: PHY Init Failed [ 10.055475] lan78xx: probe of 1-1.2:1.0 failed with error -5 [ 10.055645] usbcore: registered new interface driver lan78xx Согласен, адрес PHY не меняется. Меняется адрес в сообщении, он задается программно и PHY к нему отношение имеет только косвенное, т.е. может ответить на свой и молчать на чужой.