[yocto] meta-raspberrypi systemd rpi0-w bluetooth startup
Dengke Du
dengke.du at windriver.com
Mon Apr 2 20:04:03 PDT 2018
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 at gmail.com <mailto: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 <mailto: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
>>> <mailto: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
>>> <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
>>>
>>>
>>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180403/a3be9e31/attachment.html>
More information about the yocto
mailing list