Beelink X2 with armbian possible?

[spock]

@tkaiser: Thanks, I will report back. Looking at the logs, it does seem that something odd is going on with sdio, so you may well be right.

 

BTW, have you enjoyed the new ch340 kernel panic with OSX 10.12 ? This was how my day started when I added your "suggested accessory" to my X2 this morning :-)

[mdel]

 

The key question is how we get these things to reliably boot, shutdown and boot again - then these boxes are excellent for all kinds of purposes.

 

well yeah that was my idea to repurpose that cheap box to do many things, but frankly in terms of stability and probably also performance, if my h3 vs s905 openvpn tests prove to be right, my favorite choice at the moment is an s905 box, the cheapest being the nexbox a95x (21-25$).

 

Armbian runs extremely smoothly on it, no problems whatsoever (if not for one of the two usb port not being powered at boot).

 

So the x2 is still on my radar, i always like to have an alternative, maybe the orange pi pc would be a better choice if you don't need wifi, well the x2 wifi is probably quite miserable anyways.

 

and i managed to get one clean reboot on my x2 so there is hope =)

 

 

@@tkaiser

i'll check the loaded modules when i can get back to it.

Do you mean unloading the modules early during the shutdown process and not let the system handle that ?

[tkaiser]

Do you mean unloading the modules early during the shutdown process and not let the system handle that ?

 

Well, if the kernel panics on shutdown then 'the system' can't handle that much any more. We had several reports regarding on sun7i (Allwinner A20) and sun8i (H3) where a forced rmmod helped in such situations. And that's why these lines here exist: https://github.com/igorpecovnik/lib/blob/master/scripts/armhwinfo#L279-L287

 

Would be good of course to collect some more info which modules cause such panics to handle unloading of these modules in a generic way on shutdown.

[jernej]

@Igor or whoever maintains this device,

 

there is a nice method how to autoload correct wifi (sdio) driver on sun8i instead of manually specifying it at build/runtime. This behaves just the same as USB driver autoloading. If you execute

echo "123" > /proc/driver/wifi-pm/power

then the kernel will scan sdio bus and automatically load appropriate driver. I tested that with all common wifi drivers (8189es, 8189fs, bcmdhd) and it works.

 

There is a catch, as usual. BananaPi M2+ and Beelink X2 use same driver, bcmdhd, but they use different FWs and nvram files. If you put FW files in same folder then problem is solved for firmware part. The problem stays for nvram file. Quick fix would be that at build time you overwrite nvram file with correct one because user must download appropriate image anyway. Universal approach, which is already implemented by the driver, is to make a config file with translation between mac range and nvram file name. I sent e-mail to AMPAK about mac addresses, but I don't really expect the answer.

[spock]

@jernej

 

So to make this work, we need to:

• remove bcmdhd from /etc/modules
• ensure we have the right nvram file in place for the X2 (or M2+)
• do the echo 123 thing during network initialisation (I will work out where when I have read up on systemd - I'm so old I still find system V init a bit modern!)

I will take a look at this and work out where to put things & report back.

 

I'm currently looking at why the X2 does not shut down properly - and as @tkaiser pointed out, the likely culprit is a driver crash and I have bcmdhd firmly in my sights as the culprit. 

[jernej]

Yes, that was my first suggestion. I already made and tested following systemd file: https://github.com/jernejsk/OpenELEC-OPi2/blob/96d8367b005b02fc1c164f6fc0d6968ff0663c19/packages/sysutils/sunxi-sys-utils/system.d/sunxi-wifi-load.service

Probably you should remove "Environment" line.

 

However, thing evolved a bit today. I don't have X2 so this is another remote debugging fun (yay!). I've been working with Sven Kayser on this. This driver which is included in Armbian and OpenELEC crashes on X2, as you found out also. He noticed that driver version on Android is a bit newer. He also found source for it (https://github.com/bugquella/lichee/tree/master/linux-3.4/drivers/net/wireless/bcmdhd). Currently I'm analyzing driver code and I found out another very good thing - driver can autoselect nvram file based on chip id, so we must only provide config file with maping between chip id, chip revision and nvram file name. That way we could completely remove all hacks and drivers would be autodetected. I'm really hoping this works out.

 

I will test this concept on BananaPi M2+ with OpenELEC. I will report if it works or not. Ultimate goal would be automatic driver loading even without systemd trigger. But this comes later

[jernej]

Final solution implemented:

 

I found even newer driver, which I had to modify to work with sun8i kernel. Good thing here is that has even better system for nvram autoselection - based on chip id. Now it is possible to have one driver for multiple chips/boards. Tested on BananaPi M2+. I also fixed crashes, so it should cleanly unload and reload. Solution was found in Amlogic version of the driver - not to power down when it tells you. That means that the chip will stay powered after driver is unload, but this could be fixed by issuing:

echo "000" > /proc/driver/wifi-pm/power

Updated driver:

https://github.com/jernejsk/OpenELEC-OPi2/blob/ccd4132dbfc5a6de0962b63ae68d55cce527c791/projects/H3/patches/linux/linux-201-update-bcmdhd-driver.patch

 

Driver config file for nvram autoselection:

https://github.com/jernejsk/wlan-firmware/blob/34d66e85f8c6ce5b0291bc4aa0cc5c0dd88d659d/firmware/brcm/config.txt

 

Tested on BananaPi M2+ and OpenELEC, I'm waiting for X2 report. Should work exactly the same on Armbian. With this fix, there is no reason anymore to have manual wifi driver loading. For that purpose systemd or similar script could be enabled/disabled.

[spock]

@jernej

 

I will have a go at building this for X2. But could you tell me which version of the driver are you patching against?

A link would be helpful as I will simply build the driver on the X2 itself - I don't have time to set up a build machine until later next week.

Thanks!

[Igor]

I just updated our build system with those patches. Give it a try.

 

Wrote on mobile phone

[jernej]

Igor, I forgot to mention that driver has a new module name - dhd.ko Just curious, any plans for autoloading wifi drivers?

 

Spock, just take Igor kernel repository and then first patch with older driver update patch and then again with mine.

[Igor]

Yes, autoloading would be nice to have, just need to do few tests to make sure it's working properly. I also don't have Beelink with this chipset, only M2+

 

I added a patch and did a build tests. The rest when I find time.

[mdel]

my beelink x2 has an ap6181, i can do a test with your build if it can help.

 

also having the systematic reboot problem with current armbian 5.20, i blacklisted my wifi driver but it didn't make a difference.

[spock]

@Igor, @jernej:

 

I had a quick look at @Igor's latest patch and think it corresponds to @jernej's. So, I did a build (in a new ubuntu VM) and then copied dhd.ko across to the X2.

 

I placed the config.txt into the /lib/firmware/brcm directory.

I took the wlan0 interface down and removed the bcmdhd driver (rmmod) and loaded the new one ... and, er, ended with a kernel crash.

 

From a  first look at the dmsg just before the crash, I noticed that the firmware had not loaded so something is not right.

 

Before I get into debugging that, was there anything else I should have done first?

[jernej]

Please share dmesg output. I received confirmation that it works as expected on X2 with OpenELEC, without any crash.

[Igor]

It's working fine on my M2+ 

echo "123" > /proc/driver/wifi-pm/power
rmmod dhd

Next step is adding a script to the build.

[Reddwarf]

It's working fine on my M2+ 

echo "123" > /proc/driver/wifi-pm/power
rmmod dhd

Next step is adding a script to the build.

I downloaded the Armbian 5.20 image today, it boots fine on my MX2 (serial X2H3C... the rest is blurred) but when I do the echo trick it freezes after giving "Internal error: Oops: 5 [31] PREEMPT SWP ARM. Do I need another driver module?

[spock]

Update, I can load the dhd driver (after removing the bcmdhd.ko, replacing with dhd.ko and a little depmod -a), and now don't crash. The crash was caused by having the old bcmdhd driver load during boot. Once this was removed, no more crash on load of dhd.ko.

 

Now that dhd loads, we end up with the driver trying to load the wrong firmware, so there is a configuration problem I guess ...

 

Here's a snip of the dmesg output:

 

 

... snip ...

[  307.610253] *******************sdio init ok*******************

[  307.626360] bcmsdh_register: register client driver

[  307.626478] bcmsdh_sdmmc: bcmsdh_sdmmc_probe Enter

[  307.626592] bcmsdh_sdmmc: bcmsdh_sdmmc_probe Enter

[  307.626604] bus num (host idx)=2, slot num (rca)=1

[  307.626614] found adapter info 'DHD generic adapter'

[  307.626736] sdioh_attach: set sd_f2_blocksize 128

[  307.627235] F1 signature read @0x18000000=0x1591a962

[  307.627501] dhd_conf_set_hw_oob_intr: Enable HW OOB for 43362

[  307.630239] F1 signature OK, socitype:0x1 chip:0xa962 rev:0x1 pkg:0x9

[  307.631284] DHD: dongle ram size is set to 245760(orig 245760) at 0x0

[  307.632196] dhd_conf_set_chiprev: chip=0xa962, chiprev=1

[  307.632268] dhd_conf_set_conf_path_by_nv_path: config_path=/lib/firmware/ap6212/config.txt

[  307.634048] dhd_conf_read_config: Ignore config file /lib/firmware/ap6212/config.txt

[  307.634766] wl_create_event_handler(): thread:wl_event_handler:3dd started

[  307.634779] tsk Enter, tsk = 0xee2e1430

[  307.635075] dhd_attach(): thread:dhd_watchdog_thread:3de started

[  307.635165] dhd_attach(): thread:dhd_dpc:3df started

[  307.635179] dhd_dpc_thread: set dpc_cpucore 0 from config.txt

... snip ...

 

As we can see, the driver picks up the chipped *A962 (or 43362) - but then proceeds to pick the wrong firmware.

 

I have put the following in /lib/firmware/brcm/config.txt ...

 

 

 

nv_by_chip=1 \   43362 1 nvram_ap6210.txt   43430 0 nvram_ap6212.txt

 

I guess I am missing some config files?

 

(Remember I am using the latest normal download of the X2 firmware, and then hacking in the newly built dhd.ko on top of this.)

[spock]

@reddwarf - If you downloaded the standard firmware, this does not contain the new patch of the driver that @igor and @jernej have been working on ...

 

I suspect that we are close to sorting this out, and then I guess that @igor will publish a new version...

[Reddwarf]

@reddwarf - If you downloaded the standard firmware, this does not contain the new patch of the driver that @igor and @jernej have been working on ...

 

I suspect that we are close to sorting this out, and then I guess that @igor will publish a new version...

Ok thanks, I have an usb soundcard attached and it worked before I did an upgrade, does that sound familiar?

[jernej]

I have put the following in /lib/firmware/brcm/config.txt ...

 

If you check your dmesg snip again, you will see that driver is configured with /lib/firmware/ap6212 path. So either you move all brcm FWs, nvram files and config.txt to /lib/firmware/ap6212 folder or to /lib/firmware/brcm and recompile the driver with correct path. I guess later is more standard.

[jernej]

Next step is adding a script to the build.

 

You can wait for tomorrow. I will try to patch rf_pm driver in a way, that this won't be necessary. This behaviour would be identical to that on mainline kernel - there is a node for wifi power in device tree. If it is present, wifi chip is powered and scanned for driver.

[spock]

@jernej & @igor

 

We have progress and a bug or two to report 

 

I placed the ap6210 & ap6212 files and config.txt into /lib/firmware and did the "echo 123 thing". The firmware now loads :-) but I see that the interface was renamed to "wlan1" (at 77.830501) - which looks a little odd ?

 

 

 

 

[   77.754876] dhd_conf_set_txglom_params: tx_in_rx=1, tx_max_offset=0

[   77.754885] dhd_conf_set_disable_proptx: set disable_proptx 1

[   77.758019] dhd_preinit_ioctls wl ampdu_hostreorder failed -23

[   77.768537] Dongle Host Driver, version 1.201.59.6 (r506368)

[   77.768544] Compiled in drivers/net/wireless/bcmdhd

[   77.769375] Register interface [wlan0]  MAC: 94:a1:a2:0c:c5:c9

 

[   77.769474] dhd_module_init: Exit err=0

[   77.830501] systemd-udevd[981]: renamed network interface wlan0 to wlan1

[   78.158723] dhd_open: Enter eebaa800

[   78.257184] dhd_set_scb_probe: GET max_scb_probe failed

[   78.257760] dhd_set_scb_probe: max_scb_probe setting failed

[   78.257776] dhd_open: Exit ret=0

[   79.738790] Connectting with 88:41:fc:34:5b:5d channel (1) ssid "ROGERS", len (6)

 

Anyhow, I amended /etc/network/interfaces to add the new wlan1 and brought up the interface - but wifi did not get connected. Then I noticed that int the "ap6210" firmware there were both nvram.txt and nvram_ap6210.txt. I replaced nvram_ap6210.txt with the nvram.txt and rebooted.

 

Now it all works :-) but really it's broken as we need to sort out where all the config files go - and make sure we have the right nvram for the X2 in place.

 

So why was it broken in the first place? Well, the path for the configuration is set in CONFIG_BCMDHD_NVRAM_PATH - this is set in lib/config/kernel/linux-sun8i-default.config to be "/lib/firmware/ap6212/nvram.txt" ... and that does not work for the X2.

 

@igor - I see that this path was set in this commit: 28d4b14 on 12th May - and this is why it works on your M2 as it just happens to be the right directory, but it is not on the X2. It would make sense to do as @jernej suggests and do something like the following:

 

• Have a "/lib/firmware/dhd" directory (or use the brcm directory - but there could be conflicts with configuration, so a dhd directory might be better?)
• In there, place config.txt and the firmware from the original ap6210 and ap6212 directories.
• We also (for the X2 - could be different for other boards) need to have the original nvram.txt renamed to nvram_ap6210.txt

[ UPDATE: removing the two wlan entries in the 70-persistent-net.rules udev file fixed this ...  @igor / @jernej - Do you know why the interface is getting renamed? Could it be to do with hitting /proc/driver/wifi-pm/power ?]

 

I would have a go at this, but I have not worked with this stuff for over 20 years and would need to learn git and how to use the patch tool (again) :-) Perhaps you would be quicker? If you want me to sort it, then tell me and I will put the work in.

 

Now back to sorting out reboot reliability.

[Reddwarf]

Can someone give me a quick HowTo on how to change to Mate desktop? (ultimately I wanted Cinnamon but I understand it cannot run on ARM since there is no HW acceleration for it)

[jernej]

but I see that the interface was renamed to "wlan1" (at 77.830501) - which looks a little odd ?

<snip>

@igor / @jernej - Do you know why the interface is getting renamed? Could it be to do with hitting /proc/driver/wifi-pm/power ?

 

I have no idea, definetly is not /proc/ thing - that thing only power on wifi chip and scan for SDIO device. It is some udevd rule, maybe because it is different driver name?

 

 

Have a "/lib/firmware/dhd" directory (or use the brcm directory - but there could be conflicts with configuration, so a dhd directory might be better?)

 

There is no point to have yet another folder. There is firmware for almost all chips supported by the driver and when board with a new version cames, only config file should be updated with new nvram file location.

[spock]

@jernej There was an odd entry in the udev rules - a definition of wlan0 with a MAC address that I don't recognise. I cleared the /etc/udev/rules.d/70-persistent-net.rules, and all is working well now. So one bug gone :-)

 

As far as the folder goes, I'm not worried - I think that the current split of ap6210 and ap6212 won't be needed now there are your patches to the driver.

[Reddwarf]

Can someone give me a quick HowTo on how to change to Mate desktop? (ultimately I wanted Cinnamon but I understand it cannot run on ARM since there is no HW acceleration for it)

Anyone please? Or is there an image with Mate I can download??

[Igor]

Anyone please? Or is there an image with Mate I can download??

If you don't need acceleration support just google for "install mate debian or ubuntu" ... you probably can cook some combinations but can't help you on that. We choose to provide one (working/stable) XFCE desktop with acceleration and fine tuning.

[tkaiser]

Anyone please? Or is there an image with Mate I can download??

 

Of course not and the whole thing is not even Beelink X2 specific.

 

You would get the Debian Jessie Desktop image and then simply install the packages missing likein  this example here (for Ubuntu -- so please use 'apt-cache search mate' before to get the idea how Jessie packages might be called): https://github.com/Terra854/pine64-ubuntu-gui/blob/master/install-ubuntu-gui.sh#L655-L658

[jernej]

Igor,

 

I finished and tested autoloading patch with opi2 and bpim2+. I think it is safe to assume that we no longer need to wory about wifi drivers, at least until new version of bcmdhd module shows up.

 

bcmdhd WOW patch:

https://github.com/jernejsk/OpenELEC-OPi2/blob/e148c9b4d685ca3987364177d9c7db519c6345a0/projects/H3/patches/linux/linux-202-bcmdhd-add-wow-selection.patch

 

wifi auto power on & load patch:

https://github.com/jernejsk/OpenELEC-OPi2/blob/e148c9b4d685ca3987364177d9c7db519c6345a0/projects/H3/patches/linux/linux-203-rf_pm-auto-power-on.patch

[Igor]

@spock

Bananapro and Cubietruck are also using those files so we need to be carefully on changes.