Probleme bei DD duoflex S2 Installation auf hummingboard i2ex

    Hallo,


    ich versuche schon seit Wochen eine DD duoflex S2 mit einer mini PCIe bridge auf dem hummingboard i2ex zum Laufen zu bringen.
    Das soll dann mal headless als DVB S2 Server laufen.


    Hardware:


    solidrun hummingboard i2ex
    Adapter 1/2 mini PCIe auf voll mini PCIe
    DD Octopus mini PCIe bridge mit Lattice ECP3
    DD duoflex S2 an bridge TAB1, mit 12V und 5V versorgt


    Software:



    Debian Wheezy für Cubox/Hummingboard
    von Igor Pečovnik
    Kernel 3.14.14
    Version 2.7


    Bis Igors Version 2.6 habe ich keine Installation hinbekommen, aber seit Version 2.7:


    die Installation vom media-build-experimental-dkms läuft durch! :tup

    Quote

    DKMS: install completed.


    Irgendwie wird der Treiber dvb-Treiber aber noch nicht richtig istalliert:


    # lspci

    Quote

    00:00.0 PCI bridge: Device 16c3:abcd (rev 01)
    01:00.0 Multimedia controller: Digital Devices GmbH Octopus LE DVB adapter

    # lsmod | grep -i dd

    Quote

    ddbridge 24090 0


    # lsmod | grep -i dvb

    Quote

    (nichts)


    hier sollte eigentlich der dvb-Treiber stehen :(


    # dmesg | grep "Digital Devices"

    Quote

    [ 4.702422] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH
    [ 4.702681] DDBridge driver detected: Digital Devices Octopus DVB adapter

    # lspci -vvvnn | grep -i dvb

    Quote

    01:00.0 Multimedia controller [0480]: Digital Devices GmbH Octopus LE DVB adapter [dd01:0003]

    # dmesg | grep -i dvb

    Quote

    [ 4.702681] DDBridge driver detected: Digital Devices Octopus DVB adapter
    [ 4.704563] Port 0 (TAB 1): DUAL DVB-S2

    # dmesg | grep -i ddbridge

    Quote

    [ 4.702681] DDBridge driver detected: Digital Devices Octopus DVB adapter
    [ 4.709560] DDBridge: probe of 0000:01:00.0 failed with error -1
    [ 5.069330] Modules linked in: ir_lirc_codec lirc_dev ir_mce_kbd_decoder ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder ddbridge gpio_ir_recv


    Nach einem reboot wird zwar die Hardware noch erkannt, aber es ist so, als hätte ich das media-build-experimental-dkms nie installiert. :wand


    Hat jemand eine Idee dazu? Bin für jede Hilfe dankbar!


    Gruß,
    Thomas

    Hallo rjkm,


    danke für die Antwort. Ich musste leider das ganze System neu aufsetzen, da ich den Zustand nach dem reboot nicht reproduzieren konnte.


    hier die gewünschte Info:

    Wenn ich das richtig sehe, muss ich den DMA coherent pool vergrößern. Bin noch nicht so fit mit Linux. Wo kann ich den kernel parameter ändern? Hast Du einen Vorschlag, wieviel ich den vergrößern soll?

    Es sollte helfen die uEnv.txt mit dem Eintrag coherent_pool=2M zu erweitern.

    MSI H55M-E33 |Intel Core i3 530| 4 GB RAM | TT DVB-S2 6400 | Ubuntu 12.04 | Kernel-3.5.0-28 | VDR-2.2.0 | v4l-dvb| eigene Distri.
    ProLaint: Ubuntu Server 12.04.5 auf HP ProLiant ML330 G6, Xeon E5506 2.13-GHz, 16GB ECC DDR3, Digital Devices MaxS8, Samsung 840 EVO 120GB, 4x WD Red WD30EFRX 3TB in HP P410 Raid6, Zotac GT730 1GB

    Genau genommen ist es Ralphs Treiber.


    Aber wieso sollte es ein Bug im Treiber sein, wenn der Kernel nicht genug DMA-Puffer bereitstellen kann?


    CU
    Oliver

    Quote from UFO

    Aber wieso sollte es ein Bug im Treiber sein, wenn der Kernel nicht genug DMA-Puffer bereitstellen kann?

    Coherent memory laesst sich auf ARM nicht atomic allozieren, deshalb gibt es fuer absolute Notfaelle diesen Pool. Hier werden aber Buffer beim Device-Probe gebraucht (wenn ich das richtig verstanden habe), also nicht atomic (in Interrupt-Kontext). Man sollte die Buffer also mit GFP_KERNEL anfordern, nicht GFP_ATOMIC (oder noch schlimmer __GFP_REPEAT, was auch immer das sein soll, jedenfalls sind die __GFP-Flags nicht fuer Treiber gedacht).
    Vielleicht habe ich beim fluechtigen Reinschauen in den Treiber aber auch irgendwas uebersehen...


    Gruss,
    S:oren

    Der Treiber benutzt pci_alloc_consistent. Da müßte man mal nachsehen, warum das Kernel das atomic macht.
    Wenn man DDB_ALT_DMA definiert, benutzt er aber kmalloc (+ dma_sync_ ...)
    aber nicht der uralte Treiber aus 2011, der da oben im dmesg steht.


    Consistent memory auf ARM ist sowieso eine schlechte Idee, da er von der CPU aus saulahm ist. Dehalb meine Tests mit DDB_ALT_DMA.

    Quote from rjkm

    aber nicht der uralte Treiber aus 2011, der da oben im dmesg steht.

    Heisst das, hier geht es um einem Bug mit einem sehr alten Treiber? Nicht dem aktuellen UFO-Treiber? Dann gaebe es ja primaer ein Problem mit dem dkms, nicht mit dem Treiber selber !?


    Quote from rjkm

    Consistent memory auf ARM ist sowieso eine schlechte Idee, da er von der CPU aus saulahm ist.

    Da habe ich noch nie Probleme gehabt. Ein Cache-Flush beim dma_sync ist normalerweise schlimmer. Was auch immer "normal" ist ;)
    Vielleicht funktioniert es ja auch einfach mit groesserem Pool, so knapp ist der Hauptspeicher beim Hummingboard ja nicht...


    Gruss,
    S:oren

    Laut der kastrierten dmesg-Ausgabe oben läuft die Urversion des Treibers, die im Kernel enthalten ist. Wer so etwas verwendet, soll sich bitte nicht beschweren, wenn es Probleme gibt. Support dafür gibt es von mir jedenfalls nicht. :wand


    CU
    Oliver

    pci_alloc_consistent() benutzt anscheinend das neuere dma_alloc_coherent() mit GFP_ATOMIC. Da ich das nicht atomic brauche, werde ich es auf dma_alloc_coherent() mit GFP_KERNELumstellen, damit die kleinen atomic pools bei ARM-Kernels kein Problem mehr machen.


    Bzgl. Geschwindigkeit bei coherent vs. syncing hängt das auch davon ab, ob man direkt in anderen Speicher kopiert, oder vorher noch etwas anderes damit macht.
    Wahrscheinlich hängt es auch vom ARM-Typ und dem verwendeten Cache ab.

    Hallo zusammen,


    erstmal vielen Dank für die zahlreichen Antworten.


    ich habe zunächst den coherent_pool=4M in die uEnv.txt eingefügt.
    Nach dem reboot startet das System nicht mehr und zeigt zwei Pinguine ;( .


    Das image ist von Igor Pecovnik und ich habe auf seiner Seite gepostet, ob er eine Idee dazu hat. Leider noch keine Antwort.


    Das media-build-experimental-dkms habe ich wie folgt installiert:

    Quote

    add-apt-repository ppa:yavdr/main
    cd /etc/apt/sources.list.d
    sed -i 's/wheezy/trusty/g' /etc/apt/sources.list.d/yavdr-main-wheezy.list
    cd
    apt-get update
    apt-get install media-build-experimental-dkms


    Falsche Quelle?
    Ich werde jetzt nochmal mit UFO's Anleitung ohne das dkms und einem "frischen" image einen Versuch starten. Bei den letzten Versuchen bin ich da leider auch an irgendwelchen Fehlern hängen geblieben. Habe aber eher das Gefühl, dass es mehr am image liegt.


    Gruss,
    Thomas

    Das in yavdr/main ist schon relativ alt, in yavdr/unstable-main ist ein etwas neueres, ist aber auch schon von letztem September.
    Probiere lieber erst mal den Selbstbau. Wenn es dann funktioniert und wir Zeit finden, aktualisieren wir dann auch das dkms mal wieder.


    Lars.

    Hier mal das komplette dmesg nach Installation des media-build-experimental nach UFO's Anleitung:

    Quote from rjkm

    [...]werde ich es auf dma_alloc_coherent() mit GFP_KERNELumstellen[...]

    Sehr schoen!


    Quote from rjkm

    Bzgl. Geschwindigkeit bei coherent vs. syncing hängt das auch davon ab, ob man direkt in anderen Speicher kopiert, oder vorher noch etwas anderes damit macht.
    Wahrscheinlich hängt es auch vom ARM-Typ und dem verwendeten Cache ab.

    Ja, das sehe ich genau so. memcpy auf coherent mem ist einigermaßen schnell, direkt drauf arbeiten eher nicht.


    Gruss,
    S:oren

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login