Bear_ku

У меня Uart0, тот что PL011, работает на 2Мбит/с. Для этого в config.txt прописал строки #Uart0 and Uart1 force_turbo=0 core_freq=240 init_uart_clock=128000000 Но периодически при включении скорость работы порта отличается от требуемой. Есть подозрение что не верно устанавливается тактовая частота. Сталкивался кто-нибудь с подобной проблемой? Куда смотреть?

Прошу прощения. Использую STM32CubeIDE, может не последней версии но довольно свежую.

high_resolution_clock::now() ожил после написания своей _gettimeofday. Это корректный подход?

Как вариант подойдет. Но на сколько я знаю данная проблема решается реализацией одной из системных функций. Вот только проблема в том, что не могу вспомнить какой.

Как работает данная функция я имею представление. А вот что нужно сделать чтобы она заработала в STM?

При попытке использования сторонней библиотеки наткнулся на препятствие в виде chrono, а точнее high_resolution_clock::now(). Данная функция похоже всегда возвращает одно и то же значение, т.к. duration_cast<microseconds> всегда выдает 0. Подскажите, плз, как заставить ее работать?

Простите, погорячился. Ответ крылся в файле: arch/arm/mach-bcm2708.c

Пытаюсь заставить работать mini Uart на ядре линукса 3.18. Написал простой модуль для передачи байт, проверил на ядре 5.хх - работает. А вот на ядре 3.18 работать не хочет, нет перехода в обработчик прерываний. В исходниках нашел номер прерывания для UART, но это PL011 UART. Как узнать для miniUart?

Столкнулся с той же проблемой . На ПК порт открывался и принимались данные если в МК использовалась только функция 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

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

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

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

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

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

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

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

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

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

Драйвера на 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. Или все равно это может на что-то повлиять?

Не разбираясь в вопросе, сложно собрать сразу всю необходимую информацию. 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, изменения в котором выложил выше.

Сейчас у меня к базовой плате подключено два одинаковых модуля. На одном адрес 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 к нему отношение имеет только косвенное, т.е. может ответить на свой и молчать на чужой.

Тут реально ошибка. Исправил на 7801, изменений нет. С отладочными сообщениями у меня проблема. Вроде бы и включил их в .config, размер библиотек вырос раза в 3. Но в dmesg новой информации, по крайней мере касательно интересующей темы, не появилось. Если подскажете как правильно сделать и куда смотреть, буду благодарен. По поводу осциллограмм написал выше. Обращение к PHY есть, но ответа нет, по крайней мере в том сообщении что я вижу. При этом адрес устройства в этом сообщении меняется, при включении "0", при перезагрузке "1". Но в обоих случаях PHY ничего не отвечает. Когда PHY проверял отдельно, он вел себя адекватно. Вот цитата из документации: Required properties: - compatible: Should be one of "usb424,7800", "usb424,7801" or "usb424,7850". Честно говоря не понял к чему это относится. Адрес выставляет LAN7801 и это программная часть, на PHY он задан подтяжкой к соответствующему уровню.

Настройку 88E1512 брал отсюда: https://forums.xilinx.com/t5/Embedded-Linux/Dual-Marvell-88e1512-PHY-Ethernet-problem-Xilinx-LInux/m-p/731207#M17356 Там используются два варианта настроек для "compatible": compatible = "marvell,88e1510"; и compatible = "marvell"; Оба варианта не дали никакого результата. Я выше добавил пример из документации, там делается так. Не знаю как по другому указать, что MDIO от PHY подключен именно к LAN7801 и как еще задать адрес. В ходе загрузки получается что модуль с драйвером marvell не грузится. На шине MDIO адрес при включении платы "0", после перезагрузки "1". Вообщем живет своей жизнью. Осциллографом успеваю поймать только одно обращение по шине. Вскоре приедет логический анализатор и может он хоть что-то даст. Ну и как написал выше, МАС адрес из Devicetree на сетевое устройство не подключается. Т.е. там может ерунда написана, но может его еще кто-то правит.

А что именно вас тут смущает? И может подскажете как посмотреть, что реально из этого загружается? Вот пример из Devicetree на lan78xx &usb { usb-port@1 { compatible = "usb424,2514"; reg = <1>; #address-cells = <1>; #size-cells = <0>; usb-port@1 { compatible = "usb424,2514"; reg = <1>; #address-cells = <1>; #size-cells = <0>; ethernet: ethernet@1 { compatible = "usb424,7800"; reg = <1>; local-mac-address = [ 00 11 22 33 44 55 ]; mdio { #address-cells = <0x1>; #size-cells = <0x0>; eth_phy: ethernet-phy@1 { reg = <1>; microchip,led-modes = < LAN78XX_LINK_1000_ACTIVITY LAN78XX_LINK_10_100_ACTIVITY >; }; }; }; }; }; };

Плату делал другой человек. Я сейчас перепроверяю за ним, каких-либо критических ошибок не нашел. VDDO_SEL подтянут к земле, т.е. выбраны уровни 2.5-3.3В, что соответствует уровням на плате 3.3В. CONFIG на одной плате подключил к земле, на другой к питанию, т.е. адреса PHY 0 и 1. Оба не грузятся. PHY_RESET_N c LAN7801 подключен напрямую к RESETn 88E1512. Ориентируясь на Device Tree от Raspberry Pi 3 добавил свой кусок: /dts-v1/; /plugin/; /{ compatible = "brcm,bcm2837"; fragment@0 { target = <&usb>; __overlay__ { usb2512b@1 { compatible = "microchip,usb2512b"; reg = <0x2c>; #address-cells = < 0x01 >; #size-cells = < 0x00 >; ethernet1: usbether@1 { compatible = "usb424,7800"; reg = <1>; local-mac-address = [ 00 11 22 33 44 55 ]; mdio { #address-cells = <0x1>; #size-cells = <0x0>; eth_phy1: ethernet-phy@1 { compatible = "marvell,88e1510"; device_type = "ethernet-phy"; reg = <0>; }; }; }; ethernet2: usbether@2 { compatible = "usb424,7800"; reg = <1>; local-mac-address = [ 00 10 20 30 40 50 ]; mdio { #address-cells = <0x1>; #size-cells = <0x0>; eth_phy2: ethernet-phy@2 { compatible = "marvell,88e1510"; device_type = "ethernet-phy"; reg = <0>; }; }; }; }; }; }; }; Но изменений нет, даже МАС адреса не изменяются. Все таки надеюсь что разгадка кроется где-то тут ) Дальше уже полезу кромсать плату и заводить MDIO на ноги RPi, минуя USB-MAC.