Ok so here is the quick skinny( untested ) to setup spidev on kernel 4.x. By untested, I mean I have not actually tested the signal generated, or received by the device. I was reading however, there is a "spidev_test" bit of code you can use to test send / receive by shorting MISO to MOSI( I'm supposing at it's the only way that makes sense ). However I want to read more about this code, I've not seen yet. Information is rather sparse from my source. Here: http://elinux.org/BeagleBone_Black_Enable_SPIDEV
I will say however that the information was rather plain, and easy for me to understand anyway. But I also know there are already pre-made overlays included with most, if not all images now days. Official images that is . . . But if you do need other pins than what's used in these overlays. You'd have to write your own overlay, and include it in /lib/firmware. With that said, I'm not exactly sure how that works, or technically if it's even possible. My understand of spidev is that it is a software only driver for SPI, but I'm not 100% sure if you need physical hardware to be used with spidev, or not. Anyway . . . *Test for already functioning spidev interfaces:* debian@beaglebone:~$ ls /dev |grep spi *Check which spidev overlays come with stock image:* debian@beaglebone:~$ ls /lib/firmware/ |grep SPI BB-SPI0-MCP3008-00A0.dtbo BB-SPIDEV0-00A0.dtbo BB-SPIDEV1-00A0.dtbo BB-SPIDEV1A1-00A0.dtbo *Edit /boot/uEnv.txt to load chosen overlay at boot:* ##BeagleBone Black: HDMI (Audio/Video) disabled: enable_uboot_overlays=1 dtb=am335x-boneblack-emmc-overlay.dtb dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo The above requires a little extra explanation. enable_uboot_overlays=1 is required to enable uboot loading of overlays. The line after that loads the device tree board file I want loaded at boot. It disables both forms of HDMI. Which strictly speaking I'm not sure is necessary for the given overlay im loading. But is something I personally always do. Since I never use HDMI. dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo loads the overlay I want through uboot, at boot. *Rebot required to take effect:* debian@beaglebone:~$ sudo reboot *Test again for functioning spidev interfaces:* debian@beaglebone:~$ ls /dev |grep spi spidev1.0 spidev1.1 Profit ! Do keep in mind that this is the very newest way to load overlays at boot. However, with that said, this would also work nearly exactly the same with the previous method with one exception. Instead of using: enable_uboot_overlays=1 dtb=am335x-boneblack-emmc-overlay.dtb dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo *You would use* dtb=am335x-boneblack-emmc-overlay.dtb . . . ##Example v4.1.x #cape_disable=bone_capemgr.disable_partno= cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0 Pretty straight forward, and it's been this way a while now. There is one caveat however. If you're loading a custom overlay( one not included with the stock image ), you need to inject it into the initramfs. This is done by. . . debian@beaglebone:~$ cd /opt/scripts/tools/developers/ debian@beaglebone:/opt/scripts/tools/developers$ git pull debian@beaglebone:/opt/scripts/tools/developers$ sudo ./update_initrd.sh *AFTER* You make sure your custom overlay is located in /lib/firmware On Sun, Jan 1, 2017 at 4:21 PM, William Hermans <yyrk...@gmail.com> wrote: > So, if you think "ah this is confusing . . ." it does get worse. > > The new future way( I suspect) to load overlays at boot will likely be > through uboot. Robert has recently added this functionality into uboot, > I've tested it, and it does seem to work great. But I think this is for > 4.1.x kernels and above only. However, this pretty much renders the need to > inject your overlays into the initramfs moot. It may also be a little > faster, but I can not see it being hugely faster. It has been said however > it will make other issues with various devices at boot - Better. > > You can read about it some here: https://groups.google.com/ > forum/#!searchin/beagleboard/HERE$20THERE$20BE%7Csort: > relevance/beagleboard/W0QPDee5u2s/c1cbhzN4FAAJ > > On Sun, Jan 1, 2017 at 4:04 PM, William Hermans <yyrk...@gmail.com> wrote: > >> I meant to say I've not used SPI on any embedded Linux platform. I do >> have plenty of experience with SPI on bare metal MCU's. >> >> On Sun, Jan 1, 2017 at 3:35 PM, Greg <soapy-sm...@comcast.net> wrote: >> >>> Nice! I will add this as a reference to my project documentation. >>> >>> Regarding the fact that you have to run config-pin after each boot, you >>> can add a section that the config-pin commands can be added >>> to whatever start-up configuration is most appropriate. >>> >>> The way I am doing this currently is to simply list the commands in a >>> text file like: >>> >>> config-pin P8.30 pruout >>> config-pin P9.31 pruout >>> etc. >>> >>> Then add this to the .bashrc file in the home directory: >>> >>> source (path to the above file) >>> >>> Then the configuration is done automatically! >>> Check this discussion for some other interesting info on Device Tree: >>> >>> https://groups.google.com/forum/#!category-topic/beagleboard/1iFM1ywGQX4 >>> >>> The impression I have gotten, and I could be wrong, is that adding or >>> subtracting overlays at the command >>> line is a not guaranteed to work operation. The overlays should be >>> reliably controlled via uEnv.txt and the eeprom. >>> >>> On Sunday, January 1, 2017 at 4:49:57 PM UTC-5, Clayton Gulick wrote: >>>> >>>> Ok, here's the first draft: https://github.com/clay >>>> tongulick/beagle_bone_black_spi/blob/master/README.md >>>> >>>> Corrections and additions are welcome! >>>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to beagleboard+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/beagleboard/daacf5b9-572f-4fcb-b609-0d598dd2f0e7%40googlegroups.com >>> <https://groups.google.com/d/msgid/beagleboard/daacf5b9-572f-4fcb-b609-0d598dd2f0e7%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORpMehhJK4aTgo0BX004CXO%2B3pQkyvxsN-bE2nOCpgMxWg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
