Je remplis cycliquement la mémoire tampon DMA avec mes données en les copiant à partir de la mémoire "normale" par tranches de 290 octets.
Au premier cycle memcpy
passe toujours bien. Au deuxième cycle, il se bloque en __memcpy_neon
(c'est du moins ce que dit la gdb à chaque fois que j'appuie sur Ctrl-C).
Le désassembleur affiche toujours le strmi
instruction a été coincée dans.
À titre d'essai, j'ai remplacé memcpy()
avec mon simple octet par octet memcpy1()
et tout fonctionne bien sur tous les tampons DMA de 3MB (mais plus lentement évidemment...:-)). Pour exclure le problème d'alignement, j'ai testé la bibliothèque memcpy()
pour copier des tampons non alignés - aucun problème n'a été détecté.
J'utilise linux 2.6.37
con glibc 2.23 (gcc 6.3.1 linaro)
en DM8148
CPU.
Pourquoi ce memcpy se bloque-t-il en général et pour la deuxième fois en particulier ?
MISE À JOUR : Après des tonnes d'expériences avec différentes variantes de memcpy en assembleur, je peux affirmer que ce sont les instructions de copie de mémoire NEON, avec et sans préchargement, qui posent problème :
Loop:
PLD [r1, #0xC0]
VLDM r1!,{d0-d7}
VSTM r0!,{d0-d7}
SUBS r2,r2,#0x40
BNE Loop
Toutes les autres variantes "normales" de memcpy() fonctionnent correctement. Y a-t-il des mystères dans l'utilisation de la mémoire DMA non mise en cache ( !) avec les instructions NEON ?