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
<r10kindsofpeo...@gmail.com <mailto:r10kindsofpeo...@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...@windriver.com <mailto:dengke...@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
<r10kindsofpeo...@gmail.com
<mailto:r10kindsofpeo...@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
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
