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 On Wednesday, September 16, 2020 at 9:06:24 AM UTC-7 Dennis Bieber wrote: > On Wed, 16 Sep 2020 08:22:52 -0700 (PDT), in > gmane.comp.hardware.beagleboard.user Mark Mitchell > <mark.mitchell9999-re...@public.gmane.org> wrote: > > > >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. > > > > 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. > > > -- > Dennis L Bieber > > -- 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/8ee2bee2-472c-4343-aa1f-ac0997b21ecbn%40googlegroups.com.