[beagleboard] Cannot Enable PRU - prussdrv_open() failed

[Xsentius]

Hello all,

I am trying to make PRU work, and tried a sample code, here is the output:

root@beaglebone:/home/xsentius/2# sudo ./pru_loader pru_egp_output.bin
prussdrv_open() failed


I searched and seems like it happens since I cannot enable PRU, so I did:

root@beaglebone:/home/xsentius/2# echo BB-BONE-PRU-01 > $SLOTS
bash: echo: write error: No such file or directory

However it does not work. What might be the problem? 

I also tried:

root@beaglebone:/home/xsentius/2# echo BB-BONE-PRU-O1 > 
/sys/devices/platform/bone_capemgr/slots
bash: echo: write error: No such file or directory

Kernel version:

root@beaglebone:/home/iroh/2# uname -a
Linux beaglebone 4.1.20-bone-rt-r20 #1 Sat Mar 19 06:28:47 UTC 2016 armv7l 
GNU/Linux


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Rick Mann]

> On Apr 4, 2016, at 21:14 , Robert Nelson  wrote:
> 
> On Mon, Apr 4, 2016 at 10:29 PM, Rick Mann  wrote:
>> I updated to -r7, and set the dtb=am335x-boneblack-audio.dtb
>> 
>> Did my MMC get corrupted?
> 
> dtb=am335x-boneblack-audio.dtb
> 
> doesn't setup the emmc...

Augh, right. So, how do I get past this situation? Do I need to boot from SD 
card, or can I fix it via initramfs?

I tried googling, but didn't have much luck.

-- 
Rick Mann
rm...@latencyzero.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Robert Nelson]

On Mon, Apr 4, 2016 at 10:29 PM, Rick Mann  wrote:
> I updated to -r7, and set the dtb=am335x-boneblack-audio.dtb
>
> uEnv.txt: http://pastebin.com/yhQqzGWZ
>
> Booting fails now. Log: http://pastebin.com/M8YJJGWi
>
>> U-Boot SPL 2016.03-1-gd12d09f (Mar 17 2016 - 16:16:15)
>> Trying to boot from MMC
>> bad magic
>> .
>> .
>> .
>> Loading, please wait...
>> mount: can't find /root in /etc/fstab
>> Target filesystem doesn't have requested /sbin/init.
>> mount: mounting /dev on /root/dev failed: No such file or directory
>> No init found. Try passing init= bootarg.
>> modprobe: module i8042 not found in modules.dep
>> modprobe: module ehci-pci not found in modules.dep
>> modprobe: module ehci-orion not found in modules.dep
>> modprobe: module uhci-hcd not found in modules.dep
>> modprobe: module ohci-hcd not found in modules.dep
>
> I updated to -r7 with apt-get install.
>
> Did my MMC get corrupted?

dtb=am335x-boneblack-audio.dtb

doesn't setup the emmc...

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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Rick Mann]

Oh, I'm on a BB Green. Should that have been am335x-bonegreen-audio.dtb?

I'm in initramfs, but I'm not sure how to find the uEnv.txt file to edit it.

> On Apr 4, 2016, at 20:29 , Rick Mann  wrote:
> 
> I updated to -r7, and set the dtb=am335x-boneblack-audio.dtb
> 
> uEnv.txt: http://pastebin.com/yhQqzGWZ
> 
> Booting fails now. Log: http://pastebin.com/M8YJJGWi
> 
>> U-Boot SPL 2016.03-1-gd12d09f (Mar 17 2016 - 16:16:15)
>> Trying to boot from MMC
>> bad magic
>> .
>> .
>> .
>> Loading, please wait...
>> mount: can't find /root in /etc/fstab
>> Target filesystem doesn't have requested /sbin/init.
>> mount: mounting /dev on /root/dev failed: No such file or directory
>> No init found. Try passing init= bootarg.
>> modprobe: module i8042 not found in modules.dep
>> modprobe: module ehci-pci not found in modules.dep
>> modprobe: module ehci-orion not found in modules.dep
>> modprobe: module uhci-hcd not found in modules.dep
>> modprobe: module ohci-hcd not found in modules.dep
> 
> I updated to -r7 with apt-get install.
> 
> Did my MMC get corrupted?
> 
>> On Apr 4, 2016, at 13:36 , Robert Nelson  wrote:
>> 
>> 
>> On Apr 4, 2016 3:17 PM, "Rick Mann"  wrote:
>>> 
>>> 
 On Apr 4, 2016, at 06:57 , Robert Nelson  wrote:
 
 
 
 On Mon, Apr 4, 2016 at 8:41 AM, Robert Nelson  
 wrote:
 
 
 On Mon, Apr 4, 2016 at 4:47 AM, Rick Mann  wrote:
 I'm trying to get my audio cape to work (which is nearly identical to the 
 cape that was available for sale). I've had it working to some level of 
 success with past kernels (3.1.18), but now I'm on 4.4.6. My existing DTS 
 didn't work, so I'm looking at how the BB-BONE-AUDI-02 DTS is written.
 
 One of the differences is that it doesn't explicitly call out the McASP 
 clock frequency like the older one did. Instead, it seems to refer to 
 clk_mcasp0. But when I copy the same code into my DTS, I get:
 
 [  103.180866] of_resolve_phandles: Could not find symbol 'clk_mcasp0'
 [  103.187269] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree
 
 I found it defined by grepping /boot/dtbs. It's in 
 /boot/dtbs/4.4.6-bone-rt-r6/am335x-abbbi.dtb. Where can I find the source 
 files for these DTBs?
 
 Is this dtb part of what's loaded by default in 4.4.6-bone-rt-r6? If not, 
 can I copy the definition into my
 
 FWIW, here's my DTS and some output from dmesg: 
 http://pastebin.com/niDkWdWV
 
 
 You need to add this to your base *.dtb:
 
 https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-boneblack-audio.dts#L17-L28
 
 btw, the one thing i haven't tried, have everything in the clk defined 
 except for the gpio and load that as part of the audio overlay..
 
 side note, we just got audio (cape audio rev b) working a few weeks back, 
 so this is relatively new
>>> 
>>> Thanks, Robert. I'll give that a shot. I'm not immediately sure what my 
>>> current base *.dtb is, nor how to build a new one and specify that be used. 
>>> But maybe I can piggyback off the one you show there.
>> 
>> Switch to r7, just pushed it out this morning.
>> 
>> dtb=am335x-boneblack-audio.dtb
>> 
>>> 
>>> Out of curiosity, why can't this be done as an overlay (to help me 
>>> understand the Device Tree better)?
>>> 
>> 
>> Just a bug in the clock driver, the dynamic overlay changes is still very 
>> fragile. In most cases moving the driver as a module vs built-in, fixes it 
>> right up.. Except this is the clock driver, it needs to be built in..
>> 
>> Regards,
>> 
>> 
>> -- 
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> Rick
> 
> 
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.


-- 
Rick



-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Rick Mann]

I updated to -r7, and set the dtb=am335x-boneblack-audio.dtb

uEnv.txt: http://pastebin.com/yhQqzGWZ

Booting fails now. Log: http://pastebin.com/M8YJJGWi

> U-Boot SPL 2016.03-1-gd12d09f (Mar 17 2016 - 16:16:15)
> Trying to boot from MMC
> bad magic
> .
> .
> .
> Loading, please wait...
> mount: can't find /root in /etc/fstab
> Target filesystem doesn't have requested /sbin/init.
> mount: mounting /dev on /root/dev failed: No such file or directory
> No init found. Try passing init= bootarg.
> modprobe: module i8042 not found in modules.dep
> modprobe: module ehci-pci not found in modules.dep
> modprobe: module ehci-orion not found in modules.dep
> modprobe: module uhci-hcd not found in modules.dep
> modprobe: module ohci-hcd not found in modules.dep

I updated to -r7 with apt-get install.

Did my MMC get corrupted?

> On Apr 4, 2016, at 13:36 , Robert Nelson  wrote:
> 
> 
> On Apr 4, 2016 3:17 PM, "Rick Mann"  wrote:
> >
> >
> > > On Apr 4, 2016, at 06:57 , Robert Nelson  wrote:
> > >
> > >
> > >
> > > On Mon, Apr 4, 2016 at 8:41 AM, Robert Nelson  
> > > wrote:
> > >
> > >
> > > On Mon, Apr 4, 2016 at 4:47 AM, Rick Mann  wrote:
> > > I'm trying to get my audio cape to work (which is nearly identical to the 
> > > cape that was available for sale). I've had it working to some level of 
> > > success with past kernels (3.1.18), but now I'm on 4.4.6. My existing DTS 
> > > didn't work, so I'm looking at how the BB-BONE-AUDI-02 DTS is written.
> > >
> > > One of the differences is that it doesn't explicitly call out the McASP 
> > > clock frequency like the older one did. Instead, it seems to refer to 
> > > clk_mcasp0. But when I copy the same code into my DTS, I get:
> > >
> > > [  103.180866] of_resolve_phandles: Could not find symbol 'clk_mcasp0'
> > > [  103.187269] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree
> > >
> > > I found it defined by grepping /boot/dtbs. It's in 
> > > /boot/dtbs/4.4.6-bone-rt-r6/am335x-abbbi.dtb. Where can I find the source 
> > > files for these DTBs?
> > >
> > > Is this dtb part of what's loaded by default in 4.4.6-bone-rt-r6? If not, 
> > > can I copy the definition into my
> > >
> > > FWIW, here's my DTS and some output from dmesg: 
> > > http://pastebin.com/niDkWdWV
> > >
> > >
> > > You need to add this to your base *.dtb:
> > >
> > > https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-boneblack-audio.dts#L17-L28
> > >
> > > btw, the one thing i haven't tried, have everything in the clk defined 
> > > except for the gpio and load that as part of the audio overlay..
> > >
> > > side note, we just got audio (cape audio rev b) working a few weeks back, 
> > > so this is relatively new
> >
> > Thanks, Robert. I'll give that a shot. I'm not immediately sure what my 
> > current base *.dtb is, nor how to build a new one and specify that be used. 
> > But maybe I can piggyback off the one you show there.
> 
> Switch to r7, just pushed it out this morning.
> 
> dtb=am335x-boneblack-audio.dtb
> 
> >
> > Out of curiosity, why can't this be done as an overlay (to help me 
> > understand the Device Tree better)?
> >
> 
> Just a bug in the clock driver, the dynamic overlay changes is still very 
> fragile. In most cases moving the driver as a module vs built-in, fixes it 
> right up.. Except this is the clock driver, it needs to be built in..
> 
> Regards,
> 
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.


-- 
Rick



-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Rick Mann]

> On Apr 4, 2016, at 19:14 , Robert Nelson  wrote:
> 
>> Should that be available in apt, or do I need to git pull and build it 
>> myself? I tried "apt-get update && apt-get install -y 
>> linux-image-4.4.6-bone-rt-r7" but no luck. Maybe it just takes a while to 
>> show up?
> 
> It should be out now..  The builders where still a little behind from
> v4.6-rc2 build's..
> 
> Regards,

Thanks, just found it (while my manual build was running :-) ). Good thing, 
too; I forgot how to go from building the kernel to installing the image, dtbs, 
modules, and headers :-)


-- 
Rick Mann
rm...@latencyzero.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[William Hermans]

Probably not. At minimum, not without modifications. The problem I have
here is that I have no one wire devices to test all this stuff I'm
suggesting to you. Otherwise I'd have a fix for you already.

On Mon, Apr 4, 2016 at 6:38 PM,  wrote:

> Thanks for the tip.
>
>
> I tried correcting that line first to:
>
> gpios = < 13 0>;
>
>
> and then to
>
>
> gpios = < 13 0>;
>
>
> I'm not sure which of these is correct, though I would have thought it was 
> gpios = < 13 0>;
>
>
>
> But still no go.
>
>
> Sounds like I need to change to 4.1.
>
>
> I see that RCN's link leads to a bash script that allows
>
> more time for detection?  Could this problem be related to
>
> not enough time being allowed for detection.
>
>
> Would the script work under 3.8, and might it solve the problem?
>
>
> Thanks
>
>
> Matt
>
>
>
> On Tuesday, April 5, 2016 at 10:30:33 AM UTC+10, William Hermans wrote:
>>
>> gpios = < 2 0>
>>
>>  I'm pretty sure is reference to the gpio bank. There is 4 I think
>> for all gpio's on the processor. The two numbers that follow . . . I
>> honestly have no idea either.
>>
>> I can hoever tell you that:
>> pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13,
>> OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */ >;
>>
>> 0x34 is the pin number, and 0x37 is the pin mode. Which peripheral, or
>> GPIO mode, whether it's input, or output, and whether pull up, or pull down
>> is enabled. Pretty much my understanding here is a 32bit field with each
>> bit indicating *something*.
>>
>> On Mon, Apr 4, 2016 at 5:25 PM, REDDING Matthew <
>> matthew...@daf.qld.gov.au> wrote:
>>
>>> Eagle eyes!
>>>
>>>
>>>
>>> I’ll try changing that back and see what happens.
>>>
>>> I must confess, I don’t even know what gpios = < 2 0>; does.
>>>
>>> So I’m not sure where any changes came from.
>>>
>>>
>>>
>>> I think I know what the other line you indicated does.
>>>
>>>
>>>
>>>
>>>
>>> Kind regards
>>>
>>>
>>>
>>>
>>>
>>> Matt Redding, Ph.D.
>>>
>>> Soil Chemist/Geochemist
>>>
>>> AgriScience Queensland
>>>
>>> Queensland DAFF
>>>
>>>
>>>
>>> 0408 787100
>>>
>>> 07 46 88 1372
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] *On
>>> Behalf Of *William Hermans
>>> *Sent:* Tuesday, 5 April 2016 10:22 AM
>>> *To:* beagl...@googlegroups.com
>>> *Subject:* Re: [beagleboard] Re: Troubleshooting one-wire DS18B20
>>> detection on BBB, debian, kernel: 3.8.13-bone70
>>>
>>>
>>>
>>> *Using the modprobe w1-gpio produces no output.*
>>>
>>>
>>>
>>> *Is this where the problem is?*
>>>
>>>
>>>
>>> *Thanks*
>>>
>>>
>>>
>>> *Matt*
>>>
>>> So, I'm not 100% sure what the problem is. I've never used One wire in
>>> linux - ever - And I'm not 100% sure what driver needs to be loaded, if any
>>> for this specific device. I'm just trying my best to help you troubleshoot
>>> the problem, because obviously there is something wrong, if the device does
>>> not show up on several boards, using several devices.
>>>
>>> So Matt, I noticed you've changed the GPIO pin here:
>>>
>>> gpios = < 2 0>;
>>>
>>> But not here:
>>>
>>> pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13,
>>> OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */ >;
>>>
>>> So do keep in mind that I'm no device tree file expert. So I'm not sure
>>> if that is bad, or not. But it *seems* wrong to me. Maybe I'm wrong ?
>>>
>>>
>>>
>>> On Mon, Apr 4, 2016 at 5:14 PM,  wrote:
>>>
>>> Hi William and Peter...
>>>
>>>
>>>
>>> root@beaglebone:~# lsmod
>>> Module  Size  Used by
>>> arc41691  2
>>> zd1211rw   43946  0
>>>
>>> mac80211  424813  1 zd1211rw
>>> cfg80211  354018  2 mac80211,zd1211rw
>>> rfkill 16672  2 cfg80211
>>> g_multi50407  2
>>> libcomposite   15028  1 g_multi
>>> omap_rng4062  0
>>> mt7601Usta639170  0
>>>
>>>
>>>
>>>
>>>
>>> Using the modprobe w1-gpio produces no output.
>>>
>>>
>>>
>>> Is this where the problem is?
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> Matt
>>>
>>>
>>>
>>>
>>> On Tuesday, April 5, 2016 at 10:08:36 AM UTC+10, William Hermans wrote:
>>>
>>> william@beaglebone:~$ sudo modprobe w1-gpio
>>> william@beaglebone:~$ lsmod
>>> Module  Size  Used by
>>> w1_gpio 3069  0
>>> wire   27112  1 w1_gpio
>>> . . .
>>>
>>> *My understanding was that 3.8 and above kernels needed no module,
>>> simply the DTO. It was pre 3.8 kernels that required the kernel module. Or
>>> am I missing something there? Certainly, every page I'm reading referring
>>> to 3.8 kernel 1Wire has absolutely no reference to kernel modules.*
>>>
>>> So, perhaps, but if there is something wrong with the device tree blob
>>> file, the driver wont auto load. Which would give us an indication as to
>>> what's wrong.
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Apr 4, 2016 at 5:01 PM, Peter Lawler  wrote:

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[matthew . redding]

Thanks for the tip.


I tried correcting that line first to:

gpios = < 13 0>;


and then to 


gpios = < 13 0>;


I'm not sure which of these is correct, though I would have thought it was 
gpios = < 13 0>;



But still no go.


Sounds like I need to change to 4.1.


I see that RCN's link leads to a bash script that allows

more time for detection?  Could this problem be related to 

not enough time being allowed for detection.


Would the script work under 3.8, and might it solve the problem?


Thanks


Matt



On Tuesday, April 5, 2016 at 10:30:33 AM UTC+10, William Hermans wrote:
>
> gpios = < 2 0>
>
>  I'm pretty sure is reference to the gpio bank. There is 4 I think 
> for all gpio's on the processor. The two numbers that follow . . . I 
> honestly have no idea either.
>
> I can hoever tell you that:
> pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13, 
> OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */ >;
>
> 0x34 is the pin number, and 0x37 is the pin mode. Which peripheral, or 
> GPIO mode, whether it's input, or output, and whether pull up, or pull down 
> is enabled. Pretty much my understanding here is a 32bit field with each 
> bit indicating *something*.
>
> On Mon, Apr 4, 2016 at 5:25 PM, REDDING Matthew  > wrote:
>
>> Eagle eyes!
>>
>>  
>>
>> I’ll try changing that back and see what happens.
>>
>> I must confess, I don’t even know what gpios = < 2 0>; does.
>>
>> So I’m not sure where any changes came from.
>>
>>  
>>
>> I think I know what the other line you indicated does.
>>
>>  
>>
>>  
>>
>> Kind regards
>>
>>  
>>
>>  
>>
>> Matt Redding, Ph.D.
>>
>> Soil Chemist/Geochemist
>>
>> AgriScience Queensland
>>
>> Queensland DAFF
>>
>>  
>>
>> 0408 787100
>>
>> 07 46 88 1372
>>
>>  
>>
>>  
>>
>>  
>>
>> *From:* beagl...@googlegroups.com  [mailto:
>> beagl...@googlegroups.com ] *On Behalf Of *William Hermans
>> *Sent:* Tuesday, 5 April 2016 10:22 AM
>> *To:* beagl...@googlegroups.com 
>> *Subject:* Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 
>> detection on BBB, debian, kernel: 3.8.13-bone70
>>
>>  
>>
>> *Using the modprobe w1-gpio produces no output.*
>>
>>  
>>
>> *Is this where the problem is?*
>>
>>  
>>
>> *Thanks*
>>
>>  
>>
>> *Matt*
>>
>> So, I'm not 100% sure what the problem is. I've never used One wire in 
>> linux - ever - And I'm not 100% sure what driver needs to be loaded, if any 
>> for this specific device. I'm just trying my best to help you troubleshoot 
>> the problem, because obviously there is something wrong, if the device does 
>> not show up on several boards, using several devices.
>>
>> So Matt, I noticed you've changed the GPIO pin here:
>>
>> gpios = < 2 0>;
>>
>> But not here:
>>
>> pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13, 
>> OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */ >;
>>
>> So do keep in mind that I'm no device tree file expert. So I'm not sure 
>> if that is bad, or not. But it *seems* wrong to me. Maybe I'm wrong ?
>>
>>  
>>
>> On Mon, Apr 4, 2016 at 5:14 PM,  
>> wrote:
>>
>> Hi William and Peter...
>>
>>
>>
>> root@beaglebone:~# lsmod
>> Module  Size  Used by
>> arc41691  2 
>> zd1211rw   43946  0 
>>
>> mac80211  424813  1 zd1211rw
>> cfg80211  354018  2 mac80211,zd1211rw
>> rfkill 16672  2 cfg80211
>> g_multi50407  2 
>> libcomposite   15028  1 g_multi
>> omap_rng4062  0 
>> mt7601Usta639170  0 
>>
>>  
>>
>>  
>>
>> Using the modprobe w1-gpio produces no output.
>>
>>  
>>
>> Is this where the problem is?
>>
>>  
>>
>> Thanks
>>
>>  
>>
>> Matt
>>
>>  
>>
>>
>> On Tuesday, April 5, 2016 at 10:08:36 AM UTC+10, William Hermans wrote:
>>
>> william@beaglebone:~$ sudo modprobe w1-gpio
>> william@beaglebone:~$ lsmod
>> Module  Size  Used by
>> w1_gpio 3069  0
>> wire   27112  1 w1_gpio
>> . . .
>>
>> *My understanding was that 3.8 and above kernels needed no module, simply 
>> the DTO. It was pre 3.8 kernels that required the kernel module. Or am I 
>> missing something there? Certainly, every page I'm reading referring to 3.8 
>> kernel 1Wire has absolutely no reference to kernel modules.*
>>
>> So, perhaps, but if there is something wrong with the device tree blob 
>> file, the driver wont auto load. Which would give us an indication as to 
>> what's wrong.
>>
>>  
>>
>>  
>>
>> On Mon, Apr 4, 2016 at 5:01 PM, Peter Lawler  wrote:
>>
>>
>>
>> On 2016/04/05 9:49 AM, William Hermans wrote:
>>
>>   Ok, so the device tree seems to load but where is
>> the output of lsmod ? It should look something like( more or less ) with
>> hopefully the generic one-wire module also loaded.
>>
>>
>> My understanding was that 3.8 and above kernels needed no module, simply 
>> the DTO. It was pre 3.8 kernels that required the kernel module. Or am I 
>> missing 

Re: [beagleboard] Re: Development setup

[Jacek Radzikowski]

Another take on GPIO problem, not as well documented, but handling for
the user all the conversions between bits and GPIO pins. Also
implements support for I2C and SPI: https://github.com/piranha32/IOoo

Jacek.



On Mon, Apr 4, 2016 at 7:33 PM, Graham  wrote:
> Rob:
>
>  I would read the Molloy book/Website/Videos.
>
> He explains in detail how to set up Eclipse + gcc  cross-compile toolchain.
> under Windows.
> I have also done the same thing on a VM running Ubuntu under windows, or
> directly on a PC running Ubuntu.
>
> Molloy, unfortunately does all of his C  I/O examples via the Linux
> pseudo-file I/O method, which is very slow.
>
> If you are looking for a low level, public domain, C I/O package for GPIO,
> SPI and I2C, try:
> https://github.com/VegetableAvenger/BBBIOlib
>
> If you find a better one, please report back. There are not many out there.
>
> I have had good luck with it running GPIO, high speed SPI transfers, lots of
> I2C etc.
>
> In a tight ON/OFF loop, the fastest I can toggle a GPIO pin using Linux
> pseudo-file I/O is about 6 kHz.
>
> Using BBBIOlib, I can toggle a GPIO pin at about 2.4 MHz, almost a three
> orders of magnitude improvement.
>
> --- Graham
>
> ==
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.



-- 
Given a choice between two theories, take the one which is funnier

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[William Hermans]

The problem is, there are still a few things that do not work properly in
kernel 4.x yet. Or at least the last I heard. It's always worked fine for
me, but I'm a hobbyist experimenter . . .

On Mon, Apr 4, 2016 at 5:42 PM, Peter Lawler  wrote:

>
> On 2016/04/05 10:35 AM, William Hermans wrote:
>
>> No idea if kernel 4.1.x will work for the OP or not.
>>
> Indeed. I would, however, strongly suggest that if it's for work connected
> to op's mail address - Queensland (Australia) Department of Agriculture and
> Fisheries - they move to a 4.1 LTS kernel as it does have much better DTO
> stuff in it etc (from what I've read) and will be far more usable to them.
>
> P.
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone and Chromebook connection

[Paul Wolfson]

>
> Just out of curiosity, which OS image are you using for your Beaglebone?


​It was in the screenshot.​

​  Machinekit Debian Image 2016-03-13
Linux beaglebone 3.8.13-xenomai-r17​

-
Paul Wolfson, Ph.D., TX LPI, #A17473
Dallas Legal Technology
3402 Oak Grove Avenue, Suite 300-A
Dallas, Texas 75204-2353


*214-257-0984 (Tel)214-838-7220 (Fax)Send me an email. *
-
The contents of this email are confidential to the sender and the ordinary
user of the email address to which it was addressed, and may also be
privileged.  If you are not the addressee of the email, you may not copy,
forward, disclose or otherwise use it or any part of it in any form
whatsoever.  If you have received this email in error, please advise the
sender at  214-257-0984.  Thank you.
-

On Mon, Apr 4, 2016 at 7:20 AM,  wrote:

> Hi Paul,
> Thanks for posting this info.
> There might be an issue with my Chromebook then because they network
> doesn't seem to come up. Just out of curiosity, which OS image are you
> using for your Beaglebone?
> Also yesterday after I finished running apt-get upgrade, all of the sudden
> they USB network started working. Of course after I rebooted the Beaglebone
> never came back up again.
> When I get more time, I will play with different Linux images on the
> Beaglebone see if that changes anything.
> Cheers
> Christian
>
>
> On Monday, 4 April 2016 11:57:25 UTC+10, Paul Wolfson wrote:
>>
>> Hi Christian,
>>
>> Out of curiosity I just tried connecting my Samsung Chromebook to my
>> beaglebone using a standard USB cable and it worked fine.  Note below that
>> the Chromebook is getting a DHCP address 192.168.7.1 from the beaglebone,
>> but otherwise it's okay.
>>
>> If you continue to have trouble you can open the Chromebook terminal and
>> type help_advanced.  That will give you access to the Chrome dev shell
>> where you have access to route and dmesg to help in debugging, which will
>> show that there is a route created between 192.168.1.x and 192.168.7.x.
>>
>> crosh> route
>> /0 default via 192.168.1.1 dev mlan0  metric 1
>> /1 192.168.1.0/24 dev mlan0  proto kernel  scope link  src 192.168.1.151
>> /2 192.168.7.0/30 dev eth0  proto kernel  scope link  src 192.168.7.1
>>
>>
>>
>> ​
>>
>> -
>> Paul Wolfson
>> -
>>
>>
>> On Sat, Apr 2, 2016 at 1:41 AM,  wrote:
>>
>>> Hi Wally,
>>> Thanks for your reply.
>>> I'm using the latest Debian image from the downloads sections. Also I
>>> ran apt-get dist-upgrade to make sure it had the latest version of all the
>>> packages.
>>> I need to investigate the 'USB gadget interface'. All I know is that
>>> from the linux side, it seems to be up and running with IP address
>>> 192.168.7.2. From the Chromebook side the interface doesn't seem to come
>>> up. If I manually assign the ip address to 192.168.7.1, I still can't ping
>>> each other.
>>> I imagine that when you say 'wired' connection you mean using a regular
>>> ethernet cable rather than USB. Ethernet works just fine, but it kindof
>>> makes it clunkier than having a Chromebook ->USB->Beaglebone.
>>> Thanks
>>> Christian
>>>
>>> On Saturday, 2 April 2016 03:05:25 UTC+11, Wally Bkg wrote:

 What Beaglebone image are you running?   I've found many of the recent
 images have issues with getting the "USB gadget" Ethernet over USB to work
 reliably.   Without the USB gadget interface the ssh deb...@192.168.7.2
 will not work.  Can you try a wired Ethernet connection?  Then the ssh
 login should work to the IP your router assigns to the Beaglebone.

 On Thursday, March 31, 2016 at 7:47:48 PM UTC-5, christi...@gmail.com
 wrote:
>
> Hi all,
> I'm trying to connect a Beaglebone to a Chromebook without any luck.
> The network connection doesn't seem to get established.
> Only time it worked was when I had to reboot the Chromebook after I
> received an OS update. Once I logged in, the network was up. I didn't
> manage to get the connection up again after that once time.
>
> Thanks for your help.
> Christian
>
 --
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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 

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[Peter Lawler]

On 2016/04/05 10:35 AM, William Hermans wrote:

No idea if kernel 4.1.x will work for the OP or not.
Indeed. I would, however, strongly suggest that if it's for work 
connected to op's mail address - Queensland (Australia) Department of 
Agriculture and Fisheries - they move to a 4.1 LTS kernel as it does 
have much better DTO stuff in it etc (from what I've read) and will be 
far more usable to them.


P.

--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SPI BBB Master, BBB Slave

[Harvey White]

On Mon, 4 Apr 2016 14:54:37 -0700, you wrote:

>If you are using an SPI master, then what you say is correct, but if you are a 
>SPI slave, then some other device is controlling the clock, which means you 
>have to have data available before the clock starts. If there is no delay 
>between packets, then timing is critical.

Quite correct, so the designers of the slave interface reply with what
when the device is not ready?  My suspicion is that it's 0xFF.  I
think they have to deal with this gracefully.

Harvey


>
>Regards,
>John
>> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SPI BBB Master, BBB Slave

[John Syne]

> On Apr 4, 2016, at 4:56 PM, ybeag...@rehut.com wrote:
> 
> On Monday, April 04, 2016 16:05:47 John Syne wrote:
> 
>> Yeah, this is the approach used by the I2C Slave Framework. So
>> traditionally, the McSPI driver registers with the SPI Framework as an SPI
>> Master. Now through DT config, we could have the McSPI driver register with
>> the SPI Framework as an SPI Slave and then the SPI framework registers a
>> callback with the McSPI driver (Slave Provider). On receiving event from
>> the master, McSPI driver calls Custom Driver callback, which responds by
>> writing to McSPI FIFO. Does that sound reasonable?
> 
> Sort of. I'd suggest an alternative (might be implied by what you are saying):
> - Provide a fast callback that does exactly what you are saying.
> - If no fast callback is registered, a slow path callback can be registered. 
> This slow back call back is invoked via a work queue.
Yep, I think we are talking about the same thing. Either call the callback in 
interrupt context, or schedule the callback through a work queue (bottom half). 
> 
> Goal with something like this is to lessen the timing requirement on the 
> driver user.
> 
> The I2C slave side doesn't need this as I2C provides for the slave to slow 
> things down if needed.
Good point because I2C can drag this out until slave does an ack. However, SPI 
slave could respond with a wait response until it has data available. Maybe the 
interrupt routing checks kfifo for a response message and it none exist, send 
wait command. Master retries until it gets the desired response. 
> 
>>> On receive, queue more data for xfer to avoid underruns on the MISO end.
>>> If
>>> nothing is queued by the driver user, put in fix data to keep the McSPI
>>> happy (avoid underruns).
>> 
>> I agree. In the case when the slave driver cannot respond in time, simply
>> send a wait response and have the master retry until successful.
>>> A better implementation may be to use a work queue arrangement to limit
>>> the
>>> exposure of the driver user to time criticality. Probally need to
>>> propagate
>>> the CS (SS) signal up to the driver user to help synchronize things.
>> 
>> The McSPI hardware will take care of this. From what I recall, McSPI does
>> not process SPI signals until Slave Select is true.
> 
> That is not sufficient for a slave. Consider the following usage scenario -
> Protocol is - SS is asserted on a per transaction. First 8 bits clocked in is 
> a command. Additional clocks will read out data. Attempting to read out data 
> beyond what is appropriate for the command will return zeros. Deasserting /SS 
> will stop the current transaction to allow a new transaction to be started.
> 
> Something like that is often used for things that return variable amounts of 
> data. It can also provide a back channel for the master to resync thing.
> 
> Without propagating the /SS state back up to the driver user, the driver 
> would 
> have a hard time synchronizing on the protocol level.
I see your point. Need to do some thinking on this one. So we need some sort of 
state machine?

Regards,
John
> 
> 
> Getting it as a clean interface would definitely benefit from a rewrite
> as
> you described.
 
 If you are willing, perhaps this is a project we can work on together.
>>> 
>>> We can talk about it.
>>> 
 Regards,
 John
 
> 
> 
> 
> -- 
> Hunyue Yau
> http://www.hy-research.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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[Peter Lawler]

On 2016/04/05 10:27 AM, Robert Nelson wrote:

Guys, or just use v4.1.x, i have a nice example using P9.12:

https://github.com/beagleboard/bb.org-overlays/blob/master/examples/BB-W1-P9.12/example.sh

Regards,


Followup:
After moving my data pin from 17 using my attempt at DTO to pin 12 with 
RCN's *and using his example script), my DS18B20 is reading to within 
0.2 degrees of my known working SHT10 sensor so I'm pretty happy about now.


Thanks Robert!

P.

--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[William Hermans]

No idea if kernel 4.1.x will work for the OP or not.

On Mon, Apr 4, 2016 at 5:31 PM, Peter Lawler  wrote:

>
>
> On 2016/04/05 10:27 AM, Robert Nelson wrote:
>
>> Guys, or just use v4.1.x, i have a nice example using P9.12:
>>
>>
>> https://github.com/beagleboard/bb.org-overlays/blob/master/examples/BB-W1-P9.12/example.sh
>>
>>
>> I'm so embarrassed right now. I now remember thinking on Sunday 'I think
> RCN shipped a demo' but never actually chased the thought up...
>
> Will check it out immediately as I am on 4.1.x
>
> THanks!
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[Peter Lawler]

On 2016/04/05 10:27 AM, Robert Nelson wrote:

Guys, or just use v4.1.x, i have a nice example using P9.12:

https://github.com/beagleboard/bb.org-overlays/blob/master/examples/BB-W1-P9.12/example.sh


I'm so embarrassed right now. I now remember thinking on Sunday 'I think 
RCN shipped a demo' but never actually chased the thought up...


Will check it out immediately as I am on 4.1.x

THanks!

--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[William Hermans]

gpios = < 2 0>

 I'm pretty sure is reference to the gpio bank. There is 4 I think
for all gpio's on the processor. The two numbers that follow . . . I
honestly have no idea either.

I can hoever tell you that:
pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13,
OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */ >;

0x34 is the pin number, and 0x37 is the pin mode. Which peripheral, or GPIO
mode, whether it's input, or output, and whether pull up, or pull down is
enabled. Pretty much my understanding here is a 32bit field with each bit
indicating *something*.

On Mon, Apr 4, 2016 at 5:25 PM, REDDING Matthew <
matthew.redd...@daf.qld.gov.au> wrote:

> Eagle eyes!
>
>
>
> I’ll try changing that back and see what happens.
>
> I must confess, I don’t even know what gpios = < 2 0>; does.
>
> So I’m not sure where any changes came from.
>
>
>
> I think I know what the other line you indicated does.
>
>
>
>
>
> Kind regards
>
>
>
>
>
> Matt Redding, Ph.D.
>
> Soil Chemist/Geochemist
>
> AgriScience Queensland
>
> Queensland DAFF
>
>
>
> 0408 787100
>
> 07 46 88 1372
>
>
>
>
>
>
>
> *From:* beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com]
> *On Behalf Of *William Hermans
> *Sent:* Tuesday, 5 April 2016 10:22 AM
> *To:* beagleboard@googlegroups.com
> *Subject:* Re: [beagleboard] Re: Troubleshooting one-wire DS18B20
> detection on BBB, debian, kernel: 3.8.13-bone70
>
>
>
> *Using the modprobe w1-gpio produces no output.*
>
>
>
> *Is this where the problem is?*
>
>
>
> *Thanks*
>
>
>
> *Matt*
>
> So, I'm not 100% sure what the problem is. I've never used One wire in
> linux - ever - And I'm not 100% sure what driver needs to be loaded, if any
> for this specific device. I'm just trying my best to help you troubleshoot
> the problem, because obviously there is something wrong, if the device does
> not show up on several boards, using several devices.
>
> So Matt, I noticed you've changed the GPIO pin here:
>
> gpios = < 2 0>;
>
> But not here:
>
> pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13,
> OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */ >;
>
> So do keep in mind that I'm no device tree file expert. So I'm not sure if
> that is bad, or not. But it *seems* wrong to me. Maybe I'm wrong ?
>
>
>
> On Mon, Apr 4, 2016 at 5:14 PM,  wrote:
>
> Hi William and Peter...
>
>
>
> root@beaglebone:~# lsmod
> Module  Size  Used by
> arc41691  2
> zd1211rw   43946  0
>
> mac80211  424813  1 zd1211rw
> cfg80211  354018  2 mac80211,zd1211rw
> rfkill 16672  2 cfg80211
> g_multi50407  2
> libcomposite   15028  1 g_multi
> omap_rng4062  0
> mt7601Usta639170  0
>
>
>
>
>
> Using the modprobe w1-gpio produces no output.
>
>
>
> Is this where the problem is?
>
>
>
> Thanks
>
>
>
> Matt
>
>
>
>
> On Tuesday, April 5, 2016 at 10:08:36 AM UTC+10, William Hermans wrote:
>
> william@beaglebone:~$ sudo modprobe w1-gpio
> william@beaglebone:~$ lsmod
> Module  Size  Used by
> w1_gpio 3069  0
> wire   27112  1 w1_gpio
> . . .
>
> *My understanding was that 3.8 and above kernels needed no module, simply
> the DTO. It was pre 3.8 kernels that required the kernel module. Or am I
> missing something there? Certainly, every page I'm reading referring to 3.8
> kernel 1Wire has absolutely no reference to kernel modules.*
>
> So, perhaps, but if there is something wrong with the device tree blob
> file, the driver wont auto load. Which would give us an indication as to
> what's wrong.
>
>
>
>
>
> On Mon, Apr 4, 2016 at 5:01 PM, Peter Lawler  wrote:
>
>
>
> On 2016/04/05 9:49 AM, William Hermans wrote:
>
>   Ok, so the device tree seems to load but where is
> the output of lsmod ? It should look something like( more or less ) with
> hopefully the generic one-wire module also loaded.
>
>
> My understanding was that 3.8 and above kernels needed no module, simply
> the DTO. It was pre 3.8 kernels that required the kernel module. Or am I
> missing something there? Certainly, every page I'm reading referring to 3.8
> kernel 1Wire has absolutely no reference to kernel modules.
>
> P.
>
>
>
> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[Robert Nelson]

Guys, or just use v4.1.x, i have a nice example using P9.12:

https://github.com/beagleboard/bb.org-overlays/blob/master/examples/BB-W1-P9.12/example.sh

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.
For more options, visit https://groups.google.com/d/optout.

RE: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[REDDING Matthew]

Eagle eyes!

I’ll try changing that back and see what happens.
I must confess, I don’t even know what gpios = < 2 0>; does.
So I’m not sure where any changes came from.

I think I know what the other line you indicated does.


Kind regards


Matt Redding, Ph.D.
Soil Chemist/Geochemist
AgriScience Queensland
Queensland DAFF

0408 787100
07 46 88 1372



From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of William Hermans
Sent: Tuesday, 5 April 2016 10:22 AM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on 
BBB, debian, kernel: 3.8.13-bone70

Using the modprobe w1-gpio produces no output.

Is this where the problem is?

Thanks

Matt
So, I'm not 100% sure what the problem is. I've never used One wire in linux - 
ever - And I'm not 100% sure what driver needs to be loaded, if any for this 
specific device. I'm just trying my best to help you troubleshoot the problem, 
because obviously there is something wrong, if the device does not show up on 
several boards, using several devices.
So Matt, I noticed you've changed the GPIO pin here:

gpios = < 2 0>;
But not here:
pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13, OMAP_PIN_INPUT_PULLUP 
| OMAP_MUX_MODE7 - w1-gpio */ >;
So do keep in mind that I'm no device tree file expert. So I'm not sure if that 
is bad, or not. But it *seems* wrong to me. Maybe I'm wrong ?

On Mon, Apr 4, 2016 at 5:14 PM, 
> wrote:
Hi William and Peter...


root@beaglebone:~# lsmod
Module  Size  Used by
arc41691  2
zd1211rw   43946  0

mac80211  424813  1 zd1211rw
cfg80211  354018  2 mac80211,zd1211rw
rfkill 16672  2 cfg80211
g_multi50407  2
libcomposite   15028  1 g_multi
omap_rng4062  0
mt7601Usta639170  0


Using the modprobe w1-gpio produces no output.

Is this where the problem is?

Thanks

Matt


On Tuesday, April 5, 2016 at 10:08:36 AM UTC+10, William Hermans wrote:
william@beaglebone:~$ sudo modprobe w1-gpio
william@beaglebone:~$ lsmod
Module  Size  Used by
w1_gpio 3069  0
wire   27112  1 w1_gpio
. . .
My understanding was that 3.8 and above kernels needed no module, simply the 
DTO. It was pre 3.8 kernels that required the kernel module. Or am I missing 
something there? Certainly, every page I'm reading referring to 3.8 kernel 
1Wire has absolutely no reference to kernel modules.
So, perhaps, but if there is something wrong with the device tree blob file, 
the driver wont auto load. Which would give us an indication as to what's wrong.


On Mon, Apr 4, 2016 at 5:01 PM, Peter Lawler 
> wrote:


On 2016/04/05 9:49 AM, William Hermans wrote:
  Ok, so the device tree seems to load but where is
the output of lsmod ? It should look something like( more or less ) with
hopefully the generic one-wire module also loaded.

My understanding was that 3.8 and above kernels needed no module, simply the 
DTO. It was pre 3.8 kernels that required the kernel module. Or am I missing 
something there? Certainly, every page I'm reading referring to 3.8 kernel 
1Wire has absolutely no reference to kernel modules.

P.


--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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.
For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google 
Groups "BeagleBoard" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/beagleboard/nT93pfbvCzQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
The information in this email together with any attachments is intended only 
for the person or entity to which it is addressed and may contain confidential 
and/or privileged material. There is no waiver of any confidentiality/privilege 
by your inadvertent receipt of this material. 
Any form of review, 

RE: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[REDDING Matthew]

OK, I don't think this is a module I've got control over:

root@beaglebone:~# modprobe -r w1-gpio
FATAL: Module w1_gpio is builtin.
root@beaglebone:~# modprobe -v w1-gpio
<>

-Original Message-
From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Peter Lawler
Sent: Tuesday, 5 April 2016 10:19 AM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on 
BBB, debian, kernel: 3.8.13-bone70



On 2016/04/05 10:14 AM, matthew.redd...@daf.qld.gov.au wrote:
> Hi William and Peter...
> 
>
> Using the modprobe w1-gpio produces no output.
>
'modprobe -v w1-gpio' would produce more detail (to test, use modprobe -r 
w1-gpio to unload the module first).

However I'm just reading up and what William refers to seems to be if the DTO 
loads properly it SHOULD load up the module, thus the module not loading is a 
symptom of the DTO not being correct.

I'm currently looking at some other stuff that's indicating that maybe my 
wiring isn't the best.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google 
Groups "BeagleBoard" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/beagleboard/nT93pfbvCzQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
The information in this email together with any attachments is intended only 
for the person or entity to which it is addressed and may contain confidential 
and/or privileged material. There is no waiver of any confidentiality/privilege 
by your inadvertent receipt of this material. 
Any form of review, disclosure, modification, distribution and/or publication 
of this email message is prohibited, unless as a necessary part of Departmental 
business.
If you have received this message in error, you are asked to inform the sender 
as quickly as possible and delete this message and any copies of this message 
from your computer and/or your computer system network.
--

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[William Hermans]

>
> *Using the modprobe w1-gpio produces no output.*
>
> *Is this where the problem is?*
>
> *Thanks*
>
> *Matt*

So, I'm not 100% sure what the problem is. I've never used One wire in
linux - ever - And I'm not 100% sure what driver needs to be loaded, if any
for this specific device. I'm just trying my best to help you troubleshoot
the problem, because obviously there is something wrong, if the device does
not show up on several boards, using several devices.

So Matt, I noticed you've changed the GPIO pin here:

gpios = < 2 0>;

But not here:
pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13,
OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */ >;

So do keep in mind that I'm no device tree file expert. So I'm not sure if
that is bad, or not. But it *seems* wrong to me. Maybe I'm wrong ?

On Mon, Apr 4, 2016 at 5:14 PM,  wrote:

> Hi William and Peter...
>
>
> root@beaglebone:~# lsmod
> Module  Size  Used by
> arc41691  2
> zd1211rw   43946  0
>
> mac80211  424813  1 zd1211rw
> cfg80211  354018  2 mac80211,zd1211rw
> rfkill 16672  2 cfg80211
> g_multi50407  2
> libcomposite   15028  1 g_multi
> omap_rng4062  0
> mt7601Usta639170  0
>
>
> Using the modprobe w1-gpio produces no output.
>
> Is this where the problem is?
>
> Thanks
>
> Matt
>
>
> On Tuesday, April 5, 2016 at 10:08:36 AM UTC+10, William Hermans wrote:
>>
>> william@beaglebone:~$ sudo modprobe w1-gpio
>> william@beaglebone:~$ lsmod
>> Module  Size  Used by
>> w1_gpio 3069  0
>> wire   27112  1 w1_gpio
>> . . .
>>
>> *My understanding was that 3.8 and above kernels needed no module, simply
>> the DTO. It was pre 3.8 kernels that required the kernel module. Or am I
>> missing something there? Certainly, every page I'm reading referring to 3.8
>> kernel 1Wire has absolutely no reference to kernel modules.*
>>
>> So, perhaps, but if there is something wrong with the device tree blob
>> file, the driver wont auto load. Which would give us an indication as to
>> what's wrong.
>>
>>
>> On Mon, Apr 4, 2016 at 5:01 PM, Peter Lawler  wrote:
>>
>>>
>>>
>>> On 2016/04/05 9:49 AM, William Hermans wrote:
>>>
   Ok, so the device tree seems to load but where is
 the output of lsmod ? It should look something like( more or less ) with
 hopefully the generic one-wire module also loaded.

>>>
>>> My understanding was that 3.8 and above kernels needed no module, simply
>>> the DTO. It was pre 3.8 kernels that required the kernel module. Or am I
>>> missing something there? Certainly, every page I'm reading referring to 3.8
>>> kernel 1Wire has absolutely no reference to kernel modules.
>>>
>>> P.
>>>
>>>
>>> --
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] troubleshooting DS18B20 temperature sensors on BBB debian V 7.8

[matthew . redding]

Hi All GPIO Gurus,

Thanks very much for taking the time to read this.


I've been following the documented processes (e.g. 
http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/
)
to get a 1 wire interface up and running to read several DS18B20 
temperature sensors.

I've got a .dts to load, and the overlay is showing in slots, but the 
sensors (I've used several 5 different ones) are never detected.

I'm using the device tree overlay from the above web site, and the same 
hardware layout.


using dmesg | grep bone_cape suggests the overlay loaded successfully:


[8.697062] bone-capemgr bone_capemgr.9: part_number 'w1', version 'N/A'
[8.697138] bone-capemgr bone_capemgr.9: slot #7: generic override
[8.697155] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
data at slot 7
[8.697171] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
Name,00A0,Override Manuf,w1'
[8.697259] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
number/version based 'w1-00A0.dtbo
[8.697274] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
'w1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[8.727950] bone-capemgr bone_capemgr.9: slot #7: dtbo 'w1-00A0.dtbo' 
loaded; converting to live tree
[8.728198] bone-capemgr bone_capemgr.9: slot #7: #2 overlays
[8.757662] bone-capemgr bone_capemgr.9: slot #7: Applied #2 overlays.



and the appropriate overlay appears in the slots:


root@beaglebone:~# cat /sys/devices/bone_capemgr.9/slots
 0: 54:PF--- 
 1: 55:PF--- 
 2: 56:PF--- 
 3: 57:PF--- 
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,w1

However, when I look in the appropriate directory for the device file, no 
devices appear:


root@beaglebone:~# ls /sys/bus/w1/devices/w1_bus_master1
driver  power  subsystem  uevent  w1_master_add  w1_master_attempts 
 w1_master_max_slave_count  w1_master_name  w1_master_pointer 
 w1_master_pullup  w1_master_remove  w1_master_search 
 w1_master_slave_count  w1_master_slaves  w1_master_timeout


I've used two different BBB's, and 5 different sensors, singly or in 
combination. None of them. Volatages across the grnd and power pins are 
showing at the expected approx 3.3 volts, as is voltage across the DQ-grnd.

Kernel version is:

3.8.13-bone70

I've run out of troubleshooting tests -- and would appreciate some 
suggestions as to what else to look for.

Thanks for your help!

Kind regards

Matt


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone and Chromebook connection

[christiant1971]

Hi Paul,
Thanks for posting this info.
There might be an issue with my Chromebook then because they network 
doesn't seem to come up. Just out of curiosity, which OS image are you 
using for your Beaglebone?
Also yesterday after I finished running apt-get upgrade, all of the sudden 
they USB network started working. Of course after I rebooted the Beaglebone 
never came back up again.
When I get more time, I will play with different Linux images on the 
Beaglebone see if that changes anything.
Cheers
Christian


On Monday, 4 April 2016 11:57:25 UTC+10, Paul Wolfson wrote:
>
> Hi Christian,
>
> Out of curiosity I just tried connecting my Samsung Chromebook to my 
> beaglebone using a standard USB cable and it worked fine.  Note below that 
> the Chromebook is getting a DHCP address 192.168.7.1 from the beaglebone, 
> but otherwise it's okay.
>
> If you continue to have trouble you can open the Chromebook terminal and 
> type help_advanced.  That will give you access to the Chrome dev shell 
> where you have access to route and dmesg to help in debugging, which will 
> show that there is a route created between 192.168.1.x and 192.168.7.x.
>
> crosh> route
> /0 default via 192.168.1.1 dev mlan0  metric 1
> /1 192.168.1.0/24 dev mlan0  proto kernel  scope link  src 192.168.1.151
> /2 192.168.7.0/30 dev eth0  proto kernel  scope link  src 192.168.7.1
>
>
>
> ​
>
> -
> Paul Wolfson
> -
>
>
> On Sat, Apr 2, 2016 at 1:41 AM,  
> wrote:
>
>> Hi Wally,
>> Thanks for your reply.
>> I'm using the latest Debian image from the downloads sections. Also I ran 
>> apt-get dist-upgrade to make sure it had the latest version of all the 
>> packages.
>> I need to investigate the 'USB gadget interface'. All I know is that from 
>> the linux side, it seems to be up and running with IP address 192.168.7.2. 
>> From the Chromebook side the interface doesn't seem to come up. If I 
>> manually assign the ip address to 192.168.7.1, I still can't ping each 
>> other.
>> I imagine that when you say 'wired' connection you mean using a regular 
>> ethernet cable rather than USB. Ethernet works just fine, but it kindof 
>> makes it clunkier than having a Chromebook ->USB->Beaglebone.
>> Thanks
>> Christian
>>
>> On Saturday, 2 April 2016 03:05:25 UTC+11, Wally Bkg wrote:
>>>
>>> What Beaglebone image are you running?   I've found many of the recent 
>>> images have issues with getting the "USB gadget" Ethernet over USB to work 
>>> reliably.   Without the USB gadget interface the ssh deb...@192.168.7.2 
>>> will not work.  Can you try a wired Ethernet connection?  Then the ssh 
>>> login should work to the IP your router assigns to the Beaglebone.
>>>
>>> On Thursday, March 31, 2016 at 7:47:48 PM UTC-5, christi...@gmail.com 
>>> wrote:

 Hi all,
 I'm trying to connect a Beaglebone to a Chromebook without any luck. 
 The network connection doesn't seem to get established.
 Only time it worked was when I had to reboot the Chromebook after I 
 received an OS update. Once I logged in, the network was up. I didn't 
 manage to get the connection up again after that once time.

 Thanks for your help.
 Christian

>>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

RE: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[REDDING Matthew]

Hi William and Peter again…
Can it actually be a module problem if it is creating the directories for the 
devices one wire bus, just not detecting the devices?

Thanks!

Matt

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of REDDING Matthew
Sent: Tuesday, 5 April 2016 10:14 AM
To: BeagleBoard
Subject: Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on 
BBB, debian, kernel: 3.8.13-bone70

Hi William and Peter...


root@beaglebone:~# lsmod
Module  Size  Used by
arc41691  2
zd1211rw   43946  0

mac80211  424813  1 zd1211rw
cfg80211  354018  2 mac80211,zd1211rw
rfkill 16672  2 cfg80211
g_multi50407  2
libcomposite   15028  1 g_multi
omap_rng4062  0
mt7601Usta639170  0


Using the modprobe w1-gpio produces no output.

Is this where the problem is?

Thanks

Matt


On Tuesday, April 5, 2016 at 10:08:36 AM UTC+10, William Hermans wrote:
william@beaglebone:~$ sudo modprobe w1-gpio
william@beaglebone:~$ lsmod
Module  Size  Used by
w1_gpio 3069  0
wire   27112  1 w1_gpio
. . .
My understanding was that 3.8 and above kernels needed no module, simply the 
DTO. It was pre 3.8 kernels that required the kernel module. Or am I missing 
something there? Certainly, every page I'm reading referring to 3.8 kernel 
1Wire has absolutely no reference to kernel modules.
So, perhaps, but if there is something wrong with the device tree blob file, 
the driver wont auto load. Which would give us an indication as to what's wrong.


On Mon, Apr 4, 2016 at 5:01 PM, Peter Lawler  
wrote:


On 2016/04/05 9:49 AM, William Hermans wrote:
  Ok, so the device tree seems to load but where is
the output of lsmod ? It should look something like( more or less ) with
hopefully the generic one-wire module also loaded.

My understanding was that 3.8 and above kernels needed no module, simply the 
DTO. It was pre 3.8 kernels that required the kernel module. Or am I missing 
something there? Certainly, every page I'm reading referring to 3.8 kernel 
1Wire has absolutely no reference to kernel modules.

P.


--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google 
Groups "BeagleBoard" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/beagleboard/nT93pfbvCzQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
The information in this email together with any attachments is intended only 
for the person or entity to which it is addressed and may contain confidential 
and/or privileged material. There is no waiver of any confidentiality/privilege 
by your inadvertent receipt of this material. 
Any form of review, disclosure, modification, distribution and/or publication 
of this email message is prohibited, unless as a necessary part of Departmental 
business.
If you have received this message in error, you are asked to inform the sender 
as quickly as possible and delete this message and any copies of this message 
from your computer and/or your computer system network.
--

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[Peter Lawler]

On 2016/04/05 10:14 AM, matthew.redd...@daf.qld.gov.au wrote:

Hi William and Peter...


Using the modprobe w1-gpio produces no output.

'modprobe -v w1-gpio' would produce more detail (to test, use modprobe 
-r w1-gpio to unload the module first).


However I'm just reading up and what William refers to seems to be if 
the DTO loads properly it SHOULD load up the module, thus the module not 
loading is a symptom of the DTO not being correct.


I'm currently looking at some other stuff that's indicating that maybe 
my wiring isn't the best.


--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[matthew . redding]

Hi William and Peter...


root@beaglebone:~# lsmod
Module  Size  Used by
arc41691  2 
zd1211rw   43946  0 

mac80211  424813  1 zd1211rw
cfg80211  354018  2 mac80211,zd1211rw
rfkill 16672  2 cfg80211
g_multi50407  2 
libcomposite   15028  1 g_multi
omap_rng4062  0 
mt7601Usta639170  0 


Using the modprobe w1-gpio produces no output.

Is this where the problem is?

Thanks

Matt


On Tuesday, April 5, 2016 at 10:08:36 AM UTC+10, William Hermans wrote:
>
> william@beaglebone:~$ sudo modprobe w1-gpio
> william@beaglebone:~$ lsmod
> Module  Size  Used by
> w1_gpio 3069  0
> wire   27112  1 w1_gpio
> . . .
>
> *My understanding was that 3.8 and above kernels needed no module, simply 
> the DTO. It was pre 3.8 kernels that required the kernel module. Or am I 
> missing something there? Certainly, every page I'm reading referring to 3.8 
> kernel 1Wire has absolutely no reference to kernel modules.*
>
> So, perhaps, but if there is something wrong with the device tree blob 
> file, the driver wont auto load. Which would give us an indication as to 
> what's wrong.
>
>
> On Mon, Apr 4, 2016 at 5:01 PM, Peter Lawler  > wrote:
>
>>
>>
>> On 2016/04/05 9:49 AM, William Hermans wrote:
>>
>>>   Ok, so the device tree seems to load but where is
>>> the output of lsmod ? It should look something like( more or less ) with
>>> hopefully the generic one-wire module also loaded.
>>>
>>
>> My understanding was that 3.8 and above kernels needed no module, simply 
>> the DTO. It was pre 3.8 kernels that required the kernel module. Or am I 
>> missing something there? Certainly, every page I'm reading referring to 3.8 
>> kernel 1Wire has absolutely no reference to kernel modules.
>>
>> P.
>>
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[William Hermans]

Another thing I was noticing after greping the config, at least for my
kernel version. Is that there is no Dallas One Wire kernel module for that
specific device. So it could be that it is compiled in statically. I've
been in menu config several times, and have noticed a lot of Dallas One
Wire drivers, but could not say if that one exists in the kernel, or not .
. .

On Mon, Apr 4, 2016 at 5:08 PM, William Hermans  wrote:

> william@beaglebone:~$ sudo modprobe w1-gpio
> william@beaglebone:~$ lsmod
> Module  Size  Used by
> w1_gpio 3069  0
> wire   27112  1 w1_gpio
> . . .
>
> *My understanding was that 3.8 and above kernels needed no module, simply
> the DTO. It was pre 3.8 kernels that required the kernel module. Or am I
> missing something there? Certainly, every page I'm reading referring to 3.8
> kernel 1Wire has absolutely no reference to kernel modules.*
>
> So, perhaps, but if there is something wrong with the device tree blob
> file, the driver wont auto load. Which would give us an indication as to
> what's wrong.
>
>
> On Mon, Apr 4, 2016 at 5:01 PM, Peter Lawler 
> wrote:
>
>>
>>
>> On 2016/04/05 9:49 AM, William Hermans wrote:
>>
>>>   Ok, so the device tree seems to load but where is
>>> the output of lsmod ? It should look something like( more or less ) with
>>> hopefully the generic one-wire module also loaded.
>>>
>>
>> My understanding was that 3.8 and above kernels needed no module, simply
>> the DTO. It was pre 3.8 kernels that required the kernel module. Or am I
>> missing something there? Certainly, every page I'm reading referring to 3.8
>> kernel 1Wire has absolutely no reference to kernel modules.
>>
>> P.
>>
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[Peter Lawler]

On 2016/04/05 10:08 AM, William Hermans wrote:

So, perhaps, but if there is something wrong with the device tree blob
file, the driver wont auto load. Which would give us an indication as to
what's wrong.


ahhh... *grabs another coffee*

--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[William Hermans]

william@beaglebone:~$ sudo modprobe w1-gpio
william@beaglebone:~$ lsmod
Module  Size  Used by
w1_gpio 3069  0
wire   27112  1 w1_gpio
. . .

*My understanding was that 3.8 and above kernels needed no module, simply
the DTO. It was pre 3.8 kernels that required the kernel module. Or am I
missing something there? Certainly, every page I'm reading referring to 3.8
kernel 1Wire has absolutely no reference to kernel modules.*

So, perhaps, but if there is something wrong with the device tree blob
file, the driver wont auto load. Which would give us an indication as to
what's wrong.


On Mon, Apr 4, 2016 at 5:01 PM, Peter Lawler  wrote:

>
>
> On 2016/04/05 9:49 AM, William Hermans wrote:
>
>>   Ok, so the device tree seems to load but where is
>> the output of lsmod ? It should look something like( more or less ) with
>> hopefully the generic one-wire module also loaded.
>>
>
> My understanding was that 3.8 and above kernels needed no module, simply
> the DTO. It was pre 3.8 kernels that required the kernel module. Or am I
> missing something there? Certainly, every page I'm reading referring to 3.8
> kernel 1Wire has absolutely no reference to kernel modules.
>
> P.
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[Peter Lawler]

On 2016/04/05 9:49 AM, William Hermans wrote:

  Ok, so the device tree seems to load but where is
the output of lsmod ? It should look something like( more or less ) with
hopefully the generic one-wire module also loaded.


My understanding was that 3.8 and above kernels needed no module, simply 
the DTO. It was pre 3.8 kernels that required the kernel module. Or am I 
missing something there? Certainly, every page I'm reading referring to 
3.8 kernel 1Wire has absolutely no reference to kernel modules.


P.

--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SPI BBB Master, BBB Slave

[ybeagle3]

On Monday, April 04, 2016 16:05:47 John Syne wrote:

> Yeah, this is the approach used by the I2C Slave Framework. So
> traditionally, the McSPI driver registers with the SPI Framework as an SPI
> Master. Now through DT config, we could have the McSPI driver register with
> the SPI Framework as an SPI Slave and then the SPI framework registers a
> callback with the McSPI driver (Slave Provider). On receiving event from
> the master, McSPI driver calls Custom Driver callback, which responds by
> writing to McSPI FIFO. Does that sound reasonable?

Sort of. I'd suggest an alternative (might be implied by what you are saying):
- Provide a fast callback that does exactly what you are saying.
- If no fast callback is registered, a slow path callback can be registered. 
This slow back call back is invoked via a work queue.

Goal with something like this is to lessen the timing requirement on the 
driver user.

The I2C slave side doesn't need this as I2C provides for the slave to slow 
things down if needed.

> > On receive, queue more data for xfer to avoid underruns on the MISO end.
> > If
> > nothing is queued by the driver user, put in fix data to keep the McSPI
> > happy (avoid underruns).
> 
> I agree. In the case when the slave driver cannot respond in time, simply
> send a wait response and have the master retry until successful.
> > A better implementation may be to use a work queue arrangement to limit
> > the
> > exposure of the driver user to time criticality. Probally need to
> > propagate
> > the CS (SS) signal up to the driver user to help synchronize things.
> 
> The McSPI hardware will take care of this. From what I recall, McSPI does
> not process SPI signals until Slave Select is true.

That is not sufficient for a slave. Consider the following usage scenario -
Protocol is - SS is asserted on a per transaction. First 8 bits clocked in is 
a command. Additional clocks will read out data. Attempting to read out data 
beyond what is appropriate for the command will return zeros. Deasserting /SS 
will stop the current transaction to allow a new transaction to be started.

Something like that is often used for things that return variable amounts of 
data. It can also provide a back channel for the master to resync thing.

Without propagating the /SS state back up to the driver user, the driver would 
have a hard time synchronizing on the protocol level.


> >>> Getting it as a clean interface would definitely benefit from a rewrite
> >>> as
> >>> you described.
> >> 
> >> If you are willing, perhaps this is a project we can work on together.
> > 
> > We can talk about it.
> > 
> >> Regards,
> >> John
> >> 



-- 
Hunyue Yau
http://www.hy-research.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[William Hermans]

>
> *Hi William,*
>
> *Please see my original post and you will see the outputs from each of
> these commands.*
> *The driver appears to be loaded perfectly. *
>

Seems I missed that part. Ok, so the device tree seems to load but where is
the output of lsmod ? It should look something like( more or less ) with
hopefully the generic one-wire module also loaded.

william@beaglebone:~$ lsmod
Module  Size  Used by
bnep   13297  2
rfcomm 52320  0
bluetooth 394459  10 bnep,rfcomm
nfsd  220016  2
sg 24111  0
uas11682  0
usb_storage47695  1 uas
evdev   7956  0
tda998x11683  1
tilcdc 27869  0
omap_rng4346  0
omap_aes   13033  0
rng_core7233  1 omap_rng
omap_sham  19152  0
drm_kms_helper106705  3 tda998x,tilcdc
uio_pdrv_genirq 3313  0
leds_gpio   3102  0
uio 8350  1 uio_pdrv_genirq


On Mon, Apr 4, 2016 at 4:31 PM,  wrote:

> Hi William,
>
> Please see my original post and you will see the outputs from each of
> these commands.
> The driver appears to be loaded perfectly.
>
> On Tuesday, April 5, 2016 at 9:26:37 AM UTC+10, William Hermans wrote:
>>
>> Starters for troubleshooting. After issuing the commands this person
>> suggest on that site . . .
>>
>> cp w1-00A0.dtbo /lib/firmware
>> echo w1 > /sys/devices/bone_capemgr.9/slots
>>
>> You should run dmesg | grep w1 to see what the output is. Passed that,
>> are you sure you have the one wire driver loaded ? I've never actually used
>> one wire on Linux personally, but there is a generic one-wire kernel module
>> that I've read about . . .
>>
>>
>> On Mon, Apr 4, 2016 at 3:19 PM, Peter Lawler  wrote:
>>
>>>
>>> On Tuesday, 5 April 2016 08:04:14 UTC+10, matthew...@daf.qld.gov.au
>>> wrote:

 Hello BBB Gurus,


>>> Hi there, I offer no help really... but
>>>
>>> heh funny you raise this as I'm trying to get this sensor to 'work'
>>> under 4.1.18 by first trying to follow the 3.8 way of doing things then
>>> learning how the new way of things is done then intending to forward port.
>>>
>>> Maybe there's someone out there with a 'simple' guide to porting DTO's
>>> and the like (I'm up to the stage of trying to read the "w1_slave" figure
>>> but that just doesn't exist in 4.1.18 so yeah lots more reading for me to
>>> go...). Just figured I'd add a 'me too idk what's going on' so I can keep a
>>> more easy track of this thread :)
>>>
>>> Cheers,
>>>
>>> Pete.
>>>
>>>
>>>
>>>
>>>
 --
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Development setup

[William Hermans]

>
> *Rob:*
>
> * I would read the Molloy book/Website/Videos.*
>
> *He explains in detail how to set up Eclipse + gcc  cross-compile
> toolchain. under Windows.*
> *I have also done the same thing on a VM running Ubuntu under windows, or
> directly on a PC running Ubuntu.*
>
> *Molloy, unfortunately does all of his C  I/O examples via the Linux
> pseudo-file I/O method, which is very slow.*
>
> *If you are looking for a low level, public domain, C I/O package for
> GPIO, SPI and I2C, try:*
> *https://github.com/VegetableAvenger/BBBIOlib
> *
>
> *If you find a better one, please report back. There are not many out
> there.*
>
> *I have had good luck with it running GPIO, high speed SPI transfers, lots
> of I2C etc.*
>
> *In a tight ON/OFF loop, the fastest I can toggle a GPIO pin using Linux
> pseudo-file I/O is about 6 kHz.*
>
> *Using BBBIOlib, I can toggle a GPIO pin at about 2.4 MHz, almost a three
> orders of magnitude improvement.*
>

I will agree that the Derek Molloy book (exploring beaglebone )is a fairly
good start into the tools, and techniques used for the software used with
the hardware. But it is by no means an exhaustive resource when it comes to
many things.

BBBIOlib is also no longer maintained*. *which means it could have issues
working with the newer kernels*. *The good news however is the it basically
looks like an abstraction for /dev/mem/ and mmap(). Which surely if Rob has
had 30 years embedded programing experience he'll have zero problems
twiddling around directly with the device registers.

On Mon, Apr 4, 2016 at 4:33 PM, Graham  wrote:

> Rob:
>
>  I would read the Molloy book/Website/Videos.
>
> He explains in detail how to set up Eclipse + gcc  cross-compile
> toolchain. under Windows.
> I have also done the same thing on a VM running Ubuntu under windows, or
> directly on a PC running Ubuntu.
>
> Molloy, unfortunately does all of his C  I/O examples via the Linux
> pseudo-file I/O method, which is very slow.
>
> If you are looking for a low level, public domain, C I/O package for GPIO,
> SPI and I2C, try:
> https://github.com/VegetableAvenger/BBBIOlib
>
> If you find a better one, please report back. There are not many out there.
>
> I have had good luck with it running GPIO, high speed SPI transfers, lots
> of I2C etc.
>
> In a tight ON/OFF loop, the fastest I can toggle a GPIO pin using Linux
> pseudo-file I/O is about 6 kHz.
>
> Using BBBIOlib, I can toggle a GPIO pin at about 2.4 MHz, almost a three
> orders of magnitude improvement.
>
> --- Graham
>
> ==
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Development setup

[Graham]

Rob:

 I would read the Molloy book/Website/Videos.

He explains in detail how to set up Eclipse + gcc  cross-compile toolchain. 
under Windows.
I have also done the same thing on a VM running Ubuntu under windows, or 
directly on a PC running Ubuntu.

Molloy, unfortunately does all of his C  I/O examples via the Linux 
pseudo-file I/O method, which is very slow.

If you are looking for a low level, public domain, C I/O package for GPIO, 
SPI and I2C, try:
https://github.com/VegetableAvenger/BBBIOlib

If you find a better one, please report back. There are not many out there.

I have had good luck with it running GPIO, high speed SPI transfers, lots 
of I2C etc.

In a tight ON/OFF loop, the fastest I can toggle a GPIO pin using Linux 
pseudo-file I/O is about 6 kHz.

Using BBBIOlib, I can toggle a GPIO pin at about 2.4 MHz, almost a three 
orders of magnitude improvement.

--- Graham

==

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Control and monitor Beaglebone from azure

[William Hermans]

>
> *Beaglebone and Azure are not a problem, Azure is a generic Microsoft
> branded cloud resource, which you can run locally.*
>

>From a technological perspective perhaps. But on an IP owned by whom
perspective it's a huge problem for many.

On Mon, Apr 4, 2016 at 10:52 AM, Paul Wolfson  wrote:

> Beaglebone and Azure are not a problem, Azure is a generic Microsoft
> branded cloud resource, which you can run locally.
>
> For reference, I have a mixed stack of Linux and Windows servers running
> on a Microsoft Hyper-V Server stack.  Node.js and C#.net (mono) are common
> across all the platforms.  There is no charge for the basic hyper-V server,
> you just pay for the Microsoft licensed products you have running on it.
> There is no limit to the Linux resources you have running.Unless you
> want Visual Studio supporting Windows 10 IoT  or SQL Server there is no
> compelling need for Microsoft anything.  Libvirt and KVM are a good
> substitute for Hyper-V.
>
> Generic Hyper-V Server SKU:
>  10586.0.151029-1700.TH2_RELEASE_SERVERHYPERCORE_OEM_X64FRE_EN-US
>
> I haven't found anything on Azure that I can't already do locally using a
> stack of Microsoft and Linux servers and desktops except for the big data
> analytics offerings.  If you need access to Microsoft products as a
> developer, you can subscribe to one of their MAPS programs.
>
> On Sunday, April 3, 2016 at 5:55:05 PM UTC-4, Sean McMahon wrote:
>>
>> Hmm Not much response.
>>
>> I came across this :
>> https://www.microsoft.com/en-gb/server-cloud/internet-of-things/azure-iot-suite.aspx
>>
>> Anyone tried it out?
>>
>> On Monday, 28 March 2016 14:59:33 UTC+1, Sean McMahon wrote:
>>>
>>> Hi,
>>>
>>> I'm looking to talk to my beaglebone over an azure virtual machine,
>>> (external network).
>>>
>>> Are there any good tutorials on how to control a beaglebone from the web.
>>>
>>> I've been searching the web for about three hours and haven't found
>>> anything suitable yet.
>>>
>>> Thanks,
>>> Seán
>>>
>> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[matthew . redding]

Hi William,

Please see my original post and you will see the outputs from each of these 
commands.
The driver appears to be loaded perfectly. 

On Tuesday, April 5, 2016 at 9:26:37 AM UTC+10, William Hermans wrote:
>
> Starters for troubleshooting. After issuing the commands this person 
> suggest on that site . . .
>
> cp w1-00A0.dtbo /lib/firmware
> echo w1 > /sys/devices/bone_capemgr.9/slots
>
> You should run dmesg | grep w1 to see what the output is. Passed that, 
> are you sure you have the one wire driver loaded ? I've never actually used 
> one wire on Linux personally, but there is a generic one-wire kernel module 
> that I've read about . . .
>
>
> On Mon, Apr 4, 2016 at 3:19 PM, Peter Lawler  > wrote:
>
>>
>> On Tuesday, 5 April 2016 08:04:14 UTC+10, matthew...@daf.qld.gov.au 
>> wrote:
>>>
>>> Hello BBB Gurus,
>>>
>>>
>> Hi there, I offer no help really... but 
>>
>> heh funny you raise this as I'm trying to get this sensor to 'work' under 
>> 4.1.18 by first trying to follow the 3.8 way of doing things then learning 
>> how the new way of things is done then intending to forward port.
>>
>> Maybe there's someone out there with a 'simple' guide to porting DTO's 
>> and the like (I'm up to the stage of trying to read the "w1_slave" figure 
>> but that just doesn't exist in 4.1.18 so yeah lots more reading for me to 
>> go...). Just figured I'd add a 'me too idk what's going on' so I can keep a 
>> more easy track of this thread :)
>>
>> Cheers,
>>
>> Pete.
>>
>>
>>
>>
>>
>>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[William Hermans]

Starters for troubleshooting. After issuing the commands this person
suggest on that site . . .

cp w1-00A0.dtbo /lib/firmware
echo w1 > /sys/devices/bone_capemgr.9/slots

You should run dmesg | grep w1 to see what the output is. Passed that, are
you sure you have the one wire driver loaded ? I've never actually used one
wire on Linux personally, but there is a generic one-wire kernel module
that I've read about . . .


On Mon, Apr 4, 2016 at 3:19 PM, Peter Lawler  wrote:

>
> On Tuesday, 5 April 2016 08:04:14 UTC+10, matthew...@daf.qld.gov.au wrote:
>>
>> Hello BBB Gurus,
>>
>>
> Hi there, I offer no help really... but
>
> heh funny you raise this as I'm trying to get this sensor to 'work' under
> 4.1.18 by first trying to follow the 3.8 way of doing things then learning
> how the new way of things is done then intending to forward port.
>
> Maybe there's someone out there with a 'simple' guide to porting DTO's and
> the like (I'm up to the stage of trying to read the "w1_slave" figure but
> that just doesn't exist in 4.1.18 so yeah lots more reading for me to
> go...). Just figured I'd add a 'me too idk what's going on' so I can keep a
> more easy track of this thread :)
>
> Cheers,
>
> Pete.
>
>
>
>
>
>> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Development setup

[William Hermans]

>
> *Thanks John, i will :) I am bare metal embbeded developer for 30+ years
> but getting started with (embedded) linux is not really self explaining ;)*
>

are you familiar with gcc at all ? I'd actually learn gcc, make, autotools
etc, and use an NFS share, with a local( to Windows ) text editor. That is
if I undestand your situation correctly. You're using Windows as your main
workstation OS ?

Anyway, once you understand the basics of the gcc toolchain, and all that
you can pretty much pick any IDE you want, if one is really required. I've
been programming many years myself ( since the early 90's ) and actually
find my self using command line tools more, and more often. Maybe you're in
the same boat, maybe not . . .

On Mon, Apr 4, 2016 at 3:46 PM, 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> I'm exactly the same in experience .  If you wrote an app for bare metal
> you would have the advantage of understanding every thing below it with
> your background . Writing a Linux app for myself that access the lowest
> level without understanding the underlying complexity is something I'm
> unwilling to do. If your just writing a Linux app you probably less apt to
> experience pain using a make file.  You didn't mention why an IDE  ?
>
> Sent from Yahoo Mail on Android
> 
>
> On Mon, Apr 4, 2016 at 5:45 PM, Rob van Schelven
>  wrote:
> Thanks John, i will :) I am bare metal embbeded developer for 30+ years
> but getting started with (embedded) linux is not really self explaining ;)
>
> Op maandag 4 april 2016 21:40:46 UTC+2 schreef Rob van Schelven:
>>
>> Hi all,
>>
>> Does someone know if there is any information available to setup a
>> development environment (IDE) running under MS Windows or Ubuntu (in
>> virtual machine under windows) to develop C/C++ code for the BBB
>>
>> Thanks
>> Rob
>>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SPI BBB Master, BBB Slave

[John Syne]

> On Apr 4, 2016, at 3:25 PM, ybeag...@rehut.com wrote:
> 
> On Monday, April 04, 2016 13:13:48 John Syne wrote:
>>> On Apr 4, 2016, at 12:49 PM, ybeag...@rehut.com wrote:
>>> 
>>> On Monday, April 04, 2016 12:04:56 John Syne wrote:
 I’m not sure that is correct. The master will normally send a command and
 then your slave driver will have to respond with relevant packet. The
 protocol will have to be well defined.
>>> 
>>> None of that is required by SPI (in the most basic form  it is just a
>>> shift
>>> register). What I was alluding it protocol games that be played like
>>> Master
>>> writes byte to slave and waits for an active GPIO before anymore clocking.
>>> Or even a dumb (unidirectional) protocol where the master waits for a
>>> GPIO to go active before clocking out data.
>> 
>> Well, technically, that is correct, because data is shifted in and out at
>> the same time, using the same clock. However, when the master hasn’t
>> requested a specific data, what do you respond with? Random data? Perhaps
>> if it was just streaming channel data, then I can see your point.
> 
> Since SPI is always full duplex, it comes down to protocol definition. It 
> could be a fixed pattern, 0, 0xff, or random, or undefined data during the 
> initial clock out for the command byte. 
> 
>>> In contrast, doing it like a lot of common devices where you can clock in
>>> a
>>> byte (i.e. register address or a command) and expect data after another 8
>>> clocks could impose some very tight timing requirements.
>> 
>> I agree, this could be very difficult to achieve using interrupts, but using
>> DMA that should be pretty simple. That presupposes that the data is already
>> in the DMA buffer and this is some streaming interface I spoke of
>> previously. Streaming channel data into the BBB using DMA would also be
>> pretty simple. Exchanging of short master/slave command/response would need
>> interrupt processing. Maybe using fixed size messages and using fifo
>> watermark might limit the interrupt overhead.
 However, you are correct that the
 SPI slave must be preconfigured and waiting for the master to start
 clocking the interface. The problem with the SPI framework and in
 particular the McSPI driver is that they is written around a master
 implementation and adding slave support is almost impossible. It would be
 easier to write a slave McSPI from scratch. The I2C slave framework might
 be a good guide on how to make this work.
>>> 
>>> There are 2 things being mixed up here -
>>> Merely grafting on slave functionality isn't too difficult with the
>>> current
>>> McSPI driver (that's what I did). The main thing this gets you is a lot of
>>> the driver registration and McSPI init is reused; this is a big hack but
>>> it gets data flowing.
>> 
>> Can you share that with me? I would be interested to see how you managed to
>> do this. I’ve looked at this several times and each time my head wants to
>> explode.
> 
> Unfortunately, I cannot share that code (paperwork reasons, owned by 
> customer). The differences between slave/master from a pure driver's point of 
> view is a few register settings. A naive way of doing this is -
> 
> Initialize as slave
> Have a callback in the driver that queue's data for transmission. 
> Driver user (aka data consumer) registers a receive callback that is invoked 
> when data comes in.  Driver user is responsible for ignoring data when 
> appropriate. 
Yeah, this is the approach used by the I2C Slave Framework. So traditionally, 
the McSPI driver registers with the SPI Framework as an SPI Master. Now through 
DT config, we could have the McSPI driver register with the SPI Framework as an 
SPI Slave and then the SPI framework registers a callback with the McSPI driver 
(Slave Provider). On receiving event from the master, McSPI driver calls Custom 
Driver callback, which responds by writing to McSPI FIFO. Does that sound 
reasonable? 
> 
> On receive, queue more data for xfer to avoid underruns on the MISO end. If 
> nothing is queued by the driver user, put in fix data to keep the McSPI happy 
> (avoid underruns). 
I agree. In the case when the slave driver cannot respond in time, simply send 
a wait response and have the master retry until successful. 
> 
> A better implementation may be to use a work queue arrangement to limit the 
> exposure of the driver user to time criticality. Probally need to propagate 
> the CS (SS) signal up to the driver user to help synchronize things.
The McSPI hardware will take care of this. From what I recall, McSPI does not 
process SPI signals until Slave Select is true. 
> 
>>> Getting it as a clean interface would definitely benefit from a rewrite as
>>> you described.
>> 
>> If you are willing, perhaps this is a project we can work on together.
> 
> We can talk about it. 
>> 
>> Regards,
>> John
>> 
 Regards,
 John
 
> On Apr 4, 2016, at 11:27 AM, ybeag...@rehut.com wrote:
> 
> Getting 

Re: [beagleboard] Re: Development setup

['Mark Lazarewicz' via BeagleBoard]

I'm exactly the same in experience .  If you wrote an app for bare metal you 
would have the advantage of understanding every thing below it with your 
background . Writing a Linux app for myself that access the lowest level 
without understanding the underlying complexity is something I'm unwilling to 
do. If your just writing a Linux app you probably less apt to experience pain 
using a make file.  You didn't mention why an IDE  ?

Sent from Yahoo Mail on Android 
 
  On Mon, Apr 4, 2016 at 5:45 PM, Rob van Schelven wrote:   
Thanks John, i will :) I am bare metal embbeded developer for 30+ years but 
getting started with (embedded) linux is not really self explaining ;)

Op maandag 4 april 2016 21:40:46 UTC+2 schreef Rob van Schelven:
Hi all,
Does someone know if there is any information available to setup a development 
environment (IDE) running under MS Windows or Ubuntu (in virtual machine under 
windows) to develop C/C++ code for the BBB
ThanksRob


-- 
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.
For more options, visit https://groups.google.com/d/optout.
  

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Rick Mann]

> On Apr 4, 2016, at 13:36 , Robert Nelson  wrote:
> 
> > > You need to add this to your base *.dtb:
> > >
> > > https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-boneblack-audio.dts#L17-L28
> > >
> > > btw, the one thing i haven't tried, have everything in the clk defined 
> > > except for the gpio and load that as part of the audio overlay..
> > >
> > > side note, we just got audio (cape audio rev b) working a few weeks back, 
> > > so this is relatively new
> >
> > Thanks, Robert. I'll give that a shot. I'm not immediately sure what my 
> > current base *.dtb is, nor how to build a new one and specify that be used. 
> > But maybe I can piggyback off the one you show there.
> 
> Switch to r7, just pushed it out this morning.

Should that be available in apt, or do I need to git pull and build it myself? 
I tried "apt-get update && apt-get install -y linux-image-4.4.6-bone-rt-r7" but 
no luck. Maybe it just takes a while to show up?

Thanks!

> 
> dtb=am335x-boneblack-audio.dtb
> 
> >
> > Out of curiosity, why can't this be done as an overlay (to help me 
> > understand the Device Tree better)?
> >
> 
> Just a bug in the clock driver, the dynamic overlay changes is still very 
> fragile. In most cases moving the driver as a module vs built-in, fixes it 
> right up.. Except this is the clock driver, it needs to be built in..
> 
> Regards,
> 
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.


-- 
Rick



-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SPI BBB Master, BBB Slave

[ybeagle3]

On Monday, April 04, 2016 13:13:48 John Syne wrote:
> > On Apr 4, 2016, at 12:49 PM, ybeag...@rehut.com wrote:
> > 
> > On Monday, April 04, 2016 12:04:56 John Syne wrote:
> >> I’m not sure that is correct. The master will normally send a command and
> >> then your slave driver will have to respond with relevant packet. The
> >> protocol will have to be well defined.
> > 
> > None of that is required by SPI (in the most basic form  it is just a
> > shift
> > register). What I was alluding it protocol games that be played like
> > Master
> > writes byte to slave and waits for an active GPIO before anymore clocking.
> > Or even a dumb (unidirectional) protocol where the master waits for a
> > GPIO to go active before clocking out data.
> 
> Well, technically, that is correct, because data is shifted in and out at
> the same time, using the same clock. However, when the master hasn’t
> requested a specific data, what do you respond with? Random data? Perhaps
> if it was just streaming channel data, then I can see your point.

Since SPI is always full duplex, it comes down to protocol definition. It 
could be a fixed pattern, 0, 0xff, or random, or undefined data during the 
initial clock out for the command byte. 

> > In contrast, doing it like a lot of common devices where you can clock in
> > a
> > byte (i.e. register address or a command) and expect data after another 8
> > clocks could impose some very tight timing requirements.
> 
> I agree, this could be very difficult to achieve using interrupts, but using
> DMA that should be pretty simple. That presupposes that the data is already
> in the DMA buffer and this is some streaming interface I spoke of
> previously. Streaming channel data into the BBB using DMA would also be
> pretty simple. Exchanging of short master/slave command/response would need
> interrupt processing. Maybe using fixed size messages and using fifo
> watermark might limit the interrupt overhead.
> >> However, you are correct that the
> >> SPI slave must be preconfigured and waiting for the master to start
> >> clocking the interface. The problem with the SPI framework and in
> >> particular the McSPI driver is that they is written around a master
> >> implementation and adding slave support is almost impossible. It would be
> >> easier to write a slave McSPI from scratch. The I2C slave framework might
> >> be a good guide on how to make this work.
> > 
> > There are 2 things being mixed up here -
> > Merely grafting on slave functionality isn't too difficult with the
> > current
> > McSPI driver (that's what I did). The main thing this gets you is a lot of
> > the driver registration and McSPI init is reused; this is a big hack but
> > it gets data flowing.
> 
> Can you share that with me? I would be interested to see how you managed to
> do this. I’ve looked at this several times and each time my head wants to
> explode.

Unfortunately, I cannot share that code (paperwork reasons, owned by 
customer). The differences between slave/master from a pure driver's point of 
view is a few register settings. A naive way of doing this is -

Initialize as slave
Have a callback in the driver that queue's data for transmission. 
Driver user (aka data consumer) registers a receive callback that is invoked 
when data comes in.  Driver user is responsible for ignoring data when 
appropriate. 

On receive, queue more data for xfer to avoid underruns on the MISO end. If 
nothing is queued by the driver user, put in fix data to keep the McSPI happy 
(avoid underruns). 

A better implementation may be to use a work queue arrangement to limit the 
exposure of the driver user to time criticality. Probally need to propagate 
the CS (SS) signal up to the driver user to help synchronize things.

> > Getting it as a clean interface would definitely benefit from a rewrite as
> > you described.
> 
> If you are willing, perhaps this is a project we can work on together.

We can talk about it. 
> 
> Regards,
> John
> 
> >> Regards,
> >> John
> >> 
> >>> On Apr 4, 2016, at 11:27 AM, ybeag...@rehut.com wrote:
> >>> 
> >>> Getting it to work is not hard. (Had it working for a project.) To get
> >>> to
> >>> work reliably at a high clock rate requires debugging the DMA or working
> >>> out a protocol where timing isn't as tricky. As a slave the master can
> >>> start clocking at anytime and unless the FIFO (or DMA) is preloaded with
> >>> the entire packet the master wants, you will need to respond to the
> >>> interrupt before an underrun occurs.
> >>> 
> >>> The bigger barrier is a framework for SPI slave.
> >>> 
> >>> On Monday, March 28, 2016 09:14:38 Yaron Yzhak Lederman wrote:
>  Thank you very much about clarifying this point !
>  
>  I don't think that I can allocate enough time to dive into what John
>  described - I assume that at some stage there will be such a driver or
>  other form of such support
>  
>  Thanks for now
>  
>  On Sun, Mar 27, 2016 at 11:29 PM, 

[beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[Peter Lawler]

On Tuesday, 5 April 2016 08:04:14 UTC+10, matthew...@daf.qld.gov.au wrote:
>
> Hello BBB Gurus,
>
>
Hi there, I offer no help really... but 

heh funny you raise this as I'm trying to get this sensor to 'work' under 
4.1.18 by first trying to follow the 3.8 way of doing things then learning 
how the new way of things is done then intending to forward port.

Maybe there's someone out there with a 'simple' guide to porting DTO's and 
the like (I'm up to the stage of trying to read the "w1_slave" figure but 
that just doesn't exist in 4.1.18 so yeah lots more reading for me to 
go...). Just figured I'd add a 'me too idk what's going on' so I can keep a 
more easy track of this thread :)

Cheers,

Pete.





>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[matthew . redding]

Hello BBB Gurus,

Summary, having loaded up the device tree overlay, correctly (?) and 
identifying that the overlay is indeed loaded, the pin configured, and the 
circuit correct (all according to
http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/
 
), my BBB will not detect any of the DS18B20's that I connect (I've tried 
5).
I've tried a second BBB, with the same result.

I'm after suggestions to troubleshoot this further --as I have basically 
run aground at this point!

Some detail:

kernel:
3.8.13-bone70

Device tree overlay:


/*
* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
* Modified  by Russell Senior from the weather cape's DTS file.
* Minor formatting by C W Rose.
*/
/dts-v1/;
/plugin/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "BB-W1";
version = "00A0";

exclusive-use = "P8.11";

fragment@0 {
target = <_pinmux>;
__overlay__ {
 bb_w1_pins: pinmux_bb_w1_pins {
 pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13, 
OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */ >;
 };
};
};

fragment@1 {
target = <>;
__overlay__ {
onewire@0 {
compatible  = "w1-gpio";
status  = "okay";
pinctrl-names   = "default";
pinctrl-0   = <_w1_pins>;
gpios = < 2 0>;
};
};
};
};


Relevant output from dmesg:  


[8.697062] bone-capemgr bone_capemgr.9: part_number 'w1', version 'N/A'
[8.697138] bone-capemgr bone_capemgr.9: slot #7: generic override
[8.697155] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
data at slot 7
[8.697171] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
Name,00A0,Override Manuf,w1'
[8.697259] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
number/version based 'w1-00A0.dtbo
[8.697274] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
'w1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[8.727950] bone-capemgr bone_capemgr.9: slot #7: dtbo 'w1-00A0.dtbo' 
loaded; converting to live tree
[8.728198] bone-capemgr bone_capemgr.9: slot #7: #2 overlays
[8.757662] bone-capemgr bone_capemgr.9: slot #7: Applied #2 overlays.

Slots:


root@beaglebone:~# cat /sys/devices/bone_capemgr.9/slots
 0: 54:PF--- 
 1: 55:PF--- 
 2: 56:PF--- 
 3: 57:PF--- 
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,w1

It's not seeing any of the sensors:


root@beaglebone:~# ls /sys/bus/w1/devices/w1_bus_master1
driver  power  subsystem  uevent  w1_master_add  w1_master_attempts 
 w1_master_max_slave_count  w1_master_name  w1_master_pointer 
 w1_master_pullup  w1_master_remove  w1_master_search 
 w1_master_slave_count  w1_master_slaves  w1_master_timeout

Voltages across the DQ and ground pin of the DS18B20's is just under 3.3 V, 
and a bit higher across the power to grnd pin.
So pullup appears correct.

Could someone suggest some further troubleshooting approaches?
Hey, I'll take solutions as well!

Thanks for your help.


Kind regards

Matt

 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Development setup

[John Syne]

Then you are where I was probably 10 years ago. Fortunately there are good 
references around that will make your life much easier. Also, you have chosen 
one of the best platforms to work on and this user group has alway been really 
helpful. Best advice, is to always explain what you are trying to do, what 
results you see and most important, always list your kernel version and Debian 
version. 

Regards,
John




> On Apr 4, 2016, at 2:45 PM, Rob van Schelven  wrote:
> 
> Thanks John, i will :) I am bare metal embbeded developer for 30+ years but 
> getting started with (embedded) linux is not really self explaining ;)
> 
> Op maandag 4 april 2016 21:40:46 UTC+2 schreef Rob van Schelven:
> Hi all,
> 
> Does someone know if there is any information available to setup a 
> development environment (IDE) running under MS Windows or Ubuntu (in virtual 
> machine under windows) to develop C/C++ code for the BBB
> 
> Thanks
> Rob
> 
> -- 
> 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 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SPI BBB Master, BBB Slave

[John Syne]

> On Apr 4, 2016, at 2:42 PM, Harvey White  wrote:
> 
> On Mon, 4 Apr 2016 13:13:48 -0700, you wrote:
> 
>> 
>> 
>>> On Apr 4, 2016, at 12:49 PM, ybeag...@rehut.com wrote:
>>> 
>>> On Monday, April 04, 2016 12:04:56 John Syne wrote:
 I’m not sure that is correct. The master will normally send a command and
 then your slave driver will have to respond with relevant packet. The
 protocol will have to be well defined.
>>> 
>>> None of that is required by SPI (in the most basic form  it is just a shift 
>>> register). What I was alluding it protocol games that be played like Master 
>>> writes byte to slave and waits for an active GPIO before anymore clocking. 
>>> Or 
>>> even a dumb (unidirectional) protocol where the master waits for a GPIO to 
>>> go 
>>> active before clocking out data. 
>> Well, technically, that is correct, because data is shifted in and out at 
>> the same time, using the same clock. However, when the master hasn’t 
>> requested a specific data, what do you respond with? Random data? Perhaps if 
>> it was just streaming channel data, then I can see your point. 
> 
> Data that is shifted back into the master is generally a known
> quantity, generally 0xFF.
> 
> I haven't run into a device that requires data to be sent within a
> certain amount of time.  Generally, you don't have to always run at
> the maximum, although there's sometimes a minimum.
> 
> I've been debugging SPI stuff on another platform, and the time
> between bytes did not seem to be significant if it were held up by the
> debugger.
If you are using an SPI master, then what you say is correct, but if you are a 
SPI slave, then some other device is controlling the clock, which means you 
have to have data available before the clock starts. If there is no delay 
between packets, then timing is critical.

Regards,
John
> 
>>> 
>>> In contrast, doing it like a lot of common devices where you can clock in a 
>>> byte (i.e. register address or a command) and expect data after another 8 
>>> clocks could impose some very tight timing requirements.
>> I agree, this could be very difficult to achieve using interrupts, but using 
>> DMA that should be pretty simple. That presupposes that the data is already 
>> in the DMA buffer and this is some streaming interface I spoke of 
>> previously. Streaming channel data into the BBB using DMA would also be 
>> pretty simple. Exchanging of short master/slave command/response would need 
>> interrupt processing. Maybe using fixed size messages and using fifo 
>> watermark might limit the interrupt overhead. 
> 
> IF you're dealing with a streaming interface, then the timing is
> imposed by the data stream output, and all the timing relaxations have
> limits.
> 
> 
> Harvey
> 
>>> 
>>> 
 However, you are correct that the
 SPI slave must be preconfigured and waiting for the master to start
 clocking the interface. The problem with the SPI framework and in
 particular the McSPI driver is that they is written around a master
 implementation and adding slave support is almost impossible. It would be
 easier to write a slave McSPI from scratch. The I2C slave framework might
 be a good guide on how to make this work.
>>> 
>>> There are 2 things being mixed up here -
>>> Merely grafting on slave functionality isn't too difficult with the current 
>>> McSPI driver (that's what I did). The main thing this gets you is a lot of 
>>> the 
>>> driver registration and McSPI init is reused; this is a big hack but it 
>>> gets 
>>> data flowing.
>> Can you share that with me? I would be interested to see how you managed to 
>> do this. I’ve looked at this several times and each time my head wants to 
>> explode. 
>>> 
>>> Getting it as a clean interface would definitely benefit from a rewrite as 
>>> you 
>>> described.
>> If you are willing, perhaps this is a project we can work on together. 
>> 
>> Regards,
>> John
 
 Regards,
 John
> 
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SPI BBB Master, BBB Slave

[Harvey White]

On Mon, 4 Apr 2016 13:13:48 -0700, you wrote:

>
>
>> On Apr 4, 2016, at 12:49 PM, ybeag...@rehut.com wrote:
>> 
>> On Monday, April 04, 2016 12:04:56 John Syne wrote:
>>> I’m not sure that is correct. The master will normally send a command and
>>> then your slave driver will have to respond with relevant packet. The
>>> protocol will have to be well defined.
>> 
>> None of that is required by SPI (in the most basic form  it is just a shift 
>> register). What I was alluding it protocol games that be played like Master 
>> writes byte to slave and waits for an active GPIO before anymore clocking. 
>> Or 
>> even a dumb (unidirectional) protocol where the master waits for a GPIO to 
>> go 
>> active before clocking out data. 
>Well, technically, that is correct, because data is shifted in and out at the 
>same time, using the same clock. However, when the master hasn’t requested a 
>specific data, what do you respond with? Random data? Perhaps if it was just 
>streaming channel data, then I can see your point. 

Data that is shifted back into the master is generally a known
quantity, generally 0xFF.

I haven't run into a device that requires data to be sent within a
certain amount of time.  Generally, you don't have to always run at
the maximum, although there's sometimes a minimum.

I've been debugging SPI stuff on another platform, and the time
between bytes did not seem to be significant if it were held up by the
debugger.

>> 
>> In contrast, doing it like a lot of common devices where you can clock in a 
>> byte (i.e. register address or a command) and expect data after another 8 
>> clocks could impose some very tight timing requirements.
>I agree, this could be very difficult to achieve using interrupts, but using 
>DMA that should be pretty simple. That presupposes that the data is already in 
>the DMA buffer and this is some streaming interface I spoke of previously. 
>Streaming channel data into the BBB using DMA would also be pretty simple. 
>Exchanging of short master/slave command/response would need interrupt 
>processing. Maybe using fixed size messages and using fifo watermark might 
>limit the interrupt overhead. 

IF you're dealing with a streaming interface, then the timing is
imposed by the data stream output, and all the timing relaxations have
limits.


Harvey

>> 
>> 
>>> However, you are correct that the
>>> SPI slave must be preconfigured and waiting for the master to start
>>> clocking the interface. The problem with the SPI framework and in
>>> particular the McSPI driver is that they is written around a master
>>> implementation and adding slave support is almost impossible. It would be
>>> easier to write a slave McSPI from scratch. The I2C slave framework might
>>> be a good guide on how to make this work.
>> 
>> There are 2 things being mixed up here -
>> Merely grafting on slave functionality isn't too difficult with the current 
>> McSPI driver (that's what I did). The main thing this gets you is a lot of 
>> the 
>> driver registration and McSPI init is reused; this is a big hack but it gets 
>> data flowing.
>Can you share that with me? I would be interested to see how you managed to do 
>this. I’ve looked at this several times and each time my head wants to 
>explode. 
>> 
>> Getting it as a clean interface would definitely benefit from a rewrite as 
>> you 
>> described.
>If you are willing, perhaps this is a project we can work on together. 
>
>Regards,
>John
>>> 
>>> Regards,
>>> John


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Development setup

[John Syne]

I would recommend getting Derek Molloy’s book which covers everything you need. 
Search Google for Derek Molloy who has a nice website that also covers several 
of these topics. His youtube video’s are excellent.

Regards,
John




> On Apr 4, 2016, at 2:33 PM, Rob van Schelven  wrote:
> 
> RE: From user space or kernel module?
> 
> Sorry i am real new to linux. My intention is to create an executable that 
> access low level IO. I assume this is user space. In any case not a device 
> driver or so..
> 
> 
> Op maandag 4 april 2016 21:40:46 UTC+2 schreef Rob van Schelven:
> Hi all,
> 
> Does someone know if there is any information available to setup a 
> development environment (IDE) running under MS Windows or Ubuntu (in virtual 
> machine under windows) to develop C/C++ code for the BBB
> 
> Thanks
> Rob
> 
> -- 
> 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 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] IO Effecting Multiple Pins

[Jared McIntyre]

When I pull certain gpio pins down, other pins are briefly pulled down for 
just a moment. I'm thinking this is a configuration issue, but I can't 
figure out why (I'm fairly certain I've locked things down correctly in the 
cape manager).

I'm using P9_11, P9_12, P9_13, P9_15, P9_23, P9_24, P9_26, and P9_27 all 
set to output with pull  up. I've used the prebuilt cape configurations 
found here: 
https://github.com/nomel/beaglebone/blob/master/gpio-header/README.md and 
enabled the pull up state.

I also have SPI 0, HDMI, and eMMC installed in the cape manager.

Any thoughts on what could cause these other pins to briefly drop?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Development setup

[Rob van Schelven]

RE: From user space or kernel module?

Sorry i am real new to linux. My intention is to create an executable that 
access low level IO. I assume this is user space. In any case not a device 
driver or so..


Op maandag 4 april 2016 21:40:46 UTC+2 schreef Rob van Schelven:
>
> Hi all,
>
> Does someone know if there is any information available to setup a 
> development environment (IDE) running under MS Windows or Ubuntu (in 
> virtual machine under windows) to develop C/C++ code for the BBB
>
> Thanks
> Rob
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Development setup

[Robert Nelson]

Not 100%, from the blog and videos, it looks like a user space with kernel
hooks.
On Apr 4, 2016 4:07 PM, "John Syne"  wrote:

> From user space or kernel module?
>
> Regards,
> John
>
>
>
>
> On Apr 4, 2016, at 2:06 PM, Robert Nelson  wrote:
>
>
> On Apr 4, 2016 2:40 PM, "Rob van Schelven"  wrote:
> >
> > Hi all,
> >
> > Does someone know if there is any information available to setup a
> development environment (IDE) running under MS Windows or Ubuntu (in
> virtual machine under windows) to develop C/C++ code for the BBB
>
> https://msdn.microsoft.com/en-us/commandline/wsl/about
>
> This isn't ready yet, but might be useful for you windows developers..
>
> Regards,
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Development setup

[John Syne]

>From user space or kernel module?

Regards,
John




> On Apr 4, 2016, at 2:06 PM, Robert Nelson  wrote:
> 
> 
> On Apr 4, 2016 2:40 PM, "Rob van Schelven"  > wrote:
> >
> > Hi all,
> >
> > Does someone know if there is any information available to setup a 
> > development environment (IDE) running under MS Windows or Ubuntu (in 
> > virtual machine under windows) to develop C/C++ code for the BBB
> 
> https://msdn.microsoft.com/en-us/commandline/wsl/about 
> 
> This isn't ready yet, but might be useful for you windows developers..
> 
> Regards,
> 
> 
> -- 
> 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 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Development setup

[Robert Nelson]

On Apr 4, 2016 2:40 PM, "Rob van Schelven"  wrote:
>
> Hi all,
>
> Does someone know if there is any information available to setup a
development environment (IDE) running under MS Windows or Ubuntu (in
virtual machine under windows) to develop C/C++ code for the BBB

https://msdn.microsoft.com/en-us/commandline/wsl/about

This isn't ready yet, but might be useful for you windows developers..

Regards,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Development setup

[Rob van Schelven]

Thanks John!

Do you know if there's a dedicated C/C++ library available to access the 
GPIO/SPI/I2C

Thanks, Rob

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Robert Nelson]

On Apr 4, 2016 3:17 PM, "Rick Mann"  wrote:
>
>
> > On Apr 4, 2016, at 06:57 , Robert Nelson 
wrote:
> >
> >
> >
> > On Mon, Apr 4, 2016 at 8:41 AM, Robert Nelson 
wrote:
> >
> >
> > On Mon, Apr 4, 2016 at 4:47 AM, Rick Mann  wrote:
> > I'm trying to get my audio cape to work (which is nearly identical to
the cape that was available for sale). I've had it working to some level of
success with past kernels (3.1.18), but now I'm on 4.4.6. My existing DTS
didn't work, so I'm looking at how the BB-BONE-AUDI-02 DTS is written.
> >
> > One of the differences is that it doesn't explicitly call out the McASP
clock frequency like the older one did. Instead, it seems to refer to
clk_mcasp0. But when I copy the same code into my DTS, I get:
> >
> > [  103.180866] of_resolve_phandles: Could not find symbol 'clk_mcasp0'
> > [  103.187269] bone_capemgr bone_capemgr: slot #4: Failed to resolve
tree
> >
> > I found it defined by grepping /boot/dtbs. It's in
/boot/dtbs/4.4.6-bone-rt-r6/am335x-abbbi.dtb. Where can I find the source
files for these DTBs?
> >
> > Is this dtb part of what's loaded by default in 4.4.6-bone-rt-r6? If
not, can I copy the definition into my
> >
> > FWIW, here's my DTS and some output from dmesg:
http://pastebin.com/niDkWdWV
> >
> >
> > You need to add this to your base *.dtb:
> >
> >
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-boneblack-audio.dts#L17-L28
> >
> > btw, the one thing i haven't tried, have everything in the clk defined
except for the gpio and load that as part of the audio overlay..
> >
> > side note, we just got audio (cape audio rev b) working a few weeks
back, so this is relatively new
>
> Thanks, Robert. I'll give that a shot. I'm not immediately sure what my
current base *.dtb is, nor how to build a new one and specify that be used.
But maybe I can piggyback off the one you show there.

Switch to r7, just pushed it out this morning.

dtb=am335x-boneblack-audio.dtb

>
> Out of curiosity, why can't this be done as an overlay (to help me
understand the Device Tree better)?
>

Just a bug in the clock driver, the dynamic overlay changes is still very
fragile. In most cases moving the driver as a module vs built-in, fixes it
right up.. Except this is the clock driver, it needs to be built in..

Regards,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Development setup

[John Syne]

Eclipse, Code Composer Studio (CCSV6) and ARM DS5 all do a pretty decent job.

Regards,
John




> On Apr 4, 2016, at 12:40 PM, Rob van Schelven  wrote:
> 
> Hi all,
> 
> Does someone know if there is any information available to setup a 
> development environment (IDE) running under MS Windows or Ubuntu (in virtual 
> machine under windows) to develop C/C++ code for the BBB
> 
> Thanks
> Rob
> 
> -- 
> 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 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Rick Mann]

> On Apr 4, 2016, at 06:57 , Robert Nelson  wrote:
> 
> 
> 
> On Mon, Apr 4, 2016 at 8:41 AM, Robert Nelson  wrote:
> 
> 
> On Mon, Apr 4, 2016 at 4:47 AM, Rick Mann  wrote:
> I'm trying to get my audio cape to work (which is nearly identical to the 
> cape that was available for sale). I've had it working to some level of 
> success with past kernels (3.1.18), but now I'm on 4.4.6. My existing DTS 
> didn't work, so I'm looking at how the BB-BONE-AUDI-02 DTS is written.
> 
> One of the differences is that it doesn't explicitly call out the McASP clock 
> frequency like the older one did. Instead, it seems to refer to clk_mcasp0. 
> But when I copy the same code into my DTS, I get:
> 
> [  103.180866] of_resolve_phandles: Could not find symbol 'clk_mcasp0'
> [  103.187269] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree
> 
> I found it defined by grepping /boot/dtbs. It's in 
> /boot/dtbs/4.4.6-bone-rt-r6/am335x-abbbi.dtb. Where can I find the source 
> files for these DTBs?
> 
> Is this dtb part of what's loaded by default in 4.4.6-bone-rt-r6? If not, can 
> I copy the definition into my
> 
> FWIW, here's my DTS and some output from dmesg: http://pastebin.com/niDkWdWV
> 
> 
> You need to add this to your base *.dtb:
> 
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-boneblack-audio.dts#L17-L28
> 
> btw, the one thing i haven't tried, have everything in the clk defined except 
> for the gpio and load that as part of the audio overlay..
> 
> side note, we just got audio (cape audio rev b) working a few weeks back, so 
> this is relatively new

Thanks, Robert. I'll give that a shot. I'm not immediately sure what my current 
base *.dtb is, nor how to build a new one and specify that be used. But maybe I 
can piggyback off the one you show there.

Out of curiosity, why can't this be done as an overlay (to help me understand 
the Device Tree better)?

Thanks!


-- 
Rick Mann
rm...@latencyzero.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SPI BBB Master, BBB Slave

[John Syne]

> On Apr 4, 2016, at 12:49 PM, ybeag...@rehut.com wrote:
> 
> On Monday, April 04, 2016 12:04:56 John Syne wrote:
>> I’m not sure that is correct. The master will normally send a command and
>> then your slave driver will have to respond with relevant packet. The
>> protocol will have to be well defined.
> 
> None of that is required by SPI (in the most basic form  it is just a shift 
> register). What I was alluding it protocol games that be played like Master 
> writes byte to slave and waits for an active GPIO before anymore clocking. Or 
> even a dumb (unidirectional) protocol where the master waits for a GPIO to go 
> active before clocking out data. 
Well, technically, that is correct, because data is shifted in and out at the 
same time, using the same clock. However, when the master hasn’t requested a 
specific data, what do you respond with? Random data? Perhaps if it was just 
streaming channel data, then I can see your point. 
> 
> In contrast, doing it like a lot of common devices where you can clock in a 
> byte (i.e. register address or a command) and expect data after another 8 
> clocks could impose some very tight timing requirements.
I agree, this could be very difficult to achieve using interrupts, but using 
DMA that should be pretty simple. That presupposes that the data is already in 
the DMA buffer and this is some streaming interface I spoke of previously. 
Streaming channel data into the BBB using DMA would also be pretty simple. 
Exchanging of short master/slave command/response would need interrupt 
processing. Maybe using fixed size messages and using fifo watermark might 
limit the interrupt overhead. 
> 
> 
>> However, you are correct that the
>> SPI slave must be preconfigured and waiting for the master to start
>> clocking the interface. The problem with the SPI framework and in
>> particular the McSPI driver is that they is written around a master
>> implementation and adding slave support is almost impossible. It would be
>> easier to write a slave McSPI from scratch. The I2C slave framework might
>> be a good guide on how to make this work.
> 
> There are 2 things being mixed up here -
> Merely grafting on slave functionality isn't too difficult with the current 
> McSPI driver (that's what I did). The main thing this gets you is a lot of 
> the 
> driver registration and McSPI init is reused; this is a big hack but it gets 
> data flowing.
Can you share that with me? I would be interested to see how you managed to do 
this. I’ve looked at this several times and each time my head wants to explode. 
> 
> Getting it as a clean interface would definitely benefit from a rewrite as 
> you 
> described.
If you are willing, perhaps this is a project we can work on together. 

Regards,
John
>> 
>> Regards,
>> John
>> 
>>> On Apr 4, 2016, at 11:27 AM, ybeag...@rehut.com wrote:
>>> 
>>> Getting it to work is not hard. (Had it working for a project.) To get to
>>> work reliably at a high clock rate requires debugging the DMA or working
>>> out a protocol where timing isn't as tricky. As a slave the master can
>>> start clocking at anytime and unless the FIFO (or DMA) is preloaded with
>>> the entire packet the master wants, you will need to respond to the
>>> interrupt before an underrun occurs.
>>> 
>>> The bigger barrier is a framework for SPI slave.
>>> 
>>> On Monday, March 28, 2016 09:14:38 Yaron Yzhak Lederman wrote:
 Thank you very much about clarifying this point !
 
 I don't think that I can allocate enough time to dive into what John
 described - I assume that at some stage there will be such a driver or
 other form of such support
 
 Thanks for now
 
 On Sun, Mar 27, 2016 at 11:29 PM, John Syne  wrote:
> The McSPI needs a driver and there is currently no Linux Driver that
> supports SPI slave mode. The current driver
> /drivers/spi/spi-omap2-mcspi.c
> does not support slave mode. The Linux kernel SPI framework uses
> spi-omap2-mcspi driver on TI processors.
> 
> Regards,
> John
> 
> 
> 
> 
> On Mar 27, 2016, at 12:35 PM, William Hermans  wrote:
> 
> I'd actually look into using the McSPI module. Which is hardware, and
> does
> support slave mode.
> 
> On Sun, Mar 27, 2016 at 11:29 AM, John Syne  wrote:
>> Ah, what you are trying to do cannot be done with the current SPI
>> driver
>> because Linux SPI framework does not support SPI slave mode. Recently
>> someone added I2C slave support to the I2C framework and that might be
>> your
>> first place to look. My approach would be to create a custom SPI driver
>> that does not use the SPI framework. The length and frequency of
>> messages
>> will define the driver design. For example, if the message length is
>> smaller than the SPI receive FIFO size, I would do this with
>> interrupts,
>> but the interrupt 

Re: [beagleboard] SPI BBB Master, BBB Slave

[ybeagle3]

On Monday, April 04, 2016 12:04:56 John Syne wrote:
> I’m not sure that is correct. The master will normally send a command and
> then your slave driver will have to respond with relevant packet. The
> protocol will have to be well defined.

None of that is required by SPI (in the most basic form  it is just a shift 
register). What I was alluding it protocol games that be played like Master 
writes byte to slave and waits for an active GPIO before anymore clocking. Or 
even a dumb (unidirectional) protocol where the master waits for a GPIO to go 
active before clocking out data. 

In contrast, doing it like a lot of common devices where you can clock in a 
byte (i.e. register address or a command) and expect data after another 8 
clocks could impose some very tight timing requirements.


> However, you are correct that the
> SPI slave must be preconfigured and waiting for the master to start
> clocking the interface. The problem with the SPI framework and in
> particular the McSPI driver is that they is written around a master
> implementation and adding slave support is almost impossible. It would be
> easier to write a slave McSPI from scratch. The I2C slave framework might
> be a good guide on how to make this work.

There are 2 things being mixed up here -
Merely grafting on slave functionality isn't too difficult with the current 
McSPI driver (that's what I did). The main thing this gets you is a lot of the 
driver registration and McSPI init is reused; this is a big hack but it gets 
data flowing.

Getting it as a clean interface would definitely benefit from a rewrite as you 
described.
> 
> Regards,
> John
> 
> > On Apr 4, 2016, at 11:27 AM, ybeag...@rehut.com wrote:
> > 
> > Getting it to work is not hard. (Had it working for a project.) To get to
> > work reliably at a high clock rate requires debugging the DMA or working
> > out a protocol where timing isn't as tricky. As a slave the master can
> > start clocking at anytime and unless the FIFO (or DMA) is preloaded with
> > the entire packet the master wants, you will need to respond to the
> > interrupt before an underrun occurs.
> > 
> > The bigger barrier is a framework for SPI slave.
> > 
> > On Monday, March 28, 2016 09:14:38 Yaron Yzhak Lederman wrote:
> >> Thank you very much about clarifying this point !
> >> 
> >> I don't think that I can allocate enough time to dive into what John
> >> described - I assume that at some stage there will be such a driver or
> >> other form of such support
> >> 
> >> Thanks for now
> >> 
> >> On Sun, Mar 27, 2016 at 11:29 PM, John Syne  wrote:
> >>> The McSPI needs a driver and there is currently no Linux Driver that
> >>> supports SPI slave mode. The current driver
> >>> /drivers/spi/spi-omap2-mcspi.c
> >>> does not support slave mode. The Linux kernel SPI framework uses
> >>> spi-omap2-mcspi driver on TI processors.
> >>> 
> >>> Regards,
> >>> John
> >>> 
> >>> 
> >>> 
> >>> 
> >>> On Mar 27, 2016, at 12:35 PM, William Hermans  wrote:
> >>> 
> >>> I'd actually look into using the McSPI module. Which is hardware, and
> >>> does
> >>> support slave mode.
> >>> 
> >>> On Sun, Mar 27, 2016 at 11:29 AM, John Syne  wrote:
>  Ah, what you are trying to do cannot be done with the current SPI
>  driver
>  because Linux SPI framework does not support SPI slave mode. Recently
>  someone added I2C slave support to the I2C framework and that might be
>  your
>  first place to look. My approach would be to create a custom SPI driver
>  that does not use the SPI framework. The length and frequency of
>  messages
>  will define the driver design. For example, if the message length is
>  smaller than the SPI receive FIFO size, I would do this with
>  interrupts,
>  but the interrupt would occur only when exceeding the FIFO threshold
>  and
>  then dump the full FIFO in the bottom half interrupt handler. This way,
>  you
>  would get an interrupt on every say every 32 receive bytes, which will
>  reduce the interrupt overhead and improve throughput.
>  
>  If the message length is more than the FIFO length, or if the message
>  is
>  cyclical, then I would use DMA to copy the SPI data into a ping-pong
>  buffer
>  arrangement. From the use space app, you would use poll to wait for a
>  complete buffer, and then read that buffer via read or mmap.
>  
>  Question is, how experienced are you at writing Linux drivers? This
>  isn’t
>  a trivial task.
>  
>  Regards,
>  John
>  
>  
>  
>  
>  On Mar 27, 2016, at 12:26 AM, Yaron Yzhak Lederman <
>  yaron.leder...@gmail.com> wrote:
>  
>  John Hi,
>  
>  Thank you for coming back on this.
>  
>  I'm trying to connect 2 SPI busses on the BBB (HDMI disabled) and
>  configure SPI1 as SPI slave so that I can sent messages from SPI0 to
>  SPI1

[beagleboard] Development setup

[Rob van Schelven]

Hi all,

Does someone know if there is any information available to setup a 
development environment (IDE) running under MS Windows or Ubuntu (in 
virtual machine under windows) to develop C/C++ code for the BBB

Thanks
Rob

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SPI BBB Master, BBB Slave

[John Syne]

I’m not sure that is correct. The master will normally send a command and then 
your slave driver will have to respond with relevant packet. The protocol will 
have to be well defined. However, you are correct that the SPI slave must be 
preconfigured and waiting for the master to start clocking the interface. The 
problem with the SPI framework and in particular the McSPI driver is that they 
is written around a master implementation and adding slave support is almost 
impossible. It would be easier to write a slave McSPI from scratch. The I2C 
slave framework might be a good guide on how to make this work. 

Regards,
John




> On Apr 4, 2016, at 11:27 AM, ybeag...@rehut.com wrote:
> 
> Getting it to work is not hard. (Had it working for a project.) To get to 
> work 
> reliably at a high clock rate requires debugging the DMA or working out a 
> protocol where timing isn't as tricky. As a slave the master can start 
> clocking at anytime and unless the FIFO (or DMA) is preloaded with the entire 
> packet the master wants, you will need to respond to the interrupt before an 
> underrun occurs. 
> 
> The bigger barrier is a framework for SPI slave. 
> 
> On Monday, March 28, 2016 09:14:38 Yaron Yzhak Lederman wrote:
>> Thank you very much about clarifying this point !
>> 
>> I don't think that I can allocate enough time to dive into what John
>> described - I assume that at some stage there will be such a driver or
>> other form of such support
>> 
>> Thanks for now
>> 
>> On Sun, Mar 27, 2016 at 11:29 PM, John Syne  wrote:
>>> The McSPI needs a driver and there is currently no Linux Driver that
>>> supports SPI slave mode. The current driver /drivers/spi/spi-omap2-mcspi.c
>>> does not support slave mode. The Linux kernel SPI framework uses
>>> spi-omap2-mcspi driver on TI processors.
>>> 
>>> Regards,
>>> John
>>> 
>>> 
>>> 
>>> 
>>> On Mar 27, 2016, at 12:35 PM, William Hermans  wrote:
>>> 
>>> I'd actually look into using the McSPI module. Which is hardware, and does
>>> support slave mode.
>>> 
>>> On Sun, Mar 27, 2016 at 11:29 AM, John Syne  wrote:
 Ah, what you are trying to do cannot be done with the current SPI driver
 because Linux SPI framework does not support SPI slave mode. Recently
 someone added I2C slave support to the I2C framework and that might be
 your
 first place to look. My approach would be to create a custom SPI driver
 that does not use the SPI framework. The length and frequency of messages
 will define the driver design. For example, if the message length is
 smaller than the SPI receive FIFO size, I would do this with interrupts,
 but the interrupt would occur only when exceeding the FIFO threshold and
 then dump the full FIFO in the bottom half interrupt handler. This way,
 you
 would get an interrupt on every say every 32 receive bytes, which will
 reduce the interrupt overhead and improve throughput.
 
 If the message length is more than the FIFO length, or if the message is
 cyclical, then I would use DMA to copy the SPI data into a ping-pong
 buffer
 arrangement. From the use space app, you would use poll to wait for a
 complete buffer, and then read that buffer via read or mmap.
 
 Question is, how experienced are you at writing Linux drivers? This isn’t
 a trivial task.
 
 Regards,
 John
 
 
 
 
 On Mar 27, 2016, at 12:26 AM, Yaron Yzhak Lederman <
 yaron.leder...@gmail.com> wrote:
 
 John Hi,
 
 Thank you for coming back on this.
 
 I'm trying to connect 2 SPI busses on the BBB (HDMI disabled) and
 configure SPI1 as SPI slave so that I can sent messages from SPI0 to SPI1
 -
 this allows me my application development and laterone I'll connect the
 respective SPI slave and master devices
 
 Thank you
 Yaron
 
 On Wed, Mar 23, 2016 at 10:37 PM, John Syne  wrote:
> What exactly are you trying to do? Please explain your application so
> that we can propose a solution.
> 
> Regards,
> John
> 
> 
> 
> 
> On Mar 23, 2016, at 4:29 AM, yaron.leder...@gmail.com wrote:
> 
> Hi,
> 
> Is there any resolution about this ? Since I'm having the same
> consideration
> 
> Thanks !
> 
> 
> On Wednesday, November 4, 2015 at 4:15:23 PM UTC+2, ravi...@gmail.com
> 
> wrote:
>> Hi,
>> 
>> I'm trying to setup SPI slave mode with same above method and
>> changed OMAP2_MCSPI_MODULCTRL_MS set to 0 for slave mode.
>> 
>> i'm facing issue in master mode and slave both on sckl pin
>> configuration.
>> 
>> http://elinux.org/BeagleBone_Black_Enable_SPIDEV in this link why sckl
>> pin is configured as INPUT 0x33 but it will work with same
>> configuration if
>> i change it to OUTPUT it doesn't work with any 

Re: [beagleboard] Re: BBB, Debian, Chipsee display: Tkinter gives error

[Harke Smits]

Hello David and John,

Thanks for your reactions. Sorry for the delay, was occupied with some
other duties like skiing
echo $DISPLAY from the debian command line returns nothing (a blank line).
The same command form the debian command line coming from the LXDE
interface gives: :0. So I issue the sudo python myprog.py command after the
LXDE shell has been loaded: that works for me.I need sudo because of the
Adafruit library, but I suppose that is another story.
Would be great to run the program without LXDE but I guess that will not
work.
The next problem is: how to run the program automatically upon start-up. I
prefer without LXDE but I am afraid that is not possible. So I need to
start myprog.py form a kind of start-up script
Btw: what is X11? The link is not terribly clear for me as a novice...

Best regards,
Harke


On Sat, Mar 26, 2016 at 10:01 PM, David Good  wrote:

> It looks like you need to set the DISPLAY environment variable so that
> tkinter knows which display to use.
>
> Is X11 installed on the BBB?
>
> On my linux machine, when I try echo $DISPLAY, I get ":0.0" without the
> quotes.
>
> What happens if you run that command?
>
> You might check out some of the info on this page as well.
>
>
> http://unix.stackexchange.com/questions/17255/is-there-a-command-to-list-all-open-displays-on-a-machine
>
> --David
>
> On Sat, Mar 26, 2016 at 1:59 PM, John Baker 
> wrote:
>
>> Harke:
>> Another in the Learned Group, I think it was Steve Plant but I can't find
>> the post, suggested connecting a keyboard and mouse to the BBB and running
>> the Python program with 'sudo python your_python_program'. That worked
>> great for me. I never would have thought of it. My code is a GUI with
>> buttons, text boxes and an animation graph running Tkinter and also running
>> PyBBIO for PWM output and ADC inputs.
>> John
>> johnbakeree.blogspot.com
>>
>> On Saturday, February 13, 2016 at 3:07:04 AM UTC-8, Harke Smits wrote:
>>>
>>> Hello Learned Group,
>>>
>>> I have a BBB running Debian (2015-11-03 version) with a Chipsee 4.3
>>> display. It works great, so far so good: both in graphic mode and text. I
>>> try to script an application requiring a GUI, so I loaded Tkinter and
>>> entered a test program.
>>> This is the result:
>>>
>>> Traceback (most recent call last):
>>>   File "testtk.py", line 2, in 
>>> root = Tkinter.Tk()
>>>   File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1712, in __init__
>>> self.tk = _tkinter.create(screenName, baseName, className,
>>> interactive, wantobjects, useTk, sync, use)
>>> _tkinter.TclError: no display name and no $DISPLAY environment variable
>>> root@beaglebone:/home/apptest#
>>>
>>> Its the same whether I run from BBB via bash or via another pc with
>>> Cloud9.
>>>
>>> I googled a lot and the error is not uncommon, but could not find a clue
>>> for my case.
>>>
>>> Please advise, regards,
>>> Harke
>>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/w7vDlQctKD8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SPI BBB Master, BBB Slave

[ybeagle3]

Getting it to work is not hard. (Had it working for a project.) To get to work 
reliably at a high clock rate requires debugging the DMA or working out a 
protocol where timing isn't as tricky. As a slave the master can start 
clocking at anytime and unless the FIFO (or DMA) is preloaded with the entire 
packet the master wants, you will need to respond to the interrupt before an 
underrun occurs. 

The bigger barrier is a framework for SPI slave. 

On Monday, March 28, 2016 09:14:38 Yaron Yzhak Lederman wrote:
> Thank you very much about clarifying this point !
> 
> I don't think that I can allocate enough time to dive into what John
> described - I assume that at some stage there will be such a driver or
> other form of such support
> 
> Thanks for now
> 
> On Sun, Mar 27, 2016 at 11:29 PM, John Syne  wrote:
> > The McSPI needs a driver and there is currently no Linux Driver that
> > supports SPI slave mode. The current driver /drivers/spi/spi-omap2-mcspi.c
> > does not support slave mode. The Linux kernel SPI framework uses
> > spi-omap2-mcspi driver on TI processors.
> > 
> > Regards,
> > John
> > 
> > 
> > 
> > 
> > On Mar 27, 2016, at 12:35 PM, William Hermans  wrote:
> > 
> > I'd actually look into using the McSPI module. Which is hardware, and does
> > support slave mode.
> > 
> > On Sun, Mar 27, 2016 at 11:29 AM, John Syne  wrote:
> >> Ah, what you are trying to do cannot be done with the current SPI driver
> >> because Linux SPI framework does not support SPI slave mode. Recently
> >> someone added I2C slave support to the I2C framework and that might be
> >> your
> >> first place to look. My approach would be to create a custom SPI driver
> >> that does not use the SPI framework. The length and frequency of messages
> >> will define the driver design. For example, if the message length is
> >> smaller than the SPI receive FIFO size, I would do this with interrupts,
> >> but the interrupt would occur only when exceeding the FIFO threshold and
> >> then dump the full FIFO in the bottom half interrupt handler. This way,
> >> you
> >> would get an interrupt on every say every 32 receive bytes, which will
> >> reduce the interrupt overhead and improve throughput.
> >> 
> >> If the message length is more than the FIFO length, or if the message is
> >> cyclical, then I would use DMA to copy the SPI data into a ping-pong
> >> buffer
> >> arrangement. From the use space app, you would use poll to wait for a
> >> complete buffer, and then read that buffer via read or mmap.
> >> 
> >> Question is, how experienced are you at writing Linux drivers? This isn’t
> >> a trivial task.
> >> 
> >> Regards,
> >> John
> >> 
> >> 
> >> 
> >> 
> >> On Mar 27, 2016, at 12:26 AM, Yaron Yzhak Lederman <
> >> yaron.leder...@gmail.com> wrote:
> >> 
> >> John Hi,
> >> 
> >> Thank you for coming back on this.
> >> 
> >> I'm trying to connect 2 SPI busses on the BBB (HDMI disabled) and
> >> configure SPI1 as SPI slave so that I can sent messages from SPI0 to SPI1
> >> -
> >> this allows me my application development and laterone I'll connect the
> >> respective SPI slave and master devices
> >> 
> >> Thank you
> >> Yaron
> >> 
> >> On Wed, Mar 23, 2016 at 10:37 PM, John Syne  wrote:
> >>> What exactly are you trying to do? Please explain your application so
> >>> that we can propose a solution.
> >>> 
> >>> Regards,
> >>> John
> >>> 
> >>> 
> >>> 
> >>> 
> >>> On Mar 23, 2016, at 4:29 AM, yaron.leder...@gmail.com wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> Is there any resolution about this ? Since I'm having the same
> >>> consideration
> >>> 
> >>> Thanks !
> >>> 
> >>> 
> >>> On Wednesday, November 4, 2015 at 4:15:23 PM UTC+2, ravi...@gmail.com
> >>> 
> >>> wrote:
>  Hi,
>  
>  I'm trying to setup SPI slave mode with same above method and
>  changed OMAP2_MCSPI_MODULCTRL_MS set to 0 for slave mode.
>  
>  i'm facing issue in master mode and slave both on sckl pin
>  configuration.
>  
>  http://elinux.org/BeagleBone_Black_Enable_SPIDEV in this link why sckl
>  pin is configured as INPUT 0x33 but it will work with same
>  configuration if
>  i change it to OUTPUT it doesn't work with any slave device and no
>  clock on
>  that pin.
>  
>  Please anyone clarify this doubt and issues.
>  
>  For slave mode i tried to change OMAP2_MCSPI_MODULCTRL_MS bit in driver
>  file spi_omap2_mcspi.c but no use. still its master only.
>  
>  Please provide any suggestion or exact procedure.
>  
>  Thank you in advance.
>  
>  Regard s
>  Ravi
>  
>  On Thursday, September 18, 2014 at 5:45:47 AM UTC+5:30,
>  
>  phil...@gmail.com wrote:
> > I am having issues with SPI between two BBB that may be simple to
> > solve. I have spidev_test loopback working on each board but am having
> > problems connecting the two.
> > 
> > spi0 master 

[beagleboard] Re: Control and monitor Beaglebone from azure

[Paul Wolfson]

Beaglebone and Azure are not a problem, Azure is a generic Microsoft 
branded cloud resource, which you can run locally.

For reference, I have a mixed stack of Linux and Windows servers running on 
a Microsoft Hyper-V Server stack.  Node.js and C#.net (mono) are common 
across all the platforms.  There is no charge for the basic hyper-V server, 
you just pay for the Microsoft licensed products you have running on it. 
 There is no limit to the Linux resources you have running.Unless you 
want Visual Studio supporting Windows 10 IoT  or SQL Server there is no 
compelling need for Microsoft anything.  Libvirt and KVM are a good 
substitute for Hyper-V.

Generic Hyper-V Server SKU: 
 10586.0.151029-1700.TH2_RELEASE_SERVERHYPERCORE_OEM_X64FRE_EN-US

I haven't found anything on Azure that I can't already do locally using a 
stack of Microsoft and Linux servers and desktops except for the big data 
analytics offerings.  If you need access to Microsoft products as a 
developer, you can subscribe to one of their MAPS programs.

On Sunday, April 3, 2016 at 5:55:05 PM UTC-4, Sean McMahon wrote:
>
> Hmm Not much response.
>
> I came across this : 
> https://www.microsoft.com/en-gb/server-cloud/internet-of-things/azure-iot-suite.aspx
>
> Anyone tried it out?
>
> On Monday, 28 March 2016 14:59:33 UTC+1, Sean McMahon wrote:
>>
>> Hi,
>>
>> I'm looking to talk to my beaglebone over an azure virtual machine, 
>> (external network).  
>>
>> Are there any good tutorials on how to control a beaglebone from the web.
>>
>> I've been searching the web for about three hours and haven't found 
>> anything suitable yet.
>>
>> Thanks,
>> Seán
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: New Device Tree Do not Change Pin Values

[Xsentius]

I am very grateful Robert, it worked. I can change pin modes easily, time 
to test some PRU codes. Thank you so much!

On Monday, April 4, 2016 at 5:55:45 PM UTC+3, RobertCNelson wrote:
>
>
>
> On Mon, Apr 4, 2016 at 9:51 AM, Xsentius  > wrote:
>
>> Oh, that is a very precious information, I really appreciate it. 
>>
>> So is there a way to see updates? Do you recommend me to go back to 3.8, 
>> if it is stable?
>>
>
> Correctly set them in the overlay and don't worry about it..
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] eMMC gets timeout when I put on cape

[Chris Morgan]

On Mon, Apr 4, 2016 at 11:53 AM, Martin Wiingaard 
wrote:

> Hey There,
>
> I'm running BeagleBone Black Rev C.
> I have developed my own custom cape, it is using the following IO-pins:
>
> BBB-header no
>
> BBB GPIO no
>
> P9_42
>
> 7
>
> P9_18
>
> 4
>
> P9_17
>
> 5
>
> P9_15
>
> 48
>
> P9_28
>
> 113
>
> P9_23
>
> 49
>
> P9_31
>
> 110
>
> P9_12
>
> 60
>
> P9_29
>
> 111
>
> P9_27
>
> 115
>
> P9_25
>
> 117
>
> I have developed a device tree overlay, that's declaring all the pins as
> GPIOs, and I have set all pins to output with value 0. Other than that am I
> using the VDD_3V3 and VDD_5V.
>
> When I put the cape on, I get some error mesaages on dmesg:
>
> [  159.482950] mmcblk0: error -110 sending status command, retrying
>
> [  159.489379] mmcblk0: error -110 sending status command, aborting
>
> [  159.495725] end_request: I/O error, dev mmcblk0, sector 497760
>
>
> At this point I can still type in some simple commands to the commandline
> (such as ls and cd) but more demanding commands fails (such as top and
> shutdown), it gives me an I/O error.
>
>
> So it seems that the MMC-card for some reason is unreachable. The cape
> doesn't seem to affect the supply voltage, is was measured on VDD_3V3
> (P9_3) to be 3,15V both before and after I put the cape on.
>
>
> Does anybody have any clues, or any suggestions to how I could do further
> debugging?
>
>
> Thanks :)
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>


Are you sure none of those pins are being used by the emmc? It sure sounds
like they might be...

Chris

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] eMMC gets timeout when I put on cape

[Martin Wiingaard]

Hey There,

I'm running BeagleBone Black Rev C. 
I have developed my own custom cape, it is using the following IO-pins:

BBB-header no

BBB GPIO no

P9_42

7

P9_18

4

P9_17

5

P9_15

48

P9_28

113

P9_23

49

P9_31

110

P9_12

60

P9_29

111

P9_27

115

P9_25

117
 
I have developed a device tree overlay, that's declaring all the pins as 
GPIOs, and I have set all pins to output with value 0. Other than that am I 
using the VDD_3V3 and VDD_5V.

When I put the cape on, I get some error mesaages on dmesg:

[  159.482950] mmcblk0: error -110 sending status command, retrying

[  159.489379] mmcblk0: error -110 sending status command, aborting

[  159.495725] end_request: I/O error, dev mmcblk0, sector 497760


At this point I can still type in some simple commands to the commandline 
(such as ls and cd) but more demanding commands fails (such as top and 
shutdown), it gives me an I/O error.


So it seems that the MMC-card for some reason is unreachable. The cape 
doesn't seem to affect the supply voltage, is was measured on VDD_3V3 
(P9_3) to be 3,15V both before and after I put the cape on.


Does anybody have any clues, or any suggestions to how I could do further 
debugging?


Thanks :) 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: u-boot stuck

['Mark Lazarewicz' via BeagleBoard]

CCC come from the onchip boot code 

Sent from Yahoo Mail on Android 
 
  On Mon, Apr 4, 2016 at 10:40 AM, Laurent d'Havé wrote:   
Great !


dd'ing MLO and uboot to the SD card worked ! 
i repo sync'ed on dev machine, but it's still building the faulty u-boot. i'll 
manually force a newer git version.


Thanks a lot ! 

-- 
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.
For more options, visit https://groups.google.com/d/optout.
  

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] End of Life or wildly popular?

[William Hermans]

>
> *In stock at Adafruit:https://www.adafruit.com/products/1996
> *


It wasn't yesterday when I looked.

On Mon, Apr 4, 2016 at 7:51 AM, Graham  wrote:

> In stock at Adafruit:
> https://www.adafruit.com/products/1996
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: New Device Tree Do not Change Pin Values

[Robert Nelson]

On Mon, Apr 4, 2016 at 9:51 AM, Xsentius  wrote:

> Oh, that is a very precious information, I really appreciate it.
>
> So is there a way to see updates? Do you recommend me to go back to 3.8,
> if it is stable?
>

Correctly set them in the overlay and don't worry about it..

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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: New Device Tree Do not Change Pin Values

[Xsentius]

Oh, that is a very precious information, I really appreciate it. 

So is there a way to see updates? Do you recommend me to go back to 3.8, if 
it is stable?

On Monday, April 4, 2016 at 5:45:33 PM UTC+3, RobertCNelson wrote:
>
>
>
> On Mon, Apr 4, 2016 at 9:42 AM, Xsentius  > wrote:
>
>> So do you think that's why I cannot change pin mode settings? 
>>
>
> You are also assuming "sudo cat $PINS" works on 4.1.x... it doesn't 
> currently show updates from loading overlays..
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] End of Life or wildly popular?

[Graham]

In stock at Adafruit:
https://www.adafruit.com/products/1996


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: New Device Tree Do not Change Pin Values

[Robert Nelson]

On Mon, Apr 4, 2016 at 9:42 AM, Xsentius  wrote:

> So do you think that's why I cannot change pin mode settings?
>

You are also assuming "sudo cat $PINS" works on 4.1.x... it doesn't
currently show updates from loading overlays..

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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: New Device Tree Do not Change Pin Values

[Xsentius]

So do you think that's why I cannot change pin mode settings? 

Kind Regards

On Monday, April 4, 2016 at 5:27:48 PM UTC+3, RobertCNelson wrote:
>
>
>
> On Mon, Apr 4, 2016 at 9:23 AM, frank brewer  > wrote:
>
>> Also now I checked whether uio_pruss is loaded:
>>
>> root@beaglebone:~# lsmod
>> Module  Size  Used by
>> c_can_platform  6564  0
>> c_can   9605  1 c_can_platform
>> can_dev11455  1 c_can
>> spidev  6739  0
>> tieqep  8510  0
>> pwm_tiehrpwm4546  0
>> pwm_tiecap  3492  0
>> 8021q  17344  0
>> garp5975  1 8021q
>> mrp 7322  1 8021q
>> stp 1911  1 garp
>> llc 5257  2 stp,garp
>> pru_rproc  11099  0
>> usb_f_acm   7180  1
>> u_serial   10646  3 usb_f_acm
>> usb_f_rndis22734  1
>> g_multi 5316  0
>> usb_f_mass_storage 42745  2 g_multi
>> u_ether12028  2 usb_f_rndis,g_multi
>> libcomposite   43810  4 usb_f_acm,usb_f_rndis,g_multi,
>> usb_f_mass_storage
>> pruss  14686  1 pru_rproc
>> omap_rng4358  0
>> rng_core7441  1 omap_rng
>> snd_soc_davinci_mcasp17352  0
>> snd_soc_edma1150  1 snd_soc_davinci_mcasp
>> spi_omap2_mcspi10681  0
>> uio_pdrv_genirq 3521  0
>> uio 8467  1 uio_pdrv_genirq
>> cfg80211  399381  0
>> rfkill 17701  2 cfg80211
>>
>> Seems like it is not. I have pruss and pru_rproc but not uio_pruss. Can 
>> that be the problem?
>>
>> I tried loading it:
>>
>> root@beaglebone:~# modprobe uio_pruss
>> modprobe: FATAL: Module uio_pruss not found.
>>
>>
>> However I could not. Any ideas?
>>
>
> This is documented through out this forum..
>
> In another thread you mentioned you were running:
>
> 4.1.18-ti-rt-r56
>
> This "v4.1.x-ti" which uses remoteproc_pruss..
>
> If you want uio_pruss, you need to use "4.1.x-bone" or "4.4.x-bone"..
>
> cd /opt/scripts/tools/
> git pull
> sudo ./update_kernel.sh --bone-rt-kernel --lts-4_1
>
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Confused about npm installs.

[Wally Bkg]

The johnny-five beaglebone-io didn't go any better :(
as root:
cd .node-red
npm install  -g --unsafe-perm johnny-five beaglebone-io

npm ERR! Linux 4.1.18-ti-r55
npm ERR! argv "node" "/usr/local/bin/npm" "install" "-g" "--unsafe-perm" 
"johnny-five" "beaglebone-io"
npm ERR! node v0.12.12
npm ERR! npm  v3.8.2
npm ERR! code ELIFECYCLE

npm ERR! ffi@1.2.6 install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the ffi@1.2.6 install script 'node-gyp rebuild'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the ffi package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node-gyp rebuild
npm ERR! You can get information on how to open an issue for this project 
with:
npm ERR! npm bugs ffi
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls ffi
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR! /root/.node-red/npm-debug.log



-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: u-boot stuck

[Laurent d'Havé]

>
> Great !
>


dd'ing MLO and uboot to the SD card worked ! 
i repo sync'ed on dev machine, but it's still building the faulty u-boot. 
i'll manually force a newer git version.


Thanks a lot ! 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: New Device Tree Do not Change Pin Values

[Robert Nelson]

On Mon, Apr 4, 2016 at 9:23 AM, frank brewer 
wrote:

> Also now I checked whether uio_pruss is loaded:
>
> root@beaglebone:~# lsmod
> Module  Size  Used by
> c_can_platform  6564  0
> c_can   9605  1 c_can_platform
> can_dev11455  1 c_can
> spidev  6739  0
> tieqep  8510  0
> pwm_tiehrpwm4546  0
> pwm_tiecap  3492  0
> 8021q  17344  0
> garp5975  1 8021q
> mrp 7322  1 8021q
> stp 1911  1 garp
> llc 5257  2 stp,garp
> pru_rproc  11099  0
> usb_f_acm   7180  1
> u_serial   10646  3 usb_f_acm
> usb_f_rndis22734  1
> g_multi 5316  0
> usb_f_mass_storage 42745  2 g_multi
> u_ether12028  2 usb_f_rndis,g_multi
> libcomposite   43810  4 usb_f_acm,usb_f_rndis,g_multi,
> usb_f_mass_storage
> pruss  14686  1 pru_rproc
> omap_rng4358  0
> rng_core7441  1 omap_rng
> snd_soc_davinci_mcasp17352  0
> snd_soc_edma1150  1 snd_soc_davinci_mcasp
> spi_omap2_mcspi10681  0
> uio_pdrv_genirq 3521  0
> uio 8467  1 uio_pdrv_genirq
> cfg80211  399381  0
> rfkill 17701  2 cfg80211
>
> Seems like it is not. I have pruss and pru_rproc but not uio_pruss. Can
> that be the problem?
>
> I tried loading it:
>
> root@beaglebone:~# modprobe uio_pruss
> modprobe: FATAL: Module uio_pruss not found.
>
>
> However I could not. Any ideas?
>

This is documented through out this forum..

In another thread you mentioned you were running:

4.1.18-ti-rt-r56

This "v4.1.x-ti" which uses remoteproc_pruss..

If you want uio_pruss, you need to use "4.1.x-bone" or "4.4.x-bone"..

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh --bone-rt-kernel --lts-4_1


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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: New Device Tree Do not Change Pin Values

[frank brewer]

Also now I checked whether uio_pruss is loaded:

root@beaglebone:~# lsmod
Module  Size  Used by
c_can_platform  6564  0
c_can   9605  1 c_can_platform
can_dev11455  1 c_can
spidev  6739  0
tieqep  8510  0
pwm_tiehrpwm4546  0
pwm_tiecap  3492  0
8021q  17344  0
garp5975  1 8021q
mrp 7322  1 8021q
stp 1911  1 garp
llc 5257  2 stp,garp
pru_rproc  11099  0
usb_f_acm   7180  1
u_serial   10646  3 usb_f_acm
usb_f_rndis22734  1
g_multi 5316  0
usb_f_mass_storage 42745  2 g_multi
u_ether12028  2 usb_f_rndis,g_multi
libcomposite   43810  4 usb_f_acm,usb_f_rndis,g_multi,
usb_f_mass_storage
pruss  14686  1 pru_rproc
omap_rng4358  0
rng_core7441  1 omap_rng
snd_soc_davinci_mcasp17352  0
snd_soc_edma1150  1 snd_soc_davinci_mcasp
spi_omap2_mcspi10681  0
uio_pdrv_genirq 3521  0
uio 8467  1 uio_pdrv_genirq
cfg80211  399381  0
rfkill 17701  2 cfg80211

Seems like it is not. I have pruss and pru_rproc but not uio_pruss. Can 
that be the problem?

I tried loading it:

root@beaglebone:~# modprobe uio_pruss
modprobe: FATAL: Module uio_pruss not found.


However I could not. Any ideas?

On Monday, April 4, 2016 at 3:04:59 PM UTC+3, Xsentius wrote:
>
> I am trying a PRU example from Derek Molloy's book, however whatever I do, 
> pin values do not change. Could you please check what I am doing wrong?
>
>
> dts file:
>
>
> /* Device Tree Overlay for enabling the pins that are used in Chapter 13
> * This overlay is based on the BB-PRU-01 overlay
> * Written by Derek Molloy for the book "Exploring BeagleBone: Tools and
> * Techniques for Building with Embedded Linux" by John Wiley & Sons, 2014
> * ISBN 9781118935125. Please see the file README.md in the repository root
> * directory for copyright and GNU GPLv3 license information.
> */
> /dts-v1/;
> /plugin/;
>
>
> / {
>compatible = "ti,beaglebone", "ti,beaglebone-black";
>
>
>part-number = "EBB-PRU-Example";
>version = "00A0";
>
>
>/* This overlay uses the following resources */
>exclusive-use =
>  "P9.11", "P9.13", "P9.27", "P9.28", "pru0";
>
>
>fragment@0 {
>   target = <_pinmux>;
>   __overlay__ {
>
>
>  gpio_pins: pinmux_gpio_pins { // The GPIO pins
> pinctrl-single,pins = <
>0x070 0x07  // P9_11 MODE7 | OUTPUT | GPIO pull-down
>0x074 0x27  // P9_13 MODE7 | INPUT | GPIO pull-down
> >;
>  };
>
>
>  pru_pru_pins: pinmux_pru_pru_pins {   // The PRU pin modes
> pinctrl-single,pins = <
>0x1a4 0x05  // P9_27 pr1_pru0_pru_r30_5, MODE5 | OUTPUT | 
> PRU
>0x19c 0x26  // P9_28 pr1_pru0_pru_r31_3, MODE6 | INPUT | 
> PRU
> >;
>  };
>   };
>};
>
>
>fragment@1 { // Enable the PRUSS
>   target = <>;
>   __overlay__ {
>  status = "okay";
>  pinctrl-names = "default";
>  pinctrl-0 = <_pru_pins>;
>   };
>};
>
>
>fragment@2 { // Enable the GPIOs
>   target = <>;
>   __overlay__ {
>  gpio_helper {
> compatible = "gpio-of-helper";
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
>  };
>   };
>};
> };
>
>
>
>
> I compile with:
>
> dtc -O dtb -o EBB-PRU-Example-00A0.dtbo -b 0 -@ EBB-PRU-Example.dts
>
>
>
> then copy it under /lib/firmware and do:
>
> sudo sh ‐c "echo EBB‐PRU‐Example > $SLOTS"
>
> Then I check:
>
>
> $SLOTS output:
>
>
> xsentius@beaglebone:~/chp13/overlay$ cat $SLOTS
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  6: P-O-L-   0 Override Board Name,00A0,Override Manuf,EBB-PRU-Example
>
>
>
> dmesg output:
>
> [  701.582790] bone_capemgr bone_capemgr: slot #6: override
> [  701.582839] bone_capemgr bone_capemgr: Using override eeprom data at 
> slot 6
> [  701.582892] bone_capemgr bone_capemgr: slot #6: 'Override Board 
> Name,00A0,Override Manuf,EBB-PRU-Example'
> [  701.584950] bone_capemgr bone_capemgr: slot #6: dtbo 
> 'EBB-PRU-Example-00A0.dtbo' loaded; overlay id #0
>
>
> Everything seems normal up to here, but when I check pin values:
>
>
> xsentius@beaglebone:~/chp13/overlay$ sudo cat $PINS|grep '103\|105'
> pin 103 (44e1099c.0) 0027 pinctrl-single
> pin 105 (44e109a4.0) 0027 pinctrl-single
>
> Those pins values seem not changed. They should be equal to 26 and 5.
> Do you have an idea?
>
> Here are my system properties:
>
> xsentius@beaglebone:~/chp13/overlay$ uname -a
> Linux beaglebone 4.1.18-ti-rt-r56 #1 SMP PREEMPT RT Thu Mar 31 00:22:06 
> UTC 2016 armv7l 

Re: [beagleboard] Re: u-boot stuck

[Robert Nelson]

On Mon, Apr 4, 2016 at 9:16 AM, Laurent d'Havé  wrote:

> Thats my issue ..
>
>
> The mSD card i use for flashing that has an "old" MLO/uboot and won't boot
> anymore (it's actually the bbb image you can download on their site that
> has a "flasher app" in it, i just replace the uboot, mlo, rootfs with my
> custom builds)
>
> I've tried other mSD images i kept from the past that boot on other BBB,
> but those two BBB that have seen the faulty u-boot won't try to boot from
> mSD anymore... i'm really stuck. It's like it won't ever try to boot off
> mSD anymore.
> And holding BOOT button just gets me to spi boot ().
>

"CCC"'s means it can't find the bootloader..

Follow the directions here:

https://eewiki.net/display/linuxonarm/BeagleBone+Black

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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: New Device Tree Do not Change Pin Values

[frank brewer]

Also now I checked whether uio_pruss is loaded:

root@beaglebone:~# lsmod
Module  Size  Used by
c_can_platform  6564  0
c_can   9605  1 c_can_platform
can_dev11455  1 c_can
spidev  6739  0
tieqep  8510  0
pwm_tiehrpwm4546  0
pwm_tiecap  3492  0
8021q  17344  0
garp5975  1 8021q
mrp 7322  1 8021q
stp 1911  1 garp
llc 5257  2 stp,garp
pru_rproc  11099  0
usb_f_acm   7180  1
u_serial   10646  3 usb_f_acm
usb_f_rndis22734  1
g_multi 5316  0
usb_f_mass_storage 42745  2 g_multi
u_ether12028  2 usb_f_rndis,g_multi
libcomposite   43810  4 usb_f_acm,usb_f_rndis,g_multi,
usb_f_mass_storage
pruss  14686  1 pru_rproc
omap_rng4358  0
rng_core7441  1 omap_rng
snd_soc_davinci_mcasp17352  0
snd_soc_edma1150  1 snd_soc_davinci_mcasp
spi_omap2_mcspi10681  0
uio_pdrv_genirq 3521  0
uio 8467  1 uio_pdrv_genirq
cfg80211  399381  0
rfkill 17701  2 cfg80211

Seems like it is not. I have pruss and pru_rproc but not uio_pruss. Can 
that be the problem?

I tried loading it:

root@beaglebone:~# modprobe uio_pruss
modprobe: FATAL: Module uio_pruss not found.


However I could not. Any ideas?


On Monday, April 4, 2016 at 3:04:59 PM UTC+3, Xsentius wrote:
>
> I am trying a PRU example from Derek Molloy's book, however whatever I do, 
> pin values do not change. Could you please check what I am doing wrong?
>
>
> dts file:
>
>
> /* Device Tree Overlay for enabling the pins that are used in Chapter 13
> * This overlay is based on the BB-PRU-01 overlay
> * Written by Derek Molloy for the book "Exploring BeagleBone: Tools and
> * Techniques for Building with Embedded Linux" by John Wiley & Sons, 2014
> * ISBN 9781118935125. Please see the file README.md in the repository root
> * directory for copyright and GNU GPLv3 license information.
> */
> /dts-v1/;
> /plugin/;
>
>
> / {
>compatible = "ti,beaglebone", "ti,beaglebone-black";
>
>
>part-number = "EBB-PRU-Example";
>version = "00A0";
>
>
>/* This overlay uses the following resources */
>exclusive-use =
>  "P9.11", "P9.13", "P9.27", "P9.28", "pru0";
>
>
>fragment@0 {
>   target = <_pinmux>;
>   __overlay__ {
>
>
>  gpio_pins: pinmux_gpio_pins { // The GPIO pins
> pinctrl-single,pins = <
>0x070 0x07  // P9_11 MODE7 | OUTPUT | GPIO pull-down
>0x074 0x27  // P9_13 MODE7 | INPUT | GPIO pull-down
> >;
>  };
>
>
>  pru_pru_pins: pinmux_pru_pru_pins {   // The PRU pin modes
> pinctrl-single,pins = <
>0x1a4 0x05  // P9_27 pr1_pru0_pru_r30_5, MODE5 | OUTPUT | 
> PRU
>0x19c 0x26  // P9_28 pr1_pru0_pru_r31_3, MODE6 | INPUT | 
> PRU
> >;
>  };
>   };
>};
>
>
>fragment@1 { // Enable the PRUSS
>   target = <>;
>   __overlay__ {
>  status = "okay";
>  pinctrl-names = "default";
>  pinctrl-0 = <_pru_pins>;
>   };
>};
>
>
>fragment@2 { // Enable the GPIOs
>   target = <>;
>   __overlay__ {
>  gpio_helper {
> compatible = "gpio-of-helper";
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
>  };
>   };
>};
> };
>
>
>
>
> I compile with:
>
> dtc -O dtb -o EBB-PRU-Example-00A0.dtbo -b 0 -@ EBB-PRU-Example.dts
>
>
>
> then copy it under /lib/firmware and do:
>
> sudo sh ‐c "echo EBB‐PRU‐Example > $SLOTS"
>
> Then I check:
>
>
> $SLOTS output:
>
>
> xsentius@beaglebone:~/chp13/overlay$ cat $SLOTS
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  6: P-O-L-   0 Override Board Name,00A0,Override Manuf,EBB-PRU-Example
>
>
>
> dmesg output:
>
> [  701.582790] bone_capemgr bone_capemgr: slot #6: override
> [  701.582839] bone_capemgr bone_capemgr: Using override eeprom data at 
> slot 6
> [  701.582892] bone_capemgr bone_capemgr: slot #6: 'Override Board 
> Name,00A0,Override Manuf,EBB-PRU-Example'
> [  701.584950] bone_capemgr bone_capemgr: slot #6: dtbo 
> 'EBB-PRU-Example-00A0.dtbo' loaded; overlay id #0
>
>
> Everything seems normal up to here, but when I check pin values:
>
>
> xsentius@beaglebone:~/chp13/overlay$ sudo cat $PINS|grep '103\|105'
> pin 103 (44e1099c.0) 0027 pinctrl-single
> pin 105 (44e109a4.0) 0027 pinctrl-single
>
> Those pins values seem not changed. They should be equal to 26 and 5.
> Do you have an idea?
>
> Here are my system properties:
>
> xsentius@beaglebone:~/chp13/overlay$ uname -a
> Linux beaglebone 4.1.18-ti-rt-r56 #1 SMP PREEMPT RT Thu Mar 31 00:22:06 
> UTC 2016 armv7l 

[beagleboard] Re: u-boot stuck

[Laurent d'Havé]

Thats my issue ..


The mSD card i use for flashing that has an "old" MLO/uboot and won't boot 
anymore (it's actually the bbb image you can download on their site that 
has a "flasher app" in it, i just replace the uboot, mlo, rootfs with my 
custom builds)

I've tried other mSD images i kept from the past that boot on other BBB, 
but those two BBB that have seen the faulty u-boot won't try to boot from 
mSD anymore... i'm really stuck. It's like it won't ever try to boot off 
mSD anymore.
And holding BOOT button just gets me to spi boot ().


i tryed anyther mSD card, just in case mine got busted somehow , but same 
issue.

On Monday, April 4, 2016 at 12:51:12 PM UTC+2, Laurent d'Havé wrote:
>
> 'Flashed' a custom angstrom build from SD as i have done many times in the 
> past  (tested the image from the SD a couple of times and was working 
> great)
>
> upon reboot, i get this :
>
>
> U-Boot SPL 2016.01 (Mar 25 2016 - 14:36:19)
> Trying to boot from MMC
> reading args
> spl_load_image_fat_os: error reading image args, err - -1
> reading u-boot.img
> reading u-boot.img
>
>
> U-Boot 2016.01 (Mar 25 2016 - 14:36:19 +0100)
>
>Watchdog enabled
> I2C:   ready
> DRAM:  512 MiB
> NAND:  0 MiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> *** Error - No Valid Environment Area found
> *** Warning - bad CRC, using default environment
>
> Net:not set. Validating first E-fuse MAC
> cpsw, usb_ether
> =>
>
>
>
> Won't boot from SD anymore, can't type anything ... if i try to start it 
> with the "boot" button down, i'm just getting "CCC". 
> If i can get it to boot from SD i can always try to fix things easily ... 
>
>
>
> How can i unbrick this ? :(
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] u-boot stuck

[Robert Nelson]

On Mon, Apr 4, 2016 at 9:06 AM, Laurent d'Havé  wrote:

> Alright. good to know.
>
> Though i now bricked my two spare BBBlack ... so can't test if the update
> doesn't bug anymore..
>
> Any idea how i can unbrick ?
>

Easy

1: correctly write the MLO/u-boot.img to your microSD card..
2: hold boot button down with finger nail
3: insert power
4: u-boot prompt on serial port..

Grab the good version of u-boot from here:

https://eewiki.net/display/linuxonarm/BeagleBone+Black

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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] u-boot stuck

[Laurent d'Havé]

Alright. good to know.

Though i now bricked my two spare BBBlack ... so can't test if the update 
doesn't bug anymore..

Any idea how i can unbrick ?

On Monday, April 4, 2016 at 3:39:25 PM UTC+2, RobertCNelson wrote:
>
>
>
> On Mon, Apr 4, 2016 at 5:51 AM, Laurent d'Havé  > wrote:
>
>> 'Flashed' a custom angstrom build from SD as i have done many times in 
>> the past  (tested the image from the SD a couple of times and was 
>> working great)
>>
>> upon reboot, i get this :
>>
>>
>> U-Boot SPL 2016.01 (Mar 25 2016 - 14:36:19)
>> Trying to boot from MMC
>> reading args
>> spl_load_image_fat_os: error reading image args, err - -1
>> reading u-boot.img
>> reading u-boot.img
>>
>>
>> U-Boot 2016.01 (Mar 25 2016 - 14:36:19 +0100)
>>
>>Watchdog enabled
>> I2C:   ready
>> DRAM:  512 MiB
>> NAND:  0 MiB
>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>> *** Error - No Valid Environment Area found
>> *** Warning - bad CRC, using default environment
>>
>> Net:not set. Validating first E-fuse MAC
>> cpsw, usb_ether
>> =>
>>
>>
>>
>> Won't boot from SD anymore, can't type anything ... if i try to start it 
>> with the "boot" button down, i'm just getting "CCC". 
>> If i can get it to boot from SD i can always try to fix things easily ... 
>>
>
> known issue in 2016.01, it was fixed shortly after release.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Robert Nelson]

On Mon, Apr 4, 2016 at 8:41 AM, Robert Nelson 
wrote:

>
>
> On Mon, Apr 4, 2016 at 4:47 AM, Rick Mann  wrote:
>
>> I'm trying to get my audio cape to work (which is nearly identical to the
>> cape that was available for sale). I've had it working to some level of
>> success with past kernels (3.1.18), but now I'm on 4.4.6. My existing DTS
>> didn't work, so I'm looking at how the BB-BONE-AUDI-02 DTS is written.
>>
>> One of the differences is that it doesn't explicitly call out the McASP
>> clock frequency like the older one did. Instead, it seems to refer to
>> clk_mcasp0. But when I copy the same code into my DTS, I get:
>>
>> [  103.180866] of_resolve_phandles: Could not find symbol 'clk_mcasp0'
>> [  103.187269] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree
>>
>> I found it defined by grepping /boot/dtbs. It's in
>> /boot/dtbs/4.4.6-bone-rt-r6/am335x-abbbi.dtb. Where can I find the source
>> files for these DTBs?
>>
>> Is this dtb part of what's loaded by default in 4.4.6-bone-rt-r6? If not,
>> can I copy the definition into my
>>
>> FWIW, here's my DTS and some output from dmesg:
>> http://pastebin.com/niDkWdWV
>
>
>
> You need to add this to your base *.dtb:
>
>
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-boneblack-audio.dts#L17-L28
>

btw, the one thing i haven't tried, have everything in the clk defined
except for the gpio and load that as part of the audio overlay..

side note, we just got audio (cape audio rev b) working a few weeks back,
so this is relatively new

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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Where is BB-ADC and friends?

[Jacek Radzikowski]

On Mon, Apr 4, 2016 at 9:04 AM, Robert Nelson  wrote:
> On Sun, Apr 3, 2016 at 11:24 PM, Jacek Radzikowski
>  wrote:
>> Robert,
>>
>> I installed the overlays without problems on Debian 8.4 with kernel
>> 4.4.5-bone5. Adding overlays works fine, but removing them fails with
>> an OOPS. I remember similar problems from the era of 3.x kernels, but
>> I thought it had been addressed long time ago. Does the problem still
>> persist, or is it an issue with my setup?
>
> For now, still just reboot when you want to remove an overlay..

ok, thanks. I just wanted to make sure that I did not screw up something badly.

Regards,
Jacek.





-- 
Given a choice between two theories, take the one which is funnier

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] pruss_uio 4a300000.pruss: pins are not configured from the driver

[Robert Nelson]

On Mon, Apr 4, 2016 at 4:04 AM, Rick Mann  wrote:

> Can anyone tell me what this log message means when I load my overlay that
> enables the PRUs?
>
> [  348.342331] pruss_uio 4a30.pruss: pins are not configured from the
> driver
>
> Here's more context, and my DTS:
>
> http://pastebin.com/UPB1xjPF


Well, you don't have any pin's defined in the pruss node..

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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] My overlay can't find clk_mcasp0

[Robert Nelson]

On Mon, Apr 4, 2016 at 4:47 AM, Rick Mann  wrote:

> I'm trying to get my audio cape to work (which is nearly identical to the
> cape that was available for sale). I've had it working to some level of
> success with past kernels (3.1.18), but now I'm on 4.4.6. My existing DTS
> didn't work, so I'm looking at how the BB-BONE-AUDI-02 DTS is written.
>
> One of the differences is that it doesn't explicitly call out the McASP
> clock frequency like the older one did. Instead, it seems to refer to
> clk_mcasp0. But when I copy the same code into my DTS, I get:
>
> [  103.180866] of_resolve_phandles: Could not find symbol 'clk_mcasp0'
> [  103.187269] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree
>
> I found it defined by grepping /boot/dtbs. It's in
> /boot/dtbs/4.4.6-bone-rt-r6/am335x-abbbi.dtb. Where can I find the source
> files for these DTBs?
>
> Is this dtb part of what's loaded by default in 4.4.6-bone-rt-r6? If not,
> can I copy the definition into my
>
> FWIW, here's my DTS and some output from dmesg:
> http://pastebin.com/niDkWdWV



You need to add this to your base *.dtb:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-boneblack-audio.dts#L17-L28

(that section can not be loaded as overlay, it must be in your base dtb)

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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] u-boot stuck

[Robert Nelson]

On Mon, Apr 4, 2016 at 5:51 AM, Laurent d'Havé  wrote:

> 'Flashed' a custom angstrom build from SD as i have done many times in the
> past  (tested the image from the SD a couple of times and was working
> great)
>
> upon reboot, i get this :
>
>
> U-Boot SPL 2016.01 (Mar 25 2016 - 14:36:19)
> Trying to boot from MMC
> reading args
> spl_load_image_fat_os: error reading image args, err - -1
> reading u-boot.img
> reading u-boot.img
>
>
> U-Boot 2016.01 (Mar 25 2016 - 14:36:19 +0100)
>
>Watchdog enabled
> I2C:   ready
> DRAM:  512 MiB
> NAND:  0 MiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> *** Error - No Valid Environment Area found
> *** Warning - bad CRC, using default environment
>
> Net:not set. Validating first E-fuse MAC
> cpsw, usb_ether
> =>
>
>
>
> Won't boot from SD anymore, can't type anything ... if i try to start it
> with the "boot" button down, i'm just getting "CCC".
> If i can get it to boot from SD i can always try to fix things easily ...
>

known issue in 2016.01, it was fixed shortly after release.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] enable ADC in device tree

[Robert Nelson]

On Mon, Apr 4, 2016 at 7:23 AM, lucas  wrote:
> I am trying to enable the ADC of the BBB in the device tree. I had to
> disable to capemanager because of reasons apparent from this thread:
> https://groups.google.com/forum/#!category-topic/beagleboard/pru/IKVmIjvXnIs
>
> I have a bit of trouble to wrap my head around how the device tree works. My
> idea was to extend am335x-boneblack-overlay.dts inside the devicetree
> directory and rebuild and install it. I wanted to base this on the following
> cape:
> https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/cape-bone-iio-00A0.dts
>
> So, I took a wild guess and added

sudo sh -c "echo 'BB-ADC' > /sys/devices/platform/bone_capemgr/slots"

Read the adc values under:

/sys/bus/iio/devices/

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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Cape Manager - cannot see HDMI & eMMC (4.1.18-ti-rt kernel)

[Robert Nelson]

On Mon, Apr 4, 2016 at 8:16 AM, frank brewer 
wrote:

> Sorry for spamming but wanted to ask just to be sure: so there is no way
> to be sure that I could disable hdmi & eMMC successfully?
>

What do you mean "to be sure"...

"read" the readme.txt:

https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md

section:

BBB compatibility issues:

set the dtb for what you want.. and they set what they set..

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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Debian 8.3 ssh problems

['lukas strassel' via BeagleBoard]

Sry for my late response :/
I tried but couldn't get a response from the bbb - as it seemed I was the
only one having this problem, so I reinstalled once again (using debian
console edition) and everything worked as expected :)
So perhaps there was sth. wrong with the image I downloaded or the creation
of the bootable sdcard.

But there is something I don't understand with the console edition:
If I restart a service via:
/etc/init.d/ssh restart
i get a response in form of:
[ ok ] Restarting ssh (via systemctl): ssh.service.
but when using "service ssh restart" I don't get any response.
Probably just a missing package?

Regards,
lukas

2016-03-24 15:53 GMT+01:00 Robert Nelson :

> On Thu, Mar 24, 2016 at 9:48 AM, 'sakulstra' via BeagleBoard
>  wrote:
> > So i installed gtkterm and ran it with the provided command... than in
> > another terminal I executed dhclient eth1 - was this what you wanted me
> to
> > do?
>
> So when you fire up gtkterm, you should have a serial connection into
> the bbb.  if you hit enter it should ask you for the user, just type
> root 
>
> in the bbb: fire up:
>
> journalctl -f
>
> then on your pc:
>
> sudo dhclient eth1
>
> you should see a bunch of log messages from "journalctl -f" on what's
> going on inside the bbb.
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/bU_-l0FC5D4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Cape Manager - cannot see HDMI & eMMC (4.1.18-ti-rt kernel)

[frank brewer]

Sorry for spamming but wanted to ask just to be sure: so there is no way to 
be sure that I could disable hdmi & eMMC successfully?

Regards

On Monday, April 4, 2016 at 4:06:59 PM UTC+3, RobertCNelson wrote:
>
> On Mon, Apr 4, 2016 at 7:27 AM, frank brewer  > wrote: 
> > Thank you so much for your reply Robert, sorry I misread it. Then I have 
> > another question, then what it is the reason that when I check $SLOTS, I 
> > cannot see HDMI & emmc? Here is the output again: 
>
> Because they are not separate dtbo objects in v4.1.x 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Cape Manager - cannot see HDMI & eMMC (4.1.18-ti-rt kernel)

[Robert Nelson]

On Mon, Apr 4, 2016 at 7:27 AM, frank brewer  wrote:
> Thank you so much for your reply Robert, sorry I misread it. Then I have
> another question, then what it is the reason that when I check $SLOTS, I
> cannot see HDMI & emmc? Here is the output again:

Because they are not separate dtbo objects in v4.1.x

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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Where is BB-ADC and friends?

[Robert Nelson]

On Sun, Apr 3, 2016 at 11:24 PM, Jacek Radzikowski
 wrote:
> Robert,
>
> I installed the overlays without problems on Debian 8.4 with kernel
> 4.4.5-bone5. Adding overlays works fine, but removing them fails with
> an OOPS. I remember similar problems from the era of 3.x kernels, but
> I thought it had been addressed long time ago. Does the problem still
> persist, or is it an issue with my setup?

For now, still just reboot when you want to remove an overlay..


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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Cape Manager - cannot see HDMI & eMMC (4.1.18-ti-rt kernel)

[frank brewer]

Btw Robert, this is my uEnv.txt file:

##These are needed to be compliant with Angstrom's 2013.06.20 u-boot.


loadaddr=0x8200
fdtaddr=0x8800
rdaddr=0x8808


initrd_high=0x
fdt_high=0x


##These are needed to be compliant with Debian 2014-05-14 u-boot.


loadximage=echo debug: [/boot/vmlinuz-${uname_r}] ... ; load mmc 0:2 ${
loadaddr} /boot/vmlinuz-${uname_r}
loadxfdt=echo debug: [/boot/dtbs/${uname_r}/${fdtfile}] ... ;load mmc 0:2 ${
fdtaddr} /boot/dtbs/${uname_r}/${fdtfile}
loadxrd=echo debug: [/boot/initrd.img-${uname_r}] ... ; load mmc 0:2 ${
rdaddr} /boot/initrd.img-${uname_r}; setenv rdsize ${filesize}
loaduEnvtxt=load mmc 0:2 ${loadaddr} /boot/uEnv.txt ; env import -t ${
loadaddr} ${filesize};
check_dtb=if test -n ${dtb}; then setenv fdtfile ${dtb};fi;
loadall=run loaduEnvtxt; run check_dtb; run loadximage; run loadxrd; run 
loadxfdt;


mmcargs=setenv bootargs console=tty0 console=${console} ${optargs} ${
cape_disable} ${cape_enable} root=/dev/mmcblk0p2 rootfstype=${mmcrootfstype} 
${cmdline}


##Disable HDMI/eMMC (v3.8.x)
cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-
EMMC-2G


uenvcmd=run loadall; run mmcargs; echo debug: [${bootargs}] ... ; echo debug
: [bootz ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr}] ... ; bootz ${loadaddr} 
${rdaddr}:${rdsize} ${fdtaddr};




Regards,
Frank




On Monday, April 4, 2016 at 3:21:14 PM UTC+3, RobertCNelson wrote:
>
>
> On Apr 4, 2016 7:17 AM, "frank brewer"  
> wrote:
> >
> > I just checked 
> https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md, and 
> seems like HDMI & eMMC are disabled by default, is it true? How can I be 
> sure that those pins are not being used by HDMI & eMMC?
>
> 'Enabled' by default.. Read the readme again, for the correct dtb= option 
> for HDMI and emmc disabled.
>
> Regards, 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Cape Manager - cannot see HDMI & eMMC (4.1.18-ti-rt kernel)

[frank brewer]

Thank you so much for your reply Robert, sorry I misread it. Then I have 
another question, then what it is the reason that when I check $SLOTS, I 
cannot see HDMI & emmc? Here is the output again:


frank@beaglebone:~/chp13/overlay$ cat $SLOTS
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1

Also, I added:

cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-
EMMC-2G



to uEnv.txt, however I since I cannot see HDMI & eMMC under $SLOTS, then 
how can I be sure that I freed them successfully?

Thanks again!


On Monday, April 4, 2016 at 3:21:14 PM UTC+3, RobertCNelson wrote:
>
>
> On Apr 4, 2016 7:17 AM, "frank brewer"  
> wrote:
> >
> > I just checked 
> https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md, and 
> seems like HDMI & eMMC are disabled by default, is it true? How can I be 
> sure that those pins are not being used by HDMI & eMMC?
>
> 'Enabled' by default.. Read the readme again, for the correct dtb= option 
> for HDMI and emmc disabled.
>
> Regards, 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] enable ADC in device tree

[lucas]

I am trying to enable the ADC of the BBB in the device tree. I had to 
disable to capemanager because of reasons apparent from this 
thread: 
https://groups.google.com/forum/#!category-topic/beagleboard/pru/IKVmIjvXnIs

I have a bit of trouble to wrap my head around how the device tree works. 
My idea was to extend am335x-boneblack-overlay.dts inside the devicetree 
directory and rebuild and install it. I wanted to base this on the 
following 
cape: 
https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/cape-bone-iio-00A0.dts

So, I took a wild guess and added 

/** ADC ***/
{
tscadc {
compatible = "ti,ti-tscadc";
reg = <0x44e0d000 0x1000>;

interrupt-parent = <>;
interrupts = <16>;
ti,hwmods = "adc_tsc";
status = "okay";

adc {
ti,adc-channels = <0 1 2 3 4 5 6 7>;
};
};

test_helper: helper {
compatible = "bone-iio-helper";
vsense-name  = "AIN0", "AIN1", "AIN2", "AIN3", "AIN4", "AIN5", "AIN6", 
"AIN7";
vsense-scale = <100 100 100 100 100 100 100 
100>;
status = "okay";
};
};

at the end of  am335x-boneblack-overlay.dts. This compiled fine and I was 
able to install it and reboot without any apparent errors. But 
unfortunately, this didn't add any AIN* devices (the command "find /sys/ - 
name '*AIN*' " doesn't find anything). So, how could I go about enabling 
the ADC without using the capemanger? 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Cape Manager - cannot see HDMI & eMMC (4.1.18-ti-rt kernel)

[Robert Nelson]

On Apr 4, 2016 7:17 AM, "frank brewer"  wrote:
>
> I just checked
https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md, and
seems like HDMI & eMMC are disabled by default, is it true? How can I be
sure that those pins are not being used by HDMI & eMMC?

'Enabled' by default.. Read the readme again, for the correct dtb= option
for HDMI and emmc disabled.

Regards,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Cape Manager - cannot see HDMI & eMMC (4.1.18-ti-rt kernel)

[frank brewer]

I just 
checked https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md, 
and seems like HDMI & eMMC are disabled by default, is it true? How can I 
be sure that those pins are not being used by HDMI & eMMC?

Thanks!

On Monday, April 4, 2016 at 11:58:11 AM UTC+3, frank brewer wrote:
>
> I just upgraded by kernel and dtc version. Here are their outputs:
>
> frank@beaglebone:/media$ uname -r
> 4.1.18-ti-rt-r56
> frank@beaglebone:/media$ dtc --version
> Version: DTC 1.4.1-g1e75ebc9
>
>
> Now when I check slots, HDMI & eMMC are not shown:
>
> frank@beaglebone:/media$ 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,cape-universaln
>
> What might be the problem? What should I do?
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.