Disable console over Serial in Dev on RPi3?

Do you have any overlay loaded in any of the images?

Let’s talk only about ResinOS without any docker image maybe, since it’s reproductible this way.

UPDATE : Hey, I think I have some idea :

Sometimes /dev/serial0 is linked to /dev/ttyAMA0, and sometimes it’s not, it’s /dev/serial1 which is linked to /dev/ttyAMA0. And you told me a month ago that what is important is masking the serial-getty@serialx, not masking the serial-getty@ttyAMA0.

So maybe the first step would be to check which /dev/serialx is linked to /dev/ttyAMA0, masking serial-getty@serial0 won’t do the trick every time.

Well it’s a theory for dev OS though, not for prod OS, except if you mask the yourself building the OS.

UPDATE 2 : I’ve just tried on a "Resin OS 2.0.8+rev1 (dev) " masking everything and rebooting, but I can’t display anything cat’ing all /dev.

So it would mean only one version of Resin OS is allowing me to see data on /dev/ttyAMA0, so I know it looks like I’ve installed something special on this card, but I have not.

Is it possible something installed in the Docker image influence what’s happening on the host ?

So far I thought the only interactions where :

  • volumes (containers writing datas visible by host in volume directories)
  • ports (you set a port mapping so each listening container port corresponds to a listening host port).

Are there low level interactions which would allow some process running in the container to write on /dev/ttyAMA0 from the container ?

UPDATE : one thing I’ve just learnt is the baudrate has to be set to 1200 to receive anything.

So on the working card, if I do stty -F /dev/ttyAMA0 9600, my cat doesn’t display anything, and if I set back to 1200, it works back, clearly it’s a necessary condition. And stty may persist the baudrate setting somewhere, since it’s always working on our first card, even after reboot.

Knowing this, I’ve tried to set baudrate on my other cards with no sucess.

Ok, this time I think I got it (can’t test right now). So, the answer would be “no Docker layers won’t influence what’s happening on the host” but RESIN_HOST_CONFIG_* application variables set in “Fleet Configuration > Application config variables” will !

So in my case, the 3 things to do (only 2 in prod ResinOS) to make the serial port readable were :

  1. Disabling port services (watching carefully the serial0/serial1 links or disabling everything) :

    mount -o remount,rw /
    systemctl mask serial-getty@ttyAMA0.service
    systemctl mask serial-getty@serial0.service
    systemctl mask serial-getty@serial1.service
    reboot

  2. setting the baudrate to a lower value using “stty” (which seems to be a persistent setting through reboots).

  3. Configuring some variables in /boot/config.txt through “Fleet Configuration > Application config variables” in resin.io :

    RESIN_HOST_CONFIG_dtoverlay pi3-miniuart-bt
    RESIN_HOST_CONFIG_enable_uart 1

1 Like

Great. I dd ask you about any loaded overlays :slight_smile:
The overlay you loaded switches bluetooth from the main full serial port over to the other serial port, leaving ttyAMA0 available for your device to use and send data over to the pi.

Mmmm ok, so that’s what you meant by “overlay”… To me you were talking about some docker layer (one of Docker storage driver is called “overlayfs”).

Cool, glad things are sorted now.

@Tristan107 in this context Raspberry Pi Device Tree Overlays. They modify the behaviour of the system quite a bit, as you see it as well, so knowing what overlays are enabled makes a big difference, and helps us debug. So for example here the pi3-miniuart-bt was the relevant device tree overlay, which changes the availability of the serial port.

(Also, I think you don’t need the enable_uart setting anymore, just the pi3-miniuart-bt setting. I think…)

Ok, thanks for the details.

“Do you have any overlay” was a bit short for me to recreate the good context around :wink:

Yeah, sorry about that. :slight_smile: Working with devices all day it takes a bit of context switching sometimes to make sure everyone’s talking about the same thing.

Just for confirmation and others with the same problem. When using a production image, it was enough to change the host config as mentioned:

so no need to change cmdline.txt or mask serial-getty or lowering the baudrate!

I folllowed the details above on my Dev OS to enable the serial port.

I use Bluetooth on the RPi to do BLE communications - after I open the serial port now, my bluetooth no longer works.

If I try Bluetooth before opening the serial port, it communicates fine, then as soon as I open the Serial Port, the Bluetooth fails.

I am on v2.29.2 of Device OS, I am testing on Prod now.

@mhazley, How are you connecting your bluetooth device, and which commands did you run in dev?

Hi, apologies all, this was a red-herring.

Stripped my pyserial code back to basics, removing some additional libs and it all seems to work now. Not 100% what was causing the issue at this point.

mount -o remount,rw /
systemctl mask serial-getty@serial0.service
reboot

Worked great to solve my problem. Can this be defined in the dashboard under “Device Configuration” ?

Sorry to open this back up…

Having the same issues here, running balenaOS 2.32.0+rev4 dev version on an intel nuc. We are having serial issues in one of our docker containers. The fixes above don’t seem to be working. I am not sure if it is a raspberry pi vs intel nuc issue or a docker issue, or some other issue.

Any ideas?

@tylorbayer which specific issues are you seeing? As I would expect Disable console over Serial in Dev on RPi3? to work fine for disabling the serial console in dev images

I think I still need to poke around a little bit in the HostOS… in the meantime, is there any way to check if the console is definitely disabled?

If you run systemctl | grep getty in the host os then it should give a list of all the getty services currently running and there shouldn’t be any like serial-getty@*.service running

1 Like

So running the commands above (mount/remount then systemctl mask) and then rebooting wouldn’t change that grep output and I was still seeing the serial-getty@*.service and my device was still throwing the errors regarding the serial port like it was before…

Then I ran ‘systemctl mask serial-getty@ttyS0.service’ and that worked instantly and persisted after reboot… I am not sure why it fixed my issue but the device is working great for me now with the development os. I tested in localmode as well and it works thankfully!

Thank you for the help and quick responses!