Hello All,
With LCD, it seems like SPI is behaving awkwardly. I have two beagle bone boards one with LCD plugged in (SYS1) and the other stand alone beagle bone (SYS2), both running latest debian lxqt 2gb image (may 7 2017). The curious thing over here is that before u-boot spi was working just fine with the LCD.
Following are the results from each of the systems:
SYS1 (beaglebone + LCD4)
debian@beaglebone:~$ uname -a
Linux beaglebone 4.4.62-ti-r99 #1 SMP Sat Apr 22 14:21:03 UTC 2017 armv7l GNU/Linux
debian@beaglebone:~$ dmesg | grep bone
[ 0.000000] Kernel command line: console=ttyO0,115200n8 bone_capemgr.enable_partno=BB-SPIDEV1 bone_capemgr.uboot_capemgr_enabled=1 root=UUID=e4c7e2e7-0fbf-494c-8d84-305d291d2b7a ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet
[ 2.376478] bone_capemgr bone_capemgr: Baseboard: ‘A335BNLT,00C0,2516BBBK2265’
[ 2.376509] bone_capemgr bone_capemgr: compatible-baseboard=ti,beaglebone-black - #slots=4
[ 2.376544] bone_capemgr bone_capemgr: slot #0: auto loading handled by U-Boot
[ 2.376566] bone_capemgr bone_capemgr: slot #1: auto loading handled by U-Boot
[ 2.376587] bone_capemgr bone_capemgr: slot #2: auto loading handled by U-Boot
[ 2.376629] bone_capemgr bone_capemgr: slot #3: auto loading handled by U-Boot
[ 2.376655] bone_capemgr bone_capemgr: enabled_partno PARTNO ‘BB-SPIDEV1’ VER ‘N/A’ PR ‘0’
[ 2.376667] bone_capemgr bone_capemgr: slot #4: override
[ 2.376681] bone_capemgr bone_capemgr: slot #4: auto loading handled by U-Boot
[ 2.377276] bone_capemgr bone_capemgr: initialized OK.
[ 6.851318] systemd[1]: Set hostname to .
debian@beaglebone:/dev$ ls sp*
ls: cannot access sp*: No such file or directory
SYS2 (stand along beagle bone)
debian@beaglebone:~$ uname -a
Linux beaglebone 4.4.62-ti-r99 #1 SMP Sat Apr 22 14:21:03 UTC 2017 armv7l GNU/Linux
debian@beaglebone:~$ dmesg|grep bone
[ 0.000000] Kernel command line: console=ttyO0,115200n8 bone_capemgr.enable_partno=BB-SPIDEV1 bone_capemgr.uboot_capemgr_enabled=1 root=UUID=599ccfe6-2803-4ea0-9141-2bb571994e70 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet
[ 2.445200] bone_capemgr bone_capemgr: Baseboard: ‘A335BNLT,00C0,2516BBBK22E8’
[ 2.445233] bone_capemgr bone_capemgr: compatible-baseboard=ti,beaglebone-black - #slots=4
[ 2.445270] bone_capemgr bone_capemgr: slot #0: auto loading handled by U-Boot
[ 2.445291] bone_capemgr bone_capemgr: slot #1: auto loading handled by U-Boot
[ 2.445337] bone_capemgr bone_capemgr: slot #2: auto loading handled by U-Boot
[ 2.445359] bone_capemgr bone_capemgr: slot #3: auto loading handled by U-Boot
[ 2.445379] bone_capemgr bone_capemgr: enabled_partno PARTNO ‘BB-SPIDEV1’ VER ‘N/A’ PR ‘0’
[ 2.445390] bone_capemgr bone_capemgr: slot #4: override
[ 2.445403] bone_capemgr bone_capemgr: slot #4: auto loading handled by U-Boot
[ 2.446010] bone_capemgr bone_capemgr: initialized OK.
[ 17.551299] systemd[1]: Set hostname to .
debian@beaglebone:~$ cd /dev
debian@beaglebone:/dev$ ls sp*
spidev1.0 spidev1.1 spidev2.0 spidev2.1
Am I missing something regarding how u-boot is supposed to work?
Thanks
Gaurav
What does lsmod have to say about which drivers are loaded on each system ?
Hell,
Thanks for the response. Seems like spidev available on both systems.
For sys1 (beaglebone+LCD)
debian@beaglebone:~$ lsmod
Module Size Used by
omap_aes_driver 23912 0
omap_sham 26513 0
omap_rng 5544 0
rng_core 9066 1 omap_rng
tilcdc 31597 0
ti_am335x_tsc 6268 0
ti_am335x_tscadc 6563 1 ti_am335x_tsc
evdev 13511 0
uio_pdrv_genirq 3923 0
uio 10524 1 uio_pdrv_genirq
8021q 23043 0
garp 7049 1 8021q
mrp 8967 1 8021q
stp 2430 1 garp
llc 5903 2 stp,garp
usb_f_mass_storage 49849 2
usb_f_acm 8361 2
u_serial 13753 1 usb_f_acm
usb_f_ecm 11064 2
usb_f_rndis 25865 2
u_ether 14349 2 usb_f_ecm,usb_f_rndis
libcomposite 53618 16 usb_f_acm,usb_f_ecm,usb_f_rndis,usb_f_mass_storage
spidev 8860 0
tieqep 9981 0
pwm_tiehrpwm 5883 1
pru_rproc 15431 0
pruss_intc 8603 1 pru_rproc
pruss 12090 1 pru_rproc
for sys2 (beaglebone only):
debian@beaglebone:~$ lsmod
Module Size Used by
snd_soc_hdmi_codec 6738 1
ti_am335x_adc 6364 0
kfifo_buf 3732 1 ti_am335x_adc
industrialio 62863 2 ti_am335x_adc,kfifo_buf
snd_soc_simple_card 9812 0
omap_aes_driver 23912 0
omap_sham 26513 0
pwm_tiecap 4571 0
omap_rng 5544 0
rng_core 9066 1 omap_rng
tilcdc 31597 0
c_can_platform 7581 0
c_can 12220 1 c_can_platform
can_dev 14358 1 c_can
snd_soc_davinci_mcasp 20606 2
snd_soc_edma 1290 1 snd_soc_davinci_mcasp
snd_soc_omap 3762 1 snd_soc_davinci_mcasp
snd_soc_core 190453 5 snd_soc_hdmi_codec,snd_soc_davinci_mcasp,snd_soc_edma,snd_soc_omap,snd_soc_simple_card
snd_pcm_dmaengine 5894 2 snd_soc_core,snd_soc_omap
snd_pcm 104314 5 snd_soc_hdmi_codec,snd_soc_davinci_mcasp,snd_soc_core,snd_soc_omap,snd_pcm_dmaengine
snd_timer 24761 1 snd_pcm
snd 72473 3 snd_soc_core,snd_timer,snd_pcm
soundcore 8661 1 snd
spi_omap2_mcspi 12952 0
tda998x 15704 0
evdev 13511 4
ti_am335x_tsc 6268 0
ti_am335x_tscadc 6563 2 ti_am335x_adc,ti_am335x_tsc
uio_pdrv_genirq 3923 0
uio 10524 1 uio_pdrv_genirq
8021q 23043 0
garp 7049 1 8021q
mrp 8967 1 8021q
stp 2430 1 garp
llc 5903 2 stp,garp
usb_f_mass_storage 49849 2
usb_f_acm 8361 2
u_serial 13753 3 usb_f_acm
usb_f_ecm 11064 2
usb_f_rndis 25865 2
u_ether 14349 2 usb_f_ecm,usb_f_rndis
libcomposite 53618 16 usb_f_acm,usb_f_ecm,usb_f_rndis,usb_f_mass_storage
spidev 8860 0
tieqep 9981 0
pwm_tiehrpwm 5883 0
pru_rproc 15431 0
pruss_intc 8603 1 pru_rproc
pruss 12090 1 pru_rproc
Thanks
Gaurav
Hello,
http://elinux.org/4D_4.3_LCD_CAPE
Thanks for the reference Robert, that solved the issue. Apparently I should not be mixing uboot with “bone_capemgr.enable”. I am not sure why did the /dev/spidev* work on the system without the LCD.
Thanks again,
gaurav
Hello,
Where does uboot log what capes have been loaded? clearly dmesg | grep bone does not show any capes loaded by uboot.
Thanks
Gaurav
So the "non-lcd" worked, since u-boot auto-loaded the overlay for
cape-universal, thus /dev/spidev* was created.
Regards,
It gives a hint:
[ 2.376544] bone_capemgr bone_capemgr: slot #0: "auto loading
handled by U-Boot"
plug in a serial adapter, you'll see u-boot reading the cape eeprom
and making decisions based on /boot/uEnv.txt variables.
Regards,
I’m noticing on the second system spi_omap2_mcspi is loading as well. One thing I have also noticed is that with recent TI kernels,kernel modules seem to remove themselves when not needed, or possibly conflicting with another driver. Which is a good thing, but also, could potentially be a bad thing if that does not work as intended. My guess here, is that spi_omap2_mcspi is moving it’s self out of the way, and on it’s way out is stopping the other SPI interfaces from loading. Additionally, my guess is that if you need the functionality of the other SPI “channels”, you’ll have to create a custom overlay.
Or, completely disregard what I say, because the two of you seem to have
gotten the problem solved while I was typing a response 