That should be “and then”, not “Or”. wpa_cli -i wlan0 reconfigure tells wpa_supplicant to re-read the config file. wpa_cli shouldn’t require sudo if the debian user is in the netdev group and the group for the control interface has been set in the config file:
ctrl_interface=DIR=/run/wpa_supplicant GROUP=netdev
thanks!
i wonder, did they recently move wpa_cli…
debian@BeagleBone:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
debian@BeagleBone:~$ which wpa_cli
debian@BeagleBone:~$ sudo which wpa_cli
/sbin/wpa_cli
is there a way to rollback to connman? systemd is not great at networking management especially in multi-interface conditions…
@RobertCNelson the default username : password (debian:temppwd) for the 01.10 snapshot for the BB AI doesn’t work (this image: am57xx-debian-11.2-iot-armhf-2022-01-10-4gb.img.xz).
Also, I’ve successfully (at least so do I think) flashed the eMMC from the SD card with the Debian 11.x (Bullseye) IOT Snapshot provided in the present post (the one for the BB AI, i.e. arm57xx) but the board reboots when I do a sudo apt update, did try twice, the first time it even appeared to go into a reboot loop (I switched the power off when the LEDs were off); the second time I did the apt update, the board rebooted only once. Is this expected? Is there anything updatable with these snapshots?
Feel free to install connman… It just no longer has an active maintainer in Debian anymore… Thus it’s now not a good default.
The other option is Network-Manager, however this doesn’t handle usb0/usb1 as nice as systemd-networkd…
Regards,
i wonder… if cloud-init broke this…
That’s not normal, it should not “reboot”… Do you have the fan cape? Or any cooling accross, wonder if it’s being triggered by over-temp???
There’s been a few updates…
Regards,
Robert: It’s nothing short of amazing how much you are doing for the beaglebone, as if you are the key person maintaining the ecosystem alive.
i wonder… if cloud-init broke this…
I have no idea, this is beyond my competences following my first steps in the beaglebone ecosystem, starting last week.
A pity that cloud9 is E.O.L., the few days I’ve spent with it before deciding to update to Bullseye proved it was a capable IDE with lots of good and fine tuned examples. Replacing it with VScode… I’m not a fan of anything microsoft even if it’s open source: the company was maybe afraid Linux would be a threat to its business with so much Deep Learning frameworks working better on Linux, so it integrated Linux in their own OS, certainly a clever move but opportunistic, duplicitous and a bit machiavellian to my eyes (nothing against users and developers of VScode!). I’ll stick to VIM for coding! And well this is not the topic of this post anyway…
For the reboot issue: I had the fan cap on. I was connected to my phone’s hotspot if that matters (no reason it should). I thought about a power supply issue (can a voltage drop cause this?) but was connected to a bench top P.S. with ample amp capacity, set to 5.2V to cope with any drop in the cable, and the reboot really did occur right within the update (a few seconds after it “Hit” the servers). I also wonder if it had anything to do with the time zone not being properly set but no, I could update later with no reboot issue while connected with an ethernet cable and another P.S.
Best, Ludovic
I hope this is an appropriate place to report any issue on these snapshots…
I’ve performed a sudo apt update, upgrade, updated the U-Boot as shown above.
I have updated the show-pin script, which originally didn’t work, with the one located here:
https://raw.githubusercontent.com/mvduin/bbb-pin-utils/bbai-experimental/show-pins
But I’m having troubles to configure pins:
$ config-pin P9_31 pruout
ERROR: open() for /sys/devices/platform/44000000.ocp/44000000.ocp:P9_31_pinmux/state failed, No such file or directory
Here is my beagle-version:
model:[BeagleBoard.org_BeagleBone_AI]
dogtag:[BeagleBoard.org Debian Bullseye IoT Image 2022-01-01]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 2021.04-g702ea30b (Nov 19 2021 - 00:11:11 +0000)]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am5729-beagleboneai.dts]
UBOOT: Loaded Overlay:[BBORG_FAN-A000.kernel]
kernel:[5.10.90-ti-r35]
nodejs:[v12.22.5]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.14.20210821.0-0~bullseye+20210821]
pkg:[bb-customizations]:[1.20211215.2-0~bullseye+20220102]
pkg:[bb-usb-gadgets]:[1.20220112.3-0~bullseye+20220112]
pkg:[bb-wl18xx-firmware]:[1.20211222.2-0~bullseye+20211222]
pkg:[kmod]:[28-1]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
pkg:[firmware-ti-connectivity]:[20210315-3]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal input bluetooth netdev gpio admin tisdk weston-launch cloud9ide]
cmdline:[console=ttyS0,115200n8 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet]
dmesg | grep remote
[ 11.098358] remoteproc remoteproc0: 58820000.ipu is available
[ 11.103881] remoteproc remoteproc0: Direct firmware load for dra7-ipu1-fw.xem4 failed with error -2
[ 11.103912] remoteproc remoteproc0: powering up 58820000.ipu
[ 11.103942] remoteproc remoteproc0: Direct firmware load for dra7-ipu1-fw.xem4 failed with error -2
[ 11.103973] remoteproc remoteproc0: request_firmware failed: -2
[ 11.111419] remoteproc remoteproc1: 55020000.ipu is available
[ 11.113433] remoteproc remoteproc1: Direct firmware load for dra7-ipu2-fw.xem4 failed with error -2
[ 11.113433] remoteproc remoteproc1: powering up 55020000.ipu
[ 11.113494] remoteproc remoteproc1: Direct firmware load for dra7-ipu2-fw.xem4 failed with error -2
[ 11.113494] remoteproc remoteproc1: request_firmware failed: -2
[ 11.143646] remoteproc remoteproc2: 40800000.dsp is available
[ 11.144439] remoteproc remoteproc3: 41000000.dsp is available
[ 11.151153] remoteproc remoteproc2: Direct firmware load for dra7-dsp1-fw.xe66 failed with error -2
[ 11.151184] remoteproc remoteproc2: powering up 40800000.dsp
[ 11.151245] remoteproc remoteproc2: Direct firmware load for dra7-dsp1-fw.xe66 failed with error -2
[ 11.151245] remoteproc remoteproc2: request_firmware failed: -2
[ 11.157714] remoteproc remoteproc3: Direct firmware load for dra7-dsp2-fw.xe66 failed with error -2
[ 11.157745] remoteproc remoteproc3: powering up 41000000.dsp
[ 11.157775] remoteproc remoteproc3: Direct firmware load for dra7-dsp2-fw.xe66 failed with error -2
[ 11.157775] remoteproc remoteproc3: request_firmware failed: -2
dmesg | grep pru
dmesg | grep pinctrl-single
[ 5.037597] pinctrl-single 4a003400.pinmux: 282 pins, size 1128
dmesg | grep gpio-of-helper
lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END
I also noticed these Direct firmware load for [...] failed with error -2 messages.
And:
ls -l /sys/class/remoteproc
doesn’t list the PRU at remoteproc4 to 7 as I thought I would observe, as shown here [Getting started with the BeagleBone AI].
lrwxrwxrwx 1 root root 0 Jan 14 16:07 remoteproc0 -> ../../devices/platform/44000000.ocp/58820000.ipu/remoteproc/remoteproc0
lrwxrwxrwx 1 root root 0 Jan 14 16:07 remoteproc1 -> ../../devices/platform/44000000.ocp/55020000.ipu/remoteproc/remoteproc1
lrwxrwxrwx 1 root root 0 Jan 14 16:07 remoteproc2 -> ../../devices/platform/44000000.ocp/40800000.dsp/remoteproc/remoteproc2
lrwxrwxrwx 1 root root 0 Jan 14 16:07 remoteproc3 -> ../../devices/platform/44000000.ocp/41000000.dsp/remoteproc/remoteproc3
What am I missing to be able to configure pins? And to have the PRU listed at remoteproc4 to 7?
Best,
Ludovic
[edited to add info in /sys/class/remoteproc]
Hi @Ludo everything in that Getting Started guide references an older image with a highly tweaked v4.14.x/v4.19.x kernel image.
All that stuff hasn’t been re-ported to v5.10.x yet…
Feel free to use the TIDL specific 10.x (buster) Snapshots: Debian 10.x (Buster) - Monthly Snapshots
Which are also updated once a month…
Regards,
Thanks Robert.
All that stuff hasn’t been re-ported to v5.10.x yet…
Noted. Facing problems and digging to try to solve them is an excellent way to learn. I’ll report issues on github (link mentioned at the top of your post), where I should have done so from the beginning (instead of here).
Feel free to use the TIDL specific 10.x (buster) Snapshots: Debian 10.x (Buster) - Monthly Snapshots
Will do, in order to get familiar with the PRU; but since a lot seems to have changed in the Bullseye release, I’d also like to jump in to the Bullseye train early.
Best, Ludovic