Igor

We are constantly updating all supported boards. Some boards get big, some minor changes. Expect one update soon - it's coming with apt-get update && apt-get upgrade manner. Some upgrades might result in error, check this.

Enabling OTG should not affect wlan feature. Are you sure you did not modify anything else? Just try with original DTB too see if you got wifi back.

We don't deal with Android in any way, can't help.

OK. This would help pack kernel faster but if not possible, not that critical since this is not done that many times. So no much other alternatives except adjusting "build-all" to work simultaneously.

http://unix.stackexchange.com/questions/177045/compile-source-package-with-multiple-cpu-cores-in-debian-apt-get-b-source Can we use this tool for multi core packing? It would also save some time.

Check image.armbian.com for updated 5.21 images. Both are tested and working O.K. Noticed before my notice

I'll check once again and upload new image.

What if you install only armbian-firmware and remove other firmwares?

Recent armbian-firmware is a "all in one package" -> It's full linux-firmware with removed all stuff that does not possibly work here + some wierd firmware that is used on our boards and it's not present upstream. Build from here + remove: https://github.com/igorpecovnik/lib/blob/master/extras/firmware.sh Adding our collection over: https://github.com/igorpecovnik/lib/tree/master/bin/firmware-overlay Proper rt2870.bin should be present by default.

None. I made quick investigation and haven't found a solution. Anyway, there are at least two ways to go from here - close examine of overlayroot scripts or DIY. You need an overlay modules, which is build in and few proper mounts, which you can find in driver documentation. This way is also userspace independent and must work. It's just a bit more rough way.

Are you using latest Jessie desktop version? Not upgraded to 5.20 but downloaded 5.20? We just introduced Pulseaudio in latest build (we were using ALSA before) so things might not be well polished ...

Welcome on board. Can you try with some older versions, than we might start to find a solution. I don't recall such problems with this board. BTW - how do you power the board?

Patch is present only in our NEXT branch and it was not tested on 4.8.0 ... perhaps some adjustment is needed?

This forum, website and few other services are running on XU4 in 0 db mode - with large heat sink (not picture of mine but it's the same one) and some speed limitations. Unfortunately, traffic is slowly getting high for this board so it will go out probably by the end of this year. Thanks

U-boot on Cubian might be the same. It would help if you can rule this out.

Old u-boot is EOL / not supported for at least two reasons. First is that it's old (and buggy), second is that proper sources were lost long time ago, before Armbian project even started. There are sources on the GitHub but I don't know which one was used to build this one, which one is working o.k. ... Imagine how much time you need to invest to find a best working old NAND u-boot for Cubietruck and referred patch will not work. That one is for modern 2014.xx mainline U-boot. So you will need than to reinvent the wheel. Try getting this new one to work. I heard it's possible but never found time to try. From our perspective is not an urgent issue.

https://github.com/igorpecovnik/lib/commit/3332e4bb38d89e96b77201bbde60e1da08c15ca1 It's fixed in build script but images need to be updated. Possible workaround: reboot a board at first login and it might be o.k. (untested)

I repeat the same with clean 5.20 install to eMMC, the exact same way and with the same gears. I only don't have 128Gb eMMC but 8gb which should not play any role. apt-get update apt-get upgrade reboot all fine next no boot ... true. I can take a look later ... This is the uart log:

I can add this package to our repo if it works on Debian? http://packages.ubuntu.com/xenial/overlayroot

I just issue an update to my eMMC driven C2, going from 5.16 to 5.20 without a problem. How exactly did you install to eMMC? Do you have a serial console?

If you are booting from NAND you are forced to use that old U-boot loader. Modern opensource, which we use by default, does not contain NAND support ... boot from SD and you can use latest u-boot, hopefully all bugs free.

NAND is problematic and also u-boot (where basic hw init is done) with abilities to boot Linux from NAND is old and sources are lost. In any case NAND chips, found on A10 and A20 boards, are slower and less reliable than most SD cards. Forget about or migrate to H3 board with eMMC - Orange PC+ for example. That's another story. Faster and more reliable than SD card(s).

You made a typo: fdt_file not fdtfile That's why there was no change. And those: mmc1: queuing unknown CIS tuple 0x80 (2 bytes) in log are due too default enabled eMMC for all boards. If you board does not have it you will see this ... it must be fixed in u-boot.

Perhaps you are facing network / auto mirror selection (default Debian) issue. Try changing /etc/apt/sources.list with: deb http://ftp.de.debian.org/debian jessie main contrib non-free deb-src http://ftp.de.debian.org/debian jessie main contrib non-free deb http://ftp.debian.org/debian/ jessie-updates main contrib non-free deb-src http://ftp.debian.org/debian/ jessie-updates main contrib non-free deb http://security.debian.org/ jessie/updates main contrib non-free deb-src http://security.debian.org/ jessie/updates main contrib non-free Do an apt-get update after that.

We are doing lots of testing but still we can't catch all the bugs. We can't afford to test all upgrades from all old versions on all boards and when it comes to 3rd party wifi, this job becomes impossible. Recently we started initiative to involve more people into testing phase to hopefully get better results and produce images and upgrades with less bugs. At the moment this is in it's infant state and we don't know if and how this will works. When you do an upgrade in the most critical area (kernel and u-boot), you need to be prepared. Some boards breaks even they works fine in our lab due too quality issues and different board revisions (mostly due to diff RAM chips). We'll put some additional warnings.