Kernel-Module kompilieren - erster Versuch

  • 62 Antworten
  • Letztes Antwortdatum
S

sven-ola

Ambitioniertes Mitglied
24
Hey,

(gehört evnt. in die Entwickler-Ecke. Ich benutze das Forum mal als Notizblock, evnt. hilft es jemanden ja)

Das hier habe ich gelesen:
Building Android kernel images

Es gibts 2 verschiedene Cross-Compile toolchains:

1 Für faule Leute bietet eine Firma "G++ Lite für ARM-GNU/Linux Target"
Download Sourcery G++ Lite Edition for ARM
Der Java-Installer ist recht huebsch und es installiert dann
einen "gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)" für
das Target "arm-none-linux-gnueabi". Will ich aber nicht benutzen.

2 Für nicht-so-faule wird mit dem Auschecken der Quelltexte eine
Toolcain mitinstalliert. Ich habe ein neues Verzeichnis angelegt:
/usr/src/android. Hineinwechseln und "repo init", "repo sync". Es finden
sich dann verschiedene Versionen unter ./prebuild, beispielsweise unter
linux-x86/toolchain/arm-eabi-4.4.0/bin/, Target ist arm-eabi, diese
Version ist offenbar etwas neuer: "gcc version 4.4.0 (GCC)".
Instruktionen, um die Quellen zu installieren finden sich dann hier:
Get source ?(Android Open Source Project)?

3 Jedenfalls braucht man einen Linux-Kernel-Quellbaum. Der war beim
Checkout (siehe Punkt 2) nicht dabei. Also das hier ausführen:

cd /usr/src/android
git clone git://android.git.kernel.org/kernel/msm.git

In dem lokalen GIT repo sollten mehrere Branches bereits drin sein.
Die Suche nach einem speziellen Samsung-Galaxy-Branch startet ich mit:

sven-ola@pcacer:/usr/src/android/msm$ git branch -a
* android-msm-2.6.27
origin/HEAD
origin/android-msm-2.6.25
origin/android-msm-2.6.27
origin/android-msm-2.6.29
origin/android-msm-2.6.29-donut
origin/android-msm-htc-2.6.25
origin/msm-2.6.25

Schade, kein Samsung da. Evnt. auch brauchbar - der 2.6.27 Branch, der
ja bereits aktiviert ist (der mit dem Stern). Die 2.6.27 steht auch im
./Makefile oben drin - ist ist offenbar gleich alles passend da.

4 Das dmesg auf dem Mobiltelefon behauptet, dass GCC 4.2.1 benutzt wurde:
"Linux version 2.6.27 (hudson@andy) (gcc version 4.2.1)". Damit stehen
aus Schritt 2 für Linux und MAC-OS diese Compiler zur Verfügung:

/usr/src/android/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gcc -v
oder
/usr/src/android/prebuilt/darwin-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gcc -v

(Eins von beiden lässt sich ausführen - falls du nicht mehr weisst ob bei
dir ein Linux oder ein MAC-OS drauf ist <ggg>)

5 Wir brauchen eine .config-Datei. Die ziehe ich mir vom Telefon:

adb pull /proc/config.gz /dev/stdout | gunzip -c > .config

(Vom 17.Juli, also noch nicht mal einen Monat her. Wow).

Erstmal den Cross-Compiler in den Pfad aufnehmen:
export PATH=$PATH:/usr/src/android/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin

Die Konfiguration kann man mit "make ARCH=arm CROSS_COMPILE=arm-eabi- menuconfig"
anpassen. Ich habe einfach das Programm wieder beendet und gespeichert. Dann noch
ein Test-Compile:

make ARCH=arm CROSS_COMPILE=arm-eabi-

Scheint zu laufen. Ctrl-C. Jetzt ein Unionfs dazu, das gibt es auf
Unionfs: A Stackable Unification File System. Passende Diff-Datei
herunterladen und draufspielen:

zcat unionfs-2.5.2_for_2.6.27.24.diff.gz | patch -p1 --dry-run

OK - sieht gut aus, also nochmal ohne "--dry-run". Das UnionFS einschalten
mit "make ARCH=arm CROSS_COMPILE=arm-eabi- menuconfig" (steht unter
File systems -> Layered file systems -> Unionfs = Module). Speichern.
Kompilieren mit "make ARCH=arm CROSS_COMPILE=arm-eabi- modules".

6 Schnell mal draufspielen:
adb push fs/unionfs/unionfs.ko /sdcard
adb shell
insmod /sdcard/unionfs.ko
dmesg

Mist: Unresolved symbols. Das kann jetzt heiter werden :(
<4>[ 5693.336535] unionfs: Unknown symbol vfs_splice_from
<4>[ 5693.341992] unionfs: Unknown symbol vfs_splice_to
<4>[ 5693.357345] unionfs: Unknown symbol release_open_intent
 
Ich habe auch schon versucht meinen eigenen Kernel für das Samsung Galaxy zu kompilieren. Nach ein paar Klimmzügen ging der dann durch, aber er startet nicht. Die erste Fehleranalyse zeigte dann, dass mein kernel nur 1,4mb hat, der von Samsung 1,9mb. Da fehlt also doch so einiges.

Wenn man die Samsung config.gz mit den Sourcen von android-msm-2.6.27 vergleicht, tauchen Einträge auf die gibt es gar nicht. So verwendet das Samsung einen Melfas Touchscreen für den es praktisch keine open source Treiber gibt (vielleicht passen die von MELPAS MCS-5000 Touchscreen, mehr zu Multitouch für Galaxy in meinen Blog)

Ich hab jetzt erst mal eine Anfrage an Samsung geschickt mit der Frage nach dem Quellcode für den Galaxy-Linux-Kernel. Habe sie aber über samsungmobile.co.uk schicken müssen, weil die deutsche Variante kennt im Email-Formular das Galaxy nicht. Eine internationale Samsung Seite gibt es ja nicht, und die von Korea ist nicht in Englisch. Die Antwort steht noch aus.
O2 werde ich auch noch anfragen, sie haben das Galaxy schließlich verkauft, bin aber noch nicht dazu gekommen.

Wie es aussieht müssen wir also erst mal auf die sourcen warten.

multioptionSDK
 
Hey,

ich warte aber nicht gern :) Dass in dem Google-GIT-Repo die Hälfte fehlt, fällt schon beim config.gz auf, welches man sich ja von dem Telefon laden kann, z.B. sowas: "CONFIG_SAMSUNG_CAPELA=y".

Ich habe jetzt ein laufendes unionfs.ko, aber das ist ein *GANZ ÜBLER HACK*. Der Unionfs-Patch ändert dies und das im Kernel. Und das erfordert wiederum, dass man den Kernel neu übersetzt (z.B. werden nicht-exportierte Symbole kurzerhand mit EXPORT_SYMBOL_GPL() herausgeführt. Das wiederum erfordert normalerweise eine Bitte-Bitte-Mail auf der LKML.

Egal - wenn man den unionfs-2.6.27.patch einspielt und dann meinen Hack oben drauf (Attached). Noch kein kleines "arm-eabi-strip --strip-debug" und man hat ein Modul (ebenfalls Attached). Wozu? Ich möchte diesen Debian-Krams ausprobieren (siehe Debian & Android Together on G1 - Jay Freeman (saurik)). Die Busybox von da läuft, ext2 ist bereits im Kernel und loop-mounten geht auch (unter der busybox). An sich hab' ich also alles beineinander.

HTH
// Sven-Ola
 

Anhänge

  • unionfs-for-samsung-galaxy.zip
    38,1 KB · Aufrufe: 303
Netter Hack! :)

@Touchscreen: aus irgendeinem Grund hab ich gestern nicht dran gedacht ins config zu schauen und einfach Samsung-Leute, die einen Melfas-Touchscreen-Treiber posten, mit dem Galaxy assoziiert... Von der Config-Option her sind die Treiber doch nicht gleich, also wohl doch warten. Vielleicht haben sie ihn aber auch einfach nur umbenannt: die anderen Controller können laut Melfas alle keine Interrupts, aber in meinem dmesg find ich das hier:
Code:
melfas_ts_probe: Start touchscreen melfas-tsi-touchscreen in interrupt mode
Sollte es tatsächlich der MCS-5000 sein, dann kann der wohl auch Multitouch: In dem Treiber, den du gefunden hast, sehe ich in mcs5000_ts_input_read folgendes:
Code:
    switch (buffer[READ_INPUT_INFO]) {
[...]
    case INPUT_TYPE_SINGLE:
[...]
    case INPUT_TYPE_DUAL:
        /* TODO */
        break;
    case INPUT_TYPE_PALM:
        /* TODO */
        break;
    case INPUT_TYPE_PROXIMITY:
        /* TODO */
        break;
Die Hardware sollte es also können, jetzt brauchen wir nur noch ein Datenblatt. Oder viel Zeit zum Herumspielen und ein wenig Glück...

Aber auf jeden Fall brauchen wir dafür den Sourcecode von Samsung. Hab in den letzten Wochen schon 2 Mails geschickt, aber noch keine Antwort bekommen. Werd am Montag dann mal die Hotline anrufen und mich solange weiterleiten lassen, bis ich wen kompetenten erwisch. Zumindest so kompetent, dass er weiß, was eine Strafanzeige wegen gewerblicher Urheberrechtsverletzung ist.
 
sven-ola schrieb:
Ich habe jetzt ein laufendes unionfs.ko, aber das ist ein *GANZ ÜBLER HACK*. Der Unionfs-Patch ändert dies und das im Kernel. Und das erfordert wiederum, dass man den Kernel neu übersetzt (z.B. werden nicht-exportierte Symbole kurzerhand mit EXPORT_SYMBOL_GPL() herausgeführt. Das wiederum erfordert normalerweise eine Bitte-Bitte-Mail auf der LKML.

Oho, nicht übel! Meine Kenntnisse von Kernel-Interna sind nicht so super-detailliert; was ich gerne hätte wären die Netfilter-Module, um z.B. einen transparenten Proxy aufzusetzen. Kannst Du schätzen, ob das auch klappen könnte, oder ist Netfilter zu tief integriert, als dass das funktioniert? (Im Samsung-Kernel ist CONFIG_NETFILTER=n).

Floe
 
Hab grad in Deinen Patch reingeschaut:
Code:
+    /*
+     * This is an ugly hack. The Samsung kernel does not 
+     * export the release_open_intent function. We know, that
+     * it resides somewhere between path_put and filp_open...
+     */

:eek: :cool: Hut ab, das ist mal echt Hardcore.

Ich probier jetzt einfach mal aus, ob/wo der Kernel bei den Netfilter-Modulen mault. Vielleicht klappt der Trick ja auch da, wer weiss..
 
Kein CONFIG_NETFILTER? Das sieht schlecht aus. Dann fehlen die entsprechenden Haken im System, die kann man nicht einfach 'reinpatchen. Das Init in net/socket.c bekaeme man wohl noch hin, aber z.B. ipv4/ip_output.c oder ipv4/ip_sockglue.c sehen uebler aus. Suche mal mit
Code:
grep -w CONFIG_NETFILTER $(find net -name "*.c")
Zumindest in 2.6.30 (hab' gerade nix anderes da) findet man Erweiterungen für "static" Funktionen. Sowas kann man nicht einfach ueberschreiben oder umbiegen - jedenfalls nicht ohne ein paar _ASM() oder __emit zu verteilen...
 
sven-ola schrieb:
Sowas kann man nicht einfach ueberschreiben oder umbiegen - jedenfalls nicht ohne ein paar _ASM() oder __emit zu verteilen...
Böse :D Das ist ja schon fast wie Rootkit spielen.. Parallel dazu sollte man aber weiterhin Samsung nerven, dass sie den Source rausrücken. Gibts da schon was neues?

Floe
 
So, Teilerfolg:
Code:
# lsmod
xt_tcpudp 3072 0 - Live 0xbf041000
xt_NFQUEUE 1792 0 - Live 0xbf03f000
x_tables 13572 2 xt_tcpudp,xt_NFQUEUE, Live 0xbf03a000
bcm4325 135600 0 - Live 0xbf017000
multipdp 12724 15 - Live 0xbf012000
dpram 67352 6 - Live 0xbf000000
Hatte noch einen ganz merkwürdigen Fehler zuvor, insmod hat sich im dmesg mit "unknown relocation: 3" beschwert. Folgender Fix hat geholfen:
Code:
--- linux/Makefile     
+++ linux/Makefile     
@@ -563,6 +563,11 @@
 # disable invalid "can't wrap" optimzations for signed / pointers
 KBUILD_CFLAGS  += $(call cc-option,-fwrapv)

+# gcc-4.4 defaults to generating .eh_frame sections, but we aren't
+# interested in those currently. additionally, it causes issues on some
+# architectures.
+KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
+
 # Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
 # But warn user when we do so
 warn-assign = \

Hängt wohl davon ab, welche binutils man hat, aber mit dem Patch lassen sich zumindest die x_*.ko laden. Bei ip_tables.ko hakts dann aber doch:

Code:
[20122.321198] ip_tables: Unknown symbol nf_register_sockopt
[20122.330656] ip_tables: Unknown symbol nf_unregister_sockopt

Das sind genau die Sachen aus net/ipv4/ip_sockglue.c; könnte man nicht alternative Versionen davon (im Prinzip einfach net/ipv4/builtin.o) als Modul laden?

Floe
 
floe schrieb:
Gibts da schon was neues?

Habe gerade Antwort vom Samsung Service der Insel erhalten. Ich soll "contact Android to resolve this enquiry". Lustig, mein Betriebssystem weiß also wo die sourcen zu finden sind. Naja, wer hat da auch was anderes erwartet.

Bei O2 verweisen die auf Samsung. Bleibt also nix weiter übrig, als die noch ein wenig zu nerven. Gibt es eigentlich eine Sammelstelle für GPL-Verstöße?

multioptionSDK
 
multioptionSDK schrieb:
Habe gerade Antwort vom Samsung Service der Insel erhalten. Ich soll "contact Android to resolve this enquiry". Lustig, mein Betriebssystem weiß also wo die sourcen zu finden sind. Naja, wer hat da auch was anderes erwartet.
Interessant. Mir haben heute die Hotline-Leute gesagt, dass sie noch keine Antwort aus Korea haben... Aber der Herr hat zumindest versprochen, nochmal nachzufragen. Ich geb ihnen halt noch ein paar Tage Zeit, bis ich einen bösen Brief schreib.

Vielleicht bringts was, den Autor von diesem MCS-5000 Treiber anzuschreiben? Der arbeitet für Samsung und am Kernel; wenn der Treiber wirklich was mit dem Galaxy zu tun hat, sollte er ja intern bessere Kontakte haben. Eventuell kommen wir so schneller zu einem Ergebnis.

multioptionSDK schrieb:
Bei O2 verweisen die auf Samsung. Bleibt also nix weiter übrig, als die noch ein wenig zu nerven. Gibt es eigentlich eine Sammelstelle für GPL-Verstöße?
Also ich kenn nur gpl-violations.org. Die sind ja angeblich eh schon informiert, bzw. bringt das glaub ich in unserem Fall wenig: Harald Welte ist der Autor von Teilen des Netfilter-Codes, und wie wir ja wissen, hat Samsung den weggelassen. Zivilrechtlich kann gpl-violations.org also in dem Fall glaub ich nichts machen.
 
leromarinvit schrieb:
Also ich kenn nur gpl-violations.org. Die sind ja angeblich eh schon informiert, bzw. bringt das glaub ich in unserem Fall wenig: Harald Welte ist der Autor von Teilen des Netfilter-Codes, und wie wir ja wissen, hat Samsung den weggelassen. Zivilrechtlich kann gpl-violations.org also in dem Fall glaub ich nichts machen.
Doch, doch. Das geht zum Glück schon, weil diverse Linux-Entwickler ihr Copyright an Harald Welte übertragen haben, so dass er eigentlich in praktisch allen Fällen Zivilklage einreichen kann.

Floe

P.S. tun.ko lässt sich zwar problemlos compilieren und laden, aber beim ersten Aufruf von tunctl stürzt das Gerät sowas von ab.. naja. Mal schauen ob man irgendwo ne serielle Konsole herbekommt.
 
floe schrieb:
P.S. tun.ko lässt sich zwar problemlos compilieren und laden, aber beim ersten Aufruf von tunctl stürzt das Gerät sowas von ab.. naja. Mal schauen ob man irgendwo ne serielle Konsole herbekommt.
Seltsam. Bei mir funktioniert das problemlos. Ich hab allerdings nicht den Android git tree genommen, sondern vanilla 2.6.27.29 (und vorher im Makefile das .29 rausgenommen). Glaub aber nicht, dass das einen Unterschied macht. Hab mein Binary in einem anderen Thread gepostet, kannst du mal probieren ob das bei dir geht?

Edit: tunctl hab ich nicht probiert, nur OpenVPN; das geht jedenfalls.
 
leromarinvit schrieb:
Edit: tunctl hab ich nicht probiert, nur OpenVPN; das geht jedenfalls.

Mein tun.ko funzt jetzt auch mit tunctl; hatte wohl zuviel an der Kernel-Config rumgespielt. Gut, dass das jetzt geht, ist zwar nicht ganz so flexibel wie Netfilter, aber ein Anfang.

Jetzt werd ich mir mal vpnc anschauen und versuchen, ob ich den gegen diese nervige bionic-libc gelinkt bekomme. Wie hast Du das bei OpenVPN/OpenSSL gemacht, kannst Du da vielleicht mal CFLAGS/LDFLAGS posten?
 
Ach - ihr habt openvpn hinbekommen. Das ja prima - *freu*. Ich probier's gleich selbst - vleien Dank...
 
floe schrieb:
kannst Du da vielleicht mal CFLAGS/LDFLAGS posten?
Ich bin da kein Experte, aber kann man die nicht aus den android sourcen übernehmen?
 
multioptionSDK schrieb:
Ich bin da kein Experte, aber kann man die nicht aus den android sourcen übernehmen?
Naja, nicht so einfach. Ich hab jedenfalls noch keine Stelle gefunden, wo die klar und deutlich drinstehen - insbesondere nicht so, dass es mit automake und autoconf zusammen funzt.

Ich hab mir ein Wrapper-Skript für configure gebastelt, das zumindest einen Teil der Arbeit abnimmt.. hab's mal angehängt.

Links dazu:
eabi-gcc can't find stdio.h - android-ndk | Google Groups
Android Tricks: Hello World C program using Android Toolchain

Je mehr ich damit mache, desto blöder finde ich bionic.. :-/
 

Anhänge

  • myconf.sh.txt
    1,9 KB · Aufrufe: 298
Zuletzt bearbeitet:
floe schrieb:
Wie hast Du das bei OpenVPN/OpenSSL gemacht, kannst Du da vielleicht mal CFLAGS/LDFLAGS posten?

Ich hab erst die halbe Nacht mit agcc herumgespielt, bin aber zu nichts gekommen. Letztendlich hab ich einen neuen OpenSSL-Tree über den von Android drüberkopiert und einfach mit dem SDK "make openssl" compiled.

OpenVPN selbst hab ich nicht selber compiled, da hat das Binary von den xda-devs wunderbar funktioniert. OpenSSL war nur für Blowfish notwendig.
 

Ähnliche Themen

DerOhneNick
Antworten
3
Aufrufe
1.479
DerOhneNick
DerOhneNick
M
  • mikesch dauerhaft
Antworten
12
Aufrufe
2.586
BOotnoOB
BOotnoOB
M
  • Moonblast
Antworten
1
Aufrufe
1.232
swa00
swa00
Zurück
Oben Unten