Closed wubi4292 closed 5 years ago
@wubi4292 That should not be the problem. May be the issue is you need to unblock the wifi? What do you get with rfkill list
?
I'm currently working on a newer kernel, but nevertheless my modules below.
BTW brcmfmac
is the wifi module which you have. So no worries there.
``` root@edison:~# uname -a Linux edison 4.20.0-rc3-edison-acpi-standard #1 SMP Sat Nov 24 15:11:12 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux root@edison:~# lsmod Module Size Used by ipt_MASQUERADE 20480 0 usb_f_mass_storage 53248 2 usb_f_eem 20480 2 u_ether 28672 1 usb_f_eem usb_f_serial 20480 2 u_serial 28672 1 usb_f_serial libcomposite 65536 14 usb_f_serial,usb_f_eem,usb_f_mass_storage iptable_nat 16384 0 nf_nat_ipv4 16384 2 ipt_MASQUERADE,iptable_nat nf_nat 36864 1 nf_nat_ipv4 spi_pxa2xx_platform 32768 0 intel_mrfld_pwrbtn 20480 0 extcon_intel_mrfld 16384 0 brcmfmac 278528 0 pwm_lpss_pci 16384 0 intel_mrfld_adc 16384 0 pwm_lpss 16384 1 pwm_lpss_pci brcmutil 20480 1 brcmfmac spi_pxa2xx_pci 16384 0 ti_ads7950 40960 0 hci_uart 49152 0 industrialio_triggered_buffer 16384 1 ti_ads7950 btbcm 16384 1 hci_uart kfifo_buf 16384 1 industrialio_triggered_buffer spidev 24576 0 intel_soc_pmic_mrfld 16384 0 mmc_block 45056 4 sdhci_pci 45056 0 cqhci 32768 1 sdhci_pci sdhci 57344 1 sdhci_pci led_class 20480 1 sdhci mmc_core 151552 5 sdhci,cqhci,mmc_block,brcmfmac,sdhci_pci ```
Hi Ferry, Thank you for your comments. I got below updates to you. Also, if your wifi is working in newer version, could you please post all files in /lib/firmware/brcm? I can replace my files.
++rfkill list: 1: phy1: wlan Soft blocked: no Hard blocked: no
++below is the response when I reload brcmfmac (I also updated wifi's firmware). root@edison:/lib/firmware/brcm# modprobe -v brcmfmac insmod /lib/modules/4.18.0-edison-no-acpi-standard/kernel/drivers/net/wireless/broadcom/brcm80211/brcmutil/brcmutil.ko insmod /lib/modules/4.18.0-edison-no-acpi-standard/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko root@edison:/lib/firmware/brcm# [ 170.121048] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip BCM43340/2 [ 170.349914] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip BCM43340/2 [ 170.358952] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 170.375763] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43340/2 wl0: Oct 23 2017 08:41:23 version 6.10.190.70 (r674464) FWID 01-98d71006
wifi has been working I think since 4.8. I have:
root@edison:~# journalctl -b | grep brcm
Nov 24 21:58:43 edison kernel: brcmfmac: F1 signature read @0x18000000=0x1602a94c
Nov 24 21:58:43 edison kernel: brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip BCM43340/2
Nov 24 21:58:43 edison kernel: brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip BCM43340/2
Nov 24 21:58:43 edison kernel: brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43340-sdio.clm_blob failed with error -2
Nov 24 21:58:43 edison kernel: brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
Nov 24 21:58:43 edison kernel: brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43340/2 wl0: Feb 20 2015 12:54:17 version 6.10.190.55 (r536162) FWID 01-6cb01dcc
Look like you have a newer firmware. That's weird, how can that be?
I found my 4.18 system missing some modules by comparing with your modules in 4.2.0, such as usb related modules, which might cause this wifi abnormal. Not sure if you can release a new branch so I can build a new image.
No, this is the wrong direction. As I said I am working on a newer kernel 4.20. The config for that kernel enables stuff that are not needed or not even working on the 4.18 kernel. One such thing is the usb, which on 4.20 supports otg (meaning the usb port can be either host or device) and can be a gadget. This will not work on 4.18 due to missing patches, while trying to enable it will break the usb driver which we need to force into host mode. This explains some of the additional modules. Also, I am fixing wifi hostapd, which might explain other modules.
Let try to focus on the issue2. 1 the issue title mentions "sumo64-acpi", however in your kernel first post you have "/lib/modules/4.18.0-edison-acpi-standard" and in the 2nd "insmod /lib/modules/4.18.0-edison-no-acpi-standard/kernel/drivers/net/wireless/broadcom/brcm80211/brcmutil/brcmutil.ko".
2 your rfkill shows you have only wifi active, no bluetooth present. For the acpi enabled kernel there should also be bluetooth as it is automatically powered. This also suggests you are running the non-acpi kernel. With the non-acpi kernel you need to systemctl start bluetooth_attach
to power the bluetooth after which it will appear on the rfkill list.
So it looks something is getting mixed up (acpi vs. no-acpi). Did you read the instructions here: Intel Edison Image Builder. Following these instructions without doubt (as it works for me and others and Yocto gives a quite good reproducible result) you can build an image (u-boot + kernel + rootfs) that works.
Maybe it would be good to start with deciding what you need, acpi enabled or mraa working? 32bit or 64 bit?
issue 1: Yes, I did change to sumo32 for the second module list. Please find module list for sumo64-acpi below. issue 2: Yes, rfkill list is also run under sumo32. Please find module list for sumo64-acpi below.
I am a application developer. I wish to use x64 OS to information hub with .Net Core, Node JS, and Mongodb. Therefore, a working 64bit OS(with wifi and uart) is the priority for me. Below is my list and installation procedure. Due to error message is about RF radio channel, it should be a configuration issue. As you side the image is working, can you help to check : (1) is my procedure ok? (2) is this possible to have any old configuration file after flash the new image?
Thank you very much
***sumo64 acpi building procedure used
***rfkill list under sumo64-acpi root@edison:~# rfkill list 0: hci0: bluetooth Soft blocked: no Hard blocked: no 1: phy0: wlan Soft blocked: no Hard blocked: no
****Loading brcmfmac related messages root@edison~# modprobe -v -r brcmfmac rmmod brcmfmac [ 1446.152414] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do. [ 1446.160750] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do. [ 1446.171173] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do. [ 1446.178528] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-5)
root@edison~# modprobe -v brcmfmac insmod /lib/modules/4.18.0-edison-acpi-standard/kernel/drivers/net/wireless/broadcom/brcm80211/brcmutil/brcmutil.ko insmod /lib/modules/4.18.0-edison-acpi-standard/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko root@edison:~# [ 1533.352346] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip BCM43340/2 [ 1533.578608] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip BCM43340/2 [ 1533.587795] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 1533.602579] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43340/2 wl0: Feb 20 2015 12:54:17 version 6.10.190.55 (r536162) FWID 01-6cb01dcc
1) AFAICT there is nothing wrong with your process or image result. It is not necessary to modprobe the wifi drivers, they should already be loaded. 2) Flashall overwrites kernel + rootfs. I forgot if it also flashes U-Boot? Can you check? What version do you see on the terminal when booting? I use either external sd card, usb disk or flash internal mmc using Flash Tool Lite. But /home/root stays intact. However, there are no configuration files there IIRC.
Instructions for getting a wifi connection are here: Current state/Networking functions.
This should be all that is needed. If not, let's see what is going wrong there.
As I understand you are not needing mraa for now. In that case i recommend to use the acpi version, as Andy Shevchenko will only be developing further on that kernel and U-Boot. Non-acpi (is working) but has reached end of the line. Between 32bit and 64bit: there seems to be not much advantage for the 64bit. The speed gains seem to be easily lost due to penalties the SLM (silvermont) Atom processor has when executing long instructions. Moreover, I have found that the HSU (uart) looses chars on 64b when the buad rate > 500kb/s, this does not happen on 32b. One day I will find this bug and solve it...
Very happy to let you know that my wifi is working now. I did not notice that this image is using connman, which excluded the wifi access from iwconfig and configure_edison --wifi.
Thank you for the sharing of 64bit OS on Edison. I just share my reasons to use x86_64 OS. (1) Microsoft .Net core would only support x86_64 in Linux environment, which would reuse many c# codes for IOT hub. I will start to test it and compare the performance on Arm32. (2) As new versions of Mongodb only support x86_64 linux (SSL enabled), it will be really interesting to see the performance of Mongodb in Edison as well.
**uboot version U-Boot 2018.09 (Nov 22 2018 - 09:24:06 +0000)
That is very good to know that it works now. And you are right: those are very good reasons to use 64bit.
Note: the original image also used connman. But that old version of connman has limitations that were worked around by using hostapd and other tricks.
Actually I am working on configure_edison as that is not working right now. I hope to have it fixed with kernel 4.20 in a few weeks from now. That will give us ethernet over usb gadget + wifi tethering, ethernet over usb adapter (selected types) + wifi tethering, oobe (out-of-the-box-experience) = configure_edison + configure using web interface.
Other plans: use the new kernel subsystem to blink the LED, move to Yocto Thud, fix MRAA. Merge my docs folder from master to edison-fw/master.
If you have improvements, suggestions to code or docs (docs are in htot/meta-intel-edison/master and github uses jekyl to generate automatic github.io pages), PR's very welcome!
Hi Ferry, I am looking forward to see your new work on 4.20. With current build on 4.18, I found apt-get is not working due to missing source list. Also, when a source list is inserted, I cannot install the key for that source due to dependency issue. therefore, not sure if you have any plan on apt-get? Also, as you mentioned out-of-box-experience, I want to check if a minimum environment (dependency), which is similar to ubuntu, can be build out of box?
thank you!!
I haven't tried apt-get, I need to setup the deb server first. But that would be useful. Later. For now I copy over the debs and use dpkg. Did you start a server on your debs directory, or did you want to add Ubuntu repo (that won't work)?
Oobe is a recipe use for initial configuration. Your minimal environment, would it contain more or less packages than it does now. What would you like to see changed?
@wubi4292, you can't use any Debian (or any existing at all to that matter) package repos as those are built for different distros. The way it works in Yocto is that when the distro is built (together with packages, called package stream), one has to setup a server to share all the packages, only then you can use that as a source. Getting packages from random repos on the Internet will get your Edison in trouble.
@wubi4292 Yes, sometimes you get lucky when a simple package has no or not many dependencies. In your case you are probably missing an .so here or there. You can use ldd
to try to hunt that down. But for complex stuff that will turn our to be a lot of work, if at all successful
To elaborate further on @alext-mkrs remark: like with debian you would prefer to turn to a debian repo to get a package, with yocto you would turn to https://layers.openembedded.org/layerindex/branch/sumo/recipes/. Not to get a package, but to get a recipe to build the package. Sometimes you will find the recipe in a layer you are not yet using. In case of .Net Core 2 I found https://layers.openembedded.org/layerindex/recipe/84704/ in meta-iot-cloud for sumo. If you need something newer, master of meta-aspnet has dotnet-source-build 2.1.2.
So, you would add the layer to bblayers.conf, and the recipe name to your image.bb, yocto will build and add the package (and its dependencies) for you.
If you want to tweak the build, sometimes you can just copy over the recipe and edit it. Other times it makes more sense to extend the existing recipe using .bbappend files.
hi, it seems that BCM43340 wifi module is not loaded and missing. not sure if it is a building error or something I missed. Thank you very much!
Peter
**iwconfig shows below: sit0 no wireless extensions. lo no wireless extensions. wlan0 no wireless extensions. *****current loaded modules Module Size Used by spi_pxa2xx_platform 28672 0 pwm_lpss_pci 16384 0 pwm_lpss 16384 1 pwm_lpss_pci spi_pxa2xx_pci 16384 0 brcmfmac 274432 0 brcmutil 16384 1 brcmfmac iptable_nat 16384 0 nf_nat_ipv4 16384 1 iptable_nat hci_uart 49152 0 nf_nat 32768 1 nf_nat_ipv4 btbcm 16384 1 hci_uart ti_ads7950 36864 0 industrialio_triggered_buffer 16384 1 ti_ads7950 kfifo_buf 16384 1 industrialio_triggered_buffer spidev 20480 0 mmc_block 40960 3 sdhci_pci 36864 0 cqhci 28672 1 sdhci_pci sdhci 53248 1 sdhci_pci led_class 16384 1 sdhci mmc_core 147456 5 sdhci,cqhci,mmc_block,brcmfmac,sdhci_pci
***/lib/modules/4.18.0-edison-acpi-standard drwxr-xr-x 5 root root 4096 Nov 22 2018 kernel -rw-r--r-- 1 root root 67710 Nov 22 2018 modules.alias -rw-r--r-- 1 root root 67465 Nov 22 2018 modules.alias.bin -rw-r--r-- 1 root root 14141 Nov 22 2018 modules.builtin -rw-r--r-- 1 root root 17093 Nov 22 2018 modules.builtin.bin -rw-r--r-- 1 root root 3778 Nov 22 2018 modules.dep -rw-r--r-- 1 root root 6320 Nov 22 2018 modules.dep.bin -rw-r--r-- 1 root root 0 Nov 22 2018 modules.devname -rw-r--r-- 1 root root 2190 Nov 22 2018 modules.order -rw-r--r-- 1 root root 55 Nov 22 2018 modules.softdep -rw-r--r-- 1 root root 10135 Nov 22 2018 modules.symbols -rw-r--r-- 1 root root 12927 Nov 22 2018 modules.symbols.bin