Odys Loox - USB-Hub aktivieren und nutzen!

[djolivier]

Kann mir das jmd nochmal fuer dummies erklaeren? Hab ein Loox mit dem orig ROM und wuerde gerne meinen usb hub nutzen, danke

Sent from my Orange Boston using Tapatalk

 

[fluxflux]

Hätte noch jemand direkt ein tun.ko für den Loox für mich?

Im Anhang das tun.ko für den Loox, wegen eines Fehlers im ersten Upload als tun2.zip im Anhang ...

Thomas.

 

[RainerWP]

Im Anhang das tun.ko für den Loox.

Thomas.

Hi Thomas,
wird bei mir nicht geladen

<4>[ 3282.434064] tun: Unknown symbol netpoll_trap

Bis dann,

Rainer

 

[fluxflux]

Probier' doch mal das Modul aus dem Xpress-Thread ... da hängt auch eines als ZIP an, der Kernel ist ja identisch.

Habe den Fehler gefunden, das Modul tun.ko, das bei mir geladen wird, im Post oben als tun2.zip im Anhang ...

Thomas.

 

[RainerWP]

Jupp,

lädt ohne Probs
Dann werde ich mal die Tage mein VPN einrichten

Danke und bis dann............

Rainer

 

[Oma7144]

In der boot.img findest du eine init.rc, die öffnest du und schreibst nach der Zeile

insmod rk29nand.ko.ko

die Zeile

insmod hubenable.ko
insmod tun.ko

rein und speicherst die init.rc wieder.

Die beiden Kernelmodule hubenable.ko und tun.ko packst du ins Rootverzeichnis der offenen boot.img und erstellst eine neue boot.img, die du aufs Tablet flashst, sonst brauchst du nichts neu flashen!

Das war es dann schon.

Und das läuft auf allen Geräten, auch auf nicht gerooteten.

Thomas.

Hi flux, wir hatten schon darüber geschwätzt, ob du nicht als nächste Großtat eine boot.img baust, mit allen bisherigen Errungenschaften:

usbenable.ko
joydev.ko
tun.ko
cd-rom support
bluetooth
steckdosenleiste
....

Die Steuerung für die Marssonde kann ja später mal berücksichtigt werden ;-)


Many thanks in advance!

 

[TheWolf]

Hi flux, wir hatten schon darüber geschwätzt, ob du nicht als nächste Großtat eine boot.img baust, mit allen bisherigen Errungenschaften:

Dir Frage ist natürlich auch, wieviel Platz haben wir überhaupt in der boot.img?

Gruß,
TheWolf

 

[fluxflux]

Dir Frage ist natürlich auch, wieviel Platz haben wir überhaupt in der boot.img?

Gruß,
TheWolf

Genügend für einen ganzen Sack voller Kernelmodule ...

Thomas.

 

[fluxflux]

Hi flux, wir hatten schon darüber geschwätzt, ob du nicht als nächste Großtat eine boot.img baust, mit allen bisherigen Errungenschaften ...

Ich denke, dass der Weg von RainerWP mit einem Link in der init.rc (boot.img) auf ein universelles Startskript in /data oder sonstwo der richtige Weg ist.

Da kann dann von jedem Nutzer individuell entschieden werden, was gestartet und welche Kernelmodule geladen werden sollen.

Denn nicht jeder braucht die zusätzlichen Kernelmodule im laufenden Kernel.

So entfällt jede zukünftige Änderung der boot.img.

Ich warte mal ab, was da als Lösung angeboten werden wird ...

Thomas.

 

[ropa]

Hi,

also ich habe das so gemacht. In init.sh ganz an das Ende

# if user init.sh
if [ -x /data/init.sh ]
then
        /busybox sh /data/init.sh
fi

Funktioniert einwandfrei.

btw habe ich ausserdem die busybox gegen meine selbst compilierte ausgetauscht. Die hat jetzt so ziemlich alle Funktionen drin. Ich moechte einmal ueber inotifyd z.B. das gps starten, wenn das entsprechende usb-geraet angeschlossen wird. Ich hoffe inotify ist auch im Kernel aktiviert.

Viele Gruesse
ropa

 

[RainerWP]

Hi,
also ich habe das so gemacht. In init.sh ganz an das Ende

Hi ropa,

die ist init.sh ist aber nicht standardmäßig im system drin oder ?
Falls ja, wo ?

Bis dann..............

Rainer

 

[fluxflux]

@ ropa

Gute Idee, das ist sicher ein guter Ansatz, halte uns bitte auf dem Laufenden ... ich habe /data/etc/rc.d/ angelegt und dort ein rc.local als General-User-Skript angelegt, in das ich dann bei Bedarf weitere Skripte aus /data/etc/rc.d/ eintrage. Das ist sicher Geschmacksache und bei mir von Slackware her so gewohnt.

@ RainerWP

ropa meint sicher die init.rc in der boot.img ...

Thomas.

 

[ropa]

Hi,

nee, nee, ich meine schon /init.sh. Die wird innerhalb von
init.rc aufgerufen.

service init_sh /init.sh                                                                                                                                                                             
    user root                               
    oneshot

Fragt mich nicht wie das da hineinkommt. Ich war's nicht ;-)

Und /data/etc/rc.d ist mir auch recht. Eigentlich waere mir /etc/rc.d am liebsten,
das waere noch naeher dran. Aber darueber koennen wir uns auslassen wenn wir
sonst nix mehr zu tun haben. Dann wird's aber sowieso langsam langweilig.


Viele Gruesse
ropa

ps.: Rainer, ich denke Deine Frage ist damit auch beantwortet ?

 

[Oma7144]

btw habe ich ausserdem die busybox gegen meine selbst compilierte ausgetauscht. Die hat jetzt so ziemlich alle Funktionen drin.

Kannst du die bitte mal zur Verfügung stellen und den Installationsweg beschreiben? Danke!

 

[fluxflux]

@ ropa

Woher kommt die init.sh? Die ist in der boot.img beim Loox standardmäßig sicher nicht drin ...

Thomas.

 

[ropa]

Hi,

klar, kein Problem.

Die orginal busybox aus dem boot.img habe ich einfach in dem ausgepackten boot.img ersetzt. Als Tools habe ich die benutzt die in dem Thread "cRoms für den Odys Loox/Xpress mit suRoot und ext3/RW/FullRoot" von PopEi angegeben sind also rkflashtool dann noch https://github.com/naobsd/rkutils und die perl-scripts von Rksp - Arctablet zum aus- und einpacken der Dateien in boot.img.

Die init.sh auf meinem System sieht so aus:

#!/busybox sh

if [ ! -e /data/sysrw/TAG ]; then
    /busybox mkdir /data/sysrw
        /busybox cp -r /sysro/* /data/sysrw/
        /busybox touch /data/sysrw/TAG
        reboot
fi

/busybox echo "ABC" > /data/WENDAL

# if user init.sh
if [ -x /data/init.sh ]
then
        /busybox sh /data/init.sh
fi

Hat da vielleicht wendal was mit zu tun. Frag' mich nicht wie das da hin kommt, ich habe erst vorgestern zum 1.mal ein boot.img gebastelt und
da habe ich das genommen was auf dem loox war.

Ich moechte das aber im Moment nicht untersuchen. Ich nutze die Zeit lieber um mit meiner eigenen Idee weiterzukommen, zumal es ja gut funktioniert und ich keinen Grund sehe etwas daran zu drehen.

Viele Gruesse
ropa

 

[fluxflux]

Das kann dann nur die Version sein, die die system.img (cramfs) auf /data gespiegelt hat und so schreibbar macht ...

Aber danke für die Aufklärung. Man könnte dann ja die /data/init.sh auch direkt in der init.rc aufrufen? Richtig? Also ohne den Umweg über die /init.sh!? Man bräuchte dann nur eine /busybox, die im boot.img bisher auch nicht enthalten ist, wenn ich mich recht erinnere ...

Thomas.

 

[ropa]

Hi fluxflux,

direkt aus init.rc ginge auch. Aber die busybox hat damit nichts zu tun. Die habe ich nur dabei, weil inotifyd in der orginalen busybox fehlt.

So, grundsaetzlich geht das was ich vorhabe schon einmal, also inotify ist im kernel. Ich habe aber gerade gesehen, dass es in Android einen ueventd gibt, der darin die Rolle der udev-rules uebernimmt. Ich muss mir das einmal naeher ansehen. Es geht wahrscheinlich ueber diesen Weg auch ohne viele Aenderungen.

Verdammt, ich weis einfach noch zu wenig von Android.

 

[fluxflux]

Hi fluxflux,

direkt aus init.rc ginge auch. Aber die busybox hat damit nichts zu tun. Die habe ich nur dabei, weil inotifyd in der orginalen busybox fehlt.

Wenn die init.sh den Befehl /busybox sh aufruft, dann muss doch die busybox im Rootverzeichnis der boot.img liegen ... oder was sehe ich hier falsch?

Hat natürlich nichts mit deiner hier geposteten busybox zu tun, das ist schon klar.

Kannst du mal posten, was in deiner boot.img alles drin ist?

Danke,

Thomas.

 

[ropa]

Hi fluxflux,

Du siehst nichts falsch. Da ist im Normalfall schon eine busybox drin. Das habe ich dann falsch verstanden.

root@linux-5hu4:/home/Projects/Loox/images/BOOT-20120202_1713> find
.
./init.rk29board.rc
./sbin
./sbin/ueventd
./sbin/adbd
./init.rc
./sys
./init
./init.sh
./ueventd.goldfish.rc
./su
./dev
./busybox
./default.prop
./ueventd.rk29board.rc
./initlogo.rle
./data
./proc
./init.goldfish.rc
./ueventd.rc
./init_battery.sh
./rk29xxnand_ko.ko

zu ueventd:
"ueventd.rc is the android equvivalent of udev rules, but it scope is very limited. It mentions the permissions and the owner of the newly added file in the system. /ueventd.rc is read by the init deamon itself, and it listens on the netlink socket for events from the kernel. This is similar to how udev deamon listens for the events from the kernel."

Ist also doch nicht das Richtige. Ich mache weiter mit inotify.


Viele Gruesse
ropa