Beelink GT1 Ultimate, S912, wifi chip QCA9377 wifi "partially" works.

[bthoven]

I follow the method here: 

My box can now see the wifi, but there are a few quirks:

1. It sees only some of the 5Ghz band. For example, it can't see my own 5Ghz AP, but can see my neighborhood 5G APs

2. when connected with either 2.4Ghz and 5Ghz band, and I did the speed test. It is fine with the download speed, but the upload speed is just less than 1Mbps, always. Thus, the connection is virtually useless, e.g. I can vnc to it, but it shows black screen because the screen can't be uploaded to my vnc client due to the upload speed problem.

Is there any work around?

My armbian: Armbian_20.10_Arm-64_focal_current_5.9.0_desktop.img

dtb file: /dtb/amlogic/meson-gxm-q200.dtb

 

dmesg shows the message below:

[    8.933696] ath10k_sdio mmc2:0001:1: qca9377 hw1.1 sdio target 0x05020001 chip_id 0x00000000 sub 0000:0000
[    8.933704] ath10k_sdio mmc2:0001:1: kconfig debug 0 debugfs 0 tracing 0 dfs 1 testmode 0
[    8.934080] ath10k_sdio mmc2:0001:1: firmware ver WLAN.TF.1.1.1-00061-QCATFSWPZ-1 api 5 features ignore-otp crc32 7746e551

[9.083147] ath10k_sdio mmc2:0001:1: failed to fetch board data for bus=sdio,vendor=0271,device=0701,subsystem-vendor=0000,subsystem-device=0000 from ath10k/QCA9377/hw1.0/board-2.bin
[9.083936] ath10k_sdio mmc2:0001:1: board_file api 1 bmi_id N/A crc32 544289f7

[   20.225122] wlan1: authenticate with d4:5f:25:ec:5b:3a
[   20.287094] wlan1: send auth to d4:5f:25:ec:5b:3a (try 1/3)
[   20.295165] wlan1: authenticated
[   20.299017] wlan1: associate with d4:5f:25:ec:5b:3a (try 1/3)
[   20.311166] wlan1: RX AssocResp from d4:5f:25:ec:5b:3a (capab=0x831 status=0 aid=2)
[   20.367269] wlan1: associated
[   20.367967] ath: EEPROM regdomain: 0x8348
[   20.367976] ath: EEPROM indicates we should expect a country code
[   20.367981] ath: doing EEPROM country->regdmn map search
[   20.367985] ath: country maps to regdmn code: 0x3a
[   20.367990] ath: Country alpha2 being used: US
[   20.367993] ath: Regpair used: 0x3a
[   20.368003] ath: regdomain 0x8348 dynamically updated by country element
[   20.535469] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[   20.574912] rc rc0: two consecutive events of type space
[   50.418850] ath10k_sdio mmc2:0001:1: failed to transmit packet, dropping: -12
[   50.418864] ath10k_sdio mmc2:0001:1: failed to submit frame: -12
[   50.418870] ath10k_sdio mmc2:0001:1: failed to push frame: -12
[   50.418885] ath10k_sdio mmc2:0001:1: failed to transmit packet, dropping: -12
[   50.418891] ath10k_sdio mmc2:0001:1: failed to submit frame: -12
[   50.418896] ath10k_sdio mmc2:0001:1: failed to push frame: -12
[   50.699934] ath10k_sdio mmc2:0001:1: failed to transmit packet, dropping: -12
[   50.699949] ath10k_sdio mmc2:0001:1: failed to submit frame: -12

 

[forart.it]

Hi there, very interesting test.

 

I succesfully run latest LibreELEC "box" nightly builds (Kodi-20) in my YokaTV KB2 - S912-based - by using "meson-gxm-q200.dtb" so I believe that "should support most hardware" (as chewitt suggested here).

 

I'll try ARMbian soon...

[chewitt]

I have recently upstreamed a device-tree for the GT1-Ultimate, see: https://patchwork.kernel.org/project/linux-amlogic/patch/20220707101423.90106-1-jbrunet@baylibre.com/. AFAIK the box only shipped with a Broadcom SDIO module and the earlier (non-ultimate) GT1 box has the QCA9377 inside. If I can get confirmation (and dmesg log output) from a non-ultimate box with QCA9377 booting the following LE image I will send the non-ultimate GT1 dts upstream too:

 

https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-box.img.gz - set the non-ultimate GT1 dtb name in uEnv.ini before booting.

 

I've also added the u-boot signing FIPs here: https://github.com/LibreELEC/amlogic-boot-fip/tree/master/beelink-gt1 - It's been tested with a genuine GT1-Ultimate (there are some fakes in circulation) but the Beelink devs claim the same u-boot sources are used with both versions of the box. There's a pre-built u-boot 2022.07 binary here: https://chewitt.libreelec.tv/testing/u-boot/u-boot.bin.sd.bin-beelink-gt1 that can be used for SD/eMMC booting.

[Dimm500]

chewitt, is this topic actual? I have GT1 Ultimate with chip Longsys LTM8830. As far as I know it equivalent for QCA9377. I can put here dmesg output, but I can't download this image (404 error): https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-box.img.gz

[chewitt]

According to the Beelink developers the GT1-Ultimate shipped with a Broadcom WiFi module, while the earlier GT1 (non-ultimate, but looks identical) box shipped with a QCA9377 module. So either you have a non-ultimate box, or a fake Ultimate box (there are fakes around).

 

https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.95.0-box.img.gz

 

^ This image includes a "meson-gxm-gt1.dtb" which should work with QCA9377 modules. I've been waiting for someone to show up and test it. So please install, SSH into the box, and share the URL generated by "pastekodi" so I can see the boot log. If WiFi and BT are working I will send the device-tree upstream to the kernel. If they aren't .. we can see the errors.

[Dimm500]

I don't think that it's fake edition. I supposed that it is one of beelink GT-F-V10_20161015 PCB modifications (GT-F-L S912/DD4 3G/32G/L TM8830 sticker on PCB). Now I use firmware from SlimBox team for QCA9377 chip. All works good. 

Log from LibreELEC: http://ix.io/4mTT

[chewitt]

@Dimm500 Boot log looks okay apart from Ethernet not working (it's probed but fails). Does this box have 10/100 or Gigabit Ethernet? Can you share some high-res pics of the PCB (to see the Ethernet PHY chip markings)?

 

WiFi and BT are both probed working so the device-tree looks correct for that part. Did WiFi/BT work with the default firmwares embedded in the LE image? - or not? - I'm unsure if "Now I used firmware from Slimbox" refers to WiFi/BT firmware files or a complete Android ROM image.

[Dimm500]

I have no photo of my PCB in hi-res, only bad quality. And I can't open box now, because I have no thermal paste. But I found photo of my PCB on other forum (all stickers, elements placement and form are the same - I compared with my bad quality photo). Photo in attachment.  

 

I didn't check Ethernet on Libreelec, but BT+Wi-Fi work with the default  firmwares embedded in the LE image. If you want I can check Ethernet on Libreelec image later.
When I spoke about SlimTV firmware, I mean full ROM - this my main ROM, which I use on EMMC. Wi-Fi, BT and Ethernet work good with it.

[Dimm500]

Ethernet chip crop

[chewitt]

cd /storage/.update
wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.95.1.tar
reboot

 

@Dimm500 please run those ^ commands and then run "pastekodi" and share the log again once the update completes. Ethernet fails to probe PHY address 0, so I've tweaked the device-tree to probe address 1 which is occasionally used by some boxes.

 

also run "mdio" and it should list an MDIO entry for "stmmac-X" .. if yes, please run "mdio stmmac* | paste" and share that URL too please.

[Dimm500]

Done 

 

Цитата

LibreELEC:~ # pastekodi
http://ix.io/4n7j
LibreELEC:~ # mdio
fixed-0
mdio_mux-0.2009087f
mdio_mux-0.e40908ff
stmmac-0
LibreELEC:~ # mdio stmmac-0 | paste
http://ix.io/4n7k

 

 

P.S.: "Failed to start ethmactool-config.service" message appeared during boot process.

[chewitt]

cd /storage/.update
wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.95.1.tar
reboot

 

^ Update again please. I've added/enabled some additional Ethernet PHY drivers in the kernel. Do "pastekodi" afterwards. Thanks.

[Dimm500]

Done 

 

Цитата

LibreELEC (chewitt): 10.95.1 (AMLGX.arm)
LibreELEC:~ # pastekodi
http://ix.io/4nks
LibreELEC:~ # mdio
fixed-0
mdio_mux-0.2009087f
mdio_mux-0.e40908ff
stmmac-0
LibreELEC:~ # mdio stmmac-0 | paste
http://ix.io/4nkt

 

 

P.S.: "Failed to start ethmactool-config.service" message still appeared during boot process.
P.P.S.: Sometimes (30%) STB don't boot. Stack on logo and this message.

[chewitt]

cd /storage/.update
wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.95.1.tar
reboot

 

Hi, please update and then run "pastekodi" (and share URL) again. I've done something which might get Ethernet working?

[Dimm500]

Sorry for delay:

LibreELEC:~/.update # wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.95.1.tar
Connecting to chewitt.libreelec.tv (138.68.75.163:443)
wget: server returned error: HTTP/1.1 404 Not Found
 

[chewitt]

I deleted the 10.95.1 image. There is a newer one in the same folder. Use initiative!

[Dimm500]

After the last reboot, the set-top box automatically updated to the 11th version. I don't see any error messages during reboot process. 

 

Цитата

LibreELEC:~ # pastekodi
http://ix.io/4qK8

mdio command not available now. 

[Jens J.]

for a future self, my notes on making an image work fully with the wifi/bt:

 

 

 

SD customization:

to make uboot work: sd card bin, u-boot-p212.bin -> u-boot.ext

# DTB:

edit /boot/extlinux/extlinux.conf, uncomment line:
FDT /dtb/amlogic/meson-gxm-gt1-ultimate.dtb
(comment out all other FDT lines)

apt update && apt install net-tools git vim

## wifi firmware
mkdir -p /lib/firmware/ath10k/QCA9377/hw1.0/
download files from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0
copy them to /lib/firmware/ath10k/QCA9377/hw1.0/

# replace special firmware (which seems more stable)
ln -sf /lib/firmware/ath10k/QCA9377/hw1.0/firmware-sdio-5.bin /lib/firmware/ath10k/QCA9377/hw1.0/firmware-5.bin

# fix bt?
fdtput -t s /boot/dtb/amlogic/meson-gxm-gt1-ultimate.dtb /soc/bus@c1100000/serial@84c0/bluetooth compatible "qcom,qca9377-bt"
fdtget /boot/dtb/amlogic/meson-gxm-gt1-ultimate.dtb /soc/bus@c1100000/serial@84c0/bluetooth compatible

# bt firmware
mkdir /lib/firmware/qca
download fw files to this dir:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/qca/rampatch_00230302.bin
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/qca/nvm_00230302.bin

# figure out a way to cycle the bt uart power at startup on qca9377
# simply getting the state of the gpio pin seems to cause it to correct itself
gpioget gpiochip1 96
# (maybe consider moving from shutdown-gpios to reset-gpios in device-tree?)

## fix cpu throttling
https://forum.armbian.com/topic/18429-managing-cpufreq-on-biglittle/

# consider porting the remote-control map into device tree

[SteeMan]

@Jens J.  If you could package this into a PR then everyone could benefit from your hard work 

[Jens J.]

@SteeMan yes I would love to do exactly that

I figured out how to add new dts - cumbersome, but through "kernel patch" process.

I'm still trying to wrap my head around a few other armbian things:

As I understand it, armbian has it's own firmware package, which is probably some subset of normal linux-firmware packages. Is there some accepted way to extend this (to add the qca9377 firmwares?) such that the build process includes it - or is there some sort of install script I can invoke during build.

(I was considering making this a special board type, basically Beelink GT1 w/ this QCA9377-compatible bt/wifi). Was trying to find out all the steps to add a new board support, but it's not really well documented from what I can tell. Is there any high-level outline of the steps?

[Jens J.]

ok the QCA9377/LTM8830 firmwares added to armbian-firmware
https://github.com/armbian/firmware/pull/63

 

With this newer firmware package, the wifi should work.

Bluetooth will need the change in the DTS.

 

I'm working on a PR for armbian/build repo to add DTS for this variant, which I think is called "mini-m8s-pro"

Basically a Beelink GT1 ultimate dts with LTM8830 (QCA9377) wifi/bluetooth, which will look like this:

https://gist.github.com/zerog2k/a702a41fe91f52b07c2e53e4f359f580#file-meson-gxm-mini-m8s-pro-dts-L85-L86

Edited October 9, 2023 by Jens J.

[Jens J.]

deleted

Edited October 9, 2023 by Jens J.

[SteeMan]

@Jens J. I would suggest that you work on learning how to incorporate into the armbian build each of the components that you are modifying.

 

I wanted to point out to you that armbian builds two different firmware files: armbian-firmware and armbian-firmware-full.  The install by default installs armbian-firmware.  The difference between the two is that armbian-firmware is a paired down set of firmware theoretically containing just the firmware needed for supported boards.  Whereas armbian-firmware-full is the complete firmware from the linux kernel plus any custom/added firmwares that are not mainlined.  So since you are just using what is in mainline, all you should need to do is install the full firmware package (apt install armbian-firmware-full).

In your PR, since you copied from mainline, if mainline gets updates to those files, they will not be incorporated into armbian, so that is potentially a problem.

 

 

[Jens J.]

ok thanks @SteeMan

I see armbian-firmware is around 16MB vs 300+MB of armbian-firmware-full. Luckily, I don't think the firmware has changed on the QCA9377 much since 2020's commit. I do see your point though. Is there some way to have the armbian-firmware build process dynamically pull the latest from upstream kernel for the selected drivers/sections, without doing the whole "kitchen sink" approach of armbian-firmware-full, which is a bit excessive for some devices with limited storage?

 

Regarding learning, I'm using what you started with config/boards/aml-s9xx-box.tvb and adapting this to a new board type (mini-m8s-pro.tvb), along with adding dts at patch/kernel/meson64-edge/dt/meson-gxm-mini-m8s-pro.dts

If there is further documentation on this process of adding new board support, especially around the amlogic flavors, to better guide me, I'd be happy to check that out

 

[SteeMan]

10 hours ago, Jens J. said:

Regarding learning, I'm using what you started with config/boards/aml-s9xx-box.tvb and adapting this to a new board type (mini-m8s-pro.tvb), along with adding dts at patch/kernel/meson64-edge/dt/meson-gxm-mini-m8s-pro.dts

If there is further documentation on this process of adding new board support, especially around the amlogic flavors, to better guide me, I'd be happy to check that out

For now I would suggest you just incorporate your changes into the existing s9xx-box.  Adding an entire new board comes with a much higher level of commitment on your part (expectations on being a maintainer for that board to keep it in the project).  Also since TV boxes aren't officially supported by Armbian, we try to have minimal impact on the build infrastructure.  Also by keeping these emlogic boxes under one umbrella, hopefully that leads to more community/developer support for all of them, as opposed to spreading them out as separate boards.  This can always be changed in the future if directions/needs change.

[SteeMan]

10 hours ago, Jens J. said:

I see armbian-firmware is around 16MB vs 300+MB of armbian-firmware-full. Luckily, I don't think the firmware has changed on the QCA9377 much since 2020's commit. I do see your point though. Is there some way to have the armbian-firmware build process dynamically pull the latest from upstream kernel for the selected drivers/sections, without doing the whole "kitchen sink" approach of armbian-firmware-full, which is a bit excessive for some devices with limited storage?

@rpardini What is the recommended approach to incorporating firmware from mainline into the armbian-firmware package (other than copying the files and then running the risk of divergent files over time if they change in mainline)?  Some sort of buildtime reference that copies the current mainline files over? What was done here https://github.com/armbian/firmware/pull/63 seems brittle to me.