Hi!
Hatte vorhin schon im GitHub gesehen dass wohl Kernel 3.14.2 bald kommt udn direkt erstmal eine Änderung an der Kernelconfig vorgeschlagen (RT2800USB_RT53XX=y um den in der Xpeed-LX3 verbauten rt5372 auch mit dem rt2800 usb Treibermodul lauffähig zu machen).
Wird die Xpeed-LX3 auch einen neuen BL brauchen für den neuen Kernel, oder kann der aktuelle das bereits?
Noch was : mit dem von GI mitgeschickten Nano-USB-Wifi-Dongle konnte ich mit dem rt2800usb ohne Probleme einen AP auf der LX3 starten. Problem ist einzig und allein, dass der rt2800usb nich den integrierten chip supported (obwohl das modul das könnte!) und dieser daher nur mit dem rt5370sta modul (welches keinen station mode, also keinen hostapd) unterstützt.
Soweit LG p1ng

In diesem Zusammenhang moechte ich gern nochmal darauf hinweisen, dass es grober Unfug ist speziellen Hardwaresupport für bestimmte Module nicht mit zu compilen, nur weil man die spezielle Hardware mit einem anderen Modul nutzen will. Dafür ist das Userspace Module-Blacklisting bzw. udev da. Finde es ehrlich gesagt nicht so witzig stundenlang mit zig firmwares rumzubasteln, nur um dann festzustellen, das jemand den support fuer bestimmte chips in einem modul komplett deaktiviert, nur weil er ein ganz anderes modul für diesen chip nutzen will. Sowas macht man im Userspace und nicht in der Kernelconfig. Es hat naemlich durchaus seinen Grund warum sowohl rt2800usb als auch rt53xx beide den 5372 unterstuetzen..... und wenn niemand einen nachteil davon haette, warum dann den leuten, die es gern anders machen wuerden das zusammenschneiden?? Nich falsch verstehen, aber bin grad bisschen angefressen, weil gewisse developer im git nich verstehen worum es geht, aber ich mir mein auch nich mein eigenes image bauen kann da kaum doku vorhanden ist um sich die git sourcen selber zu compilen. (Forumfrage seit wochen unbeantwortet). Wenns wirklich was kompliziertes waere.. aber nee es is einfach so unnoetig. Udev kann ohne Probleme per udev-rule für ein per id exakt definiertes geraet einen definierten treiber laden. Man muesste noch nichtmal rt2800usb komplett blacklisten.. naja.. muss ich halt weiter einen extea externen usb stick an der box haben um softap nutzen zu koennen obwohl es der interne genauso koennte .. *seufz*

Das ist echt nett, danke.
Bin selber (meiner Meinung nach xD) auch kein völliger novize, arbeite seit ueber einen jahrzehnt mit unix basierten geraete. Ich bin auch jemand der sich gern den Aufwand macht, Dinge die ich in meinem Heinsetup zum laufen bekommen habe auch fuer andere zugaenglich zu machen. Da ich auch son ziemlicher bastler bin, und nich immer nerven mag: gibts eine moeglichkeit eine "definiere" build ungebung einzuichten? habe auf zwei verschiedenen gentoo-basierten maschinen den gleichen fehler wenn ich versuch mir das image vom git selbst zu compilen. Bin ueber jede Unterstuetzung dankbar und revanchier mich denn mit getesten neuen coolen Funktionen wie zB LIRC support in dem Boxen, richtig komplett mit Enigma2-Lirc support und fernbedienungs-anlernen im menue usw usw.

Was ich genau bereits gemacht hab : siehe thread im enigma2-allgemein-Bereich
lg, p1ngb4ck

PS: der fehler weist (glaube ich) darauf hin, dass die "MACHINE"-env variable von bitbake irgendwo auf den wert der qemu-machine veraendert wird, obwohl er eigtl den wert "inihdp" haben sollte. Habe alle dependencies dreifach kontrolliert, finde aber nix. Auch ein kontrollieren aller dynamic links und libs (auf gentoo via revdep-rebuild programm) brachte keine keinerlei fehler, make manuell auf 3.81 gedowngradet usw usw. welches system benutzt ihr? Macht es vlt sinn eine eigene vm zu installieren zB mit nem ubuntu/mint whatever? Hab nun bereits einige stunden zeit investiert um mir ne funktionierende build-umgebung zu schaffen, vor dem bisschen aufwand schrecke ich nicht zurück solange ich irgendeine aussage hab auf welchem system es unter welchen vorrausetzungen laufen "sollte".. danke nochmal im voraus

Okay das erklaert einiges haha

Da henrylicious so nettwar und mir ein angepasstes image zu bauen, konnte ich nun (leider) die problematik (siehe git) mit dem von mir gewuenschten modul nachvollziehen / bestaetigen.
Hostap mit r2800usb wird also nischt.
Habe nun entdeckt das es einen unofficial patch fuer hostapd gibt um support fuer die rtl-sta module hinzuzufuegen. Werde mir mal per gentoo crossdev ein neues hostapd binary mit dem patch bauen und dann weitere infos liefern. Lg