Linux Treiber bauen

[Tobias P. (hubertus)]

Hallo,
es geht zwar um Rmbedded Linux, aber da es nicht sehr embeddedspezifisch 
ist passts hier vielleicht besser.

Also, ich habe einen ARM Prozessor mit einem lauffähigen embedded Linux. 
Uart, Ethernet etc. geht. Diese Devices sind auch alle im Device Tree 
vermerkt und unter /dev habe ich entsprechende Devicefiles, z.B. für den 
Uart.

Am Prozessor ist noch ein kleiner FPGA dran, wo ich ein spezielles 
Device mit memory mapped IO synthetisiere. Jetzt muss ich natürlich, um 
das Ding aus Linux heraus ansprechen zu können, einen Treiber dafür 
haben.

Dazu ein paar Fragen:

Muss ich das "Spezialdevice" zwingend mit in den Device Tree aufnehmen?

Für das Ding brauche ich ja auch noch ein Device File unter /dev. Wer 
erzeugt das File?
Ich dachte eigentlich, den Treiber könnte ich als loadable Module bauen. 
Wenn das Device benutzt werden soll, dann wird das Modul geladen und 
irgend ein System call erzeugt mir das Device file? oder wie geht es 
richtig?
 ich lese zwar grade "Linux device driver development", aber irgendwie 
wird nicht sauber darauf eingegangen, woher das Device File kommt und 
wer das Modul für den Treiber lädt.

Dann - um auf die memory mapped IO Register des Device zugreifen zu 
können, rufe ich einfach ioremap() oder mmap() auf und mache den 
Memorybereich so zugreifbar? oder wie geht es richtig.
Danke & Gruss
Tobias

[Stephan (Gast)]

Hi
Lies mal was zum Thema "User Space Drivers". Vielleicht kannst Du auf 
einen echten Treiber verzichten.
Gruss
S.

[Till U. (tuhde)]

Tobias Plüss schrieb:

> Muss ich das "Spezialdevice" zwingend mit in den Device Tree aufnehmen?

Nein. Siehe Netzwerkdevices.

> Für das Ding brauche ich ja auch noch ein Device File unter /dev. Wer
> erzeugt das File?

Die Distribution oder Du oder udev.

> Ich dachte eigentlich, den Treiber könnte ich als loadable Module bauen.
> Wenn das Device benutzt werden soll, dann wird das Modul geladen und
> irgend ein System call erzeugt mir das Device file? oder wie geht es
> richtig?

Das Kernel Modul implementiert nur die Funktionalität des physikalischen 
Gerätes. Es registriert eine ( Major- und Minor- ) Device Nummer und 
wartet auf Arbeit. Der Rest sollte in Deinem Buch stehen.

Das Devicefile ist der Teil, auf den Benutzer mit ihren Berechtigungen 
über ioctl's oder File I/O zugreifen können. Das Devicefile greift auf 
eine bestimmte ( Major- und Minor- ) Device Nummer zu und stellt so die 
Verbindung zum Kernel Modul her.
Siehe auch: man mknod(1)

Alle Geräte, mit denen Benutzer direkt kommunizieren können sollen, 
brauchen ein Devicefile.

[Max (Gast)]

Ist das Zynq von Xilinx? Dort ist schon alles vorhanden, man 
kommuniziert mit fpga über /dev.

[Tobias P. (hubertus)]

Hallo zusammen,

> Lies mal was zum Thema "User Space Drivers". Vielleicht kannst Du auf

ja, das ist gut möglich dass das mit einem User Space Driver geht. Was 
ist das Kriterium hierfür?

> Ist das Zynq von Xilinx

nein, ist was anderes. Die Frage ist auch eher allgemein gemeint.


@Till
Also, verstehe ich das richtig:

Man lädt das Kernelmodul. Dieses registriert die beiden Nummern (Major 
und Minor). Zudem muss zuvor das Device File erstellt werden (oder aber 
man erstellt es beim Laden des Kernelmoduls automatisch, was auch noch 
nett wäre...) Dann gibts da noch eine Struktur, weiss den Namen nicht 
mehr genau auswendig, aber irgendwas mit ...ops - dort stehen 
Funktionspointer drin für open, read, write, ...
Wenn jetzt ein Devicefile mit File I/O geöffnet wird, schaut der Kernel, 
welche Major/Minor-Nummer dem Devicefile zugeordnet ist, und pickt sich 
das jenige Kernelmodul raus, welches ebendiese Nummern registriert hat. 
Über die Funktionspointer open, read, write, ... werden dann 
entsprechenden Callbackfunktionen aufgerufen. Richtig?

Weisst du ein gutes Beispiel, wo ich mir das ein wenig abgucken kann?

Oder kann ich den Beispielcode aus "Linux Device Driver Development" 
benutzen? Der dürfte zwar recht alt sein, weil er für Kernel 2.6x ist...


Gruss Tobias

[Till U. (tuhde)]

>> Lies mal was zum Thema "User Space Drivers". Vielleicht kannst Du auf
>
> ja, das ist gut möglich dass das mit einem User Space Driver geht. Was
> ist das Kriterium hierfür?

Gast Stephan hebt hier auf eine kleine Erleichterung ab. Im Kernel 
herrscht ein anderes Memory Mapping als im User Space. Wenn Du jetzt 
einen Kernel Treiber schreibst, mußt Du zwischen User Space und Kernel 
Space Memory konvertieren. Was Gast Stephan nicht berücksichtigt, ist, 
daß Dein Prozessor memory mapped auf Dein Gerät zugreift. Die genannte 
Erleichterung gilt aber nur für den Zugriff von Programmen auf das 
Device File. Nur hierbei ist bei einem User Space Treiber keine 
Umwandlung nötig.

Ansonsten enthält ein User Space Treiber 99% den gleichen Code, wie sein 
Bruder im Kernel und ist definitiv auch ein "echter" Treiber.

Gängige Praxis ist, einen User Space Treiber zu entwickeln und den dann 
ins Kernel zu portieren.

> @Till
> Also, verstehe ich das richtig:
>
> Man lädt das Kernelmodul. Dieses registriert die beiden Nummern (Major
> und Minor). Zudem muss zuvor das Device File erstellt werden

Ja, aber alt, für viele Systeme und Kernel aber noch aktuell.

> (oder aber man erstellt es beim Laden des Kernelmoduls automatisch, was > auch 
noch nett wäre...)

Dein Modul, kann / darf das nicht, es läuft im Kernelspace, da gibt es 
keine Filesystemfunktionen. Dafür ist aber udev da. Wenn Dein Modul 
lädt, besser gesagt, wenn es ein gültiges Gerät erkennt und dieses 
registriert, meldet es dem Kernel seine Daten. Das Kernel erzeugt dann 
ein Event für udev. udev erzeugt dann ( im Userspace ) anhand von Regeln 
in /etc/udev.d/ ein Devicefile und evtl. verschiedene Sym-Links darauf. 
Hierbei hast Du dann mit Major- und Minor- Nummern nichts mehr zu tun.

> Dann gibts da noch eine Struktur, weiss den Namen nicht
> mehr genau auswendig, aber irgendwas mit ...ops - dort stehen
> Funktionspointer drin für open, read, write, ...
> Wenn jetzt ein Devicefile mit File I/O geöffnet wird, schaut der Kernel,
> welche Major/Minor-Nummer dem Devicefile zugeordnet ist, und pickt sich
> das jenige Kernelmodul raus, welches ebendiese Nummern registriert hat.
> Über die Funktionspointer open, read, write, ... werden dann
> entsprechenden Callbackfunktionen aufgerufen. Richtig?

Ja. Nur die ioctl hast Du vergessen.
Du mußt Dich auch noch mit Device Klassen aus einander setzen. Dein 
Gerät wird vermutlich nichts wirklich Neues machen. Durch das 
einsortieren in eine vorhandene Klasse kannst Du Dir eine Menge Arbeit 
sparen.

> Weisst du ein gutes Beispiel, wo ich mir das ein wenig abgucken kann?

In den Kernel Sourcen gibt es mehrere Skeleton Treiber, die sollten Dir 
helfen.

> Oder kann ich den Beispielcode aus "Linux Device Driver Development"
> benutzen? Der dürfte zwar recht alt sein, weil er für Kernel 2.6x ist...

Kenn' ich nicht, sollte aber gehen. In 2.6 war udev schon drin'.

[Hans Ulli K. (Gast)]

Tobias Plüss schrieb:

Hallo Tobias ;-)

>
> Am Prozessor ist noch ein kleiner FPGA dran, wo ich ein spezielles
> Device mit memory mapped IO synthetisiere. Jetzt muss ich natürlich, um
> das Ding aus Linux heraus ansprechen zu können, einen Treiber dafür
> haben.
>
> Dazu ein paar Fragen:
>
> Muss ich das "Spezialdevice" zwingend mit in den Device Tree aufnehmen?

Wenn du es als Device im Userland anspfrechen willst jat.

>
> Für das Ding brauche ich ja auch noch ein Device File unter /dev. Wer
> erzeugt das File?

In Prinzip dein Treiber beim "allozieren" des Deivces

> Ich dachte eigentlich, den Treiber könnte ich als loadable Module bauen.
> Wenn das Device benutzt werden soll, dann wird das Modul geladen und
> irgend ein System call erzeugt mir das Device file? oder wie geht es
> richtig?

Die Frage ist erstmal was für ein Device Type dein FPGA darstellen kann.
Block oder Char Device.
Das bezieht sich nur auf den Datentransport.
Also einzelne Bytes oder in Block zu z.B. 512 Bytes (aka Floppy HDD),
Um Kommandos an dein Device zu geben gibt es ioctl's

>  ich lese zwar grade "Linux device driver development", aber irgendwie
> wird nicht sauber darauf eingegangen, woher das Device File kommt und
> wer das Modul für den Treiber lädt.
>

Düfte irgend wo in den Sourcen zu finden.
Aber erstmal die obige Frage beantworten Block oder Char.


> Dann - um auf die memory mapped IO Register des Device zugreifen zu
> können, rufe ich einfach ioremap() oder mmap() auf und mache den
> Memorybereich so zugreifbar? oder wie geht es richtig.

ioremap ist eine Kernelfunktion um dein Device für den Kernel vom 
physikalischen in den virtuellen Bereich zu mappen. Weil du nur per 
"virtueller" Adresse auf dein Device zugreifst.

mmap () ist eine Kernel/Userland Funktion um sagen wir das unnnötige 
kopieren von Daten zu verhindern.


> Danke & Gruss
> Tobias

[Tobias P. (hubertus)]

Hallo Ulli und alle anderen,

so ich habe dank euren Infos die richtigen Stichworte bei Google 
eingeben können und bin nun auf folgendes gestossen:

http://hg.berlios.de/repos/kedr/file/b0f4d9d02d35/sources/examples/sample_target/cfake.c

Der Code sieht in meinen Augen eigentlich nicht soo schlecht aus. Ich 
habe ihn ein wenig modifiziert, und in den open / read usw. 
Callbackfunktionen einfach entsprechende printk() Aufrufe eingebaut und 
das Ding auf meinem PC compiliert. Nach einer anfänglichen kernel panic, 
weil ich irgendwo einen Pointer noch verbogen hatte, hats beim zweiten 
mal nun geklappt:

mit insmod test.ko wird das Modul geladen, und ein ls /dev bringt mir 
ein cfake0 Devicefile. Mit cat /var/log/syslog | grep cfake sehe ich 
meinen Text beim Open-Aufruf :-) Danach habe ich noch mit einem kleinen 
Bastel-C-Programm das Device File mit open() geöffnet, ein paar Bytes 
rein geschrieben und wieder zugemacht - konnte man alles im syslog 
verfolgen. Das Modul scheint also zu funktionieren. Und - besonders toll 
- mit rmmod test.ko verschwindet auch das Device File wieder und es wird 
sauber aufgeräumt.

Super! Das Modul scheint also so grundsätzlich mal zu funktionieren.

Jetzt muss ich mir nur noch überlegen, ob mein Device was ich 
hardwaremässig anspreche ein Block- oder Chardevice ist. Also, es hat 
ein paar Memory Mapped Register, eigentlich interessieren mich nur die. 
Kann ich mir also die Read / Write Funktionen sparen und nur ioctl 
implementieren? Ich dachte mir, mit ioctl könnte ich dann die 
Registernummern und die zu schreibenden Werte übergeben. So wie hier:
http://www.linuxforu.com/2011/08/io-control-in-linux/

Was meint ihr?

Gruss

[Hans Ulli K. (Gast)]

Welche Mengen an Daten werden geschrieben/gelesen ??

Mein "Framework" ohne die HW zu kennen.

mknod cfake c 240 0

f = open("/dev/cfake", O_RDWR);
ioctl(f, CFAKE_FUNC1)
write(f, buffer, 100)

Um deinen FPGA zu "programmieren"

[Georg A. (georga)]

Die Sache mit den Userspace-Treibern geht leider vernünftig nur bei x86, 
weil da mmap auf /dev/mem auch für den PCI/IO/Peripheriebereich geht. 
Bei ARM-Linux geht das nicht. Hab deswegen für ödes LED-Geblinke über 
GPIO extra einen Treiber schreiben müssen...

> Kann ich mir also die Read / Write Funktionen sparen und nur ioctl
> implementieren?

Sicher. read/write ist für viele Sachen gar tauglich.

[Tobias P. (hubertus)]

@Georg
was meinst du mit "gar tauglich" ? :-)


Ich habe mal den Code ein wenig aufgeräumt und das was ich nicht brauche 
raus genommen. So sieht er jetzt aus:

#include <linux/version.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/fs.h>
#include <linux/errno.h>
#include <linux/err.h>
#include <linux/cdev.h>
#include <linux/device.h>
#include <linux/mutex.h>
#include <asm/uaccess.h>



#define CFAKE_DEVICE_NAME "cfake"

struct cfake_device
{
  int major;
  dev_t devnbr;
  static struct class *class = NULL;
  struct cdev cdev;
};

static struct cfake_device* this_device = NULL;

static int
cfake_open(struct inode *inode, struct file *filp)
{
  unsigned int mj = imajor(inode);
  unsigned int mn = iminor(inode);
  struct cfake_device *dev = NULL;

  if((mj != this_device->major) || (mn < 0) || (mn > 1))
  {
    /* no such device */
    return -ENODEV;
  }

  /* store a pointer to struct cfake_dev here for other methods */
  filp->private_data = this_device; 

  if (inode->i_cdev != &this_device->cdev)
  {
    /* no such device */
    return -ENODEV;
  }

#if 0
  /* if opened the 1st time, allocate the buffer */
  if (dev->data == NULL)
  {

    dev->data = (unsigned char*)kzalloc(dev->buffer_size, GFP_KERNEL);

    if (dev->data == NULL)

    {

      printk(KERN_WARNING "[target] open(): out of memory\n");

      return -ENOMEM;

    }

  }
#endif
  return 0;
}

static int
cfake_release(struct inode *inode, struct file *fp)
{
  return 0;
}

static ssize_t
cfake_read(struct file *filp, char __user *buf, size_t count, loff_t *f_pos)
{
  return 0;
}

static ssize_t
cfake_write(struct file *filp, const char __user *buf, size_t count, loff_t *f_pos)
{
  return count;
}

static loff_t
cfake_llseek(struct file *filp, loff_t off, int whence)
{
  return 0;
}

static struct file_operations cfake_fops = {
  .owner = THIS_MODULE,
  .read = cfake_read,
  .write = cfake_write,
  .open = cfake_open,
  .release = cfake_release,
  .llseek = cfake_llseek,
};

static int __init
cfake_init_module(void)
{
  int err = 0;
  struct device* node;
  
  /* allocate memory for storing the internal variables */
  this_device =
    (struct cfake_device*)kzalloc(sizeof(struct cfake_device), GFP_KERNEL);

  /* proceed only if memory could be allocated */
  if(this_device != NULL) {
    /* allocate a character device */
    err = alloc_chrdev_region(&this_device->devnbr, 0, 1, CFAKE_DEVICE_NAME);
    if(err < 0) {
      goto memfree;
    }
    
    /* create a device class */
    this_device->class = class_create(THIS_MODULE, CFAKE_DEVICE_NAME);
    if(IS_ERR(this_device->class)) {
      err = PTR_ERR(this_device->class);
      goto unregister;
    }
    
    /* initialise the character device */
    cdev_init(&this_device->cdev, &cfake_fops);
    this_device->cdev.owner = THIS_MODULE;
    
    /* add the character device */
    err = cdev_add(&this_device->cdev, this_device->devnbr, 1);
    if(err) {
      goto classdestroy;
    }
    
    /* create a device node of this class */
    node =
      device_create(this_device->class, NULL,
      this_device->devnbr, NULL, CFAKE_DEVICE_NAME);
    if(IS_ERR(node)) {
      err = PTR_ERR(node);
      goto deletedevice;
    }
    
    /* success */
    return 0;
  }
  
  /* no memory allocated */
  return -ENOMEM;

  /* device node creation failed */
deletedevice:
  cdev_del(&this_device->cdev);

  /* adding the character device failed */
classdestroy:
  class_destroy(this_device->class);

  /* class creation failed */
unregister:
  unregister_chrdev_region(MKDEV(this_device->major, 0), 1);

  /* character device allocation failed */
memfree:
  kzfree(this_device);

  return err;
}

static void __exit
cfake_exit_module(void)
{
  /* destroy the device node */
  device_destroy(cfake_class, MKDEV(cfake_major, 0));
  
  /* delete the character device */
  cdev_del(&cdev);

  /* destroy the device class */
  class_destroy(this_device->class);

  /* unregister the character devices */
  unregister_chrdev_region(MKDEV(cfake_major, 0), 1);
}

module_init(cfake_init_module);
module_exit(cfake_exit_module);

MODULE_AUTHOR("Tobias Pluess");
MODULE_LICENSE("GPL");

Der goto-Teil gefällt mir nicht so, aber es ist am einfachsten ;-)
sieht nicht so schlecht aus, oder? Habe das in der Zwischenzeit aber 
nicht mehr getestet. Aber vielleicht sieht einer noch Fehler. Was ich 
nun noch machen muss ist ioctl implementieren; ich habe da allerdings 
gesehen dass es verschiedene Varianten gibt; irgendwie ioctl_unlock 
usw., welches ist das richtige?

[Georg A. (georga)]

Ich wollte noch ein "nicht" kaufen ;)

Das goto ist den Dijkstra-Jüngern zwar ein Graus, aber hier durchaus 
gerechtfertigt. Alles andere macht den Fluss noch undurchschaubarer bzw. 
fehlerträchtiger, und "try-catch" gibts ja auch nicht.

Die Sache mit dem Lock kommt noch vom "Big-Kernel-Lock", der bis Ende 
der 2.6er (oder so) die IO-Ops geschützt hat und jetzt noch aus 
Kompatibilitätsgründen da ist. Nimm den alten (nicht den unlocked*), und 
du musst dir keine grossen Gedanken machen. Die Performanceeffekte des 
unlocked* wären in der Anwendung ohnehin nicht bemerkbar. Da gehts um 
Multicore/Massiv-SMP.

[Tobias P. (hubertus)]

Hi Georg,

ach soo :-)

Okay aber den Callback "nur" ioctl() gibt es m.E. nicht, ich finde nur 
die modifizierten Varianten. Was mache ich falsch?

Btw, Dijkstra war mir kein Begriff, hab aber kurz gegoogled ;-) 
Allerdings ist "GOTO Statement considered harmful" tatsächlich das, was 
ich mal gelernt habe :D

Ehm, etwas ist mir noch aufgefallen - mit

sudo insmod ./test.ko

wird das Modul geladen, und unter /dev wird meine Devicenode erstellt, 
soweit alles gut... wenn ich aber

sudo rmmod test

mache, dann wird auch das Modul entladen, aber die Devicenode bleibt 
bestehen bis ich den PC neu starte. Ist das richtiges bzw. gewolltes 
Verhalten? Ich hätte eigentlich erwartet dass die Devicenode beim 
Entladen des Moduls entfernt wird.

Gruss Tobias

[Georg A. (georga)]

> Was mache ich falsch?

Das normale/alte würde compat_ioctl heissen.

> Allerdings ist "GOTO Statement considered harmful" tatsächlich das, was
> ich mal gelernt habe :D

Wobei die Goto-Nutzung in der Zeit aber auch extrem war. Die meisten 
Sprachen hatten nichts strukturierendes, oft nichtmal ein else zum if... 
Von daher halte ich es für übertrieben, heute beim Auftauchen von ein 
paar versprengten Gotos gleich wieder den ollen Dijkstra-Spruch 
rauszulassen.

> Ich hätte eigentlich erwartet dass die Devicenode beim
> Entladen des Moduls entfernt wird.

Sollte es, ein printk im exit-code zeigt, ob er überhaupt aufgerufen 
wird ;) Die Reihenfolge beim Aufräumen kommt mir aber komisch vor. Mach 
mal den class_destroy vor den cdev_del, so machens andere.. Ausserdem 
solltest du als letztes noch this_device freigeben (das wirds aber nicht 
sein).

[Hans Ulli K. (Gast)]

Tobias Plüss schrieb:
> sudo rmmod test
>
> mache, dann wird auch das Modul entladen, aber die Devicenode bleibt
> bestehen bis ich den PC neu starte. Ist das richtiges bzw. gewolltes
> Verhalten? Ich hätte eigentlich erwartet dass die Devicenode beim
> Entladen des Moduls entfernt wird.
>
> Gruss Tobias

Was macht denn udev oder ein anderer Hotplugmanager (mdev / logfile)
Der Device-Node in /dev wird ja nicht per Kernel erzeugt, sondern der 
Kernel gibt per /proc/sys/kernel/hotplug an der Userspace weiter.

Das mit dem goto in den Sourcen finde ich normal. Außerdem ist eine 
return Anweisung auch ein goto, nur sieht man es nicht sofort.


Wer findet hier den Fehler ...

        spin_lock(&spinlock_1);

        /* Do something */

        if (fail) {
                spin_unlock(&spinlock_1);
                return;
        }

        spin_lock(&spinlock_2);

        /* Do something */

        if (fail) {
                spin_unlock(&spinlock_2);
                spin_unlock(&spinlock_1);
                return;
        }

        /* Do something */

        if (fail) {
                spin_unlock(&spinlock_1);
                return;
        }


        /* Do something */

        if (fail) {
                spin_unlock(&spinlock_1);
                spin_unlock(&spinlock_2);
                return;
        }

        spin_unlock(&spinlock_2);
        spin_unlock(&spinlock_1);

[Tobias P. (hubertus)]

Hallo Hans Ulli und Georg,
sorry für die Verspätete Antwort, ich hatte viel zu tun ;-)

Ich werde noch meine Reihenfolge im Module-Exit Code korrigieren und 
dann heute Abend nochmal schauen, ob es so besser funktioniert.

Noch eine andere Frage:
angenommen, mein FPGA-Device bietet ein paar memory mapped Register an, 
sagen wir an der physikalischen Adresse 0xf0000000. Normalerweise klemmt 
die MMU ja Zugriffe auf nicht gemapptes Memory ab, oder? Das heisst, 
selbst wenn mein Treiber geladen wurde, kann ich noch nicht auf die 
Adresse 0xf0000000 einfach so zugreifen, das würde doch einen Fehler 
auslösen - wahrscheinlich segmentation fault, oder sowas. Kann ich mit 
mmap() oder so einer Funktion das Memory irgendwie so mappen, dass ich 
zugreifen darf? das ist mir noch nicht klar. Irgendwie muss ich ja auf 
die Adresse meines Devices zugreifen können damit ich die Register lesen 
und schreiben kann.

Das Lesen / Schreiben geschieht dann mit den Makros readl() bzw. 
writel(), ja?

Gruss Tobias


PS: Ulli, der Fehler liegt doch im 3. "if(fail)", oder? Da wird nur 
spinlock 1 unlocked, nicht aber die 2.

[Georg A. (georga)]

Wenn du auf HW-Speicher im Kernel zugreifen willst, nimm 
ioremap(_nocache). Das liefert dann die (virtuelle) Startadresse zurück, 
auf der du dann den Bereich siehst. Ohne das gibt's einen Oops... Ein 
iounmap zum Aufräumen gibts auch. Schau dir zB. mal die diversen 
Kerneltreiber an, fast jeder nutzt das. Meistens kommt da die 
physikalische Addresse aus dem PCI-Config-Space, bei Embedded-Kram ist 
sie manchmal auch hardcoded.

> Das Lesen / Schreiben geschieht dann mit den Makros readl() bzw.
> writel(), ja?

Ja, sollte man nehmen. Wobei für einen Quick-Hack auf x86 auch einfach 
normales Gepointere geht.  readl/writel kümmern sich u.a. um 
little/big-Endian-Probleme (PCI ist zB. LE, auf BE-Maschinen hätte ein 
roher 32Bit-Read vertauschte Bytes). Auf seltsamen Architekturen (zB. 
Alpha...) macht das auch noch die Aufteilung der Byte/Word/Long-Zugriffe 
auf verschiedene Adressbereiche.

[Tobias P. (hubertus)]

Hi Georg,

super, danke, damit komme ich zurecht, denke ich ;-)
Wenn ich noch ein Problem raus finde melde ich mich wieder hier.

Gruss & schönen Abend
Tobias

[Hans Ulli K. (Gast)]

Tobias Plüss schrieb:
>
> PS: Ulli, der Fehler liegt doch im 3. "if(fail)", oder? Da wird nur
> spinlock 1 unlocked, nicht aber die 2.

Beachte mal die Reihenfolge des Lockings :

        spin_lock(&spinlock_1);

        /* Do something */

        if (fail) {
                spin_unlock(&spinlock_1);
                return;
        }

        spin_lock(&spinlock_2);

        /* Do something */

        if (fail) {
                spin_unlock(&spinlock_2);
                spin_unlock(&spinlock_1);
                return;
        }

        if (fail) {
                spin_unlock(&spinlock_1);
                spin_unlock(&spinlock_2);
                return;
        }

Beim zweiten "fail" wird falsch unlocked.

Im Programmfluss wurde erst das spinlock_1, dann spinlock_2 gesetzt.
Ein Unlock sollte, dann Rückwärts ablaufen.
Es ist quasi wie beim allozieren/free dieser struct.

struct {
        char *mem;
} data;

struct data *test;

Wenn du den Speicher von *test freigibst muss du ja auch erst ein
free (test->mem);
machen, sonnst hast du ein memory hole ...

Und da ist es echt einfacher diese Sache mit einem
goto
in C abzufangen und es ist einfacher zu lesen.


Mit dem mmap vom deinem FPGA, schaue mal in dem Bereich
drivers/gpu
Die Grafikkarten haben das gleiche "Problem" wie du. Da wird auch ein 
Bereich per mmap in den Userspace gemapped.

[Tobias P. (hubertus)]

Hallo zusammen,

ich habe noch eine Frage hierzu!
Ich habe hier ein laufendes Embedded Linux System, das ich selber 
compiliert habe. Den Kernel habe ich mit arm-none-eabi-gcc kompiliert.

Da ich auf dem Target keinen Compiler habe, muss ich meinen Treiber 
Cross-Compilieren. Dazu habe ich folgendes Makefile:

ifneq ($(KERNELRELEASE),)
# We were called by kbuild

obj-m += test.o

else  # We were called from command line

KDIR := /hdd/sinetscu-dev/linux-socfpga
PWD  := $(shell pwd)
CROSS=arm-linux-gnueabihf-

default:
  $(MAKE) -C $(KDIR) SUBDIRS=$(PWD)  ARCH=arm CROSS_COMPILE=$(CROSS) modules


endif  # End kbuild check
######################### Version independent targets ##########################

clean:
  rm -f -r *.o *.ko .*cmd .tmp* core *.i

Vorerst möchte ich nur folgendes Fake-Modul compilieren:

#include <linux/version.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/fs.h>
#include <linux/errno.h>
#include <linux/err.h>
#include <linux/cdev.h>
#include <linux/device.h>
#include <linux/mutex.h>
#include <asm/uaccess.h>


static int __init
cfake_init_module(void)
{
  printk(KERN_INFO "io driver loaded");
  return 0;
}

static void __exit
cfake_exit_module(void)
{
  printk(KERN_INFO "io driver unloaded");
}

module_init(cfake_init_module);
module_exit(cfake_exit_module);

MODULE_AUTHOR("Tobias Pluess <[e-mail]>");
MODULE_LICENSE("GPL");

und dann müsste ich ja unter /var/log/messages meine Meldungen von dem 
Treiber sehen. Also, compilieren geht, ABER, wenn ich auf meinem Target 
(das mit Buildroot erstellt wurde) dann eingebe

insmod ./test.ko

dann kriege ich den Fehler:

test: version magic '3.10.0-00163-gd4db2a9-dirty SMP mod_unload ARMv7 
p2v8 ' should be '3.10.0-0016'
insmod: can't insert './test.ko': invalid module format


warum? ich habe für den Treiber ja dieselben Header verwendet wie für 
den Kernel. Was mache ich falsch?


Gruss Tobias

[Hans Ulli K. (Gast)]

Tobias Plüss schrieb:
>
> test: version magic '3.10.0-00163-gd4db2a9-dirty SMP mod_unload ARMv7
> p2v8 ' should be '3.10.0-0016'
> insmod: can't insert './test.ko': invalid module format
>
>
> warum? ich habe für den Treiber ja dieselben Header verwendet wie für
> den Kernel. Was mache ich falsch?
>
>
> Gruss Tobias
Wenn ich das richtig lese "*-gd4db2a9-dirty" hast du den Treiber über 
das Makefile von Kconfig/Kbuild angeworfen.

Mache bitte in Kconfig die Option
"Automatically append version information to the version string"
aus.
An deine Kernelversion wird ein git Hash angefügt. Außerdem zeigt 
"dirty" an das du nicht commited hast.

[Tobias P. (hubertus)]

Hi Hans Ulli,

s u p e r, das hat funktioniert! jetzt kann ich mein crosscompiliertes 
Modul auf meinen embedddd device laden. Toll! :D
debuggen kann man aber solch ein kernelmodul nicht so richtig oder?

Gruss