

карамболь
Участник*-
Posts
272 -
Joined
-
Last visited
Content Type
Profiles
Forums
Calendar
Everything posted by карамболь
-
Программист в драйвере выделит кусок памяти в ДДР и вернет вам ее физический адрес. Как то так
-
вы уверены, что правильный Fsbl засунули в Boot.bin ?
-
может, в DTB выключен ?
-
ZC706 и Vivado 2020.1
карамболь replied to attaboy's topic in Системы на ПЛИС - System on a Programmable Chip (SoPC)
типа такого gem0: [email protected] { compatible = "cdns,gem"; reg = <0xe000b000 0x1000>; status = "disabled"; interrupt-parent = <&gic>; interrupts = <0 22 4>; clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>; clock-names = "pclk", "hclk", "tx_clk"; #address-cells = <1>; #size-cells = <0>; phy-handle = <ðernet_phy>; phy-mode = "rgmii-id"; ethernet_phy: [email protected]{ reg = <7>; }; }; тут больше https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841740/Macb+Driver -
ZC706 и Vivado 2020.1
карамболь replied to attaboy's topic in Системы на ПЛИС - System on a Programmable Chip (SoPC)
в DTB обычно -
Уже реализовал все в ПЛИС. Получилось быстрее и надежнее
-
Спасибо ! Т.е. только для одного интерфейса GEM активизировать галочку MDIO ?
-
есть, но там 2-й GEM через PL (EMIO) роутится. Во всяком, случае, что нашел пока. На форуме у кислых нашел топик с таким решением по DTB &gem0 { status = "okay"; local-mac-address = [00 0a 35 00 00 00]; phy-handle = <ðernet_phy0>; ethernet_phy0: [email protected] { reg = <0>; }; ethernet_phy1: [email protected]{ reg = <1>; }; }; &gem1 { status = "okay"; local-mac-address = [00 0a 35 00 00 01]; phy-handle = <ðernet_phy1>; }; И вроде бы, у коллеги это сработало. Вот я и хотел убедиться, так ли это... Я правильно понимаю, что при такой реализации, подключать в Vivado MDI нужно только для для GEM0 ? Меня немного смущает, что два разных интерфейса юзают одни и те же пины MDIO.
-
Никто не подключал больше одного Gem ?
-
Поправка для MDIO можно выбрать MIO 50-51, но они уже используются для SD карты
-
Здравствуйте. Появилась необходимость использовать два GEM, причем, будут использованы разные микросхемы PHY. Ковыряясь в Vivado обнаружил, что несмотря на возможность выбора 4-х GEM, сигналы MDC всегда MIO76 и MIO76. Насколько я понял в DTB это должно выглядеть так mdio { compatible = "cdns,macb-mdio"; reg = <0x0 0xff0b0000 0x0 0x1000>; clocks = <&clk125>, <&clk125>, <&clk125>; clock-names = "pclk", "hclk", "tx_clk"; ethernet_phya: [email protected] { reg = <0xA>; }; ethernet_phyb: [email protected] { reg = <0xB>; }; }; Gem1: [email protected] { .... phy-handle = <& ethernet_phya>; } Gem3: [email protected] { .... phy-handle = <& ethernet_phyb>; } Так ли это ? Может был у кого такой опыт ?
-
да устраивает в принципе. Лень все переписывать ) И хочется понять, неужели 1 КГц это слишком быстро для гигигерцового двухядерного проца ?
-
Здравствуйте. Ситуация следующая. Есть система на SOC, 2 ядра + FPGA, частота ядра 1 ГГц. На ПЛИС реализован модуль, который принимает из UART пакеты, частота пакетов 1 КГц, размер 50 байт. После приема пакета модуль формирует прерывание. В драйвере реализован девайс, который при открытии засыпает и ждет соответствующего прерывания. После возникновения прерывания системный вызов open возвращает дескриптор. Код в пространстве пользователя открывает устройство, потом читает необходимое кол-во байт и закрывает устройство. Проблема в том, что периодически пакеты теряются. Реально принимается с секунду около 900 пакетов из 1000 ожидаемых. Оказалось, что время от времени открытие девайса занимает более 2, а то и 4 мсек, соответственно за это время драйвер успевает принять несколько пакетов. В драйвере все четко, строго каждую мсек приходит пакет и копируется в буфер. Проблема именно в связке между девайсом и кодом в пространстве пользователя. Пытался вставлять wait_event_interruptible в функцию read, чтобы не один раз получить дескриптор, но это ничего не изменило. Понимаю, что можно буферизировать пакеты в драйвере и читать сразу несколько. Но мне важно привязать каждый пакет к таймштампу в юзерспейсе Что еще можно предпринять ?
-
UltraScale+ Linux reboot
карамболь replied to карамболь's topic in Системы на ПЛИС - System on a Programmable Chip (SoPC)
да, все аналогично -
UltraScale+ Linux reboot
карамболь replied to карамболь's topic in Системы на ПЛИС - System on a Programmable Chip (SoPC)
да вроде все, как на оригинально плате -
UltraScale+ Linux reboot
карамболь replied to карамболь's topic in Системы на ПЛИС - System on a Programmable Chip (SoPC)
Дело в том, что наша плата полный клон платы TRENZ TE0808 и на трензовской плате с клоками никаких проблем нет если загрузиться с той же самой SD карты. Еще вопрос к вам по поводу сброса. Может ли быть связано с ошибками в разводке то, что проц зависает при запуске reboot из Линукса или это чисто программная проблема ? -
UltraScale+ Linux reboot
карамболь replied to карамболь's topic in Системы на ПЛИС - System on a Programmable Chip (SoPC)
FSBL пишет, что про таймаут, потом ошибку по клоку. Настроен через I2C PLL. Если грузить BOOT.bin в котором FSBL хочет видеть 3 клока, то ошибки тоже 3. В текущей прошивке использую только 150 МГц для SATA и ошибка тоже одна -
UltraScale+ Linux reboot
карамболь replied to карамболь's topic in Системы на ПЛИС - System on a Programmable Chip (SoPC)
кстати, в убуте сброс работает. Не понимаю, почему в прошлый раз не отработал, возможно, был включен Jtag программатор, но это не точно. А в Линуксе не работает. На отладочной плате та же самая сборка с SD карты - работает сброс и в убуте, и в Линуксе. Чудеса... Еще на кастомной плате не лочится ФАПЧ на 505-м банке PS, хотя клоки присутствуют -
UltraScale+ Linux reboot
карамболь replied to карамболь's topic in Системы на ПЛИС - System on a Programmable Chip (SoPC)
Действительно, не влияет... Воткнул SD карту в отладочную плату и там Reset в U-Boot работает. Похоже, что проблема имеет физическую природу. Каким образом программный сброс может быть связан с внешней обвязкой ? -
UltraScale+ Linux reboot
карамболь replied to карамболь's topic in Системы на ПЛИС - System on a Programmable Chip (SoPC)
А что влияет ? Почему даже reset в U-boot не работает ? -
UltraScale+ Linux reboot
карамболь replied to карамболь's topic in Системы на ПЛИС - System on a Programmable Chip (SoPC)
Сейчас покопался и обнаружил, что не включил SWDT0 и SWDT1 в настройках Mpsoc. Подозреваю, что тут собака и порылась -
UltraScale+ Linux reboot
карамболь replied to карамболь's topic in Системы на ПЛИС - System on a Programmable Chip (SoPC)
в u-boot тоже не работает -
Здравствуйте, коллеги. Наконец изготовили собственные платы на основе UltraScale+. Перенес аккуратно весь необходимый софт с учетом изменений. В принципе, в основном всё работает. Т.е. связка FSBL-PMUFW-U-BOOT-Linux. Грузится с SD карты и с qspi. Но вылезла такая проблема, что не отрабатывает команда reboot в Линуксе. [ OK ] Reached target Unmount All Filesystems. [ OK ] Stopped target Local File Systems (Pre). [ OK ] Stopped Create Static Device Nodes in /dev. [ OK ] Stopped Create System Users. [ OK ] Stopped Remount Root and Kernel File Systems. [ OK ] Reached target Shutdown. [ OK ] Reached target Final Step. [ OK ] Started Reboot. [ OK ] Reached target Reboot. На последней строчке зависает и всё... Куда копать ? Спасибо
-
Hello_SoC.files = /path/Hello_SoC Hello_SoC.path = /home INSTALLS += Hello_SoC Ну и смотрите - Проекты-> Запуск чего там в "установка файлов", "программа на машине", "программа на устройстве"