Re: [beagleboard] Re: ds18b20 with BBGW

[William Hermans]

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 = < 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 

Re: [beagleboard] Re: ds18b20 with BBGW

[William Hermans]

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 = < 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 

Re: [beagleboard] Re: ds18b20 with BBGW

[William Hermans]

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

[acheesehead]

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 = < 28 GPIO_ACTIVE_HIGH>;
> ---
> >   gpios = < 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

[William Hermans]

*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 = < 29 GPIO_ACTIVE_HIGH>;
---
>   gpios = < 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 = < 26 GPIO_ACTIVE_HIGH>;
> ---
> >   gpios = < 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 

Re: [beagleboard] Re: ds18b20 with BBGW

[William Hermans]

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 = < 26 GPIO_ACTIVE_HIGH>;
---
>   gpios = < 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.

[beagleboard] BeagleBone Blue Alpha users sought

[Jason Kridner]

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: Beaglebone Black PRU Troubles

[Zach B]

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  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  on 
the PRU but that also means, as far as I understand, that it was reading 
directly from  in bank0 when the data was actually in  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, , 4
>> NOP
>> XIN 10, , 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] Windows 10 anniversary update broke Ethernet over USB

[Erik Welsh]

  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

[Laurel Watts - NOAA Affiliate]

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, , 4
> NOP
> XIN 10, , 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
>