U-boot SPI fails to load with LCD

Gaurav S

unread,

May 9, 2017, 1:16:28 PM5/9/17

to BeagleBoard

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 <beaglebone>.

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 <beaglebone>.

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

William Hermans

unread,

May 9, 2017, 1:19:50 PM5/9/17

to beagl...@googlegroups.com

What does lsmod have to say about which drivers are loaded on each system ?

Gaurav S

unread,

May 9, 2017, 1:34:50 PM5/9/17

to BeagleBoard

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

Robert Nelson

unread,

May 9, 2017, 1:38:50 PM5/9/17

to Beagle Board, Gaurav

Which lcd?

For spidev please read:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Override_external_capes

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5852e231-e19e-4b1e-9a4f-3c9acd6656e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gaurav S

unread,

May 9, 2017, 1:50:15 PM5/9/17

to BeagleBoard, gaurav....@gmail.com

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

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

Gaurav

unread,

May 9, 2017, 2:08:55 PM5/9/17

to BeagleBoard, Gaurav Sureka

Hello,

Where does uboot log what capes have been loaded? clearly dmesg | grep bone does not show any capes loaded by uboot.

Thanks

Gaurav

Robert Nelson

unread,

May 9, 2017, 2:19:49 PM5/9/17

to Beagle Board, Gaurav

On Tue, May 9, 2017 at 12:50 PM, Gaurav S <gaurav....@gmail.com> wrote:
> 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.

So the "non-lcd" worked, since u-boot auto-loaded the overlay for
cape-universal, thus /dev/spidev* was created.

Regards,

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

Robert Nelson

unread,

May 9, 2017, 2:20:42 PM5/9/17

to Beagle Board, Gaurav Sureka

On Tue, May 9, 2017 at 1:08 PM, Gaurav <gaurav....@gmail.com> wrote:
> Hello,
> Where does uboot log what capes have been loaded? clearly dmesg | grep bone
> does not show any capes loaded by uboot.

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.

William Hermans

unread,

May 9, 2017, 2:20:57 PM5/9/17

to beagl...@googlegroups.com

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.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c0363018-6862-4b01-a933-1cdd2521c5c8%40googlegroups.com.

William Hermans

unread,

May 9, 2017, 2:25:37 PM5/9/17

to beagl...@googlegroups.com

On Tue, May 9, 2017 at 11:20 AM, William Hermans <yyr...@gmail.com> wrote:

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 ;)

Reply all

Reply to author

Forward