omap2_mcspi 48030000.spi: chipselect 0 already in use

GoogleGroups
1

Hi All -
I am not very familiar with using this chat so please have patience with me.

I am working on a beaglebone black based system that we are trying to move from kernel Ver 3.8 to 4.4.

We have a working code base that runs on ver 3.8 but when I try to run it on ver 4.4 I get the message

11.682162] omap2_mcspi 48030000.spi: chipselect 0 already in use
[ 11.688461] spi_master spi1: spi_device register error /ocp/spi@48030000/channel@0
[ 11.696131] of_spi_notify: failed to create for ‘/ocp/spi@48030000/channel@0’
[ 11.703325] __of_changeset_entry_notify: notifier error @/ocp/spi@48030000/channel@0
[ 11.884030] omap2_mcspi 48030000.spi: chipselect 1 already in use
[ 11.890275] spi_master spi1: spi_device register error /ocp/spi@48030000/channel@1
[ 11.897937] of_spi_notify: failed to create for ‘/ocp/spi@48030000/channel@1’
[ 11.905139] __of_changeset_entry_notify: notifier error @/ocp/spi@48030000/channel@1
[ 12.215468] omap2_mcspi 481a0000.spi: chipselect 0 already in use
[ 12.221776] spi_master spi2: spi_device register error /ocp/spi@481a0000/channel@0
[ 12.229461] of_spi_notify: failed to create for ‘/ocp/spi@481a0000/channel@0’
[ 12.236658] __of_changeset_entry_notify: notifier error @/ocp/spi@481a0000/channel@0
[ 12.642142] omap2_mcspi 481a0000.spi: chipselect 1 already in use
[ 12.648433] spi_master spi2: spi_device register error /ocp/spi@481a0000/channel@1
[ 12.656098] of_spi_notify: failed to create for ‘/ocp/spi@481a0000/channel@1’
[ 12.663293] __of_changeset_entry_notify: notifier error @/ocp/spi@481a0000/channel@1

This appears in the dmesg log and at boot up.

during boot I get the message

loading /boot/dtbs/4.4.113-ti-r145/am335x-boneblack-uboot.dtb …

so It seems there is a conflict between this file and my device tree which uses the same settings as BB-SPIDEV0-00A0.dts and BB-SPIDEV1-00A0.dts

I have tried using the BB-SPIDEV0 dtbo files instead and get same problem.

The SPI ports (0 and 1) both work correctly except that the spi0 chip select line functions correctly on program startup but when I call it for a specific function it goes low and stays low.

so really ther are 2 questions -
Why is this not allowing my normal functioning of the device tree like it was.

2 - Is there something that changed with the way ioctl() handles the spi accesses that is now broken in ver 4.4 but worked ok in ver 3.8

the complete version I am using is

Linux beaglebone 4.4.113-ti-r145 #1 SMP Mon Jan 29 19:44:54 UTC 2018 armv7l GNU/Linux

Please let me know if there is specific information I can supply to help resolve this question?

Thanks

Mark

2

Whenever i read users moving from v3.8.x to -> xyz... i have to ask,
are you still using "load device tree overlays while booting the
kernel"???

That is no longer supported..

We really recommend all users switch to u-boot overlays with at least
the v4.14.x-ti based kernel.

This is a pretty drastic change for anyone running a 3.8.x based setup.

So i'd advise you take a new microsd card, blank out the eMMC, and
test with a newer buster-iot image:

https://rcn-ee.net/rootfs/bb.org/testing/2020-09-07/buster-iot/

and just see if you can get your application working on that..

Regards,

3

Hi Robert -
Thanks so much for your quick reply.

We initially did try the most recent version but could not get that to work so stepped back to earlier versions as that is a very large jump as you said. we also tried the uboot approach but that did not work either. now I am suspicious that it is because we were not using ver. 4.14 or newer.

Is there a guide to show how to set up the uEnv.txt file and any others to use Uboot to load the device trees? I dont quite understand how or what cape universal is doing or when to use it or not.

Thanks for your help.

Mark

4

This relies upon the version of u-boot being used also... (which is why
it was suggested that you blank the eMMC, so there is no boot attempt from
it -- I prefer to flash the eMMC with a modern image)

  Old BBB (Debian Wheezy era, maybe early Jessie) have a u-boot in the
eMMC that assumes the kernel will load device trees. Updating the eMMC with
a modern image should install a u-boot that does device tree loading. Note
that newer u-boot also detect the uSD card, and transition to it
automatically (so, booting from eMMC u-boot to uSD card device tree [I
believe] followed by uSD kernel) -- no need to hold down the boot-select to
get it to boot from uSD.

  If you have the old u-boot in eMMC, you MUST use the boot-select button
to force it to load u-boot from the uSD card instead.

5

Hi Guys -
Thanks so much for your responses. Sorry for the delay, lots going on…

so just to update you, we have the version 4.4 almost running except forthe spi0 chip select error behavior I have described earlier.
We are currently committed to the 3.8 version for internal reasons and it is working. we do need to move to the newer version and that is what this discussion is about. We did try later versions (4.14) previously but because we are quite embedded with the cape manager and we had numerous errors at boot (I believe) we migrated to version 4.4 that supports the cape manager, which is where we are now.

we fully intend to move the later versions but are very close with 4.4 so will likely try to make that work then move to 4.14 and ultimately buster or what ever is current . the reason is that 4.4 will give us access to resources that 3.8 did not .

so I need some clarification on the device tree side of things. it is my understanding that I need to load device trees to make the connection between the kernel drivers and the physical hardware and to set up the physical hardware as well.

the connection to the kernel driver is done through the compatible entry in the device tree which in our case points to SPIDEV.

thus it is necessary to load the device tree to make this happen.

when I follow the boot sequence, U-boot loads

/boot/dtbs/4.4.113-ti-r145/am335x-boneblack-uboot.dtb

and it contains a reference to load an ocp related driver which i assume is the one that we have a collision with
/ocp/spi@48030000/channel@0

what is the relationship of the /ocp/… driver structure to the /dev/spidev driver structure? This is a fundamental question that I have not been able to find the answer to?

I think that I need to disable the spi references in the /boot/dtbs/4.4.113-ti-r145/am335x-boneblack-uboot.dtband that should get me past the problem but iI am not clear on why they are not existing co0peratively…

By the way i get the same behavior (spi driver pin collision) when I use the beagle bone supplied BB-SPIDEV0-00A0.dts device tree.

I appreciate that you might not want to debug such an old problem but if you could help me to understand what the structure relationships are or point me to some material that would help my understanding that would be a big help.

Regarding the newer versions of the OS , I wonder if there is a reference uEnv.txt file that shows how to load a device tree from UBoot correctly . My understanding is that cape-universal should be disabled.

Per your comments dennis - I assume blank the emmc is done by using something like dd comand to write 0’s to to the eemc. please advise.

Thanks guys - I really appreciate any help I can get.

Cheers
Mark

6

Hi Guys -
Thanks so much for your responses. Sorry for the delay, lots going on...

so just to update you, we have the version 4.4 almost running except forthe spi0 chip select error behavior I have described earlier.
We are currently committed to the 3.8 version for internal reasons and it is working. we do need to move to the newer version and that is what this discussion is about. We did try later versions (4.14) previously but because we are quite embedded with the cape manager and we had numerous errors at boot (I believe) we migrated to version 4.4 that supports the cape manager, which is where we are now.

we fully intend to move the later versions but are very close with 4.4 so will likely try to make that work then move to 4.14 and ultimately buster or what ever is current . the reason is that 4.4 will give us access to resources that 3.8 did not .

so I need some clarification on the device tree side of things. it is my understanding that I need to load device trees to make the connection between the kernel drivers and the physical hardware and to set up the physical hardware as well.

the connection to the kernel driver is done through the compatible entry in the device tree which in our case points to SPIDEV.

thus it is necessary to load the device tree to make this happen.

when I follow the boot sequence, U-boot loads
/boot/dtbs/4.4.113-ti-r145/am335x-boneblack-uboot.dtb

and it contains a reference to load an ocp related driver which i assume is the one that we have a collision with
/ocp/spi@48030000/channel@0

what is the relationship of the /ocp/.... driver structure to the /dev/spidev driver structure? This is a fundamental question that I have not been able to find the answer to?

I think that I need to disable the spi references in the /boot/dtbs/4.4.113-ti-r145/am335x-boneblack-uboot.dtband that should get me past the problem but iI am not clear on why they are not existing co0peratively...

By the way i get the same behavior (spi driver pin collision) when I use the beagle bone supplied BB-SPIDEV0-00A0.dts device tree.

I appreciate that you might not want to debug such an old problem but if you could help me to understand what the structure relationships are or point me to some material that would help my understanding that would be a big help.

Sorry, debugging kernel overlays is a nightmare, that's why no one
uses it anymore..

Regarding the newer versions of the OS , I wonder if there is a reference uEnv.txt file that shows how to load a device tree from UBoot correctly . My understanding is that cape-universal should be disabled.

actually cape-universal works fine with overlays as of the latest
image's, it took some trial and error..

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

Per your comments dennis - I assume blank the emmc is done by using something like dd comand to write 0's to to the eemc. please advise.

This should remove the old u-boot:

sudo dd if=/dev/zero of=/dev/mmcblk1 count=1 seek=1 bs=128k

Regards,

7

thanks very much for the last reply robert. i need a bit to digest , just wanted to get back to you. thank you for your promptness.
i will review the link.
cheers
Mark