Igor

I use this card in my notebook and it's a great performer when it comes to STA but I could not establish AP mode. Neither they did. It looks like firmware restriction.

It is possible that you need to use updated u-boot which properly recognize board you have. Possible solution: - make an image from latest sources. There were some relevant changes in the u-boot - set fdt_file parameter in /boot/armbianenv to one of those: https://github.com/armbian/config/blob/master/debian-config-submenu#L424-L430

... which AFAIK doesn't support AP at 5Ghz.

Nope. The only good and operational are ath10 based cards and they are not recognized on this board, but they work on those: https://www.armbian.com/clearfog-base/ https://www.armbian.com/clearfog/ But you can use USB3 based AC cards. They work fine on mainline kernel: http://amzn.to/2jvV8q1

Update to latest armbian, go to armbian-config -> system and change display manager.

Going back is one solution, but this way might be better:

We haven't done many changes to C1 except: - kernel configuration is ours (probably irrelevant) - boot process (not relevant) - boot settings (.ini) should be the same but it is worth checking (probably irrelevant) - CPU governor might be different (possibly relevant) - userspace changes (irrelevant)

Network problem. Try to remove eth0 entries from /etc/network/interfaces and reboot.

I almost forgot this. With legacy kernel you need to load module (dhd, ap6211 or ap6212) with op_mode=2 while on mainline kernel this is not needed.

Patch would need to be backported to 4.14.y ... perhaps this would do:

boot.scr is binary made from boot.cmd ... how it is made is written in the last line. This tells nothing. All SD cards die. Sooner or later. Since I am dealing with Armbian I already threw away 10-15 cards and at least half of them were claimed to be the best in their (consumer) class. An upgrade is very stressful for SD card.

Yes. The same as mine. (last picture) I am monitoring the development on various platforms and all had/have troubles in PCI implementation. The firstwith mPCI was Hummingboard 1 (imx6). Solidrun needed months to a year to bring it up on their legacy 3.14.y back then, then they changed the kernel for more recent "upstream" Freescale 3.14.y and mPCI was never fully operational again. We kept original 3.14.y where mPCI works fine. Also on Hummingboard 2. Then, on the latest mainline kernel 4.15.y, it also works fine. Even ath10 cards work. The situation with Clearfog was little better but only with second BSP package, when they moved to kernel 4.4.y ... the initial kernel was 3.10.y. And now with mainline where only a few things are missing. Then we have first Allwinner H6 mPCI which is ... broken. I have no experiences with Bananapi R2 (MT7623) mPCI implementation. Random behavior can be a sign that implementation is broken. From my perspective and from what I know I can't say anything else than it is broken. If I would know why and where I would fix it. What can you do? Press on Globalscale/Marvell to put more efforts in fixing this.

https://www.armbian.com/pine64/ Most if not all problems which are written under Pine64 are also present here. Documentation is only slightly outdated. Some things were fixed in the meantime. Nothing we can do about.

You can safely kill the process. Troubles of this kind are possible and for this reason, we don't ship headers with new images. But the process can, in fact, take hours on some prehistoric SD card. BTW. We dropped official support for R1 since months - if an upgrade fails ...

I made a few tests - all those cards are operational on Clearfog with the same (mainline) kernel drivers. 01:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01) 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter wlp1s0 IEEE 802.11 ESSID:off/any Mode:Managed Access Point: Not-Associated Tx-Power=14 dBm Retry short limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off wlp2s0 IEEE 802.11 ESSID:off/any Mode:Managed Access Point: Not-Associated Tx-Power=0 dBm Retry short limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on There are different Espressobins out there so its possible that some card works, some doesn't. Cards can also be little different. Working: Qualcomm Atheros AR928X http://ix.io/101m Qualcomm Atheros QCA9565 http://ix.io/101s Not working: Detected but crashing Qualcomm Atheros AR93xx (9382/ar5bhb116) legacy: http://ix.io/101u mainline: http://ix.io/101G Undetected properly Qualcomm Atheros AR9380 (9380/ar5bxb112) Undetected at all QCA9880 AC

You mean https://github.com/armbian/build, default branch?

Not possible ... unless you are a super geek. Start with a clean Debian (or perhaps Ubuntu if they support it) image from the download section.

We provide two kernels for Espressobin. One is stock (the same as on Buildroot and other stock builds. Only with bugfixes and some 3rd party wireless drivers), while the other is a modern one. Both should work and they do work for me. Which Wireless card do you use and is it actually working on a stock kernel? Can you extract kernel configuration of this image? Edit: If 168c:0030 is AR9380 than it must work with Armbian. I have one around and it works. Probably only with most recent u-boot.

The official version is only one. This case here should not happen but it is also not critical. I already talked to Helios4 folks and an update will be rolled out as soon as I find the time (I guess not today since I am barely typing this). But this process is purposely not automatic. Someone has to test before pushing updated packages to the stable repository ...

I haven't noticed such troubles in general and if you use the main branch and not development, nothing critical has been changed.

If FA uses reference design and I believe they do, then you download latest armbian, go to armbian-config -> hardware and enable all USB ports. If this doesn't work, then there is could be something wrong with the board ... which I actually don't have and can't check. (I do have some engineering sample of this board but it is completely different)

Yes. But if both are the same version it should not upgrade unless forced or if you switch kernels between default and stable. In this case, you only get what is in the repository. You can also switch to the beta repository, which should be latest 4.14. ... but you lost "warranty"

Espressobin mPCI stack is not in a good shape and we have no resources to improve it. If this was not improved with the last u-boot update, then this won't change for a while. I also tested one of the most interesting cards (QCA9880/ath10) ... and it doesn't work. Use cards which we recommend/test. Development boards do not have BIOS. They have u-boot which take care of this job and that one was updated last week.

Then better just leave as is for next couple of months. Another alternative is to move NEXT to default and operate only default and dev for some time?

armbian-config is (beta) and known that it has some troubles in this area. We are changing networking - check this thread.