Igor

You will not get commit rights, so you will not be able to break anything You can try to work on some features which were not be addressed and when you have a working solution, patch, you send it to Github as PR. I am just pointing you to the latest sources, that you will not deal with something that has already been solved. It is true in both cases. On build script branch sunxi-4.18, NEXT was already moved to 4.17.y, while master branch have NEXT on 4.14.y and DEV on 4.17.y or 4.18RC ... it doesn't matter. Just read my post once again

This is present only on stock Allwinner kernel. For H3 we have images based on such kernels, while for H5 we skip that kernel due to overall low quality.

You can proceed with my link and build the driver since its apparently 8192EU, which is covered by our example. In case you don't get proper headers, you will need to switch to a nightly repository. In case our recipe doesn't work, proceed this way: https://www.google.si/search?q=2001%3A3319 Remember just that headers package name at armbian is not the same as on x86/generic install. So use our armbian-config method of isntalling. That's all help you can get here. Other problems are related to the driver sources ... which is out of our power anyway.

Well, two things are essential: lsusb to see ID of the chip kernel version It's possible that this wifi is not supported, which is obvious since you are asking here, and do it this way: https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-build-a-wireless-driver

Aha, we need to push an update ... to fix this problem. It's still present on old builds. Paste dmesg somewhere with an attached adaptor.

There are too little informations to tell you anything. You always provide system logs, otherwise, most likely, nobody will even try to help you: armbianmonitor -u

Aha. I am working on an Allwinner patches cleanup. Perhaps you could join? https://github.com/armbian/build/tree/sunxi-4.18 I haven't try to build H6 images yet, but I think you need to enable NEXT in board configuration since we only have NEXT kernel, v. 4.17.y ... 4.18.y when it's ready. This whole part will be merged into master when current regressions are solved and when its tested well enough.

Where did you find this? We don't have it.

Yes. Just use an image for Orange Pi 2e. If your eMMC is not seen under /proc/partitions ... it's dead. If you see it, try to fsck and then mount ... SD cars is usually /dev/mmcblk0 and /dev/mmcblk1 eMMC or vice versa. Just try to mount its first and only partition: mount /dev/mmcblk0p1 /mnt

No, that is irrelevant and btw. Ubuntu 18 is also packed with bugs but Canonical sell it as stable. Do we fix their bugs? Few of them we did but we can't fix them all. We are just a few people and we can't afford to do that in such scale. As you can see even a big company with a bunch of full-time engineers cannot do that. A switch is in the pipeline. We are waiting for slots of our free time. This is very limited lately and we have little options to do anything in this area. I would like to do or see more tests before pushing out an update. We can't afford that it doesn't boot after an upgrade since support is also extremely limited and our direct cost. That is also the reason why Ubuntu 18 is labeled testing.

First type: armbianmonitor -u that we have a bigger picture.

Sometimes it took a while to see the obvious It's also not a perfect solution but it's better than digging into the broken code. Even here I had a few troubles and I hope image works and I hope also MALI works.

Try adding to /boot/armbianEnv.txt extraarg=thiswatchdogparameter=value Wrote on mobile

Mainline support is under development and it doesn't work very well. In case you find something not working ... nobody will listen. If that is ok, here are some test builds: https://dl.armbian.com/rock64/nightly/

https://github.com/armbian/build/commit/fab979feeaac093494ca29a17000989d4970483f Tinker sources restored to this. Building works, haven't manage to boot the board yet.

Why don't you use full virtualization then? Virtualbox for example? Just remember that this will be slow Get rather some used, Intel I7 4790K, pre/previous generation gaming PC without a dedicated graphics card. It will be way more bang.

We stopped to deal with this kernel (3.4.y) a long time ago and you will not find many people around that still do something about it. We fixed a ton of issues but it's impossible to fix them all with resources that are around. Fixes that were discovered are usually implemented. That's what our project essentially do. Virtually all devs are working only on a modern kernel, (4.17.y ->), which will soon cover most of the functionality. Actually, when video/3D acceleration is working, these old kernel images are going to be trashed. We keep them solo for multimedia capabilities. This is an old issue which is gone from my head so rather try to do some search for a possible solution.

What about starting with this: https://apt.armbian.com/pool/main/l/linux-source-4.4.120-default-rockchip/

If we are talking about u-boot patch then yes. It can be per board, for kernel it has to be inside board dt or via some hack. But first we need to find out where Wrote on mobile

They probably use a patch somewhere we don't have. Do we have the same u-boot / kernel? Perhaps trying with the same kernel config, device tree, ...

Edit /etc/default/armbian-zram and disable it.

Please pay attention during next kernel updates. I am slowly enabling functions which could potentially cause problems.

I found another solution

Recommended: https://forum.armbian.com/topic/5246-wifi-performance-benchmark-test/?do=findComment&comment=42408

I haven't noticed this problem. Without digging in, I can't tell and I will not be digging in soon due to "out of office". Try to use stock u-boot (or our older ones) if that changes anything otherwise a small and stupid bash startup script can serve as a workaround until we fix this.