[yocto] meta-raspberrypi systemd rpi0-w bluetooth startup

[r10kindsofpeople]

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 at 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 at 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 at 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
>>>
>>
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180320/6e661160/attachment.html>