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
On Friday, September 18, 2020 at 2:30:35 PM UTC-7 RobertCNelson wrote: > On Fri, Sep 18, 2020 at 4:22 PM Mark Mitchell > <mark.mit...@gmail.com> 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a0cea613-c64a-411a-9454-53db9ba9a9d6n%40googlegroups.com.
