Re: [beagleboard] Tools to debug the driver .

[John Syne]

I completely agree with Vesa comments and I believe Lauterbach is the gold 
standard when it comes to Kernel Aware debugging. It is a difficult tool to 
learn but it is very powerful and has everything you need to get the job done. 
I have learned a lot just using the T32.

Several years ago, I worked with the CCSV4 developers at TI and they did manage 
to get a decent kernel aware debugger working, but they dropped those features 
in CCSV5 because they wanted to stay closer to the Eclipse base environment so 
that upgrades to newer Eclipse releases was easier. Their plan was to add Linux 
Kernel aware debugging, but later decided that there wasn’t enough interest to 
justify the investment. As of CCSV6, they still don’t have Linux kernel ware 
debugging. From what they told me, I was one of the few users who was asking 
for Linux Kernel aware debugging. At that time, I made the switch to Lauterbach 
and have never looked back. 

I also use BDI2000/BDI3000 from Abatron and PEEDi from Ronetix which act as a 
gdbserver so any GDB compatible debug app can be used for debugging. While they 
do have some kernel aware debugging capabilities, they are no ware as 
comprehensive as Lauterbach. 

Regarding FlySwatter2, you are better off purchasing a Blackhawk USB200 which 
cost less than $100 and it works fine with CCSV6. FlySwatter requires a lot of 
work on your behalf to make it work.

Regards,
John




> On May 5, 2016, at 1:06 AM, Vesa Jääskeläinen  wrote:
> 
> Hi,
> 
> If you really want to work with Linux JTAG debugging you need to have a JTAG 
> debugger and debugging software that is really Linux aware. There aren't many 
> available that really support both kernel and app debugging at the same time 
> for Linux using JTAG connectivity.
> 
> You may want to check out Peter Griffin's GDB and Linux Kernel Awareness 
> slides from Embedded Linux Conference Europe 2015:
> http://events.linuxfoundation.org/sites/events/files/slides/ELC-E%20Linux%20Awareness.pdf
> 
> If you want to save your time and do your work today I recommend paying a bit 
> more than that and go for even for entry level Lauterbach's Power Debug 
> debugger. Their software (Trace32) is not pretty for today's standards but 
> has bunch of features that makes your life easier. There is slight learning 
> curve for the tool but once that is done it gets your work done. Price is 
> thou 4 number figure (in euros/dollars -- lower half).
> 
> If you are looking for ARM DS-5 -- it has also some features and a bit 
> shinier user interface (in some places) but currently lacks in some features 
> that are found in Trace32 -- perhaps biggest is co-debugging over JTAG for 
> Kernel and Applications at the same time, next missing feature is general 
> flexibility I suppose. This same story matches quite a lot of debugging 
> software currently available. DS-5's system profiler is something that might 
> be interest for some.
> 
> If you want to play around with open source alternatives -- especially then 
> check the presentation above.
> 
> Also note that BBB has TI's Compact JTAG connector -- so get matching adapter 
> and solder the socket.
> 
> TI has done some work with their Code Composer Studio and then there are some 
> low cost JTAG debuggers that are compatible with the tool -- you are locked 
> to TI's ecosystem but that might also be something to consider. It also 
> exposes some "homemade" features of TI processors. Haven't used the tool for 
> Linux kernel debugging but there might be someone here with experience with 
> the tool for that purpose.
> 
> And if someone has other kind of experiences in here I would love to hear :) 
> both OSS and commercial solutions are in interest.
> 
> Thanks,
> Vesa Jääskeläinen
> 
> On 05/05/16 07:52, Raul Piper wrote:
>> Is TIN FlysWatter2  a 
>> better tool for debugging the kernel driver in BBB.Can some one please post 
>> thier experience?
>> -Rp
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/ea576ae1-cb10-4ebc-8ae6-a17f6c694970%40googlegroups.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] Power - shutdown

[John Syne]

You cannot just use a supercap. You have to use a boost switching regulator to 
keep the voltage on the processor constant while the supercap discharges. 
This is a lot more complicated than you suggest. You also have to deal with the 
case of brown outs where the power is only off for fractions of a seconds or 
cases where the power comes on and then off again before the board has fully 
powered up. This requires a power monitor and a state machine to only power the 
board on once the supercap is fully charged. Also, if you don’t recycle the 
power after a power fail, the BBB has the potential to lock and remains locked 
until the power is recycled. 

Regards,
John




> On May 2, 2016, at 11:09 AM, William Hermans  wrote:
> 
> Use a super capacitor.
> 
> Ok, a little abstract . . .
> 
> Use a super capacitor, and if using a console image . . .  sudo apt-get 
> install acpid
> 
> Then the board will automatically shutdown when 5V input goes missing. I'd 
> make sure you pick a super cap that can sustain the beaglebone for ~30 
> seconds, even if not needed. Just in case. Typically though, here, we see 
> that the board shuts down within 5 seconds or so. Maybe slightly longer. 
> 
> On Mon, May 2, 2016 at 10:47 AM, William Hermans  > wrote:
> I have been building embedded systems for a while now and I am considering 
> using the beaglebone (BBB) for an upcoming project, but I am confused by 
> everything I read regarding the shutdown requirements. As an embedded system 
> the only way to turn it off is to simply shutdown the power with a switch, 
> yet my preliminary research indicates that this is a no-no as it may damage 
> the BBB and/or corrupt the file system.  I also read a lot of comments 
> regarding voltage on the pins after a shutdown; in my case, very likely there 
> will be a CAT5 cable with live activity connected even after power down; 
> assume the magnetics should protect the BBB, but just checking.
> 
> This is true of any system running an OS that is not red only. If you 
> unceremoniously yank the power, you're asking for trouble.
> 
> I have used quite a few micro controllers and various self-standing systems, 
> but am fairly new to the BBB - still mostly reading about it.  Am I missing 
> something?  How can a device meant to be used in embedded systems not be 
> tolerant of power loss and be so finicky about power?
> 
> It sounds like you're missing a lot. It sounds like you've had a lot of 
> experience with small micros, that run bare metal, but have have no, or 
> limited experience with using an embedded OS. 
> 
> Then if you stop and think of the cost of this board, and what the goal of 
> beagleboard.org  was when the board was created. 
> Perhaps then it become clear as to how / why we're where we are in this 
> context. You can fix all of this yourself, using external hardware, and 
> custom software.
> 
> By the way, I can see there is a battery backup circuit but I do not want to 
> use a lithium battery for safety/temperature/cost reasons.  Using a large 
> capacitor also seems tricky as the shutdown may take a few seconds so I don't 
> see how that will work.
> 
> Any suggestions would be greatly appreciated.
> 
> Use a super capacitor.
> 
> 
> 
> On Mon, May 2, 2016 at 8:39 AM, Gerald Coley  > wrote:
> 
> 
> On Mon, May 2, 2016 at 10:36 AM, Yiannis Papelis  > wrote:
> I have been building embedded systems for a while now and I am considering 
> using the beaglebone (BBB) for an upcoming project, but I am confused by 
> everything I read regarding the shutdown requirements. As an embedded system 
> the only way to turn it off is to simply shutdown the power with a switch, 
> yet my preliminary research indicates that this is a no-no as it may damage 
> the BBB and/or corrupt the file system.  I also read a lot of comments 
> regarding voltage on the pins after a shutdown; in my case, very likely there 
> will be a CAT5 cable with live activity connected even after power down; 
> assume the magnetics should protect the BBB, but just checking.
> 
> I have used quite a few micro controllers and various self-standing systems, 
> but am fairly new to the BBB - still mostly reading about it.  Am I missing 
> something?  How can a device meant to be used in embedded systems not be 
> tolerant of power loss and be so finicky about power?
> 
> By the way, I can see there is a battery backup circuit but I do not want to 
> use a lithium battery for safety/temperature/cost reasons.  Using a large 
> capacitor also seems tricky as the shutdown may take a few seconds so I don't 
> see how that will work.
> 
> Any suggestions would be greatly appreciated.
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message 

Re: [beagleboard] mcasp pinmux settings

[John Syne]

The pinmux input/output setting are only relevant when using GPIO. When using a 
peripheral like McASP, the input/output are defined by the pin function. Also, 
the serializers directions are defined by:

serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
2 0 1 0
0 0 0 0
0 0 0 0
0 0 0 0
>;

Regards,
John




> On Apr 28, 2016, at 9:43 PM, evilwulfie  wrote:
> 
> Not much help
> there is a file i have found  BB-BONE-AUDI-03-00A0.dts
> that have other settings
> 
> fragment@0 {
> target = <_pinmux>;
> __overlay__ {
> 
> bone_audio_cape_audio_pins: pinmux_bone_audio_cape_audio_pins {
> pinctrl-single,pins = <
> 0x1ac 0x20/* mcasp0_ahclkx, INPUT | MODE0 */
> 0x19c 0x22/* mcasp0_axr2, INPUT | MODE2 */
> 0x194 0x20/* mcasp0_fsx, INPUT | MODE0 */
> 0x198 0x08/* mcasp0_axr0, OUTPUT | MODE0 */
> 0x190 0x20/* mcasp0_aclkx, INPUT | MODE0 */
> >;
> };
> };
> };
> 
> seems closer but still backwards in my eye
> 
> 
> On 4/28/2016 9:39 PM, William Hermans wrote:
>> I really hate when gmail does that crap . . .
>> 
>> pinctrl-single,pins = <
>> 0x190 (PIN_INPUT_PULLDOWN | MUX_MODE0)/*
>> mcasp0_aclkx.mcasp0_aclkx */
>> 0x194 (PIN_INPUT_PULLDOWN | MUX_MODE0)/*
>> mcasp0_fsx.mcasp0_fsx, INPUT */
>> 0x198 (PIN_INPUT_PULLDOWN | MUX_MODE0)/*
>> mcasp0_axr0.mcasp0_axr0 */
>> 0x19c (PIN_INPUT_PULLDOWN | MUX_MODE2)/*
>> mcasp0_ahclkr.mcasp0_axr2 */
>> 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE0)/*
>> MCASP0_AHCLKX -> MCASP0_AHCLKX (I2S_MCLK_OUT)- in */
>> >;
>> 
>> On Thu, Apr 28, 2016 at 9:38 PM, William Hermans > > wrote:
>> pinctrl-single,pins = <
>> 0x190 (PIN_INPUT_PULLDOWN | MUX_MODE0)/*
>> mcasp0_aclkx.mcasp0_aclkx */
>> 0x194 (PIN_INPUT_PULLDOWN | MUX_MODE0)/*
>> mcasp0_fsx.mcasp0_fsx, INPUT */
>> 0x198 (PIN_INPUT_PULLDOWN | MUX_MODE0)/*
>> mcasp0_axr0.mcasp0_axr0 */
>> 0x19c (PIN_INPUT_PULLDOWN | MUX_MODE2)/*
>> mcasp0_ahclkr.mcasp0_axr2 */
>> 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE0)/*
>> MCASP0_AHCLKX -> MCASP0_AHCLKX (I2S_MCLK_OUT)- in */
>> >;
>> 
>> On Thu, Apr 28, 2016 at 9:24 PM, evilwulfie < 
>> evilwul...@gmail.com 
>> > wrote:
>> Ok  I am slightly confused her on the pinmux signal directions.
>> 
>> In the BB-BONE-AUDI-02-00A0.dts file we have all pins set to inputs
>> 
>> fragment@0 {
>> target = <_pinmux>;
>> __overlay__ {
>> bone_audio_cape_audio_pins: pinmux_bone_audio_cape_audio_pins {
>> pinctrl-single,pins = <
>> 0x190 (PIN_INPUT_PULLDOWN | MUX_MODE0)/*
>> mcasp0_aclkx.mcasp0_aclkx */
>> 0x194 (PIN_INPUT_PULLDOWN | MUX_MODE0)/*
>> mcasp0_fsx.mcasp0_fsx, INPUT */
>> 0x198 (PIN_INPUT_PULLDOWN | MUX_MODE0)/*
>> mcasp0_axr0.mcasp0_axr0 */
>> 0x19c (PIN_INPUT_PULLDOWN | MUX_MODE2)/*
>> mcasp0_ahclkr.mcasp0_axr2 */
>> 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE0)/*
>> MCASP0_AHCLKX -> MCASP0_AHCLKX (I2S_MCLK_OUT)- in */
>> >;
>> };
>> };
>> };
>> 
>> Am i missing something here ? All pins should be outputs except the
>> audio input on axr0.mcasp0 which should be an input.
>> 
>> On the UARTS the signal directions are correct.
>> 
>> Is there some black magic that i am missing ?
>> 
>> 
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus 
>> 
>> --
>> For more options, visit  
>> http://beagleboard.org/discuss 
>> 
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to  
>> beagleboard+unsubscr...@googlegroups.com
>>  .
>> To view this discussion on the web visit  
>> https://groups.google.com/d/msgid/beagleboard/89a7327f-23fc-3b59-958a-1d4b741575c9%40gmail.com
>>  
>> .
>> For more options, visit  
>> https://groups.google.com/d/optout 
>> 

Re: [beagleboard] Fast Pin Toggling Using MMAP

[John Syne]

> On Apr 28, 2016, at 4:46 AM, frank brewer  wrote:
> 
> 
> I just noticed the faster way of toggling pins by using mmap, and after 
> trying chiragnagpal's example, I could achieve 2.6MHz. 
> 
> 
> 
> Example was for 1 pin only, now I want to use 8 pins, so I edited .dtc file 
> as following:
> 
> /*
> * 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 Purpose License Version 2 as
> * published by the Free Software Foundation
> *
> * Original from: 
> github.com/jadonk/validation-scripts/blob/master/test-capemgr/
> *
> * Modified by Derek Molloy for the example on www.derekmolloy.ie
> * that maps GPIO pins for the example
> */
> 
> 
> /dts-v1/;
> /plugin/;
> 
> 
> /{
>compatible = "ti,beaglebone", "ti,beaglebone-black";
>part-number = "DM-GPIO-Test";
>version = "00A0";
> 
> 
>fragment@0 {
>  target = <_pinmux>;
> 
> 
>  __overlay__ {
>   pinctrl_test: DM_GPIO_Test_Pins {
> pinctrl-single,pins = <
> 
> 
> 0x070 0x07  /* P9_11 60 OUTPUT MODE7 - The 
> LED Output */
> 0x078 0x07  /* P9_12 60 OUTPUT MODE7 - The 
> LED Output */
> 0x074 0x07  /* P9_13 60 OUTPUT MODE7 - The 
> LED Output */
> 0x048 0x07  /* P9_14 60 OUTPUT MODE7 - The 
> LED Output */
> 0x040 0x07  /* P9_15 60 OUTPUT MODE7 - The 
> LED Output */
> 0x04c 0x07  /* P9_16 60 OUTPUT MODE7 - The 
> LED Output */
> 0x15c 0x07  /* P9_17 60 OUTPUT MODE7 - The 
> LED Output */
> 0x158 0x07  /* P9_18 60 OUTPUT MODE7 - The 
> LED Output */
> 
> 
> 
> 
>/* OUTPUT  GPIO(mode7) 0x07 pulldown, 0x17 
> pullup, 0x?f no pullup/down */
>/* INPUT   GPIO(mode7) 0x27 pulldown, 0x37 
> pullup, 0x?f no pullup/down */
> 
> 
> >;
>   };
>  };
>};
> 
> 
>fragment@1 {
> target = <>;
> __overlay__ {
> test_helper: helper {
> compatible = "bone-pinmux-helper";
> pinctrl-names = "default";
> pinctrl-0 = <_test>;
> status = "okay";
> };
> };
> };
> };
> 
> 
> However I could not figure out how to edit the header file used in the 
> example. Here is the header file of the example:
> 
> #ifndef _BEAGLEBONE_GPIO_H_
> #define _BEAGLEBONE_GPIO_H_
> 
> 
> #define GPIO1_START_ADDR 0x4804C000
> #define GPIO1_END_ADDR 0x4804DFFF
> #define GPIO1_SIZE (GPIO1_END_ADDR - GPIO1_START_ADDR)
> #define GPIO_OE 0x134
> #define GPIO_SETDATAOUT 0x194
> #define GPIO_CLEARDATAOUT 0x190
> 
> 
> 
> 
> #define PIN (1<<28)
> 
> 
> 
> 
> #endif
> 
> 
> Questions:
> 
> 1) I could not find START_ADDR, END_ADDR, OE, SETDATAOUT, CLEARDATAOUT from 
> technical manual. Where can I find them for the pins from P9_11 ... upto P9_18
See AM3358 TRM Table 2-3 GPIO1
> 
> 2) what is the explanation of the following statement? What does it do?
> define PIN ( 1<<28)
Take a 1 and left shift by 28. This means bit 28 is set.

>From Section 25.4
134h GPIO_OE
190h GPIO_CLEARDATAOUT
194h GPIO_SETDATAOUT

Learn to read the TRM. Section 2.1, Memory Map. Last section of each chapter is 
the register layout, for example, 25.4 is the GPIO register layout. 

> 
> 3) I am going to use it for SPI communication, so since the timing is 
> critical, and Linux is not RT, there is a possibility that some other 
> interrupts may damage my communaction. Do you think that it would be a 
> problem? If yes, what precautions can I get?
It is possible because the data is synchronized to the clock. However, I would 
recommend doing this with PRU.

Regards,
John
> 
> Regards,
> Frank
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/fe2ed36d-96bb-43d3-aeee-9e85fcbfd04b%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, 

Re: [beagleboard] connman & NFS

[John Syne]

Thanks Robert.

Regards,
John




> On Apr 22, 2016, at 4:57 PM, Robert Nelson <robertcnel...@gmail.com> wrote:
> 
> 
> 
> On Fri, Apr 22, 2016 at 6:23 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> Over the past couple of weeks, connman has been updated twice and in each 
> instance it breaks my BBB over NFS.
> 
> Here is what happens:
> 
> In my /lib/systemd/system/connman.service, I have a line:
> 
> ExecStart=/usr/sbin/connman -n -I eth0 // Prevent connman from managing eth0
> 
> which the upgrade changes to:
> 
> ExecStart=/usr/sbin/connman -n
> 
> and that breaks my apt-get upgrade while updating connman because I see:
> 
> nfs: server 10.100.116.105 not responding, still trying
> 
> My only option is to cycle the BBB power and then issue the following command 
> to complete the connman installation:
> 
> dpkg —configure -a
> 
> Now I am able to boot, but DNS won’t work (connman isn’t managing eth0)
> 
> To fix this, I have to delete
> 
> /usr/lib/tempfile.d/connman/resolv.conf
> 
> and then create a file
> 
> /var/run/connman/resolv.conf
> 
> which /etc/resolv.conf is linked to.
> 
> Is there a better way to deal with this issue?
> 
> Ah crap, that's me...  Sorry about that.. 
> 
> Yeah, i need to detect eth0 is in connman.service and not remove it.  Before 
> i even think about pushing the next connman update..
> 
> We had a bug in connman where the wifi softap was no longer coming up..
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/ <https://rcn-ee.com/>
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYhc7QwChjNwF3j_vORo2Y6vvCvyA_HzRA7K7m4UsEn96A%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/beagleboard/CAOCHtYhc7QwChjNwF3j_vORo2Y6vvCvyA_HzRA7K7m4UsEn96A%40mail.gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/861AF8D4-A311-4893-A747-C8B0EABB0C5C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] connman & NFS

[John Syne]

Over the past couple of weeks, connman has been updated twice and in each 
instance it breaks my BBB over NFS. 

Here is what happens:

In my /lib/systemd/system/connman.service, I have a line:

ExecStart=/usr/sbin/connman -n -I eth0 // Prevent connman from managing eth0

which the upgrade changes to:

ExecStart=/usr/sbin/connman -n

and that breaks my apt-get upgrade while updating connman because I see:

nfs: server 10.100.116.105 not responding, still trying

My only option is to cycle the BBB power and then issue the following command 
to complete the connman installation:

dpkg —configure -a

Now I am able to boot, but DNS won’t work (connman isn’t managing eth0)

To fix this, I have to delete

/usr/lib/tempfile.d/connman/resolv.conf

and then create a file

/var/run/connman/resolv.conf

which /etc/resolv.conf is linked to.

Is there a better way to deal with this issue?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0173B620-6D50-4236-BFEA-61D4046B2BE0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] CCSV6 for MacOS

[John Syne]

TI have just released Code Composer Studio for MacOS. I’ve been pushing them to 
release a Mac version for year. In the process of downloading, so I don’t know 
how functional it is yet. 

http://processors.wiki.ti.com/index.php/Download_CCS 


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ABEEB848-CCCD-499A-A7F4-272CC3C7D2C6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] uio_pruss on Mainline Linux

[John Syne]

The main concepts remain the same. What has changed is TI are moving to use 
standard API’s instead of some of the custom API’s they used in the past. For 
example one of the chief improvements over 4.1 they are making is to introduce 
a irqchip, so that client users can use standard irq handling API instead
of the custom API in 4.1. TI should be introducing this in their 4.4 TI 
Processor SDK release. We however should have access to the update in a few 
weeks. 

Regards,
John




> On Apr 22, 2016, at 12:56 PM, tcmichals  wrote:
> 
> 
> 
> Maybe you should explain why you think this is worthless? 
> if the software is under going a redesign what are the changes? does this 
> mean the documentation is now worthless due to the redesign? 
>> remoteproc_pruss is getting "redesigned" again... ;(
>> 
>> woow, here is new documentation from TI and now its worthless? 
>> http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg 
>>  
>> 
> 
>  
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/8714ebfc-0037-4983-8243-1461c3f692eb%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/D6171C45-AE59-4A18-AA78-83F7A1E0A57D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] uio_pruss on Mainline Linux

[John Syne]

Maybe you should explain why you think this is worthless?

Regards,
John




> On Apr 22, 2016, at 6:29 AM, tcmichals  wrote:
> 
> 
> 
> remoteproc_pruss is getting "redesigned" again... ;(
> 
> woow, here is new documentation from TI and now its worthless? 
> http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/252f12c9-5f22-4e2a-8321-10ff0a756672%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/DD65ED21-A327-429D-A4CD-0A6982E21885%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] uio_pruss on Mainline Linux

[John Syne]

But this was done a while ago when the added support for ethernet. I’m not 
aware of any other changes. 

Regards,
John




> On Apr 21, 2016, at 5:21 PM, Robert Nelson  wrote:
> 
> 
> 
> On Thu, Apr 21, 2016 at 7:09 PM, Jordan Yelloz  > wrote:
> Thanks, that appears to be a pretty small patch, I'll try it out.
> I would have no problem using the remoteproc_pruss if it was in the official 
> kernel but I can't see any as of 4.6-rc4.
> 
> remoteproc_pruss is getting "redesigned" again... ;(
> 
> I'm tempted to say, let's just clean it up and push it.
> 
> If someone complains, uio_pruss has been in mainline for awhile, and 
> remoteproc_pruss has gone no where. ;)
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/ 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYggjgGzF-wgU5hac8om7XwBoH6DNZg%3DGqanHoG7j0Ji%3DQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CCD3E8F7-B3EB-475A-91E0-E2E5CD34C092%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Battery shutdown

[John Syne]

Yep, perfectly clear. You are a hater and there is no hope for you. Strange how 
the few conflicts on this forum have always involved you as one of the parties. 
I don’t recall any other conflicts that did not involve you. Perhaps you need 
professional help to get over your anger issues. Anyway, good luck to you.

Regards,
John




> On Apr 20, 2016, at 9:40 AM, William Hermans <yyrk...@gmail.com> wrote:
> 
> What a shitty attitude. I don’t mind helping people out who appreciate the 
> help, but why would anyone help you when you all you do is complain about the 
> help. 
> Regards,
> John
> It's not just anyone who gets this special treatment. Just you. I dont like 
> you, have told you this repeatedly and yet you feel compelled to inject 
> yourself into discussions I start, or participate in. I even told you I would 
> have nothing further to say to you ever. And you again felt compelled to 
> inject yourself into this discussion.
> 
> But hey, who knows, maybe someday you'll get the hint.
> 
> 
> On Wed, Apr 20, 2016 at 1:48 AM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> What a shitty attitude. I don’t mind helping people out who appreciate the 
> help, but why would anyone help you when you all you do is complain about the 
> help. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 20, 2016, at 1:18 AM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> 
>> I just don’t understand what you are asking for. The code is self 
>> explanatory and with a little effort, you can make it work. My guess is you 
>> want me to add the include headers and create the Makefile and Kconfig 
>> files. If that is what you want, I can do it for you, but I thought you 
>> would know how to do this yourself. Take a book and read about sigaction. 
>> I’m sure you will find examples just like the ones I sent you. I’ve pulled 
>> code like this together for year to understand how comms works between the 
>> kernel and user space.  
>> Regards,
>> John
>> Dont do it for me, because I do not need it. Do it for all those interested 
>> people you mentioned before. 
>> 
>> You say it's easy, and you're pasting in random code here in there, but I've 
>> yet to see you come up with a real, and solid solution. You keep talking 
>> around the subject like it's simple . . .so put your money where your mouth 
>> is. 
>> 
>> Either that, or stop "talking", because you're not helping anyone.
>> 
>> 
>> On Wed, Apr 20, 2016 at 12:59 AM, John Syne <john3...@gmail.com 
>> <mailto:john3...@gmail.com>> wrote:
>> I just don’t understand what you are asking for. The code is self 
>> explanatory and with a little effort, you can make it work. My guess is you 
>> want me to add the include headers and create the Makefile and Kconfig 
>> files. If that is what you want, I can do it for you, but I thought you 
>> would know how to do this yourself. Take a book and read about sigaction. 
>> I’m sure you will find examples just like the ones I sent you. I’ve pulled 
>> code like this together for year to understand how comms works between the 
>> kernel and user space.  
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 20, 2016, at 12:45 AM, William Hermans <yyrk...@gmail.com 
>>> <mailto:yyrk...@gmail.com>> wrote:
>>> 
>>> Well that is not how I'd do things, and I suppose that code if complete and 
>>> integrated into the tps65217.c file, it might work . . .
>>> 
>>> But as I said that code is not complete, and is what looks like example 
>>> code out of some Documentation/*txt file. 
>>> 
>>> On Tue, Apr 19, 2016 at 10:14 PM, John Syne <john3...@gmail.com 
>>> <mailto:john3...@gmail.com>> wrote:
>>> 
>>>> On Apr 19, 2016, at 9:28 PM, William Hermans <yyrk...@gmail.com 
>>>> <mailto:yyrk...@gmail.com>> wrote:
>>>> 
>>>> That's not what I was saying at all. I'm saying if all this is that easy 
>>>> for you, then you should add this functionality, and be the community hero.
>>>> 
>>>> This sort of thing is definitely not above my pay grade, but I am not a 
>>>> kernel hacker, and I do not know the file structure all that well. So it 
>>>> would take me a while to to figure out everything I need to know, about 
>>>> everything I'd need. So if this thing is really that easy for you, why 
>>>> don't you make a new LKM, something that takes an argument, 

Re: [beagleboard] BBB Battery shutdown

[John Syne]

What a shitty attitude. I don’t mind helping people out who appreciate the 
help, but why would anyone help you when you all you do is complain about the 
help. 

Regards,
John




> On Apr 20, 2016, at 1:18 AM, William Hermans <yyrk...@gmail.com> wrote:
> 
> I just don’t understand what you are asking for. The code is self explanatory 
> and with a little effort, you can make it work. My guess is you want me to 
> add the include headers and create the Makefile and Kconfig files. If that is 
> what you want, I can do it for you, but I thought you would know how to do 
> this yourself. Take a book and read about sigaction. I’m sure you will find 
> examples just like the ones I sent you. I’ve pulled code like this together 
> for year to understand how comms works between the kernel and user space.  
> Regards,
> John
> Dont do it for me, because I do not need it. Do it for all those interested 
> people you mentioned before. 
> 
> You say it's easy, and you're pasting in random code here in there, but I've 
> yet to see you come up with a real, and solid solution. You keep talking 
> around the subject like it's simple . . .so put your money where your mouth 
> is. 
> 
> Either that, or stop "talking", because you're not helping anyone.
> 
> 
> On Wed, Apr 20, 2016 at 12:59 AM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> I just don’t understand what you are asking for. The code is self explanatory 
> and with a little effort, you can make it work. My guess is you want me to 
> add the include headers and create the Makefile and Kconfig files. If that is 
> what you want, I can do it for you, but I thought you would know how to do 
> this yourself. Take a book and read about sigaction. I’m sure you will find 
> examples just like the ones I sent you. I’ve pulled code like this together 
> for year to understand how comms works between the kernel and user space.  
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 20, 2016, at 12:45 AM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> 
>> Well that is not how I'd do things, and I suppose that code if complete and 
>> integrated into the tps65217.c file, it might work . . .
>> 
>> But as I said that code is not complete, and is what looks like example code 
>> out of some Documentation/*txt file. 
>> 
>> On Tue, Apr 19, 2016 at 10:14 PM, John Syne <john3...@gmail.com 
>> <mailto:john3...@gmail.com>> wrote:
>> 
>>> On Apr 19, 2016, at 9:28 PM, William Hermans <yyrk...@gmail.com 
>>> <mailto:yyrk...@gmail.com>> wrote:
>>> 
>>> That's not what I was saying at all. I'm saying if all this is that easy 
>>> for you, then you should add this functionality, and be the community hero.
>>> 
>>> This sort of thing is definitely not above my pay grade, but I am not a 
>>> kernel hacker, and I do not know the file structure all that well. So it 
>>> would take me a while to to figure out everything I need to know, about 
>>> everything I'd need. So if this thing is really that easy for you, why 
>>> don't you make a new LKM, something that takes an argument, or two. LIke 
>>> g_multi where you pass in a path for the g_mass_storage bit of the driver. 
>>> Except of course, you want to be able to set a time out for a shutdown.
>>> 
>>> Second, a kernel module should not require a specific init daemon. That 
>>> goes against the whole point of Linux.
>>> 
>>> 
>>> FYI I could do this entirely in userspace, really easily. Except I would 
>>> have to poll, instead of using an interrupt, and I pretty much be writing 
>>> duplicate code, or code that does a duplicate job. But passed that I really 
>>> do not have to time for this, or to read through, and understand all the 
>>> required Linux kernel, and LKMs to do this "properly". It's a lot of work 
>>> for someone who really doesn't know what they're doing.
>> Yep, it can be done in user space as well. Simply add sigaction to the 
>> tps65217 mfd driver. Here is an example of a standalone KM with a user space 
>> app. So now we do not use input key, but send events via kernel signals 
>> (similar to kill -9 pid or ctrl-c).
>> 
>> Kernel Code:
>> 
>> ===
>> #define SIG_TEST 44  // we choose 44 as our signal number (real-time signals 
>> are in the range of 33 to 64)
>> 
>> struct dentry *file;
>> 
>> static ssize_t write_pid(struct file *file, const char __user *buf,
>> size_t count, lof

Re: [beagleboard] BBB Battery shutdown

[John Syne]

I just don’t understand what you are asking for. The code is self explanatory 
and with a little effort, you can make it work. My guess is you want me to add 
the include headers and create the Makefile and Kconfig files. If that is what 
you want, I can do it for you, but I thought you would know how to do this 
yourself. Take a book and read about sigaction. I’m sure you will find examples 
just like the ones I sent you. I’ve pulled code like this together for year to 
understand how comms works between the kernel and user space.  

Regards,
John




> On Apr 20, 2016, at 12:45 AM, William Hermans <yyrk...@gmail.com> wrote:
> 
> Well that is not how I'd do things, and I suppose that code if complete and 
> integrated into the tps65217.c file, it might work . . .
> 
> But as I said that code is not complete, and is what looks like example code 
> out of some Documentation/*txt file. 
> 
> On Tue, Apr 19, 2016 at 10:14 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> 
>> On Apr 19, 2016, at 9:28 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> 
>> That's not what I was saying at all. I'm saying if all this is that easy for 
>> you, then you should add this functionality, and be the community hero.
>> 
>> This sort of thing is definitely not above my pay grade, but I am not a 
>> kernel hacker, and I do not know the file structure all that well. So it 
>> would take me a while to to figure out everything I need to know, about 
>> everything I'd need. So if this thing is really that easy for you, why don't 
>> you make a new LKM, something that takes an argument, or two. LIke g_multi 
>> where you pass in a path for the g_mass_storage bit of the driver. Except of 
>> course, you want to be able to set a time out for a shutdown.
>> 
>> Second, a kernel module should not require a specific init daemon. That goes 
>> against the whole point of Linux.
>> 
>> 
>> FYI I could do this entirely in userspace, really easily. Except I would 
>> have to poll, instead of using an interrupt, and I pretty much be writing 
>> duplicate code, or code that does a duplicate job. But passed that I really 
>> do not have to time for this, or to read through, and understand all the 
>> required Linux kernel, and LKMs to do this "properly". It's a lot of work 
>> for someone who really doesn't know what they're doing.
> Yep, it can be done in user space as well. Simply add sigaction to the 
> tps65217 mfd driver. Here is an example of a standalone KM with a user space 
> app. So now we do not use input key, but send events via kernel signals 
> (similar to kill -9 pid or ctrl-c).
> 
> Kernel Code:
> 
> ===
> #define SIG_TEST 44   // we choose 44 as our signal number (real-time signals 
> are in the range of 33 to 64)
> 
> struct dentry *file;
> 
> static ssize_t write_pid(struct file *file, const char __user *buf,
> size_t count, loff_t *ppos)
> {
>   char mybuf[10];
>   int pid = 0;
>   int ret;
>   struct siginfo info;
>   struct task_struct *t;
>   /* read the value from user space */
>   if(count > 10)
>   return -EINVAL;
>   copy_from_user(mybuf, buf, count);
>   sscanf(mybuf, "%d", );
>   printk("pid = %d\n", pid);
> 
>   /* send the signal */
>   memset(, 0, sizeof(struct siginfo));
>   info.si <http://info.si/>_signo = SIG_TEST;
>   info.si <http://info.si/>_code = SI_QUEUE;  // this is bit of a 
> trickery: SI_QUEUE is normally used by sigqueue from user space,
>   // and kernel space should use 
> SI_KERNEL. But if SI_KERNEL is used the real_time data
>   // is not delivered to the user space 
> signal handler function.
>   info.si <http://info.si/>_int = 1234;   //real time signals may 
> have 32 bits of data.
> 
>   rcu_read_lock();
> //t = find_task_by_pid_type(PIDTYPE_PID, pid);  //find the task_struct 
> associated with this pid
>   t = pid_task(find_pid_ns(pid, _pid_ns), PIDTYPE_PID);
>   if(t == NULL){
>   printk("no such pid\n");
>   rcu_read_unlock();
>   return -ENODEV;
>   }
>   rcu_read_unlock();
>   ret = send_sig_info(SIG_TEST, , t);//send the signal
>   if (ret < 0) {
>   printk("error sending signal\n");
>   return ret;
>   }
>   return count;
> }
> 
> static const struct file_operations my_fops = {
> 

Re: [beagleboard] Custom board base on beaglebone black without HDMI ... problems

[John Syne]

https://github.com/RobertCNelson/u-boot/blob/master/board/ti/common/board_detect.h
 


Regards,
John




> On Apr 19, 2016, at 9:38 PM, masoud hajian  wrote:
> 
> Dear John,
> 
> Thank you for your help. Mostly all of my board problems has been solved 
> except EEPROM. what is EEPROM role in the board? In my custom board I used 
> EEPROM that i desolderd from beaglebone black orginal board and every thing 
> goes well but I want to know for a blank EEPROM what should I do?
> 
> Regards,
> Masoud
> 
> On Tuesday, April 19, 2016 at 12:52:51 PM UTC+4:30, john3909 wrote:
> https://eewiki.net/display/linuxonarm/BeagleBone+Black 
> 
> 
> Regards,
> John
> 
> 
> 
> 
> On Apr 19, 2016, at 12:07 AM, masoud hajian  > wrote:
> 
> thanks for your answer.I could not disable HDMI, because I did not find any 
> file by name of uEnv.txt. I partitioned my uSD card in two part, BOOT and 
> rootfs then I compiled kernel and copied zImage, u-boot.img, dtb to BOOT 
> partition and file system to rootfs partition then boot system by uSD. then I 
> copied uSD to eMMC by "dd" command. there is no uENV.txt. Please tell me 
> where i can find it or any alternative way to disable HDMI.
> 
> Do you have 4.1 kernel link which it compatible by BBB?
> 
> Regards,
> Masoud
> 
> On Tuesday, April 19, 2016 at 9:52:23 AM UTC+4:30, john3909 wrote:
> Is there a reason you are using the 3.8 kernel? Also, are you sure you have 
> disabled HDMI because I see tda998x errors which are related to HDMI. Also, 
> it looks like there is a disk problem, because after the disk is mounted, and 
> attempts to run INIT, it looks like an illegal memory access which is causing 
> the segfault. I would suggest starting with a new 4.1 SDCard image and get a 
> working system before attempting any changes.  
> 
> Regards,
> John
> 
> 
> 
> 
> On Apr 18, 2016, at 9:52 PM, masoud hajian > wrote:
> 
> Dear John,
> 
> Thanks for your answers, I faced another problems. Generally, the board does 
> not work properly, some times it boots properly, another time it stops when 
> udev comes to do some thing, but the time it boot properly, there is no 
> problem at all.
> Please see the log,
> 
> BR,
>  Masoud
> 
>   
>   
> Starting kernel ...   
>   
>   
>   
> Uncompressing Linux... done, booting the kernel.  
>   
> [0.00] Booting Linux on physical CPU 0x0  
>   
> [0.00] Initializing cgroup subsys cpu 
>   
> [0.00] Linux version 3.8.13-00770-g25ad6c6c 
> (masoud@masoud-System-Product-Name) (gcc version 4.7.3 (Ubuntu/Linaro 
> 4.7.3-12u5
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
> cr=50c5387d  
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache 
> [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI 
> AM335x BeagleBone
> [0.00] bootconsole [earlycon0] enabled
>   
> [0.00] Memory policy: ECC disabled, Data cache writeback  
>   
> [0.00] AM335X ES1.0 (neon )   
>   
> [0.00] PERCPU: Embedded 8 pages/cpu @c0b66000 s9408 r8192 d15168 
> u32768 
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 129792  
> [0.00] Kernel command line: console=ttyO0 earlyprintk 
> root=/dev/mmcblk0p2 rw
> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
>   
> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 
> bytes)  
> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) 
>  

Re: [beagleboard] Custom board base on beaglebone black without HDMI ... problems

[John Syne]

https://github.com/beagleboard/image-builder/blob/master/readme.md 


Regards,
John




> On Apr 19, 2016, at 9:38 PM, masoud hajian  wrote:
> 
> Dear John,
> 
> Thank you for your help. Mostly all of my board problems has been solved 
> except EEPROM. what is EEPROM role in the board? In my custom board I used 
> EEPROM that i desolderd from beaglebone black orginal board and every thing 
> goes well but I want to know for a blank EEPROM what should I do?
> 
> Regards,
> Masoud
> 
> On Tuesday, April 19, 2016 at 12:52:51 PM UTC+4:30, john3909 wrote:
> https://eewiki.net/display/linuxonarm/BeagleBone+Black 
> 
> 
> Regards,
> John
> 
> 
> 
> 
> On Apr 19, 2016, at 12:07 AM, masoud hajian  > wrote:
> 
> thanks for your answer.I could not disable HDMI, because I did not find any 
> file by name of uEnv.txt. I partitioned my uSD card in two part, BOOT and 
> rootfs then I compiled kernel and copied zImage, u-boot.img, dtb to BOOT 
> partition and file system to rootfs partition then boot system by uSD. then I 
> copied uSD to eMMC by "dd" command. there is no uENV.txt. Please tell me 
> where i can find it or any alternative way to disable HDMI.
> 
> Do you have 4.1 kernel link which it compatible by BBB?
> 
> Regards,
> Masoud
> 
> On Tuesday, April 19, 2016 at 9:52:23 AM UTC+4:30, john3909 wrote:
> Is there a reason you are using the 3.8 kernel? Also, are you sure you have 
> disabled HDMI because I see tda998x errors which are related to HDMI. Also, 
> it looks like there is a disk problem, because after the disk is mounted, and 
> attempts to run INIT, it looks like an illegal memory access which is causing 
> the segfault. I would suggest starting with a new 4.1 SDCard image and get a 
> working system before attempting any changes.  
> 
> Regards,
> John
> 
> 
> 
> 
> On Apr 18, 2016, at 9:52 PM, masoud hajian > wrote:
> 
> Dear John,
> 
> Thanks for your answers, I faced another problems. Generally, the board does 
> not work properly, some times it boots properly, another time it stops when 
> udev comes to do some thing, but the time it boot properly, there is no 
> problem at all.
> Please see the log,
> 
> BR,
>  Masoud
> 
>   
>   
> Starting kernel ...   
>   
>   
>   
> Uncompressing Linux... done, booting the kernel.  
>   
> [0.00] Booting Linux on physical CPU 0x0  
>   
> [0.00] Initializing cgroup subsys cpu 
>   
> [0.00] Linux version 3.8.13-00770-g25ad6c6c 
> (masoud@masoud-System-Product-Name) (gcc version 4.7.3 (Ubuntu/Linaro 
> 4.7.3-12u5
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
> cr=50c5387d  
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache 
> [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI 
> AM335x BeagleBone
> [0.00] bootconsole [earlycon0] enabled
>   
> [0.00] Memory policy: ECC disabled, Data cache writeback  
>   
> [0.00] AM335X ES1.0 (neon )   
>   
> [0.00] PERCPU: Embedded 8 pages/cpu @c0b66000 s9408 r8192 d15168 
> u32768 
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 129792  
> [0.00] Kernel command line: console=ttyO0 earlyprintk 
> root=/dev/mmcblk0p2 rw
> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
>   
> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 
> bytes)  
> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) 
>   
> [

Re: [beagleboard] BBB Battery shutdown

[John Syne]

  return -1;
}
sprintf(buf, "%i", getpid());
if (write(configfd, buf, strlen(buf) + 1) < 0) {
perror("fwrite");
return -1;
}

return 0;
}
===
> 
> Lastly, when I say "really easily" I mean that I know it is possible and I 
> know how to go about doing it. I'd just have to research many things to bring 
> it all together. So would also take me a little while. Maybe a week, maybe 
> two. Assuming I had the time.
> 
> On Tue, Apr 19, 2016 at 8:51 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> Here is the problem with that. You use a different kernel to me and you don’t 
> like to use systemd. Hence I will explain how to get this working, but you 
> are going to have to do the coding and testing. To start with, which kernel 
> are you using?
> 
> From the TPS65217 datasheet the ACI bit in the INT register (0x02) will be a 
> 1 if the power status changed (either power on or power fail). The state of 
> the power is in the status register (0xA) which is 0 for no power and 1 for 
> power in valid range. So looking at the Interrupt routing, both events are 
> reported. I would recommend changing the input key to something different to 
> KEY_POWER because we do not want to modify the pwr button behavior. 
> 
> 
> if (int_reg & TPS65217_INT_ACI) {
>   /* Handle AC power status change */
>   dev_dbg(tps->dev, "AC power status change\n");
>   /* Press KEY_POWER when AC not present */
>   input_report_key(tps->pwr_but, KEY_POWER,
>   ~status_reg & TPS65217_STATUS_ACPWR);
>   input_sync(tps->pwr_but);
> }
> 
> You might have to change input_report_key to input_report_switch as I’m not 
> sure if we can extract the status from EV_KEY.
> Using udev, the input key is linked to this systemd service poweroff.target
> 
> ===
> #  This file is part of systemd.
> #
> #  systemd is free software; you can redistribute it and/or modify it
> #  under the terms of the GNU Lesser General Public License as published by
> #  the Free Software Foundation; either version 2.1 of the License, or
> #  (at your option) any later version.
> 
> [Unit]
> Description=Power-Off
> Documentation=man:systemd.special(7)
> DefaultDependencies=no
> Requires=systemd-poweroff.service
> After=systemd-poweroff.service
> AllowIsolate=yes
> 
> [Install]
> Alias=ctrl-alt-del.target
> ===
> 
> Which in turn runs the systemd-poweroff.service
> 
> ===
> #  This file is part of systemd.
> #
> #  systemd is free software; you can redistribute it and/or modify it
> #  under the terms of the GNU Lesser General Public License as published by
> #  the Free Software Foundation; either version 2.1 of the License, or
> #  (at your option) any later version.
> 
> [Unit]
> Description=Power-Off
> Documentation=man:systemd-halt.service(8)
> DefaultDependencies=no
> Requires=shutdown.target umount.target final.target
> After=shutdown.target umount.target final.target
> 
> [Service]
> Type=oneshot
> ExecStart=/bin/systemctl --force poweroff
> ===
> 
> Which powers down the board.
> 
> So here is what you need to do. When you receive a input key assigned to 
> AC_Power, with a status of fail, start a daemon with a timer. If the timer 
> expires, do the same systemctl poweroff or shutdown -h now. If you get a 
> input key for AC_Power with status of power_good before the timer expires, 
> either kill the daemon or cancel the timer. 
> 
> Hope this helps.
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 19, 2016, at 6:29 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> 
>> Good, now add it.
>> 
>> On Tue, Apr 19, 2016 at 5:16 PM, John Syne <john3...@gmail.com 
>> <mailto:john3...@gmail.com>> wrote:
>> In my last e-mail on this issue, I said "Also, the interrupt routine does 
>> not report power good, so that would have to be added”. It is a simple thing 
>> to add.
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 19, 2016, at 3:30 PM, William Hermans <yyrk...@gmail.com 
>>> <mailto:yyrk...@gmail.com>> wrote:
>>> 
>>> So there is apparently a bug related to this whole situation. Once the 
>>> input power goes away, whatever it may be. You lose USB, because the PMIC 
>>> is not longer able to supply 5V. You even get a kernel message in relation 
>>> to this from musb.
>>> 
>>> The problem is, once input power is restored, I see no indication that

Re: [beagleboard] BBB Battery shutdown

[John Syne]

Here is the problem with that. You use a different kernel to me and you don’t 
like to use systemd. Hence I will explain how to get this working, but you are 
going to have to do the coding and testing. To start with, which kernel are you 
using?

>From the TPS65217 datasheet the ACI bit in the INT register (0x02) will be a 1 
>if the power status changed (either power on or power fail). The state of the 
>power is in the status register (0xA) which is 0 for no power and 1 for power 
>in valid range. So looking at the Interrupt routing, both events are reported. 
>I would recommend changing the input key to something different to KEY_POWER 
>because we do not want to modify the pwr button behavior. 


if (int_reg & TPS65217_INT_ACI) {
/* Handle AC power status change */
dev_dbg(tps->dev, "AC power status change\n");
/* Press KEY_POWER when AC not present */
input_report_key(tps->pwr_but, KEY_POWER,
~status_reg & TPS65217_STATUS_ACPWR);
input_sync(tps->pwr_but);
}

You might have to change input_report_key to input_report_switch as I’m not 
sure if we can extract the status from EV_KEY.
Using udev, the input key is linked to this systemd service poweroff.target

===
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Power-Off
Documentation=man:systemd.special(7)
DefaultDependencies=no
Requires=systemd-poweroff.service
After=systemd-poweroff.service
AllowIsolate=yes

[Install]
Alias=ctrl-alt-del.target
===

Which in turn runs the systemd-poweroff.service

===
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Power-Off
Documentation=man:systemd-halt.service(8)
DefaultDependencies=no
Requires=shutdown.target umount.target final.target
After=shutdown.target umount.target final.target

[Service]
Type=oneshot
ExecStart=/bin/systemctl --force poweroff
===

Which powers down the board.

So here is what you need to do. When you receive a input key assigned to 
AC_Power, with a status of fail, start a daemon with a timer. If the timer 
expires, do the same systemctl poweroff or shutdown -h now. If you get a input 
key for AC_Power with status of power_good before the timer expires, either 
kill the daemon or cancel the timer. 

Hope this helps.

Regards,
John




> On Apr 19, 2016, at 6:29 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> Good, now add it.
> 
> On Tue, Apr 19, 2016 at 5:16 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> In my last e-mail on this issue, I said "Also, the interrupt routine does not 
> report power good, so that would have to be added”. It is a simple thing to 
> add.
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 19, 2016, at 3:30 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> 
>> So there is apparently a bug related to this whole situation. Once the input 
>> power goes away, whatever it may be. You lose USB, because the PMIC is not 
>> longer able to supply 5V. You even get a kernel message in relation to this 
>> from musb.
>> 
>> The problem is, once input power is restored, I see no indication that 5V is 
>> restored to USB. So If you tail -f /var/log/messages, you'll see one musb 
>> message when pulling power, but you will not see a corresponding message 
>> when plugging power back in. Additionally if you pull power multiple times. 
>> Only the first message is displayed. 
>> 
>> What this tells me is that the current kernel modules are not written to 
>> deal / handle this yet. So for now, unless I'm wrong ( which i doubt ). It's 
>> best just to power down period. After input power goes away, and simply use 
>> an R/C network to "time" system up's, in case power goes up / down rapidly. 
>> One, or more times consecutively. 
>> 
>> On Mon, Apr 18, 2016 at 6:26 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> I have an interest in this.  It's way above my pay grade from a programming 
>> perspective...
>> 
>> Mike
>> 
>> Hi Mike,
>> 
>> This is actually something I'm personally very interested in too. However, 
>> at this moment in time, my buddy and I are actually in the proces

Re: [beagleboard] BBB Battery shutdown

[John Syne]

In my last e-mail on this issue, I said "Also, the interrupt routine does not 
report power good, so that would have to be added”. It is a simple thing to add.

Regards,
John




> On Apr 19, 2016, at 3:30 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> So there is apparently a bug related to this whole situation. Once the input 
> power goes away, whatever it may be. You lose USB, because the PMIC is not 
> longer able to supply 5V. You even get a kernel message in relation to this 
> from musb.
> 
> The problem is, once input power is restored, I see no indication that 5V is 
> restored to USB. So If you tail -f /var/log/messages, you'll see one musb 
> message when pulling power, but you will not see a corresponding message when 
> plugging power back in. Additionally if you pull power multiple times. Only 
> the first message is displayed. 
> 
> What this tells me is that the current kernel modules are not written to deal 
> / handle this yet. So for now, unless I'm wrong ( which i doubt ). It's best 
> just to power down period. After input power goes away, and simply use an R/C 
> network to "time" system up's, in case power goes up / down rapidly. One, or 
> more times consecutively. 
> 
> On Mon, Apr 18, 2016 at 6:26 PM, William Hermans <yyrk...@gmail.com 
> <mailto:yyrk...@gmail.com>> wrote:
> I have an interest in this.  It's way above my pay grade from a programming 
> perspective...
> 
> Mike
> 
> Hi Mike,
> 
> This is actually something I'm personally very interested in too. However, at 
> this moment in time, my buddy and I are actually in the process of making two 
> different capes for the beaglebone. So this is one of those situations where 
> you have to have priorities . . . and while I obviously do not know 
> everything involved to get this certain thing done, it is not above my pay 
> grade. 
> 
> So perhaps in the future, it may be something I'll revisit, and would be 
> something I'd contribute back to the community.
> 
> On Mon, Apr 18, 2016 at 2:26 PM, Mike <bellyac...@gmail.com 
> <mailto:bellyac...@gmail.com>> wrote:
> On 04/18/2016 03:31 PM, John Syne wrote:
>> That is OK if this doesn’t work for you, but there are other BBB users who 
>> might find this helpful. Currently the powerfail uses the same key function 
>> as the pwr button, so the first place to start would be changing the key 
>> function to something else. Also, the interrupt routine does not report 
>> power good, so that would have to be added. After that, a systemd service 
>> could take care of the rest. 
>> 
>> Regards,
>> John
>> 
>> 
> 
> I have an interest in this.  It's way above my pay grade from a programming 
> perspective...
> 
> Mike
> 
>> 
>> 
>>> On Apr 18, 2016, at 11:31 AM, William Hermans <yyrk...@gmail.com 
>>> <mailto:yyrk...@gmail.com>> wrote:
>>> 
>>> #1 
>>> william@beaglebone:~$ ls /etc/udev/rules.d/
>>> 50-hidraw.rules  50-spi.rules  60-omap-tty.rules  70-persistent-net.rules  
>>> uio.rules
>>> 
>>> #2
>>> We do not care about the button press. We *did* care about what happens 
>>> when power is removed, while a battery is connected.
>>> 
>>> Now we do not care. We're not going to bother with it. It's too much hassle 
>>> for a result that is not really all that important. So what if the power 
>>> down routine is inefficient . . . it works.
>>> 
>>> On Mon, Apr 18, 2016 at 10:29 AM, John Syne < 
>>> <mailto:john3...@gmail.com>john3...@gmail.com <mailto:john3...@gmail.com>> 
>>> wrote:
>>> I asked Robert how the pwr button is processed and interestingly it is done 
>>> via udev and systemd. Also, there is some new code going mainstream for the 
>>> pwr button and battery charger. Perhaps you can implement the timer delay 
>>> via a custom systemd service. Here is what Robert sent me:
>>> 
>>> Oh this is finally getting upstreamed:
>>> 
>>> https://www.spinics.net/lists/linux-omap/msg127184.html 
>>> <https://www.spinics.net/lists/linux-omap/msg127184.html>
>>> 
>>> I need to switch to their version, vs our 3.8.13 erra hack that's been 
>>> forward ported for years. ;)
>>> 
>>> Behind the scenes's that patch is reporting a key-event to systemd...
>>> 
>>> https://github.com/systemd/systemd/blob/09541e49ebd17b41482e447dd8194942f39788c0/src/login/70-power-switch.rules#L13
>>>  
>>> <https://github.com/systemd/systemd/blob/09541e49ebd17b41482

Re: [beagleboard] am33xx-overlay-edma-fix.dtsi causes problems with mcasp

[John Syne]

> On Apr 19, 2016, at 3:44 AM, Rick Mann <rm...@latencyzero.com> wrote:
> 
>> 
>> On Apr 19, 2016, at 03:29 , John Syne <john3...@gmail.com> wrote:
>> 
>> It was part of this discussion in which you participated. 
>> 
>> https://groups.google.com/forum/#!msg/beagleboard/TMGEWjBLsok/ALk4h_jrCwAJ
> 
> Ooof, months ago. I can barely remember what I did last week. ;-)
> 
> In any case, I didn't put it together back then. This is the first time I've 
> gotten a 4+ kernel to do everything I need (e.g. pruss, adc, and audio). It's 
> still not all quite there, but I'm much farther along than I was. I may have 
> also missed the follow-on posts on that thread.
> 
> In any case, it doesn't seem to allow audio to be overlayed when enabled in 
> the boot DTB.
> 
>> Robert spoke about this on Jan 12, 2016:
>> 
>> it's a big workaround hack, the bug seems to be in edma_probe:
>> 
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/dma/edma.c#n2118
>> 
>> On first load of the board *.dtb, edma_probe is called and all the 'active' 
>> nodes get an edma slot, while the in-active nodes get disabled.. (power 
>> savings? for am335x, every ip has it's own edma channel, but maybe some 
>> parts need sharing?)
>> 
>> So, next when we load an overlay, for uart0, uart1, uart2, spi0, spi1, 
>> mcasp0, and mcasp1 the edma channel would be disabled, (they still load, but 
>> every transfer fails when it switches from pio-dma spi=160 bytes) as we 
>> don't re-call edma_probe to enable them*..
>> 
>> * that seems like the better fix.
> 
> I think I understand what's going on. However, I'm not seeing the result of 
> failed transfers. Audio actually works for me now.
> 
> In any case, for my primary application, I can make a single comprehensive 
> DTB to load at boot, so I should be able to get edma and audio, right? I'll 
> try this after I sleep and wake up.
> 
> Also, those discussions were for 4.1.x. Does all that still hold true for 
> 4.4.x?
My guess if Robert still has the workarround applied, then it applies to 4.4.x 
as well. Best to ask Robert about this. 

Regards,
John
> 
> Thanks,
> Rick
> 
> 
> 
>> 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 19, 2016, at 2:41 AM, Rick Mann <rm...@latencyzero.com> wrote:
>>> 
>>> The following .dtsi file:
>>> 
>>> 
>>> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-overlay-edma-fix.dtsi
>>> 
>>> causes the mcasp davinci audio driver to load during boot,
>>> and prevents overlays (like BB-BONE-AUDI-02) from setting
>>> audio parameters. The result is hardware configuration errors
>>> when trying to use ALSA commands:
>>> 
>>>> Unable to set hw params for playback: Invalid argument
>>>> Setting of hwparams failed: Invalid argument
>>> 
>>> That .dtsi file enables spi0/1, and mcasp0/1. By removing
>>> the mcasp0/1 entries, the BB-BONE-AUDI-02 overlay is able
>>> to enable mcasp while configuring it properly, and allowing
>>> the driver to work.
>>> 
>>> It's not clear to me how that file is an eDMA fix, nor why
>>> it enables mcasp.
>>> 
>>> Here's the thread on the alsa-devel list where we figured it
>>> out:
>>> 
>>> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-April/107061.html
>>> 
>>> Is the best way to report this problem here on the list like
>>> this, or to open an issue on github/dtb-rebuilder?
>>> 
>>> Note that this is all with kernel 4.4.7-bone-rt-r9. Not sure
>>> to how many other versions it applies.
>>> 
>>> 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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/77DEEFDD-F2AC-494B-A8AC-6BC54F19EEC3%40latencyzero.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 

Re: [beagleboard] am33xx-overlay-edma-fix.dtsi causes problems with mcasp

[John Syne]

It was part of this discussion in which you participated. 

https://groups.google.com/forum/#!msg/beagleboard/TMGEWjBLsok/ALk4h_jrCwAJ


Regards,
John




> On Apr 19, 2016, at 2:41 AM, Rick Mann  wrote:
> 
> The following .dtsi file:
> 
>   
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-overlay-edma-fix.dtsi
> 
> causes the mcasp davinci audio driver to load during boot,
> and prevents overlays (like BB-BONE-AUDI-02) from setting
> audio parameters. The result is hardware configuration errors
> when trying to use ALSA commands:
> 
>> Unable to set hw params for playback: Invalid argument
>> Setting of hwparams failed: Invalid argument
> 
> That .dtsi file enables spi0/1, and mcasp0/1. By removing
> the mcasp0/1 entries, the BB-BONE-AUDI-02 overlay is able
> to enable mcasp while configuring it properly, and allowing
> the driver to work.
> 
> It's not clear to me how that file is an eDMA fix, nor why
> it enables mcasp.
> 
> Here's the thread on the alsa-devel list where we figured it
> out:
> 
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-April/107061.html
> 
> Is the best way to report this problem here on the list like
> this, or to open an issue on github/dtb-rebuilder?
> 
> Note that this is all with kernel 4.4.7-bone-rt-r9. Not sure
> to how many other versions it applies.
> 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/77DEEFDD-F2AC-494B-A8AC-6BC54F19EEC3%40latencyzero.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/55916E28-05ED-4C01-89A5-5C6D30741FA9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] am33xx-overlay-edma-fix.dtsi causes problems with mcasp

[John Syne]

Robert spoke about this on Jan 12, 2016:

it's a big workaround hack, the bug seems to be in edma_probe:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/dma/edma.c#n2118

On first load of the board *.dtb, edma_probe is called and all the 'active' 
nodes get an edma slot, while the in-active nodes get disabled.. (power 
savings? for am335x, every ip has it's own edma channel, but maybe some parts 
need sharing?)

So, next when we load an overlay, for uart0, uart1, uart2, spi0, spi1, mcasp0, 
and mcasp1 the edma channel would be disabled, (they still load, but every 
transfer fails when it switches from pio-dma spi=160 bytes) as we don't re-call 
edma_probe to enable them*..

* that seems like the better fix.

Regards,
John




> On Apr 19, 2016, at 2:41 AM, Rick Mann  wrote:
> 
> The following .dtsi file:
> 
>   
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-overlay-edma-fix.dtsi
> 
> causes the mcasp davinci audio driver to load during boot,
> and prevents overlays (like BB-BONE-AUDI-02) from setting
> audio parameters. The result is hardware configuration errors
> when trying to use ALSA commands:
> 
>> Unable to set hw params for playback: Invalid argument
>> Setting of hwparams failed: Invalid argument
> 
> That .dtsi file enables spi0/1, and mcasp0/1. By removing
> the mcasp0/1 entries, the BB-BONE-AUDI-02 overlay is able
> to enable mcasp while configuring it properly, and allowing
> the driver to work.
> 
> It's not clear to me how that file is an eDMA fix, nor why
> it enables mcasp.
> 
> Here's the thread on the alsa-devel list where we figured it
> out:
> 
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-April/107061.html
> 
> Is the best way to report this problem here on the list like
> this, or to open an issue on github/dtb-rebuilder?
> 
> Note that this is all with kernel 4.4.7-bone-rt-r9. Not sure
> to how many other versions it applies.
> 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/77DEEFDD-F2AC-494B-A8AC-6BC54F19EEC3%40latencyzero.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/517CD07F-BAB9-4049-9537-8CF88548D592%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Skipping config menu with ./tools/rebuild.sh?

[John Syne]

or 

>export AUTO_BUILD=1

Regards,
John




> On Apr 19, 2016, at 12:44 AM, Rick Mann  wrote:
> 
> Hi Robert,
> 
> Is there any way to skip the configuration menu that
> comes up when I invoke ./tools/rebuild.sh, or
> ./build_kernel.sh?
> 
> TIA,
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/B3BCA94B-537F-4D50-B4F7-3B8C97ED15D6%40latencyzero.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/349382B1-0C4E-4838-8588-B3D8BFE0E09E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Skipping config menu with ./tools/rebuild.sh?

[John Syne]

>set AUTO_BUILD=1

Regards,
John




> On Apr 19, 2016, at 12:44 AM, Rick Mann  wrote:
> 
> Hi Robert,
> 
> Is there any way to skip the configuration menu that
> comes up when I invoke ./tools/rebuild.sh, or
> ./build_kernel.sh?
> 
> TIA,
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/B3BCA94B-537F-4D50-B4F7-3B8C97ED15D6%40latencyzero.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/F12B60A0-0165-42FD-A584-A05571EBC6A1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Custom board base on beaglebone black without HDMI ... problems

[John Syne]

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


Regards,
John




> On Apr 19, 2016, at 12:07 AM, masoud hajian  wrote:
> 
> thanks for your answer.I could not disable HDMI, because I did not find any 
> file by name of uEnv.txt. I partitioned my uSD card in two part, BOOT and 
> rootfs then I compiled kernel and copied zImage, u-boot.img, dtb to BOOT 
> partition and file system to rootfs partition then boot system by uSD. then I 
> copied uSD to eMMC by "dd" command. there is no uENV.txt. Please tell me 
> where i can find it or any alternative way to disable HDMI.
> 
> Do you have 4.1 kernel link which it compatible by BBB?
> 
> Regards,
> Masoud
> 
> On Tuesday, April 19, 2016 at 9:52:23 AM UTC+4:30, john3909 wrote:
> Is there a reason you are using the 3.8 kernel? Also, are you sure you have 
> disabled HDMI because I see tda998x errors which are related to HDMI. Also, 
> it looks like there is a disk problem, because after the disk is mounted, and 
> attempts to run INIT, it looks like an illegal memory access which is causing 
> the segfault. I would suggest starting with a new 4.1 SDCard image and get a 
> working system before attempting any changes.  
> 
> Regards,
> John
> 
> 
> 
> 
> On Apr 18, 2016, at 9:52 PM, masoud hajian  > wrote:
> 
> Dear John,
> 
> Thanks for your answers, I faced another problems. Generally, the board does 
> not work properly, some times it boots properly, another time it stops when 
> udev comes to do some thing, but the time it boot properly, there is no 
> problem at all.
> Please see the log,
> 
> BR,
>  Masoud
> 
>   
>   
> Starting kernel ...   
>   
>   
>   
> Uncompressing Linux... done, booting the kernel.  
>   
> [0.00] Booting Linux on physical CPU 0x0  
>   
> [0.00] Initializing cgroup subsys cpu 
>   
> [0.00] Linux version 3.8.13-00770-g25ad6c6c 
> (masoud@masoud-System-Product-Name) (gcc version 4.7.3 (Ubuntu/Linaro 
> 4.7.3-12u5
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
> cr=50c5387d  
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache 
> [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI 
> AM335x BeagleBone 
> [0.00] bootconsole [earlycon0] enabled
>   
> [0.00] Memory policy: ECC disabled, Data cache writeback  
>   
> [0.00] AM335X ES1.0 (neon )   
>   
> [0.00] PERCPU: Embedded 8 pages/cpu @c0b66000 s9408 r8192 d15168 
> u32768 
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 129792  
> [0.00] Kernel command line: console=ttyO0 earlyprintk 
> root=/dev/mmcblk0p2 rw
> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
>   
> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 
> bytes)  
> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) 
>   
> [0.00] __ex_table already sorted, skipping sort   
>   
> [0.00] allocated 1048576 bytes of page_cgroup 
>   
> [0.00] please try 'cgroup_disable=memory' option if you don't want 
> memory cgroups   
> [0.00] Memory: 511MB = 511MB total
>   
> [0.00] Memory: 510108k/510108k available, 14180k reserved, 0K highmem 
>   

Re: [beagleboard] BBB Battery shutdown

[John Syne]

That is OK if this doesn’t work for you, but there are other BBB users who 
might find this helpful. Currently the powerfail uses the same key function as 
the pwr button, so the first place to start would be changing the key function 
to something else. Also, the interrupt routine does not report power good, so 
that would have to be added. After that, a systemd service could take care of 
the rest. 

Regards,
John




> On Apr 18, 2016, at 11:31 AM, William Hermans <yyrk...@gmail.com> wrote:
> 
> #1 
> william@beaglebone:~$ ls /etc/udev/rules.d/
> 50-hidraw.rules  50-spi.rules  60-omap-tty.rules  70-persistent-net.rules  
> uio.rules
> 
> #2
> We do not care about the button press. We *did* care about what happens when 
> power is removed, while a battery is connected.
> 
> Now we do not care. We're not going to bother with it. It's too much hassle 
> for a result that is not really all that important. So what if the power down 
> routine is inefficient . . . it works.
> 
> On Mon, Apr 18, 2016 at 10:29 AM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> I asked Robert how the pwr button is processed and interestingly it is done 
> via udev and systemd. Also, there is some new code going mainstream for the 
> pwr button and battery charger. Perhaps you can implement the timer delay via 
> a custom systemd service. Here is what Robert sent me:
> 
> Oh this is finally getting upstreamed:
> 
> https://www.spinics.net/lists/linux-omap/msg127184.html 
> <https://www.spinics.net/lists/linux-omap/msg127184.html>
> 
> I need to switch to their version, vs our 3.8.13 erra hack that's been 
> forward ported for years. ;)
> 
> Behind the scenes's that patch is reporting a key-event to systemd...
> 
> https://github.com/systemd/systemd/blob/09541e49ebd17b41482e447dd8194942f39788c0/src/login/70-power-switch.rules#L13
>  
> <https://github.com/systemd/systemd/blob/09541e49ebd17b41482e447dd8194942f39788c0/src/login/70-power-switch.rules#L13>
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 17, 2016, at 11:06 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> 
>> There is no timer in that code. The timer would have to be added, and 
>> careful consideration would have to be given to exactly how that was 
>> implemented.
>> 
>> So in other words, you would, or should write a completely new kernel 
>> module, that is meant to replace what already exists - As an option.
>> 
>> On Sun, Apr 17, 2016 at 10:25 PM, evilwulfie <evilwul...@gmail.com 
>> <mailto:evilwul...@gmail.com>> wrote:
>> Where in the code do you set that timer ?
>> 
>> 
>> 
>> On 4/17/2016 7:50 PM, John Syne wrote:
>>> One more thing, the power down sequence uses the RTC framework (described 
>>> earlier in this thread), so it will be possible to set a timer for the 
>>> shutdown and the wait for the power to return event to cancel the timer. If 
>>> the power on event does not occur, the shutdown will occur.
>>> 
>>> Regards,
>>> John
>>> 
>>> 
>>> 
>>> 
>>>> On Apr 17, 2016, at 7:18 PM, evilwulfie < 
>>>> <mailto:evilwul...@gmail.com>evilwul...@gmail.com 
>>>> <mailto:evilwul...@gmail.com>> wrote:
>>>> 
>>>> Interesting.  Too bad if you want the battery to act as a UPS it cant some 
>>>> how notify the kernel that AC has been removed
>>>> and have a routine to just chill a while to see if power comes back.
>>>> 
>>>> Be nice to have a variable that is user settable for the time between loss 
>>>> of AC and shutdown.
>>>> 
>>>> As it is now it sees the AC removed, shuts down and no easy way to restart 
>>>> on power restored. Requiring some other IC to monitor power 
>>>> and then press the pwr_but to restart the processor.
>>>> 
>>>> 
>>>> 
>>>> On 4/17/2016 7:10 PM, John Syne wrote:
>>>>> Yep, it is in the BB kernel:
>>>>> 
>>>>> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch
>>>>>  
>>>>> <https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch>
>>>>> 
>>>>> So again, on line 164 is the Interrupt routing. It is this line:
>>>>> 
>>>>> + input_report_key(tps->pwr_but, KEY_

Re: [beagleboard] BBB Battery shutdown

[John Syne]

I asked Robert how the pwr button is processed and interestingly it is done via 
udev and systemd. Also, there is some new code going mainstream for the pwr 
button and battery charger. Perhaps you can implement the timer delay via a 
custom systemd service. Here is what Robert sent me:

Oh this is finally getting upstreamed:

https://www.spinics.net/lists/linux-omap/msg127184.html 
<https://www.spinics.net/lists/linux-omap/msg127184.html>

I need to switch to their version, vs our 3.8.13 erra hack that's been forward 
ported for years. ;)

Behind the scenes's that patch is reporting a key-event to systemd...

https://github.com/systemd/systemd/blob/09541e49ebd17b41482e447dd8194942f39788c0/src/login/70-power-switch.rules#L13
 
<https://github.com/systemd/systemd/blob/09541e49ebd17b41482e447dd8194942f39788c0/src/login/70-power-switch.rules#L13>

Regards,
John




> On Apr 17, 2016, at 11:06 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> There is no timer in that code. The timer would have to be added, and careful 
> consideration would have to be given to exactly how that was implemented.
> 
> So in other words, you would, or should write a completely new kernel module, 
> that is meant to replace what already exists - As an option.
> 
> On Sun, Apr 17, 2016 at 10:25 PM, evilwulfie <evilwul...@gmail.com 
> <mailto:evilwul...@gmail.com>> wrote:
> Where in the code do you set that timer ?
> 
> 
> 
> On 4/17/2016 7:50 PM, John Syne wrote:
>> One more thing, the power down sequence uses the RTC framework (described 
>> earlier in this thread), so it will be possible to set a timer for the 
>> shutdown and the wait for the power to return event to cancel the timer. If 
>> the power on event does not occur, the shutdown will occur.
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 17, 2016, at 7:18 PM, evilwulfie < 
>>> <mailto:evilwul...@gmail.com>evilwul...@gmail.com 
>>> <mailto:evilwul...@gmail.com>> wrote:
>>> 
>>> Interesting.  Too bad if you want the battery to act as a UPS it cant some 
>>> how notify the kernel that AC has been removed
>>> and have a routine to just chill a while to see if power comes back.
>>> 
>>> Be nice to have a variable that is user settable for the time between loss 
>>> of AC and shutdown.
>>> 
>>> As it is now it sees the AC removed, shuts down and no easy way to restart 
>>> on power restored. Requiring some other IC to monitor power 
>>> and then press the pwr_but to restart the processor.
>>> 
>>> 
>>> 
>>> On 4/17/2016 7:10 PM, John Syne wrote:
>>>> Yep, it is in the BB kernel:
>>>> 
>>>> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch
>>>>  
>>>> <https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch>
>>>> 
>>>> So again, on line 164 is the Interrupt routing. It is this line:
>>>> 
>>>> +  input_report_key(tps->pwr_but, KEY_POWER,
>>>> 
>>>> +  ~status_reg & TPS65217_STATUS_ACPWR);
>>>> that send a power button pressed as an input key when the AC 5V power is 
>>>> removed. 
>>>> 
>>>> Regards,
>>>> John
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Apr 17, 2016, at 4:52 PM, William Hermans <yyrk...@gmail.com 
>>>>> <mailto:yyrk...@gmail.com>> wrote:
>>>>> 
>>>>> The real reason why our source trees do not match up. My source tree is 
>>>>> based on 4.1.x, and yours seems to be 3.8.x. The patch you showed above 
>>>>> would probably botch up my source tree . . .
>>>>> 
>>>>> On Sun, Apr 17, 2016 at 4:33 PM, William Hermans < 
>>>>> <mailto:yyrk...@gmail.com>yyrk...@gmail.com <mailto:yyrk...@gmail.com>> 
>>>>> wrote:
>>>>> Yeah I recognize that code from source code not written by TI employees. 
>>>>> The file is called tps65217_charger.c, and is written by an employee of 
>>>>> another company.
>>>>> 
>>>>> Anyway, I think we're going to blow this off. The idea was to wait around 
>>>>> without power for 5 minutes, to see if power comes back up. Before 
>>>>> issuing a shutdown. Then, on the power up end, using a simple 

Re: [beagleboard] BBB Battery shutdown

[John Syne]

The way I read this is all you have to do is set ALARM2 when the AC line fails. 
If there is no ALARM2, it switches off 15uS later. 

Regards,
John




> On Apr 17, 2016, at 11:06 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> There is no timer in that code. The timer would have to be added, and careful 
> consideration would have to be given to exactly how that was implemented.
> 
> So in other words, you would, or should write a completely new kernel module, 
> that is meant to replace what already exists - As an option.
> 
> On Sun, Apr 17, 2016 at 10:25 PM, evilwulfie <evilwul...@gmail.com 
> <mailto:evilwul...@gmail.com>> wrote:
> Where in the code do you set that timer ?
> 
> 
> 
> On 4/17/2016 7:50 PM, John Syne wrote:
>> One more thing, the power down sequence uses the RTC framework (described 
>> earlier in this thread), so it will be possible to set a timer for the 
>> shutdown and the wait for the power to return event to cancel the timer. If 
>> the power on event does not occur, the shutdown will occur.
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 17, 2016, at 7:18 PM, evilwulfie < 
>>> <mailto:evilwul...@gmail.com>evilwul...@gmail.com 
>>> <mailto:evilwul...@gmail.com>> wrote:
>>> 
>>> Interesting.  Too bad if you want the battery to act as a UPS it cant some 
>>> how notify the kernel that AC has been removed
>>> and have a routine to just chill a while to see if power comes back.
>>> 
>>> Be nice to have a variable that is user settable for the time between loss 
>>> of AC and shutdown.
>>> 
>>> As it is now it sees the AC removed, shuts down and no easy way to restart 
>>> on power restored. Requiring some other IC to monitor power 
>>> and then press the pwr_but to restart the processor.
>>> 
>>> 
>>> 
>>> On 4/17/2016 7:10 PM, John Syne wrote:
>>>> Yep, it is in the BB kernel:
>>>> 
>>>> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch
>>>>  
>>>> <https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch>
>>>> 
>>>> So again, on line 164 is the Interrupt routing. It is this line:
>>>> 
>>>> +  input_report_key(tps->pwr_but, KEY_POWER,
>>>> 
>>>> +  ~status_reg & TPS65217_STATUS_ACPWR);
>>>> that send a power button pressed as an input key when the AC 5V power is 
>>>> removed. 
>>>> 
>>>> Regards,
>>>> John
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Apr 17, 2016, at 4:52 PM, William Hermans <yyrk...@gmail.com 
>>>>> <mailto:yyrk...@gmail.com>> wrote:
>>>>> 
>>>>> The real reason why our source trees do not match up. My source tree is 
>>>>> based on 4.1.x, and yours seems to be 3.8.x. The patch you showed above 
>>>>> would probably botch up my source tree . . .
>>>>> 
>>>>> On Sun, Apr 17, 2016 at 4:33 PM, William Hermans < 
>>>>> <mailto:yyrk...@gmail.com>yyrk...@gmail.com <mailto:yyrk...@gmail.com>> 
>>>>> wrote:
>>>>> Yeah I recognize that code from source code not written by TI employees. 
>>>>> The file is called tps65217_charger.c, and is written by an employee of 
>>>>> another company.
>>>>> 
>>>>> Anyway, I think we're going to blow this off. The idea was to wait around 
>>>>> without power for 5 minutes, to see if power comes back up. Before 
>>>>> issuing a shutdown. Then, on the power up end, using a simple R/C circuit 
>>>>> to ramp up voltage to 5v over a specific time period.
>>>>> 
>>>>> 
>>> 
>>> 
>>>  
>>> <https://www.avast.com/en-us/lp-safe-emailing-2109?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=oa-2109-v2-a>
>>>   Virus-free. www.avast.com 
>>> <https://www.avast.com/en-us/lp-safe-emailing-2109?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=oa-2109-v2-a>
>>> 
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss 
>>> <http://beagleboard.org/discuss>
>>> --- 
>>> You received this messag

Re: [beagleboard] BBB Battery shutdown

[John Syne]

Look at drivers/rtc/rtc-omap.c

omap_rtc_power_off_program()

Regards,
John




> On Apr 17, 2016, at 10:25 PM, evilwulfie <evilwul...@gmail.com> wrote:
> 
> Where in the code do you set that timer ?
> 
> 
> On 4/17/2016 7:50 PM, John Syne wrote:
>> One more thing, the power down sequence uses the RTC framework (described 
>> earlier in this thread), so it will be possible to set a timer for the 
>> shutdown and the wait for the power to return event to cancel the timer. If 
>> the power on event does not occur, the shutdown will occur.
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 17, 2016, at 7:18 PM, evilwulfie < 
>>> <mailto:evilwul...@gmail.com>evilwul...@gmail.com 
>>> <mailto:evilwul...@gmail.com>> wrote:
>>> 
>>> Interesting.  Too bad if you want the battery to act as a UPS it cant some 
>>> how notify the kernel that AC has been removed
>>> and have a routine to just chill a while to see if power comes back.
>>> 
>>> Be nice to have a variable that is user settable for the time between loss 
>>> of AC and shutdown.
>>> 
>>> As it is now it sees the AC removed, shuts down and no easy way to restart 
>>> on power restored. Requiring some other IC to monitor power 
>>> and then press the pwr_but to restart the processor.
>>> 
>>> 
>>> 
>>> On 4/17/2016 7:10 PM, John Syne wrote:
>>>> Yep, it is in the BB kernel:
>>>> 
>>>> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch
>>>>  
>>>> <https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch>
>>>> 
>>>> So again, on line 164 is the Interrupt routing. It is this line:
>>>> 
>>>> +  input_report_key(tps->pwr_but, KEY_POWER,
>>>> 
>>>> +  ~status_reg & TPS65217_STATUS_ACPWR);
>>>> that send a power button pressed as an input key when the AC 5V power is 
>>>> removed. 
>>>> 
>>>> Regards,
>>>> John
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Apr 17, 2016, at 4:52 PM, William Hermans <yyrk...@gmail.com 
>>>>> <mailto:yyrk...@gmail.com>> wrote:
>>>>> 
>>>>> The real reason why our source trees do not match up. My source tree is 
>>>>> based on 4.1.x, and yours seems to be 3.8.x. The patch you showed above 
>>>>> would probably botch up my source tree . . .
>>>>> 
>>>>> On Sun, Apr 17, 2016 at 4:33 PM, William Hermans < 
>>>>> <mailto:yyrk...@gmail.com>yyrk...@gmail.com <mailto:yyrk...@gmail.com>> 
>>>>> wrote:
>>>>> Yeah I recognize that code from source code not written by TI employees. 
>>>>> The file is called tps65217_charger.c, and is written by an employee of 
>>>>> another company.
>>>>> 
>>>>> Anyway, I think we're going to blow this off. The idea was to wait around 
>>>>> without power for 5 minutes, to see if power comes back up. Before 
>>>>> issuing a shutdown. Then, on the power up end, using a simple R/C circuit 
>>>>> to ramp up voltage to 5v over a specific time period.
>>>>> 
>>>>> 
>>> 
>>> 
>>>  
>>> <https://www.avast.com/en-us/lp-safe-emailing-2109?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=oa-2109-v2-a>
>>>   Virus-free. www.avast.com 
>>> <https://www.avast.com/en-us/lp-safe-emailing-2109?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=oa-2109-v2-a>
>>> 
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss 
>>> <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 
>>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>>> To view this discussion on the web visit  
>>> <https://groups.google.com/d/msgid/beagleboard/571443FC.6020505%40gmail.com?utm_medium=email_source=footer>https://groups.google.com

Re: [beagleboard] BBB Battery shutdown

[John Syne]

One more thing, the power down sequence uses the RTC framework (described 
earlier in this thread), so it will be possible to set a timer for the shutdown 
and the wait for the power to return event to cancel the timer. If the power on 
event does not occur, the shutdown will occur.

Regards,
John




> On Apr 17, 2016, at 7:18 PM, evilwulfie <evilwul...@gmail.com> wrote:
> 
> Interesting.  Too bad if you want the battery to act as a UPS it cant some 
> how notify the kernel that AC has been removed
> and have a routine to just chill a while to see if power comes back.
> 
> Be nice to have a variable that is user settable for the time between loss of 
> AC and shutdown.
> 
> As it is now it sees the AC removed, shuts down and no easy way to restart on 
> power restored. Requiring some other IC to monitor power 
> and then press the pwr_but to restart the processor.
> 
> 
> 
> On 4/17/2016 7:10 PM, John Syne wrote:
>> Yep, it is in the BB kernel:
>> 
>> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch
>>  
>> <https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch>
>> 
>> So again, on line 164 is the Interrupt routing. It is this line:
>> 
>> +input_report_key(tps->pwr_but, KEY_POWER,
>> 
>> +~status_reg & TPS65217_STATUS_ACPWR);
>> that send a power button pressed as an input key when the AC 5V power is 
>> removed. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 17, 2016, at 4:52 PM, William Hermans <yyrk...@gmail.com 
>>> <mailto:yyrk...@gmail.com>> wrote:
>>> 
>>> The real reason why our source trees do not match up. My source tree is 
>>> based on 4.1.x, and yours seems to be 3.8.x. The patch you showed above 
>>> would probably botch up my source tree . . .
>>> 
>>> On Sun, Apr 17, 2016 at 4:33 PM, William Hermans <yyrk...@gmail.com 
>>> <mailto:yyrk...@gmail.com>> wrote:
>>> Yeah I recognize that code from source code not written by TI employees. 
>>> The file is called tps65217_charger.c, and is written by an employee of 
>>> another company.
>>> 
>>> Anyway, I think we're going to blow this off. The idea was to wait around 
>>> without power for 5 minutes, to see if power comes back up. Before issuing 
>>> a shutdown. Then, on the power up end, using a simple R/C circuit to ramp 
>>> up voltage to 5v over a specific time period.
>>> 
>>> 
> 
> 
>  
> <https://www.avast.com/en-us/lp-safe-emailing-2109?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=oa-2109-v2-a>
> Virus-free. www.avast.com 
> <https://www.avast.com/en-us/lp-safe-emailing-2109?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=oa-2109-v2-a>
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/571443FC.6020505%40gmail.com 
> <https://groups.google.com/d/msgid/beagleboard/571443FC.6020505%40gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2CC5F218-6933-45E8-8B84-2CEE08263AF5%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Battery shutdown

[John Syne]

Yep, you need a hardware state machine to monitor the power source. I don’t use 
batteries as I use supercaps which are just big enough to power the board 
during shutdown. When the power returns, I restart the board. There are a few 
corner cases that occur, such as when the power comes back on during the power 
down cycle, or the power fails during the power up cycle.

Regards,
John




> On Apr 17, 2016, at 7:18 PM, evilwulfie <evilwul...@gmail.com> wrote:
> 
> Interesting.  Too bad if you want the battery to act as a UPS it cant some 
> how notify the kernel that AC has been removed
> and have a routine to just chill a while to see if power comes back.
> 
> Be nice to have a variable that is user settable for the time between loss of 
> AC and shutdown.
> 
> As it is now it sees the AC removed, shuts down and no easy way to restart on 
> power restored. Requiring some other IC to monitor power 
> and then press the pwr_but to restart the processor.
> 
> 
> 
> On 4/17/2016 7:10 PM, John Syne wrote:
>> Yep, it is in the BB kernel:
>> 
>> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch
>>  
>> <https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch>
>> 
>> So again, on line 164 is the Interrupt routing. It is this line:
>> 
>> +input_report_key(tps->pwr_but, KEY_POWER,
>> 
>> +~status_reg & TPS65217_STATUS_ACPWR);
>> that send a power button pressed as an input key when the AC 5V power is 
>> removed. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 17, 2016, at 4:52 PM, William Hermans <yyrk...@gmail.com 
>>> <mailto:yyrk...@gmail.com>> wrote:
>>> 
>>> The real reason why our source trees do not match up. My source tree is 
>>> based on 4.1.x, and yours seems to be 3.8.x. The patch you showed above 
>>> would probably botch up my source tree . . .
>>> 
>>> On Sun, Apr 17, 2016 at 4:33 PM, William Hermans <yyrk...@gmail.com 
>>> <mailto:yyrk...@gmail.com>> wrote:
>>> Yeah I recognize that code from source code not written by TI employees. 
>>> The file is called tps65217_charger.c, and is written by an employee of 
>>> another company.
>>> 
>>> Anyway, I think we're going to blow this off. The idea was to wait around 
>>> without power for 5 minutes, to see if power comes back up. Before issuing 
>>> a shutdown. Then, on the power up end, using a simple R/C circuit to ramp 
>>> up voltage to 5v over a specific time period.
>>> 
>>> 
> 
> 
>  
> <https://www.avast.com/en-us/lp-safe-emailing-2109?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=oa-2109-v2-a>
> Virus-free. www.avast.com 
> <https://www.avast.com/en-us/lp-safe-emailing-2109?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=oa-2109-v2-a>
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/571443FC.6020505%40gmail.com 
> <https://groups.google.com/d/msgid/beagleboard/571443FC.6020505%40gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/B1D3922E-9D41-4222-AD11-407748DC7B0E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Battery shutdown

[John Syne]

Sorry, that should have read line 75 in the patch file, line 164 in the source 
code. BTW, this was something I was going to work on but thanks to you I now 
have a handle on this.

Regards,
John




> On Apr 17, 2016, at 4:52 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> The real reason why our source trees do not match up. My source tree is based 
> on 4.1.x, and yours seems to be 3.8.x. The patch you showed above would 
> probably botch up my source tree . . .
> 
> On Sun, Apr 17, 2016 at 4:33 PM, William Hermans <yyrk...@gmail.com 
> <mailto:yyrk...@gmail.com>> wrote:
> Yeah I recognize that code from source code not written by TI employees. The 
> file is called tps65217_charger.c, and is written by an employee of another 
> company.
> 
> Anyway, I think we're going to blow this off. The idea was to wait around 
> without power for 5 minutes, to see if power comes back up. Before issuing a 
> shutdown. Then, on the power up end, using a simple R/C circuit to ramp up 
> voltage to 5v over a specific time period.
> 
> By the way, my local source tree is already patched with Robert's BBB 
> patches. 
> 
> On Sun, Apr 17, 2016 at 4:19 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> Apply this patch:
> 
> From 51b4d415971bb052a26938791337d1050bf94748 Mon Sep 17 00:00:00 2001
> From: Robert Nelson <robertcnel...@gmail.com <mailto:robertcnel...@gmail.com>>
> Date: Mon, 26 Oct 2015 11:42:13 -0500
> Subject: [PATCH 8/9] tps65217: Enable KEY_POWER press on AC loss / PWR_BUT
> 
> This is an adaption to v3.14.x of the original patch by Andrew Bradford 
> <andrew.bradf...@omni-id.com <mailto:andrew.bradf...@omni-id.com>>
> Some minor devm_* changes and DT support done by Pantelis Antoniou 
> <pa...@antoniou-consulting.com <mailto:pa...@antoniou-consulting.com>> for 
> 3.8.x
> 
> Signed-off-by: Robert Nelson <robertcnel...@gmail.com 
> <mailto:robertcnel...@gmail.com>>
> ---
>  arch/arm/boot/dts/am335x-bone-common.dtsi |   3 +
>  drivers/mfd/tps65217.c| 122 
> +-
>  include/linux/mfd/tps65217.h  |   5 ++
>  3 files changed, 128 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
> b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index 29c0c7e..393af39 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -330,6 +330,9 @@
>*/
>   ti,pmic-shutdown-controller;
>  
> + interrupt-parent = <>;
> + interrupts = <7>;   /* NNMI */
> +
>   regulators {
>   dcdc1_reg: regulator@0 {
>   regulator-name = "vdds_dpr";
> diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
> index 7d1cfc1..0730431 100644
> --- a/drivers/mfd/tps65217.c
> +++ b/drivers/mfd/tps65217.c
> @@ -24,8 +24,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> @@ -157,6 +161,82 @@ static const struct of_device_id tps65217_of_match[] = {
>   { /* sentinel */ },
>  };
>  
> +static irqreturn_t tps65217_irq(int irq, void *irq_data)
> +{
> + struct tps65217 *tps = irq_data;
> + unsigned int int_reg = 0, status_reg = 0;
> +
> + tps65217_reg_read(tps, TPS65217_REG_INT, _reg);
> + tps65217_reg_read(tps, TPS65217_REG_STATUS, _reg);
> + if (status_reg)
> + dev_dbg(tps->dev, "status now: 0x%X\n", status_reg);
> +
> + if (!int_reg)
> + return IRQ_NONE;
> +
> + if (int_reg & TPS65217_INT_PBI) {
> + /* Handle push button */
> + dev_dbg(tps->dev, "power button status change\n");
> + input_report_key(tps->pwr_but, KEY_POWER,
> + status_reg & TPS65217_STATUS_PB);
> + input_sync(tps->pwr_but);
> + }
> + if (int_reg & TPS65217_INT_ACI) {
> + /* Handle AC power status change */
> + dev_dbg(tps->dev, "AC power status change\n");
> + /* Press KEY_POWER when AC not present */
> + input_report_key(tps->pwr_but, KEY_POWER,
> + ~status_reg & TPS65217_STATUS_ACPWR);
> + input_sync(tps->pwr_but);
> + }
> + if (int_reg & TPS65217_INT_USBI) {
> + /* Handle USB power status change */
> + dev_dbg(tps->dev, "USB power status change\n");
> + }
> +
> + return IR

Re: [beagleboard] BBB Battery shutdown

[John Syne]

Yep, it is in the BB kernel:

https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch
 
<https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch>

So again, on line 164 is the Interrupt routing. It is this line:

+   input_report_key(tps->pwr_but, KEY_POWER,
+   ~status_reg & TPS65217_STATUS_ACPWR);
that send a power button pressed as an input key when the AC 5V power is 
removed. 

Regards,
John




> On Apr 17, 2016, at 4:52 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> The real reason why our source trees do not match up. My source tree is based 
> on 4.1.x, and yours seems to be 3.8.x. The patch you showed above would 
> probably botch up my source tree . . .
> 
> On Sun, Apr 17, 2016 at 4:33 PM, William Hermans <yyrk...@gmail.com 
> <mailto:yyrk...@gmail.com>> wrote:
> Yeah I recognize that code from source code not written by TI employees. The 
> file is called tps65217_charger.c, and is written by an employee of another 
> company.
> 
> Anyway, I think we're going to blow this off. The idea was to wait around 
> without power for 5 minutes, to see if power comes back up. Before issuing a 
> shutdown. Then, on the power up end, using a simple R/C circuit to ramp up 
> voltage to 5v over a specific time period.
> 
> By the way, my local source tree is already patched with Robert's BBB 
> patches. 
> 
> On Sun, Apr 17, 2016 at 4:19 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> Apply this patch:
> 
> From 51b4d415971bb052a26938791337d1050bf94748 Mon Sep 17 00:00:00 2001
> From: Robert Nelson <robertcnel...@gmail.com <mailto:robertcnel...@gmail.com>>
> Date: Mon, 26 Oct 2015 11:42:13 -0500
> Subject: [PATCH 8/9] tps65217: Enable KEY_POWER press on AC loss / PWR_BUT
> 
> This is an adaption to v3.14.x of the original patch by Andrew Bradford 
> <andrew.bradf...@omni-id.com <mailto:andrew.bradf...@omni-id.com>>
> Some minor devm_* changes and DT support done by Pantelis Antoniou 
> <pa...@antoniou-consulting.com <mailto:pa...@antoniou-consulting.com>> for 
> 3.8.x
> 
> Signed-off-by: Robert Nelson <robertcnel...@gmail.com 
> <mailto:robertcnel...@gmail.com>>
> ---
>  arch/arm/boot/dts/am335x-bone-common.dtsi |   3 +
>  drivers/mfd/tps65217.c| 122 
> +-
>  include/linux/mfd/tps65217.h  |   5 ++
>  3 files changed, 128 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
> b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index 29c0c7e..393af39 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -330,6 +330,9 @@
>*/
>   ti,pmic-shutdown-controller;
>  
> + interrupt-parent = <>;
> + interrupts = <7>;   /* NNMI */
> +
>   regulators {
>   dcdc1_reg: regulator@0 {
>   regulator-name = "vdds_dpr";
> diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
> index 7d1cfc1..0730431 100644
> --- a/drivers/mfd/tps65217.c
> +++ b/drivers/mfd/tps65217.c
> @@ -24,8 +24,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> @@ -157,6 +161,82 @@ static const struct of_device_id tps65217_of_match[] = {
>   { /* sentinel */ },
>  };
>  
> +static irqreturn_t tps65217_irq(int irq, void *irq_data)
> +{
> + struct tps65217 *tps = irq_data;
> + unsigned int int_reg = 0, status_reg = 0;
> +
> + tps65217_reg_read(tps, TPS65217_REG_INT, _reg);
> + tps65217_reg_read(tps, TPS65217_REG_STATUS, _reg);
> + if (status_reg)
> + dev_dbg(tps->dev, "status now: 0x%X\n", status_reg);
> +
> + if (!int_reg)
> + return IRQ_NONE;
> +
> + if (int_reg & TPS65217_INT_PBI) {
> + /* Handle push button */
> + dev_dbg(tps->dev, "power button status change\n");
> + input_report_key(tps->pwr_but, KEY_POWER,
> + status_reg & TPS65217_STATUS_PB);
> + input_sync(tps->pwr_but);
> + }
> + if (int_reg & TPS65217_INT_ACI) {
> + /* Handle AC power status change */
> + dev_dbg(tps->dev, "AC power status change\n");
> + /* Press KEY_POWER when AC not

Re: [beagleboard] BBB Battery shutdown

[John Syne]

Nope, mine is based on 4.1. This patch was adapted by Robert from code that was 
written for 3.8.

Regards,
John




> On Apr 17, 2016, at 4:52 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> The real reason why our source trees do not match up. My source tree is based 
> on 4.1.x, and yours seems to be 3.8.x. The patch you showed above would 
> probably botch up my source tree . . .
> 
> On Sun, Apr 17, 2016 at 4:33 PM, William Hermans <yyrk...@gmail.com 
> <mailto:yyrk...@gmail.com>> wrote:
> Yeah I recognize that code from source code not written by TI employees. The 
> file is called tps65217_charger.c, and is written by an employee of another 
> company.
> 
> Anyway, I think we're going to blow this off. The idea was to wait around 
> without power for 5 minutes, to see if power comes back up. Before issuing a 
> shutdown. Then, on the power up end, using a simple R/C circuit to ramp up 
> voltage to 5v over a specific time period.
> 
> By the way, my local source tree is already patched with Robert's BBB 
> patches. 
> 
> On Sun, Apr 17, 2016 at 4:19 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> Apply this patch:
> 
> From 51b4d415971bb052a26938791337d1050bf94748 Mon Sep 17 00:00:00 2001
> From: Robert Nelson <robertcnel...@gmail.com <mailto:robertcnel...@gmail.com>>
> Date: Mon, 26 Oct 2015 11:42:13 -0500
> Subject: [PATCH 8/9] tps65217: Enable KEY_POWER press on AC loss / PWR_BUT
> 
> This is an adaption to v3.14.x of the original patch by Andrew Bradford 
> <andrew.bradf...@omni-id.com <mailto:andrew.bradf...@omni-id.com>>
> Some minor devm_* changes and DT support done by Pantelis Antoniou 
> <pa...@antoniou-consulting.com <mailto:pa...@antoniou-consulting.com>> for 
> 3.8.x
> 
> Signed-off-by: Robert Nelson <robertcnel...@gmail.com 
> <mailto:robertcnel...@gmail.com>>
> ---
>  arch/arm/boot/dts/am335x-bone-common.dtsi |   3 +
>  drivers/mfd/tps65217.c| 122 
> +-
>  include/linux/mfd/tps65217.h  |   5 ++
>  3 files changed, 128 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
> b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index 29c0c7e..393af39 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -330,6 +330,9 @@
>*/
>   ti,pmic-shutdown-controller;
>  
> + interrupt-parent = <>;
> + interrupts = <7>;   /* NNMI */
> +
>   regulators {
>   dcdc1_reg: regulator@0 {
>   regulator-name = "vdds_dpr";
> diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
> index 7d1cfc1..0730431 100644
> --- a/drivers/mfd/tps65217.c
> +++ b/drivers/mfd/tps65217.c
> @@ -24,8 +24,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> @@ -157,6 +161,82 @@ static const struct of_device_id tps65217_of_match[] = {
>   { /* sentinel */ },
>  };
>  
> +static irqreturn_t tps65217_irq(int irq, void *irq_data)
> +{
> + struct tps65217 *tps = irq_data;
> + unsigned int int_reg = 0, status_reg = 0;
> +
> + tps65217_reg_read(tps, TPS65217_REG_INT, _reg);
> + tps65217_reg_read(tps, TPS65217_REG_STATUS, _reg);
> + if (status_reg)
> + dev_dbg(tps->dev, "status now: 0x%X\n", status_reg);
> +
> + if (!int_reg)
> + return IRQ_NONE;
> +
> + if (int_reg & TPS65217_INT_PBI) {
> + /* Handle push button */
> + dev_dbg(tps->dev, "power button status change\n");
> + input_report_key(tps->pwr_but, KEY_POWER,
> + status_reg & TPS65217_STATUS_PB);
> + input_sync(tps->pwr_but);
> + }
> + if (int_reg & TPS65217_INT_ACI) {
> + /* Handle AC power status change */
> + dev_dbg(tps->dev, "AC power status change\n");
> + /* Press KEY_POWER when AC not present */
> + input_report_key(tps->pwr_but, KEY_POWER,
> + ~status_reg & TPS65217_STATUS_ACPWR);
> + input_sync(tps->pwr_but);
> + }
> + if (int_reg & TPS65217_INT_USBI) {
> + /* Handle USB power status change */
> + dev_dbg(tps->dev, "USB power status change\n");
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int tps65217_probe_pwr_but(struc

Re: [beagleboard] BBB Battery shutdown

[John Syne]

_device_id *match;
+   struct device_node *node;
bool status_off = false;
+   int irq = -1, irq_gpio = -1;
int ret;
 
-   if (client->dev.of_node) {
+   node = client->dev.of_node;
+   if (node) {
match = of_match_device(tps65217_of_match, >dev);
if (!match) {
dev_err(>dev,
@@ -175,8 +258,31 @@ static int tps65217_probe(struct i2c_client *client,
return -EINVAL;
}
chip_id = (unsigned long)match->data;
-   status_off = of_property_read_bool(client->dev.of_node,
+   status_off = of_property_read_bool(node,
"ti,pmic-shutdown-controller");
+
+   /* at first try to get irq via OF method */
+   irq = irq_of_parse_and_map(node, 0);
+   if (irq <= 0) {
+   irq = -1;
+   irq_gpio = of_get_named_gpio(node, "irq-gpio", 0);
+   if (irq_gpio >= 0) {
+   /* valid gpio; convert to irq */
+   ret = devm_gpio_request_one(>dev,
+   irq_gpio, GPIOF_DIR_IN,
+   "tps65217-gpio-irq");
+   if (ret != 0)
+   dev_warn(>dev, "Failed to "
+   "request gpio #%d\n", irq_gpio);
+   irq = gpio_to_irq(irq_gpio);
+   if (irq <= 0) {
+   dev_warn(>dev, "Failed to "
+   "convert gpio #%d to irq\n",
+   irq_gpio);
+   irq = -1;
+   }
+   }
+   }
}
 
if (!chip_id) {
@@ -200,6 +306,18 @@ static int tps65217_probe(struct i2c_client *client,
return ret;
}
 
+   tps->irq = irq;
+   tps->irq_gpio = irq_gpio;
+
+   /* we got an irq, request it */
+   if (tps->irq >= 0) {
+   ret = tps65217_probe_pwr_but(tps);
+   if (ret < 0) {
+   dev_err(tps->dev, "Failed to probe pwr_but\n");
+   return ret;
+   }
+   }
+
ret = mfd_add_devices(tps->dev, -1, tps65217s,
  ARRAY_SIZE(tps65217s), NULL, 0, NULL);
if (ret < 0) {
diff --git a/include/linux/mfd/tps65217.h b/include/linux/mfd/tps65217.h
index ac7fba4..05d24a6 100644
--- a/include/linux/mfd/tps65217.h
+++ b/include/linux/mfd/tps65217.h
@@ -257,6 +257,11 @@ struct tps65217 {
unsigned long id;
struct regulator_desc desc[TPS65217_NUM_REGULATOR];
struct regmap *regmap;
+
+   /* Power button and IRQ handling */
+   int irq_gpio;   /* might not be set */
+   int irq;
+   struct input_dev *pwr_but;
 };
 
 static inline struct tps65217 *dev_to_tps65217(struct device *dev)
-- 
2.6.2

Regards,
John




> On Apr 17, 2016, at 4:05 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> I'll *NOT* be using a TI kernel, period.
> 
> On Sun, Apr 17, 2016 at 4:02 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> OK, I see the problem. The file I was looking at is different to the one you 
> linked to. I am using the 4.1.13-ti-r33 kernel, which means that you are 
> missing a patch. Build your own kernel and then look at this file again.
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 17, 2016, at 3:55 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> 
>> https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L164 
>> <https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L164>
>> 
>> Nothing there at line 164, then on line 165 starts a function. Which 
>> contains the code I linked to yesterday. Which is the power push button 
>> code. Which again, is not helping . . . So let's walk through that function. 
>> Which happens in this order . ..
>> 
>> variable type definitions declarations.
>> conditional check to find device tree definition node.
>> test chip_id, return if failure.
>> attempt and test to allocate memory for the tps object.
>> attempt to map the tps object to the PMIC registers
>> mfd device add, and test device add.
>> attempt to read the PMIC registers, and test return code.
>> 
>> Here it gets a bit fuzzy however, it seems as though the code is attempting 
>> to r

Re: [beagleboard] BBB Battery shutdown

[John Syne]

static irqreturn_t tps65217_irq(int irq, void *irq_data)
{
struct tps65217 *tps = irq_data;
unsigned int int_reg = 0, status_reg = 0;

tps65217_reg_read(tps, TPS65217_REG_INT, _reg);
tps65217_reg_read(tps, TPS65217_REG_STATUS, _reg);
if (status_reg)
dev_dbg(tps->dev, "status now: 0x%X\n", status_reg);

if (!int_reg)
return IRQ_NONE;

if (int_reg & TPS65217_INT_PBI) {
/* Handle push button */
dev_dbg(tps->dev, "power button status change\n");
input_report_key(tps->pwr_but, KEY_POWER,
status_reg & TPS65217_STATUS_PB);
input_sync(tps->pwr_but);
}
if (int_reg & TPS65217_INT_ACI) {
/* Handle AC power status change */
dev_dbg(tps->dev, "AC power status change\n");
/* Press KEY_POWER when AC not present */
input_report_key(tps->pwr_but, KEY_POWER,
~status_reg & TPS65217_STATUS_ACPWR);
input_sync(tps->pwr_but);
}
if (int_reg & TPS65217_INT_USBI) {
/* Handle USB power status change */
dev_dbg(tps->dev, "USB power status change\n");
}

return IRQ_HANDLED;
}

Regards,
John




> On Apr 17, 2016, at 4:05 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> I'll *NOT* be using a TI kernel, period.
> 
> On Sun, Apr 17, 2016 at 4:02 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> OK, I see the problem. The file I was looking at is different to the one you 
> linked to. I am using the 4.1.13-ti-r33 kernel, which means that you are 
> missing a patch. Build your own kernel and then look at this file again.
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 17, 2016, at 3:55 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> 
>> https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L164 
>> <https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L164>
>> 
>> Nothing there at line 164, then on line 165 starts a function. Which 
>> contains the code I linked to yesterday. Which is the power push button 
>> code. Which again, is not helping . . . So let's walk through that function. 
>> Which happens in this order . ..
>> 
>> variable type definitions declarations.
>> conditional check to find device tree definition node.
>> test chip_id, return if failure.
>> attempt and test to allocate memory for the tps object.
>> attempt to map the tps object to the PMIC registers
>> mfd device add, and test device add.
>> attempt to read the PMIC registers, and test return code.
>> 
>> Here it gets a bit fuzzy however, it seems as though the code is attempting 
>> to reset the system by setting various register bits in the PMIC ?! I know 
>> all about the registers of the PMIC, or rather can find otu what is what 
>> really quick by reading the datasheet which I have right in front of me. 
>> That is not what I'm having an issue grasping. It seems to me that a 
>> shutdown in this manner would not be clean. However, it could be that 
>> setting these register bits as such may not cause an immediate power down. 
>> *That* is what I find unclear.
>> 
>> /* Set the PMIC to shutdown on PWR_EN toggle */
>> if (status_off) {
>> ret = tps65217_set_bits(tps, TPS65217_REG_STATUS,
>> TPS65217_STATUS_OFF, TPS65217_STATUS_OFF,
>> TPS65217_PROTECT_NONE);
>> if (ret)
>> dev_warn(tps->dev, "unable to set the status OFF\n");
>> }
>> 
>> The comment above the code seems to indicate that PWR_EN is causing a 
>> shutdown based on being toggle. However, PWR_EN is *NOT* a button, or even a 
>> line connected to a button. From the data sheet . . .
>> 
>> PWR_EN
>> Enable input for DCDC1, 2, 3 converters and LDO1, 2, 3, 4. Pull this pin 
>> high to start the
>> power-up sequence.
>> 
>>  In the schematic, PWR_EN is not connected to any button. Period. The button 
>> is connected to PB_IN.
>> 
>> Anyway, the rest of the code is inconsequential.
>> 
>> On Sun, Apr 17, 2016 at 3:23 PM, John Syne <john3...@gmail.com 
>> <mailto:john3...@gmail.com>> wrote:
>> Never mind, I found it.
>> 
>> drivers/mfd/tps65217.c line 164
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 17, 2016

Re: [beagleboard] BBB Battery shutdown

[John Syne]

The patched code is easier to read

Regards,
John




> On Apr 17, 2016, at 3:55 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L164 
> <https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L164>
> 
> Nothing there at line 164, then on line 165 starts a function. Which contains 
> the code I linked to yesterday. Which is the power push button code. Which 
> again, is not helping . . . So let's walk through that function. Which 
> happens in this order . ..
> 
> variable type definitions declarations.
> conditional check to find device tree definition node.
> test chip_id, return if failure.
> attempt and test to allocate memory for the tps object.
> attempt to map the tps object to the PMIC registers
> mfd device add, and test device add.
> attempt to read the PMIC registers, and test return code.
> 
> Here it gets a bit fuzzy however, it seems as though the code is attempting 
> to reset the system by setting various register bits in the PMIC ?! I know 
> all about the registers of the PMIC, or rather can find otu what is what 
> really quick by reading the datasheet which I have right in front of me. That 
> is not what I'm having an issue grasping. It seems to me that a shutdown in 
> this manner would not be clean. However, it could be that setting these 
> register bits as such may not cause an immediate power down. *That* is what I 
> find unclear.
> 
> /* Set the PMIC to shutdown on PWR_EN toggle */
> if (status_off) {
> ret = tps65217_set_bits(tps, TPS65217_REG_STATUS,
> TPS65217_STATUS_OFF, TPS65217_STATUS_OFF,
> TPS65217_PROTECT_NONE);
> if (ret)
> dev_warn(tps->dev, "unable to set the status OFF\n");
> }
> 
> The comment above the code seems to indicate that PWR_EN is causing a 
> shutdown based on being toggle. However, PWR_EN is *NOT* a button, or even a 
> line connected to a button. From the data sheet . . .
> 
> PWR_EN
> Enable input for DCDC1, 2, 3 converters and LDO1, 2, 3, 4. Pull this pin high 
> to start the
> power-up sequence.
> 
>  In the schematic, PWR_EN is not connected to any button. Period. The button 
> is connected to PB_IN.
> 
> Anyway, the rest of the code is inconsequential.
> 
> On Sun, Apr 17, 2016 at 3:23 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> Never mind, I found it.
> 
> drivers/mfd/tps65217.c line 164
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 17, 2016, at 2:37 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> 
>> So no one has any idea ? I'm looking for the module, that traps power 
>> events, and shuts down the BBB. All I need is a file name. It's pretty hard 
>> making sense of the mess that is /drivers/mfd, and the documentation does 
>> not seem to be helpful either.
>> 
>> Documentation/power/regulator/charger-management.txt does not exist in my 
>> repo, nor in Linus' repo either. There is a similar file, but nothing 
>> apparently related to our hardware. Passed that, most of the stuff int the 
>> Documentation/power directory seems to be related to ACPI, which again, has 
>> nothing to do with even our architecture . . .
>> 
>> On Sat, Apr 16, 2016 at 9:09 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> So I've only found this so far. 
>> https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L222-#L229
>>  
>> <https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L222-%23L229>
>> 
>> Which I pretty much had already figured out this morning right after I 
>> posted. Pretty much, the PMIC sees a condition, that needs attention. It 
>> writes some values to registers that relate to the given condition, and then 
>> sends an NMI out to the am335x processor. Where the am335x processor 
>> immediately picks up that the PMIC needs attention( the whole point of an 
>> NMI ), reads the register values out of the PMIC to determine what action 
>> needs to be taken. Which in the case of the power button being pressed. the 
>> am335x issues a shutdown now -h ( Linux ) Which looking at the code, 
>> actually seems like the LKM is actually writing to the PMIC registers to do 
>> this ?!
>> 
>> Anyway, no idea how a power good condition is being acted on *still*. 
>> Meaning, no idea how when a battery is connected, when the external power 
>> somehow goes missing. How that particular shutdown is happening, and from 
>> where.
&

Re: [beagleboard] BBB Battery shutdown

[John Syne]

OK, I see the problem. The file I was looking at is different to the one you 
linked to. I am using the 4.1.13-ti-r33 kernel, which means that you are 
missing a patch. Build your own kernel and then look at this file again.

Regards,
John




> On Apr 17, 2016, at 3:55 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L164 
> <https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L164>
> 
> Nothing there at line 164, then on line 165 starts a function. Which contains 
> the code I linked to yesterday. Which is the power push button code. Which 
> again, is not helping . . . So let's walk through that function. Which 
> happens in this order . ..
> 
> variable type definitions declarations.
> conditional check to find device tree definition node.
> test chip_id, return if failure.
> attempt and test to allocate memory for the tps object.
> attempt to map the tps object to the PMIC registers
> mfd device add, and test device add.
> attempt to read the PMIC registers, and test return code.
> 
> Here it gets a bit fuzzy however, it seems as though the code is attempting 
> to reset the system by setting various register bits in the PMIC ?! I know 
> all about the registers of the PMIC, or rather can find otu what is what 
> really quick by reading the datasheet which I have right in front of me. That 
> is not what I'm having an issue grasping. It seems to me that a shutdown in 
> this manner would not be clean. However, it could be that setting these 
> register bits as such may not cause an immediate power down. *That* is what I 
> find unclear.
> 
> /* Set the PMIC to shutdown on PWR_EN toggle */
> if (status_off) {
> ret = tps65217_set_bits(tps, TPS65217_REG_STATUS,
> TPS65217_STATUS_OFF, TPS65217_STATUS_OFF,
> TPS65217_PROTECT_NONE);
> if (ret)
> dev_warn(tps->dev, "unable to set the status OFF\n");
> }
> 
> The comment above the code seems to indicate that PWR_EN is causing a 
> shutdown based on being toggle. However, PWR_EN is *NOT* a button, or even a 
> line connected to a button. From the data sheet . . .
> 
> PWR_EN
> Enable input for DCDC1, 2, 3 converters and LDO1, 2, 3, 4. Pull this pin high 
> to start the
> power-up sequence.
> 
>  In the schematic, PWR_EN is not connected to any button. Period. The button 
> is connected to PB_IN.
> 
> Anyway, the rest of the code is inconsequential.
> 
> On Sun, Apr 17, 2016 at 3:23 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> Never mind, I found it.
> 
> drivers/mfd/tps65217.c line 164
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 17, 2016, at 2:37 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> 
>> So no one has any idea ? I'm looking for the module, that traps power 
>> events, and shuts down the BBB. All I need is a file name. It's pretty hard 
>> making sense of the mess that is /drivers/mfd, and the documentation does 
>> not seem to be helpful either.
>> 
>> Documentation/power/regulator/charger-management.txt does not exist in my 
>> repo, nor in Linus' repo either. There is a similar file, but nothing 
>> apparently related to our hardware. Passed that, most of the stuff int the 
>> Documentation/power directory seems to be related to ACPI, which again, has 
>> nothing to do with even our architecture . . .
>> 
>> On Sat, Apr 16, 2016 at 9:09 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> So I've only found this so far. 
>> https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L222-#L229
>>  
>> <https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L222-%23L229>
>> 
>> Which I pretty much had already figured out this morning right after I 
>> posted. Pretty much, the PMIC sees a condition, that needs attention. It 
>> writes some values to registers that relate to the given condition, and then 
>> sends an NMI out to the am335x processor. Where the am335x processor 
>> immediately picks up that the PMIC needs attention( the whole point of an 
>> NMI ), reads the register values out of the PMIC to determine what action 
>> needs to be taken. Which in the case of the power button being pressed. the 
>> am335x issues a shutdown now -h ( Linux ) Which looking at the code, 
>> actually seems like the LKM is actually writing to the PMIC registers to do 
>> this ?!
>> 
>> Anyway, no idea how a power good condition is being acted

Re: [beagleboard] BBB Battery shutdown

[John Syne]

I guess I should have read your explanation more closely. OK the interrupt 
routing issues a key input which replicates the power button being pushed. Not 
sure if this is what you want, or if you want to stop this from happening when 
when the AC power is removed.

Regards,
John




> On Apr 17, 2016, at 2:37 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> So no one has any idea ? I'm looking for the module, that traps power events, 
> and shuts down the BBB. All I need is a file name. It's pretty hard making 
> sense of the mess that is /drivers/mfd, and the documentation does not seem 
> to be helpful either.
> 
> Documentation/power/regulator/charger-management.txt does not exist in my 
> repo, nor in Linus' repo either. There is a similar file, but nothing 
> apparently related to our hardware. Passed that, most of the stuff int the 
> Documentation/power directory seems to be related to ACPI, which again, has 
> nothing to do with even our architecture . . .
> 
> On Sat, Apr 16, 2016 at 9:09 PM, William Hermans <yyrk...@gmail.com 
> <mailto:yyrk...@gmail.com>> wrote:
> So I've only found this so far. 
> https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L222-#L229
>  
> <https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L222-%23L229>
> 
> Which I pretty much had already figured out this morning right after I 
> posted. Pretty much, the PMIC sees a condition, that needs attention. It 
> writes some values to registers that relate to the given condition, and then 
> sends an NMI out to the am335x processor. Where the am335x processor 
> immediately picks up that the PMIC needs attention( the whole point of an NMI 
> ), reads the register values out of the PMIC to determine what action needs 
> to be taken. Which in the case of the power button being pressed. the am335x 
> issues a shutdown now -h ( Linux ) Which looking at the code, actually seems 
> like the LKM is actually writing to the PMIC registers to do this ?!
> 
> Anyway, no idea how a power good condition is being acted on *still*. 
> Meaning, no idea how when a battery is connected, when the external power 
> somehow goes missing. How that particular shutdown is happening, and from 
> where.
> 
> On Sat, Apr 16, 2016 at 4:32 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> I’m not sure, but best place to look would be 
> Documentation/power/regulator/charger-management.txt. I believe the PMIC 
> issues event when AC is removed. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 16, 2016, at 12:59 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> 
>> Also from what I've read this behavior is different between console and LXDE 
>> images. So if this is true I understand that. I do not want the behaviors 
>> that each of these images provides, but wish to customize my own.
>> 
>> 
>> On Sat, Apr 16, 2016 at 12:55 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> When a battery is connected to a beaglebone black, how does the software 
>> know to issue a shutdown when power is no longer coming in ? More 
>> specifically I'm interested in which file / script performs this action, and 
>> what mechanism triggers this behavior.
>> 
>> My intentions are to modify / customize what actually happens when power to 
>> the board is battery only.
>> 
>> 
>> 
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> For more options,

Re: [beagleboard] BBB Battery shutdown

[John Syne]

The best person to ask would be Nishanth Menon <n...@ti.com 
<mailto:n...@ti.com>> or Anilkumar Ch <anilku...@ti.com

Regards,
John




> On Apr 17, 2016, at 2:37 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> So no one has any idea ? I'm looking for the module, that traps power events, 
> and shuts down the BBB. All I need is a file name. It's pretty hard making 
> sense of the mess that is /drivers/mfd, and the documentation does not seem 
> to be helpful either.
> 
> Documentation/power/regulator/charger-management.txt does not exist in my 
> repo, nor in Linus' repo either. There is a similar file, but nothing 
> apparently related to our hardware. Passed that, most of the stuff int the 
> Documentation/power directory seems to be related to ACPI, which again, has 
> nothing to do with even our architecture . . .
> 
> On Sat, Apr 16, 2016 at 9:09 PM, William Hermans <yyrk...@gmail.com 
> <mailto:yyrk...@gmail.com>> wrote:
> So I've only found this so far. 
> https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L222-#L229
>  
> <https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L222-%23L229>
> 
> Which I pretty much had already figured out this morning right after I 
> posted. Pretty much, the PMIC sees a condition, that needs attention. It 
> writes some values to registers that relate to the given condition, and then 
> sends an NMI out to the am335x processor. Where the am335x processor 
> immediately picks up that the PMIC needs attention( the whole point of an NMI 
> ), reads the register values out of the PMIC to determine what action needs 
> to be taken. Which in the case of the power button being pressed. the am335x 
> issues a shutdown now -h ( Linux ) Which looking at the code, actually seems 
> like the LKM is actually writing to the PMIC registers to do this ?!
> 
> Anyway, no idea how a power good condition is being acted on *still*. 
> Meaning, no idea how when a battery is connected, when the external power 
> somehow goes missing. How that particular shutdown is happening, and from 
> where.
> 
> On Sat, Apr 16, 2016 at 4:32 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> I’m not sure, but best place to look would be 
> Documentation/power/regulator/charger-management.txt. I believe the PMIC 
> issues event when AC is removed. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 16, 2016, at 12:59 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> 
>> Also from what I've read this behavior is different between console and LXDE 
>> images. So if this is true I understand that. I do not want the behaviors 
>> that each of these images provides, but wish to customize my own.
>> 
>> 
>> On Sat, Apr 16, 2016 at 12:55 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> When a battery is connected to a beaglebone black, how does the software 
>> know to issue a shutdown when power is no longer coming in ? More 
>> specifically I'm interested in which file / script performs this action, and 
>> what mechanism triggers this behavior.
>> 
>> My intentions are to modify / customize what actually happens when power to 
>> the board is battery only.
>> 
>> 
>> 
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <http://beagleboard.org/discuss>
> --- 
> You received this message because you are sub

Re: [beagleboard] BBB Battery shutdown

[John Syne]

So in the TPS65217 datasheet, Section 9.3.7, it says in interrupt is generated 
when pushbutton is pressed/released and USB and AC voltage status change.
Look at the interrupt handler and see how this is implemented.

Regards,
John




> On Apr 17, 2016, at 2:37 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> So no one has any idea ? I'm looking for the module, that traps power events, 
> and shuts down the BBB. All I need is a file name. It's pretty hard making 
> sense of the mess that is /drivers/mfd, and the documentation does not seem 
> to be helpful either.
> 
> Documentation/power/regulator/charger-management.txt does not exist in my 
> repo, nor in Linus' repo either. There is a similar file, but nothing 
> apparently related to our hardware. Passed that, most of the stuff int the 
> Documentation/power directory seems to be related to ACPI, which again, has 
> nothing to do with even our architecture . . .
> 
> On Sat, Apr 16, 2016 at 9:09 PM, William Hermans <yyrk...@gmail.com 
> <mailto:yyrk...@gmail.com>> wrote:
> So I've only found this so far. 
> https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L222-#L229
>  
> <https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L222-%23L229>
> 
> Which I pretty much had already figured out this morning right after I 
> posted. Pretty much, the PMIC sees a condition, that needs attention. It 
> writes some values to registers that relate to the given condition, and then 
> sends an NMI out to the am335x processor. Where the am335x processor 
> immediately picks up that the PMIC needs attention( the whole point of an NMI 
> ), reads the register values out of the PMIC to determine what action needs 
> to be taken. Which in the case of the power button being pressed. the am335x 
> issues a shutdown now -h ( Linux ) Which looking at the code, actually seems 
> like the LKM is actually writing to the PMIC registers to do this ?!
> 
> Anyway, no idea how a power good condition is being acted on *still*. 
> Meaning, no idea how when a battery is connected, when the external power 
> somehow goes missing. How that particular shutdown is happening, and from 
> where.
> 
> On Sat, Apr 16, 2016 at 4:32 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> I’m not sure, but best place to look would be 
> Documentation/power/regulator/charger-management.txt. I believe the PMIC 
> issues event when AC is removed. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 16, 2016, at 12:59 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> 
>> Also from what I've read this behavior is different between console and LXDE 
>> images. So if this is true I understand that. I do not want the behaviors 
>> that each of these images provides, but wish to customize my own.
>> 
>> 
>> On Sat, Apr 16, 2016 at 12:55 PM, William Hermans <yyrk...@gmail.com 
>> <mailto:yyrk...@gmail.com>> wrote:
>> When a battery is connected to a beaglebone black, how does the software 
>> know to issue a shutdown when power is no longer coming in ? More 
>> specifically I'm interested in which file / script performs this action, and 
>> what mechanism triggers this behavior.
>> 
>> My intentions are to modify / customize what actually happens when power to 
>> the board is battery only.
>> 
>> 
>> 
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <h

Re: [beagleboard] How to make a python program start on boot? May need to use sudo.

[John Syne]

OK, so you need to learn about unix groups. In essence, you need to create a 
group, say “cape” and then make your userid a member of this group. After that, 
do the following:

sudo chown root:cape /sys/devices/bone_capemgr.9/slots

Now, as a member of the group “cape”, you are permitted to write to 
/sys/devices/bone_capemgr.9/slots.

Regards,
John




> On Apr 17, 2016, at 11:24 AM, John Baker  wrote:
> 
> I just now discovered the problem requiring sudo to start my python program. 
> It's related to PyBBIO library code to write to the PWM interface on the BBB. 
> I am trying to find out if there is a way around this requirement (to run the 
> code as root) but I may be stuck with it. :-(
> 
> I get a permission denied error related to the capemgr.9 if I don't run my 
> code as root.
> IOError: [Errno 13] Permission denied: '/sys/devices/bone_capmgr.9/slots'
> 
> John
> 
> On 4/17/2016 9:39 AM, Dennis Lee Bieber wrote:
>> On Sat, 16 Apr 2016 16:53:16 -0700 (PDT), John Baker
>>   
>> declaimed the
>> following:
>> 
>>> Hi Dieter,
>>> Still not working. I have a hunch that the problem is with Tkinter but 
>>> can't tell. I have to run my GUI program SimB.py with the terminal program 
>>> on the BBB, typing sudo python SimB.py, then it runs happily.
>>> 
>>  The key phrase is "GUI program".
>> 
>>> *Here's my crontab in /etc:*
>>> @reboot root /usr/bin/python /home/debian/Desktop/SimB.py
>>> * * * * * root /usr/bin/python /home/debian/Desktop/SimB.py
>>> 
>>  "cron" jobs do not have a console, much less a graphical session
>> manager.
>> 
>>> Apr 16 23:37:14 beaglebone /USR/SBIN/CRON[2292]: (CRON) info (No MTA 
>>> installed, discarding output)
>>> 
>>  You do not have local mail transfer agent (SMTPd or equivalent) so
>> whatever error trace cron was going to send is being dropped on the floor.
>> 
>>> 
>>> I can successfully run my program with a keyboard attached to my BBB using 
>>> sudo python SimB.py, have to use the sudo, otherwise gets a Tkinter error. 
>>> I just now double-checked and my GUI program SimB.py runs very happily. 
>>> Cannot run SimB.py thru putty as it gives the Tkinter error.
>>> 
>>  putty implies a text console connection -- unless you have an X-server
>> running on the computer AND have configured the login via putty to use the
>> computer X-server (environment variable for DISPLAY pointing to the
>> computer) there is no graphical environment in which to open the GUI
>> program.
>> 
>>  When using a direct keyboard/mouse and HDMI connection, the BBB is
>> running a local X-server and the (automatic) login is running a
>> desktop/window manager that connects to that X-server. Not sure why you'd
>> need the sudo -- Tkinter should be able to open a window from the account
>> that is running the session manager.
>> 
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/5713D4C9.8090005%40ieee.org 
> .
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/BDB95044-BDE7-478C-B276-15EA5707AE16%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Battery shutdown

[John Syne]

I’m not sure, but best place to look would be 
Documentation/power/regulator/charger-management.txt. I believe the PMIC issues 
event when AC is removed. 

Regards,
John




> On Apr 16, 2016, at 12:59 PM, William Hermans  wrote:
> 
> Also from what I've read this behavior is different between console and LXDE 
> images. So if this is true I understand that. I do not want the behaviors 
> that each of these images provides, but wish to customize my own.
> 
> 
> On Sat, Apr 16, 2016 at 12:55 PM, William Hermans  > wrote:
> When a battery is connected to a beaglebone black, how does the software know 
> to issue a shutdown when power is no longer coming in ? More specifically I'm 
> interested in which file / script performs this action, and what mechanism 
> triggers this behavior.
> 
> My intentions are to modify / customize what actually happens when power to 
> the board is battery only.
> 
> 
> 
> 
> 
> -- 
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/F27E94CA-369F-4E5D-8555-EEAD3B034C28%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Jessie Image fixed ethernet issue, but reverses SPI pins and device tree overlay does not help

[John Syne]

That is interesting. I haven’t seen that option before. 

Regards,
John




> On Apr 15, 2016, at 2:05 PM, Robert Nelson  wrote:
> 
> 
> 
> On Fri, Apr 15, 2016 at 3:19 PM,  > wrote:
> Hello,
> 
> I had posted yesterday about an issue with the ethernet not coming back after 
> you unplug the ethernet cable. I was recommended to upgrade to the Jessie 
> images as they use conman. This was great, it fixed my problem. 
> 
> But now I have another bug. The Rx/Tx pins on SPI1 seem to be flipped. 
> Attempting to modify this in the device tree overlay does not seem to work.
> 
> Does anyone else have this issue? Have you successfully been able to fix this 
> issue?
> 
> For me, I've already got hardware built. So at this point I can't work with 
> the pins being switched. But I need that ethernet bug fixed.
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/spi/omap-spi.txt?id=refs/tags/v4.6-rc3#n9
>  
> 
> 
> - ti,pindir-d0-out-d1-in: Select the D0 pin as output and D1 as
> input. The default is D0 as input and
> D1 as output.
> 
> 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 
> .

-- 
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] Eth0 doesn't work unless plugged in before boot, unplugging ethernet causes permanent disconnect

[John Syne]

That doesn’t make sense. The only place to swap MISO/MOSI is in the McSPI 
driver and that hasn’t changed. 

Regards,
John




> On Apr 15, 2016, at 1:23 PM, john.min...@jlmei.com wrote:
> 
> Hi Robert,
> 
> Updating to the Jessie image seems to solve the issue! Thank you for your 
> input!
> 
> But the Jessie image seems to have another bug that I can't seem to figure 
> out.
> 
> The Rx/Tx pins on SPI1 seem to be flipped. Attempting to modify this in the 
> device tree overlay does not seem to work.
> 
> I've already got hardware built. So at this point I can't work with the pins 
> being switched. But I need that ethernet bug fixed.
> 
> Any ideas?
> 
> Thank you!
> 
> 
> 
> On Thursday, April 14, 2016 at 12:55:10 PM UTC-7, RobertCNelson wrote:
> 
> 
> On Thu, Apr 14, 2016 at 2:10 PM,  wrote:
> Hello,
> 
> I work for an energy technology company, and we use Beaglebone Black's in our 
> product line. Over the last 2 years there has been a consistent trouble with 
> the ethernet port, and I wonder if there is a fix for this or if anyone else 
> is aware of it.
> 
> Running any of the Debian images from 2014 to present on a Beaglebone Black, 
> unless the ethernet cable is plugged in and connected to a network device 
> (switch, modem, etc) before powering on the beaglebone black it will not 
> connect to the network. It won't pull a DHCP address. It will not connect 
> with a static IP Address. And if the beaglebone is plugged into a network 
> switch and you power cycle the switch, connectivity seems to be permanently 
> lost until you also reboot the Beaglebone black. Alternatively, if you just 
> unplug the ethernet cable for 30 seconds to a minute, it will also loose 
> network connectivity.
> 
> Connected the Beaglebone Black to your PC via USB, and connect the Beaglebone 
> Black to an ethernet cable which runs to a network switch. You can ping 
> google, etc no problem the Beaglebone has internet connectivity. Disconnect 
> the ethernet cable, wait 30 seconds to a minute and reconnect the cable. The 
> beaglebone black will no longer connect to the internet. Bringing the 
> interface down and up again does not seem to fix the issue.
> 
> Sometimes this doesn't happen though. Sometimes different boards seem to work 
> no problem. So it confuses me, why do some boards work and others not?
> 
> There are situations where, like I deal with yesterday, at a clients house 
> they have a power outage. One of our beaglebone device are running off an 
> alternate battery-powered source and continues running no problem, but the 
> rest of the networking equipment looses power. When their power comes back 
> on, the networking stuff turns back on and the client is able to connect to 
> their wifi and surf the web without issue, but the Bealgebone refuses to 
> connect to the network or connect to our servers over the internet.
> 
> What is the cause of this bug? Is there a fix for it? Can the fix be remotely 
> implemented? Is it a relatively safe fix, or is there a substantial chance I 
> could brick the beaglebone?
> 
> Any help would be appreciated as I have pulled my hair out over this issue 
> for the last 2 years.
> 
> This should be fixed in the jessie image's (iot or lxqt) (NOT console) as the 
> iot/lxqt images have connman controlling eth0..
> 
> 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 
> .

-- 
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] BeagleBone PCB stackup

[John Syne]

I guess I should have scrolled up before answering this post.

Regards,
John




> On Apr 15, 2016, at 10:45 AM, Gerald Coley  wrote:
> 
> Power supply lines? Power supplies are power planes with a connection from 
> the pad to the plane using a via. 
> 
> Gerald
> 
> 
> On Fri, Apr 15, 2016 at 11:12 AM, Nick  > wrote:
> Hello gerald/forum
> 
> I had a look at BeagleBone_Black_RevB4_FAB.pdf
> in there i can see for the 50 ohm impedance signal with a track width of 4.75 
> on external layers and 5.25 on internal layers
> so does that mean power supply lines are also 4.75 track width on external 
> layer and 5.25 on internal layer
> 
> 
> Regards
> Nick
> 
> 
> 
> 
> On Wednesday, February 8, 2012 at 12:45:43 PM UTC, Gerald wrote:
> The layer stackup is already posted. It is included in PCB Files ZIP file. It 
> is in the form of a PDF file, beaglebone_revC1_PDF.zip.
>  
> http://circuitco.com/support/index.php?title=BeagleBone#Hardware_Files 
> 
>  
> Gerald
> 
> 
>  
> On Wed, Feb 8, 2012 at 6:19 AM, Gerald Coley > 
> wrote:
> I will post it for you in the next day or so.
>  
> Gerald
> 
> 
>  
> On Wed, Feb 8, 2012 at 2:00 AM, manatarms > 
> wrote:
> Dear All
> 
> Does someone have the stackup of the BeagleBone PCB? I couldn't find
> it on the hardware design page and it would help many people who want
> to do their own design.
> 
> --
> To join: http://beagleboard.org/discuss 
> To unsubscribe from this group, send email to:
> beagleboard...@googlegroups.com <>
> Frequently asked questions: http://beagleboard.org/faq 
> 
> 
> 
> 
> On Wednesday, February 8, 2012 at 12:45:43 PM UTC, Gerald wrote:
> The layer stackup is already posted. It is included in PCB Files ZIP file. It 
> is in the form of a PDF file, beaglebone_revC1_PDF.zip.
>  
> http://circuitco.com/support/index.php?title=BeagleBone#Hardware_Files 
> 
>  
> Gerald
> 
> 
>  
> On Wed, Feb 8, 2012 at 6:19 AM, Gerald Coley > 
> wrote:
> I will post it for you in the next day or so.
>  
> Gerald
> 
> 
>  
> On Wed, Feb 8, 2012 at 2:00 AM, manatarms > 
> wrote:
> Dear All
> 
> Does someone have the stackup of the BeagleBone PCB? I couldn't find
> it on the hardware design page and it would help many people who want
> to do their own design.
> 
> --
> To join: http://beagleboard.org/discuss 
> To unsubscribe from this group, send email to:
> beagleboard...@googlegroups.com <>
> Frequently asked questions: http://beagleboard.org/faq 
> 
> 
> 
> 
> -- 
> 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 
> .
> 
> 
> 
> -- 
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/ 
> gcol...@emprodesign.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] BeagleBone PCB stackup

[John Syne]

Power is supplied via power planes which are on layers 2 and 5.

Regards,
John




> On Apr 15, 2016, at 10:45 AM, Gerald Coley  wrote:
> 
> Power supply lines? Power supplies are power planes with a connection from 
> the pad to the plane using a via. 
> 
> Gerald
> 
> 
> On Fri, Apr 15, 2016 at 11:12 AM, Nick  > wrote:
> Hello gerald/forum
> 
> I had a look at BeagleBone_Black_RevB4_FAB.pdf
> in there i can see for the 50 ohm impedance signal with a track width of 4.75 
> on external layers and 5.25 on internal layers
> so does that mean power supply lines are also 4.75 track width on external 
> layer and 5.25 on internal layer
> 
> 
> Regards
> Nick
> 
> 
> 
> 
> On Wednesday, February 8, 2012 at 12:45:43 PM UTC, Gerald wrote:
> The layer stackup is already posted. It is included in PCB Files ZIP file. It 
> is in the form of a PDF file, beaglebone_revC1_PDF.zip.
>  
> http://circuitco.com/support/index.php?title=BeagleBone#Hardware_Files 
> 
>  
> Gerald
> 
> 
>  
> On Wed, Feb 8, 2012 at 6:19 AM, Gerald Coley > 
> wrote:
> I will post it for you in the next day or so.
>  
> Gerald
> 
> 
>  
> On Wed, Feb 8, 2012 at 2:00 AM, manatarms > 
> wrote:
> Dear All
> 
> Does someone have the stackup of the BeagleBone PCB? I couldn't find
> it on the hardware design page and it would help many people who want
> to do their own design.
> 
> --
> To join: http://beagleboard.org/discuss 
> To unsubscribe from this group, send email to:
> beagleboard...@googlegroups.com <>
> Frequently asked questions: http://beagleboard.org/faq 
> 
> 
> 
> 
> On Wednesday, February 8, 2012 at 12:45:43 PM UTC, Gerald wrote:
> The layer stackup is already posted. It is included in PCB Files ZIP file. It 
> is in the form of a PDF file, beaglebone_revC1_PDF.zip.
>  
> http://circuitco.com/support/index.php?title=BeagleBone#Hardware_Files 
> 
>  
> Gerald
> 
> 
>  
> On Wed, Feb 8, 2012 at 6:19 AM, Gerald Coley > 
> wrote:
> I will post it for you in the next day or so.
>  
> Gerald
> 
> 
>  
> On Wed, Feb 8, 2012 at 2:00 AM, manatarms > 
> wrote:
> Dear All
> 
> Does someone have the stackup of the BeagleBone PCB? I couldn't find
> it on the hardware design page and it would help many people who want
> to do their own design.
> 
> --
> To join: http://beagleboard.org/discuss 
> To unsubscribe from this group, send email to:
> beagleboard...@googlegroups.com <>
> Frequently asked questions: http://beagleboard.org/faq 
> 
> 
> 
> 
> -- 
> 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 
> .
> 
> 
> 
> -- 
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/ 
> gcol...@emprodesign.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] track width of external/internal layer

[John Syne]

Unless you are using the same PCB material and manufacturer, you should ask 
your PCB manufacturer. Even the PCB manufacturing process can bring about 
impedance changes. That is why the PCB manufacturer includes a impedance token 
to test the impedance and then adjust their plating/edging time.   

Regards,
John




> On Apr 15, 2016, at 9:23 AM, Nick  wrote:
> 
> 
> Dear BeagleBoard
> 
> I have a Beaglebone black hardware and have few question regarding the same 
> in some document i found the layer stack up dimension in mils it is mistyped 
> as inched anyway. 
>  
> 
> does this track width (50ohm single ended impedance control) marked in red 
> represent all signal lines like spi,i2c,uart, gpio including power lines in 
> which case the track width of power line is also 4.75 mils on external layer 
> and 5.25 miles on internal layers ? 
> Regards
> Nick
> 
> -- 
> 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] I saw an AudioCape ALSA config file in a repo somewhere

[John Syne]

Long time since I worked on alsa, but here is what I recall. 

I think it stores to /var/lib/alsa/asound.state

Use alsamixer in a ssh terminal as this is easier to use compared to amixer.

You can also do:

sudo alsactl store

Which I believe stores in /etc/asound.state

Regards,
John




> On Apr 14, 2016, at 3:14 PM, Rick Mann  wrote:
> 
> I can't remember where I saw it, but it was a kernel-related BeagleBone Black 
> repo. There was a config file (maybe amixer?) for use with the AudioCape.
> 
> Robert, do you know what I'm remembering and where it is?
> 
> -- 
> 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.

-- 
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] High rate serial data communication question

[John Syne]

> On Apr 10, 2016, at 9:52 AM, William Hermans <yyrk...@gmail.com> wrote:
> 
> #1 SPI has no slave mode driver in the kernel, so SPI( including mcSPI ) is 
> out of the question.
See my previous answer on supporting McSPI slave mode.
> #2 McSPI is limited to 16Mhz in the current kernel config, So one would have 
> to figure out how to modify that.
I take your word for this as I haven’t looked into this. Not sure why the 
limit, because McASP driver does use DMA.
> #3 I've read, and I can not remember where that the McSPI interface is 
> actually far faster than 48Mhz.
I think you are correct, because I believe the AM3358 can support more than one 
data line, which is what the MMC uses. 
> #4 3Mbit is max speed for the UART if I recall correctly.
> 
> In terms of raw speed, the USB interface *can* be about 10% faster than 
> ethernet when used as an ethernet gadget interface.
> 
> On Sun, Apr 10, 2016 at 9:35 AM, evilwulfie <evilwul...@gmail.com 
> <mailto:evilwul...@gmail.com>> wrote:
> That's still only 1/2 of what he wants.
> 
> raw parallel data not faster ?
> 
> 
> On 4/10/2016 9:30 AM, John Syne wrote:
>> Oh, and SPI can run up to 48Mbps.
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 10, 2016, at 9:23 AM, evilwulfie < 
>>> <mailto:evilwul...@gmail.com>evilwul...@gmail.com 
>>> <mailto:evilwul...@gmail.com>> wrote:
>>> 
>>> high speed I2C  : 3,2 Mbit/s
>>> 
>>> SPI  UP TO 10 Mbps
>>> 
>>> UART SERIAL   921600  <--- I think the highest serial rate
>>> 
>>> So it looks like SPI is your highest data rate other than ethernet.
>>> 
>>> I Am not so sure that the BBB can keep with both interfaces saturated.
>>> 
>>> But only further testing will see if that is the case
>>> 
>>> I cant see any way to get 8MB on any of the other interfaces.
>>> 
>>> Maybe raw parallel data between the BBBs using GPIO pins.  
>>> 
>>> 
>>> 
>>> On 4/9/2016 7:23 PM, john.w...@triangleexperience.com 
>>> <mailto:john.w...@triangleexperience.com> wrote:
>>>> 
>>>> If I had two BBB devices sitting right next to each other, what would be 
>>>> the fastest way to send data from one to the other--excluding Ethernet?
>>>> 
>>>> Specifically, I'd like to be able to:
>>>> 
>>>> Read data in from one BBB Ethernet port, send the data (unidirectionally) 
>>>> from one BBB to the other.
>>>> Examine the data on the receiving BBB, looking for key words and deleting 
>>>> them.
>>>> And then send the modified data back out via the Ethernet port on the 
>>>> second/receiving BBB.
>>>> To keep up with the 100Mb/s Ethernet pipe, I'd like to see  data rates in 
>>>> the 8MByte/s range.
>>>> 
>>>> 
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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] High rate serial data communication question

[John Syne]

> On Apr 10, 2016, at 9:46 AM, evilwulfie <evilwul...@gmail.com> wrote:
> 
> Well my guru friend on the BBB software side said that the best way would be 
> USB to USB on 2 beagle bones
Given that USB2 is 480Mbps, this might be the fastest interface, but given the 
overhead of the USB protocol, you might get 100Mbps if you are lucky. 
> 
> seems its as fast as the ethernet connection
> 
> Running Ethernet over USB
> 
> He also told me there is no slave driver for spi in the Linux kernel so thats 
> a no go.
Yep, you are correct, but if you do not use the SPI framework, it is pretty 
simple to create a slave SPI driver using DMA. A few days ago, I had a 
discussion with another developer who said he managed to modify the McSPI 
driver to support SPI slave mode using callbacks.

Regards,
John
> 
> 
> On 4/10/2016 9:30 AM, John Syne wrote:
>> Oh, and SPI can run up to 48Mbps.
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 10, 2016, at 9:23 AM, evilwulfie < 
>>> <mailto:evilwul...@gmail.com>evilwul...@gmail.com 
>>> <mailto:evilwul...@gmail.com>> wrote:
>>> 
>>> high speed I2C  : 3,2 Mbit/s
>>> 
>>> SPI  UP TO 10 Mbps
>>> 
>>> UART SERIAL   921600  <--- I think the highest serial rate
>>> 
>>> So it looks like SPI is your highest data rate other than ethernet.
>>> 
>>> I Am not so sure that the BBB can keep with both interfaces saturated.
>>> 
>>> But only further testing will see if that is the case
>>> 
>>> I cant see any way to get 8MB on any of the other interfaces.
>>> 
>>> Maybe raw parallel data between the BBBs using GPIO pins.  
>>> 
>>> 
>>> 
>>> On 4/9/2016 7:23 PM, john.w...@triangleexperience.com 
>>> <mailto:john.w...@triangleexperience.com> wrote:
>>>> 
>>>> If I had two BBB devices sitting right next to each other, what would be 
>>>> the fastest way to send data from one to the other--excluding Ethernet?
>>>> 
>>>> Specifically, I'd like to be able to:
>>>> 
>>>> Read data in from one BBB Ethernet port, send the data (unidirectionally) 
>>>> from one BBB to the other.
>>>> Examine the data on the receiving BBB, looking for key words and deleting 
>>>> them.
>>>> And then send the modified data back out via the Ethernet port on the 
>>>> second/receiving BBB.
>>>> To keep up with the 100Mb/s Ethernet pipe, I'd like to see  data rates in 
>>>> the 8MByte/s range.
>>>> 
>>>> I'd love to hear even the most bizarre suggestions...
>>>> 
>>>> 
>>>> VR/John
>>>> -- 
>>>> For more options, visit http://beagleboard.org/discuss 
>>>> <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  
>>>> <mailto:beagleboard+unsubscr...@googlegroups.com>beagleboard+unsubscr...@googlegroups.com
>>>>  <mailto:beagleboard+unsubscr...@googlegroups.com>.
>>>> For more options, visit https://groups.google.com/d/optout 
>>>> <https://groups.google.com/d/optout>.
>>> 
>>> 
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss 
>>> <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 
>>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>>> For more options, visit https://groups.google.com/d/optout 
>>> <https://groups.google.com/d/optout>.
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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] High rate serial data communication question

[John Syne]

Oh, and SPI can run up to 48Mbps.

Regards,
John




> On Apr 10, 2016, at 9:23 AM, evilwulfie  wrote:
> 
> high speed I2C  : 3,2 Mbit/s
> 
> SPI  UP TO 10 Mbps
> 
> UART SERIAL   921600  <--- I think the highest serial rate
> 
> So it looks like SPI is your highest data rate other than ethernet.
> 
> I Am not so sure that the BBB can keep with both interfaces saturated.
> 
> But only further testing will see if that is the case
> 
> I cant see any way to get 8MB on any of the other interfaces.
> 
> Maybe raw parallel data between the BBBs using GPIO pins.  
> 
> 
> 
> On 4/9/2016 7:23 PM, john.w...@triangleexperience.com 
>  wrote:
>> 
>> If I had two BBB devices sitting right next to each other, what would be the 
>> fastest way to send data from one to the other--excluding Ethernet?
>> 
>> Specifically, I'd like to be able to:
>> 
>> Read data in from one BBB Ethernet port, send the data (unidirectionally) 
>> from one BBB to the other.
>> Examine the data on the receiving BBB, looking for key words and deleting 
>> them.
>> And then send the modified data back out via the Ethernet port on the 
>> second/receiving BBB.
>> To keep up with the 100Mb/s Ethernet pipe, I'd like to see  data rates in 
>> the 8MByte/s range.
>> 
>> I'd love to hear even the most bizarre suggestions...
>> 
>> 
>> VR/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 
> .

-- 
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] High rate serial data communication question

[John Syne]

The fastest interface would be McASP which can clock at 50MHz and with four 
channels channels will give you just under 200Mbps.

Regards,
John




> On Apr 10, 2016, at 9:23 AM, evilwulfie  wrote:
> 
> high speed I2C  : 3,2 Mbit/s
> 
> SPI  UP TO 10 Mbps
> 
> UART SERIAL   921600  <--- I think the highest serial rate
> 
> So it looks like SPI is your highest data rate other than ethernet.
> 
> I Am not so sure that the BBB can keep with both interfaces saturated.
> 
> But only further testing will see if that is the case
> 
> I cant see any way to get 8MB on any of the other interfaces.
> 
> Maybe raw parallel data between the BBBs using GPIO pins.  
> 
> 
> 
> On 4/9/2016 7:23 PM, john.w...@triangleexperience.com 
>  wrote:
>> 
>> If I had two BBB devices sitting right next to each other, what would be the 
>> fastest way to send data from one to the other--excluding Ethernet?
>> 
>> Specifically, I'd like to be able to:
>> 
>> Read data in from one BBB Ethernet port, send the data (unidirectionally) 
>> from one BBB to the other.
>> Examine the data on the receiving BBB, looking for key words and deleting 
>> them.
>> And then send the modified data back out via the Ethernet port on the 
>> second/receiving BBB.
>> To keep up with the 100Mb/s Ethernet pipe, I'd like to see  data rates in 
>> the 8MByte/s range.
>> 
>> I'd love to hear even the most bizarre suggestions...
>> 
>> 
>> VR/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 
> .

-- 
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] looking for speed backup/restore of bbb emmc

[John Syne]

Well, think about what is different about your SDCard image vs the original 
SDCard image you started with. Make a note of the image you used to create your 
SDCard, and then backup your working SDCard with rsync:

sudo rsync -av /media//rootfs/ ~/sdcardbackup/rootfsV4.1.6/

Now when you need a new SDCard from your backup, use the same image to create a 
new SDCard as you did before and then restore from your backup using rsync:

sudo rsync -av ~/sdcardbackup/rootfsV4.1.6/ /media//rootfs/

This will only copy the changes you made to the original SDCard image. 

Regards,
John




> On Apr 8, 2016, at 12:32 AM, toni  wrote:
> 
> Hi,
> 
> I've done some image flashing and appreciate 
> beaglebone-black-make-microSD-flasher-from-eMMC.sh and the speed  of the 
> bmaptool. I use dd to backup the image sd to to local disk. This will cp the 
> full size of the sd even if only a part is used. Is there an easy way to make 
> a cp of the sd image without cp'ing the whole sd can be 4 - 32 GB).
> 
> As I understand beaglebone-black-make-microSD-flasher-from-eMMC.sh not only 
> creates 2 partitions of the std. (emmc) image but also cp's the bootloader. 
> So cp of the partitions is not sufficient?
> 
> Booting from sd will a direct dd emmc to nfs and vice versa work? Still cp 
> too much then. And no speedup of bmaptool.
> 
> I had 2 times kernel errors during startup after image restore which were 
> resolved after running updatebootloader script. Apparently the cp of uboot 
> isn't flawless for old 2014 versions (but still boots!)? Sorry no details but 
> using a mix of a5c, c and bbg with images from aug 2014 3.14-ti till recent.
> 
> 
> -- 
> 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] Altium file set for the Beaglebone?

[John Syne]

You need to export the Allegro files in ascii format and then Altium can import 
those files. Copper pours and other polygons have to be redone because the 
import creates hundreds of edges for each polygon. Also, some of the parts have 
to be fixed. Synchronize the schematic with PCB in Altium and then generate 
gerber files which you can compare to the gerber files from BeagleBone. The can 
be an iterative effort, fixing PCB items and then regenerating gerber files. 
Count on a few days effort to get this done. I normally add 3D rendering to all 
the parts and then generate a Solidworks 3D view of the complete PCB. 

Regards,
John




> On Apr 7, 2016, at 2:35 AM, hieutran...@gmail.com wrote:
> 
> Can you help me convert LDCK from alegro Orcad to Altium files
> 
> -- 
> 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] Source-level single-stepping kernel code on BBB?

[John Syne]

Reviewing my previous work, the two package you need are:

alsa-lib
alsa-utils

apt-get source alsa-utils
cd alsa-utils-1.0.25
export DEB_BUILD_OPTIONS=“nostrip noopt debug"
dpkg-buildpackage -rfakeroot -uc -us
make
make install

or 
dpkg -i libasound2*.deb


or
apt-get install libasound2-dbg
apt-get install libasound2.dev

Anyway, as I said I did this a long time ago, so some of this could be wrong.

Regards,
John




> On Apr 6, 2016, at 6:49 PM, Robert Nelson  wrote:
> 
> 
> 
> On Wed, Apr 6, 2016 at 8:44 PM, Rick Mann  > wrote:
> That looks like something that would be useful to figure out how to do. The 
> only part that's not immediately clear is "rebuild the entire ALSA library 
> and tools with debug symbols. Also, your Kernel must have debug symbols 
> turned on."
> 
> Can I do this with RCN's kernel build script setup?
> 
> yeah, double check your kernel's version (uname -r) grab the "yakbuild"
> 
> https://github.com/RobertCNelson/yakbuild 
> 
> 
> follow the readme.md , picking a version of gcc and 
> setting the kernel tag you want to build..
> 
> Run:
> 
> ./build_kernel.sh
> 
> when menuconfig pop's up, enable CONFIG_DEBUG_INFO...
> 
> Kernel Hacking -> Compile-Time checks and compiler options -> [x] Compile the 
> kernel with debug info "CONFIG_DEBUG_INFO"
> 
> 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 
> .

-- 
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] Source-level single-stepping kernel code on BBB?

[John Syne]

I did this years ago. From what I can find, I believe this is how you get this 
done:

sudo apt-get build-dep libasound2
apt-get source libasound2
cd alsa-lib-1.0.22/
export DEB_BUILD_OPTIONS=nostrip,noopt
dpkg-buildpackage -rfakeroot -uc -us

After that, you will have some *.deb files created, which can be installed 
using:

dpkg -i libasound*.deb

The you have to do the same with alsa-tools.


Regards,
John




> On Apr 6, 2016, at 6:44 PM, Rick Mann <rm...@latencyzero.com> wrote:
> 
> That looks like something that would be useful to figure out how to do. The 
> only part that's not immediately clear is "rebuild the entire ALSA library 
> and tools with debug symbols. Also, your Kernel must have debug symbols 
> turned on."
> 
> Can I do this with RCN's kernel build script setup?
> 
> Thanks.
> 
>> On Apr 6, 2016, at 18:05 , John Syne <john3...@gmail.com> wrote:
>> 
>> OK, so you have to rebuild the entire ALSA library and tools with debug 
>> symbols. Also, your Kernel must have debug symbols turned on. You will need 
>> to enable various ftrace features with make config. Here is a typical script 
>> I use to capture program flow.
>> 
>> 
>> ===
>> #!/bin/bash
>> set -x
>> 
>> pause() {
>> local dummy
>> read -s -r -p "Press any key to continue..." -n 1 dummy
>> }
>> 
>> echo function_graph > /sys/kernel/debug/tracing/current_tracer
>> #echo function > /sys/kernel/debug/tracing/current_tracer
>> echo 10 > /sys/kernel/debug/tracing/buffer_size_kb
>> echo function-trace > /sys/kernel/debug/tracing/trace_options
>> echo latency-format > /sys/kernel/debug/tracing/trace_options
>> echo graph-time > /sys/kernel/debug/tracing/trace_options
>> echo funcgraph-tail > /sys/kernel/debug/tracing/trace_options
>> echo funcgraph-proc > /sys/kernel/debug/tracing/trace_options
>> echo funcgraph-abstime > /sys/kernel/debug/tracing/trace_options
>> #echo __do_fault > /sys/kernel/debug/tracing/set_graph_function
>> echo 1 > /sys/kernel/debug/tracing/tracing_on
>> 
>> #Insure modprobe statements here if you want to trace the kernel module at 
>> startup 
>> 
>> aplay command
>> 
>> #Uninstall Kernel module here
>> 
>> echo 0 > /sys/kernel/debug/tracing/tracing_on
>> 
>> #cat /sys/kernel/debug/tracing/trace_pipe |grep  | grep -v 
>> "" | grep -v "" > test-trace.txt
>> #cat /sys/kernel/debug/tracing/trace_pipe | sed -n '//p' | sed 
>> '//d' > test-1-trace.txt
>> cat /sys/kernel/debug/tracing/trace_pipe > test-2-trace.txt
>> ===
>> 
>> Place this script in your BBB /home/debian folder, then as root, execute 
>> ./trace.sh
>> 
>> Finally, I index the entire linux kernel using a variation of these 
>> instructions:
>> 
>> https://wiki.eclipse.org/HowTo_use_the_CDT_to_navigate_Linux_kernel_source
>> 
>> To speed things up, you must filter out all the code from other processor 
>> architectures and drivers you don’t use. 
>> 
>> Now I can ctrl click on any term to trace the flow I get from ftrace. For 
>> something this complex, I tend to diagram the flow with a mind map or 
>> something similar. The visual layout helps me understand the framework 
>> architecture. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 6, 2016, at 5:45 PM, Rick Mann <rm...@latencyzero.com> wrote:
>>> 
>>> 
>>>> On Apr 6, 2016, at 16:53 , Peter Hurley <pe...@hurleysoftware.com> wrote:
>>>> 
>>>> If this is a latency problem, ftrace is probably your best bet, but
>>>> function_graph and the other tracers can induce even more latency.
>>> 
>>> Nothing so esoteric. I'm just trying to get the damn thing to work at all. 
>>> It's worked in previous kernels, but not in the latest. Seeing what code 
>>> gets executed will help a lot. But I'm currently stuck with the default 
>>> diagnostics available (e.g. "Unable to set hw params for playback: Invalid 
>>> argument" NOT HELPFUL).
>>> 
>>> In the past, when I spent so much time with printk, I was trying to 
>>> understand how all the modules worked together to actually configure and 
>>> drive the CODEC. I found that to be virtually impossible to do in any 
>>> comprehensive way, not already understanding it. Can't use printk() if you 
>>> don't know where to put it.
>>> 
>>> 
>>> -- 
>>> Rick Mann
>>> rm...@latencyzero.com
>>

Re: [beagleboard] Source-level single-stepping kernel code on BBB?

[John Syne]

OK, so you have to rebuild the entire ALSA library and tools with debug 
symbols. Also, your Kernel must have debug symbols turned on. You will need to 
enable various ftrace features with make config. Here is a typical script I use 
to capture program flow.


===
#!/bin/bash
set -x

pause() {
  local dummy
  read -s -r -p "Press any key to continue..." -n 1 dummy
}

echo function_graph > /sys/kernel/debug/tracing/current_tracer
#echo function > /sys/kernel/debug/tracing/current_tracer
echo 10 > /sys/kernel/debug/tracing/buffer_size_kb
echo function-trace > /sys/kernel/debug/tracing/trace_options
echo latency-format > /sys/kernel/debug/tracing/trace_options
echo graph-time > /sys/kernel/debug/tracing/trace_options
echo funcgraph-tail > /sys/kernel/debug/tracing/trace_options
echo funcgraph-proc > /sys/kernel/debug/tracing/trace_options
echo funcgraph-abstime > /sys/kernel/debug/tracing/trace_options
#echo __do_fault > /sys/kernel/debug/tracing/set_graph_function
echo 1 > /sys/kernel/debug/tracing/tracing_on

#Insure modprobe statements here if you want to trace the kernel module at 
startup 

aplay command

#Uninstall Kernel module here

echo 0 > /sys/kernel/debug/tracing/tracing_on

#cat /sys/kernel/debug/tracing/trace_pipe |grep  | grep -v 
"" | grep -v "" > test-trace.txt
#cat /sys/kernel/debug/tracing/trace_pipe | sed -n '//p' | sed '//d' > test-1-trace.txt
cat /sys/kernel/debug/tracing/trace_pipe > test-2-trace.txt
===

Place this script in your BBB /home/debian folder, then as root, execute 
./trace.sh

Finally, I index the entire linux kernel using a variation of these 
instructions:

https://wiki.eclipse.org/HowTo_use_the_CDT_to_navigate_Linux_kernel_source

To speed things up, you must filter out all the code from other processor 
architectures and drivers you don’t use. 

Now I can ctrl click on any term to trace the flow I get from ftrace. For 
something this complex, I tend to diagram the flow with a mind map or something 
similar. The visual layout helps me understand the framework architecture. 

Regards,
John




> On Apr 6, 2016, at 5:45 PM, Rick Mann  wrote:
> 
> 
>> On Apr 6, 2016, at 16:53 , Peter Hurley  wrote:
>> 
>> If this is a latency problem, ftrace is probably your best bet, but
>> function_graph and the other tracers can induce even more latency.
> 
> Nothing so esoteric. I'm just trying to get the damn thing to work at all. 
> It's worked in previous kernels, but not in the latest. Seeing what code gets 
> executed will help a lot. But I'm currently stuck with the default 
> diagnostics available (e.g. "Unable to set hw params for playback: Invalid 
> argument" NOT HELPFUL).
> 
> In the past, when I spent so much time with printk, I was trying to 
> understand how all the modules worked together to actually configure and 
> drive the CODEC. I found that to be virtually impossible to do in any 
> comprehensive way, not already understanding it. Can't use printk() if you 
> don't know where to put it.
> 
> 
> -- 
> 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.

-- 
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] Source-level single-stepping kernel code on BBB?

[John Syne]

> On Apr 6, 2016, at 5:27 PM, 'Mark Lazarewicz' via BeagleBoard 
>  wrote:
> 
> If it's a company project the Lauterbach is well worth the money 
Definitely. Lauterbach is one of my favorite tools and I cannot imagine doing 
some work without it. It is a difficult tool to learn, but it is very powerful. 
I’m sure I don’t use 90% of the features available. Best part, it is so fast 
for a JTAG debugger. 

Regards,
John
> 
> Sent from Yahoo Mail on Android 
> 
> On Wed, Apr 6, 2016 at 5:56 PM, Rick Mann
>  wrote:
> What would I need to get/do to enable me to single-step through kernel code 
> on BBB/G? JTAG header, some kind of interface, and a bunch of software 
> installed on Ubuntu? Can anyone make specific recommendations? Is it even 
> possible?
> 
> 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.
> 
> -- 
> 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] Source-level single-stepping kernel code on BBB?

[John Syne]

> On Apr 6, 2016, at 4:53 PM, Peter Hurley  wrote:
> 
> On 04/06/2016 02:56 PM, Rick Mann wrote:
>> What would I need to get/do to enable me to single-step through
>> kernel code on BBB/G? JTAG header, some kind of interface, and a
>> bunch of software installed on Ubuntu? Can anyone make specific
>> recommendations? Is it even possible?
> 
> On 04/06/2016 03:34 PM, Rick Mann wrote:
>> Thanks, John. I've tried printk and other logging, but it's virtually
>> impossible to trace something like audio, which spans many modules.
> 
> If this is a latency problem, ftrace is probably your best bet, but
> function_graph and the other tracers can induce even more latency.
My main purpose for using function_graph option was to understand program flow, 
so latency wasn’t an issue for me. I haven’t had any latency issues with my 
drivers, so I haven’t used the latency tracers that much. Mostly I use them to 
measure interrupt latency of the kernel. Other than that, my Lauterbach 
debugger gives me ns timing resolution in the trace buffer. 
> 
> I've had to write my own latency tracer on occasion to measure
> specific code paths (most recently with UART DMA timeouts from
> softirq latency). I cribbed the basic functionality from the
> irqsoff tracer; let me know if that's something you'd find useful.
> 
> If you really need to single-step, KGDB can be made to work but
> there are some limitations, the most crucial being that kgdboc
> runs over the console so you can't debug earlier than when the
> built-in 8250 driver probes. That's like 3 secs into boot so lots
> of init has already happened.
I’m wondering if late init might work for the driver you want to debug? I 
haven’t tried this, but maybe this is a workaround for this issue. 
> 
> FWIW, I did push an earlycon OMAP bootconsole for v4.6 but -rc2
> is early days, and there's already been one problem with
> MMC block device numbering. But if you're desperate and don't
> have access to JTAG, earlycon does printk() output from even
> before page table setup up to console initialization.
> 
> Regards,
> Peter Hurley
> 
> -- 
> 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] Source-level single-stepping kernel code on BBB?

[John Syne]

For audio, your best solution is ftrace. If you use function_graph option, then 
you can see the hierarchy of the call sequence. You can also use trace_printk 
to display variables at specific locations. 

BTW, Lauterbach is about $5K investment for the base tool with USB3 connection. 
You might be able to get something less expensive on eBay, but I doubt if you 
can get anything less than $1.5. 

Regards,
John




> On Apr 6, 2016, at 3:34 PM, Rick Mann <rm...@latencyzero.com> wrote:
> 
> Thanks, John. I've tried printk and other logging, but it's virtually 
> impossible to trace something like audio, which spans many modules.
> 
> I'll look into Lauterbach.
> 
>> On Apr 6, 2016, at 15:31 , John Syne <john3...@gmail.com> wrote:
>> 
>> You can do this with CCSV6 with a USB200 JTAG adapter, but CCSV6 is no 
>> longer kernel aware. CCSV4 was kernel aware, but won’t work with the current 
>> kernels. You can still debug with single stepping, software and hardware 
>> breakpoints, read/write memory, etc. Trying to debug a kernel module without 
>> a kernel aware debugger is very difficult. Since you don’t know the load 
>> address of the KM, it is difficult to set a breakpoint on INIT or probe. 
>> Best to make the driver a kernel builtin so that you can break on the start 
>> of the driver. 
>> 
>> For the most part, most kernel developers use printk to display status at 
>> strategic locations in their driver. Also, ftrace and dynamic trace tools 
>> are very useful. Read Documentation/trace on how to use these tools. They 
>> are very powerful. I have never use KDBG, but that is another solution that 
>> might work.
>> 
>> I use Lauterbach, which is like the gold standard for Kernel debugging and 
>> it is kernel aware and has a trace buffer. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 6, 2016, at 2:56 PM, Rick Mann <rm...@latencyzero.com> wrote:
>>> 
>>> What would I need to get/do to enable me to single-step through kernel code 
>>> on BBB/G? JTAG header, some kind of interface, and a bunch of software 
>>> installed on Ubuntu? Can anyone make specific recommendations? Is it even 
>>> possible?
>>> 
>>> 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.
>> 
>> -- 
>> 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 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.

-- 
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] Source-level single-stepping kernel code on BBB?

[John Syne]

You can do this with CCSV6 with a USB200 JTAG adapter, but CCSV6 is no longer 
kernel aware. CCSV4 was kernel aware, but won’t work with the current kernels. 
You can still debug with single stepping, software and hardware breakpoints, 
read/write memory, etc. Trying to debug a kernel module without a kernel aware 
debugger is very difficult. Since you don’t know the load address of the KM, it 
is difficult to set a breakpoint on INIT or probe. Best to make the driver a 
kernel builtin so that you can break on the start of the driver. 

For the most part, most kernel developers use printk to display status at 
strategic locations in their driver. Also, ftrace and dynamic trace tools are 
very useful. Read Documentation/trace on how to use these tools. They are very 
powerful. I have never use KDBG, but that is another solution that might work.

I use Lauterbach, which is like the gold standard for Kernel debugging and it 
is kernel aware and has a trace buffer. 

Regards,
John




> On Apr 6, 2016, at 2:56 PM, Rick Mann  wrote:
> 
> What would I need to get/do to enable me to single-step through kernel code 
> on BBB/G? JTAG header, some kind of interface, and a bunch of software 
> installed on Ubuntu? Can anyone make specific recommendations? Is it even 
> possible?
> 
> 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.

-- 
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] Finding GPIO3_21 on the BBB schematic

[John Syne]

You are correct. The caption on P3 is incorrect. McASP0 is connected to R167, 
U5 Pin A14 and P9 Pin 25

Regards,
John




> On Apr 5, 2016, at 7:14 PM, Rick Mann  wrote:
> 
> I'm looking at a schematic dated Mar 21, 2014, rev C. I'm trying to find 
> where the McASP0 external clock generator, on page 3, goes. It references pp. 
> 6, 10, and 11, but I can only find it on p.4 (which references only p. 11), 
> and p. 11, P9 header, pin 25 (which references only p. 4).
> 
> 
> -- 
> 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.

-- 
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] PRU configure and basic test not working

[John Syne]

That should read

> With TI attempting to mainline all it’s driver code we don’t expect to see 
> many of the problems like your in the future

Regards,
John




> On Apr 5, 2016, at 5:41 PM, John Syne <john3...@gmail.com> wrote:
> 
> So if you cannot do it, then you want another volunteer to do for you? We are 
> all in the same boat as you, and we all do our part, but simply complaining 
> about the situation without first trying to improve the situation isn’t 
> helpful. 
> 
> Previously, you mentioned Raspberry Pi, which for the most part uses the same 
> kernel and Debian FS as BBB, so any documentation that applies to Raspberry 
> Pi also applies to BBB. 
> 
> The real turmoil started with the transition from the V3 Kernel to the V4 
> kernel with the abandonment of the board file and the transition to the 
> DeviceTree. With TI attempting to mainline all it’s driver code we expect to 
> see many of the problems like your in the future. Packages for the most part 
> should work out of the box.
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 5, 2016, at 4:53 PM, Wally Bkg <wb666gre...@gmail.com 
>> <mailto:wb666gre...@gmail.com>> wrote:
>> 
>> I understand this.  I'm only stating my observations.  Kind of hard to "step 
>> up" and document something if the instructions won't work after another 
>> release or two.
>> 
>> If I find an answer I follow up so that a Google search that finds the 
>> problem might also find my solution (if any).  But fact of the matter, 
>> unless Robert or Jason come in with an answer, there usually isn't one.
>> 
>> When I broke the 2016-03-27 node-red by doing an npm install of 
>> node-red-node-beaglebone, I followed up in my thread that I'd got it working 
>> again with npm uninstall and apt-get purge & apt-get install 
>> bb-node-red-installer.   But it'd have been far more productive if the 
>> "notes" about the 2016-03-27 image had said node-red-node-beaglebone was 
>> broken despite node-red running "out of the box".
>> 
>> 
>> 
>> On Tuesday, April 5, 2016 at 12:27:09 PM UTC-5, john3909 wrote:
>> Here is what you need to understand about people on this list. There are no 
>> “developers" on this list. No one on this mailing list is paid by 
>> BeagleBoard. We are all volunteers, including Robert Nelson. If you have a 
>> problem with Documentation, then why don’t you create it so others can 
>> learn. If you need help with getting the info you need, we are all prepared 
>> to help. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Apr 5, 2016, at 9:57 AM, Wally Bkg <wb666...@ <>gmail.com 
>>> <http://gmail.com/>> wrote:
>>> 
>>> 
>>> I think the output of uname -a  for your kernel version is more helpful 
>>> than the Debian version which is running when it comes to overlays, 
>>> modules, and Beaglebone hardware specific issues.
>>> 
>>> I'm subscribing to this thread, as you are doing what I've planned to do in 
>>> the not too distant future, so I'm really interested in what the solutions 
>>> are to your problems here.
>>> 
>>> The Beaglebone development is fast and furious, which is good, but the 
>>> developers don't seem to give a hoot if changes break what little 
>>> documentation is out there, which IMHO makes the BB a rather poor choice 
>>> for newbies.   
>>> 
>>> I've posted a fair amount about Bonescript issues because I'm trying to 
>>> help a friend get started with an automation project for a solar powered, 
>>> off-grid, hydroponic green-house.  He needs some A/D or I'd have 
>>> recommended a Rasperry Pi2 from the start, but if things don't fall into 
>>> place soon I'll just buy him a Pi Hat that has A/D and give it to him along 
>>> with one of my RiP2 boards as the frustration factor is really turning me 
>>> off.   Without me helping him, he'd already have tossed the BB in the trash 
>>> and did the best he could with timers and relays, which he totally 
>>> understands -- but he was looking to get creative with some of his control 
>>> ideas that he clearly sees as difficult to do without a computer.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Tuesday, April 5, 2016 at 10:22:36 AM UTC-5, Le Costaouec Vincent wrote:
>>> 
>>> I forgot to indicate the release on which I'm working on :  
>>> #  lsb_release -da
>>> 
>>> Distributor ID:Debian
>>> Description:   

Re: [beagleboard] PRU configure and basic test not working

[John Syne]

So if you cannot do it, then you want another volunteer to do for you? We are 
all in the same boat as you, and we all do our part, but simply complaining 
about the situation without first trying to improve the situation isn’t 
helpful. 

Previously, you mentioned Raspberry Pi, which for the most part uses the same 
kernel and Debian FS as BBB, so any documentation that applies to Raspberry Pi 
also applies to BBB. 

The real turmoil started with the transition from the V3 Kernel to the V4 
kernel with the abandonment of the board file and the transition to the 
DeviceTree. With TI attempting to mainline all it’s driver code we expect to 
see many of the problems like your in the future. Packages for the most part 
should work out of the box.

Regards,
John




> On Apr 5, 2016, at 4:53 PM, Wally Bkg  wrote:
> 
> I understand this.  I'm only stating my observations.  Kind of hard to "step 
> up" and document something if the instructions won't work after another 
> release or two.
> 
> If I find an answer I follow up so that a Google search that finds the 
> problem might also find my solution (if any).  But fact of the matter, unless 
> Robert or Jason come in with an answer, there usually isn't one.
> 
> When I broke the 2016-03-27 node-red by doing an npm install of 
> node-red-node-beaglebone, I followed up in my thread that I'd got it working 
> again with npm uninstall and apt-get purge & apt-get install 
> bb-node-red-installer.   But it'd have been far more productive if the 
> "notes" about the 2016-03-27 image had said node-red-node-beaglebone was 
> broken despite node-red running "out of the box".
> 
> 
> 
> On Tuesday, April 5, 2016 at 12:27:09 PM UTC-5, john3909 wrote:
> Here is what you need to understand about people on this list. There are no 
> “developers" on this list. No one on this mailing list is paid by 
> BeagleBoard. We are all volunteers, including Robert Nelson. If you have a 
> problem with Documentation, then why don’t you create it so others can learn. 
> If you need help with getting the info you need, we are all prepared to help. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Apr 5, 2016, at 9:57 AM, Wally Bkg gmail.com 
>> > wrote:
>> 
>> 
>> I think the output of uname -a  for your kernel version is more helpful than 
>> the Debian version which is running when it comes to overlays, modules, and 
>> Beaglebone hardware specific issues.
>> 
>> I'm subscribing to this thread, as you are doing what I've planned to do in 
>> the not too distant future, so I'm really interested in what the solutions 
>> are to your problems here.
>> 
>> The Beaglebone development is fast and furious, which is good, but the 
>> developers don't seem to give a hoot if changes break what little 
>> documentation is out there, which IMHO makes the BB a rather poor choice for 
>> newbies.   
>> 
>> I've posted a fair amount about Bonescript issues because I'm trying to help 
>> a friend get started with an automation project for a solar powered, 
>> off-grid, hydroponic green-house.  He needs some A/D or I'd have recommended 
>> a Rasperry Pi2 from the start, but if things don't fall into place soon I'll 
>> just buy him a Pi Hat that has A/D and give it to him along with one of my 
>> RiP2 boards as the frustration factor is really turning me off.   Without me 
>> helping him, he'd already have tossed the BB in the trash and did the best 
>> he could with timers and relays, which he totally understands -- but he was 
>> looking to get creative with some of his control ideas that he clearly sees 
>> as difficult to do without a computer.
>> 
>> 
>> 
>> 
>> 
>> On Tuesday, April 5, 2016 at 10:22:36 AM UTC-5, Le Costaouec Vincent wrote:
>> 
>> I forgot to indicate the release on which I'm working on :  
>> #  lsb_release -da
>> 
>> Distributor ID:Debian
>> Description:Debian GNU/Linux 8.3 (jessie)
>> Release:8.3
>> Codename:jessie
>> 
>> Is anyone have already work on the PRU on this kernel version ?
>> Thanks by advance.
>> Regards.
>> Vincent
>> 
>> 
>> Le mardi 5 avril 2016 11:33:06 UTC+2, Le Costaouec Vincent a écrit :
>> Hello, 
>> 
>> I'm currently trying to configure and use the PRU of the BBB.
>> 
>> So I've tried two different method to do so however, with none of them I get 
>> succeed and I don't really 
>> understand why.
>> 
>> 1) First method (from Derek Molloy book) :
>> 
>> http://exploringbeaglebone.com/chapter13/ 
>> 
>> So I have tried to do the PRU-based Clock Signal Generators, because this 
>> one 
>> do not required any additional material except an oscilloscope.
>> 
>> So I had load the EBB-PRU-Example DTS overlay (provided in attachment), and 
>> I have receive the following message : 
>> # echo EBB-PRU-Example > $SLOTS
>> [   51.417438] bone_capemgr bone_capemgr: part_number 'EBB-PRU-Example', 
>> version 'N/A'
>> [   51.425297] bone_capemgr bone_capemgr: slot #4: 

Re: [beagleboard] PRU configure and basic test not working

[John Syne]

Here is what you need to understand about people on this list. There are no 
“developers" on this list. No one on this mailing list is paid by BeagleBoard. 
We are all volunteers, including Robert Nelson. If you have a problem with 
Documentation, then why don’t you create it so others can learn. If you need 
help with getting the info you need, we are all prepared to help. 

Regards,
John




> On Apr 5, 2016, at 9:57 AM, Wally Bkg  wrote:
> 
> 
> I think the output of uname -a  for your kernel version is more helpful than 
> the Debian version which is running when it comes to overlays, modules, and 
> Beaglebone hardware specific issues.
> 
> I'm subscribing to this thread, as you are doing what I've planned to do in 
> the not too distant future, so I'm really interested in what the solutions 
> are to your problems here.
> 
> The Beaglebone development is fast and furious, which is good, but the 
> developers don't seem to give a hoot if changes break what little 
> documentation is out there, which IMHO makes the BB a rather poor choice for 
> newbies.   
> 
> I've posted a fair amount about Bonescript issues because I'm trying to help 
> a friend get started with an automation project for a solar powered, 
> off-grid, hydroponic green-house.  He needs some A/D or I'd have recommended 
> a Rasperry Pi2 from the start, but if things don't fall into place soon I'll 
> just buy him a Pi Hat that has A/D and give it to him along with one of my 
> RiP2 boards as the frustration factor is really turning me off.   Without me 
> helping him, he'd already have tossed the BB in the trash and did the best he 
> could with timers and relays, which he totally understands -- but he was 
> looking to get creative with some of his control ideas that he clearly sees 
> as difficult to do without a computer.
> 
> 
> 
> 
> 
> On Tuesday, April 5, 2016 at 10:22:36 AM UTC-5, Le Costaouec Vincent wrote:
> 
> I forgot to indicate the release on which I'm working on :  
> #  lsb_release -da
> 
> Distributor ID:Debian
> Description:Debian GNU/Linux 8.3 (jessie)
> Release:8.3
> Codename:jessie
> 
> Is anyone have already work on the PRU on this kernel version ?
> Thanks by advance.
> Regards.
> Vincent
> 
> 
> Le mardi 5 avril 2016 11:33:06 UTC+2, Le Costaouec Vincent a écrit :
> Hello, 
> 
> I'm currently trying to configure and use the PRU of the BBB.
> 
> So I've tried two different method to do so however, with none of them I get 
> succeed and I don't really 
> understand why.
> 
> 1) First method (from Derek Molloy book) :
> 
> http://exploringbeaglebone.com/chapter13/ 
> 
> So I have tried to do the PRU-based Clock Signal Generators, because this one 
> do not required any additional material except an oscilloscope.
> 
> So I had load the EBB-PRU-Example DTS overlay (provided in attachment), and I 
> have receive the following message : 
> # echo EBB-PRU-Example > $SLOTS
> [   51.417438] bone_capemgr bone_capemgr: part_number 'EBB-PRU-Example', 
> version 'N/A'
> [   51.425297] bone_capemgr bone_capemgr: slot #4: override
> [   51.430665] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
> [   51.437772] bone_capemgr bone_capemgr: slot #4: 'Override Board 
> Name,00A0,Override Manuf,EBB-PRU-Example'
> [   52.526058] gpio-of-helper ocp:gpio_helper: ready
> [   52.531052] bone_capemgr bone_capemgr: slot #4: dtbo 
> 'EBB-PRU-Example-00A0.dtbo' loaded; overlay id #0
> 
> 
> 
> # cat $SLOTS
>  0: PF  -1 
>  1: PF  -1 
>  2: PF  -1 
>  3: PF  -1 
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,EBB-PRU-Example
> 
> I have also check :
> # lsmod |grep uio
> uio_pruss   4590  0 
> uio_pdrv_genirq 3317  0 
> uio 8319  2 uio_pruss,uio_pdrv_genirq
> 
> 
> root@beagle01:~/labs/exploringBB/chp13/fixedPRUClock# ./build 
> PRU Assembler Version 0.86
> Copyright (C) 2005-2013 by Texas Instruments Inc.
> Pass 2 : 0 Error(s), 0 Warning(s)
> Writing Code Image of 12 word(s)
> 
> # sudo ./fixedclock
> However, when I tried to monitor what append on pin P9_27 but I didn't 
> observed anything on this pins.
> 
> 
> 
> 
> 2) Second method (from the Beagle bone black cookbook written by Charles A 
> Hamilton) :
> 
> This time, I have use this DTS : BB-BONE-PRU-01 
> (https://github.com/jadonk/cape-firmware/blob/master/arch/arm/boot/dts/BB-BONE-PRU-01-00A0.dts
>  
> )
> In addition, I have tried to used this code :
> https://github.com/HudsonWerks/bbb-pru 
> 
> 
> So first I tried to add the DTS, I received this message : 
> # echo EBB-PRU-Exampecho BB-BONE-PRU-01 > $SLOTS
> [59800.649273] bone_capemgr bone_capemgr: part_number 'BB-BONE-PRU-01', 
> version 'N/A'
> [59800.656947] bone_capemgr bone_capemgr: slot #12: override
> [59800.662528] bone_capemgr 

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] 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 h

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 <ma...@dragonworks.info> 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] 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.

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

[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] 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 <john3...@gmail.com> 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 <yyrk...@gmail.com> wrote:
>>>>> 
>>>>> I'd actually look into using the McSPI module. Which is hardware, and
>>>>> does
>>>>> support slave mode.
>>>>> 
>>>>> On Su

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 <john3...@gmail.com> 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 <yyrk...@gmail.com> 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 <john3...@gmail.com> 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 <john3...@gmail.com> wrote:
>>>>> What exactly are you trying to do? Please explain your application so
>>>>> that we can propose a sol

Re: [beagleboard] /sys/class/gpio vs. DTB

[John Syne]

Why not do it in your applications?

http://derekmolloy.ie/kernel-gpio-programming-buttons-and-leds/

Regards,
John




> On Apr 3, 2016, at 4:14 PM, Rick Mann  wrote:
> 
> I configure a few GPIOs for my application. Is this something that can be 
> accomplished entirely via DTB?
> 
>   # cd /sys/class/gpio
>   
>   # echo 50 > export
>   # echo 115 > export
>   # echo out > gpio50/direction
>   # echo out > gpio115/direction
> 
>   # echo 1 > gpio50/value
>   # echo 1 > gpio115/value
>   
>   # echo 0 > gpio50/value
>   # echo 0 > gpio115/value
> 
> That is, setting which GPIOs are enabled, setting their direction, and 
> setting their output state?
> 
> 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.

-- 
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] Control and monitor Beaglebone from azure

[John Syne]

My guess is that most people here use Linux and don’t like proprietary 
solutions like Azure. I had a look at the demo, and I don’t see any value in 
what they are offering. You can do the same thing with Angularjs, D3.js, which 
are all open source and simple to interface with BBB.

Regards,
John




> On Apr 3, 2016, at 2:55 PM, 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: Find error for DHT11 with BBB code .......

[John Syne]

Why not write this with a Kernel Module:

http://derekmolloy.ie/kernel-gpio-programming-buttons-and-leds/

This is much faster and will do what you want. 

Regards,
John




> On Apr 2, 2016, at 7:42 PM, Dennis Lee Bieber  wrote:
> 
> 
>   o/~ I'm Talking to Myself in Public o/~
> 
> On Sat, 02 Apr 2016 21:37:26 -0400, Dennis Lee Bieber
>  declaimed the following:
> 
> 
> 
>>  I attempted to generate something in C++ which took hours. For some
>> reason I can't seem to find a GPIO pin that was actually toggling when
>> under an oscilloscope. Even when manually setting the pin value using the
>>  echo 1 > /sys/class/gpio/gpio#/value
>> from a command line. I could read back the 1 (or 0) value, but never found
>> a level change on the 'scope -- the pin was either tied high, or tied to
>> ground.
>> 
>>  My last version is showing some activity, but is still failing, as
>> shown (I'm wondering if usleep() has some obscenely large granularity on
>> the BBB, because it took 53 seconds to go from "beginning measurement" to
>> the first timeout error on the first byte, sixth bit):
>> 
> 
>   Actually, I suspect it's the overhead of all the I/O calls needed to
> access GPIOs via a pseudo file system.
> 
>   After all, to detect a 0 bit, requires being able to do three at least
> six I/O function calls in 27usec (the HIGH period of the bit --
> open/read/close to detect the transition to HIGH, and open/read/close to
> detect the end transition back to LOW -- and preferably multiple cycles to
> get some idea of the length)
> 
>   Might need to try the mmap route... Hopefully won't need the PRU.
> -- 
>   Wulfraed Dennis Lee Bieber AF6VN
>wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.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] Beaglebone RT test

[John Syne]

I would say that avg latency of 32uS is very good and I would be skeptical of 
this result. I don’t know what cyclictest does, but I’m wondering what the CPU 
load is during this test. My guess is the CPU load is low and that is why you 
are getting 32uS. If the CPU load was high, I would expect the number to 
increase to 100uS or more. Even Xenomai, which has a dual kernel is only able 
to achieve 40uS under load. 

Regards,
John




> On Mar 30, 2016, at 11:38 PM, Victor WANG  wrote:
> 
> hello,
> 
> I use beaglebone black and install Linux Debian (Linux beaglebone 
> 4.4.6-bone-rt-r6 #1 PREEMPT RT Thu Mar 17 04:47:32 UTC 2016 armv7l 
> GNU/Linux), I want to test the characteristic of Real Time, so I use 
> cyclictest:
> 
> After "cyclictest -p 90 - m -c 0 -i 200 -n -h 100 -q -l 1", I got:
> 
> # Total: 1
> # Min Latencies: 00012
> # Avg Latencies: 00032
> # Max Latencies: 00053
> # Histogram Overflows: 0
> # Histogram Overflow at cycle number:
> # Thread 0:
> 
> The result means the average latencies is 32 us.
> 
> I wonder if it is normal or not? (In my opinion, it is a little wired, 
> because with the RT-preempt patch, it should be better than it.)
> 
> And if there is something wrong in the process, please tell me .
> 
> Thanks so much.
> 
> -- 
> 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] What's in the iot build?

[John Syne]

Why not download the build tool and look at the config file, which list the 
packages added to the build. 

Regards,
John




> On Mar 30, 2016, at 11:22 PM, William Hermans  wrote:
> 
> By that, I'm assuming Robert meant lxde .  ..
> 
> On Wed, Mar 30, 2016 at 11:19 PM, William Hermans  > wrote:
> On Wed, Mar 30, 2016 at 2:09 PM, Wally Bkg  > wrote:
> > I'm curious as to difference between the Beaglebone Console and IOT images
> > and the reason(s) for choosing one over the other.
> >
> > Even on my BBW I prefer an lxde or lxqt image as I like to be able to do ssh
> > -X for things like gedit or geany from time to time, and I like the easy
> > back-up and/or cloning of SD cards over flashing eMMC, but I'd like to know
> > when an alternate image might make sense.
> 
> The iot image = lxqt image - lxqt/xorg...
> 
> Regards,
> 
> 
> On Wed, Mar 30, 2016 at 10:34 PM, Rick Mann  > wrote:
> So, I leave this project for half a year (maybe more), only to come back to a 
> slightly new arrangement of builds, including an "iot" build. But there's no 
> text on the page describing what's in the iot build.
> 
> That's the kind of omission that makes it take so much longer to get anywhere 
> with a project like this. It took me weeks to understand the difference 
> between console and other builds, mostly by trial and error. A sentence or 
> two on the page would be very helpful.
> 
> So, what's in the iot build?
> 
> 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 
> .
> 
> 
> 
> -- 
> 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: PWM Pin Error on Boot

[John Syne]

One more thing, you may want to look at /driver/pinctrl/pinctrl-single.c as 
this is where the pinmux gets set.You could also use dynamic tracing to help 
find the responsible routine. Look in /Documentation/dynamic-debug-howto.txt. 
Probably a little bit of trial and error will be needed to narrow down this 
problem.

Regards,
John




> On Mar 30, 2016, at 3:45 PM, M House  wrote:
> 
> Thanks for the reply John.  I'm pretty new to modifying kernel modules and I 
> haven't worked with u-boot at all.  I'm not sure at the moment when the GPIO 
> is modified but I think it happens whenever the system resets, most likely on 
> startup.  Should I try a kernel dump right after I boot?
> 
> Thanks,
> Mike
> 
> On Wednesday, March 30, 2016 at 2:03:58 PM UTC-7, john3909 wrote:
> Well, that depends on how skilled you are at modifying u-boot and the linux 
> kernel?
> 
> In each case, modify the code that toggles the GPIO pin by printing text to 
> the console when the GPIO you want is modified. You could always issue a 
> kernel dump when that GPIO is modified, which will list the call sequence 
> that causes the GPIO toggle. For the Kernel, I believe the code you want is 
> in drivers/gpio/gpio-omap.c, but I haven’t looked at u-boot in a while, but 
> it should be simple to find the equivalent code. 
> 
> If you had a decent JTAG emulator, you could simply set a breakpoint on the 
> GPIO toggle and then look at the call stack to see which routing is 
> responsible. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 30, 2016, at 1:25 PM, M House  
>> wrote:
>> 
>> Hey everyone I'm still stuck as to why my beaglebone keeps changing the 
>> polarity to 1 on boot.  I can go in and manually change it but it always 
>> resets after reboot.  Should I maybe write a start up script to force the 
>> polarity to 0?  I'd rather find the root cause rather than a hack but at 
>> this point anything that works is fine by me.
>> 
>> Thank you
>> 
>> On Saturday, March 19, 2016 at 11:30:58 PM UTC-7, M House wrote:
>> I'm doing a project right now that involves using a micro servo.  One is on 
>> port P8_13 and another on P9_14.  
>> 
>> Everytime I boot the beaglebone it gives me - error: Error enabling PWM 
>> controls: Error: ENOENT, no such file or directory 
>> '/sys/devices/ocp.3/bs_pwm_test_P9_14.15/polarity'
>> 
>> When I check this file it shows a value of '1' inside of it.  Where the same 
>> file for P8_13 shows a zero.  When I change the P9_14 polarity file to 0 the 
>> servo works as intended.  I'm really confused why the polarity is being set 
>> to 1 every time I boot the beaglebone.  This also happens if I move the 
>> servo to P9_16.
>> 
>> I did just upgrade from Debian 7.8 to 7.9 but I don't see how that would 
>> change the GPIO behavior.
>> 
>> 
>> -- 
>> 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: PWM Pin Error on Boot

[John Syne]

Well, that depends on how skilled you are at modifying u-boot and the linux 
kernel?

In each case, modify the code that toggles the GPIO pin by printing text to the 
console when the GPIO you want is modified. You could always issue a kernel 
dump when that GPIO is modified, which will list the call sequence that causes 
the GPIO toggle. For the Kernel, I believe the code you want is in 
drivers/gpio/gpio-omap.c, but I haven’t looked at u-boot in a while, but it 
should be simple to find the equivalent code. 

If you had a decent JTAG emulator, you could simply set a breakpoint on the 
GPIO toggle and then look at the call stack to see which routing is 
responsible. 

Regards,
John




> On Mar 30, 2016, at 1:25 PM, M House  wrote:
> 
> Hey everyone I'm still stuck as to why my beaglebone keeps changing the 
> polarity to 1 on boot.  I can go in and manually change it but it always 
> resets after reboot.  Should I maybe write a start up script to force the 
> polarity to 0?  I'd rather find the root cause rather than a hack but at this 
> point anything that works is fine by me.
> 
> Thank you
> 
> On Saturday, March 19, 2016 at 11:30:58 PM UTC-7, M House wrote:
> I'm doing a project right now that involves using a micro servo.  One is on 
> port P8_13 and another on P9_14.  
> 
> Everytime I boot the beaglebone it gives me - error: Error enabling PWM 
> controls: Error: ENOENT, no such file or directory 
> '/sys/devices/ocp.3/bs_pwm_test_P9_14.15/polarity'
> 
> When I check this file it shows a value of '1' inside of it.  Where the same 
> file for P8_13 shows a zero.  When I change the P9_14 polarity file to 0 the 
> servo works as intended.  I'm really confused why the polarity is being set 
> to 1 every time I boot the beaglebone.  This also happens if I move the servo 
> to P9_16.
> 
> I did just upgrade from Debian 7.8 to 7.9 but I don't see how that would 
> change the GPIO behavior.
> 
> 
> -- 
> 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] RPMsg from Linux User Space to PRU on Beaglebone Black

[John Syne]

Hi Lucas,

Good to hear this is working for you. Now for the real work ;-)

Regards,
John




> On Mar 28, 2016, at 6:10 AM, lucas  wrote:
> 
> Wow it worked :) Thank you, John! 
> 
> Short summary how to get it working: 
> 
> 1.) Compile PRU_RPMsg_LED0 project in CCS
> 2.) Transfer PRU_RPMsg_LED0.out onto beaglebone into the /lib/firmware 
> directory 
> 3.) Set symbolic link: sudo ln -s PRU_RPMsg_LED0.out am335x-pru0-fw
> 4.) restart
> 5.) modprobe virtio_rpmsg_bus
> 6.) modprobe rpmsg_pru
> 7.) check if /dev/rpmsg_pru30 exists
> 8.) echo "r" > /dev/rpmsg_pru30
> 9.) Observe red LED light up on PRU_cape :) 
> 
> 
> On Wednesday, March 23, 2016 at 8:42:50 PM UTC+1, john3909 wrote:
> Don’t include the .ko extension when using modprobe.
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 23, 2016, at 9:32 AM, lucas gmail.com 
>> > wrote:
>> 
>> Sorry forgot to copy the error message for the modprobe command: 
>> 
>> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# modprobe 
>> virtio_rpmsg_bus.ko
>> modprobe: FATAL: Module virtio_rpmsg_bus.ko not found.
>> 
>> On Wednesday, March 23, 2016 at 5:27:12 PM UTC+1, lucas wrote:
>> Hi John, 
>> 
>> thank you very much for your answer. 
>> 
>> I am using the 4.1.15-ti-rt-r43 kernel. It's the kernel that came with the 
>> debian image from the beaglebone website.  
>> 
>> Only the pruss_remoteproc module seems to be loaded on boot:
>> 
>> # lsmod
>> Module  Size  Used by
>> 8021q  17336  0
>> garp5975  1 8021q
>> mrp 7322  1 8021q
>> stp 1911  1 garp
>> llc 5257  2 stp,garp
>> pruss_remoteproc   15296  2
>> omap_rng4358  0
>> rng_core7437  1 omap_rng
>> usb_f_acm   7180  1
>> u_serial   10596  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
>> snd_soc_davinci_mcasp17266  0
>> snd_soc_edma1150  1 snd_soc_davinci_mcasp
>> spi_omap2_mcspi10681  0
>> uio_pdrv_genirq 3521  0
>> 
>> Although the other modules do exist in the driver directory.
>> 
>> ls /lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg
>> rpmsg_pru.ko  rpmsg-rpc.ko  virtio_rpmsg_bus.ko
>> 
>> I cannot modprob the modules:
>> 
>> # modprobe virtio_rpmsg_bus.ko
>> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# modprobe 
>> virtio_rpmsg_bus.ko
>> 
>> 
>> But I can use insmod 
>> 
>> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# insmod 
>> virtio_rpmsg_bus.ko
>> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# lsmod
>> Module  Size  Used by
>> virtio_rpmsg_bus   13437  0
>> 8021q  17336  0
>> garp5975  1 8021q
>> ...
>> 
>> 
>> Should I try to switch to the kernel version you are using? Is there an 
>> image or should I recompile the kernel? Any other ideas? 
>> 
>> Lucas
>> 
>> On Tuesday, March 22, 2016 at 7:40:56 PM UTC+1, john3909 wrote:
>> Hi Lucas,
>> 
>> This seems to work just fine for me. What kernel version are you using?
>> 
>> I’m using V4.1.13-ti-r33. As you can see, all remoteproc/rpmsg kernel 
>> modules are loaded automatically at boot time.
>> 
>> [   16.251480] pruss-rproc 4a30.pruss: 8 PRU interrupts parsed   
>>  
>> [   16.251567] pruss-rproc 4a30.pruss: memorydram0: pa 0x4a30 
>> size 0x2000 va e0ca 
>> [   16.251595] pruss-rproc 4a30.pruss: memorydram1: pa 0x4a302000 
>> size 0x2000 va e0ca4000 
>> [   16.251621] pruss-rproc 4a30.pruss: memory shrdram2: pa 0x4a31 
>> size 0x3000 va e0ca8000 
>> [   16.251644] pruss-rproc 4a30.pruss: memory intc: pa 0x4a32 
>> size 0x2000 va e0cac000 
>> [   16.251672] pruss-rproc 4a30.pruss: memory  cfg: pa 0x4a326000 
>> size 0x2000 va e0cb 
>> [   16.252174] pruss-rproc 4a30.pruss: creating platform devices for PRU 
>> cores
>> [   16.374800] pru-rproc 4a334000.pru0: memory iram: pa 0x4a334000 size 
>> 0x2000 va e0cb4000
>> [   16.374858] pru-rproc 4a334000.pru0: memory  control: pa 0x4a322000 size 
>> 0x400 va e0876000 
>> [   16.374901] pru-rproc 4a334000.pru0: memorydebug: pa 0x4a322400 size 
>> 0x100 va e0c9e400 
>> [   16.375152]  remoteproc1: 4a334000.pru0 is available  
>>

Re: [beagleboard] SPI BBB Master, BBB Slave

[John Syne]

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 <yyrk...@gmail.com> 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 <john3...@gmail.com 
> <mailto:john3...@gmail.com>> 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 
>> <mailto: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 <john3...@gmail.com 
>> <mailto:john3...@gmail.com>> 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 
>>> <mailto: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 
>>> <http://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 
>>> <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 dts:
>>>   0x150 0x10  /* spi0_sclk, OUTPUT_PULLUP | MODE0 */
>>>   0x154 0x30  /* spi0_d0, INPUT_PULLUP | MODE0 */
>>>   0x158 0x10  /* spi0_d1, OUT

Re: [beagleboard] C compiler

[John Syne]

Strange. I’m not sure there is a way to not use umask. With umask=022, the 
purpose is to set the default permission for newly created files or 
directories, so only the owner has write permissions. How is that a security 
flaw? I guess you can always make umask=000, but then you are enabling everyone 
write permissions as the default and that is a security flaw. 

Regards,
John




> On Mar 25, 2016, at 11:49 PM, William Hermans <yyrk...@gmail.com> wrote:
> 
> I think it should be pretty clear, and if this is not abundantly clear to new 
> users. *DO NOT USE umask* Period. good bye, the end.
> 
> One should leave the default settings and instead work with the system as 
> intended. Instead of creating a serious potential security hole.
> 
> On Fri, Mar 25, 2016 at 10:27 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> Hi Mike,
> 
> The way I think about this is umask turns off permission, which means that 
> the execute permission is provided by gcc.
> 
> For example:
> 
> MBPR:~ john$ umask
> 0022
> MBPR:~ john $ touch test
> MBPR:~ john $ ls -la test
> -rw-r--r--  1 john  staff  0 Mar 25 22:15 test
> MBPR:~ john $ gcc -Wall -o hello hello.c
> MBPR:~ john $ ls -la hello
> -rwxr-xr-x  1 john  staff  8432 Mar 25 22:17 hello
> 
> 
> As you can see, 022 is turning off “group" write and “other" write 
> permissions. So normally, touch would provide 0666, but when umask is 022, 
> permission is anded with the inverse of umask, which provides 0644. So gcc 
> would create a file with 0777 if umask was 000.
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 25, 2016, at 5:30 PM, Mike <bellyac...@gmail.com 
>> <mailto:bellyac...@gmail.com>> wrote:
>> 
>> On 03/25/2016 08:11 PM, William Hermans wrote:
>>> Im guessing that perhaps gcc's -o option now days enables the executable 
>>> bit on the output file ? I haven't looked into that however.
>> Nothing at all to do with gcc, reread what I already posted...
>> 
>> Mike
>>> 
>>> On Fri, Mar 25, 2016 at 5:08 PM, William Hermans <yyrk...@gmail.com 
>>> <mailto:yyrk...@gmail.com>> wrote:
>>> No, Mike is absolutely correct. dot's meaning in this context is current 
>>> directory, and slash is just a path modifier / separator. Putting the file 
>>> in ones $PATH would solve the "problem" of having to use dot slash I've 
>>> know  this forever, I do not know why I was thinking that chmod +x would 
>>> solve that "issue", because it wont.
>>> 
>>> I do recall at some point perhaps not too long ago that changing file 
>>> permissions to executable was required. But now days this does not seem to 
>>> be the case . . . I've always in the last several years use ./executable 
>>> until I put the executable into my local path . . .
>>> 
>>> On Fri, Mar 25, 2016 at 2:19 PM, Mike < 
>>> <mailto:bellyac...@gmail.com>bellyac...@gmail.com 
>>> <mailto:bellyac...@gmail.com>> wrote:
>>> On 03/25/2016 02:03 PM, William Hermans wrote:
>>>> No chmod needed *IF* you precede the command with a dot slash "./". So 
>>>> when you run a regular Linux command do you have to type this dot slash ? 
>>>> No because chmod +x is run on the executable at some point . . .
>>>> 
>>>> So be nice to fellow group users who actually know what they're talking 
>>>> about, and have been on this list a lot longer than you.
>>> Maybe we need to learn what ./ does...  It has absolutely nothing to do 
>>> with a files permissions or whether it's executable or not.  It's use is 
>>> regarding the lack of the current directory "." in one's PATH variable.  
>>> Umask is (largely) what controls what permissions a file is created with.
>>> 
>>> mike@pride-n-joy:~/test.d$ <mailto:mike@pride-n-joy:%7E/test.d$> ls -al
>>> total 12
>>> drwxr-xr-x  2 mike mike 4096 Mar 25 17:07 .
>>> drwxr-xr-x 37 mike mike 4096 Mar 25 16:46 ..
>>> -rw-r--r--  1 mike mike   78 Mar 25 16:47 hello.c
>>> mike@pride-n-joy:~/test.d$ <mailto:mike@pride-n-joy:%7E/test.d$> umask
>>> 0022
>>> mike@pride-n-joy:~/test.d$ <mailto:mike@pride-n-joy:%7E/test.d$> gcc -Wall 
>>> -o hello hello.c 
>>> mike@pride-n-joy:~/test.d$ <mailto:mike@pride-n-joy:%7E/test.d$> ls -l
>>> total 12
>>> -rwxr-xr-x 1 mike mike 6696 Mar 25 17:08 hello
>>> -rw-r--r-- 1 mike mike   78 Mar 25 16:47 hello.c
>>> mike@pride-n-joy:~/test.d$ <mailto:mike@pride-

Re: [beagleboard] C compiler

[John Syne]

Hi Mike,

The way I think about this is umask turns off permission, which means that the 
execute permission is provided by gcc.

For example:

MBPR:~ john$ umask
0022
MBPR:~ john $ touch test
MBPR:~ john $ ls -la test
-rw-r--r--  1 john  staff  0 Mar 25 22:15 test
MBPR:~ john $ gcc -Wall -o hello hello.c
MBPR:~ john $ ls -la hello
-rwxr-xr-x  1 john  staff  8432 Mar 25 22:17 hello


As you can see, 022 is turning off “group" write and “other" write permissions. 
So normally, touch would provide 0666, but when umask is 022, permission is 
anded with the inverse of umask, which provides 0644. So gcc would create a 
file with 0777 if umask was 000.

Regards,
John




> On Mar 25, 2016, at 5:30 PM, Mike  wrote:
> 
> On 03/25/2016 08:11 PM, William Hermans wrote:
>> Im guessing that perhaps gcc's -o option now days enables the executable bit 
>> on the output file ? I haven't looked into that however.
> Nothing at all to do with gcc, reread what I already posted...
> 
> Mike
>> 
>> On Fri, Mar 25, 2016 at 5:08 PM, William Hermans > > wrote:
>> No, Mike is absolutely correct. dot's meaning in this context is current 
>> directory, and slash is just a path modifier / separator. Putting the file 
>> in ones $PATH would solve the "problem" of having to use dot slash I've know 
>>  this forever, I do not know why I was thinking that chmod +x would solve 
>> that "issue", because it wont.
>> 
>> I do recall at some point perhaps not too long ago that changing file 
>> permissions to executable was required. But now days this does not seem to 
>> be the case . . . I've always in the last several years use ./executable 
>> until I put the executable into my local path . . .
>> 
>> On Fri, Mar 25, 2016 at 2:19 PM, Mike < 
>> bellyac...@gmail.com 
>> > wrote:
>> On 03/25/2016 02:03 PM, William Hermans wrote:
>>> No chmod needed *IF* you precede the command with a dot slash "./". So when 
>>> you run a regular Linux command do you have to type this dot slash ? No 
>>> because chmod +x is run on the executable at some point . . .
>>> 
>>> So be nice to fellow group users who actually know what they're talking 
>>> about, and have been on this list a lot longer than you.
>> Maybe we need to learn what ./ does...  It has absolutely nothing to do with 
>> a files permissions or whether it's executable or not.  It's use is 
>> regarding the lack of the current directory "." in one's PATH variable.  
>> Umask is (largely) what controls what permissions a file is created with.
>> 
>> mike@pride-n-joy:~/test.d$  ls -al
>> total 12
>> drwxr-xr-x  2 mike mike 4096 Mar 25 17:07 .
>> drwxr-xr-x 37 mike mike 4096 Mar 25 16:46 ..
>> -rw-r--r--  1 mike mike   78 Mar 25 16:47 hello.c
>> mike@pride-n-joy:~/test.d$  umask
>> 0022
>> mike@pride-n-joy:~/test.d$  gcc -Wall 
>> -o hello hello.c 
>> mike@pride-n-joy:~/test.d$  ls -l
>> total 12
>> -rwxr-xr-x 1 mike mike 6696 Mar 25 17:08 hello
>> -rw-r--r-- 1 mike mike   78 Mar 25 16:47 hello.c
>> mike@pride-n-joy:~/test.d$  hello
>> bash: hello: command not found
>> mike@pride-n-joy:~/test.d$  ./hello 
>> Hello, world!
>> mike@pride-n-joy:~/test.d$  umask 0137
>> mike@pride-n-joy:~/test.d$  gcc -Wall 
>> -o hello hello.c 
>> mike@pride-n-joy:~/test.d$  ls -l
>> total 12
>> -rw-r- 1 mike mike 6696 Mar 25 17:09 hello
>> -rw-r--r-- 1 mike mike   78 Mar 25 16:47 hello.c
>> mike@pride-n-joy:~/test.d$  hello
>> bash: hello: command not found
>> mike@pride-n-joy:~/test.d$  ./hello
>> bash: ./hello: Permission denied
>> mike@pride-n-joy:~/test.d$  ls -l
>> total 12
>> -rw-r- 1 mike mike 6696 Mar 25 17:09 hello
>> -rw-r--r-- 1 mike mike   78 Mar 25 16:47 hello.c
>> mike@pride-n-joy:~/test.d$  chmod 0750 
>> hello
>> mike@pride-n-joy:~/test.d$  ls -l
>> total 12
>> -rwxr-x--- 1 mike mike 6696 Mar 25 17:09 hello
>> -rw-r--r-- 1 mike mike   78 Mar 25 16:47 hello.c
>> mike@pride-n-joy:~/test.d$  ./hello 
>> Hello, world!
>> mike@pride-n-joy:~/test.d$  umask 022
>> mike@pride-n-joy:~/test.d$  umask
>> 0022
>> mike@pride-n-joy:~/test.d$ 
>> 
>> Mike 
>>> 
>>> On Fri, Mar 25, 2016 at 8:53 AM, Dieter Wirz < 
>>> didi.w...@gmail.com 
>>> > wrote:
>>> On Fri, Mar 25, 

Re: [beagleboard] PRU

[John Syne]

> On Mar 25, 2016, at 8:35 AM, John Tobias <john.tobias...@gmail.com> wrote:
> 
> Hi John,
> 
> I were able to compile the missing library. I compiled the programs (git tags 
> v4.0.0, v4.0.1 and v4.0.2) then copied the toggle_led.out fie into 
> /lib/firmware and named it to am335x-pru0-fw.
> 
> None of them and are loading successfully. I am using debian version 8.3 
> running kernel 4.1.15-ti-rt-r43. Below are the version of my tools that I am 
> using.
What error messages are you getting?
> 
> PRU_CGT=/home/jtobias/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2
> ARM_CGT=/home/jtobias/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.5
> SW_DIR=/home/jtobias/ti/AM335X_StarterWare_02_00_01_01
> 
> 
> Regards,
> 
> John
> 
> On Wed, Mar 23, 2016 at 8:37 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> http://processors.wiki.ti.com/index.php/Mklib#Invoking_mklib_manually 
> <http://processors.wiki.ti.com/index.php/Mklib#Invoking_mklib_manually>
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 23, 2016, at 5:55 PM, John Tobias <john.tobias...@gmail.com 
>> <mailto:john.tobias...@gmail.com>> wrote:
>> 
>> Hi John,
>> 
>> I have the PRU Add on which is pru-icss-4.0.1. Then, I tried the latest 
>> example from the git you provided.
>> I have some compilation error (please see the attached log.txt)
>> 
>> Regards,
>> 
>> John
>> 
>> 
>> On Wed, Mar 23, 2016 at 4:37 PM, John Syne <john3...@gmail.com 
>> <mailto:john3...@gmail.com>> wrote:
>> Or you can use the latest examples from here:
>> 
>> https://git.ti.com/pru-software-support-package/pru-software-support-package 
>> <https://git.ti.com/pru-software-support-package/pru-software-support-package>
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Mar 23, 2016, at 1:54 PM, John Tobias <john.tobias...@gmail.com 
>>> <mailto:john.tobias...@gmail.com>> wrote:
>>> 
>>> Hello Guys,
>>> 
>>> I am using debian image version 8.3 that I downloaded @ 
>>> http://beagleboard.org/latest-images <http://beagleboard.org/latest-images> 
>>> (4.1.15-ti-rt-r43). Also, I downloaded the TI SDK for AM335x 
>>> (http://software-dl.ti.com/processor-sw/esd/PROCESSOR-SDK-LINUX-AM335X/latest/index_FDS.html
>>>  
>>> <http://software-dl.ti.com/processor-sw/esd/PROCESSOR-SDK-LINUX-AM335X/latest/index_FDS.html>).
>>> 
>>> I compiled the sample program for PRU (toggle_led.out) and copy it over in 
>>> /lib/firmware/am335x-pru0-fw, but it did not work.
>>> 
>>> Then, I found Robert Nelson's binary and it works fine.
>>> 
>>> https://github.com/RobertCNelson/boot-scripts/commit/20a16f79be80886a1e030d197573b5950f98626d#diff-a0ab1dbc32ef29215c473f3b8979ad32
>>>  
>>> <https://github.com/RobertCNelson/boot-scripts/commit/20a16f79be80886a1e030d197573b5950f98626d#diff-a0ab1dbc32ef29215c473f3b8979ad32>
>>> 
>>> 
>>> Any idea?.
>>> 
>>> Regards,
>>> 
>>> John
>>> 
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss 
>>> <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 
>>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>>> For more options, visit https://groups.google.com/d/optout 
>>> <https://groups.google.com/d/optout>.
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <http://beagleboard.org/discuss>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group

Re: [beagleboard] PRU

[John Syne]

http://processors.wiki.ti.com/index.php/Mklib#Invoking_mklib_manually 
<http://processors.wiki.ti.com/index.php/Mklib#Invoking_mklib_manually>

Regards,
John




> On Mar 23, 2016, at 5:55 PM, John Tobias <john.tobias...@gmail.com> wrote:
> 
> Hi John,
> 
> I have the PRU Add on which is pru-icss-4.0.1. Then, I tried the latest 
> example from the git you provided.
> I have some compilation error (please see the attached log.txt)
> 
> Regards,
> 
> John
> 
> 
> On Wed, Mar 23, 2016 at 4:37 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> Or you can use the latest examples from here:
> 
> https://git.ti.com/pru-software-support-package/pru-software-support-package 
> <https://git.ti.com/pru-software-support-package/pru-software-support-package>
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 23, 2016, at 1:54 PM, John Tobias <john.tobias...@gmail.com 
>> <mailto:john.tobias...@gmail.com>> wrote:
>> 
>> Hello Guys,
>> 
>> I am using debian image version 8.3 that I downloaded @ 
>> http://beagleboard.org/latest-images <http://beagleboard.org/latest-images> 
>> (4.1.15-ti-rt-r43). Also, I downloaded the TI SDK for AM335x 
>> (http://software-dl.ti.com/processor-sw/esd/PROCESSOR-SDK-LINUX-AM335X/latest/index_FDS.html
>>  
>> <http://software-dl.ti.com/processor-sw/esd/PROCESSOR-SDK-LINUX-AM335X/latest/index_FDS.html>).
>> 
>> I compiled the sample program for PRU (toggle_led.out) and copy it over in 
>> /lib/firmware/am335x-pru0-fw, but it did not work.
>> 
>> Then, I found Robert Nelson's binary and it works fine.
>> 
>> https://github.com/RobertCNelson/boot-scripts/commit/20a16f79be80886a1e030d197573b5950f98626d#diff-a0ab1dbc32ef29215c473f3b8979ad32
>>  
>> <https://github.com/RobertCNelson/boot-scripts/commit/20a16f79be80886a1e030d197573b5950f98626d#diff-a0ab1dbc32ef29215c473f3b8979ad32>
>> 
>> 
>> Any idea?.
>> 
>> Regards,
>> 
>> John
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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] PRU

[John Syne]

Or you can use the latest examples from here:

https://git.ti.com/pru-software-support-package/pru-software-support-package 


Regards,
John




> On Mar 23, 2016, at 1:54 PM, John Tobias  wrote:
> 
> Hello Guys,
> 
> I am using debian image version 8.3 that I downloaded @ 
> http://beagleboard.org/latest-images  
> (4.1.15-ti-rt-r43). Also, I downloaded the TI SDK for AM335x 
> (http://software-dl.ti.com/processor-sw/esd/PROCESSOR-SDK-LINUX-AM335X/latest/index_FDS.html
>  
> ).
> 
> I compiled the sample program for PRU (toggle_led.out) and copy it over in 
> /lib/firmware/am335x-pru0-fw, but it did not work.
> 
> Then, I found Robert Nelson's binary and it works fine.
> 
> https://github.com/RobertCNelson/boot-scripts/commit/20a16f79be80886a1e030d197573b5950f98626d#diff-a0ab1dbc32ef29215c473f3b8979ad32
>  
> 
> 
> 
> Any idea?.
> 
> 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] PRU

[John Syne]

Did you add this?

http://processors.wiki.ti.com/index.php/Processor_SDK_PRU-ICSS_Add_On_Package 


Regards,
John




> On Mar 23, 2016, at 1:54 PM, John Tobias  wrote:
> 
> Hello Guys,
> 
> I am using debian image version 8.3 that I downloaded @ 
> http://beagleboard.org/latest-images  
> (4.1.15-ti-rt-r43). Also, I downloaded the TI SDK for AM335x 
> (http://software-dl.ti.com/processor-sw/esd/PROCESSOR-SDK-LINUX-AM335X/latest/index_FDS.html
>  
> ).
> 
> I compiled the sample program for PRU (toggle_led.out) and copy it over in 
> /lib/firmware/am335x-pru0-fw, but it did not work.
> 
> Then, I found Robert Nelson's binary and it works fine.
> 
> https://github.com/RobertCNelson/boot-scripts/commit/20a16f79be80886a1e030d197573b5950f98626d#diff-a0ab1dbc32ef29215c473f3b8979ad32
>  
> 
> 
> 
> Any idea?.
> 
> 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] RPMsg from Linux User Space to PRU on Beaglebone Black

[John Syne]

Don’t include the .ko extension when using modprobe.

Regards,
John




> On Mar 23, 2016, at 9:32 AM, lucas  wrote:
> 
> Sorry forgot to copy the error message for the modprobe command: 
> 
> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# modprobe 
> virtio_rpmsg_bus.ko
> modprobe: FATAL: Module virtio_rpmsg_bus.ko not found.
> 
> On Wednesday, March 23, 2016 at 5:27:12 PM UTC+1, lucas wrote:
> Hi John, 
> 
> thank you very much for your answer. 
> 
> I am using the 4.1.15-ti-rt-r43 kernel. It's the kernel that came with the 
> debian image from the beaglebone website.  
> 
> Only the pruss_remoteproc module seems to be loaded on boot:
> 
> # lsmod
> Module  Size  Used by
> 8021q  17336  0
> garp5975  1 8021q
> mrp 7322  1 8021q
> stp 1911  1 garp
> llc 5257  2 stp,garp
> pruss_remoteproc   15296  2
> omap_rng4358  0
> rng_core7437  1 omap_rng
> usb_f_acm   7180  1
> u_serial   10596  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
> snd_soc_davinci_mcasp17266  0
> snd_soc_edma1150  1 snd_soc_davinci_mcasp
> spi_omap2_mcspi10681  0
> uio_pdrv_genirq 3521  0
> 
> Although the other modules do exist in the driver directory.
> 
> ls /lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg
> rpmsg_pru.ko  rpmsg-rpc.ko  virtio_rpmsg_bus.ko
> 
> I cannot modprob the modules:
> 
> # modprobe virtio_rpmsg_bus.ko
> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# modprobe 
> virtio_rpmsg_bus.ko
> 
> 
> But I can use insmod 
> 
> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# insmod 
> virtio_rpmsg_bus.ko
> root@beaglebone:/lib/modules/4.1.15-ti-rt-r43/kernel/drivers/rpmsg# lsmod
> Module  Size  Used by
> virtio_rpmsg_bus   13437  0
> 8021q  17336  0
> garp5975  1 8021q
> ...
> 
> 
> Should I try to switch to the kernel version you are using? Is there an image 
> or should I recompile the kernel? Any other ideas? 
> 
> Lucas
> 
> On Tuesday, March 22, 2016 at 7:40:56 PM UTC+1, john3909 wrote:
> Hi Lucas,
> 
> This seems to work just fine for me. What kernel version are you using?
> 
> I’m using V4.1.13-ti-r33. As you can see, all remoteproc/rpmsg kernel modules 
> are loaded automatically at boot time.
> 
> [   16.251480] pruss-rproc 4a30.pruss: 8 PRU interrupts parsed
> 
> [   16.251567] pruss-rproc 4a30.pruss: memorydram0: pa 0x4a30 
> size 0x2000 va e0ca 
> [   16.251595] pruss-rproc 4a30.pruss: memorydram1: pa 0x4a302000 
> size 0x2000 va e0ca4000 
> [   16.251621] pruss-rproc 4a30.pruss: memory shrdram2: pa 0x4a31 
> size 0x3000 va e0ca8000 
> [   16.251644] pruss-rproc 4a30.pruss: memory intc: pa 0x4a32 
> size 0x2000 va e0cac000 
> [   16.251672] pruss-rproc 4a30.pruss: memory  cfg: pa 0x4a326000 
> size 0x2000 va e0cb 
> [   16.252174] pruss-rproc 4a30.pruss: creating platform devices for PRU 
> cores
> [   16.374800] pru-rproc 4a334000.pru0: memory iram: pa 0x4a334000 size 
> 0x2000 va e0cb4000
> [   16.374858] pru-rproc 4a334000.pru0: memory  control: pa 0x4a322000 size 
> 0x400 va e0876000 
> [   16.374901] pru-rproc 4a334000.pru0: memorydebug: pa 0x4a322400 size 
> 0x100 va e0c9e400 
> [   16.375152]  remoteproc1: 4a334000.pru0 is available   
> 
> [   16.380153]  remoteproc1: Note: remoteproc is still under development and 
> considered experimental. 
> [   16.572902]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
> backward compatibility isn't yet guaranteed. 
> [   16.778752]  remoteproc1: registered virtio0 (type 7)  
> 
> [   16.811201] pru-rproc 4a334000.pru0: PRU rproc node 
> /ocp/pruss@4a30/pru@4a334000 probed successfully   
> [   16.932818] pru-rproc 4a338000.pru1: memory iram: pa 0x4a338000 size 
> 0x2000 va e0ccc000
> [   16.932891] pru-rproc 4a338000.pru1: memory  control: pa 0x4a324000 size 
> 0x400 va e0cd 

Re: [beagleboard] SPI BBB Master, BBB Slave

[John Syne]

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 dts:
>   0x150 0x10  /* spi0_sclk, OUTPUT_PULLUP | MODE0 */
>   0x154 0x30  /* spi0_d0, INPUT_PULLUP | MODE0 */
>   0x158 0x10  /* spi0_d1, OUTPUT_PULLUP | MODE0 */
>   0x15c 0x10  /* spi0_cs0, OUTPUT_PULLUP | MODE0 */
> 
> spi slave dts:
>   0x150 0x30  /* spi0_sclk, INPUT_PULLUP | MODE0 */
>   0x154 0x10  /* spi0_d0, OUTPUT_PULLUP | MODE0 */
>   0x158 0x30  /* spi0_d1, INPUT_PULLUP | MODE0 */
>   0x15c 0x30  /* spi0_cs0, INPUT_PULLUP | MODE0 */
> 
> 
> The oscilloscope shows activity when spi0_sckl (P9_17) is not connected but 
> nothing when P9_17 is connected between both boards. 
> I am sending bytes from master with the command: echo 1 > /dev/spidev1.0
> 
> I need 4-8mbit/sec transfer, is this achievable by bit banging over GPIO and 
> would that be a viable alternative to getting SPI working?
> 
> 
> -- 
> 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] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

[John Syne]

For someone who has been "working with products like this for 18 years", you 
would think he would be able to help himself by now. Yet he still thinks he is 
smarter than the rest of us, advising us to “leave this BBB”. Well, Karl, there 
are many more smarter people here who think BBB is way better than Raspberry Pi 
because of the open source hardware design, unlike the proprietary hardware 
design of the Raspberry Pi. You cannot even by the processor used on the 
Raspberry Pi. I think you have completely missed the value offered by the 
BeagleBoard organization. In addition, the BBB includes two PRU processors who 
have a cycle time of 5ns which is very important for realtime control 
functions. Cannot do that with the Raspberry Pi. Clearly you have no clue, so 
your advise has no value here. 

Regards,
John




> On Mar 22, 2016, at 4:42 PM, Karl Easterly  wrote:
> 
> to be a bit more nice about my grandious statement that the BBB is dead.. 
> here is a bit of history.
> 
> I have been working with products like this for about 18 years. Small form 
> factor boards like the basic stamps and zworld jack rabbits to todays rasp 
> pi's and bbb's and the banana pros and such and such
> 
> the raspberry has a great community.. and the BBB doesnt. I have had numerous 
> instances where i was using the BBB and found an issue and there are only 
> crickets sounding on google.
> 
> I am not saying the BBB is a bad board as it is clearly a nice peice of 
> engineering.. i am saying the product BBB will pass into the past while the 
> rasp pi will persist.
> 
> id advise you leave this BBB behind as it has no value looking toward the 
> future. this ship has sunk.
> 
> and thats a bummer in many ways.
> 
> On Mar 22, 2016 7:27 PM, "ChrisB"  > wrote:
> My experience has been quite different.  Pretty much all the progress I've 
> made with the BBB was enabled by various forum posts and code repositories.  
> And every time I think I have an original question or observation, a little 
> searching online finds the answer or a similar developer experience.  It's 
> not easy getting things to work some of the time, but tenaciousness pays off 
> for the most part.
> 
> Anyway, thanks to everyone who's spent the time to post on forums and share 
> their code!  Hopefully, I will have something to contribute in the near 
> future and can start paying you all back.
> 
> Chris Burak
> 
> On Tuesday, March 22, 2016 at 4:58:27 PM UTC-6, Karl Easterly wrote:
> Ya.. I didn't ask for help.. as you noticed :)
> 
> The point is the community for the beagle board is so sparse self help is not 
> an option. A sparse community around this type of product equals a dead 
> product.
> 
> On Sun, Mar 20, 2016 at 4:32 PM, Robert P. J. Day > 
> wrote:
> Quoting Robert Nelson >:
> 
> On Mar 20, 2016 2:28 PM, "Karl Easterly" > wrote:
> 
> It's clear that the BBB is a dead product. There is no meaningful
> resources for issues, and when the system simply won't 'reset from a new
> image from their site'... that's the last straw.
> 
> Mine are going in the trash and I will advise anyone everywhere to do the
> same.
> 
> 'Last straw', I've don't remember you ever posting on here.. If it's only
> one and done for you, then there's no reason for me to waste time either..
> 
>   how *dare* everyone not drop what they're doing ***right now*** and
> solve my problem during the first weekend of march madness?
> 
> rday
> 
> 
> 
> 
> -- 
> 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] RPMsg from Linux User Space to PRU on Beaglebone Black

[John Syne]

Hi Lucas,

This seems to work just fine for me. What kernel version are you using?

I’m using V4.1.13-ti-r33. As you can see, all remoteproc/rpmsg kernel modules 
are loaded automatically at boot time.

[   16.251480] pruss-rproc 4a30.pruss: 8 PRU interrupts parsed  
  
[   16.251567] pruss-rproc 4a30.pruss: memorydram0: pa 0x4a30 size 
0x2000 va e0ca 
[   16.251595] pruss-rproc 4a30.pruss: memorydram1: pa 0x4a302000 size 
0x2000 va e0ca4000 
[   16.251621] pruss-rproc 4a30.pruss: memory shrdram2: pa 0x4a31 size 
0x3000 va e0ca8000 
[   16.251644] pruss-rproc 4a30.pruss: memory intc: pa 0x4a32 size 
0x2000 va e0cac000 
[   16.251672] pruss-rproc 4a30.pruss: memory  cfg: pa 0x4a326000 size 
0x2000 va e0cb 
[   16.252174] pruss-rproc 4a30.pruss: creating platform devices for PRU 
cores
[   16.374800] pru-rproc 4a334000.pru0: memory iram: pa 0x4a334000 size 
0x2000 va e0cb4000
[   16.374858] pru-rproc 4a334000.pru0: memory  control: pa 0x4a322000 size 
0x400 va e0876000 
[   16.374901] pru-rproc 4a334000.pru0: memorydebug: pa 0x4a322400 size 
0x100 va e0c9e400 
[   16.375152]  remoteproc1: 4a334000.pru0 is available 
  
[   16.380153]  remoteproc1: Note: remoteproc is still under development and 
considered experimental. 
[   16.572902]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
backward compatibility isn't yet guaranteed. 
[   16.778752]  remoteproc1: registered virtio0 (type 7)
  
[   16.811201] pru-rproc 4a334000.pru0: PRU rproc node 
/ocp/pruss@4a30/pru@4a334000 probed successfully   
[   16.932818] pru-rproc 4a338000.pru1: memory iram: pa 0x4a338000 size 
0x2000 va e0ccc000
[   16.932891] pru-rproc 4a338000.pru1: memory  control: pa 0x4a324000 size 
0x400 va e0cd 
[   16.932918] pru-rproc 4a338000.pru1: memorydebug: pa 0x4a324400 size 
0x100 va e0cd2400 
[   16.933190]  remoteproc2: 4a338000.pru1 is available 
  
[   16.938192]  remoteproc2: Note: remoteproc is still under development and 
considered experimental. 
[   17.081421]  remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and 
backward compatibility isn't yet guaranteed. 
[   17.114912]  remoteproc2: registered virtio1 (type 7)
  
[   17.131205] pru-rproc 4a338000.pru1: PRU rproc node 
/ocp/pruss@4a30/pru@4a338000 probed successfully   
[   17.231951]  remoteproc1: powering up 4a334000.pru0  
  
[   17.243111]  remoteproc1: Booting fw image am335x-pru0-fw, size 78652
  
[   17.271252] pru-rproc 4a334000.pru0: version 0 event_chnl_map_size 1 
event_chnl_map 039c   
[   17.271289] pru-rproc 4a334000.pru0: sysevt-to-ch[60] -> 0   
  
[   17.271305] pru-rproc 4a334000.pru0: chnl-to-host[0] -> 0
  
[   17.271318] pru-rproc 4a334000.pru0: skip intr mapping for chnl 1
  
[   17.271330] pru-rproc 4a334000.pru0: skip intr mapping for chnl 2
  
[   17.271343] pru-rproc 4a334000.pru0: skip intr mapping for chnl 3
  
[   17.271355] pru-rproc 4a334000.pru0: skip intr mapping for chnl 4
  
[   17.271367] pru-rproc 4a334000.pru0: skip intr mapping for chnl 5
  
[   17.271379] pru-rproc 4a334000.pru0: skip intr mapping for chnl 6
  
[   17.271391] pru-rproc 4a334000.pru0: skip intr mapping for chnl 7
  
[   17.271404] pru-rproc 4a334000.pru0: skip intr mapping for chnl 8
  
[   17.271416] pru-rproc 4a334000.pru0: 

Re: [beagleboard] bbb Internal ADC configuration settings?

[John Syne]

What is your kernel version?

Regards,
John




> On Mar 18, 2016, at 1:22 PM, Audrey  wrote:
> 
> It says:
> root@beaglebone:/# echo 1 > 
> /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
> -bash: /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en: No such 
> file or directory
> 
> and I can't find scan_elements in sys/bus/iio/devices/iio:device0
> root@beaglebone:/sys/bus/iio/devices/iio:device0# ls -l
> total 0
> -r--r--r-- 1 root root 4096 Mar  1 21:13 dev
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage0_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage1_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage2_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage3_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage4_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage5_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage6_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage7_raw
> -r--r--r-- 1 root root 4096 Mar  1 21:13 name
> drwxr-xr-x 2 root root0 Mar  1 21:13 power
> lrwxrwxrwx 1 root root0 Mar  1 20:47 subsystem -> ../../../../../bus/iio
> -rw-r--r-- 1 root root 4096 Mar  1 20:47 uevent
> 
> 
> On Friday, March 18, 2016 at 4:15:00 PM UTC-4, john3909 wrote:
> 
>> On Mar 18, 2016, at 1:06 PM, Audrey > wrote:
>> 
>> Hm. 
>> 
>> Sorry, but unfortunately I'm still quite a bit lost. What should I be doing 
>> to dev/iio:device0 (open?) in order to do the following:
>> echo 1 > in_voltage0_en
> From memory, 
> 
> echo 1 > /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
>> echo 1 > buffer/enable
> echo 1 > /sys/bus/iio/devices/iio:device0/buffer/enable
> 
> Regards,
> John
>> 
>> I'm assuming that I should be able to see in_voltage0_en and buffer in the 
>> folder /sys/bus/iio/devices/iio:device0 but I currently do not see those 
>> attributes/drivers/folders/buffers/whatever-you-want-to-call-them.
>> 
>> Typing 
>> root@beaglebone:/dev# open iio:device0
>> doesn't seem to do anything.
>> 
>> Do you think you could break your steps down even further?
>> 
>> Thanks.
>> 
>> On Friday, March 18, 2016 at 3:49:39 PM UTC-4, john3909 wrote:
>> It is a driver, so you can open, poll and read from /dev/iio:device0
>> 
>> For a quick test, do the following: After you enable the various 
>> scan_channels, start the buffer and then do the following:
>> 
>> dd if=/dev/iio:device0 of=~/test.txt
>> 
>> Press ctrl-C to stop capture.
>> 
>> Use hexdump to view the file. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Mar 18, 2016, at 12:37 PM, Audrey smith.edu 
>>> > wrote:
>>> 
>>> It says:
>>> root@beaglebone:/dev# cd iio:device0
>>> -bash: cd: iio:device0: Not a directory
>>> root@beaglebone:/dev# cat iio:device0
>>> cat: iio:device0: Invalid argument
>>> 
>>> 
>>> On Friday, March 18, 2016 at 3:25:13 PM UTC-4, john3909 wrote:
>>> The buffer is available here:
>>> 
>>> /dev/iio:device0
>>> 
>>> Because the driver uses interrupts, you won’t get the speed you want. The 
>>> driver has to be updated to use DMA if you want to use full speed. Reading 
>>> from the buffer will reduce your CPU load compared to using LDR_PATH 
>>> because this interface blocks until a sample is available, but not long 
>>> enough for the thread to sleep. To use DMA, IIO have introduced a DMA 
>>> framework and most of what you need is already available. However, IIO are 
>>> going to be updating the IIO DMA framework to do zero copy between the 
>>> kernel module and the socket interface, using MMU maps. 
>>> 
>>> Regards,
>>> John
>>> 
>>> 
>>> 
>>> 
 On Mar 18, 2016, at 11:21 AM, Audrey smith.edu 
 > wrote:
 
 Hi everyone,
 
 First of all, thank you everyone for trying to help me. I appreciate 
 everyone's input.
 
 I took everyone's advice, and have moved away from bash to C++. It's 
 clocking at about 2 milliseconds, but I would really like it to go down 
 into the microsecond range:
 /** Simple LDR Reading Application
 * 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.*/
  
 #include
 #include
 #include
 #include
 using namespace std;
  
 #define LDR_PATH "/sys/bus/iio/devices/iio:device0/in_voltage"
  
 int readAnalog(int number)
 {
stringstream ss;
ss << LDR_PATH << number << "_raw";
fstream fs;
fs.open(ss.str().c_str(), fstream::in);
fs >> number;
fs.close();
return number;
 }
  
 int main(int argc, char* argv[])
 {
cout << "Starting the readLDR program" << endl;
int value;
int i=1;
while (true)
{
  

Re: [beagleboard] bbb Internal ADC configuration settings?

[John Syne]

root@beaglebone:/sys/bus/iio/devices/iio:device0# tree
.
├── buffer
│   ├── enable
│   ├── length
│   └── watermark
├── dev
├── in_voltage0_raw
├── in_voltage1_raw
├── in_voltage2_raw
├── in_voltage3_raw
├── in_voltage4_raw
├── in_voltage5_raw
├── in_voltage6_raw
├── name
├── of_node -> 
../../../../../../firmware/devicetree/base/ocp/tscadc@44e0d000/adc
├── power
│   ├── async
│   ├── autosuspend_delay_ms
│   ├── control
│   ├── runtime_active_kids
│   ├── runtime_active_time
│   ├── runtime_enabled
│   ├── runtime_status
│   ├── runtime_suspended_time
│   └── runtime_usage
├── scan_elements
│   ├── in_voltage0_en
│   ├── in_voltage0_index
│   ├── in_voltage0_type
│   ├── in_voltage1_en
│   ├── in_voltage1_index
│   ├── in_voltage1_type
│   ├── in_voltage2_en
│   ├── in_voltage2_index
│   ├── in_voltage2_type
│   ├── in_voltage3_en
│   ├── in_voltage3_index
│   ├── in_voltage3_type
│   ├── in_voltage4_en
│   ├── in_voltage4_index
│   ├── in_voltage4_type
│   ├── in_voltage5_en
│   ├── in_voltage5_index
│   ├── in_voltage5_type
│   ├── in_voltage6_en
│   ├── in_voltage6_index
│   └── in_voltage6_type
├── subsystem -> ../../../../../../bus/iio
└── uevent

Regards,
John




> On Mar 18, 2016, at 1:22 PM, Audrey  wrote:
> 
> It says:
> root@beaglebone:/# echo 1 > 
> /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
> -bash: /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en: No such 
> file or directory
> 
> and I can't find scan_elements in sys/bus/iio/devices/iio:device0
> root@beaglebone:/sys/bus/iio/devices/iio:device0# ls -l
> total 0
> -r--r--r-- 1 root root 4096 Mar  1 21:13 dev
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage0_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage1_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage2_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage3_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage4_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage5_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage6_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage7_raw
> -r--r--r-- 1 root root 4096 Mar  1 21:13 name
> drwxr-xr-x 2 root root0 Mar  1 21:13 power
> lrwxrwxrwx 1 root root0 Mar  1 20:47 subsystem -> ../../../../../bus/iio
> -rw-r--r-- 1 root root 4096 Mar  1 20:47 uevent
> 
> 
> On Friday, March 18, 2016 at 4:15:00 PM UTC-4, john3909 wrote:
> 
>> On Mar 18, 2016, at 1:06 PM, Audrey > wrote:
>> 
>> Hm. 
>> 
>> Sorry, but unfortunately I'm still quite a bit lost. What should I be doing 
>> to dev/iio:device0 (open?) in order to do the following:
>> echo 1 > in_voltage0_en
> From memory, 
> 
> echo 1 > /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
>> echo 1 > buffer/enable
> echo 1 > /sys/bus/iio/devices/iio:device0/buffer/enable
> 
> Regards,
> John
>> 
>> I'm assuming that I should be able to see in_voltage0_en and buffer in the 
>> folder /sys/bus/iio/devices/iio:device0 but I currently do not see those 
>> attributes/drivers/folders/buffers/whatever-you-want-to-call-them.
>> 
>> Typing 
>> root@beaglebone:/dev# open iio:device0
>> doesn't seem to do anything.
>> 
>> Do you think you could break your steps down even further?
>> 
>> Thanks.
>> 
>> On Friday, March 18, 2016 at 3:49:39 PM UTC-4, john3909 wrote:
>> It is a driver, so you can open, poll and read from /dev/iio:device0
>> 
>> For a quick test, do the following: After you enable the various 
>> scan_channels, start the buffer and then do the following:
>> 
>> dd if=/dev/iio:device0 of=~/test.txt
>> 
>> Press ctrl-C to stop capture.
>> 
>> Use hexdump to view the file. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Mar 18, 2016, at 12:37 PM, Audrey smith.edu 
>>> > wrote:
>>> 
>>> It says:
>>> root@beaglebone:/dev# cd iio:device0
>>> -bash: cd: iio:device0: Not a directory
>>> root@beaglebone:/dev# cat iio:device0
>>> cat: iio:device0: Invalid argument
>>> 
>>> 
>>> On Friday, March 18, 2016 at 3:25:13 PM UTC-4, john3909 wrote:
>>> The buffer is available here:
>>> 
>>> /dev/iio:device0
>>> 
>>> Because the driver uses interrupts, you won’t get the speed you want. The 
>>> driver has to be updated to use DMA if you want to use full speed. Reading 
>>> from the buffer will reduce your CPU load compared to using LDR_PATH 
>>> because this interface blocks until a sample is available, but not long 
>>> enough for the thread to sleep. To use DMA, IIO have introduced a DMA 
>>> framework and most of what you need is already available. However, IIO are 
>>> going to be updating the IIO DMA framework to do zero copy between the 
>>> kernel module and the socket interface, using MMU maps. 
>>> 
>>> Regards,
>>> John
>>> 
>>> 
>>> 
>>> 
 On Mar 18, 2016, at 11:21 AM, Audrey smith.edu 
 > wrote:
 
 Hi everyone,
 
 First of all, thank you everyone for trying to help me. I appreciate 
 everyone's input.
 

Re: [beagleboard] bbb Internal ADC configuration settings?

[John Syne]

It is a driver, so you can open, poll and read from /dev/iio:device0

For a quick test, do the following: After you enable the various scan_channels, 
start the buffer and then do the following:

dd if=/dev/iio:device0 of=~/test.txt

Press ctrl-C to stop capture.

Use hexdump to view the file. 

Regards,
John




> On Mar 18, 2016, at 12:37 PM, Audrey  wrote:
> 
> It says:
> root@beaglebone:/dev# cd iio:device0
> -bash: cd: iio:device0: Not a directory
> root@beaglebone:/dev# cat iio:device0
> cat: iio:device0: Invalid argument
> 
> 
> On Friday, March 18, 2016 at 3:25:13 PM UTC-4, john3909 wrote:
> The buffer is available here:
> 
> /dev/iio:device0
> 
> Because the driver uses interrupts, you won’t get the speed you want. The 
> driver has to be updated to use DMA if you want to use full speed. Reading 
> from the buffer will reduce your CPU load compared to using LDR_PATH because 
> this interface blocks until a sample is available, but not long enough for 
> the thread to sleep. To use DMA, IIO have introduced a DMA framework and most 
> of what you need is already available. However, IIO are going to be updating 
> the IIO DMA framework to do zero copy between the kernel module and the 
> socket interface, using MMU maps. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 18, 2016, at 11:21 AM, Audrey smith.edu 
>> > wrote:
>> 
>> Hi everyone,
>> 
>> First of all, thank you everyone for trying to help me. I appreciate 
>> everyone's input.
>> 
>> I took everyone's advice, and have moved away from bash to C++. It's 
>> clocking at about 2 milliseconds, but I would really like it to go down into 
>> the microsecond range:
>> /** Simple LDR Reading Application
>> * 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.*/
>>  
>> #include
>> #include
>> #include
>> #include
>> using namespace std;
>>  
>> #define LDR_PATH "/sys/bus/iio/devices/iio:device0/in_voltage"
>>  
>> int readAnalog(int number)
>> {
>>stringstream ss;
>>ss << LDR_PATH << number << "_raw";
>>fstream fs;
>>fs.open(ss.str().c_str(), fstream::in);
>>fs >> number;
>>fs.close();
>>return number;
>> }
>>  
>> int main(int argc, char* argv[])
>> {
>>cout << "Starting the readLDR program" << endl;
>>int value;
>>int i=1;
>>while (true)
>>{
>>  float value = (float)readAnalog(0)/4095*1.8;
>>  cout <<"V= " << value << endl;
>>  cout << i << endl;
>>  i++;
>>}
>>return 0;
>> }
>> 
>> Thank you TJF for pointing me to libpruio. I'll use it later if I need it, 
>> but for now I rather not use the PRU if I don't need to.
>> 
>> So I noticed this thing where I can't see the buffer, or scan_elements, or 
>> mode in iio:device0, and I wonder if I'm not enabling the adc dto properly 
>> or something:
>> root@beaglebone:/sys/bus/iio/devices/iio:device0# ls -l
>> total 0
>> -r--r--r-- 1 root root 4096 Mar  1 20:51 dev
>> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage0_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage1_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage2_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage3_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage4_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage5_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage6_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage7_raw
>> -r--r--r-- 1 root root 4096 Mar  1 20:51 name
>> drwxr-xr-x 2 root root0 Mar  1 20:51 power
>> lrwxrwxrwx 1 root root0 Mar  1 20:50 subsystem -> ../../../../../bus/iio
>> -rw-r--r-- 1 root root 4096 Mar  1 20:50 uevent
>> 
>> This is what I've been doing to "enable" the adc (although I don't really 
>> know what it is doing. I can't find the file cape-bone-iio in bbb, and if I 
>> try echo cape-bone-iio > test.txt, it is just a regular string.):
>> echo cape-bone-iio > /sys/devices/bone_capemgr.*/slots
>> 
>> I tried searching for /driver/iio/adc/ti_am335x_adc.c, but I can't find it 
>> (there's nothing in root@beaglebone:/sys/bus/iio/drivers#). Could you 
>> perhaps specify the full filepath?
>> 
>> 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...@ <>googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this 

Re: [beagleboard] bbb Internal ADC configuration settings?

[John Syne]

The buffer is available here:

/dev/iio:device0

Because the driver uses interrupts, you won’t get the speed you want. The 
driver has to be updated to use DMA if you want to use full speed. Reading from 
the buffer will reduce your CPU load compared to using LDR_PATH because this 
interface blocks until a sample is available, but not long enough for the 
thread to sleep. To use DMA, IIO have introduced a DMA framework and most of 
what you need is already available. However, IIO are going to be updating the 
IIO DMA framework to do zero copy between the kernel module and the socket 
interface, using MMU maps. 

Regards,
John




> On Mar 18, 2016, at 11:21 AM, Audrey  wrote:
> 
> Hi everyone,
> 
> First of all, thank you everyone for trying to help me. I appreciate 
> everyone's input.
> 
> I took everyone's advice, and have moved away from bash to C++. It's clocking 
> at about 2 milliseconds, but I would really like it to go down into the 
> microsecond range:
> /** Simple LDR Reading Application
> * 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.*/
>  
> #include
> #include
> #include
> #include
> using namespace std;
>  
> #define LDR_PATH "/sys/bus/iio/devices/iio:device0/in_voltage"
>  
> int readAnalog(int number)
> {
>stringstream ss;
>ss << LDR_PATH << number << "_raw";
>fstream fs;
>fs.open(ss.str().c_str(), fstream::in);
>fs >> number;
>fs.close();
>return number;
> }
>  
> int main(int argc, char* argv[])
> {
>cout << "Starting the readLDR program" << endl;
>int value;
>int i=1;
>while (true)
>{
>  float value = (float)readAnalog(0)/4095*1.8;
>  cout <<"V= " << value << endl;
>  cout << i << endl;
>  i++;
>}
>return 0;
> }
> 
> Thank you TJF for pointing me to libpruio. I'll use it later if I need it, 
> but for now I rather not use the PRU if I don't need to.
> 
> So I noticed this thing where I can't see the buffer, or scan_elements, or 
> mode in iio:device0, and I wonder if I'm not enabling the adc dto properly or 
> something:
> root@beaglebone:/sys/bus/iio/devices/iio:device0# ls -l
> total 0
> -r--r--r-- 1 root root 4096 Mar  1 20:51 dev
> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage0_raw
> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage1_raw
> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage2_raw
> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage3_raw
> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage4_raw
> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage5_raw
> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage6_raw
> -rw-r--r-- 1 root root 4096 Mar  1 22:03 in_voltage7_raw
> -r--r--r-- 1 root root 4096 Mar  1 20:51 name
> drwxr-xr-x 2 root root0 Mar  1 20:51 power
> lrwxrwxrwx 1 root root0 Mar  1 20:50 subsystem -> ../../../../../bus/iio
> -rw-r--r-- 1 root root 4096 Mar  1 20:50 uevent
> 
> This is what I've been doing to "enable" the adc (although I don't really 
> know what it is doing. I can't find the file cape-bone-iio in bbb, and if I 
> try echo cape-bone-iio > test.txt, it is just a regular string.):
> echo cape-bone-iio > /sys/devices/bone_capemgr.*/slots
> 
> I tried searching for /driver/iio/adc/ti_am335x_adc.c, but I can't find it 
> (there's nothing in root@beaglebone:/sys/bus/iio/drivers#). Could you perhaps 
> specify the full filepath?
> 
> 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] Debugging with beaglebone black

[John Syne]

CCSV4 was partially aware, but CCSV5 and CCSV6 are not.

http://processors.wiki.ti.com/index.php/Linux_Aware_Debug_(CCSv4.x) 
<http://processors.wiki.ti.com/index.php/Linux_Aware_Debug_(CCSv4.x)>

Regards,
John




> On Mar 18, 2016, at 2:29 PM, Mark Lazarewicz <lazar...@yahoo.com> wrote:
> 
> John I remember using Lauterbach to do this isn't CCS  kernel aware? 
> 
> Sent from Yahoo Mail on Android 
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
> On Fri, Mar 18, 2016 at 1:24 PM, John Syne
> <john3...@gmail.com> wrote:
> Problem with GDB, is you cannot start the debugger until after the kernel 
> module is loaded, which means no debugging of init or probe sections. The 
> reason is GDB doesn’t know where in memory the kernel module is loaded until 
> after it is loaded. This is why you need a kernel aware debugger like 
> Lauterbach which loads the kernel module code, loads the debug symbols and 
> breaks at the start of init. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 18, 2016, at 1:50 AM, William Hermans <yyrk...@gmail.com 
>> > wrote:
>> 
>> https://www.google.com/search?q=how+to+debug+linux+kernel+modules 
>> <https://www.google.com/search?q=how+to+debug+linux+kernel+modules>
>> 
>> Just like you would on any platform.
>> 
>> On Thu, Mar 17, 2016 at 8:46 PM, John Syne <john3...@gmail.com 
>> > wrote:
>> To debug kernel modules with JTAG, you have to have a debugger which is 
>> kernel aware like Lauterbach. If you don’t want to use JTAG, then use printk 
>> or dev-dbg, dev-err, etc. You can also use ftrace, which requires you to 
>> build your own kernel and add support for the various ftrace features. Read 
>> kernel docs under documentation/trace/ftrace.txt to learn more.
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Mar 17, 2016, at 7:49 PM, cmajor.merch...@gmail.com  
>>> wrote:
>>> 
>>> I have a question about the beaglebone black. How am suppose to debug with 
>>> it? I really would prefer not to have to solder a JTAG header. Also the 
>>> JTAG header would be under the board which is really inconvenient. The case 
>>> that came with my board also has no room for the JTAG header so it would 
>>> basically render the case useless. I know it has a serial debug header but 
>>> how could I debug with it? I want to debug kernel modules.
>>> 
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss 
>>> <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 
>>> <https://groups.google.com/d/optout>.
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <https://groups.google.com/d/optout>.
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <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] bbb Internal ADC configuration settings?

[John Syne]

Yeah, that is what I thought. IIO on the 3.8 kernel didn’t have a lot of 
features and this is why you are having difficulty using it. I would recommend 
upgrading to the 4.1 kernel or even the 4.4 kernel. I personally use the 4.1 
kernel, but I back ported IIO from the IIO-next kernel so that I am using the 
latest IIO which includes DMA framework support. 

Regards,
John




> On Mar 19, 2016, at 9:46 AM, Audrey <a...@smith.edu> wrote:
> 
> Hi William, I did read that article you sent me. I was unable to follow the 
> Driver Configuration bit, but as far as the continuous mode is concerned, 
> after careful re-reading of the article, I think I understand that you are 
> trying to tell me that I should be in the /dev/iio:device0 directory to read 
> the continuous mode. However, my problem is that buffer, scan_elements, and 
> mode, which the article says are used to set up the continuous mode, should 
> be in the /sys/bus/iio/devices/iio:device0 directory. And that was where I 
> was in, but I could not find them, which is my current problem. 
> 
> John3909, my kernel version is 3.8.13-bone70.
> 
> I think if this doesn't pan out, I will be looking into using the PRU, 
> although I would like to understand the current system better before moving 
> on to something more complicated.
> 
> Thanks everyone for your help!
> 
> On Friday, March 18, 2016 at 5:59:01 PM UTC-4, William Hermans wrote:
> Audrey,
> 
> Please read the link I gave you a couple weeks ago . . . 
> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#Continuous_Mode
>  
> <http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#Continuous_Mode>
> 
> Everything you need to know to use the ADC is explained on this page. But 
> from your last post, and the paths you've shown us. You're in the wrong 
> directory. Essentially, you're still in the one-shot directories, which are 
> completely separate from the continuous mode directory structure.
> 
> On Fri, Mar 18, 2016 at 1:46 PM, John Syne <john...@gmail.com > 
> wrote:
> What is your kernel version?
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 18, 2016, at 1:22 PM, Audrey <ao...@smith.edu > wrote:
>> 
>> It says:
>> root@beaglebone:/# echo 1 > 
>> /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
>> -bash: /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en: No such 
>> file or directory
>> 
>> and I can't find scan_elements in sys/bus/iio/devices/iio:device0
>> root@beaglebone:/sys/bus/iio/devices/iio:device0# ls -l
>> total 0
>> -r--r--r-- 1 root root 4096 Mar  1 21:13 dev
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage0_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage1_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage2_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage3_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage4_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage5_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage6_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage7_raw
>> -r--r--r-- 1 root root 4096 Mar  1 21:13 name
>> drwxr-xr-x 2 root root0 Mar  1 21:13 power
>> lrwxrwxrwx 1 root root0 Mar  1 20:47 subsystem -> ../../../../../bus/iio
>> -rw-r--r-- 1 root root 4096 Mar  1 20:47 uevent
>> 
>> 
>> On Friday, March 18, 2016 at 4:15:00 PM UTC-4, john3909 wrote:
>> 
>>> On Mar 18, 2016, at 1:06 PM, Audrey <ao...@smith.edu <>> wrote:
>>> 
>>> Hm. 
>>> 
>>> Sorry, but unfortunately I'm still quite a bit lost. What should I be doing 
>>> to dev/iio:device0 (open?) in order to do the following:
>>> echo 1 > in_voltage0_en
>> From memory, 
>> 
>> echo 1 > /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
>>> echo 1 > buffer/enable
>> echo 1 > /sys/bus/iio/devices/iio:device0/buffer/enable
>> 
>> Regards,
>> John
>>> 
>>> I'm assuming that I should be able to see in_voltage0_en and buffer in the 
>>> folder /sys/bus/iio/devices/iio:device0 but I currently do not see those 
>>> attributes/drivers/folders/buffers/whatever-you-want-to-call-them.
>>> 
>>> Typing 
>>> root@beaglebone:/dev# open iio:device0
>>> doesn't seem to do anything.
>>> 
>>> Do you think you could break your steps down even further?
>>> 
>>> Thanks.
>>> 
>>> On Friday, March 18, 2016 at 3:49:39 PM UTC-4, john3909 wrote:
>>> It is a driver, so you can open, poll and read from /dev/iio:device

Re: [beagleboard] Debugging with beaglebone black

[John Syne]

Problem with GDB, is you cannot start the debugger until after the kernel 
module is loaded, which means no debugging of init or probe sections. The 
reason is GDB doesn’t know where in memory the kernel module is loaded until 
after it is loaded. This is why you need a kernel aware debugger like 
Lauterbach which loads the kernel module code, loads the debug symbols and 
breaks at the start of init. 

Regards,
John




> On Mar 18, 2016, at 1:50 AM, William Hermans <yyrk...@gmail.com> wrote:
> 
> https://www.google.com/search?q=how+to+debug+linux+kernel+modules 
> <https://www.google.com/search?q=how+to+debug+linux+kernel+modules>
> 
> Just like you would on any platform.
> 
> On Thu, Mar 17, 2016 at 8:46 PM, John Syne <john3...@gmail.com 
> <mailto:john3...@gmail.com>> wrote:
> To debug kernel modules with JTAG, you have to have a debugger which is 
> kernel aware like Lauterbach. If you don’t want to use JTAG, then use printk 
> or dev-dbg, dev-err, etc. You can also use ftrace, which requires you to 
> build your own kernel and add support for the various ftrace features. Read 
> kernel docs under documentation/trace/ftrace.txt to learn more.
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 17, 2016, at 7:49 PM, cmajor.merch...@gmail.com 
>> <mailto:cmajor.merch...@gmail.com> wrote:
>> 
>> I have a question about the beaglebone black. How am suppose to debug with 
>> it? I really would prefer not to have to solder a JTAG header. Also the JTAG 
>> header would be under the board which is really inconvenient. The case that 
>> came with my board also has no room for the JTAG header so it would 
>> basically render the case useless. I know it has a serial debug header but 
>> how could I debug with it? I want to debug kernel modules.
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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.