Igor

We are well aware that our support with tips and solutions can save you days, sometimes weeks and moths. But the problem is that we also have to invest time to recall, search, focus on the problem ... while you / public / users don't value this at all. Or in rare occasions. You think it's granted, but it's actually our family time/money that is going away for your/common gain. End users also doesn't support R&D at all, but you have a desire in top support, quick answers all the time, some even dare to demand and complain. Which is why we asks at least for a small compensation https://forum

Device tree blob https://elinux.org/Device_tree_future script.bin is Allwinner proprietary way, dead end we don't deal with for a long time. I don't know.

My C4 behaves better with latest u-boot. Its confusing, but @chewittgave me some tips to look into. Sadly time is the problem.

This feature is known to work on old BSP kernel (3.4.y) which this how-to is referring to and which we dropped a while ago. We can't afford to maintain big quantity of very different codebase and its pointless to support low quality outdated BSP kernel. At least not very long. Mainline kernel support for H3 is actually in quite good shape, but some features might not be supported yet. Or are broken. I think someone succeeded in bringing up TV out on modern kernel. Use forum search more.

Yes, it happens on random. Again.

Code difference is mainly in Allwinner specific areas which RT patch doesn't adjust. If you need more challenges that are aligned with our wishes - create and move diff between this fork and mainline to patches and change to mainline source.

Build script told you For sunxi we don't use mainline Linux directly: https://github.com/armbian/build/blob/master/config/sources/families/include/sunxi_common.inc#L16 There those tags doesn't exists. You will need to solve this differently. Quick way is to pick a ="commit:ID"

Aha - I know what you mean ... one time job / script to make them cleaner. And request only supply patches this way? Also represent stress which we have to minimise if possible - stretch over longer period. I propose to throw out warnings about patch quality if not met, but apply anyway the classical way? One can easily lost a lot of time not seeing warnings that patch hasn't been applied. Patches, user patches and patch creating are important part of the Armbian. So we should not kill any functionality or make it more complicated from any point of view.

You mean a debian src package? https://en.wikipedia.org/wiki/Debian_build_toolchain#Source_packages Well, this already works ... but not standard way. And users will always ask - even when works by the book This logic has to be brainstormed. I would go slow into any direction. @martinayotte @tparys @5kft Don't understand what you mean by that? Patches - if not broken - do apply without errors. Why do we need git am here? Do we need to create a git patch history?

I had numerous issues when using rclone in the past which eventually lead to dropping our main mirror which only had rclone capabilities. But what could in my network cause that? I am moving large amount of data via rsync all the time.

True. But it need to have a name Name should have association with where fixing what. But yet again we have to deal with exceptions. That is expected, yes. As they are added manually. https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh#L159-L163 I would say those exceptions should rather stay as is. We can't cover everything with the same logic. Or we can? AUFS for example has it own logic. We set apply from this and that kernel version. This part I don't quite understand. How to deal with

Broken SD card slot perhaps? You need serial console to determine if that is the case.

https://github.com/armbian/build https://docs.armbian.com/Developer-Guide_Build-Preparation/

I declined samples they want to send us, because we have too little support from them and you. This way: or by donating enough to hire people which will deal with this.

This is all what Armbian does regarding Chromium and IIRC in a last three years this would be the one and only complain about this problem. Since we don't maintain Chromium and since we have no means to oppose (one of the) biggest tech corporation on the world or support their products, Armbian scarce resources will do exactly nothing. Most likely its related to things you were already informed about. I don't see other explanation since it was fine until now. Which means you/we can't do nothing about and this is not Armbian fault. And I don't believe this has anything to