Version of ModemManager

Product support balenaOS
40

@mpous @alexgg I had updated config.json incorrectly.

I would be in pretty good shape if I had a way to update the device tree. What I did for now is mount the image that is on the flasher and overwrite the device trees within the image within the volume. This is far from ideal and difficult to automate.

Can you please provide a config.json method for updating uEnv.txt, device trees and overlays? Of course, this is very risky, so the ideal case would be to include a fall-back when trying to update these. You working out challenges like that is why I use Balena for real-world projects. :smiley:

1 Like
42

Hi Jason, thanks for posting your updates, this is all really good feedback for the product.

Updating device trees and overlays is something that we have some device-specific solutions and we would like to come up with a common device-agnostic one.

For example, we can:

  • Load device tree overlays at runtime for the RaspberryPis
  • Select a different device tree as a dashboard configuration for selected Jetson/i.MX device types (with caveats, as the device needs to be able to boot with the default device tree and it can only select device trees that have been integrated into balenaOS via a contributed PR).

None of the above apply to the beaglebone at the moment though.

Is this device tree overlay something that you could PR into the device repository to include in future balenaOS releases? You mention it configures some GPIOs for modem reset, are these used for any modem or just this specific modem?

Or are these settings multiplexed with other configuration so it needs to be a per-boot or even runtime applied configuration?

1 Like
43

Please adopt Distro Boot. It is adopted across a wide variety of embedded Linux systems, boards, and distributions following the Freedesktop.org/SystemD.io boot loader specification.

Possibly, but Iā€™m under the gun at the moment. The BeagleBoard.org u-boot already supports distro boot. It will take me some time to understand how youā€™ve modified u-boot to provide reliable booting and integrate with your system. It is something that your team would probably do better than me.

Perhaps you can give me some hints on how extlinux.conf can be updated safely in config.json, as I havenā€™t found where the config.json settings are applied. Iā€™d want to make sure that there is some kind of failure resilience to avoid a bad extlinux.conf being installed as well as explore how the right boot option is chosen from within it.

For my Quectel E25 modem usage, I have specific GPIOs for powering and resetting the modem. They could be generic, but I think the timings can get to be fairly modem-specific. This is something I expect all embedded-modem users to need to handle. The USB modems just seem so much easier to handle, but the cost and reliability arenā€™t as suitable for me.

There is a run-time toggling of reset. It is a start-up sequence, not just a static state. It isnā€™t complicated, but Iā€™m applying one signal, waiting, then asserting the other. It might be possible in the device tree itself, but a script is easier. Right now, Iā€™m doing it in my container, which is hazardous to my connectivity.