Re: [beagleboard] Re: Beaglebone Black PRU Troubles
Hi Zach, Are you compiling with the -V3 switch? This should enable the scratch pad correctly. I've had not problems with it this way. Laurel On Sun, Dec 4, 2016 at 9:03 PM, Zach B wrote: > Thanks Jason, those were two great examples. > > Has anyone had any trouble with the scratch pad between PRUs? I'm using it > to pass values between the two systems and it doesn't appear to be working > at all. I even created a test script that has a PRU load a value into bank > 0 and then read it back out into a separate register and it doesn't appear > to be working. I get nothing back out of bank0. Is there some control > register that you have to set to activate these banks? > Here is the code I am using to test > init: > LDI32 R21, 0x > LDI32 R1, 0x > LDI32 R2, 0x0020 > XOUT 10, &R21, 4 > NOP > XIN 10, &R1, 1 > ;MOV R1, R21 > > SUB R2, R2, 1 > MOV R30, R1 > NOP > > read_loop: > SUB R2, R2, 1 > LSR R30, R30, 1 > NOP > QBNE read_loop, R2, 0 > QBA init > HALT > > > The MOV command works just fine but the XIN command does nothing. The > register remains empty. Any thoughts? > > > Zach > > On Tuesday, November 29, 2016 at 10:16:37 AM UTC-5, Jason Reeder wrote: >> >> Greg, >> >> Yes, I'd like to get assembly only and mixed c and assembly examples in >> the support package using TI's compiler tools. I'd like to clean it up a >> bit and make it a little more useful first though. I put those examples >> together last night for you and Zach and figured I'd get them in your hands >> first. Let me know if you run into any issues. >> >> I was running on a recent-ish version of the Debian distro on my BBGW. >> I'm fairly certain that I am seeing the same dmesg output that you are >> reporting. I don't think it happens with our TI Processor SDK distro so I >> haven't looked too closely at it yet. If I get a chance tonight after work >> I'll try to update to the latest Debian and see if I can't root cause the >> PRU boot loading issues. >> >> Jason Reeder >> >> >> On Tuesday, November 29, 2016 at 6:25:34 AM UTC-6, Greg wrote: >>> >>> Hi Jason, this is awesome, much appreciated! Is it going to become part >>> of the PRU Support Package examples? >>> >>> I'll run through the process soon and report on the result. >>> I also have some questions on the interrupt examples for some time in >>> the future. >>> >>> Meanwhile, I assume you ran the demo on a recent Debian distribution on >>> a Beaglebone. >>> I was wondering if you see this in the dmesg log. This is for PRU0, and >>> there is a repeated instance of these messages for PRU1. >>> >>> It's not a big deal as the firmwares can be started reliably after >>> boot. I was not seeing this on the Beaglebones a few months ago, as the >>> firmwares would be up and running automatically >>> after boot. Just curious what is going on... >>> >>> [4.705647] irq: no irq domain found for /ocp/pruss@4a30 >>> /intc@4a32 ! >>> [4.742790] irq: no irq domain found for /ocp/pruss@4a30 >>> /intc@4a32 ! >>> [4.836176] remoteproc1: 4a334000.pru0 is available >>> [4.836201] remoteproc1: Note: remoteproc is still under development >>> and considered experimental. >>> [4.836210] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and >>> backward compatibility isn't yet guaranteed. >>> [4.836500] remoteproc1: Direct firmware load for am335x-pru0-fw >>> failed with error -2 >>> [4.836520] remoteproc1: failed to load am335x-pru0-fw >>> [4.847402] pru-rproc 4a334000.pru0: booting the PRU core manually >>> [4.847433] remoteproc1: powering up 4a334000.pru0 >>> [4.847543] remoteproc1: Direct firmware load for am335x-pru0-fw >>> failed with error -2 >>> [4.847559] remoteproc1: request_firmware failed: -2 >>> [4.852787] pru-rproc 4a334000.pru0: rproc_boot failed >>> [4.969567] remoteproc1: releasing 4a334000.pru0 >>> [4.969746] pru-rproc: probe of 4a334000.pru0 failed with error -2 >>> >>> >>> On Monday, November 28, 2016 at 11:52:36 PM UTC-5, Jason Reeder wrote: Greg and Zach, Check out the two tarballs in this drive link: https://drive.google.com /drive/folders/0B_OVOhSEksP8MDFiT0x6YU1EZG8?usp=sharing - PRU_Halt_Assembly.tar.gz - Contains a project to drop into /opt/source/pru-software-support-package/examples/am335x/ that is an assembly only projec -- > 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/77f4936f-70fa-49b5-b45b-8d6c38b3937e%40googlegroups.com >
[beagleboard] Windows 10 anniversary update broke Ethernet over USB
FYI. My computers just went thru the Window 10 anniversary update. This broke the Ethernet over USB functionality for BBB (along w/ a number of other things). When I went to re-install the BONE_D64.exe file from http://beagleboard.org/getting-started, the install failed even when run as administrator. I was able to get it working by manually updating the driver software: 1) In "Device Manager" --> "Network Adapters" --> "Linux USB Ethernet/RNDIS Gadget", right click and "Update Driver Software ...". 2) Select "Browse my computer for driver software" 3) Select "Let me pick from a list of device drivers on my computer" 4) Wait for list to be retrieved. 5) Select Manufacturer: "Microsoft", Model: "Remote NDIS Compatible Device" You will get a warning but you can let the driver update install. Cloud 9 and all the other Ethernet over USB stuff should then work. - Erik -- 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/d3f5c5b8-28dd-42ff-85a8-becb87e6a863%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Beaglebone Black PRU Troubles
Hi Laurel, Yeah I have the -V3 flags sent. I think I found the issue that I was having. I may have misread the PRU Reference guide as well as the assembly language documentation on elinux. I had thought that the register address passed in the XIN and XOUT was what register in the PRU the system should start reading or writing too. That appears to be true but it also appears to be directly tied to the banks. For example, when I was telling it to write &R21 data to bank0 it was writing to R21 in bank0 instead of the start of bank0 memory (R1). When I went to read the data back out I was attempting to write the data to &R1 on the PRU but that also means, as far as I understand, that it was reading directly from &R1 in bank0 when the data was actually in &R21 in bank0. I could be wrong but my few tests with both c and assembly seem to show that's what was occuring. Zach On Monday, December 5, 2016 at 9:05:36 AM UTC-5, laurel.a.watts wrote: > > Hi Zach, > > Are you compiling with the -V3 switch? This should enable the scratch pad > correctly. I've had not problems with it this way. > > Laurel > > On Sun, Dec 4, 2016 at 9:03 PM, Zach B > > wrote: > >> Thanks Jason, those were two great examples. >> >> Has anyone had any trouble with the scratch pad between PRUs? I'm using >> it to pass values between the two systems and it doesn't appear to be >> working at all. I even created a test script that has a PRU load a value >> into bank 0 and then read it back out into a separate register and it >> doesn't appear to be working. I get nothing back out of bank0. Is there >> some control register that you have to set to activate these banks? >> Here is the code I am using to test >> init: >> LDI32 R21, 0x >> LDI32 R1, 0x >> LDI32 R2, 0x0020 >> XOUT 10, &R21, 4 >> NOP >> XIN 10, &R1, 1 >> ;MOV R1, R21 >> >> SUB R2, R2, 1 >> MOV R30, R1 >> NOP >> >> read_loop: >> SUB R2, R2, 1 >> LSR R30, R30, 1 >> NOP >> QBNE read_loop, R2, 0 >> QBA init >> HALT >> >> >> The MOV command works just fine but the XIN command does nothing. The >> register remains empty. Any thoughts? >> >> >> Zach >> >> On Tuesday, November 29, 2016 at 10:16:37 AM UTC-5, Jason Reeder wrote: >>> >>> Greg, >>> >>> Yes, I'd like to get assembly only and mixed c and assembly examples in >>> the support package using TI's compiler tools. I'd like to clean it up a >>> bit and make it a little more useful first though. I put those examples >>> together last night for you and Zach and figured I'd get them in your hands >>> first. Let me know if you run into any issues. >>> >>> I was running on a recent-ish version of the Debian distro on my BBGW. >>> I'm fairly certain that I am seeing the same dmesg output that you are >>> reporting. I don't think it happens with our TI Processor SDK distro so I >>> haven't looked too closely at it yet. If I get a chance tonight after work >>> I'll try to update to the latest Debian and see if I can't root cause the >>> PRU boot loading issues. >>> >>> Jason Reeder >>> >>> >>> On Tuesday, November 29, 2016 at 6:25:34 AM UTC-6, Greg wrote: Hi Jason, this is awesome, much appreciated! Is it going to become part of the PRU Support Package examples? I'll run through the process soon and report on the result. I also have some questions on the interrupt examples for some time in the future. Meanwhile, I assume you ran the demo on a recent Debian distribution on a Beaglebone. I was wondering if you see this in the dmesg log. This is for PRU0, and there is a repeated instance of these messages for PRU1. It's not a big deal as the firmwares can be started reliably after boot. I was not seeing this on the Beaglebones a few months ago, as the firmwares would be up and running automatically after boot. Just curious what is going on... [4.705647] irq: no irq domain found for /ocp/pruss@4a30/intc@4a32 ! [4.742790] irq: no irq domain found for /ocp/pruss@4a30/intc@4a32 ! [4.836176] remoteproc1: 4a334000.pru0 is available [4.836201] remoteproc1: Note: remoteproc is still under development and considered experimental. [4.836210] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed. [4.836500] remoteproc1: Direct firmware load for am335x-pru0-fw failed with error -2 [4.836520] remoteproc1: failed to load am335x-pru0-fw [4.847402] pru-rproc 4a334000.pru0: booting the PRU core manually [4.847433] remoteproc1: powering up 4a334000.pru0 [4.847543] remoteproc1: Direct firmware load for am335x-pru0-fw failed with error -2 [4.847559] remoteproc1: request_firmware failed: -2 [4.852787] pru-rproc 4a334000.pru0: rproc_boot failed >>>
[beagleboard] BeagleBone Blue Alpha users sought
I'm looking for 2-3 additional alpha users for upcoming BeagleBone Blue Linux-based robotics controller. I already have a pretty good list, but my experience says self-selection is more efficient. That said, I'll still need some guidance to set priority. Unless issues are found, the initial production design is at https://github.com/jadonk/beaglebone-blue. To avoid flooding the list, contact me direct with the same subject line. If you have list-suitable queries, then reply here. -- 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/CA%2BT6QPks5-QNHiFp8JdydLUDycvvxsgY70Cu%2BAzZzY6%3DnuX4bg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: ds18b20 with BBGW
I repeated this process for P8.14, and it works fine. This is just to let others who may not be aware that you can use 1-wire on any gpio pin that is not already in use by the system. Again, double check the pins in the schematic, to make sure they're not being used by somethign like HDMI( which you can disable hdmi audio and video if you do not need it. ), or i2c-0 / i2c-2, emmc, sdcard, etc. But again you have to of course change the overlay to reflect the pin you need to use. *william@beaglebone:~$* diff ./dev/bb.org-overlays/src/arm/BB-W1-P8.14-00A0.dts ./dev/bb.org-overlays/src/arm/BB-W1-P9.12-00A0.dts 1c1,2 < /* --- > > /* 4c5 < * Virtual cape for onewire on connector pin P8.14 --- > * Virtual cape for onewire on connector pin P9.12 21c22 < part-number = "BB-W1-P8.14"; --- > part-number = "BB-W1-P9.12"; 27c28 < "P8.14"; --- > "P9.12"; 35c36 < BONE_P8_14 0x37 --- > BONE_P9_12 0x37 51c52 < gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>; --- > gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>; On Sat, Dec 3, 2016 at 3:11 PM, William Hermans wrote: > @ Sebastian > > Ah I forgot to mention loading capes from /boot/uEnv.txt. So . . . > > *william@beaglebone:~$* cat /boot/uEnv.txt |grep cape > #cmdline=coherent_pool=1M quiet cape_universal=enable > video=HDMI-A-1:1024x768@60e > #cape_disable=capemgr.disable_partno= > #cape_enable=capemgr.enable_partno= > #cape_disable=bone_capemgr.disable_partno= > > cape_enable=capemgr.enable_partno= is the way to go. You > can assign multiple cape overlays with this feature, but I do not remember > if they are space, or comma separated. I'm thinking comma separated, but > may be wrong. > > That's the first step. > > The second step would be to . . . > > Copy all your required overlays into /lib/firmware, which you've probably > already done. > > *william@beaglebone:~$* cd /opt/scripts/ > *william@beaglebone:/opt/scripts$* git pull > *william@beaglebone:/opt/scripts$* cd tools/developers/ > *william@beaglebone:/opt/scripts/tools/developers$* sudo > ./update_initrd.sh > > What this does, is notes what's in uEnv.txt in the way of enabled capes, > then which overlays you have in /lib/firmware, and "injects" these overlays > into the initramfs. This is important, and if not done, your overlays will > not load at boot using this method. But the upside is that once done, this > will load your overlays at boot faster than any other method. Near > instantly at boot, 1-2 seconds tops. > > Anyway, this method is fairly easy, and is actually the best way to go. > > -- 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/CALHSORoxQyVm4q56JLaCWZYhncAHEm7u_7Hoq-nZCj5V3pFaXA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: ds18b20 with BBGW
*OR* P8.26 . . . *smacks hardware designer / buddy . . . *william@beaglebone:~/dev/bb.org-overlays$* diff src/arm/BB-W1-P8.26-00A0.dts src/arm/BB-W1-P8.14-00A0.dts 4c4 < * Virtual cape for onewire on connector pin P8.26 --- > * Virtual cape for onewire on connector pin P8.14 21c21 < part-number = "BB-W1-P8.26"; --- > part-number = "BB-W1-P8.14"; 27c27 < "P8.26"; --- > "P8.14"; 35c35 < BONE_P8_26 0x37 --- > BONE_P8_14 0x37 51c51 < gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>; --- > gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>; *william@beaglebone:~$* cd dev/bb.org-overlays/ william@beaglebone:~/dev/bb.org-overlays$ make ./src/arm/BB-W1-P8.26-00A0.dtbo DTC src/arm/BB-W1-P8.26-00A0.dtbo *william@beaglebone:~/dev/bb.org-overlays*$ sudo cp ./src/arm/BB-W1-P8.26-00A0.dtbo /lib/firmware/ *william@beaglebone:~/dev/bb.org-overlays*$ cat /sys/devices/platform/bone_capemgr/slots 0: PF -1 1: PF -1 2: PF -1 3: PF -1 *william@beaglebone:~/dev/bb.org-overlays$* sudo sh -c "echo 'BB-W1-P8.26' > /sys/devices/platform/bone_capemgr/slots" *william@beaglebone:~/dev/bb.org-overlays$* cat /sys/devices/platform/bone_capemgr/slots 0: PF -1 1: PF -1 2: PF -1 3: PF -1 4: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-W1-P8.26 *william@beaglebone:~/dev/bb.org-overlays$* dmesg |grep W1 [ 210.416201] bone_capemgr bone_capemgr: part_number 'BB-W1-P8.26', version 'N/A' [ 210.416276] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-W1-P8.26' [ 210.430251] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-W1-P8.26-00A0.dtbo' loaded; overlay id #0 *william@beaglebone:~/dev/bb.org-overlays$* ls /sys/bus/w1/devices/ 28-0647ddf6 w1_bus_master1 *william@beaglebone:~/dev/bb.org-overlays$* cat /sys/bus/w1/devices/28-0647ddf6/w1_slave 19 01 4b 46 7f ff 07 10 eb : crc=eb YES 19 01 4b 46 7f ff 07 10 eb t=17562 Anyway, dead horse . . . point made? On Mon, Dec 5, 2016 at 6:41 PM, William Hermans wrote: > I repeated this process for P8.14, and it works fine. This is just to let > others who may not be aware that you can use 1-wire on any gpio pin that is > not already in use by the system. Again, double check the pins in the > schematic, to make sure they're not being used by somethign like HDMI( > which you can disable hdmi audio and video if you do not need it. ), or > i2c-0 / i2c-2, emmc, sdcard, etc. But again you have to of course change > the overlay to reflect the pin you need to use. > > *william@beaglebone:~$* diff > ./dev/bb.org-overlays/src/arm/BB-W1-P8.14-00A0.dts > ./dev/bb.org-overlays/src/arm/BB-W1-P9.12-00A0.dts > 1c1,2 > < /* > --- > > > > /* > 4c5 > < * Virtual cape for onewire on connector pin P8.14 > --- > > * Virtual cape for onewire on connector pin P9.12 > 21c22 > < part-number = "BB-W1-P8.14"; > --- > > part-number = "BB-W1-P9.12"; > 27c28 > < "P8.14"; > --- > > "P9.12"; > 35c36 > < BONE_P8_14 0x37 > --- > > BONE_P9_12 0x37 > 51c52 > < gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>; > --- > > gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>; > > > > > On Sat, Dec 3, 2016 at 3:11 PM, William Hermans wrote: > >> @ Sebastian >> >> Ah I forgot to mention loading capes from /boot/uEnv.txt. So . . . >> >> *william@beaglebone:~$* cat /boot/uEnv.txt |grep cape >> #cmdline=coherent_pool=1M quiet cape_universal=enable >> video=HDMI-A-1:1024x768@60e >> #cape_disable=capemgr.disable_partno= >> #cape_enable=capemgr.enable_partno= >> #cape_disable=bone_capemgr.disable_partno= >> >> cape_enable=capemgr.enable_partno= is the way to go. You >> can assign multiple cape overlays with this feature, but I do not remember >> if they are space, or comma separated. I'm thinking comma separated, but >> may be wrong. >> >> That's the first step. >> >> The second step would be to . . . >> >> Copy all your required overlays into /lib/firmware, which you've >> probably already done. >> >> *william@beaglebone:~$* cd /opt/scripts/ >> *william@beaglebone:/opt/scripts$* git pull >> *william@beaglebone:/opt/scripts$* cd tools/developers/ >> *william@beaglebone:/opt/scripts/tools/developers$* sudo >> ./update_initrd.sh >> >> What this does, is notes what's in uEnv.txt in the way of enabled capes, >> then which overlays you have in /lib/firmware, and "injects" these overlays >> into the initramfs. This is important, and if not done, your overlays will >> not load at boot using this method. But the upside is that once done, this >> will load your overlays at boot faster than any other method. Near >> instantly at boot, 1-2 seconds tops. >> >> Anyway, this method is fairly easy, and is actually the best way to go. >> >> >
Re: [beagleboard] Re: ds18b20 with BBGW
Tried your workflow today without success. Everything is OK up to the lsmod | grep w1 step. I only get the w1_gpio entry. I am not a Linux kernel expert, so I don't know how to troubleshoot why the other entries aren't showing up. I didn't see any activity on the oscilloscope either. On Thursday, December 1, 2016 at 10:28:16 PM UTC-7, William Hermans wrote: > > *1-wire workflow:* > > *Hardware setup:* > > Everything is directly connected via jumper wires, with no additional > components. > > DS18B20 PIN1 connected to Beaglebone P9.1 (ground) > DS18B20 PIN2 connected to Beaglebone P9.22 (1-wire data) > DS18B20 PIN3 connected to Beaglebone P9.5 (Vdd 5v) > > > Remove any currently loaded overlays that might be using P9_22, then > reboot. > > Install git if need be: > william@beaglebone:~/dev$ sudo apt-get install git > > git clone the bb.org-overlays repo: > william@beaglebone:~/dev$ git clone > https://github.com/beagleboard/bb.org-overlays > > Move into the source directory: > william@beaglebone:~/dev$ cd ./bb.org-overlays/src/arm > > Find the file we're looking for: > william@beaglebone:~/dev/bb.org-overlays/src/arm$ ls |grep W1 > BB-W1-P9.12-00A0.dts > > Make a copy of the file while renaming it in one go: > william@beaglebone:~/dev/bb.org-overlays/src/arm$ cp BB-W1-P9.12-00A0.dts > BB-W1-P9.22-00A0.dts > > > Edit copied 1-wire overlay source to suit our needs: > william@beaglebone:~/dev/bb.org-overlays/src/arm$ diff > BB-W1-P9.12-00A0.dts BB-W1-P9.22-00A0.dts > 4c4 > < * Virtual cape for onewire on connector pin P9.12 > --- > > * Virtual cape for onewire on connector pin P9.22 > 21c21 > < part-number = "BB-W1-P9.12"; > --- > > part-number = "BB-W1-P9.22"; > 27c27 > < "P9.12"; > --- > > "P9.22"; > 35c35 > < BONE_P9_12 0x37 > --- > > BONE_P9_22 0x37 > 51c51 > < gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>; > --- > > gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>; > > Backout to the base path: > william@beaglebone:~/dev/bb.org-overlays/src/arm$ cd ../.. > > Build our newly created overlay: > william@beaglebone:~/dev/bb.org-overlays$ make > ./src/arm/BB-W1-P9.22-00A0.dtbo > > "Install" our overlay: > william@beaglebone:~/dev/bb.org-overlays$ sudo cp > ./src/arm/BB-W1-P9.22-00A0.dtbo /lib/firmware/ > > Load our overlay: > william@beaglebone:~/dev/bb.org-overlays$ sudo sh -c "echo 'BB-W1-P9.22' > > /sys/devices/platform/bone_capemgr/slots" > > Check if the overlay loaded: > william@beaglebone:~/dev/bb.org-overlays$ cat > /sys/devices/platform/bone_capemgr/slots > 0: PF -1 > 1: PF -1 > 2: PF -1 > 3: PF -1 > 4: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-W1-P9.22 > > william@beaglebone:~/dev/bb.org-overlays$ dmesg |grep W1 > [ 2826.626795] bone_capemgr bone_capemgr: part_number 'BB-W1-P9.22', > version 'N/A' > [ 2826.626871] bone_capemgr bone_capemgr: slot #4: 'Override Board > Name,00A0,Override Manuf,BB-W1-P9.22' > [ 2826.641278] bone_capemgr bone_capemgr: slot #4: dtbo > 'BB-W1-P9.22-00A0.dtbo' loaded; overlay id #0 > > Check to make sure kernel modules loaded or not: > william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1 > w1_therm4886 0 > w1_gpio 3764 0 > wire 35398 2 w1_gpio,w1_therm > > Check sysfs: > william@beaglebone:~/dev/bb.org-overlays$ ls /sys/bus/w1/devices/ > 28-0647ddf6 w1_bus_master1 > > Read from our sensor: > william@beaglebone:~/dev/bb.org-overlays$ cat > /sys/bus/w1/devices/28-0647ddf6/w1_slave > 16 01 4b 46 7f ff 0a 10 98 : crc=98 YES > 16 01 4b 46 7f ff 0a 10 98 t=17375 > > Pat self on back for job well done ! > -- 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/3529e32e-5edd-4e1f-add2-80832ac19715%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: ds18b20 with BBGW
On Mon, Dec 5, 2016 at 7:30 PM, acheesehead wrote: > Tried your workflow today without success. Everything is OK up to the > lsmod | grep w1 step. I only get the w1_gpio entry. I am not a Linux kernel > expert, so I don't know how to troubleshoot why the other entries aren't > showing up. > > I didn't see any activity on the oscilloscope either. > Then, you must be using a 3.8.x kernel. Right ? But here are the modules needed at least on a 4.x kernel: william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1 w1_therm4886 0 w1_gpio 3764 0 wire 35398 2 w1_gpio,w1_therm All three of those need to be loaded in order for the DS18B20 to work. So, try manually loading those via modprobe. SO let's take a look at a rPI blogpost: https://www.modmypi.com/blog/ds18b20-one-wire-digital-temperature-sensor-and-the-raspberry-pi Much of this blog post is going to be RaspberryPI centric. *dtoverlay=w1-gpio, */boot/config.txt, etc. However if you scroll down to the *"Programming" *part of the blog post. This person talks about loading the required kernel modules( also note that kernel version is 3.6.11 ) Using modprobe. So if you run those two modprobe commands, and then list the contents of /sys/bus/w1/devices: *william@beaglebone:~$* ls /sys/bus/w1/devices/ 28-0647ddf6 w1_bus_master1 And you get output like the above. 1-wire *is* working, and the 1-wire master ( beaglebone ) has detected a 1-wire slave device. It's working. However, if you load both the above 1-wire kernel modules, and there is nothing in /sys/bus/w1/devices, then something is wrong. I'd have to say at this point, if you do not get an error about a missing module, that you have your pin muxed incorrectly, or not properly connected to the pin. Now if you get an error on the command line from trying to load either of those two 1-wire modules. Chances are pretty good you haven't compiled in the given proper 1-wire support. In fact, I do believe there is a whole section in menu-config for 1-wire devices. You may actually have to recompile your kernel with support for the DS18B20 1-wire device . . . Another issues between 4.x, and 3.8.x kernels is that device enumeration was different for some devices. So . . . It is entirely possible, in your overlay, that the GPIO bank you're passing in as parameters is off by one. How can be test for this ? On 4.x kernels . . . *william@beaglebone:~$* ls /sys/devices/platform/ocp 4030.ocmcram 48042000.timer480ca000.spinlock 4980.tptc driver_override 40302000.ocmcram_nocache 48044000.timer4819c000.i2c 4990.tptc modalias 44e07000.gpio 48046000.timer481ac000.gpio 49a0.tptc ocp:l4_wkup@44c0 44e09000.serial 48048000.timer481ae000.gpio 4a10.ethernet of_node 44e0b000.i2c 4804a000.timer481d8000.mmc 4c00.emif power 44e35000.wdt 4804c000.gpio 4820.interrupt-controller 5310.sham subsystem 44e3e000.rtc 4806.mmc 4831.rng 5350.aes uevent 4740.usb 480c8000.mailbox 4900.edma 5600.sgx *william@beaglebone:~$* ls /sys/devices/platform/ocp/44e07000.gpio/gpio/ gpiochip0 And the very first gpio address entry in this case was the lowest gpio bank. So, if you investigate the equivalent directory in 3.8.x, you should be able to check all gpio banks, to see what the actual lowest gpio bank is. Do also keep in mind that /sys/devices/platform/ocp/ will be different in 3.8.x. So you'll have to poke around a bit. Unless someone else posts here and gives you the proper path. I don't remember what it is. Anyway, there is another option. You can upgrade your kernel to a newer version. Which, yes, will probably mean you'll also have to either flash a newer image, or run a newer image from sdcard. -- 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/CALHSORqTRB%3D%2BsAjP81PvqSyZ2xid8Z58rgzzC_3ZtBAG0CK1Mw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: ds18b20 with BBGW
Actually the last bit probably wont work because: william@beaglebone:~$ ls /sys/devices/platform/ocp/*.gpio/gpio/ /sys/devices/platform/ocp/44e07000.gpio/gpio/: gpiochip0 /sys/devices/platform/ocp/4804c000.gpio/gpio/: gpiochip32 /sys/devices/platform/ocp/481ac000.gpio/gpio/: gpiochip64 /sys/devices/platform/ocp/481ae000.gpio/gpio/: gpiochip96 You wont get an actual gpio bank number. Just the bank offset. So going by this beaglebone blogpost: http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/ gpios = <&gpio2 13 0>; /* P8.11*/ I show P8.11 as gpio1_13 in my pinmux pdf file. So yes, 4.x versus 3.8.x, for gpio banks are definitely off by one. Looks like for 3.8.x kernel gpio banks start at gpio1, and I know for a fact that gpio banks in 4.x start at gpio0. Anyway, very good chance your overlay file is slightly wrong. Based on off by one gpio bank. On Mon, Dec 5, 2016 at 8:28 PM, William Hermans wrote: > On Mon, Dec 5, 2016 at 7:30 PM, acheesehead wrote: > >> Tried your workflow today without success. Everything is OK up to the >> lsmod | grep w1 step. I only get the w1_gpio entry. I am not a Linux kernel >> expert, so I don't know how to troubleshoot why the other entries aren't >> showing up. >> >> I didn't see any activity on the oscilloscope either. >> > > Then, you must be using a 3.8.x kernel. Right ? But here are the modules > needed at least on a 4.x kernel: > > william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1 > w1_therm4886 0 > w1_gpio 3764 0 > wire 35398 2 w1_gpio,w1_therm > > All three of those need to be loaded in order for the DS18B20 to work. So, > try manually loading those via modprobe. SO let's take a look at a rPI > blogpost: https://www.modmypi.com/blog/ds18b20-one-wire-digital- > temperature-sensor-and-the-raspberry-pi > > Much of this blog post is going to be RaspberryPI centric. *dtoverlay=w1-gpio, > */boot/config.txt, etc. However if you scroll down to the *"Programming" *part > of the blog post. This person talks about loading the required kernel > modules( also note that kernel version is 3.6.11 ) Using modprobe. So if > you run those two modprobe commands, and then list the contents of > /sys/bus/w1/devices: > > *william@beaglebone:~$* ls /sys/bus/w1/devices/ > 28-0647ddf6 w1_bus_master1 > > And you get output like the above. 1-wire *is* working, and the 1-wire > master ( beaglebone ) has detected a 1-wire slave device. It's working. > However, if you load both the above 1-wire kernel modules, and there is > nothing in /sys/bus/w1/devices, then something is wrong. I'd have to say at > this point, if you do not get an error about a missing module, that you > have your pin muxed incorrectly, or not properly connected to the pin. > > Now if you get an error on the command line from trying to load either of > those two 1-wire modules. Chances are pretty good you haven't compiled in > the given proper 1-wire support. In fact, I do believe there is a whole > section in menu-config for 1-wire devices. You may actually have to > recompile your kernel with support for the DS18B20 1-wire device . . . > > Another issues between 4.x, and 3.8.x kernels is that device enumeration > was different for some devices. So . . . It is entirely possible, in your > overlay, that the GPIO bank you're passing in as parameters is off by one. > How can be test for this ? On 4.x kernels . . . > > *william@beaglebone:~$* ls /sys/devices/platform/ocp > 4030.ocmcram 48042000.timer480ca000.spinlock > 4980.tptc driver_override > 40302000.ocmcram_nocache 48044000.timer4819c000.i2c > 4990.tptc modalias > 44e07000.gpio 48046000.timer481ac000.gpio > 49a0.tptc ocp:l4_wkup@44c0 > 44e09000.serial 48048000.timer481ae000.gpio > 4a10.ethernet of_node > 44e0b000.i2c 4804a000.timer481d8000.mmc > 4c00.emif power > 44e35000.wdt 4804c000.gpio 4820.interrupt-controller > 5310.sham subsystem > 44e3e000.rtc 4806.mmc 4831.rng > 5350.aes uevent > 4740.usb 480c8000.mailbox 4900.edma > 5600.sgx > > *william@beaglebone:~$* ls /sys/devices/platform/ocp/44e07000.gpio/gpio/ > gpiochip0 > > And the very first gpio address entry in this case was the lowest gpio > bank. So, if you investigate the equivalent directory in 3.8.x, you should > be able to check all gpio banks, to see what the actual lowest gpio bank > is. Do also keep in mind that /sys/devices/platform/ocp/ will be > different in 3.8.x. So you'll have to poke around a bit. Unless someone > else posts here and gives you the proper path. I don't remember what it is. > > Anyway, there is another option. You can upgrade your kernel to a newer > version. Which, yes, will probably mean you'll also have to either flash a > newer image, or run a newer image from sdcard. > --
Re: [beagleboard] Re: ds18b20 with BBGW
Nope, actually that persons overlay file is wrong. So yeah I don;t know time to learn Linux and start troubleshooting your problems ;) On Mon, Dec 5, 2016 at 8:47 PM, William Hermans wrote: > Actually the last bit probably wont work because: > > william@beaglebone:~$ ls /sys/devices/platform/ocp/*.gpio/gpio/ > /sys/devices/platform/ocp/44e07000.gpio/gpio/: > gpiochip0 > > /sys/devices/platform/ocp/4804c000.gpio/gpio/: > gpiochip32 > > /sys/devices/platform/ocp/481ac000.gpio/gpio/: > gpiochip64 > > /sys/devices/platform/ocp/481ae000.gpio/gpio/: > gpiochip96 > > You wont get an actual gpio bank number. Just the bank offset. So going by > this beaglebone blogpost: http://www.bonebrews.com/ > temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/ > > gpios = <&gpio2 13 0>; /* P8.11*/ > > I show P8.11 as gpio1_13 in my pinmux pdf file. So yes, 4.x versus 3.8.x, > for gpio banks are definitely off by one. Looks like for 3.8.x kernel gpio > banks start at gpio1, and I know for a fact that gpio banks in 4.x start at > gpio0. > > Anyway, very good chance your overlay file is slightly wrong. Based on off > by one gpio bank. > > On Mon, Dec 5, 2016 at 8:28 PM, William Hermans wrote: > >> On Mon, Dec 5, 2016 at 7:30 PM, acheesehead >> wrote: >> >>> Tried your workflow today without success. Everything is OK up to the >>> lsmod | grep w1 step. I only get the w1_gpio entry. I am not a Linux kernel >>> expert, so I don't know how to troubleshoot why the other entries aren't >>> showing up. >>> >>> I didn't see any activity on the oscilloscope either. >>> >> >> Then, you must be using a 3.8.x kernel. Right ? But here are the modules >> needed at least on a 4.x kernel: >> >> william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1 >> w1_therm4886 0 >> w1_gpio 3764 0 >> wire 35398 2 w1_gpio,w1_therm >> >> All three of those need to be loaded in order for the DS18B20 to work. >> So, try manually loading those via modprobe. SO let's take a look at a rPI >> blogpost: https://www.modmypi.com/blog/ds18b20-one-wire-digital-temper >> ature-sensor-and-the-raspberry-pi >> >> Much of this blog post is going to be RaspberryPI centric. >> *dtoverlay=w1-gpio, >> */boot/config.txt, etc. However if you scroll down to the *"Programming" >> *part of the blog post. This person talks about loading the required >> kernel modules( also note that kernel version is 3.6.11 ) Using modprobe. >> So if you run those two modprobe commands, and then list the contents of >> /sys/bus/w1/devices: >> >> *william@beaglebone:~$* ls /sys/bus/w1/devices/ >> 28-0647ddf6 w1_bus_master1 >> >> And you get output like the above. 1-wire *is* working, and the 1-wire >> master ( beaglebone ) has detected a 1-wire slave device. It's working. >> However, if you load both the above 1-wire kernel modules, and there is >> nothing in /sys/bus/w1/devices, then something is wrong. I'd have to say at >> this point, if you do not get an error about a missing module, that you >> have your pin muxed incorrectly, or not properly connected to the pin. >> >> Now if you get an error on the command line from trying to load either of >> those two 1-wire modules. Chances are pretty good you haven't compiled in >> the given proper 1-wire support. In fact, I do believe there is a whole >> section in menu-config for 1-wire devices. You may actually have to >> recompile your kernel with support for the DS18B20 1-wire device . . . >> >> Another issues between 4.x, and 3.8.x kernels is that device enumeration >> was different for some devices. So . . . It is entirely possible, in your >> overlay, that the GPIO bank you're passing in as parameters is off by one. >> How can be test for this ? On 4.x kernels . . . >> >> *william@beaglebone:~$* ls /sys/devices/platform/ocp >> 4030.ocmcram 48042000.timer >> 480ca000.spinlock 4980.tptc driver_override >> 40302000.ocmcram_nocache 48044000.timer >> 4819c000.i2c 4990.tptc modalias >> 44e07000.gpio 48046000.timer >> 481ac000.gpio 49a0.tptc ocp:l4_wkup@44c0 >> 44e09000.serial 48048000.timer >> 481ae000.gpio 4a10.ethernet of_node >> 44e0b000.i2c 4804a000.timer >> 481d8000.mmc 4c00.emif power >> 44e35000.wdt 4804c000.gpio >> 4820.interrupt-controller 5310.sham subsystem >> 44e3e000.rtc 4806.mmc >> 4831.rng 5350.aes uevent >> 4740.usb 480c8000.mailbox >> 4900.edma 5600.sgx >> >> *william@beaglebone:~$* ls /sys/devices/platform/ocp/44e07000.gpio/gpio/ >> gpiochip0 >> >> And the very first gpio address entry in this case was the lowest gpio >> bank. So, if you investigate the equivalent directory in 3.8.x, you should >> be able to check all gpio banks, to see what the actual lowest gpio bank >> is