Перейти к содержанию
    

Fenolftalein

Участник
  • Постов

    66
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Fenolftalein

  • Звание
    Участник
    Участник
  1. Причина оказалась не в драйвере. В dtb были неверно заданы ranges для pcie. После исправления все заработало.
  2. Смотрели со стороны платы на Xlinx, при чтении BAR на Xlinx тишина. Такая мысль тоже была. u-boot видит PCI bridge и X520. Я не могу проверить, может ли u-boot читать BAR.
  3. pci a000:00:00.0 это не X520, а PCI bridge. # lspci -tv -+-[a000:00]---00.0-[01]--+-00.0 Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection | \-00.1 Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection \-[0000:00]- Подключал другое устройство, PCIe плата от Xlinx. Та же история, BAR читается на x86 но не читается на PowerPC
  4. PowerPC выступает в роли PCI-E RC, на кастомной плате разведен слот для PCI, куда вставлена карта X520. По хорошему (на x86 с установленной X520) драйвер читает значения не равные 0xffffffff. Например, первые регистры BAR0 X520 на x86 [ 1743.634529] bar 0x0000 : 0x00000000 [ 1743.634531] bar 0x0004 : 0x00000000 [ 1743.634532] bar 0x0008 : 0x00080000 [ 1743.634533] bar 0x000c : 0xdeadbeef [ 1743.634534] bar 0x0010 : 0xdeadbeef [ 1743.634536] bar 0x0014 : 0xdeadbeef [ 1743.634537] bar 0x0018 : 0x00010000 [ 1743.634538] bar 0x001c : 0xdeadbeef То что драйвер не работает именно на плате PowerPC указывает, что проблема не в нем. Поскольку конфиг хедер X520 читается без проблем, я исключаю аппаратные косяки в плате. Значит проблема или в linux/dtb, или в u-boot. При загрузке в логе есть сообщения вида (a000:00:00.0 - RC) [ 4608.157545] pci a000:00:00.0: PCI bridge to [bus 01-ff] [ 4608.162894] pci a000:00:00.0: BAR 0: assigned [mem 0xc0000000-0xc00fffff] [ 4608.169711] ====================__find_resource: 650=============== [ 4608.176082] pci a000:00:00.0: BAR 8: no space for [mem size 0x20000000] [ 4608.182700] pci a000:00:00.0: BAR 8: failed to assign [mem size 0x20000000] [ 4608.189674] pci a000:00:00.0: BAR 9: assigned [mem 0xc0100000-0xc02fffff 64bit pref] [ 4608.197414] ====================__find_resource: 650=============== [ 4608.203764] pci a000:00:00.0: BAR 7: no space for [io size 0x10000] [ 4608.210127] pci a000:00:00.0: BAR 7: failed to assign [io size 0x10000] Что может быть причиной таких сообщений? Может ли это влиять на чтение BAR ов устройств, подключенных к RC?
  5. PCI driver не читает BAR

    Доброго времени суток. Разбираюсь с написанием PCI драйвера для PCIe EP устройства на Linux для PowerPC (P2020 процессор, кастомная плата). Для эксперимента использую сетевую плату Intel X520. Конфигурационные регистры читаются/записываются без проблем, но чтение BAR всегда возвращает 0xffffffff. Для эксперимента скомпилировал мой драйвер под x86_64 Arch Linux. BAR читается без проблем, значит дело не в моем драйвере. Сравнивая выводы lcpi -vvv для Arch и для Embedded Linux я заметил, что в Embedded для PCI bridge не назначен Interrup pin (конфигурационный регистр 0x3D = 0x00) С чем связана невозможность чтения BAR на кастомной плате PowerPC? 1 Может быть причина в отсутствии interrupt pin для pcibridge в embedded linux? 2 Разная разрядность? Область BAR 64 разрядная. Мой драйвер нормально читает BAR на 64 разрядной Arch, но не может прочитать на 32 разрядной Embedded Linux lspci -vvv для PCI bridge на Embedded linux # lspci -s a000:00:00.0 -vv a000:00:00.0 PCI bridge: Freescale Semiconductor Inc P2020 (rev 21) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin ? routed to IRQ 24 Region 0: Memory at <ignored> (32-bit, non-prefetchable) [size=1M] Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00000000-00000fff Memory behind bridge: c0000000-dfffffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME- Capabilities: [4c] Express (v1) Root Port (Slot-), MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0 ExtTag- RBE- DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x4, ASPM L0s, Exit Latency L0s <2us, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID 0000, PMEStatus- PMEPending- Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Kernel driver in use: pcieport Добавил исходный код драйвера, dmesg загрузки/выгрузки драйвера, полный вывод lspci -vvv. Ремаппинг для BAR0 происходит в probe, чтение из BAR0 в sol_write(). Карта X520 имеет два номера функции, драйвер ремапит и читает bar в a000:01:00.1 powerPC.txt lspci.txt sol_driver.txt
  6. Разобрался. Макрос configUSE_TRACE_FACILYTI нужно устанавливать только при трассировке с записью в буфер, при этом надо выделить память под буфер и задать на него указатель. Другая проблема, в некоторые отладочные макросы, к примеру traceTASK_CREATE(pxTask), передается указатель на структуру блока управления задачей tskTaskControlBlock. Как из этого указателя вытащить данные о задаче (к примеру, имя задачи, приоритет)? Для этого указатель надо привести к типу tskTaskControlBlock, но поскольку определение структуры находиться в с-файле, компилятор не видит его в файле, где я переопределяю трассировочные макросы. Возможные варианты решения: 1. Определить смещение нужных полей от начала структуры 2. Определить свою структуру, с полями идентичными полям структуры tskTaskControlBlock и приводить указатель к указателю на нее. Оба решения негибки и не очевидны. Наверное, авторы предусмотрели более простое решение. Хотелось бы знать, какое? P.S. Непонятно, зачем потребовалось размещать определение структуры tskTaskControlBlock в с-файле. Или это такая защита от случайного доступа к полям структуры?
  7. Доброго времени суток. При попытке скомпилировать проект, с использованием трассировочных макросов (установка configUSE_TRACE_FACILYTI в 1 в "FreeRTOSConfig.h") компилятор выдает ошибку "type mismatch in assigment" на строчку /* Write the details of all TCB's in pxList into buffer. */ listGET_OWNER_OF_NEXT_ENTRY( pxFirstTCB, pxList); в файле "tasks.c" При установке configUSE_TRACE_FACILYTI в 0 все компилируется нормально. Версия FreeRTOS 7.2.0 Компилятор C18
  8. Написал коррелятор на 8-битном сдвиговом регистре. Вход тактовая частота, сигнал. Выход : значение корреляционной функции (5 бит, старший знак) + 0-й бит сдвигового регистра, для возможного расширения. Опорная последовательнось подается на параллельный вход. Среда ise WebPack, ПЛИС xc95288. Результаты: Macrocells : 84 terms : 971 Register : 8 Functional Block 284 То есть я ошибся в предположении, что схема будет жадной до регистров, функциональные блоки закончаться раньше. Я испоьзовал в большинстве блоков параллельные операторы. В связи с этим вопрос по VHDL. Можно ли сэкономить функциональные блоки, за счет использования последовательных опреаторов, вместо параллельных?
  9. Нет, гораздо меньше. Последовательность несинхронизирована, и это главная проблема. Синхронизация по методу зачетного отрезка, как было замечено выше, ухудшаеться помехоустойчивость. Метод последовательной обработки, как предложил bogaev_roman, тоже приходил в голову, но стоит ли огород городить? Метод сдвигового регистра простой быстрый , а метод циклической обработки сложный, более критичен по времени. Похоже, подберу ПЛИС для варианта со сдвиговым регистром.
  10. Требуется детектор двоичной псевдослучайной последовательности. На вход поседовательность и тактовый сигнал. Два выхода: корреляция ("1" - положительная корреляция, "0" - отрицательная корреляция), и выход обнаружения сигнала ("1" - есть сигнал, "0" - нет сигнала). Видел схему на сдвиговом регистре, разрядностью равной длина ПСП, но эта схема жадная на триггеры (для последовательности 127 бит нужно 127 триггеров). Есть другие варианты, схем и (желательно) описание на VHDL?
  11. Просто, что бы было понятно. Проблема исчезла после того как более внимательно выставил биты конфигурации. Как они влияли на скважность ШИМ так и не понял.
  12. ГКЧ на ШИМ 18f452

    Доброго времени суток. Нужно сделать ГКЧ от 50 до 150кГц на 18f452. Использую ШИМ. Пересчитываю частоту в период, и соответственно изменяю время заполнения, что бы при любом периоде скважность была 50%. На частотах близких к 50кГц скважность 50%. С ростом частоты скважность почему-то увеличивается (примерно 80% на 150кГц), что для ГКЧ не есть хорошо. В моделях MPLAB и Proteus скважность выдерживается. Инициализация ШИМ unsigned int imp; PR2 = (char)(1000/((float)f*0.2) + 0.5) - 1;//4Tosc = 0.2мкс, предделитель не используется, f - частота в кГц imp = 2*PR2 + 2; // длительность импульса 1/2 периода (CCPR1L:CCP1CON<5:4>) = 2[(PR2) + 1] CCPR1L = (imp >> 2) & 0xFF; // старшие 8 бит CCP1CONbits.DC1B0 = imp & 0x01; CCP1CONbits.DC1B1 = (imp >> 1) & 0x01; // младшии 2 бита
  13. Доброго времени суток. Для счетчика Гейгера требуется питание 400в. Требуется получить их от 3-х элементов тип AAA. Старый вариант использовал блокинг генератор, но для его питания нужно минимум 6 Вольт.
×
×
  • Создать...