BBB: Using DMA with SPI

[John B]

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:

https://groups.google.com/forum/?fromgroups#!searchin/beagleboard/spi$20dma%7Csort:date/beagleboard/YV5qDHTgtBQ/MAI1s-PUAQAJ

and

https://groups.google.com/forum/?fromgroups#!searchin/beagleboard/spi$20dma%7Csort:date/beagleboard/_22bW7vMkW0/rn01nfvyBQAJ

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.

Regards,

John

[Robert Nelson]

Yes this was fixed, by NOT using kernel overlays.. (race condition)

Use either a full DTB or u-boot Overlays..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[John B]

Hi Robert,

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.

Thanks

John

[Robert Nelson]

No you are seeing a different issue.. The DMA/SPI/Overlays would cause
a "hardlock" when trying to switch from pio mode to DMA.

In your case, your just seeing an un-optimized dma..

Any change with v4.14.x?

[John B]

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.

Thanks for the suggestion on using 4.14.x.

John

[John B]

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.

John

[Robert Nelson]

before you run that script, just make sure you run:

sudo update-initramfs -ck `uname -r`

[Jeff Andich]

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:

http://beagleboard.org/discuss?place=msg%2Fbeagleboard%2Fx1mxG7c-ilg%2F2Q8OROMCAwAJ

Where Robert indicated to do:

(1) depmod -a

(2)  sudo update-initramfs -ck `uname -r`  (or update-initramfs -uk 'uname -r')

Not sure if updating the module dependency db is needed, but something to consider..

[Jeff Andich]

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?

https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSDcard 

Thanks!!

[John B]

Thanks Robert, of course that fixed the issue as Jeff points out.

I agree that it would be nice to have that in the documentation for updating the Kernel.

John

[albe...@gmail.com]

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.