We currently having some issues regarding updating of Balena OS. We made a custom image, where we added our bootup scripts, so that we know for sure that 4G is active. Luckly we are still in testing phase. This worked fine till Balena released BalenaOS 2.47.0+rev1.
In our test we had 2 devices offline on purpose. We put them online again and we see that one of the devices we changed to online again has the status. Online (VPN only) When we check the diagnostics tool, we get the following results:
We cannot update the image, because it overwrites the custom bash file that enables the 4G connection of our hardware. We where thinking about the following solutions:
Update our custom image and deploy through your platform.
Add patch to your balena-raspberrypi , so that it is always working and we don’t need a custom image
add container that activates sim module instead of the patched image
I would like to know what solution is best for us or that there is a possibility to execute the bash file outside your update mechanism.
Creating a container that activates the SIM is the most “balena-like” way to resolve this. Creating a separate service can also help you isolate troubleshoot the specific SIM capabilities you’re looking for. Perhaps, too, you could use Device and Environment variables to customize your deployment without having to make customizations to your image. I’ll also raise in issue regarding 2.47.0+rev1. Can you tell us what device(s) you’re using and any specific HAT/SIM module?
It’s supported by Balena OS, but only the mini-pcie variant. It even gets unstable because of your modemManager.service. If we don’t disable the modemManager.service, there is a possiblity that the USB stops working completely. So we disable that one in your build . We use qmicli and set gpio pins on boot.
#P7 (BCM P4), Pull high enable flight mode
# Check if gpio is already exported
if [ ! -d /sys/class/gpio/gpio4 ]; then
echo "4" >/sys/class/gpio/export
echo "exported gpio4"
sleep 1 # Short delay while GPIO permissions are set up
fi
echo "out" >/sys/class/gpio/gpio4/direction
echo "0" >/sys/class/gpio/gpio4/value
if [ ! -d /sys/class/gpio/gpio6 ]; then
echo "6" >/sys/class/gpio/export
echo "exported gpio6"
sleep 1 # Short delay while GPIO permissions are set up
fi
echo "out" >/sys/class/gpio/gpio6/direction
echo "0" >/sys/class/gpio/gpio6/value
With these modifications we get a stable working OS for the last three months, until 6 days ago the 4G connection stopped working.
Hi @neonlink, reading through your issue, I would like to encourage you to go with your second suggested method, which is to PR a change to the balena-raspberrypi build. Since modifying the balenaOS is image is not recommended and could lead to all kinds of unintended issues and make it impossible for us to support you in the future.
My suggestion would be to look into creating a custom DT overlay named something like neolink-modem.dtb that would be included by default in our build and would enable all the GPIO with the right values on boot up, there by enabling your modem. This DT overlay would persist through HostOS updates, which other changes wouldn’t.
I would also strongly recommend using modemManager to bring up the modem, we test the SIM7600 with modemmanager (also under the hood it uses qmicli) and it works great, so I woudn’t disable modemManager either as again these types of changes make it difficult for OS updates and our team to support in the future.
My sense is that a simple custom DTB and modemmanager will get you a stable modem that doesn’t rely on OS modifications or rely on the containers to modify connection settings (which we also don’t recommend as the container engine can sometimes get into a corrupt state and not be able to start your container)
Let us know your thoughts and we can help guide you to add this custom DTB!
There needs to be also a second commit, as we’re triggering dtbo’s build from another yocto component:
From 7a8089f5423b06869bd59bd3dbd09968039a7848 Mon Sep 17 00:00:00 2001
From: User Name <user@email.io>
Date: Fri, 1 May 2020 14:40:47 +0200
Subject: [PATCH 2/2] conf/layer: Add Waveshare dtbo to overlays
Signed-off-by: User Name <user@email.io>
---
layers/meta-balena-raspberrypi/conf/layer.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/layers/meta-balena-raspberrypi/conf/layer.conf b/layers/meta-balena-raspberrypi/conf/layer.conf
index 1595d52..02e7da8 100644
--- a/layers/meta-balena-raspberrypi/conf/layer.conf
+++ b/layers/meta-balena-raspberrypi/conf/layer.conf
@@ -130,6 +130,7 @@ KERNEL_DEVICETREE_append = " \
overlays/uart5.dtbo \
overlays/vc4-fkms-v3d.dtbo \
overlays/vga666.dtbo \
+ overlays/waveshare-sim7600.dtbo \
overlays/wittypi.dtbo \
"
--
2.17.1
Please don’t forget to use your name and desired email in the patches, and also feel free to re-word the commit messages as you find appropriate. Thanks!
I have problems figuring out how to enable dhcp on the wwan0. even when the wwan0 is configured on boot, dhcp is not available.
I added these udevrules to config.json:
Hi, for cellular connections once ModemManager registers and connects to a network creating the wwan0 interface, NetworkManager will ask ModemManager to handle IP configuration. The ipv4 method auto means that NetworkManager will await for DHCP configuration to arrive from the configured gateway. You do not need to add such an udev rule for this.
Will you be able to share support access with such a device, so that I can take a look? If you can please send me the device dashboard link in a private message and I will check it tomorrow (I am in a EU timezone).
Thanks for sharing support access with the device. I checked it now and it is all looking good. Currently the device only connects through cellular, and WiFi is not connected, and all is working well. NetworkManager is able to get an IP, gateway and DNS servers through DHCP.
