Hallo liebe Liebenden^^
ich habe heute wieder ein neues Problem, mit dem ich nicht wirklich
zurecht komme, da google mir sehr spezifisches ausspuckt - und zwar für
x(&, während ich auf einem ARM (armel) arbeite.
Ich habe den Linux Kernel 2.6.33.2 und dort I2C als festen Modul mit
einkonfiguriert.
Ebenso die RTC und dort meinen RTC-Chip ausgewählt. Zusetzlich noch die
Konfigurationen wie im Anhang - m.M.n wird dort beschrieben wie der
Kernel die RTC einbindet. hmmh.
Passiert aber nicht, warum? Muss man eine Datei editieren, damit die RTC
gefunden wird?
hwclock --debug ist nutzlos. Sagt mir auch nur das offensichtliche:
/dev/rtc fehlt.
Hier meine Aufglistung von dev (ls):
MAKEDEV null stderr tty26 tty47 ttyS1 usbmon0
bus ppp stdin tty27 tty48 ttyS2 usbmon1
char psaux stdout tty28 tty49 ttyS3 usbmon2
console ptmx tty tty29 tty5 ttyp0 vcs
cpu_dma_latency pts tty0 tty3 tty50 ttyp1 vcs1
fb0 ptyp0 tty1 tty30 tty51 ttyp2 vcs2
fd ptyp1 tty10 tty31 tty52 ttyp3 vcs3
full ptyp2 tty11 tty32 tty53 ttyp4 vcs4
initctl ptyp3 tty12 tty33 tty54 ttyp5 vcs5
input ptyp4 tty13 tty34 tty55 ttyp6 vcs6
kmem ptyp5 tty14 tty35 tty56 ttyp7 vcsa
kmsg ptyp6 tty15 tty36 tty57 ttyp8 vcsa1
loop0 ptyp7 tty16 tty37 tty58 ttyp9 vcsa2
mem ptyp8 tty17 tty38 tty59 ttypa vcsa3
mtd0 ptyp9 tty18 tty39 tty6 ttypb vcsa4
mtd0ro ptypa tty19 tty4 tty60 ttypc vcsa5
mtd1 ptypb tty2 tty40 tty61 ttypd vcsa6
mtd1ro ptypc tty20 tty41 tty62 ttype zero
mtd2 ptypd tty21 tty42 tty63 ttypf
mtd2ro ptype tty22 tty43 tty7 ubi_ctrl
net ptypf tty23 tty44 tty8 urandom
network_latency random tty24 tty45 tty9 usbdev1.1
network_throughput shm tty25 tty46 ttyS0 usbdev2.1
..es fehlt auch zeug wie GPIO, I2C, SPI usw. keine ahnung, ob ich da was
falsches erwarte.. aber hmmh.
im root-verzeichnis: find . -name "*rtc*" findet auch nichts relevantes:
./usr/share/man/man8/rtcwake.8.gz
./usr/share/mime/application/x-kexiproject-shortcut.xml
./usr/sbin/rtcwake
./sys/bus/i2c/drivers/rtc-m41t80 <<---- treiber da, oder?
./sys/class/rtc <<----------- hmmmh
ich würde mich riesig über hilfe freuen :-)
es existert wohl eine hw-clock-Option --directisa, dann kommt man ohne
/dev/rtc aus.
allerdings klingt ..ISA nach sehr x86-spezifischer Magie... und ich habe
die option bis jetzt auch nur für x86 im Einsatz gefunden.
und bevor ich mir irgendwelche config-files verwurste, frag ich lieber
nach.
..unabhängig davon ist auch irgendwie so: man sagt es dem kernel, wie er
sich verhalten soll, und nix passiert...
Indess sthts hier auch konkret: das mit dem directisa ist nur für
gewisse platformen zu gebrauchen.
http://linux.die.net/man/8/hwclock
hmmmmmh. Wo bekommt linux eigentlich seine dev-Device-Auflistung her?
:-O
hmmh, danke.
Laut
http://www.linuxfromscratch.org/lfs/view/development/chapter07/udev.html>Drivers that have been compiled into the kernel directly register their >objects
with a sysfs (devtmpfs internally) as they are detected by the >kernel.
Aaalso sollte es automatisch passieren, wenn man das fest
eionkompiliert, so wie ich es tue...
aber:
>7.4.3.6. Udev does not create a device>Further text assumes that the driver is built statically into the kernel>or already loaded as a module, and that you have already checked that>Udev doesn't create a misnamed device.> ... Create a static device node in /lib/udev/devices ...
Was ist ein "device node" :-/ Und wie soll das helfen, zu sagen, das da
ein RTC-Chip am I2C hängt??
ok, ich bin nicht faul, aber bzgl Linux extrem schwer von begriff:
natürlich suche ich weiter per google.
eine suche nach "/lib/udev/devices" hat mich auf "mknod" gestupst.
Eine Suche danach brachte mich auf
http://www.lanana.org/docs/device-list/devices-2.6+.txt
So. Dort drin ist sogar /dev/rtc zu finden!! (unter Non-serial mice,
misc features)
Aber hilf mir Gott, beim zusammenstellen der Kommandozeile -.-
sry, bin völlig aufgeschmissen :-(
was sagt mit "10 char 135"
-> mknod /dev/rtc c 10 135 ?????????????????
-> mknod /lib/udev/devices/rtc c 10 135 ?????????????????
und wieso soll das danach gehen??
denkt bei opensource eigentlich auch mal iiiirgendjeamnd an die
anwender, wie nen leben abseits von linux haben -.-
10 (Major) und die 135 (Minor) sind magische Zahlen, die mit den
Major/Minor-Nummern im Treiber übereinstimmen müssen. Allein darüber
läuft die Verlinkung, du kannst auch ein "mknod /dev/leberwurst c 10
135" machen, und hast dann hinter leberwurst deinen RTC-Treiber.
"Früher" war /dev statisch, d.h. irgendjemand hat bei der Installation
schon die diversen mknods für alle relevanten Devices gemacht. Deswegen
war /dev auch so riesig, da war viel Zeug ohne dahinterliegenden Treiber
drin. Mit Hotplug wird das aber alles sehr mühsam, insb. auch dank USB,
weil viele Geräte auch ohne root ansprechbar sein sollen.
Inzwischen wird es dynamisch gemanaged (über udev), sodass das Laden des
Treibers an udev meldet, welche Devices es überhaupt gibt. Desweiteren
können über zusätzliche udev-Regeln auch Rechte gesetzt und
Firmware-Loader gestartet werden.
Wenn kein udev läuft (zB. auf Embeddedsystemen) muss man weiterhin mknod
machen. Mit udev ist es nicht notwendig und wäre auch ein Zeichen dafür,
dass das Gerät auch im Kernel nicht vorhanden ist.
Was sagt den dmesg zum Thema rtc? Normalerweise sollte es da auftauchen,
wenn der generische RTC-Treiber und der Chip-Treiber sich gefunden
haben, am PC zB.
rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
Nachtrag: auf dem PC (>2.6.3x) ist Major/Minor inzwischen 254,0 (bzw.
1... für weitere RTCs*). Ich nehme mal stark an, dass das auf dem ARM
dann auch so sein sollte.
*) Die Verschiebung von 10,135 auf 254,x kommt vermutlich daher, dass es
inzwischen mehrere RTCs geben kann.
Hallo, danke für deine Rückmeldung :-)
ich habe dmesg einfach mal in eine Datei umgeleitet -> Anhang.
von RTC steht erstmal nichts drin. außer, dass keine da ist.
Da du von der geschichte scheinbar ahnung hast, hast du mich leider noch
mehr verunsichert (die geänderten werte), ebenso dass ich vermute, dass
das problem noch tiefer leigt, da etwas mit der RTC in der Ausschrift
erwartet wird, aber nix zu finden ist.
I2C meldet sich ja auch an, so wie ich es erwarte. (auch wenns erstmal
nicht in /dev auftaucht)
Kannst du eine konkrete Kommandozeile erschaffen, die Frieden auf der
Welt schafft, Hunger und Religion bekämpft, Zwangabitur einführt und die
Weltformel findet?
...zumindest bzgl der rtc ;-)
Hmm, da steht garnix von deiner RTC drinnen.
Ist die auch sicher im Device-Tree / Platform init file mit angegeben?
Und wegen der Welformel:
das geht per "cat /dev/random | egrep -C 10 ......".
Statt "....." musst du die Frage auf die Antwort 42 einsetzen.
Für I2C in /dev braucht es einen Extra-Treiber (CONFIG_I2C_CHARDEF),
dann gehen auch so hilfreiche Tools wie i2cset/i2cdump. Allerdings sehen
die Kernelmeldungen auch so aus, als gäbe es gar keinen
Low-Level-I2C-Treiber. Keine Ahnung, was dein ARM da so braucht, sollte
sich aber in "I2C system bus drivers" und folgende finden lassen.
Grundsätzlich sind viele Treiber in Linux auf High-Level und Low-Level
aufgeteilt. Der Low-Level-Kram macht die eigentliche
HW-Suche/Initialisierung/HW-IO. Der High-Level kümmert sich um die
Verteilung im Kernel und den Userspace. Kann man zwar laden, hilft aber
ohne die HW-Treiber nix...
SAM9G45 :-)also muss ich nicht besorfgt sein, dass ich das das erste mal
höre? :-O
Andernfalls: irgendwas muss es ja sein. die RTC ist fest einkompiliert
und taucht sowas von gar nicht auf... vllt ist da ja wirklich irgendwas
schief :-/
Georg A. schrieb:> Mir sieht das> aber nach einem ganz gewöhnlichen Atmel-ARM aus.
Jup. Auch da kannst du mit device-tree booten.
schau mal nach /proc/device-tree, device-tree-files im uboot etc.
Oldschool geht das über das passende File in
<kernel-source>/arch/arm/mach-<was>/board_xyz.c.
LinuxDAU schrieb:> was was was? Wo, wie?
I2C hat kein Plug'n'Play. Der Kernel muss irgendwoher wissen, welchen
I2C-Bus an welcher Adresse welchen Chip angeschlossen hat.
Das geht entweder beim Booten hardgecoded im board-file, beim Booten
über ein "device-tree"-Config-File, das vom Bootloader vorgeladen wird,
oder später vielleicht irgendwie module-load-optionen? oder per
sysfs-tricksereien?
Ja, es fehlt der I2C-HW-Treiber, das erklärt dann auch alles. Im Log
gibt es jedenfalls keine Spur davon...
Ich hab mal schnell über die Sourcen gegrept, du brauchst wohl den
I2C_AT91-Treiber, damit sich da was überhaupt rührt.
Georg A. schrieb:> Ja, es fehlt der I2C-HW-Treiber, das erklärt dann auch alles. Im Log> gibt es jedenfalls keine Spur davon...
hmmm... vielleicht ist der nur "leise"?
grob mal die verfügbaren Boards in linux-3.5.0/arch/arm/mach-at91/
gecheckt, fast alle definieren da hart einen i2c-Bus.
(Ja, ich weiß, falsche Kernel-Version. Aber die hatte ich grad
ausgepackt rumliegen)
Ausnahme ist unter anderem "board-dt.c" für Device-Tree-Konfigurierte
AT91-Boards.
Evtl. kann der LinuxDAU mal sein .config-File anhängen?
oder mal ein "find /sys/bus/i2c/" ausführen?
Eigentlich müsste sowas hier reichen, um die RTC nachträglich zu
"aktivieren"
echo "rtc-m41t80 0x42" > /sys/bus/i2c/devices/i2c-9/new_device
Statt "0x42" die richtige I²C-Adresse.
statt "i2c-9" den richtigen Bus.
statt "rtc-m41t80" vielleicht! nur "m41t80"...
Gerne komm ich dem nach:
Zuerst das mit dem I2C: in meiner angehängten datei findet sich ein
"i2c /dev entries driver"
direkt dort wo auch die LEDs usw angemeldet werden. Die sind auch Teil
meines Entwicklungsboards - demnach würde ich behaupten: alles was mein
Board kann, ist auch prinzipiell vorhanden.
Ich habe die I2C-Konfig mal per Screenshot dokumentiert.
das .config-File hab ich auch angehängt - ob das richtige ist???
ich rufe immer "make linux26-menuconfig" auf.
I2C_1: I2C-Support angekreuzt. -> I2C_2 untermenü
I2C_2: I2C-Device interface -> I2C_3 untermenü davon
Tja.. und ob ihr was mit dem Config-File anfangen könnt?? Fänd ich ja
krass, wenn^^ Vllt ist es auch das falsche - sry.
So. Zum nächsten:
root@debian:~# find /sys/bus/i2c/ <<----------
/sys/bus/i2c/
/sys/bus/i2c/uevent
/sys/bus/i2c/devices
/sys/bus/i2c/drivers
/sys/bus/i2c/drivers/dummy
/sys/bus/i2c/drivers/dummy/uevent
/sys/bus/i2c/drivers/dummy/unbind
/sys/bus/i2c/drivers/dummy/bind
/sys/bus/i2c/drivers/rtc-m41t80
/sys/bus/i2c/drivers/rtc-m41t80/uevent
/sys/bus/i2c/drivers/rtc-m41t80/unbind
/sys/bus/i2c/drivers/rtc-m41t80/bind
/sys/bus/i2c/drivers/dev_driver
/sys/bus/i2c/drivers/dev_driver/uevent
/sys/bus/i2c/drivers/dev_driver/unbind
/sys/bus/i2c/drivers/dev_driver/bind
/sys/bus/i2c/drivers_probe
/sys/bus/i2c/drivers_autoprobe
eventuell hilft diese Liste, die Zeile
echo "rtc-m41t80 0x42" > /sys/bus/i2c/devices/i2c-9/new_device
zu konkretisieren?
LinuxDAU schrieb:> das .config-File hab ich auch angehängt - ob das richtige ist???
Schaut aus wie das Buildroot-config-file. Der Kernel sollte auch eins
haben. Notfalls im "make menuconfig" in ein alternatives File speichern.
Wenn meine Buildroot ihre Dateien final zusammenstellt ist mir folgende
Datei ins auge gefallen: (Anhang) dort ist immerhin die rtc vermerkt.
Ist das eine Datei die ich dem Debian irgendwie geben sollte? bis jetzt
habe ich nur den Kernel genutzt, nix anderes. (Debian ringsrum
installiert)
TWI0 ist nicht bitbanging, da fehlt definitiv der i2c_at91-Treiber in
der Liste. Vermutlich wird der durch ein fehlendes Häckchen bei "General
Setup/Prompt for development and/or incomplete code/drivers" nicht
angezeigt, selbst in der 3.2er-Kconfig steht er nämlich mit
" depends on ARCH_AT91 && EXPERIMENTAL && BROKEN" drin.
Experimental ist Ok und nicht ungewöhnlich, aber das mit Broken scheint
Absicht zu sein:
http://www.at91.com/forum/viewtopic.php/f,12/t,4665/
D.h. du musst die TWI*-Pins als GPIO-Pins nutzen und das auch dem
I2C-Bitbanging-Treiber mitteilen. Habe ich selber noch nie gemacht, hier
steht wohl was dazu:
https://www.kernel.org/doc/Documentation/gpio.txt
Nachtrag: Zum Spass kann man ja das BROKEN aus
drivers/i2c/busses/KConfig rausmachen, dann sollte der Treiber
auftauchen..
Also ich habe mir den Text durchgelesen: dort steht was von
I2C-Controllern, die die GPIOs erweitern, aber nicht andersrum :-(
Das mit dem Bitbanging, klingt erstmal ok, aber die Frage ist echt wie??
Müsste sowas nicht in meiner geposteten Devices.txt zu finden sein?
Ich weiss nicht, wie/wo man die Pins für SDA und SCL definiert. Ich hab
das noch nie gebraucht... Sollte sich aber doch googeln lassen ;)
Edit: Einige sagen, dass das Entfernen von BROKEN (und dann auch dem
Bitnbanging-Treiber) reicht und der native Treiber bei ihnen läuft.
Ansonsten scheint das Bitbanging-I2C über das Board-Setup konfiguriert
zu werden (at91*_devices.c). Evtl. ist das falsche Board ausgewählt...
Hallo, nochmal.
Um ehrlich zu sein, bin ich kein stück weiter gekommen.
Das Problem: I2C ist eigentlich vorhanden.
/sys/class/ bietet eigentlich alles vorhandene an.
root@debian:/sys/class# ls
backlight gpio i2c-dev mem net scsi_host
usb_device
bdi graphics input misc rtc spi_master
usbmon
dma hwmon leds mmc_host scsi_device tty vc
firmware i2c-adapter mdio_bus mtd scsi_disk ubi
vtconsole
i2c-adapter, i2c-dev, rtc: alles da.
Ich würde damit gerne mal die Pins zum wackeln bekommen.
interesse wäre auch hinsichtlich der SPI und anderen UARTs vorhanden.
muss man dafür zwangsläufig programmieren?
GPIO pins kann ich per Konsole beinflussen, aaaber der rest? hmmh.
irgendwie inkonsistent. Ich finde leider nur programmieranleitungen...
aber wenn man mal was über i2c aussucken könnte.. kann man auch mal das
Oszi ranhalten.
Das problem ist eigentlich: normalerweise müsste es funktionieren. Der
Kernel funktioneirt im Original mit der RTC und der Busybox. (soabld das
modul geladen ist - ich habs fest einkompiliert) Eigentlich ist es nur
so, das debian keine Referenz auf die RTC im /dev-Ordner findet.
Deswegen finde ich die modifikation der .config-Datei etwas hardcore,
dafür dass das problem wohl eher im debian liegt, als im kernel. Ein
I2C-treiber wird mir den RTC-Eintrag im /dev-Verzeichnis ja auch nicht
erstellen.....
In der Original Busybox-Distri ist im /dev ordner die rtc und die rtc0
vorhanden. dei frage ist, wie man das im debian auch so hinbekommt.
hmmh. linux -.-
> muss man dafür zwangsläufig programmieren?
Für I2C gibts die oben angesprochenen Tools (i2cset/i2cdump). Denen gibt
man das I2C-Bus-Device und passende Kommandos, dann kann man aus dem
Userspace rumstochern.
> ich habs fest einkompiliert
Hm, es gibt Treiber, die haben das nicht so gern. Versuchs mal als
Module...
> das debian keine Referenz auf die RTC im /dev-Ordner findet.
Wenn das Device da nicht auftaucht, ist es kein Debian-Problem.
und wozu gibts dann programme wie mknod, vor dessen kommandozeile man
die hände hochreist und schreiend davonrennt, weil man nicht genau weiß,
was man eingeben muss? scheint ja ein tool zu sein, um fehlerhaftes
Debian-Verhalten im dev-verzeichnis zu beheben. hmmh
i2cset: meckert, weil es im /dev kein i2c findet.
man eh. es ist doch alles vorhanden. In /sys/class/ ist alles da. Dieser
bekiffte /dev-ordner, wozu braucht man überhaupt -.-
Ich kann auch im /sys/class/gpio ordner auf die Pins zugreifen. Über
/dev geht das nicht, weil es dort auch keine GPIOs gibt. Das hat doch
system, dass im /dev absolut KEINE peripherie auftaucht.
..hauptsache 70x tty0..tty69 (echt jetzt)
mknod gibts seit Unix-Uhrschleim, gehört zum Basisystem wie rm, ls & Co
und es dient u.a. zum Anlegen von Devices, wenn es keinen Automatismus
ala udev gibt. Man kann damit aber auch als User Named Pipes (FIFOs)
erzeugen.
Nur weil ein Tool existiert, heisst es nicht, dass es zwingend notwendig
ist...
Ungeduldiger Padawan, noch viel lernen du musst ;)
> i2cset: meckert, weil es im /dev kein i2c findet.
Wenn im /sys/bus/i2c/devices keinen Bus/Adapter (i2c-*) gibt, ist das
kein Wunder. Es hängt immer noch ganz am Anfang.
> Dem debian fehlt so einiges. Und das bei gleichem Kernel.> Sicher kein Debian-Problem?
Nein. Der hd*-Kram wäre zB. für IDE-Platten. Debian nutzt udev/Hotplug,
der IDE-Treiber findet keine IDE-Platten (oder wird gar nicht geladen),
damit gibts kein udev-Callback, damit auch kein hd*. Das
Busybox-Sparsystem legt das Zeug alles prophylaktisch per mknod an,
selbst wenn kein Device dahinter ist.
>Wenn im /sys/bus/i2c/devices keinen Bus/Adapter (i2c-*) gibt, ist das>kein Wunder.
korrekt, der ordner ist leer.
Allerdings ist der Treiber doch vorhanden - auch wenns nur eine
GPIO-Emulation ist.
Ich werde das heute abend nochmal mit modulen kompilieren. vielleicht
ist ja was dran, dass das nicht fest einkompiliert werden darf.
ich freue mich jetzt schon alle permutationen der kommandozeile planlos
auszuprobieren: http://linux.die.net/man/8/modprobe
AHA. hoch intuitiv, unglaublich klar für jedermann. mal davon abgesehen:
wie soll das modul heißen? haben die entstehenden module irgendwelche
namen, die einduetig sind? Wenn ja, sind die auch intuitiv?
Und: woher kommen die module -> sind die im kernel prinzipiell vorhanden
und nur nicht aktiv, oder muss ich neben dem Kernel einfach noch mehr
auf die SD-Karte kopieren: wenn ja was?? :-O Wie bekomm ich einen
Überlick welche dateien noch alle dazugehören?
...hat sicher was mit der "modules.dep"-Datei zu tun. ach herje. welch
rattenschwanz. wieder fehlerqeulle für unendliche googlesucherei im
vollkommenen wirrwar der distributionen und kryptischen antworten, die
man selbst wieder googeln muss, um die zu verstehen. das ganze mit einer
rekursionstiefe.. unaufhaltsame Zeitverschwendung, weil Open source so
anwenderfreundlich ist...
dividieren durch 0 macht mehr spaß. :'-(
Du wöhlst bei den Treibern Modul statt fest in den
Kernel (M statt Haken). Vorher liest du natürlich
für jeden Treiber den Text, den Help anzeigt, der
erläutert eventuelle Abhängigkeiten. Dann baust du den
Kernel, anschließend mit make modules die Module, installierst
diese mit make modules_install und rufst depmod -a auf. Alles
natürlich mit Root-Privilegien.
und landen die Module dann im Kernel (uImage) oder liegen die irgendwo
anders im erzeugen Flashimage, das das gesamte root-verzeichnis
beinhaltet...
das ist mir leider etwas unklar :-(
Wenn sie im Kernel landen würden, wären sie keine Module...
Die kommen ins Flashimage und sind da typischerweise in
/lib/modules/<Kernelversion> daheim. Falls zu Netzwerk/NFS/irgendeinen
anderen Speicher hast, kannst die Module (*.ko) aber auch da ablegen und
erstmal von Hand laden.
Und bevor du da weiterverzweifelst:
Module kann man mit insmod oder modprobe laden. insmod lädt exakt ein
einzelnes angegebenes File (insmod blub.ko). Falls Module Abhängigkeiten
haben (=Code aus anderen Modulen aufrufen), muss man mit denen anfangen,
die keine haben. Andernfalls kommen "Symbol undefined" Meldungen.
Typischerweise ist das erste immer das Modul des gesamten Subsystems,
der Rest registriert sich dann da.
modprobe macht das Laden von abhnängigen Modulen automatisch (da lädt
man quasi das unterste, zB. i2c_gpio, ohne .ko). Dazu muss aber vorher
depmod eine Datenbank aufgebaut haben und die Module in /lib/modules/...
liegen.
> unaufhaltsame Zeitverschwendung, weil Open source so> anwenderfreundlich ist...
Dass Linux auf Embedded einfach ist, hat keiner gesagt. Erst recht
nicht, wenn man nicht weiss, wie was in Linux allgemein so läuft. Du
darfst ja gern mal Windows auf deinem AT91 installieren...
Ansonsten verbuch das unter Erfahrung. Das ist das, womit man Geld
verdienen kann...
make modules_install
make modules
No rule to make target.... liegt wohl am Crosscompiling...
wo finde ich jetzt die module?
Der Ordner in dem die Module hätten landen müssen enhält aber bereits
die module. irgendwelche .ko dateien.
Problem: ich darf die nicht kopieren (selbst als root).
Oder vielleicht kann ich es auch wirklich nicht:
root@debian:/media# cp -rf test/lib/modules/*
d53a0c11-b552-40c4-85b5-454c38422096/lib/modules/
cp: reading
`test/lib/modules/2.6.33.2/kernel/drivers/usb/gadget/g_file_storage.ko':
Input/output error
cp: cannot access
`test/lib/modules/2.6.33.2/kernel/drivers/rtc/rtc-core.ko': Input/output
error
cp: cannot access
`test/lib/modules/2.6.33.2/kernel/drivers/rtc/rtc-m41t80.ko':
Input/output error
cp: reading `test/lib/modules/2.6.33.2/kernel/drivers/net/wireless':
Input/output error
cp: cannot access `test/lib/modules/2.6.33.2/kernel/drivers/spi':
Input/output error
cp: reading `test/lib/modules/2.6.33.2/kernel/drivers/video':
Input/output error
cp: reading `test/lib/modules/2.6.33.2/kernel/drivers/misc':
Input/output error
cp: cannot access `test/lib/modules/2.6.33.2/kernel/net': Input/output
error
cp: cannot access `test/lib/modules/2.6.33.2/modules.seriomap':
Input/output error
cp: cannot overwrite non-directory
`d53a0c11-b552-40c4-85b5-454c38422096/lib/modules/2.6.33.2/modules.alias
' with directory `test/lib/modules/2.6.33.2/modules.alias'
hmmmh. habs trotzdem azusprobiert:
modules.dep steht drin:
/lib/modules/2.6.33.2/kernel/drivers/i2c/i2c-dev.ko
versuche ich die existenz des moduls zu prüfen
cd /lib/modules/2.6.33.2/kernel/drivers/i2c
-> not a directory. wtf
Was soll das!?
Wie bekomm ich die komischen module auf mein system??
LinuxDAU schrieb:> make modules_install> make modules>> No rule to make target...
Dann hat config das Makefile nicht richtig erstellt. Hast du in
config Module-Support aktiviert?
ja, ist an.
ich habe aber auch gerade gemerkt: im original-Dateisystem, das mir
"make" erstellt, ist
lib/modules/2.6.33.2/kernel/drivers/i2c
auch kein Ordner.
muss das so sein? Ist das normal, ist das falsch?
..daher kommen auch die fehler beim kopieren der module....
määäh. wenigstens läuft bis jetzt alles genau so wie erwartet: gar
nicht.
ooups: ich habs auch grade beim erneuten durchlaufen von make gesehen:
der installiert die module selbständig.
mehere Zeilen "INSTAL modulename.ko"
Dei frage ist: wie bekommt man die module ins debian rein?
http://www.linuxquestions.org/questions/linux-newbie-8/manually-copying-kernel-modules-63828/
demnach muss man sich die module also selbst zusammenkopierenm wenn ich
das richtig verstehe.
In der Tat habe ich die .ko-Datei für z.B. die RTC im angegeben Pfad
gefunden.
Man könnte nun also ein script schreiben, das alle *.ko dateien auf die
SD-Karte kopiert öder händisch das ganze zusammensuchen.
Problem:
rein intuitiv würde ich den entsprechen treiber in den entsprechenden
Ordner legen. Also z.B. den i2c-dev.ko in
lib/modules/2.6.33.2/kernel/drivers/i2c
der Pfad ist aber kein ordner - also ist immernoch unklar, wie man die
module auf die karte bekommt. kann ich die module einfach irgendwohin
kopieren, und die moduled.dep mit den pfaden füllen? das wäre einfacher.
RTC.png
(59 KB)
