On Tue, Sep 15, 2020 at 5:43 PM [email protected] <[email protected]> wrote: > > 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?
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, -- Robert Nelson https://rcn-ee.com/ -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYjWvQ2Buimtg_81VRzM3KGtB%3DUrwvN7pJxTwdMH4UEZxQ%40mail.gmail.com.
