Network setup taken over by something

[maxmike]

I have been running BBB networking for some time using a netmask of 255.255.255.0; I now have to expand the network

to 500 hosts, so I changed the mask to 255.255.254.0 to give a network at 192.168.0.0/23. I edited /etc/network/interfaces,

but that seems to change nothing as per following; blessed connman is NOT running:

(got the following off the serial connection)

Debian GNU/Linux 8 beaglebone ttyS0

BeagleBoard.org Debian Image 2017-03-19

root@beaglebone:~# cat /etc/network/interfaces

auto lo

iface lo inet loopback

auto eth0

iface eth0 inet static

address 192.168.0.231

netmask 255.255.254.0

gateway 192.168.0.1

root@beaglebone:~# ip addr

1: lo...

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether b0:d5:cc:ca:18:0d brd ff:ff:ff:ff:ff:ff

    inet 192.168.1.231/24 brd 192.168.1.255 scope global eth0

       valid_lft forever preferred_lft forever

    inet6 fe80::b2d5:ccff:feca:180d/64 scope link

       valid_lft forever preferred_lft forever

3: usb0...

4: usb1: ...

5: can0: ...

6: can1: ...

root@beaglebone:~# ifconfig

eth0      Link encap:Ethernet  HWaddr b0:d5:cc:ca:18:0d

          inet addr:192.168.1.231  Bcast:192.168.1.255  Mask:255.255.255.0

          inet6 addr: fe80::b2d5:ccff:feca:180d/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:404 errors:0 dropped:0 overruns:0 frame:0

          TX packets:58 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:34286 (33.4 KiB)  TX bytes:7710 (7.5 KiB)

          Interrupt:173

[evilwulfie]

connman has taken over maybe ?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you 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/0fcbaf33-44c5-42e6-8018-420282dcd335%40googlegroups.com.

[jonnymo]

Did you reset the network or reboot the board so the change will take place? 

Cheers,

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/71e73eba-d8e5-178e-85b3-3bcc695b879d%40gmail.com.

[maxmike]

Rebooted and swapped routers (only one has the new network on it).

I'm getting the feeling that Debian lost control here and needs connman. But I can't upgrade, so now I have to change

horses in midstream because the old images can't support a netmask other than /24; not a problem if you are fooling

around in the lab, but once you have installed embedded systems in the field ... geez this sort of thing burns me up. 

[Robert Nelson]

I run a /22 network (at home... Don't ask, but it's related to testing. ;) )

[ip addr show eth0]
4: eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc mq

state UP group default qlen 1000

link/ether 84:eb:18:e2:52:9a brd ff:ff:ff:ff:ff:ff
inet 192.168.3.201/22 brd 192.168.3.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::86eb:18ff:fee2:529a/64 scope link
valid_lft forever preferred_lft forever


Connman + Debian 10 (v4.14.x-ti, v4.19.x-ti, v5.4.x-ti, v4.14.x-bone,
v4.19.x-bone, and v5.4.x-bone kernel's..)

Regards,

--
Robert Nelson
https://rcn-ee.com/

[maxmike]

OK - but here we go again with cape-universal:

 

 root@beaglebone:~# config-pin -q p9.26

Current mode for P9_26 is:     default

root@beaglebone:~# config-pin p9.26 in+

ERROR: write() to /sys/devices/platform/ocp/ocp:P9_26_pinmux/state failed, No such device

[Robert Nelson]

Yeah, in+ is no longer valid..

debian@bbb-pwr02-ser10:~$ config-pin -q P9.26

Current mode for P9_26 is: default

debian@bbb-pwr02-ser10:~$ config-pin -l P9.26

Available modes for P9_26 are: default gpio gpio_pu gpio_pd gpio_input
uart can i2c pru_uart pruin

in+ may have been supported by the original version of config-pin, but
that shell script is un-maintainable as we added more boards..

The new version of config-pin, parses the actual modes available.

[maxmike]

Using BeagleBoard.org Debian Buster IoT Image 2020-04-06

On Thursday, April 23, 2020 at 4:26:03 PM UTC-7, maxmike wrote:

Wow - it looks like the entire cape-universal software is now broken:

One used to be able to do :  config-pin p8.12 out

and then test it by issuing config-pin p8.12 hi or lo

This is no longer possible, now the pin can only be set as pruout and hi/lo don't work anymore. 

[Robert Nelson]

On Thu, Apr 23, 2020 at 6:26 PM maxmike <maxmi...@gmail.com> wrote:
>>
>> Wow - it looks like the entire cape-universal software is now broken:
>
>
> One used to be able to do : config-pin p8.12 out
> and then test it by issuing config-pin p8.12 hi or lo
>
> This is no longer possible, now the pin can only be set as pruout and hi/lo don't work anymore.

I had no idea config-pin had a sub-option to also set the value and direction..

https://github.com/beagleboard/bb.org-overlays/blob/master/tools/beaglebone-universal-io/config-pin#L1077-L1109

https://github.com/beagleboard/bb.org-overlays/blob/master/tools/beaglebone-universal-io/config-pin#L1279-L1289

https://github.com/beagleboard/bb.org-overlays/blob/master/tools/beaglebone-universal-io/config-pin#L1396-L1413

Anywho, the current shipping config-pin would require:

config-pin P8.12 gpio
echo 1 > /sys/class/gpio/gpio44/value

But you probably don't want to do that..

sudo rm /usr/bin/config-pin
sudo cp -v /opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin
/usr/bin/

So there, all fixed..

For comparison, the old script:

https://github.com/beagleboard/bb.org-overlays/blob/master/tools/beaglebone-universal-io/config-pin

It's replacment..

https://github.com/beagleboard/bb.org-overlays/blob/master/tools/pmunts_muntsos/config-pin.c

[maxmike]

Is there any way to get aptitude to access gdb in Buster? apt-get update fails as does apt-get install gdb

[Chris Green]

maxmike <maxmi...@gmail.com> wrote:
>
>
> Is there any way to get aptitude to access gdb in Buster? apt-get update
> fails as does apt-get install gdb
>

It would make it easier to help you if you told us the errors you get
when trying this. .....or even copy and paste what actually happens.

--
Chris Green
·

[maxmike]

root@beaglebone:/tmp# uname -a

Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux

root@beaglebone:/tmp# apt-get update

Err:1 http://deb.debian.org/debian buster InRelease

  Temporary failure resolving 'deb.debian.org'

Err:2 http://repos.rcn-ee.com/debian buster InRelease

  Temporary failure resolving 'repos.rcn-ee.com'

Err:3 http://deb.debian.org/debian buster-updates InRelease

  Temporary failure resolving 'deb.debian.org'

Err:4 http://deb.debian.org/debian-security buster/updates InRelease

  Temporary failure resolving 'deb.debian.org'

Reading package lists... Done

W: Failed to fetch http://deb.debian.org/debian/dists/buster/InRelease  Temporary failure resolving 'deb.debian.org'

W: Failed to fetch http://deb.debian.org/debian/dists/buster-updates/InRelease  Temporary failure resolving 'deb.debian.org'

W: Failed to fetch http://deb.debian.org/debian-security/dists/buster/updates/InRelease  Temporary failure resolving 'deb.debian.org'

W: Failed to fetch http://repos.rcn-ee.com/debian/dists/buster/InRelease  Temporary failure resolving 'repos.rcn-ee.com'

W: Some index files failed to download. They have been ignored, or old ones used instead.

root@beaglebone:/tmp# apt-get install gdb

Reading package lists... Done

Building dependency tree

Reading state information... Done

Package gdb is not available, but is referred to by another package.

This may mean that the package is missing, has been obsoleted, or

is only available from another source

However the following packages replace it:

  gdb

E: Package 'gdb' has no installation candidate

[Dennis Lee Bieber]

On Sun, 26 Apr 2020 17:23:50 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user maxmike

<maxmikes001-Re5JQ...@public.gmane.org> wrote:

>
>Is there any way to get aptitude to access gdb in Buster? apt-get update
>fails as does apt-get install gdb

To the best of my knowledge, "aptitude" is just a front-end using apt
in the background to perform actions. At the best, it is still using the
same package database.

A cut&paste of the actual failure messages would have been of help...

{An hour later, after formatting and writing the 10.3 image to an SD card}

No apparent problems on a fresh 10.3 Buster image.

debian@beaglebone:~$ sudo apt install gdb

Reading package lists... Done
Building dependency tree
Reading state information... Done

The following additional packages will be installed:
libbabeltrace1 libc6-dbg
Suggested packages:
gdb-doc gdbserver
The following NEW packages will be installed:
gdb libbabeltrace1 libc6-dbg
0 upgraded, 3 newly installed, 0 to remove and 12 not upgraded.
Need to get 13.8 MB of archives.
After this operation, 23.5 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://deb.debian.org/debian buster/main armhf libbabeltrace1 armhf
1.5.6-2+deb10u1 [152 kB]
Get:2 http://deb.debian.org/debian buster/main armhf gdb armhf 8.2.1-2+b3
[2,824 kB]
Get:3 http://deb.debian.org/debian buster/main armhf libc6-dbg armhf
2.28-10 [10.8 MB]
Fetched 13.8 MB in 10s (1,452 kB/s)
Selecting previously unselected package libbabeltrace1:armhf.
(Reading database ... 72570 files and directories currently installed.)
Preparing to unpack .../libbabeltrace1_1.5.6-2+deb10u1_armhf.deb ...
Unpacking libbabeltrace1:armhf (1.5.6-2+deb10u1) ...
Selecting previously unselected package gdb.
Preparing to unpack .../gdb_8.2.1-2+b3_armhf.deb ...
Unpacking gdb (8.2.1-2+b3) ...
Selecting previously unselected package libc6-dbg:armhf.
Preparing to unpack .../libc6-dbg_2.28-10_armhf.deb ...
Unpacking libc6-dbg:armhf (2.28-10) ...
Setting up libc6-dbg:armhf (2.28-10) ...
Setting up libbabeltrace1:armhf (1.5.6-2+deb10u1) ...
Setting up gdb (8.2.1-2+b3) ...
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for libc-bin (2.28-10) ...
debian@beaglebone:~$


--
Dennis L Bieber

[Robert Nelson]

On Mon, Apr 27, 2020 at 11:27 AM maxmike <maxmi...@gmail.com> wrote:
>
> root@beaglebone:/tmp# uname -a
> Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux
> root@beaglebone:/tmp# apt-get update
> Err:1 http://deb.debian.org/debian buster InRelease
> Temporary failure resolving 'deb.debian.org'

You'll need to fix your network first.. Looks like a bad dns setting...

[Dennis Lee Bieber]

On Mon, 27 Apr 2020 09:27:19 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user maxmike

<maxmikes001-Re5JQ...@public.gmane.org> wrote:

>root@beaglebone:/tmp# uname -a
>Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29
>UTC 2020 armv7l GNU/Linux
>root@beaglebone:/tmp# apt-get update
>Err:1 http://deb.debian.org/debian buster InRelease
> Temporary failure resolving 'deb.debian.org'

Off-hand, that appears to be a problem in your network configuration
(do you have a network connection? Note that unless one fiddles with
"internet connection sharing" on the host computer, the USB access will not
work -- you'll need an actual ethernet cable connected to a router)


--
Dennis L Bieber

[maxmike]

My profuse and sincere apologies to everybody - a rotten RJ45 came off the Internet router while I was working on the local subnet router.

Mike

[Robert Nelson]

On Mon, Apr 27, 2020 at 12:34 PM maxmike <maxmi...@gmail.com> wrote:
>
> My profuse and sincere apologies to everybody - a rotten RJ45 came off the Internet router while I was working on the local subnet router.
> Mike

So a "real" hardware bug. ;)

That happens.

[maxmike]

I have serious problems with gcc 8.3.0:

 

 root@beaglebone:~/evseclient/compilec# gcc -o gcctest gcctest.c

gcctest.c: In function ‘main’:

gcctest.c:15:3: warning: implicit declaration of function ‘close’; did you mean ‘pclose’? [-Wimplicit-function-declaration]

   close(memh);

   ^~~~~

   pclose

For this source:

#include <stdio.h>

#include <stdlib.h>

#include <sys/mman.h>

#include <sys/stat.h>

#include <fcntl.h>

int main(void)

{

int memh;

/* using memory mapped I/O */

memh=open("/dev/mem", O_RDWR);

if (memh!=0) {

close(memh);

}

}

The problems get even weirder, with this sort of thing:

evsectlna.c:86:23: error: unknown type name ‘chargecurrent’

 int availablecurrent, chargecurrent, pwmisactive, nameplaterating, rfidpresent;

                                 ^~~~~~~~~~~~~

Question: is there  a way to add some older gcc's to the etc/apt/soures.list so I can find something that I can use?

[Alexander Zangerl]

On Tue, 28 Apr 2020 10:52:39 -0700, maxmike writes:
>gcctest.c:15:3: warning: implicit declaration of function ‘close’; did you
>mean ‘pclose’? [-Wimplicit-function-declaration]

...

>For this source:
>
>#include <stdio.h>
>#include <stdlib.h>
>#include <sys/mman.h>
>#include <sys/stat.h>
>#include <fcntl.h>

...

close is declared in unistd.h, which you didn't include.
man 2 close.

regards
az


--
Best Regards,
Alexander Zangerl
IT Engineer

BREATHE-SAFE intelligent cabin air filtration
Keeps your lungs and cabin dust free!
Head Office: 37-43 Argon Street, Carole Park QLD 4300 Australia
Western Australia: 169 Chisholm Crescent, Kewdale WA 6105
Tel: +61 7 3276 7833 M. +61 415 482 341 E. a...@breathe-safe.com

[Dennis Lee Bieber]

On Tue, 28 Apr 2020 10:52:39 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user maxmike

<maxmikes001-Re5JQ...@public.gmane.org> wrote:

>
>>
>> I have serious problems with gcc 8.3.0:
>
>
> root@beaglebone:~/evseclient/compilec# gcc -o gcctest gcctest.c
>gcctest.c: In function ‘main’:
>gcctest.c:15:3: warning: implicit declaration of function ‘close’; did you
>mean ‘pclose’? [-Wimplicit-function-declaration]
> close(memh);

https://www.gnu.org/software/libc/manual/html_node/Opening-and-Closing-Files.html
"""
The open and creat functions are declared in the header file fcntl.h,
while close is declared in unistd.h.

"""




>
>The problems get even weirder, with this sort of thing:
>
>evsectlna.c:86:23: error: unknown type name ‘chargecurrent’
> int availablecurrent, chargecurrent, pwmisactive, nameplaterating,
>rfidpresent;

I'd look at lines preceding that one for some undetected error (missing
; maybe).


--
Dennis L Bieber

[maxmike]

Thank you Dennis.

I don't know if this is the right place to make a comment or express an opinion, but be that as it may

I have to say that gcc needs a far better error reporting mechanism. In java if the "compiler" encounters an

unterminated expression at end of file, it flags it immediately. In gcc that error is held in abeyance for a huge

number of lines (about 500 in my case, in multiple files) before it's manifested as something that seems 

completely unrelated and slightly insane.

[Chris Green]

maxmike <maxmi...@gmail.com> wrote:
> [-- multipart/alternative, encoding 7bit, 58 lines --]
>
> [-- text/plain, encoding 7bit, charset: UTF-8, 21 lines --]

That's nothing to do with gcc really, it's just down to C syntax. The
compiler *can't* know until a lot later that there is an error.

I was a software engineer at BT (and spin off comapnies) for many
years, I coded in C, C++ and Java. All of them could throw very
confusing errors, many, many lines later than the original typo or
whatver that caused it.

That said, you shouldn't really have modules 500 lines long! :-) This
sort of problem is yet another reason for keeping functions short and
source files to a reasonable size.

--
Chris Green
·

[maxmike]

Without  much longer belabouring the point, in my case gcc did not check my .h file; instead of checking it

for syntax (a semicolon missing in a function definition) it accepted it and  reported what the effect was of trusting it - totally incomprehensible errors.

However, I have learned from this that before I compile the .c files I will compile the .h's separately first - that would have prevented the issue.

[jonnymo]

Although a bit off track from the original subject, you may what to look at some sort of lint tool to check you code for syntax errors.  If you use an editor such as Eclipse or Atom, this may do this for you already.

https://en.wikipedia.org/wiki/Lint_(software)

You could also look at the warning and error level settings and options to increase the level of complaints when the code is compiled.

Jon 

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you 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/b27b924a-9ca3-44cf-bceb-a355d002da2f%40googlegroups.com.

[maxmike]

I  may have one last  issue: in comparing the old /boot/uEnv.txt  for uname_r=4.4.68-ti-r110

with the new one for  uname_r=4.19.94-ti-r42 the semantics are now considerably different. 

I am trying to find a way to enable GPIO47 (p8.15) aka GPIO1_15 which should be free.

Config-pin says it's not exported.

[Robert Nelson]

Run:

sudo /opt/scripts/tools/version.sh

and share it's output so we can help debug...

[maxmike]

/opt/scripts/tools/version.sh

git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]

eeprom:[A335BNLTEIA03116BBBK06C2]

model:[TI_AM335x_BeagleBone_Black]

dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]

UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]

UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]

UBOOT: Loaded Overlay:[BB-ADC-00A0]

UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]

UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]

kernel:[4.19.94-ti-r42]

nodejs:[v10.15.2]

/boot/uEnv.txt Settings:

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=1]

pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]

pkg:[bb-cape-overlays]:[4.14.20200403.0-0rcnee0~buster+20200403]

pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]

pkg:[kmod]:[26-1]

pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]

pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]

groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi iio docker tisdk weston-launch xenomai cloud9ide]

cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656rng_core.default_quality=100 quiet]

dmesg | grep remote

[   74.783377] remoteproc remoteproc0: wkup_m3 is available

[   75.019987] remoteproc remoteproc0: powering up wkup_m3

[   75.020013] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168

[   75.020270] remoteproc remoteproc0: remote processor wkup_m3 is now up

[   78.879686] remoteproc remoteproc1: 4a334000.pru is available

[   78.907777] remoteproc remoteproc2: 4a338000.pru is available

dmesg | grep pru

[   78.879686] remoteproc remoteproc1: 4a334000.pru is available

[   78.879854] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed successfully

[   78.907777] remoteproc remoteproc2: 4a338000.pru is available

[   78.907991] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed successfully

dmesg | grep pinctrl-single

[    0.949371] pinctrl-single 44e10800.pinmux: 142 pins, size 568

dmesg | grep gpio-of-helper

[    0.962625] gpio-of-helper ocp:cape-universal: ready

lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

END

[Robert Nelson]

On Fri, May 1, 2020 at 6:17 PM maxmike <maxmi...@gmail.com> wrote:
>
> /opt/scripts/tools/version.sh
>
> git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
> eeprom:[A335BNLTEIA03116BBBK06C2]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
> UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
> UBOOT: Loaded Overlay:[BB-ADC-00A0]
> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
> UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
> kernel:[4.19.94-ti-r42]

Thanks!

I'd expect you to see "P8_15" listed here:

debian@bbb-pwr03-ser11:~$ ls /sys/devices/platform/ocp/
40300000.ocmcram 48060000.mmc 49800000.tptc
ocp:P8_12_pinmux ocp:P9_21_pinmux
44e07000.gpio 480c8000.mailbox 49900000.tptc
ocp:P8_13_pinmux ocp:P9_22_pinmux
44e09000.serial 480ca000.spinlock 49a00000.tptc
ocp:P8_14_pinmux ocp:P9_23_pinmux
44e0b000.i2c 4819c000.i2c 4a100000.ethernet
ocp:P8_15_pinmux ocp:P9_24_pinmux
44e0d000.tscadc 481a0000.spi 4a326004.pruss-soc-bus
ocp:P8_16_pinmux ocp:P9_26_pinmux
44e35000.wdt 481a6000.serial 4c000000.emif
ocp:P8_17_pinmux ocp:P9_27_pinmux
44e3e000.rtc 481a8000.serial 53100000.sham
ocp:P8_18_pinmux ocp:P9_30_pinmux
47400000.usb 481aa000.serial 53500000.aes
ocp:P8_19_pinmux ocp:P9_41_pinmux
48022000.serial 481ac000.gpio 56000000.sgx
ocp:P8_26_pinmux ocp:P9_42_pinmux
48024000.serial 481ae000.gpio driver_override
ocp:P9_11_pinmux ocp:P9_91_pinmux
4802a000.i2c 481cc000.can modalias
ocp:P9_12_pinmux ocp:P9_92_pinmux
48030000.spi 481d0000.can ocp:A15_pinmux
ocp:P9_13_pinmux of_node
48038000.mcasp 481d8000.mmc ocp:cape-universal
ocp:P9_14_pinmux power
48042000.timer 48300000.epwmss ocp:l4_wkup@44c00000
ocp:P9_15_pinmux subsystem
48044000.timer 48302000.epwmss ocp:P8_07_pinmux
ocp:P9_16_pinmux uevent
48046000.timer 48304000.epwmss ocp:P8_08_pinmux ocp:P9_17_pinmux
48048000.timer 4830e000.lcdc ocp:P8_09_pinmux ocp:P9_18_pinmux
4804a000.timer 48310000.rng ocp:P8_10_pinmux ocp:P9_19_pinmux
4804c000.gpio 49000000.edma ocp:P8_11_pinmux ocp:P9_20_pinmux

debian@bbb-pwr03-ser11:~$ sudo /opt/scripts/tools/version.sh | grep UBOOT

UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]

[maxmike]

Yes, it is listed, just can't use it for output:

config-pin -q 8.15

P8_15 Mode: gpio Direction: pin_not_exported Value: pin_not_exported

root@beaglebone# config-pin -l 8.15

default gpio gpio_pu gpio_pd gpio_input qep pru_ecap pruin

I thought of changing 

/sys/firmware/devicetree/base/ocp/P8_15_pinmux/pinctrl-names

which contains:

default gpio gpio_pu gpio_pd gpio_input qep pru_ecap pruin

[Robert Nelson]

bad version of config-pin?

(there's a copy under:
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin )

debian@bbb-pwr03-ser11:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin
-q P8.15
P8_15 Mode: default Direction: in Value: 0

debian@bbb-pwr03-ser11:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin
-l P8.15

default gpio gpio_pu gpio_pd gpio_input qep pru_ecap pruin

debian@bbb-pwr03-ser11:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin
P8.15 gpio_pu

debian@bbb-pwr03-ser11:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin
-q P8.15
P8_15 Mode: gpio_pu Direction: in Value: 1

[maxmike]

I am using the version you had me install on Apr 23 (see above) .

That one fixed everything except it created this. 

 

[maxmike]

My image is : BeagleBoard.org Debian Buster IoT Image 2020-04-06

On Saturday, May 2, 2020 at 9:20:30 AM UTC-7, maxmike wrote:

I get this:

root@beaglebone:/# /opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -q P8.15

[maxmike]

This is really strange - I use P8.19 exactly the same way and it works fine. P8.15 has 3 additional functions in  

/sys/firmware/devicetree/base/ocp/P8_15_pinmux/pinctrl-names: qep pru_ecap and pruin

[maxmike]

Hm, gpioinfo was not listing p8.15, so just before throwing the board out the window I decided to reboot, and now we seem to be good. 

[maxmike]

I was hopeful to return here after weaving my system together and thank @rcn for all his help,

but I'm not out of the woods yet.

All the pins initialize correctly (even 8.13 pwm, which is now in a new file) but as soon

as I write the value 47 into /sys/class/gpio/export pin 8.15 disappears again. In Debian 8

I used /sys/class/gpio/* for export, unexport, and /sys/class/gpio/gpio# for direction, value, edge, etc.

This is no longer valid under Debian 10. Sigh

[Robert Nelson]

idk, in the out of box default configuration, all valid pin's are
pre-exported.. Including 47

debian@bbb-pwr03-ser11:/sys/class/gpio$ ls
export gpio117 gpio26 gpio37 gpio5 gpio68 gpio77 gpio9
gpio10 gpio12 gpio27 gpio38 gpio50 gpio69 gpio78 gpiochip0
gpio11 gpio13 gpio3 gpio39 gpio51 gpio7 gpio79 gpiochip32
gpio110 gpio14 gpio30 gpio4 gpio60 gpio70 gpio8 gpiochip64
gpio111 gpio15 gpio31 gpio44 gpio61 gpio71 gpio80 gpiochip96
gpio112 gpio19 gpio32 gpio45 gpio62 gpio72 gpio81 unexport
gpio113 gpio2 gpio33 gpio46 gpio63 gpio73 gpio86
gpio114 gpio20 gpio34 gpio47 gpio65 gpio74 gpio87
gpio115 gpio22 gpio35 gpio48 gpio66 gpio75 gpio88
gpio116 gpio23 gpio36 gpio49 gpio67 gpio76 gpio89
debian@bbb-pwr03-ser11:/sys/class/gpio$ uname -r
4.19.94-ti-r43

i'm wondering what blocking that auto export?

[maxmike]

This seems to do the trick:

/sys/devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/

but I'm not 100% done.

[maxmike]

There is a hangup when  trying gpio 5 (p9.17) :

config-pin for it works, but 

/sys/devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio5/

does not exist

[maxmike]

I have a feeling (need to change a bunch of code to check) that gpio5 is at:

/sys/devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio5

[maxmike]

Yes, now I know how to modify my code to verify this - the gpios are split between those two directories in Debian10

[maxmike]

Is that the right thing to do to freeze the code? Or is there a chance of a mod at your end and I hold off?

[Robert Nelson]

On Fri, May 8, 2020 at 11:49 AM maxmike <maxmi...@gmail.com> wrote:
>
> Is that the right thing to do to freeze the code? Or is there a chance of a mod at your end and I hold off?

If your code used "gpiochip1" for "gpio5" let me guess your old kernel
was 3.8.x?

[maxmike]

root@niihau:~# uname -a

Linux niihau 3.8.13-bone84 #1 SMP Sun Feb 12 02:54:13 UTC 2017 armv7l GNU/Linux

[maxmike]

It was using /sys/class/gpio for all gpio's

[maxmike]

/sys/class/gpio in

root@beaglebone:~# uname -a

Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux

looks almost identical but is unusable

[Robert Nelson]

Do what ever you want, 3.8.13 is EOL..

The gpio's got renamed on mainline in 2013 (7 years ago) with 3.10.x..
They haven't changed since.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am33xx.dtsi?id=b918e2c0b5a09c1e15426854579eb7ed04ce1685

[maxmike]

Then why is /sys/class/gpio unusable when it was useable in 2017? Just wondering...

[Robert Nelson]

On Fri, May 8, 2020 at 1:50 PM maxmike <maxmi...@gmail.com> wrote:
>
> Then why is /sys/class/gpio unusable when it was useable in 2017? Just wondering...

/sys/class/gpio is going to be removed:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/obsolete/sysfs-gpio

It was EOL'ed in 2008, with 2.6.27..

It should disappear some time this year.. (2020)

[maxmike]

Thanks Robert - got it.