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 :-)
Angehängte Dateien:
-
RTC.png
59 KB
Wozu benötigst du /dev/rtc? Im aktuellen Debian/amd64 ist das auch nicht drin, hwclock funktioniert aber trotzdem.
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 ;-)
Deine RTC geht über I²C, oder? Ist die in der Board Initialisierung irgendwo erwähnt?
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...
Ich glaube Ernst meint, dass es ein Altera-FPGA wäre ;) Mir sieht das aber nach einem ganz gewöhnlichen Atmel-ARM aus.
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"...
> hmmm... vielleicht ist der nur "leise"?
Möglich. Dann sollte der Bus aber wenigstens in /sys/bus/i2c/devices
auftauchen.
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.
Ich vermute du meinst make linux26-menuconfig ? hmmh. Ich hab mal beide angehängt.
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.
määäh und wie bekommt man raus, welche Kombination an Kreuzen man setzen muss? ist das nen Scherz? :-O
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 ;)
korrektur: es geht nur bis tty63. steht ja auch ganz oben. sry. wenn man mal die /dev-Ordner vergleicht: Debian 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 Original Busybox: audio hda7 loop0 ptmx sndstat ttyp7 audio1 hda8 loop1 pts tty ttyp8 console hda9 mem ptyp0 tty0 ttyp9 dsp hdb mmcblk0 ptyp1 tty1 ttyS0 dsp1 hdb1 mmcblk0p1 ptyp2 tty2 ttyS1 fb0 hdb10 mmcblk0p2 ptyp3 tty3 ttyS2 fb1 hdb11 mmcblk0p3 ptyp4 tty4 ttyS3 fb2 hdb12 mtd0 ptyp5 tty5 ttyUS0 fb3 hdb13 mtd1 ptyp6 tty6 ttyUS1 fusion hdb14 mtd2 ptyp7 tty7 ttyUS2 hda hdb2 mtd3 ptyp8 ttygserial ttyUS3 hda1 hdb3 mtd4 ptyp9 ttyp0 ttyUSB0 hda10 hdb4 mtd5 ram ttyP0 ttyUSB1 hda11 hdb5 mtdblock0 ram0 ttyp1 ttyUSB2 hda12 hdb6 mtdblock1 ram1 ttyP1 ttyUSB3 hda13 hdb7 mtdblock2 ram2 ttyp2 ubi0 hda14 hdb8 mtdblock3 ram3 ttyP2 ubi_ctrl hda2 hdb9 mtdblock4 random ttyp3 urandom hda3 input mtdblock5 rtc ttyP3 zero hda4 kmem net rtc0 ttyp4 hda5 lcd null shm ttyp5 hda6 log psaux snd ttyp6 Dem debian fehlt so einiges. Und das bei gleichem Kernel. Sicher kein Debian-Problem?
> 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.
> i2cset: meckert, weil es im /dev kein i2c findet.
Mit1 | modprobe i2c-dev |
bekommst du dein i2c-device, aber der richtige Treiber dürfte immer noch fehlen.
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.
Also ich habe es auch nochmal doppelt überprüft: ich finde da keinen Weiteren eintrag, der etwas mit den Modulen zu tun hat hmmg
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.