Community Build Radio Firmware

[ralphy]

I'll look over your wpa observations and other points when time permits.

Thanks. I've done a bit more digging.

The file adds an IMAGE_INSTALL config option.

If I rename poky/meta-squeezeos/packages/wpasupplicant to wpa-supplicant and all occurances in the recipe then I only get the latest version.

bitbake --show-versions | grep ^wpa
wpa-supplicant                             0:2.9-r0

If I then rebuild the controller or touch firmware the image includes wpa supplicant 0.5.7 which is neither version listed. Turns out it's actually from marvell-wlan-tools-bin.

# ./wpa_supplicant -v
wpa_supplicant v0.5.7-MSI-1
Copyright (c) 2003-2006, Jouni Malinen <[email protected]> and contributors

So until I can test if v2.9 of wpa supplicant works on at least the touch both it and the controller will remain as is. This thread is about the radio firmware anyway.

I am going to leave the renamed wpa-supplicant in meta-squeezeos for now and change the baby.conf to IMAGE_INSTALL += "wpa-supplicant".

[Steevee28]

Wifi instability -> AR6000 fixes?

Since two weeks now, I'm heavily affected by Wifi stability problems of the Radios.
(see https://forums.slimdevices.com/node/1417649, although I now know that the Wireless event too big event is not the root cause)

In my neighborhood, due to Corona, several new Wifis popped up, now having more than 2 dozens neighboring Wifis, which causes all my Radios to now drop Wifi connection after minutes, sometimes even after seconds!
I'm now sure that the problem is due to Wifi interference and that it is specific to the AR6000 of the baby.

So, Ralphy, do see a chance that your new firmware may contain fixes / stability improvements for the Atheros AR6000 chipset that could solve these problems? (besides enabling Wifi channel 13)

I'm willing to test with your help, because my Radios are now completely unusable if no Ethernet cable is plugged in (which is not a true option for me).

Btw, since the driver is modularized and resides in /lib/atheros, as well as the chip firmware binaries, it should be possible to update them without having to fully switch over to your new firmware, isn't it?

[ralphy]

Since two weeks now, I'm heavily affected by Wifi stability problems of the Radios.
(see https://forums.slimdevices.com/node/1417649, although I now know that the Wireless event too big event is not the root cause)

In my neighborhood, due to Corona, several new Wifis popped up, now having more than 2 dozens neighboring Wifis, which causes all my Radios to now drop Wifi connection after minutes, sometimes even after seconds!
I'm now sure that the problem is due to Wifi interference and that it is specific to the AR6000 of the baby.

So, Ralphy, do see a chance that your new firmware may contain fixes / stability improvements for the Atheros AR6000 chipset that could solve these problems? (besides enabling Wifi channel 13)

I'm willing to test with your help, because my Radios are now completely unusable if no Ethernet cable is plugged in (which is not a true option for me).

Btw, since the driver is modularized and resides in /lib/atheros, as well as the chip firmware binaries, it should be possible to update them without having to fully switch over to your new firmware, isn't it?

I've not investigated upgrading the ar6k driver.

The only wifi related changes I've made is upgrading wpa_supplicant to the latest version and patching the kernel to not send a wireless event messages that exceeds the maximum allowed size. I could provide you with the new wpa_* binaries to try as long as you're comfortable using the linux command line.

I sometimes have to plug the radio's ethernet port into an old wireless N router configurated as an ethernet bridge with dd-wrt when this happens. Perhaps that's another option?

[Steevee28]

(...) I could provide you with the new wpa_* binaries to try as long as you're comfortable using the linux command line.
I sometimes have to plug the radio's ethernet port into an old wireless N router configurated as an ethernet bridge with dd-wrt when this happens. Perhaps that's another option?

Yes, that would be fine. I'm perfectly happy with the Linux command line

Thanks for the suggestion about using another router. I've already ordered two TL-WR802N nano routers to bring my devices back into the network as a workaround, but my third Radio is primarily in use as a true "mobile" sound system, because it also has a battery, so the nano router is not an option.

I'm now having some good opportunities to test ar6k driver changes, because, as I already wrote, my devices currently drop the Wifi connection very frequently.

Unfortunately, I don't have a cross-build system at the moment and I'd have to start from scratch. My knowledge is very limited about that.

[ralphy]

Unfortunately, I don't have a cross-build system at the moment and I'd have to start from scratch. My knowledge is very limited about that.

I took a quick look and the ar6000 driver sources for the radio are classified as confidental and not available in the public squeezeos repository.

We would need to find a similiar version of the sources. The only version reference I found was in the modules string table.

/opt/parabuild/etc/build/b20902co/a/u/t/o/jive/7.6/trunk/squeezeos/poky/build/tmp-baby/work/baby-none-linux-gnueabi/atheros-ar6-module-src-1.0-r20/atheros/[B]AR6kSDK.build_sw.62[/B]/host/os/linux/ar6000_drv.c
/opt/parabuild/etc/build/b20902co/a/u/t/o/jive/7.6/trunk/squeezeos/poky/build/tmp-baby/work/baby-none-linux-gnueabi/atheros-ar6-module-src-1.0-r20/atheros/[B]AR6kSDK.build_sw.62[/B]/host/os/linux/ar6000_raw_if.c

There are many load time settings available for the driver. Tweaking one or several of these might improve the connectivity issues, once you understand what each does.

filename:       ar6000.ko
license:        GPL and additional rights
alias:          [B]sdio:c*v0271d0300*[/B]
alias:          [B]sdio:c*v0271d0201*[/B]
alias:          [B]sdio:c*v0271d0200*[/B]
depends:        
vermagic:       2.6.26.8-rt16 preempt mod_unload modversions ARMv5 
parm:           fwloadenable:int
parm:           bmienable:int
parm:           bypasswmi:int
parm:           debuglevel:int
parm:           tspecCompliance:int
parm:           onebitmode:int
parm:           busspeedlow:int
parm:           skipflash:int
parm:           wmitimeout:int
parm:           wlanNodeCaching:int
parm:           logWmiRawMsgs:int
parm:           enableuartprint:int
parm:           enabletimerwar:int
parm:           mbox_yield_limit:int
parm:           reduce_credit_dribble:int
parm:           allow_trace_signal:int
parm:           tx_attempt:array of int
parm:           tx_post:array of int
parm:           tx_complete:array of int
parm:           hifBusRequestNumMax:int
parm:           war23838_disabled:int
parm:           resetok:int

I've sent you a PM where you can download wpa supplicant v2.9 for the radio.

To install, scp the tar file to /dev on the radio using the ethernet port.
Backup the original wpa_cli and wpa_supplicant binaries from /usr/sbin unless you're okay doing a factory reset of the radio if things go wrong.
Extract the tar file into /usr/sbin
If you get a file busy message you'll need to kill the wpa_cli and wpa_supplicant processes.
Reboot the radio. You can type reboot from the ssh connection.
You may have to setup the wireless connection again after the reboot.

[Steevee28]

(...) There are many load time settings available for the driver. (...)
parm: debuglevel:int
(...)
I've sent you a PM where you can download wpa supplicant v2.9 for the radio. (...)

Thank you. I replaced the wpa supplicant binaries by the updated version from you, but that made no difference at all.
I also tried to increase debug level by:

echo 8 > /proc/sys/kernel/printk
echo 8 > /sys/module/ar6000/parameters/debuglevel

but there is still no clue in the debug logs why the connection is lost. The last lines printed into the kernel debug log buffer are from the connection event. There is not a single log entry after that about the disconnection event. That's strange:

[34686.052367] AR6000 connected event on freq 2412 with bssid e0:cb:4e:90:c8:80  listenInterval=100, beaconInterval = 100, beaconIeLen = 22 assocReqLen=64 assocRespLen =59
[34686.067596] Network: Infrastructure

Btw, after disconnection, a reload of the driver module seems required to get Wifi up again by

/etc/init.d/wlan stop
/etc/init.d/wlan start

[ralphy]

I quite often have to reboot the radio when I reload the ar6000 driver.

You should use wpa_cli to manipulate the wireless connection.

Type help for a complete list of commands and there's plenty of usage docs online.

# wpa_cli
wpa_cli v2.9
Copyright (c) 2004-2019, Jouni Malinen <[email protected]> and contributors

Selected interface 'eth1'

Interactive mode

> status
bssid=xx:xx:xx:xx:xx:xx
freq=0
ssid=ricrswap05
id=0
mode=station
pairwise_cipher=CCMP
group_cipher=TKIP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=192.168.xxx.xxx
address=00:04:20:xx:xx:xx
uuid=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxx

[MadGod]

Version #?

What was the last supported firmware number for squeezeboxes?

[mherger]

Community Build Radio Firmware

> What was the last supported firmware number for squeezeboxes?

What SB model? Supported by what?

--

Michael

[ralphy]

For anyone trying to setup a poky build environment I've uploaded 20200213-updated-utilities-i386.tar.gz to my sourceforge site.
The file contains 32-bit curl-7.52.1 git-2.25.0 openssl-1.1.1d wget-1.18 to allow bitbake to consistantly download the sources successfully for squeezeos builds.

I use Ubuntu 10.4.04 i386 for my build environment which was current when the poky environment used to build the firmware was released.

Extract the file in /usr/local as root

sudo tar -x -z -C /usr/local -f 20200213-updated-utilities-i386.tar.gz

I'd suggest using a non-root user for building the firmware.

[naguirre]

Hi,

i successfully build and upgrade firmware of squeezebox radio, by building

 https://github.com/ralph-irving/squeezeos

reposiory.
I used Ubuntu 12.04 otherwise I got a lot of errors related to https and old cypher suite with openssl of ubuntu 10.04 (OMG it was 10 years ago !)
I had to fix few errors during the build :
* squeezeplay-baby recipe was not found
* I got errors during opkg native build so i added few more patches.
* A lot of tarballs were not found, so i find theme and directly downloaded theml in sources directory.

Setting up an ubuntu 10.04 is not so easy these days, so i setup a Docker for it. You can find it here with few more fixes.

https://github.com/naguirre/squeezeos/tree/dev/nae/docker

I agree that it's not really interresting for now to be able to flash our own firmware, but well it was a lot of fun :-)

[D1eter]

the libsdl problem...

I have an old Ubuntu 10.04 64bit VM that I'm trying to use as a build system for the Radio firmware. Unfortunately, I'm stuck at a seemingly well known problem that I haven't been able to fix: The build system has libsdl1.2debian and libsdl1.2debian-pulseaudio installed (but not libsdl-dev) and these seem to interfere with building the firmware somehow. Build fails at the install step for libsdl-image, see output attached.

I found this problem mentioned in http://wiki.slimdevices.com/index.ph...in_squeezeplay but the fix there does NOT work as is also mentioned here: https://forums.slimdevices.com/showt...l=1#post682293

Does anyone know a solution to this problem? While removing the SDL libraries from the build system might fix it I'd rather avoid this as it also removes ubuntu-desktop which I'd like to keep.

Cheers, Dieter

[ralphy]

I have an old Ubuntu 10.04 64bit VM that I'm trying to use as a build system for the Radio firmware. Unfortunately, I'm stuck at a seemingly well known problem that I haven't been able to fix: The build system has libsdl1.2debian and libsdl1.2debian-pulseaudio installed (but not libsdl-dev) and these seem to interfere with building the firmware somehow. Build fails at the install step for libsdl-image, see output attached.

I found this problem mentioned in http://wiki.slimdevices.com/index.ph...in_squeezeplay but the fix there does NOT work as is also mentioned here: https://forums.slimdevices.com/showt...l=1#post682293

Does anyone know a solution to this problem? While removing the SDL libraries from the build system might fix it I'd rather avoid this as it also removes ubuntu-desktop which I'd like to keep.

Cheers, Dieter

I had to rename /usr/bin/sdl-config as indicated in the wiki and I also have libsdl1.2-dev installed on my ubuntu 10.04 32-bit vm.

After you renamed sdl-config did you delete the tmp-baby folder?

[D1eter]

I had to rename /usr/bin/sdl-config as indicated in the wiki and I also have libsdl1.2-dev installed on my ubuntu 10.04 32-bit vm.

After you renamed sdl-config did you delete the tmp-baby folder?

As mentioned, I don't have libsdl1.2-dev installed on my build system. Just the two packages I listed. I'll install libsdl1.2-dev, do the rename and see if that does the trick.

EDIT: No, having libsdl1.2-dev installed doesn't help. The install step of libsdl-image-1.2.5 still fails, though with a slightly different error.

The problem is that at least for the install step the library search path is set to /usr/lib which is wrong. In the thread I mentioned above it was suggested to edit the relevant Makefile but I haven't been able to find out which one that is.

EDIT2: I have since successfully built the new Radio firmware using a 32bit Ubuntu 10.0.4 server VM.

[D1eter]

LMS vs. community firmware

Today I found some time to actually test the SB Radio firmware I have built. However, I didn't find out how to offer the new firmware to the Radio properly.

I copied my baby_7.8.0_r16788.bin firmware file to /var/lib/squeezeboxserver/cache/updates/ with matching baby.version file after removing what was there. Yet, the Radio didn't see the new firmware version. Restarting LMS removed the new version and the standard baby_7.7.3_r16676.bin reappeared. So I renamed my build to baby_7.7.3_r16676.bin and chose to "repeat the update to 7.7.3".

Is there a more elegant way of offering firmware? I'd prefer to use correct file names if possible.

In the few hours so far, there were no issues with the new firmware. My main reason to use the community firmware is to add the capability to play ogg/flac streams natively. This works quite well. I'd also consider to report a max sample rate of 96kHz. Where would I have to make the corresponding change?