As of today, 2015/3/16: WiFi status
I said WiFi is stable before, however, more tests show me it is not. Or I should say when the signal is good, no extra beacon loss/reassociation, WiFi seems stable. Otherwise, there is big chance (as below) that WiFi will hang.
Part 1) https://github.com/96boards/linux/issues/16
About issue: wl1271_sdio mmc2:0001:2: sdio write failed (-110)
in Debian when configured in /etc/network/interfaces.d/wlan0 and WiFi is up and connected when system booting, it is very easy to observe a WiFi hang. The reason of this lies in firmware cannot be waken up from ELP (Extreme Low Power) mode. Note: not every wakeup from ELP mode will fail, there are still unknown 'random' factors. So right, the issue is not rootcaused. But,
Workaround exists: disable ELP mode. Attached a new config file (please save it to board's /lib/firmware/ti-connectivity/ and rename it to wl18xx-conf.bin) which has ELP disabled.
Or you can do this before wlan0 up:
iw wlan0 set power_save off
echo 0> /sys/kernel/debug/ieee80211/phy0/wlcore/sleep_auth
ifconfig wlan0 up
There is another type of error which is easy to be reproduced when you run 'iw wlan0 disconnect' then run 'iw wlan0 scan' repeatedly. Two kinds of error messages but both point to a firmware-side timeout issue. They are:
a) wlcore: ERROR SW watchdog interrupt received!
That's a firmware watchdog timer interrupt and reported from FW to the host.
b) wlcore: Scan completed due to error.
That's a scan timeout error. By changing the timeout value from 30 seconds to longer does'n help. And again, here I didn't see any SDIO or wlcore driver side errors. The only thing noticeable is just a firmware side timeout.
1) check why firmware 'hangs'. Due to limited accessibility to pins on WL1835 module, this is not easy.
Can we get TI field engineers' help here? Anybody has any experience on similar issues?
2) check why the current wlcore recovery effort always fail. If this can help firmware out, it also helps.
I've noticed that the HDMI on the Hikey board only really activates
when the kernel boots.
Are there plans for the boot firmware (UEFI soon?) to interact with
the HDMI port (and USB keyboard)?
I was reading https://www.kernel.org/doc/Documentation/arm/uefi.txt
and it looks like I should have everything needed to get EFI stuff in
linux, but instead I get:
root@hikey:~# dmesg | grep -i efi
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: UEFI not found.
[ 0.079367] EFI services will not be available.
root@hikey:~# uname -a
Linux hikey 4.0.0-rc3 #19 SMP Sun Mar 15 10:57:36 CET 2015 aarch64 GNU/Linux
root@hikey:~# zcat /proc/config.gz | grep -i efi
# EFI (Extensible Firmware Interface) Support
So it has everything mentioned in the kernel doc, which goes on to say
"The stub populates the FDT /chosen node with (and the kernel scans
for) the following parameters: [linux,uefi-system-table and more]". On
hikey I get this:
root@hikey:~# dtc -I fs -O dts -o ~/effective.dts /proc/device-tree/
root@hikey:~# grep chosen -A4 effective.dts
linux,initrd-end = <0x0 0x7fff200>;
bootargs = "console=ttyAMA0,115200 earlycon=pl011,0xf8015000
root=/dev/sda1 rootwait ro ";
linux,initrd-start = <0x0 0x7fff000>;
This is an UEFI I built myself using
https://github.com/96boards/edk2/commits/hikey with a change to use
/dev/sda1 as root in bootargs, nothing more.
What is needed to get linux to notice UEFI? It looks like all the bits
are in place (bootloader, kernelstub, kernel config).
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
User/pass is linaro/linaro ... I don't remember that being documented, found it by trial and error.
On Mar 3, 2015 9:53 PM, Jason Liu <liu.h.jason(a)gmail.com> wrote:
I flashed the hikey-jessie_developer_20150208-104.emmc.img into the
system and boot up,
but don't know the login name and passwd for the debian system? Could
someone help it?
Dev mailing list
Since UEFI boot menus don't persist, configuring boot is
troublesome. The workaround is to use a "startup.nsh" script in the
boot partition (/dev/mmcblk0p6). My script looks like:
rootwait ip=dhcp console=ttyAMA0,115200 earlycon=pl011,0xf8015000
root=/dev/nfs rw quiet
During boot (serial cable required), interrupt the boot and select shell:
The default boot selection will start in 8 seconds
 Linux from eMMC
 Boot Manager
Unless you interrupt the shell, in 5sec it will run startup.nsh.
A quick breakdown of my command line:
- UEFI idea of boot partition
- The filename of the kernel to boot
- Name of the device tree file
Rest of the line is kernel command line. In my case I boot from
NFSroot. Adapt to your setup. There is also the option I don't use:
- Name of the initrd file. I don't use an initrd so this is not in my
Efi shell script doc:
There seems to be a conflict between the microSD card and other USB
peripherals (in my particular case, a USB-ethernet dongle). When the
USB-ethernet is connected, the kernel reports the following errors
[ 2571.527346] dwmmc_k3 f723e000.dwmmc1: failed to set rate 0Hz
[ 2571.547337] dwmmc_k3 f723e000.dwmmc1: failed to set rate 400000Hz
[ 2571.570917] dwmmc_k3 f723e000.dwmmc1: failed to set rate 400000Hz
[ 2571.573227] dwmmc_k3 f723e000.dwmmc1: failed to set rate 400000Hz
[ 2571.588534] dwmmc_k3 f723e000.dwmmc1: failed to set rate 400000Hz
[ 2571.590143] dwmmc_k3 f723e000.dwmmc1: failed to set rate 0Hz
And the microSD card is not discovered. Absent the USB-ethernet
dongle, it works ok.
Has anyone encountered this error, and has any suggestion how it could be fixed?
Linaro Marketing Director