Re: [beagleboard] Re: omap2_mcspi 48030000.spi: chipselect 0 already in use
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 > 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@4803/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.
Re: [beagleboard] Re: omap2_mcspi 48030000.spi: chipselect 0 already in use
On Fri, Sep 18, 2020 at 4:22 PM Mark Mitchell 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@4803/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/CAOCHtYgnWe79S1cdnN0SM-s8C2xUUactyUSCnYLV2vogxoob1A%40mail.gmail.com.
[beagleboard] Re: omap2_mcspi 48030000.spi: chipselect 0 already in use
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@4803/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 > 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.
[beagleboard] Re: omap2_mcspi 48030000.spi: chipselect 0 already in use
On Wed, 16 Sep 2020 08:22:52 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Mark Mitchell 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/jbd4mf5cg70i8r0infcajgv147ru0444a4%404ax.com.
