Re: [beagleboard] cape-universal & 4.1.x = default.. ;)

[TJF]

Am Donnerstag, 21. Juli 2016 07:35:23 UTC+2 schrieb john3909:
>
> Why not use the A & B suffix? Surely this just needs modification to your 
> regular expressions? 
>

Just renaming doesn't solve the issue. There's just one P9_42 and the 
features of P9_92 should get merged in to this pin. Check the libpruio 
overlay on how to handle this in a save manner.

But the point is: both (cape_universal and libpruio overlays) are just bad 
workarounds. They load a lot of pin configurations in kernel space memory, 
while just a few are used. A full featured dtbo file (67 header pins) has 
135140 bytes. Handling all that pre-configurations slows down boot time and 
blocks a lot of kernel memory. And finally the configuration necessary for 
a special usecase is still missing.

>From my point of view the kernel driver pinctrl-single should get patched:

   1. It should protect the system (when one CPU ball gets set, the other 
   should automatically get in input state - for CPU balls connected to P9_41 
   and P9_42).
   2. It should get an API in /sys/devices/ocp to set any pin configuration 
   (as stated in our March discussion 
   ).

This API would be the correct basis for Williams web interface (and for 
config-pin or libpruio pinmuxing).

BR

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/9ff475ab-0f97-4fc0-906c-49d989b8ef8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: UART4 read in pthread not working

[Wally Bkg]

On Wednesday, July 20, 2016 at 1:56:50 AM UTC-5, Regina Choi wrote:
>
>
> Hi, 
>
> I have programmed (in C) UART4 read in thread with blocking read, the code 
> as below: I confirmed that the UART receive port does have data through 
> oscilloscope, but somehow there is no data in read( ), the return count 
> always zero ?  
>
>
> // UART RX thread
> void* uartRxWait(void *param){
>
> unsigned char receive[100];
> int count, n;
> fd_set input;
> struct timeval timeout;
>
> //initialize input set
> FD_ZERO(&input);
> FD_SET(file, &input);
>
> timeout.tv_sec=0;
> timeout.tv_usec=0;
>
> while(1){
>
> if ((count = read(file, (void *)receive, 100))<0)
> {
> perror("Failed to read from input \n");
> printf("count = %d\n", count);
> }else{
>
> if(receive[2]==0x32){
> printf("Header received \n"); 
> }
> printf("Byte received [%d] \n", count);
> printf("Value of Pi = 0x%.2x\n", receive[0]);
>
>   }
>  
> }
>
> pthread_exit(0);
> }
>

Try adding fflush(stdout) and fflush(stderr) as the last statements in your 
while loop so you can see the outputs while the thread is running.

You thread code looks funky,  main() launches the threads and then 
immediately drops into phtread_join to wait for the Rx thread to terminate, 
which doesn't look like it'll happen without killing the program.  Or have 
you left out some of your code?

Another potential problem is that it looks like you send the command in 
main before launching the thread to receive the reply.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/9c9cdc43-7f45-4cec-bab9-722f084cddb9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] cape-universal & 4.1.x = default.. ;)

[John Syne]

I see where you are coming from, but that is very confusing to me and I suspect 
several other developers as well. P9_42 means something (Connector P9, Pin 42) 
so just adding an arbitrary 50 for a secondary function doesn’t make sense to 
me. Why not use the A & B suffix? Surely this just needs modification to your 
regular expressions?

Regards,
John




> On Jul 20, 2016, at 6:01 PM, Charles Steinkuehler  
> wrote:
> 
> On 7/20/2016 5:43 PM, John Syne wrote:
>> Now I see why I didn’t see this before. On the Pinmux spreadsheet, they are
>> labelled as P9_42A and P9_42B. I don’t know where you get P9_92 since there 
>> is
>> no pin 92 on the P9 connector.
> 
> Pin "92" is my fault.
> 
> I used the convention of adding 50 to the pin number for the "secondary" I/O 
> pin connected to the same P8/P9 header:
> 
> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin#L586-L591
> 
> ...there's a Pin 91 as well.  :)
> 
> -- 
> Charles Steinkuehler
> char...@steinkuehler.net
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- You received this message because you are subscribed to 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/25b0254b-bb74-5ae5-4555-5bd9bdc391ff%40steinkuehler.net.
> 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/B1DFA5DB-FA38-4285-B981-C59FEF46EDE5%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] cape-universal & 4.1.x = default.. ;)

[Charles Steinkuehler]

On 7/20/2016 5:43 PM, John Syne wrote:

Now I see why I didn’t see this before. On the Pinmux spreadsheet, they are
labelled as P9_42A and P9_42B. I don’t know where you get P9_92 since there is
no pin 92 on the P9 connector.


Pin "92" is my fault.

I used the convention of adding 50 to the pin number for the "secondary" 
I/O pin connected to the same P8/P9 header:


https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin#L586-L591

...there's a Pin 91 as well.  :)

--
Charles Steinkuehler
char...@steinkuehler.net

--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/25b0254b-bb74-5ae5-4555-5bd9bdc391ff%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] cape-universal & 4.1.x = default.. ;)

[John Syne]

Now I see why I didn’t see this before. On the Pinmux spreadsheet, they are 
labelled as P9_42A and P9_42B. I don’t know where you get P9_92 since there is 
no pin 92 on the P9 connector. 

P9_42A
89
0x964/164
GPIO0_7
7
gpio0[7]
P9_42B
104
0x9a0/1a0
GPIO0_7
114
gpio3[18]

Regards,
John




> On Jul 20, 2016, at 11:33 AM, William Hermans  wrote:
> 
> You can replace cape_universal by the libpruio universal overlay. That 
> doesn't enable drivers/subsystems (= saves power and resources consumptions), 
> but has the same pinmuxing capability. It's even more safe, since it seems 
> that cape_universal can damage your CPU by a sequence like
> 
> config-pin P9_42 gpio high
> config-pin P9_92 gpio low
> 
> (I didn't test it, but if you do so, please report.)
> 
> O, wait, did I miss something here ? Originally I read that as a single pin 
> but instead now am seeing two different pins. Are these one of those dual 
> accessed pin cases in the BBB ? If so, what's the implications ? 
> 
> On Wed, Jul 20, 2016 at 11:28 AM, William Hermans  > wrote:
> You can replace cape_universal by the libpruio universal overlay. That 
> doesn't enable drivers/subsystems (= saves power and resources consumptions), 
> but has the same pinmuxing capability. It's even more safe, since it seems 
> that cape_universal can damage your CPU by a sequence like
> 
> config-pin P9_42 gpio high
> config-pin P9_92 gpio low
> 
> (I didn't test it, but if you do so, please report.)
> 
> Ok, maybe, but any smart engineer should have pin isolation built into their 
> circuitry. Here, we were using buffers, but now we're going to try bi powered 
> FET's( sorry I'm not an EE so not sure that's the proper term ). But 
> basically a MOSFET that has to be powered from both sides of the connection 
> before the given "buffered" IO can complete it's circuit.
>  
> Regarding other capes, libpruio ships with a tool to adapt the universal 
> device tree overlay. It can generate overlays that do not claim a specified 
> set of pins. Instead of fiddling with device tree entries, you just list the 
> pins you want to get freed and let the tool deal with the low-level stuff. 
> Such an overlay can get loaded before or after any other cape overlay.
> 
> In order to replace the config_pin tool, you can write small programs 
> (compiled against libpruio), which do the pinmuxing and enable the subsystems 
> in use (only that ones).
> 
> BR
>  
> Here's the deal. I plan on creating a web interface for universal-io + 
> config-pin. So a user can eventually open up the web page that comes with the 
> beaglebone, and configure their IO / peripherals from a web front end. No 
> idea if that is possible with your stuff, but more importantly, I've spent a 
> good amount of my spare time looking into doing this with universal IO. Which 
> my time is much more finite lately than in the past. So I can not afford to 
> go around and research every possible way to do a thing, under the sun.
> 
> I know universal IO well enough now to make this happen once I get the time 
> to createthe web front end stuff. But I already have the back-end written. 
> Well, I have the Bonejs wrapper library which took me only a few days a 
> couple hours here and there . . .But the rest will take some time as I learn 
> how to get data from the Nodejs backend, to a web front end, such as Angular, 
> and I do not know what else right now . . .
> 
> Also for what it's worth. You do not need cape_universal=enable does not need 
> to be enabled in order to use config-pin, and universal IO.
> 
> On Wed, Jul 20, 2016 at 11:06 AM, William Hermans  > wrote:
> If we create gpio/pinmux group, I think we could keep from burdening users 
> while moving Cloud9 IDE to the 'debian' user. I believe we also have a 
> sudoers for the 'debian' user, meaning we could probably at that point 
> prevent direct root login unless someone does something to disable the root 
> password. I'd worry about that breaking things like LabVIEW, etc., but if we 
> can at least try out some minor steps towards security, it will at least make 
> everyone more aware of the holes and challenges.
> 
> I kind of roughly describe that here: 
> https://github.com/wphermans/Bonejs/blob/master/documentation/permissions.md 
> 
>  Although there is much mroe to consider than just the little bit I covered 
> there. But that should be a good start.
> 
> On Wed, Jul 20, 2016 at 11:00 AM, Jason Kridner  > wrote:
> 
> 
> On Fri, Jun 24, 2016 at 8:10 PM Charles Steinkuehler 
> mailto:char...@steinkuehler.net>> wrote:
> On 6/24/2016 5:52 PM, William Hermans wrote:
> > /Note the security 'bar' is not set particularly high, given the/
> > /default BBB images have no root password.  :)/
> >
> >
> > Thats been changed, since at least the last couple of images.
> 
> I don't think tha

Re: [beagleboard] cape-universal & 4.1.x = default.. ;)

[John Syne]

Ah, I missed that you are controlling two different GPIO connected to the same 
pin. I don’t know why you keep on bringing stuff up like this, because any 
sensible developer would obviously avoid something like this. Gerald was 
attempting to bring out all the features on the AM335x even when he didn’t have 
sufficient connector pins. Clearly, if you want the one GPIO to be an output, 
the other must be configured as an input.

Regards,
John




> On Jul 20, 2016, at 2:47 PM, TJF  wrote:
> 
> 
> 
> Am Mittwoch, 20. Juli 2016 21:36:59 UTC+2 schrieb john3909:
> Looking at:
> 
> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin
>  
> 
> 
> Nothing bad will happen. The first command will set GPIO high and the next 
> will change the GPIO to low. Besides, the AM335x won’t allow an output 
> conflict.
> 
> Nothing bad, did you test?
> 
> Yes, one CPU ball (7) goes high, the other (114) low. No conflict at the 
> AM335x. But both balls are hard wired to a single header pin on the BB board. 
> Neither the BB hardware has any protection nor the software (kernel driver or 
> config-pin/cape_universal).
> 
> BR
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to 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/b8587ab0-6626-464e-a87b-43c940992505%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/166CA2C3-4306-4FAA-B862-FB556073E74E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] cape-universal & 4.1.x = default.. ;)

[TJF]

Am Mittwoch, 20. Juli 2016 21:36:59 UTC+2 schrieb john3909:
>
> Looking at:
>
>
> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin
>  
> 
>
> Nothing bad will happen. The first command will set GPIO high and the next 
> will change the GPIO to low. Besides, the AM335x won’t allow an output 
> conflict.
>

Nothing bad, did you test?

Yes, one CPU ball (7) goes high, the other (114) low. No conflict at the 
AM335x. But both balls are hard wired to a single header pin on the BB 
board. Neither the BB hardware has any protection nor the software (kernel 
driver or config-pin/cape_universal).

BR

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/b8587ab0-6626-464e-a87b-43c940992505%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Sound does not work on BeagleBoard (rev C5) with Ubuntu 14.04.3

[Alexander Barth]

Thank you very much, Joshua, this solved indeed my problem!
Cheers,
Alex


On Fri, Jul 8, 2016 at 5:18 PM,   wrote:
> sudo usermod -a -G $USER audio
>
> On Saturday, September 19, 2015 at 6:35:55 PM UTC-7, barth.a...@gmail.com
> wrote:
>>
>> Hi all,
>>
>> Unfortunately I cannot get the sound to work on my BeagleBoard (rev C5)
>> with Ubuntu 14.04.3. I try to use the internal stereo out jack.
>>
>> Playing any file fails with the following error:
>>
>> abarth@arm:~$ aplay /usr/share/sounds/alsa/Front_Left.wav
>> ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
>> ALSA lib conf.c:4248:(_snd_config_evaluate) function snd_func_card_driver
>> returned error: No such file or directory
>> ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
>> ALSA lib conf.c:4248:(_snd_config_evaluate) function snd_func_concat
>> returned error: No such file or directory
>> ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
>> ALSA lib conf.c:4248:(_snd_config_evaluate) function snd_func_refer
>> returned error: No such file or directory
>> ALSA lib conf.c:4727:(snd_config_expand) Evaluate error: No such file or
>> directory
>> ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM default
>> aplay: main:722: audio open error: No such file or directory
>>
>>
>> The sound card does not seem to be recognized:
>> abarth@arm:~$ aplay -l
>> aplay: device_list:268: no soundcards found...
>>
>> However, in /proc/asound, I see a card0:
>>
>> abarth@arm:~$ ls /proc/asound
>> card0  cards  devices  modules  omap3beagle  oss  pcm  seq  timers
>> version
>>
>> Sound kernel modules seem to be loaded:
>>
>> abarth@arm:~$ lsmod  | grep snd
>> snd_soc_twl403042147  1
>> snd_soc_omap_mcbsp 25505  2
>> snd_soc_omap3125  1 snd_soc_omap_mcbsp
>> snd_soc_omap_twl4030 7256  0
>> snd_seq_midi6165  0
>> snd_seq_midi_event  7274  1 snd_seq_midi
>> snd_soc_core  191982  4
>> snd_soc_omap_twl4030,snd_soc_omap,snd_soc_omap_mcbsp,snd_soc_twl4030
>> snd_compress   13928  1 snd_soc_core
>> snd_pcm_dmaengine   5682  2 snd_soc_core,snd_soc_omap
>> snd_pcm_oss41006  0
>> snd_rawmidi24220  1 snd_seq_midi
>> snd_mixer_oss  15253  1 snd_pcm_oss
>> snd_pcm97788  6
>> snd_pcm_oss,snd_soc_core,snd_soc_omap,snd_soc_omap_mcbsp,snd_pcm_dmaengine,snd_soc_twl4030
>> snd_seq67850  2 snd_seq_midi_event,snd_seq_midi
>> snd_seq_device  5368  3 snd_seq,snd_rawmidi,snd_seq_midi
>> snd_timer  22978  2 snd_pcm,snd_seq
>> snd72286  9
>> snd_pcm_oss,snd_soc_core,snd_timer,snd_pcm,snd_seq,snd_rawmidi,snd_seq_device,snd_compress,snd_mixer_oss
>> soundcore   8445  1 snd
>>
>>
>>
>> I have the following alsa packages installed:
>>
>> abarth@arm:~$ dpkg -l | grep alsa
>> ii  alsa-base   1.0.25+dfsg-0ubuntu4
>> all  ALSA driver configuration files
>> ii  alsa-utils  1.0.27.2-1ubuntu2
>> armhfUtilities for configuring and using ALSA
>>
>> Some more info on my system:
>>
>> abarth@arm:~$ uname -a
>> Linux arm 4.1.5-armv7-x2 #1 SMP Tue Aug 11 21:04:06 UTC 2015 armv7l armv7l
>> armv7l GNU/Linux
>> abarth@arm:~$ cat /etc/issue
>> Ubuntu 14.04.3 LTS \n \l
>>
>> rcn-ee.net console Ubuntu Image 2015-08-17
>>
>> Any help or directions would be greatly appreciated!
>>
>> Cheers,
>> Alex
>>
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/CAHL-S0bEkZ0hx%2B-KAZ9K0jpdoOGbyyAMyYGMULXqi8tjr2GEZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBGW - wlcore crashes during boot with USB audio card installed

[Mike Erdahl]

Hi Robert,

Thank you for the suggestions!

Unfortunately updating the kernel did not fix the issue- pretty much the 
same backtraces.

I was thinking along the lines of getting a powered USB hub as well.

Interestingly, on the failed case, removing the USB audio card, then 
performing a warm reset is not enough- I must cold boot for wlcore to come 
up successfully again.

I will track down a powered hub and report back.

Regards,
Mike

On Wednesday, July 20, 2016 at 2:09:35 PM UTC-5, RobertCNelson wrote:
>
> Hi Mike
>
> On Wed, Jul 20, 2016 at 2:03 PM, Mike Erdahl  > wrote:
>
>> Hi,
>>
>> I'm working on a project that requires audio input/ output, so using a 
>> C-Media chipset based solution from Sabrent.
>>
>> With the latest BB.org kernel/ filesystem (Kernel 4.4.9, Debian 8.4), 
>> wlcore driver crashes during kernel boot if my USB audio card is 
>> installed.  Booting without the card installed, then installing after the 
>> kernel seems to always work fine (WiFi throughput is normal, USB audio in/ 
>> out works as expected).
>>
>> Occasionally I can poweroff, then back on, without removing USB audio 
>> card, and wlcore is happy.  I would say this occurs < 10%.
>>
>> Below are snippets of my kernel logs in good vs bad case:
>>
>> debian@beaglebone:~$ uname -a 
>> 
>> 
>>
> Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l 
>> GNU/Linux
>>
>
> Can you please re-test with 4.4.15-ti-r37
>
> sudo apt-get update ; sudo apt-get install linux-image-4.4.15-ti-r37 ; 
> sudo reboot
>
> Otherwise it smells like a power issue.
>
> A quick test, if you can put a "powered" usb hub between the Green 
> Wireless and your usb audio card.
>
> 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/49a87b51-5c3c-40a0-bf41-0bc47563c5f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] problems with static ip address on eth0

[Robert Nelson]

On Mon, Jul 18, 2016 at 8:48 AM,  wrote:

> I downloaded the newest image
> (bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb) and I am now trying to
> configure the eth0 to be able to use the BBB on our network.
> I can connect to it over USB link.
> I changed the /etc/network/interfaces file to the content shown below, but
> after reboot the BBB gets address 169.254.129.50 (an address assigned after
> failed DHCP assignment attempt?)
> After some searching, I have the impression that this is because the usb0
> link uses dhcp, and the BBB is also using this on eth0, although I tell it
> to use 'static' in the interfaces file.
> If I restart the eth0 link using 'ifdown eth0' and 'ifup eth0' then it
> does get the right ip address, and I can ssh to it over the eth0 interface.
> But this is not really a good solution, and I have the impression that some
> other network settings, (dns, ...) are still misconfigured.
>
> I tried deleting the usb0 link from /etc/interfaces, and disabling the
> /opt/scripts/boot/autoconfigure_usb0.sh script, but that didn't help either.
> Is there any way I can force it to use a static IP address on eth0?
>
> Thanks for any help
>
> Bart
>
>
> root@beaglebone:/etc/network# cat interfaces
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
>
> # The loopback network interface
> auto lo
> iface lo inet loopback
>
> # The primary network interface
> auto eth0
> iface eth0 inet static
> dns-nameservers 8.8.8.8 8.8.4.4
> address 30.0.0.39
> netmask 255.0.0.0
> network 30.0.0.0
> gateway 30.0.0.1
> # Example to keep MAC address between reboots
> #hwaddress ether DE:AD:BE:EF:CA:FE
>

The magic for static eth is:

sudo connmanctl config  --ipv4 manual  
 --nameservers 

run:

debian@beaglebone:~$ connmanctl services
*AO Wiredethernet_74daea0a4b52_cable

sudo connmanctl config ethernet_74daea0a4b52_cable --ipv4
manual 30.0.0.39 255.0.0.0 30.0.0.1 --nameservers 8.8.8.8

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/CAOCHtYjncsbazCyMB%3DKQrns37z_NYuvFEob0cNBvNO9CwTv4WA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Building 'ti' kernel

[Robert Nelson]

Hi Mark,

On Wed, Jul 20, 2016 at 2:43 PM, Mark A. Yoder 
wrote:

> I've just updated my instructions for building a kernel for the bone[1].
> I see that it created version=*4.4.15-bone11*.
>
> How do I build a 'ti' version like I'm currently running?
>
> bone$ *uname -a*
> Linux yoder-debian-bone 4.4.14-*ti*-r34 #1 SMP Wed Jul 6 05:33:33 UTC
> 2016 armv7l GNU/Linux
>

Sadly, the repo for building "ti" kernel's is not "build-reproducible", due
to the way i combine two working git branches...

Instead have you students/directions look to "yakbuild"

https://github.com/RobertCNelson/yakbuild

Follow the readme.md and set:

toolchain="gcc_linaro_gnueabihf_5"
kernel_tag="4.4.14-ti-r34"

then, just:

./build_kernel.sh / etc like previously..

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

[beagleboard] Building 'ti' kernel

[Mark A. Yoder]

I've just updated my instructions for building a kernel for the bone[1].  I 
see that it created version=*4.4.15-bone11*.

How do I build a 'ti' version like I'm currently running? 

bone$ *uname -a*
Linux yoder-debian-bone 4.4.14-*ti*-r34 #1 SMP Wed Jul 6 05:33:33 UTC 2016 
armv7l GNU/Linux


--Mark

[1] http://elinux.org/EBC_Exercise_08_Installing_Development_Tools_4.4 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/777cafb6-9660-4815-af3d-146080733faf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: problems with static ip address on eth0

[Wally Bkg]

Have you tried booting with the USB cable not plugged into your computer?

I've never tried using both the USB gadget and wired Ethernet at the same 
time.

When I want a static IP on the local network I usually find it easier to go 
to the router's admin page and set a static IP based on the board's MAC 
address.  Then I don't have to keep editing the config files on the Bone, 
or Pi etc.


On Monday, July 18, 2016 at 8:52:08 AM UTC-5, bart.van...@gmail.com wrote:
>
> I downloaded the newest image 
> (bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb) and I am now trying to 
> configure the eth0 to be able to use the BBB on our network.
> I can connect to it over USB link.
> I changed the /etc/network/interfaces file to the content shown below, but 
> after reboot the BBB gets address 169.254.129.50 (an address assigned after 
> failed DHCP assignment attempt?)
> After some searching, I have the impression that this is because the usb0 
> link uses dhcp, and the BBB is also using this on eth0, although I tell it 
> to use 'static' in the interfaces file.
> If I restart the eth0 link using 'ifdown eth0' and 'ifup eth0' then it 
> does get the right ip address, and I can ssh to it over the eth0 interface. 
> But this is not really a good solution, and I have the impression that some 
> other network settings, (dns, ...) are still misconfigured.
>
> I tried deleting the usb0 link from /etc/interfaces, and disabling the 
> /opt/scripts/boot/autoconfigure_usb0.sh script, but that didn't help either.
> Is there any way I can force it to use a static IP address on eth0?
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/97c82b77-e4e8-4a5f-ac8e-511757194842%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] cape-universal & 4.1.x = default.. ;)

[John Syne]

> On Jul 20, 2016, at 8:46 AM, TJF  wrote:
> 
> 
> Hi William!
> 
> Am Dienstag, 19. Juli 2016 19:54:02 UTC+2 schrieb William Hermans:
> SO, after talking with Robert and finding that all these kernel modules that 
> get loaded from cape_universal=enable. I wonder how this impacts other capes 
> such as the Logic supply RS232 / CAN cape that automatically loads it's own 
> device tree  overlay.
> 
> Could capes such as this be loaded first, and then still have universal-io 
> capabilities ? 
> 
> You can replace cape_universal by the libpruio universal overlay. That 
> doesn't enable drivers/subsystems (= saves power and resources consumptions), 
> but has the same pinmuxing capability. It's even more safe, since it seems 
> that cape_universal can damage your CPU by a sequence like
> 
> config-pin P9_42 gpio high
> config-pin P9_92 gpio low
> 
Looking at:

https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin

Nothing bad will happen. The first command will set GPIO high and the next will 
change the GPIO to low. Besides, the AM335x won’t allow an output conflict. 

Regards,
John
> (I didn't test it, but if you do so, please report.)
> 
> Regarding other capes, libpruio ships with a tool to adapt the universal 
> device tree overlay. It can generate overlays that do not claim a specified 
> set of pins. Instead of fiddling with device tree entries, you just list the 
> pins you want to get freed and let the tool deal with the low-level stuff. 
> Such an overlay can get loaded before or after any other cape overlay.
> 
> In order to replace the config_pin tool, you can write small programs 
> (compiled against libpruio), which do the pinmuxing and enable the subsystems 
> in use (only that ones).
> 
> BR
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to 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/87197b98-c1dc-472e-9919-cd2b4fa4aab5%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/4ABA5705-E21B-49C8-BCF5-08988E09176F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: How to recovery after disable eMMC in uEnv.txt

[Wally Bkg]

Have you tried downloading an image from beagleboard.org and writing it to 
an microSD card and booting from that?  I recommend the etcher utility for 
writing the SD card.  Any of the images should work.

Once you've booted the SD card you can mount the eMMC with:

sudo mkdir /mnt/emmc
sudo mount  /dev/mmcblk1p1 /mnt/emmc


And edit the uEnv.txt file in the eMMC:

sudo nano /mnt/emmc/uEnv.txt

If you've correctly fixed the uEnv.txt file, shutdown, remove the SD card 
and you should be able to boot from the eMMC again.

Newer images create only a single partition, and use a "virtual MSDOS 
partition" and only a single partition.  I prefer the new arrangement.


On Wednesday, July 20, 2016 at 1:26:14 AM UTC-5, qiu.w...@gmail.com wrote:
>
> Hi 
> I got the same problem. Have you solved it?
>
> On Sunday, July 19, 2015 at 7:33:38 PM UTC+8, huey...@gmail.com wrote:
>>
>> I uncorrectly disable eMMC in my Beaglebone Black Rev. C by following 
>> steps:
>>
>> 1. Mount the FAT partition:
>>
>>$ mount /dev/mmcblk0p1  /mnt/card
>>
>> 2. Edit the uEnv.txt on the mounted partition:
>>
>>$ nano /mnt/card/uEnv.txt
>>
>> 3. Enable following line in uEnv.txt
>>
>> 
>> optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
>>
>> Then I can not boot again, following message show on screen:
>>
>> [0.741541] omap_hsmmc mmc.5: of_parse_phandle_with_args of 
>> 'reset' failed
>>
>> then I boot into 
>>
>> Busybox v1.20.2 (Debian 1:1.20.0-7) built-in shell (ash)
>> Enter 'help' for a list of built-in commands.
>>
>> /bin/sh: can't access tty; job control turned off
>> (initramfs)
>>
>> Since there is no /dev/mmcblk0p1 now, I can not mount it and edit 
>> uEnv.txt again.
>>
>> Then how can I recovery my eMMC from this point?
>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/f5f84f69-b54a-4246-91da-bd452d041d1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBGW - wlcore crashes during boot with USB audio card installed

[Robert Nelson]

Hi Mike

On Wed, Jul 20, 2016 at 2:03 PM, Mike Erdahl  wrote:

> Hi,
>
> I'm working on a project that requires audio input/ output, so using a
> C-Media chipset based solution from Sabrent.
>
> With the latest BB.org kernel/ filesystem (Kernel 4.4.9, Debian 8.4),
> wlcore driver crashes during kernel boot if my USB audio card is
> installed.  Booting without the card installed, then installing after the
> kernel seems to always work fine (WiFi throughput is normal, USB audio in/
> out works as expected).
>
> Occasionally I can poweroff, then back on, without removing USB audio
> card, and wlcore is happy.  I would say this occurs < 10%.
>
> Below are snippets of my kernel logs in good vs bad case:
>
> debian@beaglebone:~$ uname -a
>
>
>
Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l
> GNU/Linux
>

Can you please re-test with 4.4.15-ti-r37

sudo apt-get update ; sudo apt-get install linux-image-4.4.15-ti-r37 ; sudo
reboot

Otherwise it smells like a power issue.

A quick test, if you can put a "powered" usb hub between the Green Wireless
and your usb audio card.

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/CAOCHtYihs7xO70ohrC6omJ0oDsVjhtMSrt2mYkcA%2BN-t7eBMSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] primer for GPIO on the Beagleboard -xM

[William Hermans]

The general concept behind GPIO from Linux is going to be very similar. As
they're both probably using libGPIO, if you're using a modern kernel on
your xM.

So you have:

/sysclass/gpio/ as the base path for libGPIO sysfs.  Which in turn will
have 'export', and 'unexport' files for exporting, and exporting gpio pins.
Then of course. something like:

echo '24' > /sys/class/gpio/export is going to have slightly different
implications across platforms. Meaning that of course, 'gpio24' will have a
different meaning for a Beaglebone versus a beagleboard. They'll both be
GPIO's of course.

As to actual device tree file pin muxing . . . I'm not sure. I would think
it should be similar, but I'm also not sure of the xM's pin muxing
capabilities.

On Wed, Jul 20, 2016 at 11:57 AM, Gary Pajer  wrote:

> I have one (rev A2, I think) and I want to access GPIO.
>
> Is there a good, relatively complete source of info on how to do this?  I
> see some things for the BeagleBoneBlack, but very little for the BB -xM.
> Are the instructions identical?  For example, for the BBB there is some
> calculation that has to be done to associate a pin with the "device"
> exposed by the kernel.  Is it done differently on the BB?
>
> I also see a lot of short instructions like "change the MUX for the pin in
> the device tree".I need to know what the device tree is, and how to
> change the MUX there.
>
> I really need some basic information about how this works, preferably in
> one (or a few) places.  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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/54a25865-c358-4662-a9d8-f86ce39b44db%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/CALHSORp66Dt270f9WhFUjnmQ27pXoWmLmRwdXEbd_qvf5VQdUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBGW - wlcore crashes during boot with USB audio card installed

[Mike Erdahl]

Hi,

I'm working on a project that requires audio input/ output, so using a 
C-Media chipset based solution from Sabrent.

With the latest BB.org kernel/ filesystem (Kernel 4.4.9, Debian 8.4), 
wlcore driver crashes during kernel boot if my USB audio card is installed. 
 Booting without the card installed, then installing after the kernel seems 
to always work fine (WiFi throughput is normal, USB audio in/ out works as 
expected).

Occasionally I can poweroff, then back on, without removing USB audio card, 
and wlcore is happy.  I would say this occurs < 10%.

Below are snippets of my kernel logs in good vs bad case:

debian@beaglebone:~$ uname -a   

 
Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l 
GNU/Linux

GOOD:

[ 21.553728] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)

[ 21.727062] wlcore: loaded
[ 22.635026] wlcore: PHY firmware version: Rev 8.2.0.0.233
[ 22.982650] wlcore: firmware booted (Rev 8.9.0.1.55)
[ 23.321899] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 24.678734] Bluetooth: Core ver 2.21
[ 24.682608] NET: Registered protocol family 31
[ 24.682627] Bluetooth: HCI device and connection manager initialized
[ 24.682664] Bluetooth: HCI socket layer initialized
[ 24.682681] Bluetooth: L2CAP socket layer initialized
[ 24.682778] Bluetooth: SCO socket layer initialized
[ 24.721944] Bluetooth: HCI UART driver ver 2.3
[ 24.721973] Bluetooth: HCI UART protocol H4 registered
[ 24.721981] Bluetooth: HCI UART protocol BCSP registered
[ 24.721988] Bluetooth: HCI UART protocol LL registered
[ 24.721995] Bluetooth: HCI UART protocol ATH3K registered
[ 24.722002] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 24.724095] Bluetooth: HCI UART protocol BCM registered
[ 24.724115] Bluetooth: HCI UART protocol QCA registered
[ 25.093927] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 25.093951] Bluetooth: BNEP filters: protocol multicast
[ 25.093985] Bluetooth: BNEP socket layer initialized

FAIL:

[   22.313743] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)

[   22.480016] wlcore: loaded

[   23.447478] wlcore: PHY firmware version: Rev 8.2.0.0.233

[   23.856026] wlcore: firmware booted (Rev 8.9.0.1.55)

[   24.185915] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

[   25.025939] wlcore: ERROR ELP wakeup timeout!

[   25.030401] [ cut here ]

[   25.030673] WARNING: CPU: 0 PID: 451 at 
drivers/net/wireless/ti/wlcore/main.c:797 
wl12xx_queue_recovery_work.part.8+0x46/0x48 [wlcore]()

[   25.030683] Modules linked in: arc4 wl18xx wlcore mac80211 pruss_intc 
cfg80211 rfkill snd_soc_evm snd_soc_wilink8_bt pru_rproc omap_sham pruss 
omap_aes_driver snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi 
snd_seq_device cm109 omap_rng rng_core snd_soc_davinci_mcasp snd_soc_edma 
snd_soc_omap snd_soc_core usb_f_acm snd_pcm_dmaengine u_serial usb_f_rndis 
g_multi usb_f_mass_storage u_ether libcomposite snd_pcm wlcore_sdio 
snd_timer snd soundcore evdev uio_pdrv_genirq uio

[   25.030817] CPU: 0 PID: 451 Comm: wpa_supplicant Not tainted 
4.4.9-ti-r25 #1

[   25.030824] Hardware name: Generic AM33XX (Flattened Device Tree)

[   25.030864] [] (unwind_backtrace) from [] 
(show_stack+0x11/0x14)

[   25.030891] [] (show_stack) from [] 
(dump_stack+0x73/0x80)

[   25.030920] [] (dump_stack) from [] 
(warn_slowpath_common+0x6b/0x94)

[   25.030936] [] (warn_slowpath_common) from [] 
(warn_slowpath_null+0x17/0x1c)

[   25.031043] [] (warn_slowpath_null) from [] 
(wl12xx_queue_recovery_work.part.8+0x46/0x48 [wlcore])

[   25.031221] [] (wl12xx_queue_recovery_work.part.8 [wlcore]) 
from [] (wl12xx_queue_recovery_work+0x12/0x14 [wlcore])

[   25.031365] [] (wl12xx_queue_recovery_work [wlcore]) from 
[] (wl1271_ps_elp_wakeup+0x192/0x198 [wlcore])

[   25.031507] [] (wl1271_ps_elp_wakeup [wlcore]) from 
[] (wl1271_op_add_interface+0x78/0x774 [wlcore])

[   25.032132] [] (wl1271_op_add_interface [wlcore]) from 
[] (drv_add_interface+0x38/0x118 [mac80211])

[   25.032592] [] (drv_add_interface [mac80211]) from 
[] (ieee80211_do_open+0x2f4/0x668 [mac80211])

[   25.032905] [] (ieee80211_do_open [mac80211]) from 
[] (ieee80211_start_p2p_device+0x3e/0x44 [mac80211])

[   25.033590] [] (ieee80211_start_p2p_device [mac80211]) from 
[] (nl80211_start_p2p_device+0x50/0x120 [cfg80211])

[   25.033868] [] (nl80211_start_p2p_device [cfg80211]) from 
[] (genl_rcv_msg+0x1b5/0x2bc)

[   25.033887] [] (genl_rcv_msg) from [] 
(netlink_rcv_skb+0x75/0x84)

[   25.033899] [] (netlink_rcv_skb) from [] 
(genl_rcv+0x21/0x30)

[   25.033911] [] (genl_rcv) from [] 
(netlink_unicast+0xe3/0x178)

[   25.033922] [] (netlink_unicast) from [] 
(netlink_sendmsg+0x381/0x454)

[   25.033942] [] (netlink_sendmsg) from [] 
(sock_sendmsg+0x23/0x2c)

[   25.033958] [] (sock_sendmsg) from [] 
(___sys_sendmsg+0x161/0x168)

[   25.033973] [] (___sys_sendmsg) from [] 
(__s

[beagleboard] primer for GPIO on the Beagleboard -xM

[Gary Pajer]

I have one (rev A2, I think) and I want to access GPIO.

Is there a good, relatively complete source of info on how to do this?  I 
see some things for the BeagleBoneBlack, but very little for the BB -xM.   
Are the instructions identical?  For example, for the BBB there is some 
calculation that has to be done to associate a pin with the "device" 
exposed by the kernel.  Is it done differently on the BB?

I also see a lot of short instructions like "change the MUX for the pin in 
the device tree".I need to know what the device tree is, and how to 
change the MUX there.

I really need some basic information about how this works, preferably in 
one (or a few) places.  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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/54a25865-c358-4662-a9d8-f86ce39b44db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: cape-universal & 4.1.x = default.. ;)

[William Hermans]

>
> You can replace cape_universal by the libpruio universal overlay. That
> doesn't enable drivers/subsystems (= saves power and resources
> consumptions), but has the same pinmuxing capability. It's even more safe,
> since it seems that cape_universal can damage your CPU by a sequence like
>
> config-pin P9_42 gpio high
> config-pin P9_92 gpio low
>
> (I didn't test it, but if you do so, please report.)


O, wait, did I miss something here ? Originally I read that as a single pin
but instead now am seeing two different pins. Are these one of those dual
accessed pin cases in the BBB ? If so, what's the implications ?

On Wed, Jul 20, 2016 at 11:28 AM, William Hermans  wrote:

> You can replace cape_universal by the libpruio universal overlay. That
>> doesn't enable drivers/subsystems (= saves power and resources
>> consumptions), but has the same pinmuxing capability. It's even more safe,
>> since it seems that cape_universal can damage your CPU by a sequence like
>>
>> config-pin P9_42 gpio high
>> config-pin P9_92 gpio low
>>
>> (I didn't test it, but if you do so, please report.)
>>
>
> Ok, maybe, but any smart engineer should have pin isolation built into
> their circuitry. Here, we were using buffers, but now we're going to try bi
> powered FET's( sorry I'm not an EE so not sure that's the proper term ).
> But basically a MOSFET that has to be powered from both sides of the
> connection before the given "buffered" IO can complete it's circuit.
>
>
> Regarding other capes, libpruio ships with a tool to adapt the universal
> device tree overlay. It can generate overlays that do not claim a specified
> set of pins. Instead of fiddling with device tree entries, you just list
> the pins you want to get freed and let the tool deal with the low-level
> stuff. Such an overlay can get loaded before or after any other cape
> overlay.
>
> In order to replace the config_pin tool, you can write small programs
> (compiled against libpruio), which do the pinmuxing and enable the
> subsystems in use (only that ones).
>
> BR
>
>
> Here's the deal. I plan on creating a web interface for universal-io +
> config-pin. So a user can eventually open up the web page that comes with
> the beaglebone, and configure their IO / peripherals from a web front end.
> No idea if that is possible with your stuff, but more importantly, I've
> spent a good amount of my spare time looking into doing this with universal
> IO. Which my time is much more finite lately than in the past. So I can not
> afford to go around and research every possible way to do a thing, under
> the sun.
>
> I know universal IO well enough now to make this happen once I get the
> time to createthe web front end stuff. But I already have the back-end
> written. Well, I have the Bonejs wrapper library which took me only a few
> days a couple hours here and there . . .But the rest will take some time as
> I learn how to get data from the Nodejs backend, to a web front end, such
> as Angular, and I do not know what else right now . . .
>
> Also for what it's worth. You do not need cape_universal=enable does not
> need to be enabled in order to use config-pin, and universal IO.
>
> On Wed, Jul 20, 2016 at 11:06 AM, William Hermans 
> wrote:
>
>> If we create gpio/pinmux group, I think we could keep from burdening
>> users while moving Cloud9 IDE to the 'debian' user. I believe we also have
>> a sudoers for the 'debian' user, meaning we could probably at that point
>> prevent direct root login unless someone does something to disable the root
>> password. I'd worry about that breaking things like LabVIEW, etc., but if
>> we can at least try out some minor steps towards security, it will at least
>> make everyone more aware of the holes and challenges.
>>
>> I kind of roughly describe that here:
>> https://github.com/wphermans/Bonejs/blob/master/documentation/permissions.md
>> Although there is much mroe to consider than just the little bit I covered
>> there. But that should be a good start.
>>
>> On Wed, Jul 20, 2016 at 11:00 AM, Jason Kridner <
>> jason.krid...@hangerhead.com> wrote:
>>
>>>
>>>
>>> On Fri, Jun 24, 2016 at 8:10 PM Charles Steinkuehler <
>>> char...@steinkuehler.net> wrote:
>>>
 On 6/24/2016 5:52 PM, William Hermans wrote:
 > /Note the security 'bar' is not set particularly high, given the/
 > /default BBB images have no root password.  :)/
 >
 >
 > Thats been changed, since at least the last couple of images.

>>>
>>> I don't think that's the case---we still have no root password, though
>>> one can be set. The Cloud9 IDE further doesn't require a login.
>>>
>>> If we create gpio/pinmux group, I think we could keep from burdening
>>> users while moving Cloud9 IDE to the 'debian' user. I believe we also have
>>> a sudoers for the 'debian' user, meaning we could probably at that point
>>> prevent direct root login unless someone does something to disable the root
>>> password. I'd worry about that breaking things li

Re: [beagleboard] Re: cape-universal & 4.1.x = default.. ;)

[William Hermans]

>
> You can replace cape_universal by the libpruio universal overlay. That
> doesn't enable drivers/subsystems (= saves power and resources
> consumptions), but has the same pinmuxing capability. It's even more safe,
> since it seems that cape_universal can damage your CPU by a sequence like
>
> config-pin P9_42 gpio high
> config-pin P9_92 gpio low
>
> (I didn't test it, but if you do so, please report.)
>

Ok, maybe, but any smart engineer should have pin isolation built into
their circuitry. Here, we were using buffers, but now we're going to try bi
powered FET's( sorry I'm not an EE so not sure that's the proper term ).
But basically a MOSFET that has to be powered from both sides of the
connection before the given "buffered" IO can complete it's circuit.


Regarding other capes, libpruio ships with a tool to adapt the universal
device tree overlay. It can generate overlays that do not claim a specified
set of pins. Instead of fiddling with device tree entries, you just list
the pins you want to get freed and let the tool deal with the low-level
stuff. Such an overlay can get loaded before or after any other cape
overlay.

In order to replace the config_pin tool, you can write small programs
(compiled against libpruio), which do the pinmuxing and enable the
subsystems in use (only that ones).

BR


Here's the deal. I plan on creating a web interface for universal-io +
config-pin. So a user can eventually open up the web page that comes with
the beaglebone, and configure their IO / peripherals from a web front end.
No idea if that is possible with your stuff, but more importantly, I've
spent a good amount of my spare time looking into doing this with universal
IO. Which my time is much more finite lately than in the past. So I can not
afford to go around and research every possible way to do a thing, under
the sun.

I know universal IO well enough now to make this happen once I get the time
to createthe web front end stuff. But I already have the back-end written.
Well, I have the Bonejs wrapper library which took me only a few days a
couple hours here and there . . .But the rest will take some time as I
learn how to get data from the Nodejs backend, to a web front end, such as
Angular, and I do not know what else right now . . .

Also for what it's worth. You do not need cape_universal=enable does not
need to be enabled in order to use config-pin, and universal IO.

On Wed, Jul 20, 2016 at 11:06 AM, William Hermans  wrote:

> If we create gpio/pinmux group, I think we could keep from burdening users
> while moving Cloud9 IDE to the 'debian' user. I believe we also have a
> sudoers for the 'debian' user, meaning we could probably at that point
> prevent direct root login unless someone does something to disable the root
> password. I'd worry about that breaking things like LabVIEW, etc., but if
> we can at least try out some minor steps towards security, it will at least
> make everyone more aware of the holes and challenges.
>
> I kind of roughly describe that here:
> https://github.com/wphermans/Bonejs/blob/master/documentation/permissions.md
> Although there is much mroe to consider than just the little bit I covered
> there. But that should be a good start.
>
> On Wed, Jul 20, 2016 at 11:00 AM, Jason Kridner <
> jason.krid...@hangerhead.com> wrote:
>
>>
>>
>> On Fri, Jun 24, 2016 at 8:10 PM Charles Steinkuehler <
>> char...@steinkuehler.net> wrote:
>>
>>> On 6/24/2016 5:52 PM, William Hermans wrote:
>>> > /Note the security 'bar' is not set particularly high, given the/
>>> > /default BBB images have no root password.  :)/
>>> >
>>> >
>>> > Thats been changed, since at least the last couple of images.
>>>
>>
>> I don't think that's the case---we still have no root password, though
>> one can be set. The Cloud9 IDE further doesn't require a login.
>>
>> If we create gpio/pinmux group, I think we could keep from burdening
>> users while moving Cloud9 IDE to the 'debian' user. I believe we also have
>> a sudoers for the 'debian' user, meaning we could probably at that point
>> prevent direct root login unless someone does something to disable the root
>> password. I'd worry about that breaking things like LabVIEW, etc., but if
>> we can at least try out some minor steps towards security, it will at least
>> make everyone more aware of the holes and challenges.
>>
>>
>>>
>>> Ahh...that's probably why you were getting the "askpass" errors.
>>>
>>> I haven't tried anything more recent than a few months ago.
>>>
>>> --
>>> Charles Steinkuehler
>>> char...@steinkuehler.net
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to 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/d19cdd9b-9ae5-08a8-6028-c

Re: [beagleboard] Re: cape-universal & 4.1.x = default.. ;)

[William Hermans]

If we create gpio/pinmux group, I think we could keep from burdening users
while moving Cloud9 IDE to the 'debian' user. I believe we also have a
sudoers for the 'debian' user, meaning we could probably at that point
prevent direct root login unless someone does something to disable the root
password. I'd worry about that breaking things like LabVIEW, etc., but if
we can at least try out some minor steps towards security, it will at least
make everyone more aware of the holes and challenges.

I kind of roughly describe that here:
https://github.com/wphermans/Bonejs/blob/master/documentation/permissions.md
Although there is much mroe to consider than just the little bit I covered
there. But that should be a good start.

On Wed, Jul 20, 2016 at 11:00 AM, Jason Kridner <
jason.krid...@hangerhead.com> wrote:

>
>
> On Fri, Jun 24, 2016 at 8:10 PM Charles Steinkuehler <
> char...@steinkuehler.net> wrote:
>
>> On 6/24/2016 5:52 PM, William Hermans wrote:
>> > /Note the security 'bar' is not set particularly high, given the/
>> > /default BBB images have no root password.  :)/
>> >
>> >
>> > Thats been changed, since at least the last couple of images.
>>
>
> I don't think that's the case---we still have no root password, though one
> can be set. The Cloud9 IDE further doesn't require a login.
>
> If we create gpio/pinmux group, I think we could keep from burdening users
> while moving Cloud9 IDE to the 'debian' user. I believe we also have a
> sudoers for the 'debian' user, meaning we could probably at that point
> prevent direct root login unless someone does something to disable the root
> password. I'd worry about that breaking things like LabVIEW, etc., but if
> we can at least try out some minor steps towards security, it will at least
> make everyone more aware of the holes and challenges.
>
>
>>
>> Ahh...that's probably why you were getting the "askpass" errors.
>>
>> I haven't tried anything more recent than a few months ago.
>>
>> --
>> Charles Steinkuehler
>> char...@steinkuehler.net
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to 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/d19cdd9b-9ae5-08a8-6028-cecbbea7d4f8%40steinkuehler.net
>> .
>> 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/CA%2BT6QPmBBQk0hy%2Bwz3ktPnaUYNoKC9aSvNK7y-xGDNc7gKaqUg%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/CALHSORoVNciV7%3DocOW9nxeUvMkvVN_jTnfSgynTDnh-9LemS8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: cape-universal & 4.1.x = default.. ;)

[Jason Kridner]

On Fri, Jun 24, 2016 at 8:10 PM Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 6/24/2016 5:52 PM, William Hermans wrote:
> > /Note the security 'bar' is not set particularly high, given the/
> > /default BBB images have no root password.  :)/
> >
> >
> > Thats been changed, since at least the last couple of images.
>

I don't think that's the case---we still have no root password, though one
can be set. The Cloud9 IDE further doesn't require a login.

If we create gpio/pinmux group, I think we could keep from burdening users
while moving Cloud9 IDE to the 'debian' user. I believe we also have a
sudoers for the 'debian' user, meaning we could probably at that point
prevent direct root login unless someone does something to disable the root
password. I'd worry about that breaking things like LabVIEW, etc., but if
we can at least try out some minor steps towards security, it will at least
make everyone more aware of the holes and challenges.


>
> Ahh...that's probably why you were getting the "askpass" errors.
>
> I haven't tried anything more recent than a few months ago.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to 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/d19cdd9b-9ae5-08a8-6028-cecbbea7d4f8%40steinkuehler.net
> .
> 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/CA%2BT6QPmBBQk0hy%2Bwz3ktPnaUYNoKC9aSvNK7y-xGDNc7gKaqUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] CAN over SPI using MCP2515 and Beaglebone

[John Syne]

If you are using a devicetree overlay, then SPI DMA won’t work. You have to 
build the driver into the base devicetree using dtb-rebuilder to get DMA to 
work with your SPI driver. 

Regards,
John




> On Feb 17, 2016, at 5:55 AM, pauldaniel...@gmail.com wrote:
> 
> Related question: I'm using the towertech CAN cape (mcp2515) and seeing a lot 
> of CPU usage by the spi process. For example, just connecting one interface 
> to an active bus gives 30-50% CPU usage, and that doesn't include actually 
> doing anything with the data! I'm running debian with kernel 3.8.13-bone70 
> and using the driver source they provide (mcp2515). Is this a known issue? 
> Has it been addressed in more recent kernels? 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0995AD0C-2685-4015-A6B6-C7F6174F50DC%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using PRU Cape, TI's product for BBB

[John Syne]

> On Jul 20, 2016, at 6:42 AM, Eshaan Ghosh  wrote:
> 
> I have recently purchased the PRU cape from TI for BBB and tried to run it by 
> following the instructions given in the wiki page and hands on lab
> 
> http://processors.wiki.ti.com/index.php/PRU_Cape_Getting_Started_Guide 
>  
> 
> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs 
> 
> but i really cannot understand how to use it. 
> 
> Do i need to connect an FTDI cable? If yes, then how with the cape sitting on 
> top of it which removes access to those pins?
> Is RS-232 used to debug the bbb?
The serial console is just for log output. 
>  How do i use CCS to connect to BBB using the cape and program it considering 
> I am familiar with coding TI DSPs?
You need JTAG to use CCSV6 with PRU. At reset, the PRUs are held in reset and 
the Remoteproc bootloader on the ARM processor loads the PRU firmware and  
takes the PRU out of reset. When you develop code on the PRU with CCSV6, you 
normally don’t have the ARM processor running, so TI provides GEL files to 
bring the PRU out of reset. The GEL files look very similar to C code and can 
directly read/write from/to AM335x I/O registers. After that, CCSV6 loads the 
code onto the PRU and then you have a full debugger available to step, set 
breakpoints, etc. If you have worked with DSPs, then this will be familiar to 
you.

Regards,
John
> I want to access the PRU in the BBB and program using CCSv6 like it is done 
> for DSPs. Thus I have purchased the cape.
> 
> Any help would be appreciated.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to 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/4c0e34f3-1e17-465a-98f3-624247728d7d%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/9F125C0B-6D55-4204-B072-BD3B8BF2E827%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB, device tree seems to work, but no /dev/spidev?

[William Hermans]

>
> I Will recompile the dtb from Robert git and flash the SD care. I Will
> keep my Kernel version since I have already use it for the PRU. I will let
> you know if this is work. I will also try to modify the uEnv.txt however I
> don't know if this will work with the 4.1.21 I am using.
> Thanks William
>

As far as the uEnv.txt file , and all that it's going to be identical
between 4.4.x, and 4.1.x. Or close to it. The problem is going to lay in
drivers, implementations of drivers, and things of that nature.


On Wed, Jul 20, 2016 at 8:47 AM, malkowki  wrote:

> I Will recompile the dtb from Robert git and flash the SD care. I Will
> keep my Kernel version since I have already use it for the PRU. I will let
> you know if this is work. I will also try to modify the uEnv.txt however I
> don't know if this will work with the 4.1.21 I am using.
> Thanks William
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to 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/8873538f-7d58-46dc-bb90-ae49984eaf45%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/CALHSORoNtphxDA7Tbhs3uhevPu8-n3_BqSn8GH9W279RsLe0UA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[William Hermans]

Well, I like to document stuff, as I'm  a very technical person. The
problem is, when you have a professional gig, and other things all
happening at the same time. Some things just don't get done as often as I'd
like. There is also a big difference between helping someone here, and
writing  blog post on that same subject. It takes a considerable amount of
time to blog on things. As people, at least I  want things to be accurate,
and concise as possible. Where helping out here: I can be more casual as
the nit picks of this and that do not matter so much as just achieving the
end goal.

On Wed, Jul 20, 2016 at 8:41 AM, Joseph Heller 
wrote:

> Hello William,
>
> Nice page there William.
>
> Yes we have the right installation written above for using uio.
> Documenting it on eLinux seems to be the next logical thing also. I'm
> opting to help here, already registered with my account on eLinux, or go
> for a personal page as well. There's a weak spot though. I see the pace at
> which kernel and surroundings changes is quite fast if you take a minute to
> look back, I think therefore the info, once written down, is outdated quite
> fast as well consequently. Take a look at this page for instance:
> http://elinux.org/Ti_AM33XX_PRUSSv2. It still assumes uio, but remoteproc
> now being the preferred/standard. So I think there needs to be a tighter
> link between developer and documentation to keep all in sync. The beagle
> bone project would benefit from this tighter link to my opinion. Thinking
> out loud, also here, a more modular approach on the beagle bone software
> would help. Like to use uio? Use this kernel, install this .deb, and your
> ready to go (ideally). Any changes under the hood are then kept inside the
> .deb that is affected, and documentation (or installed base so to speak
> further down the line) is much easier to maintain / keep up to date from
> user perspective.
>
> My 2 cents... but again, happy with the help offered!
>
> Regards,
> Joseph
>
> On Tuesday, July 19, 2016 at 7:06:36 PM UTC+2, William Hermans wrote:
>>
>> I think it's pretty well documented here. However you could always write
>> up an eLinux or whatever wiki page . . . I do have my own web page
>> http://www.embeddedhobbyist.com/ with stuff on it that is important to
>> me. But this information for using UIO on TI kernels I feel is largely
>> useless. Because
>>
>> The method for enabling either / or will likely change in the future.
>> Right now, personally I'm still favoring *bone* kernels, and I know I'm
>> not alone.
>> This is really a trivial "fix". Or something that is really easy to
>> remember how to do.
>>
>> @Robert, any idea on if TI plans on cleaning up the kernel module mess
>> that now "infests" TI kernels ? using something like 50M + memory
>> needlessly . . .
>>
>>
>>
>> On Tue, Jul 19, 2016 at 9:52 AM, Joseph Heller 
>> wrote:
>>
>>> Finally, that worked William (&John &Robert)! I did a small check with
>>> an LED and am able to with it on/off now via the PRU and uio.
>>>
>>> For your consideration, I wonder how you feel like to document this more
>>> structurally so others can benefit from it? I was offset by some older
>>> posts on the forum. Next thing I just though about is to make more use of
>>> the .deb functionality instead of relying on script or instructions. For
>>> instance uio "conflicts" with remoteproc in reality, but both reside on the
>>> same sd-card image. Otherwise, I also understood the PRU's are not that
>>> much used, so maybe it;s not worth the effort to invest in this.
>>>
>>> Anyway, thanks again for the help, I'd be glad to inform/post the end
>>> result of my project somewhere once my time-critical part of c code as
>>> transferred to the PRU.
>>>
>>> On Monday, July 18, 2016 at 10:30:35 PM UTC+2, William Hermans wrote:
>>>
 Well, not to mention you installed a *bone* kernel anyhow. So what
 we're talking about is really moot. e.g. a topic for a different 
 discussion.

 So. . . back on topic . . .

 *Download suitable linu image and reboot:*
 william@beaglebone:~$ sudo apt-get install linux-image-4.4.14-ti-r34
 william@beaglebone:~$ sudo reboot

 *Install git and check your dtc version:*
 william@beaglebone:~$ sudo apt-get install git
 william@beaglebone:~$ dtc -v
 Version: DTC 1.4.1

 *Clone the git into a suitable location:*
 william@beaglebone:~$ cd dev
 git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder
 dtb-4.4-ti --depth=1
 william@beaglebone:~/dev$ cd dtb-4.4-ti/

 *Edit the needed board file( this will be different for every situation
 )*
 william@beaglebone:~/dev/dtb-4.4-ti$ nano
 src/arm/am335x-boneblack-emmc-overlay.dts
 change:
 /* #include "am33xx-pruss-uio.dtsi" */
 to:
 #include "am33xx-pruss-uio.dtsi"

 *Build from source, and install the board file:*
 william@beaglebone:~/dev/dtb-4.4-ti$ make
 william@beaglebone:~/dev/d

Re: [beagleboard] Re: BBB, device tree seems to work, but no /dev/spidev?

[malkowki]

I Will recompile the dtb from Robert git and flash the SD care. I Will keep my 
Kernel version since I have already use it for the PRU. I will let you know if 
this is work. I will also try to modify the uEnv.txt however I don't know if 
this will work with the 4.1.21 I am using. 
Thanks William 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/8873538f-7d58-46dc-bb90-ae49984eaf45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: cape-universal & 4.1.x = default.. ;)

[TJF]

Hi William!

Am Dienstag, 19. Juli 2016 19:54:02 UTC+2 schrieb William Hermans:
>
> SO, after talking with Robert and finding that all these kernel modules 
> that get loaded from cape_universal=enable. I wonder how this impacts other 
> capes such as the Logic supply RS232 / CAN cape that automatically loads 
> it's own device tree  overlay.
>
> Could capes such as this be loaded first, and then still have universal-io 
> capabilities ? 
>

You can replace cape_universal by the libpruio universal overlay. That 
doesn't enable drivers/subsystems (= saves power and resources 
consumptions), but has the same pinmuxing capability. It's even more safe, 
since it seems that cape_universal can damage your CPU by a sequence like

config-pin P9_42 gpio high
config-pin P9_92 gpio low

(I didn't test it, but if you do so, please report.)

Regarding other capes, libpruio ships with a tool to adapt the universal 
device tree overlay. It can generate overlays that do not claim a specified 
set of pins. Instead of fiddling with device tree entries, you just list 
the pins you want to get freed and let the tool deal with the low-level 
stuff. Such an overlay can get loaded before or after any other cape 
overlay.

In order to replace the config_pin tool, you can write small programs 
(compiled against libpruio), which do the pinmuxing and enable the 
subsystems in use (only that ones).

BR

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/87197b98-c1dc-472e-9919-cd2b4fa4aab5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

Hello William, 

Nice page there William. 

Yes we have the right installation written above for using uio. Documenting 
it on eLinux seems to be the next logical thing also. I'm opting to help 
here, already registered with my account on eLinux, or go for a personal 
page as well. There's a weak spot though. I see the pace at which kernel 
and surroundings changes is quite fast if you take a minute to look back, I 
think therefore the info, once written down, is outdated quite fast as well 
consequently. Take a look at this page for 
instance: http://elinux.org/Ti_AM33XX_PRUSSv2. It still assumes uio, but 
remoteproc now being the preferred/standard. So I think there needs to be a 
tighter link between developer and documentation to keep all in sync. The 
beagle bone project would benefit from this tighter link to my opinion. 
Thinking out loud, also here, a more modular approach on the beagle bone 
software would help. Like to use uio? Use this kernel, install this .deb, 
and your ready to go (ideally). Any changes under the hood are then kept 
inside the .deb that is affected, and documentation (or installed base so 
to speak further down the line) is much easier to maintain / keep up to 
date from user perspective. 

My 2 cents... but again, happy with the help offered!

Regards,
Joseph

On Tuesday, July 19, 2016 at 7:06:36 PM UTC+2, William Hermans wrote:
>
> I think it's pretty well documented here. However you could always write 
> up an eLinux or whatever wiki page . . . I do have my own web page 
> http://www.embeddedhobbyist.com/ with stuff on it that is important to 
> me. But this information for using UIO on TI kernels I feel is largely 
> useless. Because 
>
> The method for enabling either / or will likely change in the future.
> Right now, personally I'm still favoring *bone* kernels, and I know I'm 
> not alone.
> This is really a trivial "fix". Or something that is really easy to 
> remember how to do.
>
> @Robert, any idea on if TI plans on cleaning up the kernel module mess 
> that now "infests" TI kernels ? using something like 50M + memory 
> needlessly . . .
>  
>
>
> On Tue, Jul 19, 2016 at 9:52 AM, Joseph Heller  > wrote:
>
>> Finally, that worked William (&John &Robert)! I did a small check with an 
>> LED and am able to with it on/off now via the PRU and uio. 
>>
>> For your consideration, I wonder how you feel like to document this more 
>> structurally so others can benefit from it? I was offset by some older 
>> posts on the forum. Next thing I just though about is to make more use of 
>> the .deb functionality instead of relying on script or instructions. For 
>> instance uio "conflicts" with remoteproc in reality, but both reside on the 
>> same sd-card image. Otherwise, I also understood the PRU's are not that 
>> much used, so maybe it;s not worth the effort to invest in this.
>>
>> Anyway, thanks again for the help, I'd be glad to inform/post the end 
>> result of my project somewhere once my time-critical part of c code as 
>> transferred to the PRU. 
>>
>> On Monday, July 18, 2016 at 10:30:35 PM UTC+2, William Hermans wrote:
>>
>>> Well, not to mention you installed a *bone* kernel anyhow. So what we're 
>>> talking about is really moot. e.g. a topic for a different discussion.
>>>
>>> So. . . back on topic . . .
>>>
>>> *Download suitable linu image and reboot:*
>>> william@beaglebone:~$ sudo apt-get install linux-image-4.4.14-ti-r34
>>> william@beaglebone:~$ sudo reboot
>>>
>>> *Install git and check your dtc version:*
>>> william@beaglebone:~$ sudo apt-get install git
>>> william@beaglebone:~$ dtc -v
>>> Version: DTC 1.4.1
>>>
>>> *Clone the git into a suitable location:*
>>> william@beaglebone:~$ cd dev
>>> git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder 
>>> dtb-4.4-ti --depth=1 
>>> william@beaglebone:~/dev$ cd dtb-4.4-ti/
>>>
>>> *Edit the needed board file( this will be different for every situation 
>>> )*
>>> william@beaglebone:~/dev/dtb-4.4-ti$ nano 
>>> src/arm/am335x-boneblack-emmc-overlay.dts
>>> change:
>>> /* #include "am33xx-pruss-uio.dtsi" */
>>> to:
>>> #include "am33xx-pruss-uio.dtsi"
>>>
>>> *Build from source, and install the board file:*
>>> william@beaglebone:~/dev/dtb-4.4-ti$ make
>>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo make install
>>>
>>> *Blacklist the remoteproc drivers:*
>>> william@beaglebone:~/dev/dtb-rebuilder$ sudo nano 
>>> /etc/modprobe.d/pruss-blacklist.conf
>>> blacklist pruss
>>> blacklist pruss_intc
>>> blacklist pru-rproc
>>> william@beaglebone:~/dev$ sudo reboot
>>>
>>> *Test to see if the device tree file loaded successfully:*
>>> william@beaglebone:~$ lsmod |grep  uio
>>> uio_pruss   4928  0
>>> uio_pdrv_genirq 3539  0
>>> uio 8822  2 uio_pruss,uio_pdrv_genirq
>>>
>>> On Mon, Jul 18, 2016 at 1:12 PM, Robert Nelson  
>>> wrote:
>>>


 On Mon, Jul 18, 2016 at 3:08 PM, Joseph Heller  
 wrote:

> small progress here; 
> 4.4.x-ti r34 did no

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

Ok thanks Robert, 

Yes, well, some rationale at least from my side as input. After I've 
checked my options to go for PRU, I found there's both remoteproc and uio. 
At first glance, I did not like the remoteproc implementation as it appears 
to be more of an interrupt based approach. I think this is more towards 
userspace program on the main processor that does not do that much harm, 
but for the PRU being the opportunity to do hard real time stuff (although 
not really interrupt based but polling-wise) a somewhat weird concept 
choice. I've seen an idea to let PRU1 handle the interrupts, and use PRU2 
to interact with PRU1 for the real realtime stuff which does sound like a 
compromise. So my "instinct" for what it's worth was to steer clear of 
remoteproc and use uio. It fitted my application better as well to have 
shared memory both accessible to PRU and userspace. As far as I could tell 
a couple of weeks ago this is not possible with remoteproc. I might be 
wrong though, but this is how I came to the conclusion to go for uio. 

Regards,
Maarten

On Tuesday, July 19, 2016 at 7:05:33 PM UTC+2, RobertCNelson wrote:
>
> Hi Joseph,
>
> On Tue, Jul 19, 2016 at 11:52 AM, Joseph Heller  > wrote:
>
>> Finally, that worked William (&John &Robert)! I did a small check with an 
>> LED and am able to with it on/off now via the PRU and uio. 
>>
>> For your consideration, I wonder how you feel like to document this more 
>> structurally so others can benefit from it? I was offset by some older 
>> posts on the forum. Next thing I just though about is to make more use of 
>> the .deb functionality instead of relying on script or instructions. For 
>> instance uio "conflicts" with remoteproc in reality, but both reside on the 
>> same sd-card image. Otherwise, I also understood the PRU's are not that 
>> much used, so maybe it;s not worth the effort to invest in this.
>>
>> Anyway, thanks again for the help, I'd be glad to inform/post the end 
>> result of my project somewhere once my time-critical part of c code as 
>> transferred to the PRU. 
>>
>
> So i'm hoping, this will only be short term.  I believe everyone at ti, 
> now has a crystal clear idea of what users want from the pruss interface.  
> So hopefully this uio/remoteproc will get fixed..  A couple notes on the 
> script, normally the dtb-rebuilder repo can be found here:
>
> /opt/source/dtb-4.4-ti/
>
> It's just for a few releases, that didn't get cloned properly.
>  
> 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/9ada81cc-b65b-430e-bb6a-291580a892a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Memory crawler for eMMC partitions

[Ankur Tank]

I am not sure If I understood it correctly,
But I assume that you are asking if we are using mmc lines for some other 
hardware or not, right ?
mmc lines are dedicatedly used for eMMC only.

But other scripts can be running in parallel to upgrade the OS in other 
partition to newer OS.
So I was thinking what will happen if write/erase and read happens 
simultaneously.

Thank you,
Ankur

On Wednesday, 20 July 2016 20:29:32 UTC+5:30, RobertCNelson wrote:

>
>
> On Wed, Jul 20, 2016 at 9:56 AM, Ankur Tank  > wrote:
>
>> Thank you for reply Mr. Nelson,
>>
>> That's the simplest solution I was also thinking.
>> Here are my timings.
>>
>> # time cat /dev/mmcblk0 > /dev/null 
>> real1m 52.01s
>> user0m 0.55s
>> sys 0m 21.74s
>>
>> However I think I have to take care that not partitions are being 
>> erased/written at the time when I run this script, right ?
>>
>
> Why? other then your mmc io maxed out, with cat your just "reading" and 
> dumping it to /dev/null...
>
> 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/ced104ea-7bd1-4c7e-ad18-b0c3edd3bf82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB, device tree seems to work, but no /dev/spidev?

[William Hermans]

Ok, so are these modules loaded ?

william@beaglebone:~/dev$ lsmod | grep spi
spidev  7523  0
spi_omap2_mcspi11148  0

I show . . .

william@beaglebone:~/dev$ ls /dev | grep spi
spidev1.0
spidev1.1
spidev2.0
spidev2.1

I am however using Charles' universal IO, and loading univ-all at boot plus
cape_universal=enabled in /boot/uEnv.txt. I am using a newer kernel version
however . . .

william@beaglebone:~/dev$ uname -r
4.4.14-ti-r34

One thing you can check in /boot/uEnv.txt though is to make sure that this
line:

cmdline=coherent_pool=1M quiet cape_universal=enable

is commented out. Or at east remove the cape_universal=enable part is
removed.




On Wed, Jul 20, 2016 at 7:46 AM, William Hermans  wrote:

> So, this is the file I remember seeing Robert talk about:
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-overlay-edma-fix.dtsi
>
> Which if we look at this it's already loaded . . .
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-overlay.dts#L12
>
> investigating further . . .
>
> On Wed, Jul 20, 2016 at 7:38 AM, William Hermans 
> wrote:
>
>> Hello William,
>>>
>>>
>>> do you mean to configure SPI in the am335x-boneblack-overlay.dts?
>>> an set spi module to be set as built-in in the kernel?
>>>
>>> Can you explain a bit? Isn't clear for me
>>>
>>
>> Yes, sorry I was not clearer, however I've not personal hands on, only
>> remember Robert mentioning it before. However, if we search the board file
>> for "SPI", and include for *something* SPI _ dtsi should stand out. Let me
>> see if I can find something quicly.
>>
>> On Wed, Jul 20, 2016 at 7:35 AM, malkowki 
>> wrote:
>>
>>> Hello William,
>>>
>>>
>>> do you mean to configure SPI in the am335x-boneblack-overlay.dts?
>>> an set spi module to be set as built-in in the kernel?
>>>
>>> Can you explain a bit? Isn't clear for me.
>>>
>>> Le mercredi 20 juillet 2016 15:45:31 UTC+2, William Hermans a écrit :


 I have also attached my Kernel Config file and the bootloog.
 Is Anyone to guide me how to solve this issue?


 I do believe that SPI has to be loaded earlier in the boot stage. I
 seem to recall this fix for this to be loading SPI from within the main
 board file.

 On Wed, Jul 20, 2016 at 5:33 AM, malkowki  wrote:

> Hi everyone,
>
> I am runing Linux version 4.1.21-bone-rt-r20 from Robert Nelson
> repository and I have the same issue.
> The DTS seems ok but the SPI module does't appear under /dev/.
> my uEnv.txt look like this:
> uname_r=4.1.21-bone-rt-r20
> optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-
> BONELT-HDMIN
> cape_enable=bone_capemgr.enable_partno=BB-SPI0-01
> If I do cat $SLOTS I have :
> 0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-SPI0-01
>
>
> I have also attached my Kernel Config file and the bootloog.
> Is Anyone to guide me how to solve this issue?
>
> thanks,
>
>
> Le samedi 27 juillet 2013 23:44:28 UTC+2, Nigel Magnay a écrit :
>>
>>
>> I'm trying to activate SPI on a BBB. I think it's nearly there, save
>> for a lack of anything in /dev, which is mysterious.
>>
>> I'm trying for SPI0 (I understand SPI1 requires HDMI deactivation).
>>
>> Brand new A5C board, uname -a is
>> Linux beaglebone 3.8.13 #1 SMP Tue Jun 18 02:11:09 EDT 2013 armv7l
>> GNU/Linux
>>
>> Followed http://elinux.org/BeagleBone_Black_Enable_SPIDEV, save for
>> - my /lib/firmware already had BB-SPI0, so I used that
>> - I didn't understand "Go to My Computer>BeagleBone Getting
>> Started>". The mounted USB drive device is read-only. I modified the
>> uEnv.txt in /boot, seems to work.
>>
>> Slots shows it there:
>> root@beaglebone:~# cat /sys/devices/bone_capemgr.8/slots
>>  0: 54:PF---
>>  1: 55:PF---
>>  2: 56:PF---
>>  3: 57:PF---
>>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI0
>>
>> root@beaglebone:~# cat
>> /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups
>> registered pin groups:
>>
>> 
>> group: pinmux_bb_spi0_pins
>> pin 84 (44e10950)
>> pin 85 (44e10954)
>> pin 86 (44e10958)
>> pin 87 (44e1095c)
>> ...
>>
>> It appears in the dmesg output
>> root@beaglebone:/dev# dmesg |grep SPI
>> [0.00] Kernel command line: console=ttyO0,115200n8 quiet
>> drm.debug=7 capemgr.enable_partno=BB-SPI0 root=/dev/mmcblk0p2 ro
>> rootfstype=ext4 rootwait
>> [0.399220] bone-capemgr bone_capemgr.8: enabled_partno
>> part_number 'BB-SPI0', version 'N/A'
>> [0.399293] bone-capemgr bone_capemg

Re: [beagleboard] Memory crawler for eMMC partitions

[Robert Nelson]

On Wed, Jul 20, 2016 at 9:56 AM, Ankur Tank  wrote:

> Thank you for reply Mr. Nelson,
>
> That's the simplest solution I was also thinking.
> Here are my timings.
>
> # time cat /dev/mmcblk0 > /dev/null
> real1m 52.01s
> user0m 0.55s
> sys 0m 21.74s
>
> However I think I have to take care that not partitions are being
> erased/written at the time when I run this script, right ?
>

Why? other then your mmc io maxed out, with cat your just "reading" and
dumping it to /dev/null...

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/CAOCHtYhYoiyPAR_ToHgvDL%2BaWHKG%3De%3DhXR5SeAaVAwtL3Cis5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Memory crawler for eMMC partitions

[Ankur Tank]

Thank you for reply Mr. Nelson,

That's the simplest solution I was also thinking.
Here are my timings.

# time cat /dev/mmcblk0 > /dev/null 
real1m 52.01s
user0m 0.55s
sys 0m 21.74s

However I think I have to take care that not partitions are being 
erased/written at the time when I run this script, right ?

On Wednesday, 20 July 2016 20:10:53 UTC+5:30, RobertCNelson wrote:
>
>
>
> On Wed, Jul 20, 2016 at 9:23 AM, Ankur Tank  > wrote:
>
>>
>> We have BBB based custom board with 256MB RAM and 4GB eMMC running Linux 
>> kernel 3.12
>>
>> *TL;DR*: Is there a open source application which periodically reads 
>> unread/rarely used partition to increase data retention? OR Is there any 
>> kernel service which can be configure
>>
>> *Detailed query,*
>> We have 3 sets of partition for OS(Bootloader, kernel+dtb & RFS) eMMC. 
>> One of them is recovery OS. Which is rarely read( none of the time 
>> written).
>>
>> Now as per eMMC manufacturerer,
>> "*If a byte is not read in 5 years there is no guarantee that byte is 
>> valid when read after 5 years.*"
>> To avoid such situation we want to have a crawler application, which 
>> would read all the unused/unread partition may be once in a year and 
>> increase data retention.
>>
>> I didn't find any open source application or kernel service/daemon which 
>> would handle that. But not sure If I am searching it correctly or not.
>>
>> Meanwhile If there is no solution available for this, I am planning to do 
>> it in following way.
>>
>> 1. Setup a cron job which would trigger once in a year and run a script.
>> 2. Script would read all the partition using dd and return.
>>
>> What do you think about this approach.
>> Let me know if you have any suggestion/correction/pointers for me.
>>
>
>
> debian@test-bbb-1:~$ time sudo cat /dev/mmcblk1 > /dev/null
>
> real 1m20.209s
> user 0m0.050s
> sys 0m14.530s
>
> That was for a 2GB eMMC, so double the time for a 4GB..
>
> But in reality, with eMMC, we are still only talking with the controller, 
> not directly with the NAND. So even a cat won't read every 'byte' as the 
> controller is doing it's own thing...
>
> 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/ad5d2b08-f70a-4cb1-a9f7-83252f076bc0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: UART, serial port read C/C++

[Wally Bkg]

On Tuesday, May 6, 2014 at 1:42:34 PM UTC-5, Andrey wrote:
>
> Hello,
>
> I need to use an UART to communicate between beaglebone and the device. I 
> have written the C code, but it has a few problems within it. I can't 
> identify the cause of the problem or to be more precise don't know how fix 
> it.  
>
> The problem is of 
> reading in the information and displaying it on a shell. I can easily 
> write any information data set that I wish, but when I try to read in 
> response it either doesn't read in, with the perror being displayed as 
> (erno = EINTR [Interrupted function call]) meaning read () function 
> returned negative number. 
>  
>
> fd = open(PORT, O_RDWR | O_NOCTTY | O_NONBLOCK);
>
> if (fd<0) {perror(PORT); exit(-1);}
>
>  
>

I think Simon's post will get you on the right track.  You are sending a 
command over the UART and expecting a response back, you pretty much have 
to block or read in a loop to give the external device time to reply.

I open the port (O_RDWR | O_NOCTTY | O_NDELAY) and use 
options.c_cc[VMIN]  = 0; // wait for each character
options.c_cc[VTIME] = 10; // wait time in 1/10s of a second

Which will time out after 1 second without response (a true error for my 
device, or a signal that the response string is complete)


Here is a code snippet of the function I use to check the signal strength 
of a cell phone modem:

int check_signal(int fd){
char buffer[256];
char *bufptr;
int bytes, n=0, nbytes=0;
char tstr[64];
if (write(fd, "AT+CSQ\r", 7) <7){
printf("%s *** ERROR! writing AT+CSQ command! ***\n",getDateTime(tstr));
FONA_DEAD=1; // send text message that FONA backup messaging system not 
working
return(-1);
}else{
while ((bytes = read(fd, &buffer[nbytes], sizeof(buffer)-nbytes-1)) > 
0){ nbytes += bytes; }
buffer[nbytes] = '\0'; // nul terminate the string
if(nbytes>0){
if(bufptr=strstr(buffer,"+CSQ:")){
sscanf(bufptr,"+CSQ: %i", &n);
//if(n==0) printf("sscanf fail: %s\n", buffer);  // actually was 
intermittently 0 signal strength with some antenna positions!
//printf("Signal Strength: %i\n",n);
return(n);
}else{
// getting occasional failures, try to tell if its time outs or 
unexpected characters that weren't flushed after previous function
// if I don't see this message from the errors increase time out a bit
printf("%s *** check_signal() Unexpected Response! 
***\n%s\n",getDateTime(tstr),buffer);
return(-2);
}
}
}
}



It sends a multi-byte command string and then waits in a loop for a 
multi-byte response than ends with a timeout after the last character is 
received.  If you always get a fixed length
reply you can make the code more responsive by exiting after the last 
character comes in, instead of waiting for the timeout. 

I generally find it easier to put blocking code in separate threads than to 
try to do non-blocking read/write in a main loop.  YMMV.

The suggestion below to use select() is also a good option.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/8d4fc307-ef27-4137-bbb2-3fb5feb01bb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB, device tree seems to work, but no /dev/spidev?

[William Hermans]

So, this is the file I remember seeing Robert talk about:
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-overlay-edma-fix.dtsi

Which if we look at this it's already loaded . . .
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-overlay.dts#L12

investigating further . . .

On Wed, Jul 20, 2016 at 7:38 AM, William Hermans  wrote:

> Hello William,
>>
>>
>> do you mean to configure SPI in the am335x-boneblack-overlay.dts?
>> an set spi module to be set as built-in in the kernel?
>>
>> Can you explain a bit? Isn't clear for me
>>
>
> Yes, sorry I was not clearer, however I've not personal hands on, only
> remember Robert mentioning it before. However, if we search the board file
> for "SPI", and include for *something* SPI _ dtsi should stand out. Let me
> see if I can find something quicly.
>
> On Wed, Jul 20, 2016 at 7:35 AM, malkowki 
> wrote:
>
>> Hello William,
>>
>>
>> do you mean to configure SPI in the am335x-boneblack-overlay.dts?
>> an set spi module to be set as built-in in the kernel?
>>
>> Can you explain a bit? Isn't clear for me.
>>
>> Le mercredi 20 juillet 2016 15:45:31 UTC+2, William Hermans a écrit :
>>>
>>>
>>> I have also attached my Kernel Config file and the bootloog.
>>> Is Anyone to guide me how to solve this issue?
>>>
>>>
>>> I do believe that SPI has to be loaded earlier in the boot stage. I seem
>>> to recall this fix for this to be loading SPI from within the main board
>>> file.
>>>
>>> On Wed, Jul 20, 2016 at 5:33 AM, malkowki  wrote:
>>>
 Hi everyone,

 I am runing Linux version 4.1.21-bone-rt-r20 from Robert Nelson
 repository and I have the same issue.
 The DTS seems ok but the SPI module does't appear under /dev/.
 my uEnv.txt look like this:
 uname_r=4.1.21-bone-rt-r20
 optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-
 BONELT-HDMIN
 cape_enable=bone_capemgr.enable_partno=BB-SPI0-01
 If I do cat $SLOTS I have :
 0: PF  -1
  1: PF  -1
  2: PF  -1
  3: PF  -1
  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-SPI0-01


 I have also attached my Kernel Config file and the bootloog.
 Is Anyone to guide me how to solve this issue?

 thanks,


 Le samedi 27 juillet 2013 23:44:28 UTC+2, Nigel Magnay a écrit :
>
>
> I'm trying to activate SPI on a BBB. I think it's nearly there, save
> for a lack of anything in /dev, which is mysterious.
>
> I'm trying for SPI0 (I understand SPI1 requires HDMI deactivation).
>
> Brand new A5C board, uname -a is
> Linux beaglebone 3.8.13 #1 SMP Tue Jun 18 02:11:09 EDT 2013 armv7l
> GNU/Linux
>
> Followed http://elinux.org/BeagleBone_Black_Enable_SPIDEV, save for
> - my /lib/firmware already had BB-SPI0, so I used that
> - I didn't understand "Go to My Computer>BeagleBone Getting
> Started>". The mounted USB drive device is read-only. I modified the
> uEnv.txt in /boot, seems to work.
>
> Slots shows it there:
> root@beaglebone:~# cat /sys/devices/bone_capemgr.8/slots
>  0: 54:PF---
>  1: 55:PF---
>  2: 56:PF---
>  3: 57:PF---
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI0
>
> root@beaglebone:~# cat
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups
> registered pin groups:
>
> 
> group: pinmux_bb_spi0_pins
> pin 84 (44e10950)
> pin 85 (44e10954)
> pin 86 (44e10958)
> pin 87 (44e1095c)
> ...
>
> It appears in the dmesg output
> root@beaglebone:/dev# dmesg |grep SPI
> [0.00] Kernel command line: console=ttyO0,115200n8 quiet
> drm.debug=7 capemgr.enable_partno=BB-SPI0 root=/dev/mmcblk0p2 ro
> rootfstype=ext4 rootwait
> [0.399220] bone-capemgr bone_capemgr.8: enabled_partno part_number
> 'BB-SPI0', version 'N/A'
> [0.399293] bone-capemgr bone_capemgr.8: slot #7: 'Override Board
> Name,00A0,Override Manuf,BB-SPI0'
> [0.404238] bone-capemgr bone_capemgr.8: loader: before slot-7
> BB-SPI0:00A0 (prio 0)
> [0.404261] bone-capemgr bone_capemgr.8: loader: check slot-7
> BB-SPI0:00A0 (prio 0)
> [0.404286] bone-capemgr bone_capemgr.8: loader: after slot-7
> BB-SPI0:00A0 (prio 0)
> [0.404315] bone-capemgr bone_capemgr.8: slot #7: Requesting part
> number/version based 'BB-SPI0-00A0.dtbo
> [0.404345] bone-capemgr bone_capemgr.8: slot #7: Requesting
> firmware 'BB-SPI0-00A0.dtbo' for board-name 'Override Board Name', version
> '00A0'
> [0.404401] bone-capemgr bone_capemgr.8: slot #7: dtbo
> 'BB-SPI0-00A0.dtbo' loaded; converting to live tree
> [0.409351] bone-capemgr bone_capemgr.8: loader: done slot-7
> BB-SPI0:00A0 (

Re: [beagleboard] Memory crawler for eMMC partitions

[Robert Nelson]

On Wed, Jul 20, 2016 at 9:23 AM, Ankur Tank  wrote:

>
> We have BBB based custom board with 256MB RAM and 4GB eMMC running Linux
> kernel 3.12
>
> *TL;DR*: Is there a open source application which periodically reads
> unread/rarely used partition to increase data retention? OR Is there any
> kernel service which can be configure
>
> *Detailed query,*
> We have 3 sets of partition for OS(Bootloader, kernel+dtb & RFS) eMMC.
> One of them is recovery OS. Which is rarely read( none of the time
> written).
>
> Now as per eMMC manufacturerer,
> "*If a byte is not read in 5 years there is no guarantee that byte is
> valid when read after 5 years.*"
> To avoid such situation we want to have a crawler application, which would
> read all the unused/unread partition may be once in a year and increase
> data retention.
>
> I didn't find any open source application or kernel service/daemon which
> would handle that. But not sure If I am searching it correctly or not.
>
> Meanwhile If there is no solution available for this, I am planning to do
> it in following way.
>
> 1. Setup a cron job which would trigger once in a year and run a script.
> 2. Script would read all the partition using dd and return.
>
> What do you think about this approach.
> Let me know if you have any suggestion/correction/pointers for me.
>


debian@test-bbb-1:~$ time sudo cat /dev/mmcblk1 > /dev/null

real 1m20.209s
user 0m0.050s
sys 0m14.530s

That was for a 2GB eMMC, so double the time for a 4GB..

But in reality, with eMMC, we are still only talking with the controller,
not directly with the NAND. So even a cat won't read every 'byte' as the
controller is doing it's own thing...

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/CAOCHtYi7%3DKeg7Le%2Bd066OXhscNwj10Mee9-yZbXanjb%2BYZgKrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB, device tree seems to work, but no /dev/spidev?

[William Hermans]

>
> Hello William,
>
>
> do you mean to configure SPI in the am335x-boneblack-overlay.dts?
> an set spi module to be set as built-in in the kernel?
>
> Can you explain a bit? Isn't clear for me
>

Yes, sorry I was not clearer, however I've not personal hands on, only
remember Robert mentioning it before. However, if we search the board file
for "SPI", and include for *something* SPI _ dtsi should stand out. Let me
see if I can find something quicly.

On Wed, Jul 20, 2016 at 7:35 AM, malkowki  wrote:

> Hello William,
>
>
> do you mean to configure SPI in the am335x-boneblack-overlay.dts?
> an set spi module to be set as built-in in the kernel?
>
> Can you explain a bit? Isn't clear for me.
>
> Le mercredi 20 juillet 2016 15:45:31 UTC+2, William Hermans a écrit :
>>
>>
>> I have also attached my Kernel Config file and the bootloog.
>> Is Anyone to guide me how to solve this issue?
>>
>>
>> I do believe that SPI has to be loaded earlier in the boot stage. I seem
>> to recall this fix for this to be loading SPI from within the main board
>> file.
>>
>> On Wed, Jul 20, 2016 at 5:33 AM, malkowki  wrote:
>>
>>> Hi everyone,
>>>
>>> I am runing Linux version 4.1.21-bone-rt-r20 from Robert Nelson
>>> repository and I have the same issue.
>>> The DTS seems ok but the SPI module does't appear under /dev/.
>>> my uEnv.txt look like this:
>>> uname_r=4.1.21-bone-rt-r20
>>> optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-
>>> BONELT-HDMIN
>>> cape_enable=bone_capemgr.enable_partno=BB-SPI0-01
>>> If I do cat $SLOTS I have :
>>> 0: PF  -1
>>>  1: PF  -1
>>>  2: PF  -1
>>>  3: PF  -1
>>>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-SPI0-01
>>>
>>>
>>> I have also attached my Kernel Config file and the bootloog.
>>> Is Anyone to guide me how to solve this issue?
>>>
>>> thanks,
>>>
>>>
>>> Le samedi 27 juillet 2013 23:44:28 UTC+2, Nigel Magnay a écrit :


 I'm trying to activate SPI on a BBB. I think it's nearly there, save
 for a lack of anything in /dev, which is mysterious.

 I'm trying for SPI0 (I understand SPI1 requires HDMI deactivation).

 Brand new A5C board, uname -a is
 Linux beaglebone 3.8.13 #1 SMP Tue Jun 18 02:11:09 EDT 2013 armv7l
 GNU/Linux

 Followed http://elinux.org/BeagleBone_Black_Enable_SPIDEV, save for
 - my /lib/firmware already had BB-SPI0, so I used that
 - I didn't understand "Go to My Computer>BeagleBone Getting Started>".
 The mounted USB drive device is read-only. I modified the uEnv.txt in
 /boot, seems to work.

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

 root@beaglebone:~# cat
 /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups
 registered pin groups:

 
 group: pinmux_bb_spi0_pins
 pin 84 (44e10950)
 pin 85 (44e10954)
 pin 86 (44e10958)
 pin 87 (44e1095c)
 ...

 It appears in the dmesg output
 root@beaglebone:/dev# dmesg |grep SPI
 [0.00] Kernel command line: console=ttyO0,115200n8 quiet
 drm.debug=7 capemgr.enable_partno=BB-SPI0 root=/dev/mmcblk0p2 ro
 rootfstype=ext4 rootwait
 [0.399220] bone-capemgr bone_capemgr.8: enabled_partno part_number
 'BB-SPI0', version 'N/A'
 [0.399293] bone-capemgr bone_capemgr.8: slot #7: 'Override Board
 Name,00A0,Override Manuf,BB-SPI0'
 [0.404238] bone-capemgr bone_capemgr.8: loader: before slot-7
 BB-SPI0:00A0 (prio 0)
 [0.404261] bone-capemgr bone_capemgr.8: loader: check slot-7
 BB-SPI0:00A0 (prio 0)
 [0.404286] bone-capemgr bone_capemgr.8: loader: after slot-7
 BB-SPI0:00A0 (prio 0)
 [0.404315] bone-capemgr bone_capemgr.8: slot #7: Requesting part
 number/version based 'BB-SPI0-00A0.dtbo
 [0.404345] bone-capemgr bone_capemgr.8: slot #7: Requesting
 firmware 'BB-SPI0-00A0.dtbo' for board-name 'Override Board Name', version
 '00A0'
 [0.404401] bone-capemgr bone_capemgr.8: slot #7: dtbo
 'BB-SPI0-00A0.dtbo' loaded; converting to live tree
 [0.409351] bone-capemgr bone_capemgr.8: loader: done slot-7
 BB-SPI0:00A0 (prio 0)


 But no /dev/spi*. Am I expected to mkdev for that? What am I missing ?

>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/7e96f063-dbbd-4212-9911-855

Re: [beagleboard] Capemgr .dtbo location

[William Hermans]

Here is one such good link that even discusses using universal io.
https://briancode.wordpress.com/2015/01/06/working-with-pwm-on-a-beaglebone-black/

Just be aware that this blog post was written with kernel 3.8.x in mind.
Some file paths have changed since then but is something that can be
accounted for.

On Wed, Jul 20, 2016 at 6:57 AM, William Hermans  wrote:

> Hi Matthew,
>
> I'll propose a different approach. First, use universal IO to mux your
> pins for PWM. Then just use the PWM sysfs file system to deal with the rest.
>
> So, I have not done this personally yet, but I know it's possible, as I've
> seen blog posts on it in the past. The universal io part I would probably
> need help from Charles as I've not that done with universal io either. But
> I suspect it's very simple.
>
> If you have further question on the subject I can help guide you. As I'd
> really lie to see people getting away from Adafruits BBIO whihc seems to be
> abandon ware now days
>
> On Tue, Jul 19, 2016 at 4:51 PM,  wrote:
>
>> I'm trying to decipher how the Adafruit_BBIO Python library does PWM, in
>> preparation for supporting kernels 4.1+. The library currently loads a cape
>> file of the name "bone_pwm_P9_21" or whatever pin number. I've looked in
>> the /lib/firmware folder and there is no such .dtbo file.
>>
>> The elinux wiki page on the topic (http://elinux.org/Capemgr) says that
>> the capemgr checks in  arch/arm/boot/dts/am335x-bone-common.dtsi for a
>> corresponding .dtbo file, or /lib/firmware. My question is: how can I read
>> that .dtsi file to know where it's getting the corresponding .dtbo?
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to 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/20f03625-d376-4379-883c-712a95d1c676%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/CALHSORr_J_VHHpnu%3Df%3DcnU4tNeN4DJ1VO5oUXfBo1Arcw7Pe2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB, device tree seems to work, but no /dev/spidev?

[malkowki]

Hello William,


do you mean to configure SPI in the am335x-boneblack-overlay.dts?
an set spi module to be set as built-in in the kernel?

Can you explain a bit? Isn't clear for me.

Le mercredi 20 juillet 2016 15:45:31 UTC+2, William Hermans a écrit :
>
>
> I have also attached my Kernel Config file and the bootloog.
> Is Anyone to guide me how to solve this issue?
>
>
> I do believe that SPI has to be loaded earlier in the boot stage. I seem 
> to recall this fix for this to be loading SPI from within the main board 
> file.
>
> On Wed, Jul 20, 2016 at 5:33 AM, malkowki  > wrote:
>
>> Hi everyone,
>>
>> I am runing Linux version 4.1.21-bone-rt-r20 from Robert Nelson 
>> repository and I have the same issue.
>> The DTS seems ok but the SPI module does't appear under /dev/.
>> my uEnv.txt look like this:
>> uname_r=4.1.21-bone-rt-r20
>> optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT
>> -HDMIN
>> cape_enable=bone_capemgr.enable_partno=BB-SPI0-01
>> If I do cat $SLOTS I have :
>> 0: PF  -1 
>>  1: PF  -1 
>>  2: PF  -1 
>>  3: PF  -1 
>>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-SPI0-01
>>
>>
>> I have also attached my Kernel Config file and the bootloog.
>> Is Anyone to guide me how to solve this issue?
>>
>> thanks,
>>
>>
>> Le samedi 27 juillet 2013 23:44:28 UTC+2, Nigel Magnay a écrit :
>>>
>>>
>>> I'm trying to activate SPI on a BBB. I think it's nearly there, save for 
>>> a lack of anything in /dev, which is mysterious.
>>>
>>> I'm trying for SPI0 (I understand SPI1 requires HDMI deactivation).
>>>
>>> Brand new A5C board, uname -a is
>>> Linux beaglebone 3.8.13 #1 SMP Tue Jun 18 02:11:09 EDT 2013 armv7l 
>>> GNU/Linux
>>>
>>> Followed http://elinux.org/BeagleBone_Black_Enable_SPIDEV, save for
>>> - my /lib/firmware already had BB-SPI0, so I used that
>>> - I didn't understand "Go to My Computer>BeagleBone Getting Started>". 
>>> The mounted USB drive device is read-only. I modified the uEnv.txt in 
>>> /boot, seems to work.
>>>
>>> Slots shows it there:
>>> root@beaglebone:~# cat /sys/devices/bone_capemgr.8/slots 
>>>  0: 54:PF--- 
>>>  1: 55:PF--- 
>>>  2: 56:PF--- 
>>>  3: 57:PF--- 
>>>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>>>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>>>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI0
>>>
>>> root@beaglebone:~# cat 
>>> /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups
>>> registered pin groups:
>>>
>>> 
>>> group: pinmux_bb_spi0_pins
>>> pin 84 (44e10950)
>>> pin 85 (44e10954)
>>> pin 86 (44e10958)
>>> pin 87 (44e1095c)
>>> ...
>>>
>>> It appears in the dmesg output
>>> root@beaglebone:/dev# dmesg |grep SPI
>>> [0.00] Kernel command line: console=ttyO0,115200n8 quiet 
>>> drm.debug=7 capemgr.enable_partno=BB-SPI0 root=/dev/mmcblk0p2 ro 
>>> rootfstype=ext4 rootwait
>>> [0.399220] bone-capemgr bone_capemgr.8: enabled_partno part_number 
>>> 'BB-SPI0', version 'N/A'
>>> [0.399293] bone-capemgr bone_capemgr.8: slot #7: 'Override Board 
>>> Name,00A0,Override Manuf,BB-SPI0'
>>> [0.404238] bone-capemgr bone_capemgr.8: loader: before slot-7 
>>> BB-SPI0:00A0 (prio 0)
>>> [0.404261] bone-capemgr bone_capemgr.8: loader: check slot-7 
>>> BB-SPI0:00A0 (prio 0)
>>> [0.404286] bone-capemgr bone_capemgr.8: loader: after slot-7 
>>> BB-SPI0:00A0 (prio 0)
>>> [0.404315] bone-capemgr bone_capemgr.8: slot #7: Requesting part 
>>> number/version based 'BB-SPI0-00A0.dtbo
>>> [0.404345] bone-capemgr bone_capemgr.8: slot #7: Requesting firmware 
>>> 'BB-SPI0-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
>>> [0.404401] bone-capemgr bone_capemgr.8: slot #7: dtbo 
>>> 'BB-SPI0-00A0.dtbo' loaded; converting to live tree
>>> [0.409351] bone-capemgr bone_capemgr.8: loader: done slot-7 
>>> BB-SPI0:00A0 (prio 0)
>>>
>>>
>>> But no /dev/spi*. Am I expected to mkdev for that? What am I missing ?
>>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you 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 .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/7e96f063-dbbd-4212-9911-855a6f2ff666%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

[beagleboard] Memory crawler for eMMC partitions

[Ankur Tank]

We have BBB based custom board with 256MB RAM and 4GB eMMC running Linux 
kernel 3.12

*TL;DR*: Is there a open source application which periodically reads 
unread/rarely used partition to increase data retention? OR Is there any 
kernel service which can be configure

*Detailed query,*
We have 3 sets of partition for OS(Bootloader, kernel+dtb & RFS) eMMC. 
One of them is recovery OS. Which is rarely read( none of the time written).

Now as per eMMC manufacturerer,
"*If a byte is not read in 5 years  there is no guarantee that byte is 
valid when read after 5 years.*"
To avoid such situation we want to have a crawler application, which would 
read all the unused/unread partition may be once in a year and increase 
data retention.

I didn't find any open source application or kernel service/daemon which 
would handle that. But not sure If I am searching it correctly or not.

Meanwhile If there is no solution available for this, I am planning to do 
it in following way.

1. Setup a cron job which would trigger once in a year and run a script.
2. Script would read all the partition using dd and return.

What do you think about this approach.
Let me know if you have any suggestion/correction/pointers for me.

Thank you,
Ankur

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/6a03c437-f019-4ac0-9d87-be6a1721ca01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: TLV320AIC32X4

[Vidhya Shree]

Hii all, 
Did any one solve this error.
Even I am not getting MCLK and BCLK.

-Vidhya

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/209acda5-5ae1-410e-9737-07bfcaf42402%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Capemgr .dtbo location

[William Hermans]

Hi Matthew,

I'll propose a different approach. First, use universal IO to mux your pins
for PWM. Then just use the PWM sysfs file system to deal with the rest.

So, I have not done this personally yet, but I know it's possible, as I've
seen blog posts on it in the past. The universal io part I would probably
need help from Charles as I've not that done with universal io either. But
I suspect it's very simple.

If you have further question on the subject I can help guide you. As I'd
really lie to see people getting away from Adafruits BBIO whihc seems to be
abandon ware now days

On Tue, Jul 19, 2016 at 4:51 PM,  wrote:

> I'm trying to decipher how the Adafruit_BBIO Python library does PWM, in
> preparation for supporting kernels 4.1+. The library currently loads a cape
> file of the name "bone_pwm_P9_21" or whatever pin number. I've looked in
> the /lib/firmware folder and there is no such .dtbo file.
>
> The elinux wiki page on the topic (http://elinux.org/Capemgr) says that
> the capemgr checks in  arch/arm/boot/dts/am335x-bone-common.dtsi for a
> corresponding .dtbo file, or /lib/firmware. My question is: how can I read
> that .dtsi file to know where it's getting the corresponding .dtbo?
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to 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/20f03625-d376-4379-883c-712a95d1c676%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/CALHSORqtDb8O7KKSY2ExG5H2-uTQ536T%2Btt%2BH3zUSYjdsgZQwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: pasm to clpru porting guide for PRU

[Mark A. Yoder]

Well I couldn't find one, so I made one. 
 http://elinux.org/EBC_Exercise_30_PRU_porting_pasm_to_clpru

Please add to it.

--Mark

On Tuesday, July 19, 2016 at 2:20:47 PM UTC-4, Mark A. Yoder wrote:
>
> I'm converting some PRU assembly code from pasm to clpru and finding there 
> are some differences.  An earlier thread 
> 
>  noted 
> some differences between the two (Use LDI, not MOV for loading constants 
> for example).
>
> Has anyone made a porting guide?  For example:
>
> #define CH1BIT r30.t8 
> converts to
>.asgr30.t8, CH1BIT
>
> Thanks...
>
> --Mark
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/7b0f3c03-18db-41a5-a145-83eca39a0c23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: CAN over SPI using MCP2515 and Beaglebone

[William Hermans]

>
> Related question: I'm using the towertech CAN cape (mcp2515) and seeing a
> lot of CPU usage by the spi process. For example, just connecting one
> interface to an active bus gives 30-50% CPU usage, and that doesn't include
> actually doing anything with the data! I'm running debian with kernel
> 3.8.13-bone70 and using the driver source they provide (mcp2515). Is this a
> known issue? Has it been addressed in more recent kernels? Thanks!
>

Sounds like there is no DMA "happening" with those SPI transactions. But if
DMA is a problem, using a PRU to bitbang SPI should probably offload that
CPU.

On Wed, Jul 20, 2016 at 2:15 AM,  wrote:

> Could you please provide us with your working device tree overlay?
>
> onsdag 17. februar 2016 15.39.41 UTC+1 skrev paulda...@gmail.com følgende:
>>
>> Related question: I'm using the towertech CAN cape (mcp2515) and seeing a
>> lot of CPU usage by the spi process. For example, just connecting one
>> interface to an active bus gives 30-50% CPU usage, and that doesn't include
>> actually doing anything with the data! I'm running debian with kernel
>> 3.8.13-bone70 and using the driver source they provide (mcp2515). Is this a
>> known issue? Has it been addressed in more recent kernels? 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/40daf875-4032-4506-bebb-450212f58f01%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/CALHSORpL_Z5wqB0j0UyJTOaXGXWU4%3DNYmGYhqwE5K4tTtgqGVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB, device tree seems to work, but no /dev/spidev?

[William Hermans]

I have also attached my Kernel Config file and the bootloog.
Is Anyone to guide me how to solve this issue?


I do believe that SPI has to be loaded earlier in the boot stage. I seem to
recall this fix for this to be loading SPI from within the main board file.

On Wed, Jul 20, 2016 at 5:33 AM, malkowki  wrote:

> Hi everyone,
>
> I am runing Linux version 4.1.21-bone-rt-r20 from Robert Nelson repository
> and I have the same issue.
> The DTS seems ok but the SPI module does't appear under /dev/.
> my uEnv.txt look like this:
> uname_r=4.1.21-bone-rt-r20
> optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-
> HDMIN
> cape_enable=bone_capemgr.enable_partno=BB-SPI0-01
> If I do cat $SLOTS I have :
> 0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-SPI0-01
>
>
> I have also attached my Kernel Config file and the bootloog.
> Is Anyone to guide me how to solve this issue?
>
> thanks,
>
>
> Le samedi 27 juillet 2013 23:44:28 UTC+2, Nigel Magnay a écrit :
>>
>>
>> I'm trying to activate SPI on a BBB. I think it's nearly there, save for
>> a lack of anything in /dev, which is mysterious.
>>
>> I'm trying for SPI0 (I understand SPI1 requires HDMI deactivation).
>>
>> Brand new A5C board, uname -a is
>> Linux beaglebone 3.8.13 #1 SMP Tue Jun 18 02:11:09 EDT 2013 armv7l
>> GNU/Linux
>>
>> Followed http://elinux.org/BeagleBone_Black_Enable_SPIDEV, save for
>> - my /lib/firmware already had BB-SPI0, so I used that
>> - I didn't understand "Go to My Computer>BeagleBone Getting Started>".
>> The mounted USB drive device is read-only. I modified the uEnv.txt in
>> /boot, seems to work.
>>
>> Slots shows it there:
>> root@beaglebone:~# cat /sys/devices/bone_capemgr.8/slots
>>  0: 54:PF---
>>  1: 55:PF---
>>  2: 56:PF---
>>  3: 57:PF---
>>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI0
>>
>> root@beaglebone:~# cat
>> /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups
>> registered pin groups:
>>
>> 
>> group: pinmux_bb_spi0_pins
>> pin 84 (44e10950)
>> pin 85 (44e10954)
>> pin 86 (44e10958)
>> pin 87 (44e1095c)
>> ...
>>
>> It appears in the dmesg output
>> root@beaglebone:/dev# dmesg |grep SPI
>> [0.00] Kernel command line: console=ttyO0,115200n8 quiet
>> drm.debug=7 capemgr.enable_partno=BB-SPI0 root=/dev/mmcblk0p2 ro
>> rootfstype=ext4 rootwait
>> [0.399220] bone-capemgr bone_capemgr.8: enabled_partno part_number
>> 'BB-SPI0', version 'N/A'
>> [0.399293] bone-capemgr bone_capemgr.8: slot #7: 'Override Board
>> Name,00A0,Override Manuf,BB-SPI0'
>> [0.404238] bone-capemgr bone_capemgr.8: loader: before slot-7
>> BB-SPI0:00A0 (prio 0)
>> [0.404261] bone-capemgr bone_capemgr.8: loader: check slot-7
>> BB-SPI0:00A0 (prio 0)
>> [0.404286] bone-capemgr bone_capemgr.8: loader: after slot-7
>> BB-SPI0:00A0 (prio 0)
>> [0.404315] bone-capemgr bone_capemgr.8: slot #7: Requesting part
>> number/version based 'BB-SPI0-00A0.dtbo
>> [0.404345] bone-capemgr bone_capemgr.8: slot #7: Requesting firmware
>> 'BB-SPI0-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
>> [0.404401] bone-capemgr bone_capemgr.8: slot #7: dtbo
>> 'BB-SPI0-00A0.dtbo' loaded; converting to live tree
>> [0.409351] bone-capemgr bone_capemgr.8: loader: done slot-7
>> BB-SPI0:00A0 (prio 0)
>>
>>
>> But no /dev/spi*. Am I expected to mkdev for that? What am I missing ?
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to 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/7e96f063-dbbd-4212-9911-855a6f2ff666%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/CALHSORoovf0uk%2BaJ-L16hQrSGtPQmKCDTE94JKsLu%3DnVwQspBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Using PRU Cape, TI's product for BBB

[Eshaan Ghosh]

I have recently purchased the PRU cape from TI for BBB and tried to run it 
by following the instructions given in the wiki page and hands on lab

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

http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs

but i really cannot understand how to use it. 


   1. Do i need to connect an FTDI cable? If yes, then how with the cape 
   sitting on top of it which removes access to those pins?
   2. Is RS-232 used to debug the bbb?
   3.  How do i use CCS to connect to BBB using the cape and program it 
   considering I am familiar with coding TI DSPs?

I want to access the PRU in the BBB and program using CCSv6 like it is done 
for DSPs. Thus I have purchased the cape.

Any help would be appreciated.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/4c0e34f3-1e17-465a-98f3-624247728d7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black

[Vinay Divakar]

Hi, Rudy,

Nothing much, Just hooked to my CC3200 LP.

*Will*, looking at the slots, I can say that you have loaded the spi dev 1
successfully. For your kernel version, adding * CAPE**=BB-SPI0-01 *in the
file  in "/etc/default/capemgr" is sufficient . To cross check the active
spi devices use " ls -al /dev/spidev*", it will show you which spi devices
are currently active and can be used. There nothing more to install or
load, you have one spi device now active and can use it for your
application. However, if I were you, I would first  do a loop back test on
the spi module to check if its functioning using the code in Roberts blog SPI
Test Utility Code
.
And about your last side question, I think that is the size of image that
is currently running on your BBB

On 19 July 2016 at 04:40, Will Napier  wrote:

> Thank you Vinay and Rudy for your replies. I am using the Kernel
> Version 3.8.13-bone79.
>
> I realised about the L thing after my last post - thank you Rudy, that
> is encouraging that I have successfully disabled HDMI. I have added
> the suggested line in /etc/default/capemgr
> (CAPE=ADAFRUIT-SP0). Following earlier advice the only other line I
> have in this file is:
>
> CAPE=BB-SP1-01.
>
> Is this correct for my purpose (ie simply and only to use the BBB to
> flash the Lenovo ROM)?
>
> After adding the line you suggested, I rebooted and this is what I now get
> in /sys/devices/bone_capemgr.9/slots:
>
>  0: 54:PF---
>  1: 55:PF---
>  2: 56:PF---
>  3: 57:PF---
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI1-01
>
> I am using the guide at
> https://libreboot.org/docs/install/bbb_setup.html. In "Setting up
> spidev on the BBB" it advises:
>
> Log on as root on the BBB, using either SSH or a serial console as
> defined in #bbb_access. Make sure that you have internet access on
> your BBB.
>
>
> Follow the instructions at
> http://elinux.org/BeagleBone_Black_Enable_SPIDEV#SPI0 up to (and
> excluding) the point where it tells you to modify uEnv.txt
>
>
> I did this, entering the .dtbo in the recommended location (for
> SP01). Here is my uEnv.txt:
>
> 
>
> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
>
> uname_r=3.8.13-bone79
> ##uuid=
> #dtb=
>
> ##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)
>
> ##BeagleBone Black: HDMI (Audio/Video) disabled:
> #dtb=am335x-boneblack-emmc-overlay.dtb
>
> ##BeagleBone Black: eMMC disabled:
> #dtb=am335x-boneblack-hdmi-overlay.dtb
>
> ##BeagleBone Black: HDMI Audio/eMMC disabled:
> #dtb=am335x-boneblack-nhdmi-overlay.dtb
>
> ##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
> #dtb=am335x-boneblack-overlay.dtb
>
> ##BeagleBone Black: wl1835
> #dtb=am335x-boneblack-wl1835mod.dtb
>
> ##BeagleBone Black: replicape
> am335x-boneblack-replicape.dtb
>
> ##BeagleBone Green: eMMC disabled
> #dtb=am335x-bonegreen-overlay.dtb
>
> cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd
> cape_universal=enable
>
> #In the event of edid real failures, uncomment this next line:
> #cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd
> cape_universal=enable video=HDMI-A-1:1024x768@60e
>
> ##Example v3.8.x
> #cape_disable=capemgr.disable_partno=
> #cape_enable=capemgr.enable_partno=
>
> ##Example v4.1.x
> #cape_disable=bone_capemgr.disable_partno=
> #cape_enable=bone_capemgr.enable_partno=
>
> ##Disable HDMI/eMMC (v3.8.x)
>
> #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
>
> ##Disable HDMI (v3.8.x)
> cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>
> ##Disable eMMC (v3.8.x)
> #cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G
>
> ##Audio Cape (needs HDMI Audio disabled) (v3.8.x)
> #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI
> #cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02
>
>
> ##enable Generic eMMC Flasher:
> ##make sure, these tools are installed: dosfstools rsync
> #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
>
> uuid=c3048a42-5170-419f-ae71-6f96bf7f6f11
>
> cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0
>
> optargs=quiet drm.debug=7
> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
> capemgr.enable_partno=BB-SPI1-01
>
> ===
>
>
> So my current questions are:
>
> I am not clear from the guide what SPI things to install. SP0 &
> SP1-01? or just one of them?
>
> Also should the optargs entry and the capemgr.enable_partno=BB-SP1-01
> be present in that file, or removed?
>
> Thank you Rudy for your files. I am not sure what to do with them. Given
> what I have detailed above, do I need to do anything with them?
>
> And a side-question about the slots listing at the top of this post,
> number 4.. why does it say 2

[beagleboard] Re: CAN over SPI using MCP2515 and Beaglebone

[laurits . triple]

Could you please provide us with your working device tree overlay?

onsdag 17. februar 2016 15.39.41 UTC+1 skrev paulda...@gmail.com følgende:
>
> Related question: I'm using the towertech CAN cape (mcp2515) and seeing a 
> lot of CPU usage by the spi process. For example, just connecting one 
> interface to an active bus gives 30-50% CPU usage, and that doesn't include 
> actually doing anything with the data! I'm running debian with kernel 
> 3.8.13-bone70 and using the driver source they provide (mcp2515). Is this a 
> known issue? Has it been addressed in more recent kernels? 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/40daf875-4032-4506-bebb-450212f58f01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Max14830, uart over spi, device tree overlay/kernel driver

[Laurits]

I am trying to get MAX14830 

 
to work with beaglebone black using max310x 
driver
 
over spi. With my dts, the overlay gets loaded, but i dont get any new 
devices in /dev.  With my oscilloscope i can see that nothing happens and 
that CS is low (Active low, so something is wrong). I dont understand what 
I am doing wrong. I have the chip connected to a 4Mhz external crystal.

Output from dmesg after loading manually:

[  212.403551] bone_capemgr bone_capemgr: part_number 'BB-MAX14830-01', 
version 'N/A'
[  212.411232] bone_capemgr bone_capemgr: slot #6: override
[  212.416720] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 6
[  212.423786] bone_capemgr bone_capemgr: slot #6: 'Override Board 
Name,00A0,Override Manuf,BB-MAX14830-01'
[  212.461917] bone_capemgr bone_capemgr: slot #6: dtbo 
'BB-MAX14830-01-00A0.dtbo' loaded; overlay id #0

modalias:

debian@arm:~$ cat /sys/bus/spi/devices/*/modalias
spi:max14830


DTS:

/dts-v1/;
/plugin/;


/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "BB-MAX14830-01";

/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P9.25",/* spi irq: gpio3_21 */
"P9.31",/* spi: spi1_sclk */
"P9.29",/* spi: spi1_d0 */
"P9.30",/* spi: spi1_d1 */
"P9.28",/* spi: spi1_cs0 */
/* the hardware IP uses */
"gpio3_21",
"spi1";

fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
bone_14830_spi1_pins: pinmux_bone_14830_spi1_pins {
pinctrl-single,pins = <
0x190 0x33  /* 
mcasp0_aclkx.spi1_sclk, RX_ENABLED | PULLUP | MODE3 */
0x194 0x33  /* 
mcasp0_fsx.spi1_d0, RX_ENABLED | PULLUP | MODE3 */
0x198 0x13  /* 
mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
0x19c 0x13  /* 
mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
>;
};

bone_14830_pins: pinmux_bone_14830_pins {
pinctrl-single,pins = <
0x1ac 0x37  /* 
mcasp0_ahclkx.gpio3_21, RX_ENABLED | PULLUP | MODE7 */
>;
};
};
};

fragment@1 {
  target = <&spi1>;
__overlay__ {
#address-cells = <1>;
#size-cells = <0>;
status= "okay";
pinctrl-names   = "default";
pinctrl-0   = <&bone_14830_spi1_pins>;
max14830@0 {
compatible = "maxim,max14830";
reg = <0>; /* cs0 */
mode=<0>;
spi-max-frequency=<100>;

pinctrl-names="default";
pinctrl-0 = <&bone_14830_pins>;
clocks=<&clk4m>;
clock-names="xtal";
interrupt-parent = <&gpio3>;
interrupts = <21 2>; // Edge Falling

clk4m: clk4m@10 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <400>;
};
};
};
};
};

 

 



-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/094fe073-92b6-4c8d-8f12-f353742ae717%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black

[Rudy Misek]

Hey Will!!

My responses are in green

I am not clear from the guide what SPI things to install. SP0 &
SP1-01? or just one of them?
>From your comments it looks like you just need to talk out of 1 spi so my
answers are for SPI0.

Also should the optargs entry and the capemgr.enable_partno=BB-SP1-01
be present in that file, or removed?
Replace it with BB-SPI0-01

Thank you Rudy for your files. I am not sure what to do with them. Given
what I have detailed above, do I need to do anything with them?
Put BB-SPI0-01-00A0.dtbo in /lib/firmware on your BBB

  .dts files are the pre compiled device tree files (human readable form)
  You create a .dtbo file by compiling a .dts file
  .dbto are files that the BBB will use (machine readable form)

And a side-question about the slots listing at the top of this post,
number 4.. why does it say 2Gb not 4Gb? I'm pretty sure I have the
4Gb. Is it that there are 2x2?
Not sure, as far as I can tell it doesn't affect my 4G BBB in any way

Reboot your BBB and cat the slots again you should see BB-SPI0-01 loaded
root@beaglebone:/# cd /dev
root@beaglebone:/dev# ls
Check that spidev1.0 is in there

IMPORTANT!!! Make sure that the Lenovo SPI is 3.3v and not 5v. If it's 5v
you'll probably blow those pins on your BBB.

Do you have a program that can send the data out of the SPI?


On Tue, Jul 19, 2016 at 9:40 PM, Will Napier  wrote:

> Thank you Vinay and Rudy for your replies. I am using the Kernel
> Version 3.8.13-bone79.
>
> I realised about the L thing after my last post - thank you Rudy, that
> is encouraging that I have successfully disabled HDMI. I have added
> the suggested line in /etc/default/capemgr
> (CAPE=ADAFRUIT-SP0). Following earlier advice the only other line I
> have in this file is:
>
> CAPE=BB-SP1-01.
>
> Is this correct for my purpose (ie simply and only to use the BBB to
> flash the Lenovo ROM)?
>
> After adding the line you suggested, I rebooted and this is what I now get
> in /sys/devices/bone_capemgr.9/slots:
>
>  0: 54:PF---
>  1: 55:PF---
>  2: 56:PF---
>  3: 57:PF---
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI1-01
>
> I am using the guide at
> https://libreboot.org/docs/install/bbb_setup.html. In "Setting up
> spidev on the BBB" it advises:
>
> Log on as root on the BBB, using either SSH or a serial console as
> defined in #bbb_access. Make sure that you have internet access on
> your BBB.
>
>
> Follow the instructions at
> http://elinux.org/BeagleBone_Black_Enable_SPIDEV#SPI0 up to (and
> excluding) the point where it tells you to modify uEnv.txt
>
>
> I did this, entering the .dtbo in the recommended location (for
> SP01). Here is my uEnv.txt:
>
> 
>
> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
>
> uname_r=3.8.13-bone79
> ##uuid=
> #dtb=
>
> ##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)
>
> ##BeagleBone Black: HDMI (Audio/Video) disabled:
> #dtb=am335x-boneblack-emmc-overlay.dtb
>
> ##BeagleBone Black: eMMC disabled:
> #dtb=am335x-boneblack-hdmi-overlay.dtb
>
> ##BeagleBone Black: HDMI Audio/eMMC disabled:
> #dtb=am335x-boneblack-nhdmi-overlay.dtb
>
> ##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
> #dtb=am335x-boneblack-overlay.dtb
>
> ##BeagleBone Black: wl1835
> #dtb=am335x-boneblack-wl1835mod.dtb
>
> ##BeagleBone Black: replicape
> am335x-boneblack-replicape.dtb
>
> ##BeagleBone Green: eMMC disabled
> #dtb=am335x-bonegreen-overlay.dtb
>
> cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd
> cape_universal=enable
>
> #In the event of edid real failures, uncomment this next line:
> #cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd
> cape_universal=enable video=HDMI-A-1:1024x768@60e
>
> ##Example v3.8.x
> #cape_disable=capemgr.disable_partno=
> #cape_enable=capemgr.enable_partno=
>
> ##Example v4.1.x
> #cape_disable=bone_capemgr.disable_partno=
> #cape_enable=bone_capemgr.enable_partno=
>
> ##Disable HDMI/eMMC (v3.8.x)
>
> #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
>
> ##Disable HDMI (v3.8.x)
> cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>
> ##Disable eMMC (v3.8.x)
> #cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G
>
> ##Audio Cape (needs HDMI Audio disabled) (v3.8.x)
> #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI
> #cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02
>
>
> ##enable Generic eMMC Flasher:
> ##make sure, these tools are installed: dosfstools rsync
> #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
>
> uuid=c3048a42-5170-419f-ae71-6f96bf7f6f11
>
> cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0
>
> optargs=quiet drm.debug=7
> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
> capemgr.enable_partno=BB-SPI1-01
>
> ===
>
>
> So my 

[beagleboard] Capemgr .dtbo location

[matthewwest217]

I'm trying to decipher how the Adafruit_BBIO Python library does PWM, in 
preparation for supporting kernels 4.1+. The library currently loads a cape 
file of the name "bone_pwm_P9_21" or whatever pin number. I've looked in the 
/lib/firmware folder and there is no such .dtbo file.

The elinux wiki page on the topic (http://elinux.org/Capemgr) says that the 
capemgr checks in  arch/arm/boot/dts/am335x-bone-common.dtsi for a 
corresponding .dtbo file, or /lib/firmware. My question is: how can I read that 
.dtsi file to know where it's getting the corresponding .dtbo?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/20f03625-d376-4379-883c-712a95d1c676%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel update to 4.4.15-ti-r35 failure

[Steve Osselton]

Working for me :)

Thanks.
 

> Most of the r37 builds are done, still waiting on a few "rt" builds, this 
> will work right now in wheezy/jessie/stretch/sid
>
> sudo apt-get update ; sudo apt-get install linux-image-4.4.15-ti-r37
>
> 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/d702e92d-ce18-4985-a10a-792ec554ea4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to decide min_free_kbytes size for BBB based custom board embedded Linux board

[Ankur Tank]

Thank you reply Mr.Hermans,

I totally agree with you, and me too not willing to change that settings(or 
not willing to change it without understanding how to decide its value).
However I have to fix those errors also, that's the reason I posted my 
query here.

Regards,
Ankur

On Wednesday, 20 July 2016 12:23:38 UTC+5:30, William Hermans wrote:
>
> Thank you for reply Willian Hermans,
>> I already referred links you provided below and that's the reason I 
>> turned to the forums to understand If I a doing anything wrong.
>> OR What is the right approach.
>>
>
> Ok, it has been my experience that it is best to let Linux handle such 
> things as it sees fit. Granted this is the first time I've actually seen, 
> or heard of this. Which tells me that again, this is something best left to 
> Linux to work out.
>
> I did years ago attempt to manually manage something similar ( in relation 
> to GbE and frame sizes etc ) in an attempt to get better performance from 
> my network adapters . . . and it did not end well. As I ended up making 
> things much worse than what Linux was doing automatically. This option 
> looks very similar in that you can easily end up making things much worse 
> than they already are.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/ee6c9f98-5f67-44f5-b05b-00c23ce1cc26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: UART4 read in pthread not working

[Regina Choi]

Hi Karl, 

Thanks for suggestion. 

My problem in the code seems to be more specific to pthread, because if I 
have the read( )  in a while loop, then the UART receive is running 
normally. Data arrived at the receive buffer are able to be pick up. 
However, the problem begin when I create UART Rx thread that just 
continuously reading the UART buffer. 



Regina


 

On Wednesday, July 20, 2016 at 3:21:44 PM UTC+8, Karl Karpfen wrote:
>
> Serial interface initialisation on Linux systems is a mess and it is easy 
> to forget something. That's why I would recommend to use a library which 
> does all the work for you like liboapc from 
> https://sourceforge.net/p/oapc/code/ci/master/tree/liboapc/
>
> Am Mittwoch, 20. Juli 2016 08:56:50 UTC+2 schrieb Regina Choi:
>>
>>
>> Hi, 
>>
>> I have programmed (in C) UART4 read in thread with blocking read, the 
>> code as below: I confirmed that the UART receive port does have data 
>> through oscilloscope, but somehow there is no data in read( ), the return 
>> count always zero ?  
>>
>> The strange thing is if minicom is open on the Uart4, then the read( ) in 
>> receive thread started to run as normal.  However, the regular file write 
>> become weird.  The string won't be able to be written into file ?! 
>>
>> Btw, my BBB version is 3.8.13-bone47
>>
>>
>> #include
>> #include// required for fopen, exit()
>> #include
>> #include
>> //#include
>> #include
>> #include
>> #include "readerComm.h"
>>
>>
>> pthread_t uartRxT , uartTxT;
>> int file, file2;
>>
>> int main (int argc, char* argv[])
>> {
>> int count;
>>  
>> pthread_attr_t attr;
>> void *status;
>> FILE *fdata;
>>
>>
>> if(argc != 2)
>> {
>>
>> printf("Invalid number of arguments, exiting!");
>> return -2;
>>
>> }
>>
>> if((file = open("/dev/ttyO4", O_RDWR | O_NOCTTY | O_NDELAY ))< 0)
>> {
>> perror("UART: Failed to open the file");
>> return -1;
>> }
>>
>> fcntl(file, F_SETFL, 0); // blocking read
>> struct termios options; //oriopt
>> tcgetattr(file, &options);
>> options.c_cflag = B9600 | CS8 | CREAD | CLOCAL;
>> options.c_iflag = IGNPAR | ICRNL;
>>
>> options.c_iflag &= ~IGNBRK;
>> options.c_iflag &= ~(IXON | IXOFF | IXANY); // shut off xon/xoff ctrl
>>
>> options.c_cc[VMIN]  = 2;// Non Canonical input mode (as we didnt 
>> set ICANON for c_lflag)
>> options.c_cc[VTIME] = 10;// 1 sec timeout
>>
>>
>> tcflush(file, TCIFLUSH);
>>
>> tcsetattr(file, TCSANOW, &options);
>>
>>
>> unsigned char cmd[] = {0x11, 0x00, 0x32};//"Tx From Beaglebone ";
>>
>> if ((count = write(file, (char*)cmd, 3))<0){
>>   perror("Failed to write to the output\n");
>>   return -1;
>>  }else{
>>  printf("Byte sent: %d \n", count);
>>  }
>>
>> fdata = fopen("capture.dat", "w");
>> if (fdata == NULL) {
>> printf("I couldn't open capture.dat for writing.\n");
>> exit(0);
>> }
>>
>> // save in file ( cannot print to file ??)
>> fprintf(fdata, "%s", "test");
>> perror("UART: Test comment");
>>
>>
>> pthread_attr_init(&attr);
>> pthread_attr_setdetachstate(&
>> attr, PTHREAD_CREATE_JOINABLE);
>>
>> // Create UArt Tx thread
>> if(pthread_create(&uartTxT, &attr, &uartTxWait, NULL)){
>> perror("GPIO: Failed to create the tx thread");
>>
>> return -1;
>> }
>>
>> // Create Uart Rx thread
>> if(pthread_create(&uartRxT, &attr, &uartRxWait, NULL)){
>> perror("GPIO: Failed to create the rx thread");
>>
>> return -1;
>> }
>>
>> pthread_attr_destroy(&attr);
>> pthread_join(uartRxT,&status);
>> pthread_join(uartTxT,&status);
>>
>> close(file);// close first file descriptor
>>
>> // capture.dat file close
>> fclose(fdata);
>>
>> return 0;
>>
>> }
>>
>> // UART RX thread
>> void* uartRxWait(void *param){
>>
>> unsigned char receive[100];
>> int count, n;
>> fd_set input;
>> struct timeval timeout;
>>
>> //initialize input set
>> FD_ZERO(&input);
>> FD_SET(file, &input);
>>
>> timeout.tv_sec=0;
>> timeout.tv_usec=0;
>>
>> while(1){
>>
>> if ((count = read(file, (void *)receive, 100))<0)
>> {
>> perror("Failed to read from input \n");
>> printf("count = %d\n", count);
>> }else{
>>
>> if(receive[2]==0x32){
>> printf("Header received \n"); 
>> }
>> printf("Byte received [%d] \n", count);
>> printf("Value of Pi = 0x%.2x\n", receive[0]);
>>
>>   }
>>  
>> }
>>
>> pthread_exit(0);
>> }
>>
>>
>> void* uartTxWait(void *param){
>>
>> usleep(100);
>> pthread_exit(0);
>> }
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 

Re: [beagleboard] Edimax WiFi Turns Off Automatically

[Tsan-Ming Chou]

I used Edimax USB Wi-Fi adapter on Raspberry Pi. I would suggest you to
refer to this

article.
This scheme is good except you need another device to behave as a
controller.

Tsan-Ming

2016-07-20 15:16 GMT+08:00 Ajit Wadekar :

> Hello,
>
> I am using Edimax WiFi Adapter. Here i have done all the configuration as
> given in the following link by adafruit for beagle bone black:
>
>
> https://learn.adafruit.com/setting-up-wifi-with-beaglebone-black/configuration
>
> Now this script and services run fine on boot up and regular operations.
>
> But most of the time I have a problem where the working WiFi of Beagle
> Bone Black goes down and Edimax Adapter turns off. Now in order to get WiFi
> up I have to use following commands to "Ifdown wlan0" and "Ifup wlan0" by
> connecting BBB to USB or restart the BBB.
>
> I need a very reliable WiFi connection which should never turn off. It
> should be able to connect router automatically even if the router goes down
> and comes up after some time.
>
> Here i have disabled HDMI and I am using 5V,2A Adapter.
>
> Regards,
> Ajit Wadekar
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to 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/a5bb7cd2-3555-4b25-9e9c-013a1d83c7af%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/CAAj9vABxUfk%2Bq4w-J06V266%3DMnDs7WyxfsfbY-BkDOOd%2B%2BPWBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Edimax WiFi Turns Off Automatically

[Ajit Wadekar]

Thanks sunny. Will test that out, but is there any other solution other 
than external hub?

On Wednesday, 20 July 2016 12:49:57 UTC+5:30, Siji Sunny wrote:
>
>
> Hello,
>>
>> I am using Edimax WiFi Adapter. Here i have done all the configuration as 
>> given in the following link by adafruit for beagle bone black:
>>
>>
>> https://learn.adafruit.com/setting-up-wifi-with-beaglebone-black/configuration
>>
>> Now this script and services run fine on boot up and regular operations. 
>>
>> But most of the time I have a problem where the working WiFi of Beagle 
>> Bone Black goes down and Edimax Adapter turns off. Now in order to get WiFi 
>> up I have to use following commands to "Ifdown wlan0" and "Ifup wlan0" by 
>> connecting BBB to USB or restart the BBB.
>>
>> I need a very reliable WiFi connection which should never turn off. It 
>> should be able to connect router automatically even if the router goes down 
>> and comes up after some time.
>>
>> Here i have disabled HDMI and I am using 5V,2A Adapter.
>>
>
> Something similar we faced earlier with RaspberryPI, and identified that 
> USB port is not providing enough power to run the WiFi adapter, solved by 
> using external USB Hub, which been powered separately.
>
>  
>
>>
>> Regards,
>> Ajit Wadekar
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you 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 .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/a5bb7cd2-3555-4b25-9e9c-013a1d83c7af%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Siji Sunny
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/9f1852a7-b62a-4bc8-b20c-1c7e8d64c891%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: UART4 read in pthread not working

[Karl Karpfen]

Serial interface initialisation on Linux systems is a mess and it is easy 
to forget something. That's why I would recommend to use a library which 
does all the work for you like liboapc 
from https://sourceforge.net/p/oapc/code/ci/master/tree/liboapc/

Am Mittwoch, 20. Juli 2016 08:56:50 UTC+2 schrieb Regina Choi:
>
>
> Hi, 
>
> I have programmed (in C) UART4 read in thread with blocking read, the code 
> as below: I confirmed that the UART receive port does have data through 
> oscilloscope, but somehow there is no data in read( ), the return count 
> always zero ?  
>
> The strange thing is if minicom is open on the Uart4, then the read( ) in 
> receive thread started to run as normal.  However, the regular file write 
> become weird.  The string won't be able to be written into file ?! 
>
> Btw, my BBB version is 3.8.13-bone47
>
>
> #include
> #include// required for fopen, exit()
> #include
> #include
> //#include
> #include
> #include
> #include "readerComm.h"
>
>
> pthread_t uartRxT , uartTxT;
> int file, file2;
>
> int main (int argc, char* argv[])
> {
> int count;
>  
> pthread_attr_t attr;
> void *status;
> FILE *fdata;
>
>
> if(argc != 2)
> {
>
> printf("Invalid number of arguments, exiting!");
> return -2;
>
> }
>
> if((file = open("/dev/ttyO4", O_RDWR | O_NOCTTY | O_NDELAY ))< 0)
> {
> perror("UART: Failed to open the file");
> return -1;
> }
>
> fcntl(file, F_SETFL, 0); // blocking read
> struct termios options; //oriopt
> tcgetattr(file, &options);
> options.c_cflag = B9600 | CS8 | CREAD | CLOCAL;
> options.c_iflag = IGNPAR | ICRNL;
>
> options.c_iflag &= ~IGNBRK;
> options.c_iflag &= ~(IXON | IXOFF | IXANY); // shut off xon/xoff ctrl
>
> options.c_cc[VMIN]  = 2;// Non Canonical input mode (as we didnt 
> set ICANON for c_lflag)
> options.c_cc[VTIME] = 10;// 1 sec timeout
>
>
> tcflush(file, TCIFLUSH);
>
> tcsetattr(file, TCSANOW, &options);
>
>
> unsigned char cmd[] = {0x11, 0x00, 0x32};//"Tx From Beaglebone ";
>
> if ((count = write(file, (char*)cmd, 3))<0){
>   perror("Failed to write to the output\n");
>   return -1;
>  }else{
>  printf("Byte sent: %d \n", count);
>  }
>
> fdata = fopen("capture.dat", "w");
> if (fdata == NULL) {
> printf("I couldn't open capture.dat for writing.\n");
> exit(0);
> }
>
> // save in file ( cannot print to file ??)
> fprintf(fdata, "%s", "test");
> perror("UART: Test comment");
>
>
> pthread_attr_init(&attr);
> pthread_attr_setdetachstate(&
> attr, PTHREAD_CREATE_JOINABLE);
>
> // Create UArt Tx thread
> if(pthread_create(&uartTxT, &attr, &uartTxWait, NULL)){
> perror("GPIO: Failed to create the tx thread");
>
> return -1;
> }
>
> // Create Uart Rx thread
> if(pthread_create(&uartRxT, &attr, &uartRxWait, NULL)){
> perror("GPIO: Failed to create the rx thread");
>
> return -1;
> }
>
> pthread_attr_destroy(&attr);
> pthread_join(uartRxT,&status);
> pthread_join(uartTxT,&status);
>
> close(file);// close first file descriptor
>
> // capture.dat file close
> fclose(fdata);
>
> return 0;
>
> }
>
> // UART RX thread
> void* uartRxWait(void *param){
>
> unsigned char receive[100];
> int count, n;
> fd_set input;
> struct timeval timeout;
>
> //initialize input set
> FD_ZERO(&input);
> FD_SET(file, &input);
>
> timeout.tv_sec=0;
> timeout.tv_usec=0;
>
> while(1){
>
> if ((count = read(file, (void *)receive, 100))<0)
> {
> perror("Failed to read from input \n");
> printf("count = %d\n", count);
> }else{
>
> if(receive[2]==0x32){
> printf("Header received \n"); 
> }
> printf("Byte received [%d] \n", count);
> printf("Value of Pi = 0x%.2x\n", receive[0]);
>
>   }
>  
> }
>
> pthread_exit(0);
> }
>
>
> void* uartTxWait(void *param){
>
> usleep(100);
> pthread_exit(0);
> }
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/2280948f-e89f-4c51-90a8-71386ebcd1d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Edimax WiFi Turns Off Automatically

[Siji Sunny]

> Hello,
>
> I am using Edimax WiFi Adapter. Here i have done all the configuration as
> given in the following link by adafruit for beagle bone black:
>
>
> https://learn.adafruit.com/setting-up-wifi-with-beaglebone-black/configuration
>
> Now this script and services run fine on boot up and regular operations.
>
> But most of the time I have a problem where the working WiFi of Beagle
> Bone Black goes down and Edimax Adapter turns off. Now in order to get WiFi
> up I have to use following commands to "Ifdown wlan0" and "Ifup wlan0" by
> connecting BBB to USB or restart the BBB.
>
> I need a very reliable WiFi connection which should never turn off. It
> should be able to connect router automatically even if the router goes down
> and comes up after some time.
>
> Here i have disabled HDMI and I am using 5V,2A Adapter.
>

Something similar we faced earlier with RaspberryPI, and identified that
USB port is not providing enough power to run the WiFi adapter, solved by
using external USB Hub, which been powered separately.



>
> Regards,
> Ajit Wadekar
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to 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/a5bb7cd2-3555-4b25-9e9c-013a1d83c7af%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Siji Sunny

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/CADtvZWC2vvCXARf%3D4FW7cpEZM3KYKG0C1zRiKVnvzM2fOZq31w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Edimax WiFi Turns Off Automatically

[Ajit Wadekar]

Hello,

I am using Edimax WiFi Adapter. Here i have done all the configuration as 
given in the following link by adafruit for beagle bone black:

https://learn.adafruit.com/setting-up-wifi-with-beaglebone-black/configuration

Now this script and services run fine on boot up and regular operations. 

But most of the time I have a problem where the working WiFi of Beagle Bone 
Black goes down and Edimax Adapter turns off. Now in order to get WiFi up I 
have to use following commands to "Ifdown wlan0" and "Ifup wlan0" by 
connecting BBB to USB or restart the BBB.

I need a very reliable WiFi connection which should never turn off. It 
should be able to connect router automatically even if the router goes down 
and comes up after some time.

Here i have disabled HDMI and I am using 5V,2A Adapter.

Regards,
Ajit Wadekar

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/a5bb7cd2-3555-4b25-9e9c-013a1d83c7af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.