Werner

Ever since patchfolders were created for different branches and different board families it has become more and more a nightmare to maintain these folders and keep them clean.
 
Instead of taking the approach to clear one or more of these folders by myself, last but not least due to lack of necessary skills, I was thinking maybe I can provide some tools that make such tasks a little easier for somebody else.
Last but not least was (and still is) this a perfect opportunity to pratice with my quite new Python skills.
 
https://github.com/EvilOlaf/refactorpatches
 
What this script basically does is break down all patches in a certain folder and check which files are targeted by each individual diff (if you choose to split them up) and sort the output by the target file.
This way it should be an easy thing to merge patches that affect the same file and therefore it is no longer necessary to take care about the order to apply them.
 
Requirements from apt: patchutils, python3
Requirements from Pypi: none but just make sure the prettytable.py is in the same folder as main refactor.py.
 
I have tested this with random patch folders for kernel patches and for what it is expected to do at the current state it seems to just work as it should.
There is still a ton of room for improvements.
 
Let me know what do you think or if it is useful at all. Even if it is not I had fun coding and using Python
 

Fixed!  I marked this as Done (both sunxi-current and sunxi-dev, tested on both for H5 and H3) 

@Igor - I just checked in a new patch that fixes the thermal throttling issues (see https://github.com/armbian/build/commit/cc55d03a7b306e80f6fae1e16de1942af5fe9701).  I have tested it extensively on the H5 (Nano Pi NEO2 Black) and throttling works great now.
 
Example run after several minutes of "cpuburn-a53":
 
The new patch includes the same changes for the H3, and I tested on an Orange Pi Zero H2+ with no heatsink, using both "stress" and "cpuburn-a7", and it works great.  Here's an example run using "cpuburn-a7":
 
 

All these messages show us, that you network isnt working or isnt working correct.
 
How did you configure your network? Network-Manager? /etc/network/interfaces? armbian-config?
 
Can you ping 8.8.8.8?
Can you ping armbian.com?
What says ifconfig for eth0 or wlan0?
whats the IP of your gateway/DNS?
what is the content of /etc/resolv.conf (when not using network-manager)
 

I don't think this was @Werner 's intention.  IIRC, since Beelink where they just replace parts we agreed that TV-Boxes are CSC only.
Let us be consistent, do not invent anything new that is arleady there, and just place a line below the TV-Box-Section as Werner suggested at the begin.
SUPPORTED
SUITABLE FOR TESTING (WIP)
SUPPORT ENDED (EOS)
NO OFFICIAL SUPPORT (CSC) are devices which are supported by the 3rd party. We usually don’t have hardware samples nor conduct any tests but they might work. There is no support whatsoever.
 
I copied that from the download FAQ section.
I still hate TLA's  (three-letter acronym) without explanation. I cannot remember what CSC stands for !   and!!! and it is not explained on the FAQ, what is a bloody FAQ for if it raises a question.
 

And within that forums create a hint like the Allwinner H6 forums had in this place:

@Declan Yes it's a failing PSU.
 
Right now it's difficult for us to send spare parts because of lockdown in Singapore.
 
Plus most probably will be faster and cheaper (if you account shipping fees) to order a substitute model on amazon.
 
Here is the one we recommend and have been tested : https://www.amazon.com/dp/B07NCG1P8X
 
I'm not sure what's your country or residence so you might have to look for the same model on the right marketplace country.
 
Hope it helps.
 

... as we are drowning in the flow of (mainly unrelated to our work) questions that are coming up every day.
 
 
Welcome to the battleground 
 
If you would asked before whether is it worth fighting it, I would save you a week ... I have that kind of experiences which I am glad to share with you. This know-how is manifested in our labels: "WIP", "COMMUNITY SUPPORT", "SUPPORT", "EOS". For your own good, you don't want to ignore them, but do ignore sales messages, "review" sites, users hype fueled by impressions and marketing, ...
 
 
Use supported hardware. Even that is not a guarantee, but it's a much more solid ground. A place where one person (with 20-30 years of general computer / Linux experience) can do something useful. In this case, its useless since lower level support is fragile, immature and unstable. If you want all this to work, you have to fix many things - if you have seniority in this field and you will need to find some friends. Alone is always hard. You have to lead and be a developer. On our forum you can find useful clues which will save you time ...
 
 
Perhaps they are useless for your battle, but it might save somebody else's week.

We seriously considered dropping support since there was much frustration related to this board. In general we want to provide stable Linux, which is hard and expensive with this board, due to cheap design and design experimenting. We have three different revisions floating around and none is really working stable. If we fix one, we might have to break other two ... 
 
 
Can be only a marketing cliche if all other terms for industrial grade hardware are not met.

Fixes pushed.

?

It is running. The log isn't full with Hex-code. Thank!

This could be an option for Windows users if...
this is set when you download it and it is meant that it re-reads to verify that the writing is error free. Just like discussed before in this thread.  Plus this function...
 
https://forum.armbian.com/topic/13421-need-your-help-what-else-beside-etcher/?do=findComment&comment=98830
 

I manually added this to the already existing patch (just under the display engine definition, be sure to modify the diff notation if you try it yourself):
+&gpu { + mali-supply = <&reg_dcdcc>; + status = "okay"; +}; + With this little modification in place, I compiled the kernel and u-boot packages again. Now I have the relevant entries that Werner has and glxinfo reports panfrost is in use. I'll test more after adjusting the devfreq parameters.
 
EDIT: If I'm not mistaken, LibreELEC already has a patch that does the same thing but the one in Armbian needs to be adjusted (until the code is mainlined, obviously).

that's super awesome @Igor!

One test board from this topic will be installed at this location and another at my desk and elsewhere. We will try to join them.

After test boards come, some more coding has to be done. Also to have better overview over the test process. Currenlty test results looks like this: https://dl.armbian.com/_test-reports/2020-05-03_15.57.22.html Its still more or less a data collection without any proper analysis ...

Hey there,
 
most of you probably already know about the Armbian IRC channel that came back to live a while ago. If not pause reading here and check out this topic and resume here after done:
 
Hey, you found your way back. Nice.
 
As stated I want to give away IRC bouncers for whoever likes to have one. It is not bound to Freenode (although it will come pre-configured for #armbian and I would appreciate to see you hang around there ). You are free to connect any IRC network you want as long as it is IPv6 capable.
 
You don't know what a bouncer is? Pause reading and check https://en.wikipedia.org/wiki/BNC_(software)
 
As a bonus I offer to anybody who donates to the Armbian project by subscription (check https://forum.armbian.com/subscriptions/) their own exclusive vhost which can contain anything you like (as long as it does not violate common sense, the target irc services rules, does not contain offense ecetera ecetera.... you know the deal). The subscription does not need to be recurring (highly recommended though ), even one time is enough and will help the project. As long as I saw the donator badge once below your nick it will suffice.
 
Some technical: The bouncer software is znc 1.8.1. You can configure it via webinterface or with commands, whatever you prefer. Check https://wiki.znc.in/ZNC.
Everything is running on a small VPS generously donated by Fosshost. Host system is Ubuntu Focal.
 
(Legal note: I do not get any reward from this nor do I want that. I recurringly donate to the project myself for quite a while now because I think it is worth it and I offer this service simply because I can and hey, maybe somebody feels comfortable spending a few bucks to get a free bouncer ideally for a few years or the rest of their lifes, whatever comes first , and also take some weight from Igor's shoulders. Service is free of charge but no warranty or uptime, accessibility, usability and so on. Consider it as beta. I reserve one's right to reject a demanded vhost from a donator for no reason if I do not feel comfortable with since I take the risk for legal complains.)
 
Interested? Simply drop me a message via forums and I will check back with you: https://forum.armbian.com/messenger/compose/?to=9032
 
Werner
 
 
PS: If you do not trust me but what a bouncer anyways, I recommend searching for LunarBNC. He has a decent service too

This might be due to the lack of some YUV configurations support in the Rockchip DRM drivers used in mainline kernels.
I'll try some new HDMI patches next week, against mainline kernels, see if that resolve these kind of situations.

Mainline kernel is known to be unstable for this board
Legacy is the way to go for now if you want it stable.

These are the 2 patches we ended up with. With thanks to everyone at on the linux-sunxi irc, particularly megi.
 
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c index 6b636362379e..ca55c2ae999d 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c @@ -23,15 +23,21 @@ #include "ccu-sun8i-h3.h" -static SUNXI_CCU_NKMP_WITH_GATE_LOCK(pll_cpux_clk, "pll-cpux", -                "osc24M", 0x000, -                8, 5,  /* N */ -                4, 2,  /* K */ -                0, 2,  /* M */ -                16, 2, /* P */ -                BIT(31),   /* gate */ -                BIT(28),   /* lock */ -                CLK_SET_RATE_UNGATE); +static struct ccu_nkmp pll_cpux_clk = { +   .enable     = BIT(31), +   .lock       = BIT(28), +   .n      = _SUNXI_CCU_MULT(8, 5), +   .k      = _SUNXI_CCU_MULT(4, 2), +   .m      = _SUNXI_CCU_DIV_MAX(0, 2, 1), +   .p      = _SUNXI_CCU_DIV_MAX(16, 2, 1), +   .common     = { +       .reg        = 0x000, +       .hw.init    = CLK_HW_INIT("pll-cpux", +                    "osc24M", +                    &ccu_nkmp_ops, +                    CLK_SET_RATE_UNGATE), +   }, +}; /* * The Audio PLL is supposed to have 4 outputs: 3 fixed factors from  
 
 
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c index 5e7e9cccc172..609e889cae3c 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c @@ -1129,20 +1129,6 @@ static const struct sunxi_ccu_desc sun50i_h5_ccu_desc = {    .num_resets = ARRAY_SIZE(sun50i_h5_ccu_resets), }; -static struct ccu_pll_nb sun8i_h3_pll_cpu_nb = { -   .common = &pll_cpux_clk.common, -   /* copy from pll_cpux_clk */ -   .enable = BIT(31), -   .lock   = BIT(28), -}; - -static struct ccu_mux_nb sun8i_h3_cpu_nb = { -   .common     = &cpux_clk.common, -   .cm     = &cpux_clk.mux, -   .delay_us   = 1, /* > 8 clock cycles at 24 MHz */ -   .bypass_index   = 1, /* index of 24 MHz oscillator */ -}; - static void __init sunxi_h3_h5_ccu_init(struct device_node *node,                    const struct sunxi_ccu_desc *desc) { @@ -1161,13 +1147,6 @@ static void __init sunxi_h3_h5_ccu_init(struct device_node *node,    writel(val | (0 << 16), reg + SUN8I_H3_PLL_AUDIO_REG);    sunxi_ccu_probe(node, reg, desc); - -   /* Gate then ungate PLL CPU after any rate changes */ -   ccu_pll_notifier_register(&sun8i_h3_pll_cpu_nb); - -   /* Reparent CPU during PLL CPU rate changes */ -   ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk, -                &sun8i_h3_cpu_nb); } static void __init sun8i_h3_ccu_setup(struct device_node *node)  
You may also need to decrease the DDR frequency by 24Mhz in uboot on some boards. No binning on H3 chips, some are inferior.
 
This is not mainlined. Nor am I aware of any effort being put into pushing them upstream.
 
No rights reserved by me. As always apply at your own risk, neither me or my employers provide you with any guarantees.

https://github.com/armbian/documentation/pull/70

https://github.com/armbian/documentation/pull/70

Spoiler inserted.

95% of config options from that link are not in the menu since menu is there to do minimal steps which you should do to achieve what you want: choose to recompile kernel, enable staging drivers and this fbtft and wait that it finishes.
 
You choose to go the complicated way where things can get messy  Armbian Linux is in a good state, better that many Linux distros out there but its not automotive grade Linux as no free Linux is. If things doesn't go the way you want, you will have to fix them. Go rather recommended way. It should work, if drivers are O.K.
 
I do understand that recompiling the module out of the tree perhaps with DKMS is the best / desired way ... but we still manage lots of kernels with way too small resources. We recently did a lot of improvements in this area, but I guess the task is not fully done yet. Perhaps this can be related to the fact that drivers come from a staging areas, which nobody care for its quality yet.

Looking interesting, indeed. Just noticed in the comments the Armbian boys already got in touch with them