Re: meta-raspberrypi systemd rpi0-w bluetooth startup

[Dengke Du <dengke.du@windriver.com>]

[-- Attachment #1: Type: text/plain, Size: 7748 bytes --]

After some tests, I found the following appearance:

1) When I add "enable_uart=1" to the /boot/config.txt, the 
brcm43438.service(use /dev/ttyAMA0) can start successfully *definitely*.

2) When I remove "enable_uart=1" from the /boot/config.txt, the 
brcm43438.service can't start always.

You can try the 1).


On 2018年03月20日 23:17, r10kindsofpeople wrote:
> FWIW: Dengke's email caused me to wonder why the RDEPENDS in bluez 
> hadn't triggered the inclusion of udev-rules-rpi in the first place.  
> I now suspect that when I tried to switch from 'rocko' to 'master', 
> the steps I took to force a rebuild were insufficient, and bluez5 was 
> not recompiled with the new patches, including the patch to increase 
> the timeout. I'm not able to check it at the moment, but will try to 
> retrace my steps when I get a chance.
>
> John
>
> On Tue, Mar 20, 2018 at 10:13 AM r10kindsofpeople 
> <r10kindsofpeople@gmail.com <mailto:r10kindsofpeople@gmail.com>> wrote:
>
>     Thanks Dengke, I thought I tried using the line
>     "After=dev-ttyAMA0.device" and referring to /dev/ttyAMA0 in the
>     hciattach command and the brcm43438.service was still being
>     triggered before the /dev/ttyAMA0 device was actually available on
>     some boots, but I may have had something else wrong at that point,
>     or I may be recalling incorrectly.  If it works for you, great.
>
>     It doesn't make sense to me that we'd need the udev-rules-rpi for
>     bluez, but then refer to /dev/ttyAMA0 in the service.  I thought
>     the point of the 99-com.rules file created by udev-rules-rpi was
>     to create a symbolic link equating /dev/ttyAMA0 and /dev/serial1
>     on the rpi0w.
>
>     It's my impression that the move to use /dev/serial1 (as an alias
>     for /dev/ttyAMA0) is an attempt to make software written for the
>     Raspberry Pi more portable across all variants of the Pi, since
>     some variants swap the role of /dev/ttyS0 and /dev/ttyAMA0 for the
>     console or swap which one is available on the GPIO expansion.  Or
>     perhaps the goal was portablilty from Raspbian to Yocto and back.
>     The steps I outlined retain that, and still seem to work
>     reliably.  I'm not entirely comfortable with relying on the udev
>     script to trigger the service that runs hciattach, (and all of
>     bluez dependent on that), but acknowledge that I don't know enough
>     about systemd and udev to know "proper" from "improper".
>
>     John
>
>     On Mon, Mar 19, 2018 at 11:01 PM Dengke Du
>     <dengke.du@windriver.com <mailto:dengke.du@windriver.com>> wrote:
>
>         Raspberry pi have two built-in UARTs, PL011 and mini UART
>
>         by default: /dev/ttyS0 refers to the mini UART, /dev/ttyAMA0
>         refers to the PL011
>
>         https://www.raspberrypi.org/documentation/configuration/uart.md
>
>         So I think the brcm43438 service should use the /dev/ttyAMA0.
>
>
>         On 2018年03月20日 10:41, Dengke Du wrote:
>>
>>         For rpi0-w bluetooth, before the commit:
>>
>>         https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-70e4910388c3702c52118d7acf7556e7
>>
>>         the brcm43438.service always failed, because it depends on
>>         /dev/ttyAMA0,after that commit, the 'udev-rules-rpi' added to
>>         the RDEPENDS for rpi0-w,we
>>
>>         can check it here:
>>
>>         https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-3b2568c620828b0ba653c1070041318aR52
>>
>>         for service brcm43438, but I still use the /dev/ttyAMA0 in
>>         it, not /dev/serial1(when I use /dev/serial1, the service
>>         failed), the service can start everytime correctly.
>>
>>
>>         On 2018年03月19日 02:10, r10kindsofpeople wrote:
>>>         Update:  I suspect this is not the proper way to do this,
>>>         but in case it provides useful information toward a better
>>>         solution...
>>>         1) systemctl disable brcm43438.service
>>>         2) modified 99-com.rules to include TAG+="systemd" and
>>>         ENV{SYSTEMD_WANTS}="device-brcm43438.service"
>>>         3) cp /lib/systemd/system/brcm43438.service
>>>         /etc/systemd/system/device-brcm43438.service
>>>         4) modified device-brcm43438.service to be as follows:
>>>         [Unit]
>>>         Description=Broadcom BCM43438 bluetooth HCI
>>>
>>>         [Service]
>>>         Type=simple
>>>         ExecStart=/usr/bin/hciattach -n /dev/serial1 bcm43xx 921600
>>>         noflow -
>>>         Restart=on-failure
>>>
>>>         note removal of Before, After, ConditionPath, Install
>>>         sections and addition of Restart=on-failure.  This last was
>>>         to cope with an intermittent timeout in hciattach.  Suppose
>>>         I should have tried increasing the timeout first.
>>>
>>>         This seems to have gotten me to the point of it starting up
>>>         at least 10 times successfully. Bottom line, in my opinion,
>>>         is that brcm43438.service is somehow running  before the
>>>         udev script can create the symbolic link for /dev/serial1 ->
>>>         /dev/ttyAMA0 despite the "After=dev-serial1.device" clause.
>>>
>>>         John
>>>
>>>
>>>         On Sat, Mar 17, 2018 at 12:32 PM r10kindsofpeople
>>>         <r10kindsofpeople@gmail.com
>>>         <mailto:r10kindsofpeople@gmail.com>> wrote:
>>>
>>>             Background:  I'm trying to bring up the pi zero w's
>>>             bluetooth using systemd. Started with rocko and then
>>>             moved to 'master' of meta-raspberry pi, sync'd about a
>>>             week ago after noticing that there were some recent
>>>             updates in this area.
>>>
>>>             There was an initial problem with /dev/serial1 not
>>>             showing up...I found udev-rules-rpi.bb
>>>             <http://udev-rules-rpi.bb>, added it to my layer, and
>>>             when it still didn't show up in my rootfs, I punted and
>>>             installed it in /etc/udev/rules.d by hand and now
>>>             /dev/serial1 shows up.  Given time, I can probably fix
>>>             the recipe on my own, so moving on.
>>>
>>>             But brcm43438.service still fails on boot.  Despite
>>>             having "After=dev-serial1.device" in the service Unit
>>>             section, it fails with:
>>>
>>>             Mar 17 16:21:13 raspberrypi0-wifi systemd[1]: Started
>>>             Broadcom BCM43438 bluetooth HCI.
>>>             Mar 17 16:21:14 raspberrypi0-wifi hciattach[105]: Can't
>>>             open serial port: No such file or directory
>>>             Mar 17 16:21:14 raspberrypi0-wifi hciattach[105]: Can't
>>>             initialize device: No such file or directory
>>>             Mar 17 16:21:14 raspberrypi0-wifi systemd[1]:
>>>             [[0;1;39mbrcm43438.service: Main process exited,
>>>             code=exited, status=1/FAILURE[[0m
>>>             Mar 17 16:21:14 raspberrypi0-wifi systemd[1]:
>>>             [[0;1;39mbrcm43438.service: Unit entered failed state.[[0m
>>>             Mar 17 16:21:14 raspberrypi0-wifi systemd[1]:
>>>             [[0;1;39mbrcm43438.service: Failed with result
>>>             'exit-code'.[[0m
>>>
>>>             If, after booting and ssh'ing into pi, I restart the
>>>             service, it starts successfully.
>>>
>>>             Any hints about what I might change to get the
>>>             brcm43438.service to start correctly the first time
>>>             (every time)?
>>>
>>>             John
>>>
>>>
>>>
>>
>>
>>
>


[-- Attachment #2: Type: text/html, Size: 15111 bytes --]