Switching from rocko to master on rpi-0w breaks wifi

[keeslinp]

Description

Changing from latest on rocko to latest on master makes it so that the wlan0 interface doesn't show up anymore.

Steps to reproduce the issue:

1. pull latest master
2. build rpi-hwup-image
3. run ip link or anything that lists the interfaces, only l0 shows up

Describe the results you received:
wlan0 isn't connected

Describe the results you expected:
wlan0 should be present.

Additional information you deem important (e.g. issue happens only occasionally):

Switching back to rocko without changing anything makes it work again.

Additional details (revisions used, host distro, etc.):
I also tried updating poky to master and it didn't improve anything.
The reason I'm updating to master is to make use of #183

[hhromic]

hi @keeslinp ,
Using a clean image built from rocko also didn't bring Wifi for me on my RPI0W. The same for master.
However to bring WiFi, you need to add this line to your local.conf file:

IMAGE_INSTALL_append = " linux-firmware-bcm43430 wpa-supplicant"

It adds the missing firmware and the wpa-supplicant package to the built image. Then, after booting, I just need to customise /etc/wpa_supplicant.conf with my network and do ifup wlan0. All works.

I'm not sure if this is by design (to keep the image minimal) or is a bug. Any comments @agherzan ?
Cheers!

[agherzan]

That is correct, HWUP image doesn't install the linux firmware for the wifi device. The part that I am confused now about is the wpa. Isn't only the linux firmware sufficient?

[keeslinp]

Sorry, I should have included my local.conf. I already have both of those included. Here is my entire local.conf

IMAGE_FEATURES += " debug-tweaks"
CONF_VERSION = "1"
CORE_IMAGE_EXTRA_INSTALL += "openssh rsync sensorhub sensorhub-updater"
IMAGE_INSTALL_append += "nodejs nodejs-npm bluez5 networkmanager config systemd"
IMAGE_INSTALL_append += " crda i2c-tools hostapd linux-firmware-bcm43430 kernel-modules linux-firmware-ralink linux-firmware-rtl8192ce linux-firmware-rtl8192cu linux-firmware-rtl8192su wireless-tools dhcp-client iw wpa-supplicant"
DISTRO_FEATURES_append += " bluez5 bluetooth wifi systemd"
INHERIT += "rm_work"
MACHINE = "raspberrypi0-wifi"
TMPDIR = "/workdir/tmp"

I'm honestly not super sure what some of those firmware packages being installed are, so those could maybe be problematic.

[hhromic]

@agherzan : to bring the Wifi device itself, the linux firmware is sufficient. However, to connect it to something you need a supplicant such as wpa supplicant. I think another alternative is networkmanager. This should be further selected by the user. So I think the only requirement to bring the radio device itself up is to include the linux firmware package. If you need a supplicant you also need to add wpa-supplicant or another alternative.

Is using IMAGE_INSTALL_append the correct method to add the linux firmware package? or is there a better practice for this?

@keeslinp : it looks like you should be using IMAGE_INSTALL_append = " package1 package2 package3" instead of using +=. Also you must use a leading space before the first package. Check carefully and try again.

I just built a test image using rocko with the suggestion I made and works fine.

[keeslinp]

I'll give that a try. Just to clarify, it does work perfectly fine on rocko. It is master that is problematic.

[hhromic]

Oh I see. I will try master now then.
But try that of using = instead of += and a leading space before the first package for each _append line you have.

[keeslinp]

I tried that and it didn't work :/. Here is my new local.conf

IMAGE_FEATURES += " debug-tweaks"
CONF_VERSION = "1"
CORE_IMAGE_EXTRA_INSTALL += "openssh rsync sensorhub sensorhub-updater"
IMAGE_INSTALL_append = " nodejs nodejs-npm bluez5 networkmanager config systemd crda i2c-tools hostapd linux-firmware-bcm43430 kernel-modules linux-firmware-ralink linux-firmware-rtl8192ce linux-firmware-rtl8192cu linux-firmware-rtl8192su wireless-tools dhcp-client iw wpa-supplicant"
DISTRO_FEATURES_append = " bluez5 bluetooth wifi systemd"
INHERIT += "rm_work"
MACHINE = "raspberrypi0-wifi"
TMPDIR = "/workdir/tmp"

Would it be worthwhile to try clearing my cache and doing a fresh build?

[mirzak]

Firmware is actually added in the machine configuration file with MACHINE_EXTRA_RRECOMMENDS

See https://github.com/agherzan/meta-raspberrypi/blob/master/conf/machine/raspberrypi0-wifi.conf#L9

Do not know why it would work on rocko and not in master because the configuration is present in booth

Try:

bitbake <image> -e | grep ^MACHINE_EXTRA_RRECOMMENDS

To check if it is set correctly, might be something removing or clearing the variable.

[hhromic]

@keeslinp : maybe is worth a try. Disclaimer: I'm very new to Yocto and no expert at all =). I'm currently having trouble trying to create an image using master, something changed since yesterday and I can't add the openembedded layer anymore (failing with a parsing error on base_conditional).

@mirzak : I also noticed that configuration. I think it just declares that the rpi-based machines have the firmware but does not install it into the image without IMAGE_INSTALL_append explicitly. I understood @agherzan just confirmed this as an intended behaviour (to not install firmware in the output image by default).

[keeslinp]

@mirzak here is the output MACHINE_EXTRA_RRECOMMENDS=" kernel-modules udev-rules-rpi linux-firmware-bcm43430"

@hhromic I'll probably give that a try when I take off tonight so that I can leave it running overnight (clean builds take a while)

[mirzak]

From Yocto docs

"A list of machine-specific packages to install as part of the image being built that are not essential for booting the machine. The image being built has no build dependencies on the packages in this list."

What actually decides if it is installed is if the image being built includes "packagroup-base" where the MACHINE_EXTRA_RRECOMMENDS are expanded, so basically if the image inherits from "core-image.bbclass" it should be installed.

[hhromic]

thanks for that @mirzak ,
however the firmware is not being included when using the rpi-hwup-image. I quickly checked and it seems to include core-image-minimal.bb which in turns inherit from core-image.bbclass. But contrary to what you suggest, it is not installing the firmware in the final image.

I tested this with a completely clean build environment, just adding the required meta-openembedded layers and then meta-raspberrypi. The output image builds, but no linux firmware is added to it.

is this a bug then?

[mirzak]

Oki not a bug (at least not in Yocto/OE-core).

Looked in to it a bit more.

core-image-minimal.bb", even though it inherits from core-image.bbclass it sets IMAGE_INSTALL and not appending to it, which overwrites anything that core-image has added to it basically.

Even the Yocto docs mentions this (if you read it all :))

A list of machine-specific packages to install as part of the image being built that are not essential for booting the machine. The image being built has no build dependency on this list of packages.

This variable affects only images based on packagegroup-base, which does not include the core-image-minimal or core-image-full-cmdline images.

So it depends on what the intentions of the rpi-hwup-image is, to decide if this is a bug or not.

One way to make sure it is included by default is to use the

MACHINE_ESSENTIAL_EXTRA_RDEPENDS

variable instead of the

 MACHINE_EXTRA_RRECOMMENDS

in the machine configuration files or just change the "rpi-hwup-image" to inherit directly from core-imageand not from core-image-minimal.

[hhromic]

interesting, @mirzak .
I guess this is a matter to think about for the maintainers of the layer then (@agherzan ).
As an end-user, I would expect rpi-hwup-image to bring all available machine hardware up, including the wifi radio, and perhaps the bluetooth as well.
Technically speaking, the firmware is the only thing needed for the radio hardware. Then is up to me as the user to further add the supplicant of my choice.
So I would vote to make the firmware included by default.

[mirzak]

I would agree with you @hhromic

[hhromic]

Hi guys,
I can confirm that wifi does not come up in the master branch and it does in rocko. The problem is that the file brcmfmac43430-sdio.bin is not copied into the /lib/firmware/brcm directory in the built image and only the brcmfmac43430-sdio.txt file is copied. If you manually copy the binary file to the built image, the rpi0w brings the Wifi interface just fine.

In rocko this works fine. I suspect the fail-safe conditional done in the recipe is not working anymore (maybe an upstream change of the firmware binary?). There are no warnings raised during the build. Seems @agherzan was working on recent commits of the recipe and maybe can spot the problem faster than me.

I will try to debug it anyway and provide feedback or a PR accordingly.

@keeslinp : if you want your image built using master to work, no need to rebuild. Just copy the binary file (.bin) alongside the txt file (.txt) in the built image's /lib/firmware/brcm folder and it will work.

[hhromic]

Hi all again.
I think I pin-pointed the problem now. The commit 61c2a96 introduced an rpi-specific condition for the linux-firmware. However, this block:

FILES_${PN}-bcm43430_rpi += " \
    ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \
"

Is not adding the brcmfmac43430-sdio.bin file in the final package. If I remove the condition _rpi it works fine again. Also, if I keep the condition but I add the binary file explicitly, like this:

FILES_${PN}-bcm43430_rpi += " \
    ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.bin \
    ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \
"

it works too. I'm not sure what would be the correct solution. The _rpi condition should be kept as this is a customisation only necessary for rpi devices. But FILES_${PN}-bcm43430 should contain the binary file already as it has without the _rpi conditional.

Perhaps BitBake is parsing this in a way we are not considering?

Also, if we mirror this block:

SRC_URI_append_rpi = " \
    file://brcmfmac43430-sdio.bin \
    file://brcmfmac43430-sdio.txt \
"

We perhaps should keep both files in FILES_${PN}-bcm43430 as well.

What do you suggest @kraj , @agherzan , @mirzak , @martingkelly (original commit author) ? I can create a PR according to your comments and we can merge it. This will fix bringing up Wifi (and potentially bluetooth) in master.

[kraj]

FILES_${PN}-bcm43430_rpi += " \
    ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.bin \
    ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \
"

seems to be correct.

[martingkelly]

@hhromic could you post the output of bitbake -e linux-firmware ? We can check SRC_URI and the _rpi logic. Perhaps _rpi isn't set for rpi0-wifi?

If you can't run bitbake because of the base_conditional issue, it's a known bug fixed by commit 99aa19ff53922b61dee0c8b63ee7f664f90e9a91 in meta-openembedded (which is in master now).

[hhromic]

hi @martingkelly, I already sorted out the base_conditional issue, as you say I just pulled the latest commits and all is fine, thanks for the suggestion!.

Regarding the firmware issue, after your comments I did the following tests:

(1) Recipe as-is from the master branch.

In Recipe:

FILES_${PN}-bcm43430_rpi += " \
    ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \
"

Output:

$ bitbake -e linux-firmware | grep ^FILES_linux-firmware-bcm43430
FILES_linux-firmware-bcm43430="      /lib/firmware/brcm/brcmfmac43430-sdio.txt "
FILES_linux-firmware-bcm43430_rpi="      /lib/firmware/brcm/brcmfmac43430-sdio.txt "

(2) Recipe modified to include the binary file.

In Recipe:

FILES_${PN}-bcm43430_rpi += " \
    ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.bin \
    ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \
"

Output:

$ bitbake -e linux-firmware | grep ^FILES_linux-firmware-bcm43430
FILES_linux-firmware-bcm43430="      /lib/firmware/brcm/brcmfmac43430-sdio.bin     /lib/firmware/brcm/brcmfmac43430-sdio.txt "
FILES_linux-firmware-bcm43430_rpi="      /lib/firmware/brcm/brcmfmac43430-sdio.bin     /lib/firmware/brcm/brcmfmac43430-sdio.txt "

(3) Recipe modified to not add _rpi conditional.

In Recipe:

FILES_${PN}-bcm43430 += " \
    ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \
"

Output:

$ bitbake -e linux-firmware | grep ^FILES_linux-firmware-bcm43430
FILES_linux-firmware-bcm43430="   /lib/firmware/brcm/brcmfmac43430-sdio.bin       /lib/firmware/brcm/brcmfmac43430-sdio.txt "

(4) Recipe modified to use _append instead of +=, like is done for SRC_URI.

In Recipe:

FILES_${PN}-bcm43430_append_rpi = " \
    ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \
"

Output:

$ bitbake -e linux-firmware | grep ^FILES_linux-firmware-bcm43430
FILES_linux-firmware-bcm43430="   /lib/firmware/brcm/brcmfmac43430-sdio.bin      /lib/firmware/brcm/brcmfmac43430-sdio.txt "

This last result is what I think is the expected and proper solution. The first and second tests create an additional FILES_linux-firmware-bcm43430_rpi that I don't think should be there, as that should be a conditional assignment. However the fourth test correctly append the extra NVRAM text file to the existing binary firmware, conditioned to _rpi, very similar to SRC_URI is handled.

If you agree with this behaviour and solution, I can create a PR to fix it. Thanks a million for your help!

[martingkelly]

I see your test results and am fine with your proposal if it works. I am, however, confused. The linux-firmware recipe already includes:

FILES_${PN}-bcm43430 = " \
  ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.bin \
"

I'm not sure why adding the bin file is required since it should already be present.

[kraj]

Is should be _append_rpi instead of _rpi +=
Since he latter overwrites any prior value that’s what you are seeing

[martingkelly]

@kraj why does += overwrite any prior value? Doesn't that break its purpose?

[kraj]

Its the override that’s causing it with append that gets addresses

[keeslinp]

@hhromic Your option 4 worked like a charm for me :). I had looked into that commit but I couldn't make heads or tails of it, yocto configs are witchcraft 80% of the time for me, I'm glad you could figure it out!

[keeslinp]

Maybe I spoke too soon, my bluetooth isn't working anymore. hciconfig isn't returning anything. Also, I'm getting an error in journalctl for hciattach:

Can't open serial port: No such file or directory
Can't initialize device: No such file or directory

Is this related to this issue or should I make a different ticket?

[hhromic]

@martingkelly: in my last proposal (test 4) I'm not adding anymore the binary file because using _append properly appends the text NVRAM file to the list keeping the binary file from the orginal recipe.
@kraj : thanks for the confirmation that using _append is the correct solution. I will prepare a PR with this fix so it can be merged.

@keeslinp : I'm happy the solution number four worked for you. This is the correct solution for the firmware missing problem.
Regarding your new bluetooth problem, it might or might not be related. I can help you debug this in the coming days.
The First question I have: did the bluetooth come up fine before applying option 4? in other words, when the firmware was not included bluetooth was working?
Let first make sure Wifi is fixed and close this issue, then we can open a new issue to diagnose the bluetooth radio. I haven't tried it on my own so I'm not sure (yet) what could be wrong.
Cheers!

[keeslinp]

@hhromic yes, when I tried master the first time the bluetooth worked fine but the wifi did not. Now, the opposite is true after applying option 4

[hhromic]

@keeslinp , that is very weird indeed. Adding the firmware shouldn't nullify bluetooth.
I was checking my image and by default it doesn't come with hciattach. This means you are adding it into your local config. Also looks like you are using systemd. Can you share your current local.conf file? Perhaps there is something else that is interfering.
Before making the PR for the linux-firmware I would like to confirm it doesn't interfere with bluetooth as you suggest.
I'm going to build another test image for this purpose, that will take a while as you know.

[keeslinp]

I posted it a little further up in this thread. When I get back to work on Monday I'll check again to make such I'm doing everything right.

…

On Sat, Feb 3, 2018, 4:24 AM Hugo Hromic ***@***.***> wrote: @keeslinp <https://github.com/keeslinp> , that is very weird indeed. Adding the firmware shouldn't nullify bluetooth. I was checking my image and by default it doesn't come with hciattach. This means you are adding it into your local config. Can you share your current local.conf file? Perhaps there is something else that is interfering. Before making the PR for the linux-firmware I would like to confirm it doesn't interfere with bluetooth as you suggest. I'm going to build another test image for this purpose, that will take a while as you know. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#184 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC6-bIVZSVbI_EJPRPqJLeHyOb58CRxGks5tREHlgaJpZM4RuYXr> .

[hhromic]

Hi @keeslinp , try to add udev-rules-rpi into your IMAGE_INSTALL_append and see if it works.
This package adds rules for udev to create the serial0 and serial1 devices that hciattach is trying to use. I checked and, similar to the firmware, this package is not installed by default.
Let me know if this works (together with working Wifi too).

[hhromic]

Hi again @keeslinp , I just tested an image using:

MACHINE = "raspberrypi0-wifi"
IMAGE_INSTALL_append = " bluez5 udev-rules-rpi linux-firmware-bcm43430 wpa-supplicant"

And I can confirm I get bluetooth and Wifi working both fine at the same time. Of course this image is minimal, so you need to attach the HCI manually:

/usr/bin/hciattach /dev/serial1 bcm43xx 921600 noflow -

In your systemd configuration, the bluez package comes with a service to do this operation automatically. After that, the BT device is correctly initialised and you can discover devices:

bluetoothctl
[bluetooth]# power on
[bluetooth]# scan on

So BT is not affected by the Wifi firmware fix. I'm going to issue a PR soon.
@keeslinp : let us know if you could get it working !

[agherzan]

I'm OK in starting to include the firmware as part of machine essential - sounds like there are many people confused by the current behavior. If anyone is interested, please push a patch.

[kraj]

I agree @agherzan for rpi3 especially, where wifi/bt is on board

[agherzan]

Yes. For RPI3 and RPI0wifi.

[keeslinp]

@hhromic That did the trick :).

Can anyone think of a reason that my bluetooth mac address would change between branches? That seems to be what I am experiencing. I mean, it's definitely not the end of the world as long as it is consistent between reboots, but just seems a little odd.

[hhromic]

Hi all,

I know I advocated for the inclusion of the firmware as default, however after thinking more about it (and learning more about Yocto too), I now think that the way it is done currently is actually the more correct approach.

1. According to Yocto documentation, the MACHINE_EXTRA_RRECOMMENDS variable (current method) is for packages that are not required for the machine to boot (but desired on a more complete image), and the MACHINE_ESSENTIAL_EXTRA_* variables (proposed method) are for packages that are strictly necessary to boot. In the case of the RPI, this firmware is not strictly necessary to boot.
2. For the case of Bluetooth, the dependency package is bluez5 which in turn carries a lot of other packages, enlarging the basic image. Again, packages that are not strictly necessary to boot.
3. Yocto is designed for users to extend base images with their own more complete images. In this paradigm, the current approach of using MACHINE_EXTRA_RRECOMMENDS would include the firmware for those users, as expected.

We should always take the position of "providing the bare minimum functional building block" and then users to extend the image/layer with their own requirements. For example, Wifi/BT are not always wanted by every user. I believe is best to ask users to add what they want than to ask users to remove what they don't.

With all that, I strongly believe that the correct thing to do is to better document these things (enable Wifi, enable BT) instead of bloating the base image by default. I can volunteer to update the current documentation to add sections to clarify how to enable those extra machine features.

If you agree, please let me know if modifying the documentation folder in this repository is all is needed to update the ReadTheDocs documentation.

---

@keeslinp : it might be that the firmware for BT (the .hcd file) is different. Or the way the MAC address is initialised is different. I don't see any harm on this and should be consistent across reboots of the same branch.

[agherzan]

I know this. The problem is that many new users get into this and not knowing this nuance they will obviously think of it as an issue. If we want to stick to the rule, what we can do is include MACHINE_EXTRA_RRECOMMENDS in our images. That would keep everyone happy.

[hhromic]

Exactly, hence we need to inform/document better to the new users.
But I got confused with your message. Using MACHINE_EXTRA_RRECOMMENDS is already the way is done in the layer:

meta-raspberrypi/conf/machine/raspberrypi0-wifi.conf

Line 9 in a2ba56f

MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-bcm43430"

And this is not including the firmware in the basic hwup images (as desired).

Then, we shouldn't touch the current image config (keeping the behaviour as it is) and just document that users must include the firmware (and BT packages) explicitly in their conf/local.conf by appending to IMAGE_INSTALL ?

[agherzan]

No. What I mean is having hwup include it by default. See here.

[mirzak]

Then, we shouldn't touch the current image config (keeping the behaviour as it is) and just document that users must include the firmware (and BT packages) explicitly in their conf/local.conf by appending to IMAGE_INSTALL ?

If they are using the rpi-hwup-image.

Other images will probably include the firmware, e.g. core-image-base which has a pretty good description.

"SUMMARY = "A console-only image that fully supports the target device
hardware.""

And I would agree that we should instead just document:

• rpi-hwup-image - just for booting
• core-image-base - full hardware support (or create a image based on core-image-base )

[mirzak]

Also the problem we have today is that all the "rpi" images inherit from rpi-hwup-image, so none of them install the firmware for WiFi.

Suggestion:

• Remove all the images we have today, beside rpi-test-image
• Move "kernel-modules to MACHINE_EXTRA_RRECOMMENDS
• Change rpi-test-image to inherit from core-image-base, and set SPLASH to raspberrypi (this could also include a SSH server)

If someone wants a "hwup" image they can use core-image-minimal

Edit: This way we will hold only ONE image in meta-raspberrypi that is good to for testing out RPi boards

[hhromic]

Hi all.
I've been reading more about all this and I completely agree with @mirzak here. Definitively we should be using the standard Poky images (core-image-minimal, core-image-base, etc.) instead of custom images made for the same purpose.

The whole idea of Yocto is that the same recipes adapt depending on the layers being used. So a core-image-minimal should produce a suitable image for your board depending on if we use meta-raspberrypi or meta-otherboard.

I just tried using these standard images and indeed core-image-base successfully adds the Wifi firmware and the BT components out of the box, while core-image-minimal just produces a small image to boot, as documented. If a user wishes for absolute control, he/she can start with the minimal image and cherry-pick components such as the Wifi firmware.

I totally support the proposal of @mirzak to clean-up the redundant images (such as rpi-hwup-image and use the standard Yocto ones. With this, we should leave the current machine configurations intact (and adding the suggestion from @mirzak about kernel-modules etc).

Question: it is possible for a time to leave rpi-hwup-image available but gracefully failing to build with a message that this image is deprecated? This would help with migrating users to the correct workflow.

If everyone agrees on this, how can we implement this change? I can help but I'm not an expert on Yocto, hence there could be things I might not be considering.

Edit: and, of course, document all this properly for users to be clear on how to use the layer.

[kraj]

you could turn rpi-hwup-image.bb to have just

require meta/recipes-core/images/core-image-base.bb

[hhromic]

True, but that would not instruct users that this is not the correct way and that they should be using core-image-base/minimal directly instead.
Also vanishing the image without notice would leave users puzzled why their images no longer build.

I noticed that kernel-modules is already in MACHINE_EXTRA_RRECOMMENDS and SPLASH is already set, both in conf/machine/include/rpi-base.inc, so the transition should be very smooth :).

Edit: oh and I strongly suggest we add information about the linux-firmware for Wifi in the documentation, much like how overcloking is documented.