On Fri, Sep 18, 2020 at 4:22 PM Mark Mitchell <[email protected]> wrote: > > 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, -- 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/CAOCHtYgnWe79S1cdnN0SM-s8C2xUUactyUSCnYLV2vogxoob1A%40mail.gmail.com.
