Return-path: Received: from mail-wi0-f180.google.com ([209.85.212.180]:35019 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752159AbbEQRhs (ORCPT ); Sun, 17 May 2015 13:37:48 -0400 Received: by wicmx19 with SMTP id mx19so52027992wic.0 for ; Sun, 17 May 2015 10:37:46 -0700 (PDT) Message-ID: <5558D1EA.8040905@gmail.com> (sfid-20150517_193751_734141_4FB50A79) Date: Sun, 17 May 2015 19:37:46 +0200 From: Arend van Spriel MIME-Version: 1.0 To: Hauke Mehrtens , Schmirr Wurst , linux-wireless , b43-dev Subject: Re: Fwd: Fwd: lspci not working References: <5557556C.2080107@lwfinger.net> <5557B396.9080300@gmail.com> <555894E7.3080600@hauke-m.de> <5558A6F1.6010303@gmail.com> <5558C6B2.7060105@gmail.com> <5558C82D.5020404@hauke-m.de> In-Reply-To: <5558C82D.5020404@hauke-m.de> Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: On 17-05-15 18:56, Hauke Mehrtens wrote: > On 05/17/2015 06:49 PM, Arend van Spriel wrote: >> >> >> On 17-05-15 16:48, Schmirr Wurst wrote: >>> ---------- Forwarded message ---------- >>> From: Schmirr Wurst >>> Date: 2015-05-17 16:47 GMT+02:00 >>> Subject: Re: Fwd: lspci not working >>> To: Arend van Spriel >>> >>> >>> 2015-05-17 16:34 GMT+02:00 Arend van Spriel : >>>> On 17-05-15 16:08, Schmirr Wurst wrote: >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Schmirr Wurst >>>>> Date: 2015-05-17 16:07 GMT+02:00 >>>>> Subject: Re: lspci not working >>>>> To: Hauke Mehrtens >>>>> >>>>> >>>>> 2015-05-17 15:17 GMT+02:00 Hauke Mehrtens : >>>>>> >>>>>> On 05/17/2015 03:00 PM, Schmirr Wurst wrote: >>>>>>> >>>>>>> 2015-05-17 14:57 GMT+02:00 Schmirr Wurst : >>>>>>>> >>>>>>>> I'm not familiar with inline answers and mailing list, tried to put >>>>>>>> some order in my answer + log file >>>>>>>> >>>>>>>> 2015-05-17 13:18 GMT+02:00 Rafał Miłecki : >>>>>>>>> >>>>>>>>> On 17 May 2015 at 12:23, Arend van Spriel >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On 05/17/15 02:21, Schmirr Wurst wrote: >>>>>>>>>>> >>>>>>>>>>> I tried as suggested to had a look at >>>>>>>>>>> /sys/bus/sdio/devices, but the only devices around there a 3 >>>>>>>>>>> mmc1:0001:1 to :3, I guess it is something else... >>>>>>>>>>> >>>>>>>>>>> I already try to install brcmfmac_sdio , with some tutorial >>>>>>>>>>> from the >>>>>>>>>>> internet, but it didn't work... >>>>>>>>>>> actually, I see under /sys/bus/sdio/drivers brcmfmac_sdio ... >>>>>>>>>>> >>>>>>>>>>> In that directory, I see a directory mmc1:0001:2 >>>>>>>>>>> under device I have 0xa94d >>>>>>>>>>> >>>>>>>>>>> I completly lost, maybe you understand that information, sorry.. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I do. The fact that you see a subdirectory mmc1:0001:2 in >>>>>>>>>> /sys/bus/sdio/drivers/brcmfmac_sdio means that the driver was >>>>>>>>>> probed >>>>>>>>>> for >>>>>>>>>> this device. Now would be a good time to share your (friends') >>>>>>>>>> kernel >>>>>>>>>> log, >>>>>>>>>> but my guess is you are either missing firmware or nvram data >>>>>>>>>> or both >>>>>>>>>> for >>>>>>>>>> this device. >>>>>>>> >>>>>>>> I ve attatched the kernel.log here >>>>>>>> https://drive.google.com/file/d/0B8gm4mLCCQAgMmNlVVFSYmNjOGs/view?usp=sharing >>>>>>>> >>>>>>>> In dmsg I see following linked with the brc driver : >>>>>>>> dmesg | grep brc >>>>>>>> [ 7.987661] brcmf_sdio_drivestrengthinit: No SDIO Drive strength >>>>>>>> init done for chip 43340 rev 2 pmurev 20 >>>>>>>> [ 7.993487] usbcore: registered new interface driver brcmfmac >>>>>>>> [ 7.996318] brcmfmac_sdio mmc1:0001:1: Direct firmware load for >>>>>>>> brcm/brcmfmac43340-sdio.bin failed with error -2 >>>>>>>> [ 9.011572] brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl >>>>>>>> 0x50 >>>>>>>> [ 10.037365] brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl >>>>>>>> 0x50 >>>>>>>>> >>>>>>>>> >>>>>>>>> It could also mean driver was loaded manually. So please also make >>>>>>>>> sure the friend uses kernel 4.0 or newer. >>>>>>>> >>>>>>>> Kernel : 4.0.0 #3 SMP PREEMPT Wed Apr 22 17:52:53 MSK 2015 >>>>>>>> Distro: >>>>>>>> Distributor ID: T100 Ubuntu 15.04 >>>>>>>> Description: Ubuntu 15.04 >>>>>>>> Release: 15.04 >>>>>>>> Codename: vivid >>>>>>>> I ve installed it from the magic stick here >>>>>>>> https://plus.google.com/communities/117853703024346186936 >>>>>> >>>>>> >>>>>> The driver complains about missing firmware and Ubuntu 15.04 does not >>>>>> contain it. >>>>>> >>>>>> Please place this file >>>>>> >>>>>> https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/plain/brcm/brcmfmac43340-sdio.bin >>>>>> >>>>>> >>>>>> to /lib/firmware/brcm/brcmfmac43340-sdio.bin >>>>>> >>>>>> Hauke >>>>> >>>>> Before that, the system was complaining about >>>>> brcm/brcmfmac43340-sdio.bin, and now about brcm/brcmfmac43340-sdio.txt >>>>> but errors are similar... >>>> >>>> >>>> I guess your system in jinxed because of the hostname you setup :-p >>>> >>>> Ok, more seriously now. This is the nvram data I mentioned earlier. This >>>> system may have that info stored in efi variable. You should be able >>>> to find >>>> it in /sys/firmware/efi/efivars/nvram-*. >>>> >>>> It may be necessary to run the following commands: >>>> >>>> # modprobe efivarfs >>>> # mount -t efivarfs efivarfs /sys/firmware/efi/efivars >>>> >>>> Regards, >>>> Arend >>>> >>> I cant be kind with manufacturer like broadcom and nvidia and those >>> that are builting in such hardware ;) >> >> You are talking to a broadcom employee (in disguise ;-) ). >> >>> cat /sys/firmware/efi/efivars/nvram-74b00bd9-805a-4d61-b51f-43268123d113 >>> What am I supposed to do with this ? >> >> You are kidding? I'll chew it for you: >> >> $ cp /sys/firmware/efi/efivars/nvram-74b00bd9* >> /lib/firmware/brcm/brcmfmac43340-sdio.txt > > Why can't the driver directly access this efi var? I haven't checked if > this is already done somewhere, but letting a user do this manually does > not seam nice. Hi Hauke, Well, we have been relying on firmware files and nvram being available under /lib/firmware. Not that we can not change that, but the manual copy is is a one time thing and only applicable for systems that ran Win8.1. I suppose there would be a way to get the efivar directly or have request_firmware api do it if it is considered firmware. Given that it is placed under /sys/firmware seems to imply that. Regards, Arend >> >> Regards, >> Arend >> >