[Frage] Treiber kompilieren - aber wie?

[df8oe]

Ich möchte einen Treiber für einen USB-Stick bauen - hier ist das Projekt:

http://sdr.osmocom.org/trac/wiki/rtl-sdr#Buildingthesoftware

Für mein Hauptsystem LMDE (Debian) war das kein Problem. Aber wie mache ich das für freetz und den mips? Viel Prozessorlast erzeugt der Treiber nicht - sollte also technisch laufen...

df8oe

 

[MaxMuster]

Sollte gehen, das mit Freetz auch zu bauen, es gibt hier ein Makefile für OpenWRT.

 

[df8oe]

Ich glaube, hier brauche ich deutlich mehr Infos...

Kompiliert wird ja nicht auf der Fritzbox selbst, sondern es wird auf meinem Debian-System crosskompiliert. Da habe ich ja auch freetz gebaut...

1) Voraussetzung ist libusb-1.0-dev und die libusb sollte auch als Library vorhanden sein. Ist sie das bei freetz? Woher bekomme ich dann die dev dazu?
2) Ich habe den Ordner mit den Quelldateien schon auf meinem Rechner und kann ihn irgendwo (wo?) ins freetz-Verzeichnis kopieren.
3) Das Makefile enthält ja auch Infos für die Prozessorarchitektur - oder nicht? Kann/muss ich das Makefile aus deinem Link noch bearbeiten?
4) das Resultat ist ein kleines Binary - eine einzige Datei brauche ich nur. Diese kann von einem x-beliebigen Ort aus gestartet werden - also kein make install nötig. Aber:
5) Der verbleibende "Zweisprung" ./configure und make muss ja durchgeführt werden - oder entfällt das ./configure, wenn das makefile schon existiert? Wenn ja:
6) Reicht bei richtig angepasstem Makefile ein make im Projektordner, in dem die Dateien für das Proggi sind?

Ich habe bislang nur "linear" kompiliert - für die Architektur, auf die der Compiler auch lief. So ein Cross-Projekt habe ich noch nie gemacht...

Gruß
df8oe

 

[sf3978]

So ein Cross-Projekt habe ich noch nie gemacht...

Hast Du das howto "How to start your first freetz package" schon gelesen?

Wenn nicht, dann siehe diesen Link: http://freetz.org/wiki/help/howtos/...t#Firststeps-Howtostartyourfirstfreetzpackage

 

[MaxMuster]

Auf die Schnelle (im freetz-Ordner):

Im "make menuconfig" Box wählen und "libusb1" (Shared libraries ---> USB & FTDI ---> libusb1)
Dazu muss der Kompetenz-Level mindestetns "Advanced" sein.

Dann ein "Freetz-Makefile" anlegen und Bauen:

mkdir make/rtl-sdr
cat << EOF > make/rtl-sdr/rtl-sdr.mk
RTL_SDR_GIT_REPOSITORY:=git://git.osmocom.org/rtl-sdr.git
$(call PKG_INIT_BIN, $(call git-get-latest-revision,$(RTL_SDR_GIT_REPOSITORY)))
$(PKG)_SITE:=git@$($(PKG)_GIT_REPOSITORY)
$(PKG)_SOURCE:=sdr-$($(PKG)_VERSION).tar.xz
$(PKG)_DIR:=$($(PKG)_SOURCE_DIR)/sdr-$($(PKG)_VERSION)

$(PKG)_DEPENDS_ON := libusb1
$(PKG)_BUILD_PREREQ += git

$(PKG)_BINARY:=$($(PKG)_DIR)/src/.libs/rtl_sdr
$(PKG)_TARGET_BINARY:=$($(PKG)_DEST_DIR)/usr/bin/$(pkg)


$(PKG)_CONFIGURE_OPTIONS += PKG_CONFIG_PATH="$(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib/pkgconfig"

$(PKG)_CONFIGURE_PRE_CMDS += autoreconf -i ;



$(PKG_SOURCE_DOWNLOAD)
$(PKG_UNPACKED)
$(PKG_CONFIGURED_CONFIGURE)

$($(PKG)_BINARY) $($(PKG)_LIBRARY): $($(PKG)_DIR)/.configured
	$(SUBMAKE) -C $(RTL_SDR_DIR) all \
		CC="$(TARGET_CC)" \
		PKG_CONFIG_PATH="$(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib/pkgconfig"


$($(PKG)_TARGET_BINARY): $($(PKG)_BINARY)
	$(INSTALL_BINARY_STRIP)
	mkdir -p $(RTL_SDR_DEST_DIR)/usr/lib
	cp -pP $(RTL_SDR_DIR)/src/.libs/rtl_* $(RTL_SDR_DEST_DIR)/usr/bin
	$(TARGET_STRIP) $(RTL_SDR_DEST_DIR)/usr/bin/*
	cp -pP $(RTL_SDR_DIR)/src/.libs/tuner*.o $(RTL_SDR_DEST_DIR)/usr/lib
	cp -pP $(RTL_SDR_DIR)/src/.libs/lib*.so* $(RTL_SDR_DEST_DIR)/usr/lib
	$(TARGET_STRIP) $(RTL_SDR_DEST_DIR)/usr/lib/*.so*


$(pkg):

$(pkg)-precompiled: $($(PKG)_TARGET_BINARY)

$(pkg)-clean:
	-$(SUBMAKE) -C $(RTL_SDR_DIR) clean

$(pkg)-uninstall:
	$(RM) $(RTL_SDR_TARGET_BINARY)

$(PKG_FINISH)

EOF

make rtl-sdr-precompiled

Das baut es zumindest bei mir. Ohne "Config.in" kommt das Ergebnis aber nicht ins Image...

 

[df8oe]

@MaxMuster

Genial!!!!!!! Hat auf Anhieb gefunzt - die Binaries sind jetzt gebaut. Ich hatte dummerweise die libusb1 noch nicht mit eingebunden - was bedeutet, dass ich nicht nur rtl-sdr sondern alles neu bauen musste (??)

Da auf meiner Box bereits ein recht umfangreiches freetz (mit nfs-server etc.) läuft und dies auch im Produktiveinsatz ist, bin ich am Grübeln, wie ich das neu gebaute libusb ins vorhandene System bringen kann, ohne das System länger lahmzulegen. Ich habe zunächst die neu gebauten libraries und Symlinks aus /lib und /usr/lib/freetz ins vorhandene System kopiert, dann die Binaries vom rtl-Projekt und die dazugehörigen Libraries in /usr/bin bzw. /usr/lib. Zumindest die letzten beiden Schritte dürften korrekt sein - ob das mit dem libusb1 so geht, da bin ich mir nicht so sicher. Zumindest meckert das Binary rtl_test, wenn ich es auf der fb starte, "can't load library 'libusb-1.0.so.0'", obwohl ich diese library in /usr/lib/freetz kopiert habe.

Ein ldconfig gibt es nicht im Linux der fb. Also muss ich dem System irgendwie anders mitteilen, dass es neue Libs gibt... Existiert da eine Möglichkeit, das zu erledigen? Da der einzige Unterschied zwischen dem laufenden System und dem neu erstellten die libusb1 ist, würde ich auch einen "dirty-Hack" machen und die entsprechende (cache??)-Datei aus dem neu erstellten System über die des alten Systems rüberkopieren. Nur heisst sie leider nicht ld.so.cache...

Ich arbeite übrigens mit rootfs und externer Festplatte, da meine zahlreichen Erweiterungen nicht im Ansatz in den Flash gepasst hätten...

 

[RalfFriedl]

Ein ldconfig gibt es nicht im Linux der fb. Also muss ich dem System irgendwie anders mitteilen, dass es neue Libs gibt... Existiert da eine Möglichkeit, das zu erledigen?

Du kopierst die Libraries in die passenden Verzeichnisse, dann werden sie automatisch gefunden. Da sich die Verzeichnisse auf einer Festplatte befinden, sollte das kein Problem sein. Für andere Fälle enthält der LD_LIBRARY_PATH noch einige Verzeichnisse, die im RAM der Box sind, da kann man notfalls kleinere Libraries unterbringen.

 

[df8oe]

@RalfFriedl

...genau das funktioniert eben nicht! Ich habe die Libraries in /usr/lib/freetz kopiert - da, wo sie im erstellten filesystem auch hinzugekommen sind. Sie werden aber NICHT automatisch gefunden. Und in der Variable LD_LIBRARY_PATH ist nur /mod/lib - sonst nix. Gibt es einen cache, in dem die bekannten Libraries stehen? Ich kann mir nicht denken, dass der Kernel bei jedem Aufruf einer Library zig Ordner durchsucht. Ich vermute, in irgendeiner (cache)-Datei steht drin, welche Library in welchem Ordner ist. Diese Datei könnte beim Bauen des Systems erzeugt worden sein. Da auf meiner Box das "alte" System läuft, sind dort natürlich nur die "alten" Libraries eingetragene. Und da ich noch nicht weiss, wie die Datei heisst, kann ich die "neue" auch nicht rüberkopieren...

df8oe

 

[RalfFriedl]

Es kann sein, dass Dein System so alt ist, dass es /usr/lib/freetz nicht automatisch durchsucht. Mach mal einen Symlink in /mod/lib auf die benötigten Libraries, oder nimm /usr/lib/freetz in LD_LABRARY_PATH mit auf.

 

[df8oe]

Also verstehen tue ich das nicht....

Das System, das aktiv ist und das, was ich erstellt habe, haben die gleiche Basis (sowohl freetz-seitig als auch fb-firmware-seitig). Bedeutet: Es KANN NICHT ZU ALT SEIN - sonst würden ja die Libraries, die im alten System in /usr/lib/frretz sind nicht auffindbar bzw. nutzlos sein.... Dort sind schon einige Libs, und die werden auch gefunden und genutzt. Und die libusb1-Libs sind nach dem neuen make einfach dazugekommen... Nichtsdestotrotz habe ich /usr/lib/freetz mal versuchsweise in die Umgebungsvariable übernommen - und siehe da (staun,staun...) - die Fehlermeldung der nicht auffindbaren Library ist weg. Dafür gibt es leider eine neue: "usb_claim_interface error -5". Vorher wurde der rtl-Stick aber von der Software korekt identifiziert - immerhin.

Zunächst möchte ich verstehen, warum die Libs erst nach Erweiterung der Umgebungsvariable gefunden wurden - andere Libs in /usr/lib/freetz aber offenbar auch "so" gefunden werden. Dann ist natürlich die neue Fehlermeldung zu interpretieren und das Problem zu finden...

Jeder Schritt (auch mit Fehlermeldungen) führt bei Linux näher ans Ziel - das ist meine Erfahrung. Mit der unter Windows bekannten "schweren Schutzverletzung" kommt man dagegen nicht wirklich weiter

df8oe

 

[RalfFriedl]

Dann war nicht das System zu alt, sondern beim Linken wurde nicht /usr/lib/freetz als Suchpfad angegeben. Zumindest werden jetzt alle benötigten Libraries geladen.
Was die andere Meldung betrifft, vielleicht ist der Kernel zu alt für die USB Library. Such mal bei Google nach der Meldung.

 

[MaxMuster]

Läßt du das eventuell nicht mit root-Rechten laufen?

 

[df8oe]

@RalfFriedl

Hmmm..... Sowohl das alte System auch als das neue enthielten schon Libs in /usr/lib/freetz. Müsste also doch beim Linken bereits berücksichtigt sein - oder irre ich da??

So muss ich nur dran denken, dass das Ganze nur bis zum nächsten Neustart ohne Eingriffe läuft

@MaxMuster
Ich starte das Programm via ssh als root.Ich bin noch nicht wirklich weiter - googlen ergab, dass das Programm keinen exclusiven Zugriff auf den USB-Port bekommen konnte (oder es zumindest glaubt, keinen zu haben). Schade - keine Kernellogs :/

df8oe

 

[RalfFriedl]

Müsste also doch beim Linken bereits berücksichtigt sein - oder irre ich da??

Es ist eine Option, die explizit an den Linker übergeben werden muss.

 

[sf3978]

Zunächst möchte ich verstehen, warum die Libs erst nach Erweiterung der Umgebungsvariable gefunden wurden - andere Libs in /usr/lib/freetz aber offenbar auch "so" gefunden werden.

Schau dir die Ausgabe von:

readelf -d ./<dein-binary> | grep RPATH

an. Mit z. B. der Linkeroption "-Wl,-rpath,/<Pfad>/<zum>/<Verzeichnis>" (in deinem makefile), kannst Du verschiedene und mehrere Verzeichnisse angeben in denen während der Laufzeit nach shared libraries gesucht/geschaut wird. Beispiele gibt es hier im Forum, evtl auch im www.freetz.org.

 

[df8oe]

@RalfFriedl & sf3978

Pfad war tatsächlich nicht im Binary dazugelinkt - liegt am Makefile. Kurzer und schnelle Hack: ich habe von der fehlenden Library einen Sylink in /usr/bin gelegt - denn im Verzeichnis, aus dem das Binary gestartet wird, schaut es immer nach So übersteht das Ganze auch einen Neustart fehlerfrei

Danke - df8oe

 

[df8oe]

VERDACHT wegen neuer Fehlermeldung:

Wenn schon der Lib-Pfad nicht korrekt dazugelinkt war...

Der Quellcode für das Proggi geht von einem "normalen Linux-System" aus - und dort sind die Pfade der Libraries mit ldconfig bekannt gemacht. Auch die Pfade zum /proc/usb...etcetcetc... sind mit Sicherheit gemäss des normalen Linux-Standards bearbetet. Eventuelle "schräge Pfade" werden nicht gesucht/gefunden. Kann es sein, dass das Programm im falschen Pfad nachschaut, ob es exclusiven Zugriff auf den USB-Port hat und dieser Pfad nicht mit dem Pfad unter Freetz übereinstimmt? Also ein weiteres Linker-Problem, da durch einen entsprechenden Eintrag (odr qad durch einen Symlink) gelöst werden kann??

df8oe

 

[sf3978]

Kann es sein, dass das Programm im falschen Pfad nachschaut, ...

Wenn Du ldd auf deiner Box hättest, dann könntest Du evtl. feststellen wo das Programm (binary) nach libraries nachschaut.

 

[MaxMuster]

Du könntest es mit "strace <programm>" aufrufen (sofern du strace aucf der Box hast) um zu sehen, was das Programm so tut.
Eventuell liegt es am USB-Port (bzw. dessen Strom-Kapazität), was ein "aktiver USB-HUB" beheben sollte. Oder aber, das Ding steckt bereits an einem Hub und verträgt sich mit anderen USB Geräten nicht ...

 

[df8oe]

Ich habe zunächst mal im makefile von MaxMuster bei den Optionen für Compiler und Linker die Zeile


LDFLAGS="-Wl,-rpath,/usr/lib/freetz"


ergänzt und neu gebaut. Nun wird das libusb1 auch mit der alten Umgebungsvariable und ohne Symlink auf libusb1 gefunden - also hier Erfolg.

Ich habe den Stick wahlweise an einen der beiden USB-Ports via Hub und auch direkt an den anderen freien Port gestöpselt - beide male das gleiche Ergebnis. usb-claim-error...

df8oe