Broadcom WLAN never shows up in kernel if Windows is not installed...

still_waiting_for_EOF · 2017-12-16 16:23:01

Hi!

I have a most peculiar problem, stay with me here.

For a school, I want to deploy Arch on their shittier-than-shitty Acer One 10 netbook/tablets since the school ictmanager couldn't be bothered to check if 150 potential laptops are able to boot using PXE (hint: no ethernet port)...

Anyhow, this Baytrail device turned into hard times even just to get postboot (32 bit EFI on x64 machine...)

Now, after having looked for hours and hours into the Broadcom drivers for this machine I finally found a working driver in the catatombs of Our Mighty Kernel: https://patchwork.kernel.org/patch/9791523/ Some awesome kernelwarrior called 'Hans de Goede' scraped together all the possible drivers for this broadcom device.

I added brcmfmac43430-sdio.txt.ap6210 as brcmfmac43430a0-sdio.txt to /lib/firmware/brcm and finally I had hopes for this utter malcreation: wifi was finally up and working.

Now for the actual problem: After repartitioning the buildin 'mmcblk' blockdevice, pacstrapping Arch unto it, ofcourse readding the justmentioned driver and a reboot, the laptop no longer sees the broadcom device.. No dmesg references, nothing. Reinserting brcmfmac didn't do anything either. Retried the (just now working) usb arch installation: no wifi either. I've tried all of the possible combinations of drivers in the link metioned above: nope.

Then after many more hours of fucking around up until the brink of complete delerium I reinstalled Windows unto the buildin 'mmcblk' and see if Windows could find the wlan. Indeed it did! So I try Arch again, having found more possible solutions to try, and fuck me wlan0 pops up in dmesg again.

So I install Arch again, and the problem returns: no more broadcom device. So I install windows again.. And wlan works again etc. etc.

I've tried this for 3 times now. The broadcom device only works if there is a Windows installation on the builtin memoryblock...

Here you can find the drivers I've used/tried and dmesg + lspci + lsusb logs: https://wolk.wopwop.cc/s/cRJ9IR5ButIBYeu
(working wlan dmesg + lspci + lsusb i will upload when windows finishes reinstalling)

WTF is going on here? Can anyone here shine his/hers light, if even the faintest, upon this problem?

It would be totally awesome if I could get this school addicted to Linux because right now they are hooked up to the bad stuff.

Anyhow, thanks!

slytux · 2017-12-20 02:44:44

Check if your wireless is disabled when windows shuts off. There is a software rkill switch similar to the hardware button some laptops have. Check if it blocked with

rfkill list

still_waiting_for_EOF · 2017-12-20 14:27:23

Yes! I thought of that too since I figured Windows was fucking something up so I tried that. Unfortunately, rfkill shows no devices.

I think I have worked it down to problems with the SDIO bus (on which the BCM43430 resides) because of the following discrepancy between the kernel log when wlan works and when it doesn't.

When it doesnt work:
$ dmesg | grep -i mmc

[ 0.130298] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xe0000000-0xe3ffffff] (base 0xe0000000)
[ 0.130327] PCI: MMCONFIG at [mem 0xe0000000-0xe3ffffff] reserved in E820
[ 0.256787] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-3f] only partially covers this bridge
[ 8.500267] mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
[ 8.523602] mmc1: SDHCI controller on ACPI [80860F14:01] using ADMA
[ 8.550123] mmc2: SDHCI controller on ACPI [80860F14:03] using ADMA
[ 8.635193] mmc0: new HS200 MMC card at address 0001
[ 9.150037] mmcblk0: mmc0:0001 M52532 29.1 GiB
[ 9.154854] mmcblk0boot0: mmc0:0001 M52532 partition 1 4.00 MiB
[ 9.159726] mmcblk0boot1: mmc0:0001 M52532 partition 2 4.00 MiB
[ 9.164281] mmcblk0rpmb: mmc0:0001 M52532 partition 3 4.00 MiB
[ 9.197097] mmcblk0: p1 p2 p3 p4

When WLAN works (and Windows is installed):
$ dmesg | grep -i mmc

[ 0.130306] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xe0000000-0xe3ffffff] (base 0xe0000000)
[ 0.130335] PCI: MMCONFIG at [mem 0xe0000000-0xe3ffffff] reserved in E820
[ 0.257256] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-3f] only partially covers this bridge
[ 8.123784] mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
[ 8.144082] mmc1: SDHCI controller on ACPI [80860F14:01] using ADMA
[ 8.172139] mmc2: SDHCI controller on ACPI [80860F14:03] using ADMA
[ 8.201957] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 8.209002] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 8.215749] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 8.222846] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 8.230368] mmc0: new HS200 MMC card at address 0001
[ 8.329248] mmc1: new high speed SDIO card at address 0001
[ 9.346549] mmcblk0: mmc0:0001 M52532 29.1 GiB
[ 9.366742] mmcblk0boot0: mmc0:0001 M52532 partition 1 4.00 MiB
[ 9.371447] mmcblk0boot1: mmc0:0001 M52532 partition 2 4.00 MiB
[ 9.376077] mmcblk0rpmb: mmc0:0001 M52532 partition 3 4.00 MiB
[ 9.408272] mmcblk0: p1 p2 p3 p4
[ 9.793524] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 9.799275] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 9.804992] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 9.815945] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)

The thing that makes it completely weird is that when I unpack a preconfigured Windows image over the mmcblk0 device, as in "dd if=/mnt/usb/win10.iso.xz | xz -T4 -d | dd of=/dev/mmcblk0 status=progress", about half way trough if I run "modprobe -r brcmfmac; modprobe brcmfmac" the bcm43430 is detected properly and I can immediately use wifi… Nothing showing detecting of an SDIO bus...

Since the SDIO uses the SD-card standard there must be some weird interaction going on. However if I dd zeros or random to mmcblk0 the bcm43430 is not detected…

I have tried unbinding/binding the "80860F14:01" (from dmesg above) device from the driver but this didn't do it.

I have also tried removing all files from the main ntfs partition of the Windows installation and wlan is again not detected, but only after a reboot! When I then make a 5g file with dd seeded by /dev/random I have had it working sometimes after a reboot. So it apears to me that the partitioning is not of isue here.

Anyone involved in Baytrail/SDIO development that can shed a light on this? I'll try contacting Arend van Spriel and/or Hans de Goede with this problem since they seem to pop up everywhere when baytrail, sdio or the bcm43430 are being discussed. I'll post any results back to this thread.

ewaller · 2017-12-20 16:01:00

Sounds to me like the computer is doing something completely brain dead -- I bet the pre-boot environment is looking at the file system for files that contain firmware for the Broadcom device and, if those files are found, is setting up the hardware prior to starting an OS. I've seen more stupid designs O_o

Edit: BTW, if you would please edit your post and change the quote tags to code tags...

Last edited by ewaller (2017-12-20 16:01:44)

Arch Linux

#1 2017-12-16 16:23:01

Broadcom WLAN never shows up in kernel if Windows is not installed...

#2 2017-12-20 02:44:44

Re: Broadcom WLAN never shows up in kernel if Windows is not installed...

#3 2017-12-20 14:27:23

Re: Broadcom WLAN never shows up in kernel if Windows is not installed...

#4 2017-12-20 16:01:00

Re: Broadcom WLAN never shows up in kernel if Windows is not installed...

Board footer