[beagleboard] Re: When is Ubuntu 20.04 Console Image Release Planned?

[A Metelko]

I should add ...  I don’t need an exact date.  As an engineer doing 
integration myself, I fully will understand if delays happen.  I just need 
to general timeframe (i.e. a target month or quarter).  We have features we 
want to add to our system that point to the need to upgrade to Ubuntu 20.04.

On Monday, October 12, 2020 at 4:18:00 PM UTC-5 mary.m...@gmail.com wrote:

> Looking at the https://github.com/RobertCNelson/omap-image-builder 
> activity, I see that there have been changes to add the ability to release 
> a 20.04.1 version of the "console-armhf" image.  The last update was in 
> April (ubuntu-18.04.4-console-armhf-2020-04-09.tar.xz 
> ).
>   
> I was wondering when a new release might be expected which will have a 
> released version for "ubuntu-20.04.1-console-armhf-2020-xx-xx.tar.xz"?  
> What are the issues that are still in progress?  I particularly interested 
> in the 5.4.66-ti-rt-r18 kernel release 
> 
> .
>
> Thanks in advance for any information on this activity.
>
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/264aca8f-0557-41ab-8bc5-538e35ee5f86n%40googlegroups.com.

[beagleboard] Re: Online training update

[set_]

Hello Again,

If someone, maybe you and/or other people too, wants to set up a fund for 
teaching circumstances with a nice platform for learning in real-time w/ 
etiquette, sign me up. I can pay $5.00 on specific sessions if others are 
involved.

...

It may not sound like much to finance the beagleboard.org foundation but if 
there are more people than just me signed up, $5.00 multiplied by (n) 
persons may help the foundation some. So, GSOC for 2021 happens and so 
others like myself can learn more about the works dedicated to BBB.io 
boards outside of reading may both prove more valuable than just throwing 
source at people (maybe). Just maybe. And, who knows? Maybe a tidbit of an 
inkling of info. of what is to come may persuade onlookers. For instance, 
maybe a couple of "What is Next" ideas would be worthwhile. 

Seth

On Thursday, October 15, 2020 at 2:43:33 PM UTC-5, set_ wrote:
>
> Hello,
>
> I saw the resolution and I would like in on learning objectives. The books 
> seem to have ceased in the BeagleBoard.org world, i.e. for obvious reasons. 
> Once something is put on paper, someone else has already changed something 
> else to the point where what is on paper is "old" news.
>
> Anyway, I want in too!
>
> Seth
>
> On Thursday, March 19, 2020 at 2:40:46 PM UTC-5, Jason Kridner wrote:
>>
>> https://beagleboard.org/blog/2020-03-18-online-training-update
>>
>> As mentioned in my New Year’s resolution 
>> , 
>> I’m going to launch some online training for embedded Linux development.
>>
>>
>> Yes, this training will happen. Interest continues to build. At this 
>> point, I’m delaying until the first of our triannual image releases 
>> 
>>  comes 
>> out next month to align with the latest software release. I’m also fixing 
>> an issue with the TechLab boards being improperly classified for export, 
>> preventing shipments to some countries. I’m also working on getting a few 
>> more of these into distribution as I expect we’ll run out with everyone 
>> looking to do this training.
>>
>>
>> To make sure you don’t miss out, subscribe to the blog at 
>> beagleboard.org/blog.
>>
>>
>> Here’s a bit more on the format:
>> • It will be done as YouTube “premieres” 
>>  of 30 minute videos with live chat
>> • There will be an extra 30 minutes of live chat on beagleboard.org/chat
>> • On-going discussion on beagleboard.org/discuss under “Training”
>> • First session built on PocketBeagle TechLab 
>>  materials
>> from e-ALE workshops
>> [image: ➡] Kits will be available via a Digi-Key shopping cart 
>> 
>> PocketBeagle® and TechLab Workshop Setup
>>
>> Feel free to get kits now, but I’ll try to include time to acquire kits 
>> after the first video. The first video will be more of an introduction to 
>> the concept and BeagleBoard.org. I’ll announce here on this blog when the 
>> first video is scheduled to premiere and will give at least a week’s notice.
>>
>>
>> As of now, some topics to be covered include:
>> [image: ➡] Use Linux command-line and explore file system
>> [image: ➡] Program basic Linux interfaces in JavaScript/Node-RED and 
>> Python
>> [image: ➡] Program PRUs using C
>> [image: ➡] Start writing kernel drivers in C
>>
>>
On Thursday, October 15, 2020 at 2:43:33 PM UTC-5, set_ wrote:
>
> Hello,
>
> I saw the resolution and I would like in on learning objectives. The books 
> seem to have ceased in the BeagleBoard.org world, i.e. for obvious reasons. 
> Once something is put on paper, someone else has already changed something 
> else to the point where what is on paper is "old" news.
>
> Anyway, I want in too!
>
> Seth
>
> On Thursday, March 19, 2020 at 2:40:46 PM UTC-5, Jason Kridner wrote:
>>
>> https://beagleboard.org/blog/2020-03-18-online-training-update
>>
>> As mentioned in my New Year’s resolution 
>> , 
>> I’m going to launch some online training for embedded Linux development.
>>
>>
>> Yes, this training will happen. Interest continues to build. At this 
>> point, I’m delaying until the first of our triannual image releases 
>> 
>>  comes 
>> out next month to align with the latest software release. I’m also fixing 
>> an issue with the TechLab boards being improperly classified for export, 
>> preventing shipments to some countries. I’m also working on getting a few 
>> more of these into distribution as I expect we’ll run out with everyone 
>> looking to do this training.
>>
>>
>> To make sure you don’t miss out, subscribe to the blog at 
>> beagleboard.org/blog.
>>
>>
>> Here’s a bit more on the format:
>> • It will be done as YouTube “premieres” 
>> 

[beagleboard] Re: Online training update

[Seth Nowlin]

Hello,

I saw the resolution and I would like in on learning objectives. The books 
seem to have ceased in the BeagleBoard.org world, i.e. for obvious reasons. 
Once something is put on paper, someone else has already changed something 
else to the point where what is on paper is "old" news.

Anyway, I want in too!

Seth

On Thursday, March 19, 2020 at 2:40:46 PM UTC-5, Jason Kridner wrote:
>
> https://beagleboard.org/blog/2020-03-18-online-training-update
>
> As mentioned in my New Year’s resolution 
> , 
> I’m going to launch some online training for embedded Linux development.
>
>
> Yes, this training will happen. Interest continues to build. At this 
> point, I’m delaying until the first of our triannual image releases 
> 
>  comes 
> out next month to align with the latest software release. I’m also fixing 
> an issue with the TechLab boards being improperly classified for export, 
> preventing shipments to some countries. I’m also working on getting a few 
> more of these into distribution as I expect we’ll run out with everyone 
> looking to do this training.
>
>
> To make sure you don’t miss out, subscribe to the blog at 
> beagleboard.org/blog.
>
>
> Here’s a bit more on the format:
> • It will be done as YouTube “premieres” 
>  of 30 minute videos with live chat
> • There will be an extra 30 minutes of live chat on beagleboard.org/chat
> • On-going discussion on beagleboard.org/discuss under “Training”
> • First session built on PocketBeagle TechLab 
>  materials
> from e-ALE workshops
> [image: ➡] Kits will be available via a Digi-Key shopping cart 
> 
> PocketBeagle® and TechLab Workshop Setup
>
> Feel free to get kits now, but I’ll try to include time to acquire kits 
> after the first video. The first video will be more of an introduction to 
> the concept and BeagleBoard.org. I’ll announce here on this blog when the 
> first video is scheduled to premiere and will give at least a week’s notice.
>
>
> As of now, some topics to be covered include:
> [image: ➡] Use Linux command-line and explore file system
> [image: ➡] Program basic Linux interfaces in JavaScript/Node-RED and 
> Python
> [image: ➡] Program PRUs using C
> [image: ➡] Start writing kernel drivers in C
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/522ed974-8b9b-4977-b588-9c24a7247713o%40googlegroups.com.

[beagleboard] Attempting to change boot params on Debian 4.19.94 Buster IoT image.

[mcp]

Just noticed that others have viewed my question in the BB Black section.  
I might have posted in the wrong
area of the forum.  Re posting to hopefully get a few U-Boot experienced 
eyes on this -- not trying to flood the forum.
Let me know if there's a cleaner/preferred way to do this. Thanks.

On Monday, October 12, 2020 at 4:25:44 PM UTC-7, cpmcp...@rtisys.org wrote:

Just getting back into BBB world - working on a PRU project.  I need to 
reserve some DDR memory for use as an
extended PRU data buffer and have decided, while experimenting, to add " 
mem=384M memmap=128M$384M" to the
kernel command line.  I managed to get that working on an older Debian 
image, but have updated all my boards to
latest (probably latest -1 by now!) Debian IoT flasher.  I'm running on the 
BBB flash mem not the uSD card.

I have read that Debian things have changed a bit and everything is now 
contained in a single partition.  The only
uEnv.txt file I can find is in /boot.  I have changed the line that 
includes console speed params to include the above 
parameters but, they do not show up in the /proc/cmdline display.  Similar 
changes on older kernels have worked - or
at least show up in the /proc/cmdline display after booting.  I have also 
renamed the bbb-uEnv.txt file in /  to
uEnv.txt and edited it as well.  But, no joy there either.

Most of the info I find after searching is from 2011 - 2014, so not sure if 
its of any relevance.  I've read through and 
and followed instructions found in my new copy of "Exploring Beaglebone" 
(ver. 2, and, by the way, a great book 
worth having!).  Have a better understanding of the whole U-Boot process; 
but still not working.

Could someone please
shed some light on the current (i.e. 2020) procedure for adding custom 
kernel parms to the Debian boot?  I'm trying to
stay as close to the off-the-shelf BBB releases as possible, but just can't 
seem to find the path down to the right place
in the boot process to get these additional parms in place.  Any help would 
be appreciated.

Cheers,
Chuck

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/bfafcaa3-1533-44e8-8dc1-c7f23c95d3d4o%40googlegroups.com.

[beagleboard] Re: Guide on configuring pins

[TJF]

Yes, kernel pinmuxing is terrible. And when you use the config-pin tool in 
a bad manner on pins P9_41/P9_42 it can damage your CPU.

That's why I developed libpruio. It can do all pin-muxing from user space 
in a safe manner (headers P8, P9, JT and also SD-Card-slot or user LEDS). 
Ie you can switch a PIN from input to output while your program is running. 
And your software is working on all kernel versions from 3.8 to the current 
5.x without any adaption.

Find details at

http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/index.html

Regards

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/383087f8-294b-4c1c-acef-f28b2a39fd0eo%40googlegroups.com.

Re: [beagleboard] Re: Boot time optimization

[TJF]

-bone- kernels are booting faster than the -ti- flavors.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/b860d2e2-a387-4c82-9a72-4463543b316ao%40googlegroups.com.

Re: [beagleboard] BBB - using "special" P9.41 as GPIO

[dee v]

That would be an option where it not for the fact that I have a board that 
has a peripheral connected to P9_41, so I really need to get that pin to 
toggle...

Op donderdag 15 oktober 2020 om 14:39:28 UTC+2 schreef evilw...@gmail.com:

> If you really need extra io pins, use a I2C io expander. much easier than
> beating yourself up.
>
>
> On 10/15/2020 2:08 AM, deev...@gmail.com wrote:
>
> I don't like to admit defeat, but this time I give up...
>
> I am trying to use the BeagleBone Black P9_41 pin as a GPIO 
> (GPIO3_20/GPIO0_20). According to the BeagleBone Black System reference 
> manual two different balls are connected to that pin:
> "# Both of these signals connect to pin 41 of P11. Resistors are installed 
> that allow for the GPIO3_20 connection to be removed by removing R221. The 
> intent is to allow the SW to use either of these signals, one or the other, 
> on pin 41. SW should set the unused pin in input mode when using the other 
> pin. This allowed us to get an extra signal out to the expansion header. "
>
> I realize this complicates matters, but I have no choice but to use this 
> exact pin. I am using other pins succesfully. Additionally, I am using 
> overlays to use ttyO1, ttyO2, ttyO4 and ttyO5. 
> The R221 designator is not correct, so I downloaded the boardfiles and 
> looked at them in Orcad. I tryed desoldered R19 (which disconnects CLKOUT2) 
> as well as R20 (one at a time), but that didn't help. I resoldered both 0R 
> bridges.
>
> I have created a DTS which compiles succesfully with 
>
> After doing 
> echo 116 > /sys/class/gpio/unexport
> echo 116 > /sys/class/gpio/export
> echo out > /sys/class/gpio/gpio116/direction
>
>
>
>
> I can toggle the pin in software:
> echo 1 > /sys/class/gpio/gpio116/value
>
>
> and
> cat /sys/class/gpio/gpio116/value
>
>
> returns 1 or 0 depending on what value I set it to
>
> However, the voltage of the pin stays at 3.3V.
> I've also tried to init GPIO20 as well as 116, set them both to low or set 
> one to input and the other output/high. No luck.
>
> I guess I need more than a simple overlay/pinmux config/... to set the pin 
> configuration (and disable CLKOUT2)
>
> There is lots of information on how to create and use them, but no clear 
> explanation on how to do this with current kernels. I've gone through Derek 
> Malloys book, but some of his methods seems deprecated with newer kernels.
>
> My (compiling but not functioning) p941test-00A0.dts (based on the TI dts 
> example files):
>
> /*
>  * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License version 2 as
>  * published by the Free Software Foundation.
>  */
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
>
> /* identification */
> part-number = "pinctrl-test-0";
>
> fragment@0 {
> target = <_pinmux>;
> __overlay__ {
> pinctrl_test: pinctrl_test_0_pins {
> pinctrl-single,pins = <
> 0x1b4 0x0F/* P9_41 muxRegOffset, OUTPUT | MODE0 | 
> Pull down enabled */
> 0x1a8 0x07/* P9_42 muxRegOffset, OUTPUT | MODE0 */
>
> >;
> };
> };
> };
>
> fragment@1 {
> target = <>;
> __overlay__ {
> test_helper: helper {
> compatible = "bone-pinmux-helper";
> pinctrl-names = "default";
> pinctrl-0 = <_test>;
> status = "okay";
> };
> };
> };
> };
>
>
> compiling this with 
> sudo make -d src/arm/p941test-00A0.dtbo
>
> seems to do what it should.
> After using ./install.sh to put it everything in the correct directory, I 
> set 
> uboot_overlay_addr7=/lib/firmware/p941test-00A0.dtbo in /boot/uEnv.txt
>
>
>
> I'm quite confident my dts is the issue, but no idea what's wrong (and it 
> does compile).
>
>
> Some additional info:
>
> /opt/scripts/tools/version.sh returns:
> git:/opt/scripts/:[1aa73453b2c980b75e31e83dab7dd8b6696f10c7]
> eeprom:[A335BNLTEIA04718BBBK00F9]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2018.09-2-
> gd5b4c4b656]:[location: dd MBR]
> kernel:[4.14.71-ti-r80]
> nodejs:[v6.14.4]
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-UART1-
> 00A0.dtbo]
> uboot_overlay_options:[uboot_overlay_addr5=/lib/firmware/BB-UART2-
> 00A0.dtbo]
> uboot_overlay_options:[uboot_overlay_addr6=/lib/firmware/BB-UART4-
> 00A0.dtbo]
> uboot_overlay_options:[uboot_overlay_addr7=/lib/firmware/BB-UART5-
> 00A0.dtbo]
> uboot_overlay_options:[disable_uboot_overlay_video=1]
> uboot_overlay_options:[disable_uboot_overlay_audio=1]
> uboot_overlay_options:[disable_uboot_overlay_wireless=1]
> 

Re: [beagleboard] Failing Ethernet Transcievers (help)

[Jeffrey Nichols]

Sorry for the late response. Here's the info you requested:

maintenance@beaglebone:~$ uname -r
4.4.54-ti-r93



On Tuesday, September 29, 2020 at 9:32:20 AM UTC-4 RobertCNelson wrote:

> Oh, that looks fun, specially with no errors over dmesg..
>
> Which kernel version?
>
> uname -r ?
>
> Regards,
>
> On Tue, Sep 29, 2020 at 8:24 AM suprock tech  wrote:
> >
> > Sorry it took a few days but heres some logs.
> >
> >
> > Working beaglebone, Unit #1542:
> > dmesg output when plugging in a cable:
> > [ 74.039867] cpsw 4a10.ethernet eth0: Link is Up - 100Mbps/Full -
> > flow control off
> > [ 74.040069] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> > [ 74.162638] 8021q: 802.1Q VLAN Support v1.8
> > [ 74.162796] 8021q: adding VLAN 0 to HW filter on device eth0
> >
> > maintenance@beaglebone:~$ ifconfig
> > eth0 Link encap:Ethernet HWaddr 38:d2:69:52:69:10
> > inet addr:192.168.2.155 Bcast:192.168.2.255 Mask:255.255.255.0
> > inet6 addr: 2601:18d:8901:ec80:3ad2:69ff:fe52:6910/64
> > Scope:Global
> > inet6 addr: fe80::3ad2:69ff:fe52:6910/64 Scope:Link
> > UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
> > RX packets:34 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:1000
> > RX bytes:4103 (4.0 KiB) TX bytes:15847 (15.4 KiB)
> > Interrupt:173
> >
> > Iperf works as a server:
> > maintenance@beaglebone:~$ iperf -s
> > 
> > Server listening on TCP port 5001
> > TCP window size: 85.3 KByte (default)
> > 
> > [ 4] local 192.168.2.155 port 5001 connected with 192.168.2.188 port 
> 11268
> > [ ID] Interval Transfer Bandwidth
> > [ 4] 0.0-10.0 sec 114 MBytes 94.9 Mbits/sec
> >
> > Iperf works as a client too:
> > maintenance@beaglebone:~$ iperf -c 192.168.2.188
> > 
> > Client connecting to 192.168.2.188, TCP port 5001
> > TCP window size: 43.8 KByte (default)
> > 
> > [ 3] local 192.168.2.155 port 45668 connected with 192.168.2.188 port 
> 5001
> > [ ID] Interval Transfer Bandwidth
> > [ 3] 0.0-10.0 sec 113 MBytes 94.7 Mbits/sec
> >
> >
> >
> > Unit #5788:
> > dmesg output when plugging in a cable:
> > [ 73.783078] cpsw 4a10.ethernet eth0: Link is Up - 100Mbps/Full -
> > flow control rx/tx
> > [ 73.783175] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> > [ 73.873892] 8021q: 802.1Q VLAN Support v1.8
> > [ 73.873966] 8021q: adding VLAN 0 to HW filter on device eth0
> >
> > Despite what's shown in dmesg the beaglebone auto negotiates with the
> > switch to 100Mbps at half duplex (not full). The link lights on both
> > ends (beaglebone and switch) are on. The device cannot get an address:
> > maintenance@beaglebone:~$ ifconfig
> > eth0 Link encap:Ethernet HWaddr 04:79:b7:ac:27:ba
> > inet6 addr: fe80::679:b7ff:feac:27ba/64 Scope:Link
> > UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
> > RX packets:1 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:1000
> > RX bytes:590 (590.0 B) TX bytes:6374 (6.2 KiB)
> > Interrupt:173
> >
> >
> >
> > Unit #5104:
> > dmesg output when plugging in a cable:
> > [ 106.355039] cpsw 4a10.ethernet eth0: Link is Up - 100Mbps/Full -
> > flow control off
> > [ 106.355138] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> > [ 106.430626] 8021q: 802.1Q VLAN Support v1.8
> > [ 106.430698] 8021q: adding VLAN 0 to HW filter on device eth0
> >
> > does get an address:
> > maintenance@beaglebone:~$ ifconfig
> > eth0 Link encap:Ethernet HWaddr 04:79:b7:a3:6b:e8
> > inet addr:192.168.2.151 Bcast:192.168.2.255 Mask:255.255.255.0
> > inet6 addr: fe80::679:b7ff:fea3:6be8/64 Scope:Link
> > inet6 addr: 2601:18d:8901:ec80:679:b7ff:fea3:6be8/64 Scope:Global
> > UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
> > RX packets:36 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:87 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:1000
> > RX bytes:4151 (4.0 KiB) TX bytes:17119 (16.7 KiB)
> > Interrupt:173
> >
> > Iperf works as a server (using iperf -c 192.168.2.151 on the other end):
> > maintenance@beaglebone:~$ iperf -s
> > 
> > Server listening on TCP port 5001
> > TCP window size: 85.3 KByte (default)
> > 
> > [ 4] local 192.168.2.151 port 5001 connected with 192.168.2.188 port 
> 10788
> > [ ID] Interval Transfer Bandwidth
> > [ 4] 0.0-10.0 sec 113 MBytes 94.7 Mbits/sec
> >
> > Iperf locks up completely when the roles are reversed. I had to
> > terminate the process on the other computer, and it gave crazy results
> > on the beagle:
> > maintenance@beaglebone:~$ iperf -c 192.168.2.188
> > 

Re: [beagleboard] Re: Remote access for the beagle bone black (BBB) to modify /upgrade file from cloud server

[Tarmo]

On Thursday, October 15, 2020 at 8:43:46 AM UTC+3 Niresh wrote:

> Is there a way to access the beagle-bone using SSH or something like that 
> without registering the device to another server?
>

This is a network setup issue. Any remote access solution requires that a 
network route exist from your computer to the BBB. If you and the BBB are 
in the same local network, it's routable and you can connect to it. If the 
BBB has a public IP address (or port forwarding is set up to it), it's 
routable and you can connect to it. If the BBB is behind a NAT and no port 
forwarding is set up, it's not routable and you cannot connect to it. 

Here's where the various tunnelling and VPN solutions come in. You can 
choose one which is best for your requirements, but you cannot get remote 
access to a non-routable device without them.

I've used a simple jumpbox in the form of an SSH server where all the 
different BBB-s connect to. Each opens a remote tunnel on a specific port 
which leads back to it. Eg. port 20013 would have a tunnel to device nr 13, 
port 20014 to nr 14 etc. There's a Debian package called autossh with a 
script which maintains a persistent SSH connection to the jumpbox. This is 
a fairly simple solution to set up and use initially, but not a very good 
one - mainly because it doesn't scale beyond a few dozen devices. I'd go 
for a VPN next time. 

--
Kind regards,
Tarmo

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/43e35925-e214-450b-8f64-2b0f99b31491n%40googlegroups.com.

Re: [beagleboard] BBB - using "special" P9.41 as GPIO

[evilwulfie]

If you really need extra io pins, use a I2C io expander. much easier than
beating yourself up.

On 10/15/2020 2:08 AM, deevee...@gmail.com wrote:

I don't like to admit defeat, but this time I give up...

I am trying to use the BeagleBone Black P9_41 pin as a GPIO 
(GPIO3_20/GPIO0_20). According to the BeagleBone Black System 
reference manual two different balls are connected to that pin:
"# Both of these signals connect to pin 41 of P11. Resistors are 
installed that allow for the GPIO3_20 connection to be removed by 
removing R221. The intent is to allow the SW to use either of these 
signals, one or the other, on pin 41. SW should set the unused pin in 
input mode when using the other pin. This allowed us to get an extra 
signal out to the expansion header. "


I realize this complicates matters, but I have no choice but to use 
this exact pin. I am using other pins succesfully. Additionally, I am 
using overlays to use ttyO1, ttyO2, ttyO4 and ttyO5.
The R221 designator is not correct, so I downloaded the boardfiles and 
looked at them in Orcad. I tryed desoldered R19 (which disconnects 
CLKOUT2) as well as R20 (one at a time), but that didn't help. I 
resoldered both 0R bridges.


I have created a DTS which compiles succesfully with

After doing
|
echo 116>/sys/class/gpio/unexport
echo 116>/sys/class/gpio/export
echo out>/sys/class/gpio/gpio116/direction
|




I can toggle the pin in software:
|
echo 1>/sys/class/gpio/gpio116/value
|


and
|
cat /sys/class/gpio/gpio116/value
|


returns 1 or 0 depending on what value I set it to

However, the voltage of the pin stays at 3.3V.
I've also tried to init GPIO20 as well as 116, set them both to low or 
set one to input and the other output/high. No luck.


I guess I need more than a simple overlay/pinmux config/... to set the 
pin configuration (and disable CLKOUT2)


There is lots of information on how to create and use them, but no 
clear explanation on how to do this with current kernels. I've gone 
through Derek Malloys book, but some of his methods seems deprecated 
with newer kernels.


My (compiling but not functioning) p941test-00A0.dts (based on the TI 
dts example files):


|
/*
 * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 */
/dts-v1/;
/plugin/;

/{
    compatible ="ti,beaglebone","ti,beaglebone-black";

/* identification */
    part-number ="pinctrl-test-0";

    fragment@0 {
        target =<_pinmux>;
        __overlay__ {
            pinctrl_test:pinctrl_test_0_pins {
                pinctrl-single,pins =<
0x1b40x0F/* P9_41 muxRegOffset, OUTPUT | MODE0 | Pull down enabled */
0x1a80x07/* P9_42 muxRegOffset, OUTPUT | MODE0 */

>;
};
};
};

    fragment@1 {
        target =<>;
        __overlay__ {
            test_helper:helper {
                compatible ="bone-pinmux-helper";
                pinctrl-names ="default";
                pinctrl-0=<_test>;
                status ="okay";
};
};
};
};

|

compiling this with
|
sudo make -d src/arm/p941test-00A0.dtbo
|

seems to do what it should.
After using ./install.sh to put it everything in the correct 
directory, I set

|
uboot_overlay_addr7=/lib/firmware/p941test-00A0.dtboin/boot/uEnv.txt
|



I'm quite confident my dts is the issue, but no idea what's wrong (and 
it does compile).



Some additional info:

/opt/scripts/tools/version.sh returns:
|
git:/opt/scripts/:[1aa73453b2c980b75e31e83dab7dd8b6696f10c7]
eeprom:[A335BNLTEIA04718BBBK00F9]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org DebianImage2018-10-07]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot2018.09-2-gd5b4c4b656]:[location:dd 
MBR]

kernel:[4.14.71-ti-r80]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-UART1-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr5=/lib/firmware/BB-UART2-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr6=/lib/firmware/BB-UART4-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr7=/lib/firmware/BB-UART5-00A0.dtbo]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_wireless=1]
uboot_overlay_options:[disable_uboot_overlay_adc=1]
pkg check:to individually upgrade run:[sudo apt install --only-upgrade 
]

pkg:[bb-cape-overlays]:[4.14.20200805.0-0~stretch+20200805]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.3-git20181009.0-0rcnee0~stretch+20181010]
cmdline:[console=ttyO0,115200n8bone_capemgr.uboot_capemgr_enabled=1root=/dev/mmcblk1p1 
ro rootfstype=ext4 rootwait coherent_pool=1Mnet.ifnames=0quiet]

dmesg |grep pinctrl-single
[1.040989]pinctrl-single 44e10800.pinmux:142pins at pa f9e10800 size 568
dmesg 

[beagleboard] Guide on configuring pins

[deeveee83]

Hi,

I've been using a BBB for a couple of years now and have always struggled 
to configure pins.
There have been plenty of methods that have changed with kernel updates. As 
a result lots of information on the internet contradicts other posts and 
many of them are simply not working anymore.

Is there something like "a definitive guide on how to configure and control 
the pins on the current kernel version"?

I've seen pin manager, pin config, overlays, dtbo files loaded in slots, 
dtbo loaded in uboot and (it seems like) many others.

I can't get P9_41 to work as an output (it has two different "balls" going 
to it), but would really like to understand what I'm doing.
Currently at kernel 4.14.71-ti-r80, but willing to update to newer if I can 
get everything working again.

Thanks in advance!


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/429dc024-b83c-4093-a8a0-b0652e42c901o%40googlegroups.com.

[beagleboard] BBB - using "special" P9.41 as GPIO

[deeveee83]

I don't like to admit defeat, but this time I give up...

I am trying to use the BeagleBone Black P9_41 pin as a GPIO 
(GPIO3_20/GPIO0_20). According to the BeagleBone Black System reference 
manual two different balls are connected to that pin:
"# Both of these signals connect to pin 41 of P11. Resistors are installed 
that allow for the GPIO3_20 connection to be removed by removing R221. The 
intent is to allow the SW to use either of these signals, one or the other, 
on pin 41. SW should set the unused pin in input mode when using the other 
pin. This allowed us to get an extra signal out to the expansion header. "

I realize this complicates matters, but I have no choice but to use this 
exact pin. I am using other pins succesfully. Additionally, I am using 
overlays to use ttyO1, ttyO2, ttyO4 and ttyO5. 
The R221 designator is not correct, so I downloaded the boardfiles and 
looked at them in Orcad. I tryed desoldered R19 (which disconnects CLKOUT2) 
as well as R20 (one at a time), but that didn't help. I resoldered both 0R 
bridges.

I have created a DTS which compiles succesfully with 

After doing 
echo 116 > /sys/class/gpio/unexport
echo 116 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio116/direction




I can toggle the pin in software:
echo 1 > /sys/class/gpio/gpio116/value


and
cat /sys/class/gpio/gpio116/value


returns 1 or 0 depending on what value I set it to

However, the voltage of the pin stays at 3.3V.
I've also tried to init GPIO20 as well as 116, set them both to low or set 
one to input and the other output/high. No luck.

I guess I need more than a simple overlay/pinmux config/... to set the pin 
configuration (and disable CLKOUT2)

There is lots of information on how to create and use them, but no clear 
explanation on how to do this with current kernels. I've gone through Derek 
Malloys book, but some of his methods seems deprecated with newer kernels.

My (compiling but not functioning) p941test-00A0.dts (based on the TI dts 
example files):

/*
 * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 */
/dts-v1/;
/plugin/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";

/* identification */
part-number = "pinctrl-test-0";

fragment@0 {
target = <_pinmux>;
__overlay__ {
pinctrl_test: pinctrl_test_0_pins {
pinctrl-single,pins = <
0x1b4 0x0F/* P9_41 muxRegOffset, OUTPUT | MODE0 | 
Pull down enabled */
0x1a8 0x07/* P9_42 muxRegOffset, OUTPUT | MODE0 */

>;
};
};
};

fragment@1 {
target = <>;
__overlay__ {
test_helper: helper {
compatible = "bone-pinmux-helper";
pinctrl-names = "default";
pinctrl-0 = <_test>;
status = "okay";
};
};
};
};


compiling this with 
sudo make -d src/arm/p941test-00A0.dtbo

seems to do what it should.
After using ./install.sh to put it everything in the correct directory, I 
set 
uboot_overlay_addr7=/lib/firmware/p941test-00A0.dtbo in /boot/uEnv.txt



I'm quite confident my dts is the issue, but no idea what's wrong (and it 
does compile).


Some additional info:

/opt/scripts/tools/version.sh returns:
git:/opt/scripts/:[1aa73453b2c980b75e31e83dab7dd8b6696f10c7]
eeprom:[A335BNLTEIA04718BBBK00F9]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2018.09-2-gd5b4c4b656
]:[location: dd MBR]
kernel:[4.14.71-ti-r80]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-UART1-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr5=/lib/firmware/BB-UART2-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr6=/lib/firmware/BB-UART4-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr7=/lib/firmware/BB-UART5-00A0.dtbo]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_wireless=1]
uboot_overlay_options:[disable_uboot_overlay_adc=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.14.20200805.0-0~stretch+20200805]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.3-git20181009.0-0rcnee0~stretch+20181010]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=
/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 
quiet]
dmesg | grep pinctrl-single
[1.040989] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568
dmesg | grep gpio-of-helper

[beagleboard] Re: Remote access for the beagle bone black (BBB) to modify /upgrade file from cloud server

[Chris Green]

Niresh  wrote:
> [-- text/plain, encoding 7bit, charset: UTF-8, 144 lines --]
> 
> Is there a way to access the beagle-bone using SSH or something like that
> without registering the device to another server?
> This is for commercial purposes and data protection is very important.
> Right now, it is connected to the AWS cloud server where our web
> application is running.
> 
You can use ssh but you need to get some help from whoever administers
the "AWS cloud server".

Things needed:-

The ssh daemon in the BBB needs to be running (I can't remember if
this is default or not)

You need to know the BBB's IP address, presumably it will be on a
LAN connected to the "AWS cloud server".

You need the "AWS cloud server" or the router 'behind' it to
forward connections from the internet (i.e. you) on port 22 to the
BBB

Looking at what "AWS cloud server" I suspect that the IOT services
there might be what you need to talk to your BBB.

-- 
Chris Green
·

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/8iql5h-qag5.ln1%40esprimo.zbmc.eu.