2

Our company is attempting to use a raspberry pi 0 wifi for an IOT product that we are booting with a custom yocto image. After making some changes (added mender) the serial 1 device stopped working on first boot. This means that the bluetooth fails to start. After rebooting it works perfectly every time, but the very first time it boots after a fresh installation it fails consistently.

The error that we are getting is dev-serial1.device: Job dev-serial1.device/start timed out. This then causes bcrm43438 to fail which breaks bluetooth.

We have the following udev rule set up at /etc/udev/rules.d/99-com.rules:

KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\
    ALIASES=/proc/device-tree/aliases; \
    if cmp -s $ALIASES/uart0 $ALIASES/serial0; then \
        echo 0;\
    elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then \
        echo 1; \
    else \
        exit 1; \
    fi\
'", SYMLINK+="serial%c"

KERNEL=="ttyS0", PROGRAM="/bin/sh -c '\
    ALIASES=/proc/device-tree/aliases; \
    if cmp -s $ALIASES/uart1 $ALIASES/serial0; then \
        echo 0; \
    elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then \
        echo 1; \
    else \
        exit 1; \
    fi \
'", SYMLINK+="serial%c"

if we run udevadm control --reload-rules && udevadm trigger after booting it will load up serial1 and then if we run btuart it will start working properly.

Is there a good way to debug the udev startup process to see what is going on? It is a little weird because it is only on the first boot, and so we can't edit the systemd-udevd.service file and reboot because the problem will no longer manifest.

Improve this question
2

The first boot may be slower than the reboot (cold boot vs warm boot). Since your hardware is relatively underpowered as an IoT device, running into a timeout seems more likely.

Why not just try waiting a little longer for the service to boot up since it's a timeout issue?

Check related directives in man systemd.unit, like JobTimeoutSec= and JobRunningTimeoutSec=.

Set it to a value a that is acceptable to you, but still reasonable. Is it OK if it takes a minute or two to boot up? Try setting this to 60 to 100 seconds to see if that helps.

If this simple solution doesn't solve it, then I would consider digging deeper to the issue.

Improve this answer
2
  • 1
    I think you were right about the timing issue. We ended up solving it by just stamping over the udev rule with a simple one that always symlinks. The uart device was probably not set up properly in time. All the conditional stuff in the rule was for supporting different rpi devices, but we only need to support one so we can safely ignore it. – keeslinp Jun 6 '18 at 17:55
  • If you believe my answer was correct, please mark it as accepted. Thanks! – Mark Stosberg Jun 6 '18 at 20:53
2

I'm not going to try to decipher your script, but to answer your question re debugging udev, man systemd-udevd.service is your friend!

Read that, and pay particular attention to the --debug and --exec-delay= options.

Improve this answer
2
  • The rule is straight from the layer So hopefully, it is alright. I'll check out the docs for more info. – keeslinp Jun 4 '18 at 22:30
  • That gist worked on another system that (I assume) could have been configured differently than yours. All my answer is going to give you is more information - information you may need to resolve the issue. – Seamus Jun 5 '18 at 14:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.