meta-raspberrypi systemd rpi0-w bluetooth startup

meta-raspberrypi systemd rpi0-w bluetooth startup

[r10kindsofpeople]

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

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, 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: 1853 bytes --]

Re: meta-raspberrypi systemd rpi0-w bluetooth startup

[r10kindsofpeople]

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

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> 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, 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: 3833 bytes --]

Re: meta-raspberrypi systemd rpi0-w bluetooth startup

[Dengke Du]

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

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: 6766 bytes --]

Re: meta-raspberrypi systemd rpi0-w bluetooth startup

[Dengke Du]

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

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: 7937 bytes --]

Re: meta-raspberrypi systemd rpi0-w bluetooth startup

[r10kindsofpeople]

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

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> 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> 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, 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: 9629 bytes --]

Re: meta-raspberrypi systemd rpi0-w bluetooth startup

[r10kindsofpeople]

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

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> 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>
> 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> 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, 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: 10810 bytes --]

Re: meta-raspberrypi systemd rpi0-w bluetooth startup

[Dengke Du]

[-- 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 --]