Busybox Befehl "patch"

tiga05

tiga05

Fortgeschrittenes Mitglied
12
Guten Tag,

ich hätte mal eine Frage zum Befehl "patch" bei der App Busybox.

Ich kenne den Befehl patch eigentlich im Zusammenhang, mit dem Hinzufügen von Komponenten in den Kernel. Ist es also mit der Busybox möglich, Komponenten zum Kernel hinzuzufügen?! Und das noch während dem Betrieb?

Ich muss natürlich sagen, dass meine Linux-Kenntnisse sich irgendwo zwischen Programme installieren und durch Ordner navigieren bewegen :smile:. Wenn ich also gerade schwer daneben bin, nehmt es mir bitte nicht übel :biggrin:

MfG

tiga05
 
Nein.

Was du mit patch vor der Kernel Erstellung veränderst ist der Source Code, also Textdateien. Danach erst wird der Kernel kompiliert und somit lauffähig.

Mit Patch kannst du also quasi jede Textdatei ändern/aktualisieren. Die angewendeten Dateien sind nur Differenzdateien, die eben die alten Dateien auf den aktuellen Stand bringen. Das kann man natürlich nicht nur mit Kernel Source Dateien machen sondern mit allen möglichen Textdateien. Hat also mit dem Kernel selbst nicht viel zu tun, ist nur ein Werkzeug, wie es z.B. auch ein Texteditor ist um Code zu schreiben.

Natürlich gibt es auch ähnliche Tools für Binäre Dateien, wie es der kompilierte Kernel ist, z.B. bsdiff.

Du bräuchtest dann jedoch erst mal einen kompilierten Kernel und den alten Kernel um die Differnezdatei zwischen beiden zu erstellen, dann wäre es theoretisch auch möglich einen fertigen Kernel zu patchen, jedoch nicht gerade ratsam und sinnvoll, da bei Android der Kernel nicht so rumliegt wie bei Linux sondern ein Image mit der Ramdisk zusammen ist. Du bräuchtest also einen patch der zu dieser Ramdisk passt. Da hat Android auch seine eigenen Tool. Beim Erstellen einer ROM kann man solche patches erstellen lassen, sind auch meist in den OTA enthalten. Mit applypatch werden sie dann angewendet und auf die Boot Partition geschrieben. Also auch nix on the fly, da es nicht den Kernel im RAM ändert sondern die ROM, kannst gleich auch eine neue boot.img mit dem neuen Kernel flashen.

Dem Kernel fügt man neue Komponenten über Module hinzu, also Wunschmodul am PC kompilieren und mit insmod am Gerät laden. So lassen sich jedoch nicht alle Eigenschaften eines Kernels verändern.

Manpage patch
 
  • Danke
Reaktionen: Patman75 und tiga05
Danke. Das hilft mir schonmal weiter.

Ich würde gerne Treiber zum Kernel hinzufügen. Um genau zu sein geht es um Touchdriver für einen Touchscreen, welche vom Hersteller bereit gestellt worden sind, jedoch noch nicht im Linux Kernel enthalten sind.

Kann man Touchdriver problemlos mit insmod auf das Gerät laden un so den bereits kompilierten Kernel erweitern?

Ich bin hier schon eine weile am rummachen. Ich habe im XDA Forum eine Anleitung zum kompilieren gefunden (extra eine VM mit Ubuntu und Programmen als Entwicklerumgebung installiert) und habe mir auch schon die Sources vom Kernel runtergeladen. Leider hänge ich beim eigentlichen kompilieren an vielen kleinen Problemen. Ist halt mein erstes mal :D. Wenn es leichter geht, bin ich natürlich dafür offen :).
 
die Frage ist: was für ein Touchscreen?
Soll es den original ersetzen oder ist es einer über USB?

Bei erstens müsstest du dir einen eignen Kernel erstellen und eben ihn statt dem installierten nutzen, da es Änderungen am Kernel direkt erfordert, genauer und für gewöhnlich in arch/arm/mach-deinSoC/board-deinBoard.c dort muss du den Aufruf des neuen Touchscreen Treibers bekannt machen und dann natürlich auch den Touchscreen Treiber selbst mit in den Kernel kompilieren.

Solltest du jedoch von einem externen Touchscreen schreiben, dann müsste es über Modul ladbar sein. Wenn es z.B. ein USB Touchscreen ist dann brauchst du usbhid und hid-multitouch, das ist der generischen Treiber für USB Touchscreens. Inzwischen genügen sie aus, das was die meisten USB Touchscreen Hersteller als Linux Treiber zur Verfügung stellen komplett veraltet.
 
Zuletzt bearbeitet von einem Moderator:
Ich kann jetzt keine genauen Angaben machen. Aber es handelt sich um einen Touchscreen von iiyama mit Technik von 3M. Er wird per HDMI und USB angeschlossen. Auf deren Homepage habe ich einen Android Treiber gefunden.

Du meinst also der generische Treiber ist noch nicht in Android integriert? Und den kann ich dann ganz einfach über ein Modul hinzufügen (wie auch immer das geht :)).

Ich habe bereits versucht, den Bildschirm über Hinzufügen der manufacturer id und product id in system/usr/idc (oder so ähnlich) zum Laufen zu bringen. Laut diversen Foren kann der Bildschirm mit entsprechenden Einstellungen, in der erstellten config, dann funktionieren. Ich habe dann allerdings im Internet eine Liste gefunden, in der die Linux kompatiblen Geräte aufgelistet sind. Dort war zwar die Firma 3M vertreten jedoch nicht das spezifische Modell (bzw.die id).

Das eigentliche Problem was ich habe ist ja , dass beim Touchscreen nur “klicken“ möglich ist, jedoch kein “rumtouchen“. Im Prinzip wie bei einer Maus, bei der nur die linke Maustaste funktioniert. Der Touchscreen ist allerdings in Ordnung . Das habe ich unter Windows getestet .
 
Mensch, lass dir doch nicht alles aus der Nase ziehen.
- Gib mal einen direkt Link zum Touchscreen und desse Treiber
- Mit welchem Android Gerät soll es zusammenarbeiten?

Ist also wie ich rauslese, ein externer Monitor mit Touch.
Kernel Treiber sind immer eine Sache, ob Android es auch annimmt eine andere.

- Prüfe erst mal, ob es nur einen klick annimmt oder auch mehrer gleichzeitig.
- gib mal im Terminal "cat /proc/bus/input/devices" ein und schau welches davon dein Touchscreen ist und wie es erkannt wurde
- suche unter /sys/bus/usb dein Gerät und schau in dessen uevent Datei rein, dort findest du auch mit welchem Modul es geladen wurde
...

Wenn es nur einen Klick annimmt und nicht mehrer Touches gleichzeitig, dann wurde es wahrscheinlich mit hid-generic/hid-core geladen, ist dann wahrscheinlich schon in deinem Kernel enthalten (ist fast immer damit externe Maus und Tastatur funktionieren)

Kompiliere das Modul hid-multitouch (usbhid brauchst du nicht, da es der Kernel schon hat) mit deinem Kernel Source code und lade es. Wenns dann klappt -> alles gut
wenn nicht -> immer noch one touch/klick -> evtl. Änderungen in Android nötig, kannst in dem Fall auch mal den Hersteller Treiber testen. Muss du aber mal schauen für welche Kernel Version es ist.
 
Zuletzt bearbeitet von einem Moderator:
Guten Morgen,

es handelt sich um einen Iiyama Prolite t2735msc. Zum Einsatz kommt die Touchtechnik von 3M. Hier der Link zum Treiber: 3M Touch Systems Support 3M US: Electronic Solutions : 3M United States
Einfach dann Android auswählen.

Der Stick ist ein TvPeCee mms.884 Quad mit Android 4.2. Den Sourcecode habe ich von der Seite des Anbieters: TVPeCee Internet-TV & HDMI-Stick "MMS-884.quad" inkl. Airmouse

Ich kann mit einem Finger "klicken". Wenn ich mit mehreren Fingern "klicke", klickt er wild durcheinander. Er erkennt aber definitiv immer nur einen Finger gleichzeitig (Kann man sich ja über Entwickleroptionen anzeigen lassen).

Zum "cat" Befehl: Ich lade am Besten mal ein Bild hoch:
http://www.bilder-upload.eu/show.php?file=04de69-1397108600.jpg

Der Name wurde richtig erkannt. Aber mit sonstigen Daten kann ich nicht viel anfangen. Man sieht da nur noch die IDs des Gerätes und an welcher Stelle des Hubs es angeschlossen ist (der Hub ist im Gerät selber verbaut).

Uevent: Dazu auch mal ein Bild:
http://www.bilder-upload.eu/show.php?file=33967f-1397108699.jpg


Ich sehe also, dass es den Driver (wie du ja schon vermutet hast), bekommen hat.

Ich bin übrigens nach folgender XDA-Anleitung vorgegangen: [Tutorial] Building Your First Kernel - xda-developers
 
Gut...

Der Hersteller stellt nicht wirklich einen Treiber bereit, es ist nur ein patch, der die IDs des Geräts dem Kernel bekannt macht, es wird dann hid-multitouch geladen, also der generische.
Wenn er dir nur one touch erkennt, dann hat er auf jeden Fall nicht den richtigen Treiber geladen.

Das es ein TV Stick ist, verändert die Situation. Diese haben oft schon hid-multitouch reinkompiliert.
1. Woher hast du deine Config überhaupt? Dieser muss zum installierten Kernel passen. War sie bei den Sourcen dabei?, wenn ja wo? Oder hast du sie vom Gerät. Wenn sie nicht vom Gerät ist, dann schau mal ob /proc/config.gz existiert. Das ist eine Kopier der Config deines Kernels, viele stellen sie in proc bereit, jedoch nicht alle. Falls sie vorhanden ist, kopiere sie auf den PC, entpacke es und nutze es in Zukunft als deine Config,
2. Schau mal in deine config, was bei CONFIG_HID_MULTITOUCH steht, ist eine Raute davor, ein =y dahinter oder gar ein =m.
Sollte es mit y in den Kernel reinkompiliert sein, muss du deinen gesamten Kernel austauschen, bei # (inaktiv) oder m (also Modul) genügt es wenn du nur das Modul auf das Gerät kopierst.
3. rk3188 hat, wenn ich mich nicht ganz täusche einen 3.0.8 Kernel, da sind die IDs noch notwenidg (beim aktuellen Kernel wurde das ganze überarbeitet und ist daher meist nicht mehr nötig) Du wirst also wohl diesen Patch vom Hersteller brauchen. Den musst du also passend zu deiner Kernel Version herunterladen und auf deinen Source Code anwenden. Hast du das getan, war es erfolgreich?
4. im Terminal solltest du dann mal
Code:
make oldconfig
eingeben (deine config muss als .config benannt im Stammordner sein). Damit bereitest du das kompilieren mit der alten config vor. Danach gibst du
Code:
make menuconfig
ein. Im Terminal erscheint nun ein blaues Fenster, navigieren musst du nach Device Drivers->HID Devices->Special HID drivers->HID Multitouch Panels, aktivere es als Module (m), falls es zuvor nicht aktiv war, speichern und raus. Sollte es einen * haben und somit in den Kernel rein kompiliert sein, kannst du so lassen, muss dann aber den ganzen Kernel austauschen.
5. erstelle den Kernel mit "make", sollte er dir danach nicht auch die Module erstellt haben muss du noch "make modules" laufen lassen.
6. Wenn alles gut gegangen ist findest du das Module unter divers/hid/hid-multitouch.ko. Schau auch mal ins Verzeichnis drivers/hid/usbhid. Sollten dort die Module usbhid.ko und hid-core.ko vorhanden sein, muss du sie auch nehmen. Sie kopierst du dann aufs Gerät und kannst sie dann mit insmod laden.

Nun muss du natürlich sagen, wo es bei dir hapert! Ich weiß ja immer noch nicht, was du gemacht hast.
Hast du den Patch schon angewendet? War es erfolgreich?
Hast du den Kernel schon mal kompiliert? Lief es sauber durch oder gab es einen fail/error? (kann bei rk3188 schon mal vorkommen, erst recht wenn du die falsche config genommen hast)
Hast du schon mal hid-multitouch erstellt, war das Modul vorhanden? Konntest du es in deinen Kernel laden oder wurde es verweigert?
(Lade das Modul immer bevor du den Touchscreen an den Stick anschließt)
...
Fragen über Fragen.
 
Danke erstmal, dass du dir die Mühe machst.

1. Du meinst doch sicherlich die CPU-Config. In dem XDA-Thread wird geschrieben, dass ich die Config aus arch/arm/configs und dann mein Modell nehmen soll. Das habe ich getan. Sie lag in den Sources in dem Unterordner kernel. In der Tat hast du recht, dass ich mir beim zu verwendendem Modell unsicher bin. Ich habe folgende Configs, die wohl ungefähr zur Auswahl passen: rk3188_magicwand_defconfig, rk3188_steak_defconfig und rk3188_tb_defconfig. Der Rest hat kein "rk3188" im Namen.
Ich weiß leider nicht, was ich davon nehmen müsste und hätte im Zweifelsfall alle ausprobiert. Ich gehe allerdings davon, dass eine davon richtig ist, weil das ja eigentlich die Sourcen von dem Stick sind.

Auf dem Stick selber gibt es leider keine config.gz im /proc/ Ordner.

2. Bei allen drei Configs steht "=y" hinter dem entsprechendem Punkt.

3. Unter Kernel-Version im Android bei "über das Gerät" steht 3.0.36+. Den Patch habe ich laut Ausgabe der Konsole erfolgreich angewandt (so wie in der Anleitung von 3M beschrieben; mit dem "patch" Befehl)

4. Habe ich nun von "*" auf "m" geändert, da ich es gerne als Modul hätte. (Anmerkung: Andere Befehle habe ich natürlich auch ausgeführt, entsprechend der Anleitung auf XDA)

Erstellen des Kernels:

Zwischenzeitlich hatte ich Probleme beim kompilieren von irgendwelchen IPV4 Netfilter. Es kam folgende Fehlermeldung: "linux/netfilter_ipv4/ipt_ecn.h no such file or directory"

Das lag daran, dass die entsprechende Datei teilweise groß geschrieben wurde, statt wie hier gefordert, klein. Ich habe es dann selber klein geschrieben. War das richtig so? Jedenfalls hat er mir danach an dieser Stelle keinen Fehler mehr angezeigt.

Aktuell hänge ich beim kompilieren an dem Problem, dass ein geforderter Ordner schlicht ganz fehlt. Zumindest finde ich ihn nicht. Er sollte ja entweder unter drivers liegen, oder unter include/linux Hier mal mein Output vom Ende der Log:

Code:
 CC      net/core/neighbour.o
  CC      net/core/rtnetlink.o
  CC      net/core/utils.o
  CC      net/core/link_watch.o
  CC      net/core/filter.o
  CC      net/core/flow.o
  CC      net/core/net-sysfs.o
  CC      net/core/fib_rules.o
  CC      net/core/net-traces.o
  LD      net/core/built-in.o
  CC      net/ethernet/eth.o
  LD      net/ethernet/built-in.o
  CC      net/ipv4/route.o
  CC      net/ipv4/inetpeer.o
  CC      net/ipv4/protocol.o
  CC      net/ipv4/ip_input.o
  CC      net/ipv4/ip_fragment.o
  CC      net/ipv4/ip_forward.o
  CC      net/ipv4/ip_options.o
  CC      net/ipv4/ip_output.o
  CC      net/ipv4/ip_sockglue.o
  CC      net/ipv4/inet_hashtables.o
  CC      net/ipv4/inet_timewait_sock.o
  CC      net/ipv4/inet_connection_sock.o
  CC      net/ipv4/tcp.o
In file included from include/net/inetpeer.h:15:0,
                 from include/net/route.h:28,
                 from include/net/inet_hashtables.h:32,
                 from include/net/tcp.h:37,
                 from net/ipv4/tcp.c:272:
net/ipv4/tcp.c: In function 'tcp_nuke_addr':
include/net/ipv6.h:338:17: warning: 'in6' may be used uninitialized in this function [-Wmaybe-uninitialized]
net/ipv4/tcp.c:3366:19: note: 'in6' was declared here
  CC      net/ipv4/tcp_input.o
  CC      net/ipv4/tcp_output.o
  CC      net/ipv4/tcp_timer.o
  CC      net/ipv4/tcp_ipv4.o
  CC      net/ipv4/tcp_minisocks.o
  CC      net/ipv4/tcp_cong.o
  CC      net/ipv4/datagram.o
  CC      net/ipv4/raw.o
  CC      net/ipv4/udp.o
  CC      net/ipv4/udplite.o
  CC      net/ipv4/arp.o
  CC      net/ipv4/icmp.o
  CC      net/ipv4/devinet.o
  CC      net/ipv4/af_inet.o
  CC      net/ipv4/igmp.o
  CC      net/ipv4/fib_frontend.o
  CC      net/ipv4/fib_semantics.o
  CC      net/ipv4/fib_trie.o
  CC      net/ipv4/inet_fragment.o
  CC      net/ipv4/ping.o
  CC      net/ipv4/sysctl_net_ipv4.o
  CC      net/ipv4/sysfs_net_ipv4.o
  CC      net/ipv4/proc.o
  CC      net/ipv4/fib_rules.o
  CC      net/ipv4/esp4.o
  CC      net/ipv4/tunnel4.o
  CC      net/ipv4/xfrm4_mode_transport.o
  CC      net/ipv4/xfrm4_mode_tunnel.o
  CC      net/ipv4/netfilter.o
  CC      net/ipv4/netfilter/nf_nat_rule.o
  CC      net/ipv4/netfilter/nf_nat_standalone.o
net/ipv4/netfilter/nf_nat_standalone.c: In function 'nf_nat_standalone_init':
net/ipv4/netfilter/nf_nat_standalone.c:289:2: warning: the comparison will always evaluate as 'true' for the address of 'nat_decode_session' will never be NULL [-Waddress]
  CC      net/ipv4/netfilter/nf_conntrack_l3proto_ipv4_compat.o
  CC      net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.o
  CC      net/ipv4/netfilter/nf_conntrack_proto_icmp.o
  CC      net/ipv4/netfilter/nf_nat_core.o
net/ipv4/netfilter/nf_nat_core.c: In function 'nf_nat_protocol_unregister':
net/ipv4/netfilter/nf_nat_core.c:528:2: warning: the comparison will always evaluate as 'true' for the address of 'nf_nat_unknown_protocol' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_core.c: In function 'nf_nat_init':
net/ipv4/netfilter/nf_nat_core.c:739:3: warning: the comparison will always evaluate as 'true' for the address of 'nf_nat_unknown_protocol' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_core.c:740:2: warning: the comparison will always evaluate as 'true' for the address of 'nf_nat_protocol_tcp' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_core.c:741:2: warning: the comparison will always evaluate as 'true' for the address of 'nf_nat_protocol_udp' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_core.c:742:2: warning: the comparison will always evaluate as 'true' for the address of 'nf_nat_protocol_icmp' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_core.c:751:2: warning: the comparison will always evaluate as 'true' for the address of 'nf_nat_seq_adjust' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_core.c:753:2: warning: the comparison will always evaluate as 'true' for the address of 'nfnetlink_parse_nat_setup' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_core.c:756:2: warning: the comparison will always evaluate as 'true' for the address of 'nf_nat_get_offset' will never be NULL [-Waddress]
  CC      net/ipv4/netfilter/nf_nat_helper.o
  CC      net/ipv4/netfilter/nf_nat_proto_unknown.o
  CC      net/ipv4/netfilter/nf_nat_proto_common.o
  CC      net/ipv4/netfilter/nf_nat_proto_tcp.o
  CC      net/ipv4/netfilter/nf_nat_proto_udp.o
  CC      net/ipv4/netfilter/nf_nat_proto_icmp.o
  LD      net/ipv4/netfilter/nf_conntrack_ipv4.o
  LD      net/ipv4/netfilter/nf_nat.o
  CC      net/ipv4/netfilter/nf_defrag_ipv4.o
  CC      net/ipv4/netfilter/nf_nat_amanda.o
net/ipv4/netfilter/nf_nat_amanda.c: In function 'nf_nat_amanda_init':
net/ipv4/netfilter/nf_nat_amanda.c:80:2: warning: the comparison will always evaluate as 'true' for the address of 'help' will never be NULL [-Waddress]
  CC      net/ipv4/netfilter/nf_nat_ftp.o
net/ipv4/netfilter/nf_nat_ftp.c: In function 'nf_nat_ftp_init':
net/ipv4/netfilter/nf_nat_ftp.c:123:2: warning: the comparison will always evaluate as 'true' for the address of 'nf_nat_ftp' will never be NULL [-Waddress]
  CC      net/ipv4/netfilter/nf_nat_h323.o
net/ipv4/netfilter/nf_nat_h323.c: In function 'init':
net/ipv4/netfilter/nf_nat_h323.c:584:2: warning: the comparison will always evaluate as 'true' for the address of 'set_h245_addr' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_h323.c:585:2: warning: the comparison will always evaluate as 'true' for the address of 'set_h225_addr' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_h323.c:586:2: warning: the comparison will always evaluate as 'true' for the address of 'set_sig_addr' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_h323.c:587:2: warning: the comparison will always evaluate as 'true' for the address of 'set_ras_addr' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_h323.c:588:2: warning: the comparison will always evaluate as 'true' for the address of 'nat_rtp_rtcp' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_h323.c:589:2: warning: the comparison will always evaluate as 'true' for the address of 'nat_t120' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_h323.c:590:2: warning: the comparison will always evaluate as 'true' for the address of 'nat_h245' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_h323.c:591:2: warning: the comparison will always evaluate as 'true' for the address of 'nat_callforwarding' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_h323.c:592:2: warning: the comparison will always evaluate as 'true' for the address of 'nat_q931' will never be NULL [-Waddress]
  CC      net/ipv4/netfilter/nf_nat_irc.o
net/ipv4/netfilter/nf_nat_irc.c: In function 'nf_nat_irc_init':
net/ipv4/netfilter/nf_nat_irc.c:85:2: warning: the comparison will always evaluate as 'true' for the address of 'help' will never be NULL [-Waddress]
  CC      net/ipv4/netfilter/nf_nat_pptp.o
net/ipv4/netfilter/nf_nat_pptp.c: In function 'nf_nat_helper_pptp_init':
net/ipv4/netfilter/nf_nat_pptp.c:285:2: warning: the comparison will always evaluate as 'true' for the address of 'pptp_outbound_pkt' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_pptp.c:288:2: warning: the comparison will always evaluate as 'true' for the address of 'pptp_inbound_pkt' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_pptp.c:291:2: warning: the comparison will always evaluate as 'true' for the address of 'pptp_exp_gre' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_pptp.c:294:2: warning: the comparison will always evaluate as 'true' for the address of 'pptp_nat_expected' will never be NULL [-Waddress]
  CC      net/ipv4/netfilter/nf_nat_sip.o
net/ipv4/netfilter/nf_nat_sip.c: In function 'nf_nat_sip_init':
net/ipv4/netfilter/nf_nat_sip.c:554:2: warning: the comparison will always evaluate as 'true' for the address of 'ip_nat_sip' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_sip.c:555:2: warning: the comparison will always evaluate as 'true' for the address of 'ip_nat_sip_seq_adjust' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_sip.c:556:2: warning: the comparison will always evaluate as 'true' for the address of 'ip_nat_sip_expect' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_sip.c:557:2: warning: the comparison will always evaluate as 'true' for the address of 'ip_nat_sdp_addr' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_sip.c:558:2: warning: the comparison will always evaluate as 'true' for the address of 'ip_nat_sdp_port' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_sip.c:559:2: warning: the comparison will always evaluate as 'true' for the address of 'ip_nat_sdp_session' will never be NULL [-Waddress]
net/ipv4/netfilter/nf_nat_sip.c:560:2: warning: the comparison will always evaluate as 'true' for the address of 'ip_nat_sdp_media' will never be NULL [-Waddress]
  CC      net/ipv4/netfilter/nf_nat_tftp.o
net/ipv4/netfilter/nf_nat_tftp.c: In function 'nf_nat_tftp_init':
net/ipv4/netfilter/nf_nat_tftp.c:46:2: warning: the comparison will always evaluate as 'true' for the address of 'help' will never be NULL [-Waddress]
  CC      net/ipv4/netfilter/nf_nat_proto_dccp.o
  CC      net/ipv4/netfilter/nf_nat_proto_gre.o
  CC      net/ipv4/netfilter/nf_nat_proto_udplite.o
  CC      net/ipv4/netfilter/nf_nat_proto_sctp.o
  CC      net/ipv4/netfilter/ip_tables.o
  CC      net/ipv4/netfilter/iptable_filter.o
  CC      net/ipv4/netfilter/iptable_mangle.o
  LD      net/ipv4/netfilter/iptable_nat.o
  CC      net/ipv4/netfilter/iptable_raw.o
  CC      net/ipv4/netfilter/ipt_ah.o
  CC      net/ipv4/netfilter/ipt_ecn.o
net/ipv4/netfilter/ipt_ecn.c:26:21: warning: 'struct ipt_ecn_info' declared inside parameter list [enabled by default]
net/ipv4/netfilter/ipt_ecn.c:26:21: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
net/ipv4/netfilter/ipt_ecn.c: In function 'match_ip':
net/ipv4/netfilter/ipt_ecn.c:28:55: error: dereferencing pointer to incomplete type
net/ipv4/netfilter/ipt_ecn.c:29:17: error: dereferencing pointer to incomplete type
net/ipv4/netfilter/ipt_ecn.c:29:28: error: 'IPT_ECN_OP_MATCH_IP' undeclared (first use in this function)
net/ipv4/netfilter/ipt_ecn.c:29:28: note: each undeclared identifier is reported only once for each function it appears in
net/ipv4/netfilter/ipt_ecn.c: At top level:
net/ipv4/netfilter/ipt_ecn.c:34:9: warning: 'struct ipt_ecn_info' declared inside parameter list [enabled by default]
net/ipv4/netfilter/ipt_ecn.c: In function 'match_tcp':
net/ipv4/netfilter/ipt_ecn.c:48:11: error: dereferencing pointer to incomplete type
net/ipv4/netfilter/ipt_ecn.c:48:25: error: 'IPT_ECN_OP_MATCH_ECE' undeclared (first use in this function)
net/ipv4/netfilter/ipt_ecn.c:49:12: error: dereferencing pointer to incomplete type
net/ipv4/netfilter/ipt_ecn.c:58:11: error: dereferencing pointer to incomplete type
net/ipv4/netfilter/ipt_ecn.c:58:25: error: 'IPT_ECN_OP_MATCH_CWR' undeclared (first use in this function)
net/ipv4/netfilter/ipt_ecn.c:59:12: error: dereferencing pointer to incomplete type
net/ipv4/netfilter/ipt_ecn.c: In function 'ecn_mt':
net/ipv4/netfilter/ipt_ecn.c:75:10: error: dereferencing pointer to incomplete type
net/ipv4/netfilter/ipt_ecn.c:75:24: error: 'IPT_ECN_OP_MATCH_IP' undeclared (first use in this function)
net/ipv4/netfilter/ipt_ecn.c:76:3: warning: passing argument 2 of 'match_ip' from incompatible pointer type [enabled by default]
net/ipv4/netfilter/ipt_ecn.c:25:20: note: expected 'const struct ipt_ecn_info *' but argument is of type 'const struct ipt_ecn_info *'
net/ipv4/netfilter/ipt_ecn.c:79:10: error: dereferencing pointer to incomplete type
net/ipv4/netfilter/ipt_ecn.c:79:25: error: 'IPT_ECN_OP_MATCH_ECE' undeclared (first use in this function)
net/ipv4/netfilter/ipt_ecn.c:79:46: error: 'IPT_ECN_OP_MATCH_CWR' undeclared (first use in this function)
net/ipv4/netfilter/ipt_ecn.c:80:3: warning: passing argument 2 of 'match_tcp' from incompatible pointer type [enabled by default]
net/ipv4/netfilter/ipt_ecn.c:32:20: note: expected 'const struct ipt_ecn_info *' but argument is of type 'const struct ipt_ecn_info *'
net/ipv4/netfilter/ipt_ecn.c: In function 'ecn_mt_check':
net/ipv4/netfilter/ipt_ecn.c:92:10: error: dereferencing pointer to incomplete type
net/ipv4/netfilter/ipt_ecn.c:92:24: error: 'IPT_ECN_OP_MATCH_MASK' undeclared (first use in this function)
net/ipv4/netfilter/ipt_ecn.c:95:10: error: dereferencing pointer to incomplete type
net/ipv4/netfilter/ipt_ecn.c:98:10: error: dereferencing pointer to incomplete type
net/ipv4/netfilter/ipt_ecn.c:98:25: error: 'IPT_ECN_OP_MATCH_ECE' undeclared (first use in this function)
net/ipv4/netfilter/ipt_ecn.c:98:46: error: 'IPT_ECN_OP_MATCH_CWR' undeclared (first use in this function)
net/ipv4/netfilter/ipt_ecn.c: At top level:
net/ipv4/netfilter/ipt_ecn.c:111:22: error: invalid application of 'sizeof' to incomplete type 'struct ipt_ecn_info'
make[3]: *** [net/ipv4/netfilter/ipt_ecn.o] Error 1
make[2]: *** [net/ipv4/netfilter] Error 2
make[1]: *** [net/ipv4] Error 2
make: *** [net] Error 2
tgaudich@kg-edv-189-ubuntu:~/android/kernel_rk31881$ ^C


Komplett kompiliert habe ich den Kernel noch nicht. Deswegen bin ich zum Module kompilieren auch noch nicht gekommen

EDIT: Den Ordner gibt es doch. Leider die gesuchte Datei aber nicht.

EDIT2: Die Sourcen sind entpackt 7 GB. Der Kernel nur 500Mb Was ist denn der ganze Rest? Da gibt es Z.b. noch einen anderen Kernel-Ordner. Der nennt sich kernel-T. Ich selber habe mir allerdings nur die 500MB vom kernel Ordner gezogen, da die Platte der VM leider nicht wirklich groß ist. Den Rest brauche ich doch für meine Zwecke eigentlich nicht, oder doch?
 
Zuletzt bearbeitet:
Nun, ich habe keine Ahnung was du da getrieben hast, hast jedoch deinen Source Tree wohl durcheinander gebracht.

In dem Archiv hast du den gesamten Source für das Android auf deinem Stick. Nur der Kernel Ordner müsste eigentlich reichen, kernel-t ist der Source für den rk3188T Prozessor. Musst du halt mal schauen, ob du den rk3188 CPU oder die T Variante hast, danach wählst du den Kernel Ordner.

Fangen wir mal von vorne an.
- Entpacke den Kernel Ordner von neuem, damit es frisch ist und du deine Fehler/Veränderungen nicht weiter mitschleppst.
- wenn du in deinem Dateiexplorer das Anzeigen von versteckten Dateien aktivierst, dann siehst du das im Kernel Verzeichnis schon eine .config Datei existiert. Sie ist höchstwahrscheinlich die Config für deinen Kernel (muss sie aber nicht sein). Brauchst also wohl keine andere Config. Auf jeden Fall ist keine der defconfigs zu deinem Stick passend. Die vorhandenen Scripte in den anderen Ordnern legen die .config als deinen Config nahe. Im Kernel Ordner ist auch eine Datei mrgtmp0, diese ist auch eine Config, kannst du mal testen, wenn es mit der .config nicht bootet.
- Ich erwähnte oben schon, dass als Modul kompilieren dir nicht viel bringt, wenn hid-multitouch schon direkt in den Kernel kompiliert ist, da du dann so oder so den gesamten Kernel auswechseln musst. Ist dann schlauer es weiter drin zu lassen als noch mit einem Modul rumhantieren. Bedarf also keine Änderungen mit menuconfig.
- Wende nun den Patch wie in der Readme dazu auf deinen Kernel Source an.
- Bei Rockchip Geräten ist der Kernel meist eigenständig, also nicht mit der boot.img zusammengepackt. Er wird als kernel.img erstellt. Das machst du mit "make kernel.img -j5" (vergiss nicht die exports aus der Anleitung zu Kompilieren, die du gepostet hattest)
- Das läuft dann sauber durch. Wenn es fertig ist findest du die Datei kernel.img in deinem Kernel Verzeichnis. Diesen flashst du dann mit einem Rockchip Tool. Kannst auch aus Linux heraus machen. Im Thread https://www.android-hilfe.de/forum/...pgrade-tool-fuer-rockchip-geraete.548915.html findest du das nötige Tool dazu.

Edit: Noch eine Anmerkung. Vor dem Flashen solltest du dich zuvor auch schlau machen, wie das Gerät sich verhält, wie man es in den Flash Modus bekommt, ob es wie es bei Notfall zu handhaben ist (unbrick und co.)
 
Zuletzt bearbeitet von einem Moderator:
  • Danke
Reaktionen: tiga05
So. Also es sieht momentan so aus:
Ich habe den Kernel erfolgreich kompiliert. Leider habe ich Probleme den Stick in den Download-Modus zu versetzen. Es gibt KEINE Taste, bis auf die Power-Taste auf dem Stick. Der Befehl im Android Terminal Emulator "reboot download" geht nicht. "reboot recovery" geht allerdings. Kann man das auch irgendwie über den Recovery-Modus regeln, oder per ADB?
 
Zuletzt bearbeitet:
Einen Reboot download Befehl gibt es nicht, wenn dann "reboot bootloader".
Du solltest jedoch vorsichtig sein, ein neuer Kernel, vor allem wenn man nicht weiß, ob die Config richtig war, kann auch zu einem nicht bootenden OS führen.
Wenn du keine Möglichkeit hast mechanisch in den bootloader zu booten, würde es in dem Fall ganz schlecht aussehen und einem Brick gleichkommen. Dann hättest du nicht mehr die Möglichkeit über das Tool neu zu flashen.
Ob du dann noch in die Recovery kommen würdest und ob du auch ein Image hast, das sich über die Recovery flashen lässt, müsste sich dann erst rausstellen, bzw. Du vor einem Eingriff auch sicher stellen.

Mein Rat also: schau hier in das TV Stick Forum. Es gibt dort auch andere Sticks, bei denen ein Boot in den Bootloader nur über Android möglich ist. Manche kann man wohl öffnen und mit Tricks dann in den Bootloader booten. Schau dir auch diese Möglichkeiten an und ob sie für dich in Frage kommen, evtl. testen bevor du was flashst. Evtl. Ist es auch eine gute Idee vor dem Eingriff eine Custom Recovery zu flashen.

Sicher dich also so gut wie möglich ab, bevor du flashst. All das liegt in deiner Verantwortung.


Wenn der Kernel nun durch gelaufen ist, kannst du natürlich auch versuchen hid-multitouch als Modul zu kompilieren.
Die Chancen, dass der installierte Kernel es annimmt ist zwar verschwindend gering, da schon vorhanden, probieren macht aber schlau ;)
Wenn du schon mal bei Module kompilieren bist, dann such dir auch mal irgendein anderes aus, eins was nicht im Kernel enthalten ist. Kompilieren das gleich mit und lade es dann später auf dem Gerät mit insmod. Sinn der Übung ist, wenn der Kernel das Modul annimmt, dann kann so falsch die Config nicht sein, da ein Kernel nur passende Module laden kann. Gibt etwas Sicherheit.
 
Guten Morgen,

ich habe es nun geschafft, das Gerät in den Download-Modus zu versetzen. Am ende war es doch recht einfach: An-Knopf gedrückt halten und dann den USB-Stecker reinstecken. Unter Linux hat er dann auch erfolgreich den Kernel geflasht (zumindest meinte er "Download image ok"). Gibt es eigentlich irgendeine Möglichkeit, sich in dem Kernel zu verewigen? Ich würde nämlich gerne 100% sicher gehen, dass der Kernel, den ich geflasht habe, auch genutzt wird.

Weil, er erkennt den Monitor immer noch als USBHID. Kann ich irgendwo nachschauen, dass der Eintrag des Herstellers nun auch vorhanden ist?
EDIT dazu: Die Einträge sind im unkompilierten Kernel vorhanden wie in der 3M-Anleitung beschrieben vorhanden. hid-core.c, hid-ids.c und hid-multitouch.c wurden bearbeitet.

Das so weit als Feedback. Ich bastel dann noch ein wenig rum....

Technisch gesehen ist das Teil übrigens ein cx 919 ii und irgendwo ist auch ein AP6210 verlötet. Da kann ich ja auch alle passenden ROMS dafür flashen.

EDIT: Nur um nochmal sicher zu gehen:
1. patchen des Kernels mit: patch -p1 -d drivers < ../kernelpatch (im Kernel root-verzeichnis, während die für den Path benutzte Datei ein Ordner höher liegt)
2. export ARCH=arm
3. export CROSS_COMPILE=~/android/toolchains/arm-eabi-linaro-4.6.2/bin/arm-eabi- (da wo eben die Compiler-Tools liegen)
4. make oldconfig
5. make menuconfig
6. make kernel.img

EDIT: Es tut einfach nicht :(
 
Zuletzt bearbeitet:
zu 1. ist der patch sauber und erfolgreich durchgelaufen?
zu 3. dein Compiler ist nicht gerade der aktuellste, wenn du es mal mit einem aktuelleren Versuchen willst, dann kannst du auch mit dem gnu Compiler, also dem Standard Ubuntu Compiler, versuchen. Siehe dazu https://www.android-hilfe.de/forum/...acer-iconia-tab-a210.355232.html#post-4829777
zu 5. was hast du mit make menuconfig verändert? Wenn du hid-multitouch als Modul kompiliert hast, dann ist es nicht im Kernel enthalten und wird dadurch natürlich nicht geladen. In dem Fall findest du hid-multitouch.ko im Verzeichnis drivers/hid, diese Datei muss du dann aufs Gerät kopieren und mit insmod (root) laden

Schau auch mal auf dem Gerät ob das Verzeichniss /sys/module/hid_multitouch/drivers exisitert und falls ja, ob da ein Symlink zu USB Gerät existiert.
 

Anhänge

  • kernel.img.zip
    3,3 MB · Aufrufe: 127
1. Ja, ist er. Muss ich eigentlich nach jedem "make clean", den Patch neu anwenden?
3. Ich habe nun den verlinkten probiert. Das Ende vom kompilieren des kompletten Sources sieht so aus:

Code:
  CC      net/xfrm/xfrm_sysctl.o
  CC      net/wireless/sme.o
  CC      net/wireless/chan.o
  CC      net/xfrm/xfrm_replay.o
  CC      net/wireless/ethtool.o
  CC      net/xfrm/xfrm_user.o
  CC      net/xfrm/xfrm_ipcomp.o
  CC      net/wireless/mesh.o
  CC      net/wireless/wext-compat.o
  CC      net/wireless/wext-sme.o
  CC      net/wireless/wext-core.o
  CC      net/wireless/wext-proc.o
  CC      net/wireless/wext-priv.o
  LD      net/wireless/cfg80211.o
  LD      net/wireless/built-in.o
  LD      net/xfrm/built-in.o
  LD      net/built-in.o
  LD      vmlinux.o
  MODPOST vmlinux.o
  GEN     .version
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
  KSYM    .tmp_kallsyms1.S
  AS      .tmp_kallsyms1.o
  LD      .tmp_vmlinux2
  KSYM    .tmp_kallsyms2.S
  AS      .tmp_kallsyms2.o
  LD      vmlinux
  SYSMAP  System.map
  SYSMAP  .tmp_System.map
  OBJCOPY arch/arm/boot/Image
  Building modules, stage 2.
  MODPOST 23 modules
  Kernel: arch/arm/boot/Image is ready
  AS      arch/arm/boot/compressed/head.o
  CC      drivers/media/common/tuners/max2165.mod.o
  CC      drivers/media/common/tuners/mc44s803.mod.o
  CC      drivers/media/common/tuners/mt2060.mod.o
  CC      drivers/media/common/tuners/mt20xx.mod.o
  CC      drivers/media/common/tuners/mt2131.mod.o
  CC      drivers/media/common/tuners/mt2266.mod.o
  LZO     arch/arm/boot/compressed/piggy.lzo
  CC      drivers/media/common/tuners/mxl5005s.mod.o
/bin/sh: 1: lzop: not found
make[2]: *** [arch/arm/boot/compressed/piggy.lzo] Error 1
make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2
make: *** [zImage] Error 2
make: *** Waiting for unfinished jobs....
  CC      drivers/media/common/tuners/mxl5007t.mod.o
  CC      drivers/media/common/tuners/qt1010.mod.o
  CC      drivers/media/common/tuners/tda18212.mod.o
  CC      drivers/media/common/tuners/tda18218.mod.o
  CC      drivers/media/common/tuners/tda18271.mod.o
  CC      drivers/media/common/tuners/tda827x.mod.o
  CC      drivers/media/common/tuners/tda8290.mod.o
  CC      drivers/media/common/tuners/tda9887.mod.o
  CC      drivers/media/common/tuners/tea5761.mod.o
  CC      drivers/media/common/tuners/tea5767.mod.o
  CC      drivers/media/common/tuners/tuner-simple.mod.o
  CC      drivers/media/common/tuners/tuner-types.mod.o
  CC      drivers/media/common/tuners/tuner-xc2028.mod.o
  CC      drivers/media/common/tuners/xc5000.mod.o
  CC      drivers/media/video/gspca/gspca_main.mod.o
  CC      drivers/scsi/scsi_wait_scan.mod.o
  LD [M]  drivers/media/common/tuners/max2165.ko
  LD [M]  drivers/media/common/tuners/mc44s803.ko
  LD [M]  drivers/media/common/tuners/mt2060.ko
  LD [M]  drivers/media/common/tuners/mt20xx.ko
  LD [M]  drivers/media/common/tuners/mt2131.ko
  LD [M]  drivers/media/common/tuners/mt2266.ko
  LD [M]  drivers/media/common/tuners/mxl5005s.ko
  LD [M]  drivers/media/common/tuners/mxl5007t.ko
  LD [M]  drivers/media/common/tuners/qt1010.ko
  LD [M]  drivers/media/common/tuners/tda18212.ko
  LD [M]  drivers/media/common/tuners/tda18218.ko
  LD [M]  drivers/media/common/tuners/tda18271.ko
  LD [M]  drivers/media/common/tuners/tda827x.ko
  LD [M]  drivers/media/common/tuners/tda8290.ko
  LD [M]  drivers/media/common/tuners/tda9887.ko
  LD [M]  drivers/media/common/tuners/tea5761.ko
  LD [M]  drivers/media/common/tuners/tea5767.ko
  LD [M]  drivers/media/common/tuners/tuner-simple.ko
  LD [M]  drivers/media/common/tuners/tuner-types.ko
  LD [M]  drivers/media/common/tuners/tuner-xc2028.ko
  LD [M]  drivers/media/common/tuners/xc5000.ko
  LD [M]  drivers/media/video/gspca/gspca_main.ko
  LD [M]  drivers/scsi/scsi_wait_scan.ko
tgaudich@kg-edv-189-ubuntu:~/android/kernel$ make ARCH=arm CROSS_COMPILE_=arm-linux-gnueabi- modules -j5
  CHK     include/linux/version.h
  CHK     include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
  CALL    scripts/checksyscalls.sh
  Building modules, stage 2.
  MODPOST 23 modules
tgaudich@kg-edv-189-ubuntu:~/android/kernel$

Das ZImage schlägt fehl?

5. Ich habe dort nichts verändert. Der Treiber ist immer noch inkludiert (*)

Du hast einen Kernel verlinkt. Wäre das der kompilierte? Ich habe jetzt nur das Problem, dass ich mittlerweile eine Custom-Rom drauf gemacht habe und kein Backup der alten Rom. *facepalm*. Da kommt der Stick dann nicht mehr über die Bootanimation hinweg und startet dann neu. Aber immerhin habe ich jetzt die Gewissheit, dass der Kernel, den ich per Ubuntu geflasht habe, auch Anwendung findet :biggrin:
 
1. nein, machst du nur einmal. Clean löscht nichts an den Sourcen sondern nur die kompilierten Ergebnisse.
3. Du solltest schon auch schreiben, was du genau ausgeführt hast. Dass du bei deinem Gerät einen kernel.img brauchst, hatten wir doch schon auf der letzten Seite, du musst also "make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- kernel.img -j5". Bei deiner Ausgabe ist nicht ersichtlich mit welchem Befehl du den Build angestoßen hast. Beachte auch die richtige schreibweise, beim make modules hast du CROSS_COMPILE_ statt CROSS_COMPILE. Solche Flüchtigkeitsfehler solltest du vermeiden!

Ja, klar ist der kompiliert, ansonsten wäre doch ein verlinken unsinnig
 
Ich habe folgende Befehle eingegeben:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- clean
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- oldconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j5

Ich wollte jetzt den kompletten Kernel mit ROM kompilieren. Sollte ja eigentlich auch funktionieren. Dabei kann er aber eben kein zimage erstellen (Was auch immer das ist). Der eigentliche Kernel kann fehlerfrei kompiliert werden (make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- kernel.img ).

Ich muss mir jetzt aber erstmal wieder irgendwo das original Rom besorgen...
 
zImage ist ein komprimierter Kernel.

Letzte Zeile ist bei dir eben unnötig, da du ein kernel.img brauchst.
Die vorletzte brauchst du auch nicht, wenn du an den Kernel configs nichts ändern möchtest.
Das du die Befehle eingegeben hattest, sagt jedoch nicht aus, dass du sie auch richtig eingegeben hattest. Schau mal in deine Ausgabe oben, CROSS_COMPILE hattest du falsch geschrieben. Kannst du sicher sagen, dass du es bei den übrigen Befehlen richtig eingegeben hattest?

Ganz ehrlich: langsam reicht es mir.
Wenn du schon was anderes machst, dann schreibe auch exakt was du gemacht hast! Ich werde mir sicher nicht aus den Fingern saugen, welche ROM du nun versuchst zu kompilieren, mit welchen Befehlen...
 
Ich bin erstaunt, wie viel Geduld du mit mir hast :).

Ich habe meinen Fehler korrigiert und die Befehle nochmals eingegeben - bevor ich das vorhin gepostet hatte.

Der Kernel ist immer noch derselbe. Ich habe mittlerweile allerdings mal einige Custom-Roms probiert, in der Hoffnung, dass diese vielleicht mehr können. Leider sind die Custom-Roms doch zu stark verändert, als das diese mit dem original Kernel kompatibel sind. Jetzt muss ich eben irgendwo die Stock-Rom auftreiben. Oder eben die Sources richtig kompilieren und dann flashen. Mir ist klar, dass sich anderer Source-Code anders verhalten kann bzw. unter bestimmten Umständen anders kompiliert werden muss.

Ansonsten werde ich wohl mit der Custom-Rom mit vorlieb nehmen müssen. Und der Touchscreen geht halt wieder zurück. Auch wenn das Ganze jetzt vielleicht nicht funktioniert, so habe ich doch sehr viele Dinge dazu gelernt. Ohne dich wäre ich nicht so weit gekommen. Dafür nochmal vielen Dank!
 
Naja, eine Custom ROM hat auch einen Kernel, dieser Kernel hat einen Quellcode, dieser Kernel Quellcode steht wie jeder andere Kernel Quellcode unter der GPL. ;)
Finde also den original Thread der ROM, in welcher Community auch immer, dort müsste der Dev auch einen Link zum Kernel Quellcode bereitstellen und falls nicht, dann Frage ihn dort danach ;)
 

Ähnliche Themen

S
Antworten
2
Aufrufe
1.558
seluce
S
Foh
Antworten
0
Aufrufe
1.215
Foh
Foh
L
  • linuxnutzer
Antworten
2
Aufrufe
950
linuxnutzer
L
Zurück
Oben Unten