Ich habe SPI-Flash an mein Linux-Board (imx 233-basiert) angeschlossen, das in seinem SPI-Bus läuft. Ich habe den Kernel und den SPI-Bus und den Flash-Chip dafür konfiguriert.
Der Blitz befindet sich derzeit auf einem Steckbrett. Bevor ich versuchte, unter Linux zu arbeiten, habe ich es separat versucht und kann mit einem FT2232H-Chip (FT2232-Breakout-Board von DangerousPrototypes.com) lesen und schreiben, wie ich möchte. Allerdings musste ich beim Linux-Board Pull-up-Widerstände (10k) in die Dateneingänge und Datenausgänge einbauen, sonst wurde der Chip nicht richtig erkannt.
Mein eigentliches Problem ist, dass ich jetzt versuche, nur rohen Flash über den mtd-Treiber zu lesen, und alles scheint korrekt zu sein, wenn ich weniger als 35 Bytes lese. Sofort, wenn ich mehr als 35 Bytes (36 oder mehr) lese, beschwert sich der Treiber über DMA-Fehler:
[ 521.700000] mxs-spi 80034000.ssp: DMA transfer timeout
[ 521.700000] spi_master spi32766: failed to transfer one message from queue
Auch in diesem Fall sind die meisten (wenn nicht alle) Bytes falsch. Das Lesen von weniger als 35 Bytes wird "sofort" (kein Timeout) zurückgegeben, und alle gelesenen Bytes sind korrekt.
Mein C-Code stammt direkt aus dem MTD-Lesebeispiel:
int main(int argc, char * argv[])
{
if (argc != 2)
{
printf("Need arguments how many chars to read\nExiting...\n");
return 1;
}
int amount = atoi(argv[1]);
printf("reading (%d) chars\n", amount);
mtd_info_t mtd_info;
int fd = open("/dev/mtd0", O_RDONLY);
ioctl(fd, MEMGETINFO, &mtd_info);
printf("MTD type: %u\n", mtd_info.type);
printf("MTD total size : %u bytes\n", mtd_info.size);
printf("MTD erase size : %u bytes\n", mtd_info.erasesize);
/* read buffer */
unsigned char buf[amount];
read(fd, buf, sizeof(buf));
int i = 0;
for (i = 0; i < amount; i++)
{
printf("%i: %X\n",i,buf[i]);
}
return 0;
}
Das Timeout passiert "wie erwartet" (10 Sekunden) in spi-mxs.c:
drivers/spi/spi-msx.c:
static int mxs_spi_txrx_dma(...):
....
ret = wait_for_completion_timeout(&spi->c, msecs_to_jiffies(SSP_TIMEOUT));
Irgendwelche Ideen, was falsch sein könnte? Ich bin nicht so gut mit Elektronik, also bitte alle Vorschläge sind willkommen.
Ich denke, es ist ein Problem mit dem SPI-Treiber. Funktioniert es immer noch nicht mit dem 3.7-Upstream-Kernel? Dort wurden viele Fixes angewendet.
Das ist kein Elektronikproblem. Auf einem SPI-Bus hat der Master die vollständige Kontrolle über das Timing jeder initiierten Übertragung. Insbesondere bei einer Leseoperation kann das Slave-Gerät fehlerhafte Daten oder überhaupt keine Daten zurückgeben, aber es hat keinen Einfluss darauf, ob die Übertragung abgeschlossen ist oder nicht.
Mit anderen Worten, der DMA-Timeout-Fehler, den Sie erhalten, ist ausschließlich ein Problem innerhalb des Linux-Kernels oder des spezifischen Treibers, den Sie verwenden. In jedem Fall wird eine genauere Antwort viel mehr Details von Ihnen erfordern: Welchen Flash-Chip verwenden Sie? Welches CPU-Board verwendest du? Welche Linux-Distribution verwendest du? Wie lauten die Versionsnummern des Kernels und aller Kernelmodule und/oder Gerätetreiber, die Sie verwenden? Hast du Links, wo diese Artikel zu finden sind?
John u
Kaz
read
Systemaufruf zurückgegeben wurde-1
. Sie ignorieren den Rückgabewert, und daher gibt Ihre Schleife in diesem Fall nicht initialisierte Daten aus dem Array mit variabler Länge aus.Mäusez
Jul