I am wondering if any progress has been made in getting Device Tree Overlays (via uBoot) to correctly allow DMA to be used on the SPI devices. I have not seen any recent mention of this issue. Referring to these previous articles:
It is suggested that should you want to use DMA with SPI, enable the SPI in the main DTB (sigh). Is this still the case? If so, does it even make sense to use DT Overlays for any other resources I am using (GPIO’s for example)? Since I’m hacking up the main DTB anyway, why not just add everything I need there and not worry about the uBoot DT Overlays at all?
Thanks so much for any insight anyone may have into this.
I am currently using the uboot_overlay_addrX scheme, and it seems the driver is always using PIO even for large SPI transfers (between 1024 and 3072 bytes). Under 3.8.13 I was using the Kernel overlay mechanism with success (DMA worked), but this past week I just switched to the more recent stuff that no longer supports the cape manager “slots” file, meaning, all overlays are in the uEnv.txt (or part of the main DTB). I’d rather not monkey with the main DTB, however, if that’s the only way to get SPI+DMA then I guess I’ll have to do that. Do I need a newer kernel and/or u-boot? version.sh output attached.
Robert,
Yes. It seems that 4.14.x works fine. Using a logic analyzer with 4.9.99, it seems that, while it was doing DMA, it was ALWAYS using a word size of 8 bits. So you 'd see 8 clocks, a substantial gap, 8 clocks, gap, 8 clocks, etc. Using the same driver module code we used for 4.9.99 (albeit, built with the 4.14.40 kernel includes/Makefiles), we ran it with the 4.14.40 kernel. We now see the correct 32 bit transfers: 32 clocks, gap, 32 clocks, gap. The gap is now about 1/5th of the total time as opposed to half of it.
Something must have been fixed/changed between 4.9.99 and 4.14.40 in the SPI driver. I’ll ‘diff’ them out and see if I spot anything.
I found that the eMMC flasher (/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh) no longer appears to work after I upgraded to Kernel 4.14.x. I traced this to /opt/scripts/tools/eMMC/functions.sh in prepare_environment(). It seems that /proc and /sys are not mounted when the flasher script is executed from init. Needless to say, this caused agita for the rest of the script. I’m not sure if this has been addressed someplace else (maybe it has to do with the fact I am using initrd.img-4.9.82-ti-r102? I doubt it though.)
In any event, in case someone is running into the same issue, I have attached my updated functions.sh which addresses the issue by mounting /proc and /sys just after the script does /tmp. This seems to work fine; it should even work on a system where /proc and /sys are already mounted.
I ran into a similar issue when I upgraded my kernel on an existing BB-X15 image and then attempted to run the flasher script from the SD card on a BB-X15:
Would you please add a note in the following location (and/or other applicable pages) about running init-ramfs when updating the kernel? And maybe even a blurb about why this is needed?
Hi! Could anyone add an example how to use dma-spi on bbb? I run bbb 4.14.71-ti-r80 and have no clue how to use it.
On the web there are mixed answers to the performance of spi-dma on bbb. Is it worth the effort, to me it seems rather complex implementing it.