Igor

IIRC why we add this make scripts is ... most/many wireless drivers failed to build without running make scripts first. And people start to complain ... and we found a "solution". I think we have to keep this, just need to fix it properly and if possible without too much hassle.

Why would you want to do that? Not enough bugs?

Well. This workaround is since early days and its a step forward from not working at all to yes, you can use headers. We support a lot of different kernels, which are a decade apart. Stock Debian has a very simple job here, fixing one script while we can do just that. I agree that your proposal would be better but ... we are just a few vs "1000 issues". If someone can make and test on mainline I can port this to others ... when I finish operation "sand castle" Wrote on mobile

Good catch. Now we need to add it here (+ all other source packaging patches) and test. This method is picky on a shell and it doesn't work everywhere. It has to be done a bit differently.

It is mostly enabled by default. If not, check this example: https://github.com/armbian/build/blob/1d18b1ea1b51236acba56b3f234334ed8ef062f4/patch/kernel/sunxi-next/add_otg_neoair.patch

If you were editing something outside user area, this is normal. It will not change branches ... and overwrite your changes. Perhaps we need to add another warning.

I am not sure if this is what you want to know, but: - Debian.org or Ubuntu.com officially does not support any of those boards/boxes, - Armbian userspace has many small but vital performance or security adjustments, - Armbian fancy some kernel development and a lot of its maintaining. Debian relies on upstream sources for ARM hardware which can be years behind and/or lack of many functions, - Armbian userspace is lean, clean but 100% Debian (or Ubuntu) compatible - many stock Debian bugs are fixed on the way, "better than original :)" - a build system is a central part of this whole ecosystem. You can DIY. Debian much harder. - dedicated support forums per boards/boxes - plug and play vs. complicated install scenarios on Stock Debian - unified development scenarios and user experience vs. mess of different setup instructions scattered all around I must have forgotten many other important points

This console is n/a at boot time. You need to attach a normal serial console to those 3 pins to get u-boot output.

AIR image has disabled ethernet ... but you can try to enable it. I don't recall if that is all. We merge images when it's possible (without regressions) and if we find the time. In this case, you will need to play with board configuration (DTB) and u-boot settings (to enable eMMC support).

Can you attach microUSB serial console and paste the output? If any.

It will boot but: - you might not see eMMC (Air) - wireless might not work (both)

https://docs.armbian.com/Developer-Guide_Build-Options/

This must be something else. I own Lime2 without eMMC and it used to work with such configuration. Board has NAND but that should be irrelevant. Since I am out of office, I can't assist very well. Can you try booting this image: https://dl.armbian.com/lime2/Ubuntu_bionic_next_nightly.7z (we only create one test image which is Ubuntu. To hunt many possible userspace bugs at the same time) Manual u-boot compile and install: http://linux-sunxi.org/Mainline_U-Boot (you still might need to add "some" patches)

OK. One more thing to try out is switching to DEV branch in case of instability. It's unpatched mainline kernel, master branch, 4.18.RC*. You might not have a screen (get serial console) or board might not boot at all due to missing support. But some boards are present by default, with basic support ... worthy reference to find out if possible problems are within our patch set or are already in an upstream kernel source.

Debian testing is not supported. We have enough problems without that. You are welcome to discuss this further in the general area.

We only support Armbian builds here.

Ubuntu Bionic? It has plenty of (upstream) bugs and that is the reason we don't support it.

4.17.y is still in works. This might be worth reading:

If you choose to freeze from armbian-config, this should also be frozen. Then it could be a problem with upstream changes - check which packages, that might be related, are changed. No other ideas.

In that case further u-boot patching will be required. It's important to catch serial console logs in case it doesn't boot. We might fix that too.

Ubuntu Bionic is not yet supported since there are still small (upstream) bugs, which are hard to fix with our resources ... Its under testing and can't serve as a proper reference point. Try building Debian Stretch Desktop to test your build system.

I found the source of the problem. A few patches went missing in a transition from 4.16 back to 4.14 ... Fixed with this commit: https://github.com/armbian/build/commit/fbb57527107e3633741aef378da7e29447f538f9

Those BSP kernels are usually in a pretty bad state. You can only expect more troubles and certainly less support than here. Kernel 4.14.y works well and also SPDIF, which I assume has some value in this case, while it is (was?) broken in more recent kernels. I will try to check later today again what is causing this problem.

The problem is most likely in the BSP package, where are all those startup scripts are: linux-root-xenial-orangepiwin

Somebody else will need to verify this. Don't have access to this particular hardware for another two weeks.