Werner

tobetter's Gnome-wayland is the best build I've ever used out of my 2 SBC's.  Rock64 and the N2+.   Just got the N2+ last week and it's as good as folks are saying so far.   So today I built Armbian Deb bullseye-dev for it and I thought you might like to know how it went.
 
Flashed to sdcard booted first try.   Same as the Ubu focal-dev last week.   Both run great but the nic on the UBU broke as you know using armbian-config to upgrade it to nightly.   The bullseye nic won't download during first upgrade faster than 1-10k p/s.
Popped a wireless nic in , finished upgrade and rebooted.   Solid blue/red lights no boot.   Maybe they are related.
 
Figured you could use the info.  When I get free time I like to experiment with cutting edge builds of a few arm distro's.  
FYI   I'm waiting for a patch set for mainline kernel on Manjaro hoping panfrost gets support working soon through mesa.
At this time the tobetter libMali drivers seem the way to go until then.  I will attempt an Armbian KDE build/install when panfrost/mesa/mainline is more advanced.  
 
Cheers, Archetech
 
Update  8-13-20         Thanks to the dev team I can report that my N2+ is now officially OC'ed to 2100  vs 1800 Mhz and idles at 29 C.    Lanefu built the latest Boot stuff  and I hand edited the boot.ini to match the new dual use- n2 and plus one at github.  Sadly we confirmed the nic can't receive well at all.   Looking forward to more progess on this SBC.

And maybe take a course in how-to-choose-a-proper-topic-title

I soldered these to my PowerSupply, you could as well solder it to an USB-Connector... DC Power Plug Male Connector 4.0x1.7mm Male Socket With Cord Cable,DC pigtail 4.0/1.7mm /Free shipping/10PCS
US $6.64 / lot (10 pieces)  https://www.aliexpress.com/item/1927392841.html
 
I didn't test them on "how many cycles" they last, but I like the sealed barrel. To solder the barrel was always the weak spot to me.

Well that flag isn't documented. I'll fix that.

The two worst things that could happen are either the compile failes or the board does not boot after kernel replacement. So if possible make a backup of your sd card first, just in case...
 
Also take note that running a custom kernel voids support from Armbian side

Not possible via apt or any other way to sideload.
However making a working kernel package for your board is fairly easy using the build script: https://github.com/armbian/build
Clone, run, select your board and that you wish to adjust the kernel config. Done. The script will handle the rest.

Maybe you wanna to share your success by commiting a PR to https://github.com/armbian/build/blob/master/config/kernel/linux-rk3399-legacy.config ?
 

Hi Igor,
 
My validating status still remains. I thought it would go out after 7 days.
 
Thanks,
Wasanka

Done. Now moving topics (with link leaving there) to this forum is needed. In case someone finds time, otherwise I'll do it later.
 
Readability is also a matter, not just logical mixing. Here perhaps simply merging H6 into H5/A64 won't be that bad and its even logical.
 

Agree. That should stay as is. It should be there for "urgent, stupid things or combination of both with a bad luck. Most boards doesn't start due to bad powering and that will not just go away. But we can add a restriction that post have to be approve by moderator in any case ... ?
 
 
Yeah.

The DEV branch is now 5.8.y, commmitted this morning ...

I'm not deeply familiar with those boards, but in doing some really quick checks it looks like indeed the hardware doesn't provide any means to get more voltage to the CPU, which means they wouldn't work...
 
 
Yes, I've found in testing that it appears that the H2+/H3 can be pushed harder than the H5...  I tested 1.3GHz on a couple H5s and couldn't get them stable above 1.2GHz (some other ones are fine, however).  My OPi Zero has no issue, however...it's interesting.  Also, note that with the way I created these overlays the passive cooling maps work properly, which means that the boards will clock down at the appropriate temperature thresholds, improving stability.  You'll note that while your board clocked to 1368MHz early on, it spent the bulk of its time at 1200MHz due to thermals.  This is good - it provides stability and will allow the board to clock to the maximum when it can.

https://duckduckgo.com/?q=root+console+auto+login+bionic&t=ffab&ia=web
2nd result and don't forget to check with https://www.armbian.com/donate/ for the wasted time

I would have been back sooner, but being new on the forum, it seemed to not let me post more than once in 24 hours.  Or something.
 
But I was busy with this most of yesterday in an interesting way.  I gave up (for now anyway) doing this on my Fedora Desktop.  What I did was to download Armbian for my Orange Pi PC 2, put it on an SD card and run it on the Orange Pi.  Then I used armbian-config to download kernel sources, which worked just fine, placing them in /usr/src.  Then I could remove the SD card, mount it on my desktop and copy the sources for my convenience.
 
Then I put the SD card back into the Orange Pi, fired it up, did a cd to /usr/src/linux-source-5.4.43-sunxi64 and typed "make".   It plowed away for 10 hours or more (it finished during the night when I was asleep).  It hung once in the afternoon requiring a reboot and restarting make.  The advantage of this for me, is the build leaves object files (*.o) in the source tree letting me know at a glance just what source files were involved in the build.  This has proven invaluable for me in the past when rummaging around in the linux sources.  Now I can pull that SD card again and copy these files to my desktop for study.
 
It would be nice to do as Werner says and be able to grab the sources and patch them on my desktop.  I have the idea of studying the Armbian build system and reproducing parts of it in Python to liberate it from being debian dependent -- but using the actual target system was the easy way.
 
So thanks for the advice.  I still haven't looked at why the R_WDOG patch failed, but I figure that is something that someone else will run into and sort out.
 
Thanks again.
 
   Tom

From my feel most of those are crap anyways and provide some weird/useles soft-raid solutions which can be realised via mdadm as well or even rely on that...

One of the cards i have costed around 80euro, and it is almost useless.. The cheap cards is the best here, in my opinion.

@wolf7250 - here you go, here is a couple i got home.

Delock 4 port SATA PCI Express Card - Marvell 88SE9215 - Works out of the box.
 
StarTech.com 4 Port PCI Express SATA III 6Gbps RAID Controller Card with Heatsink (PCIe SATA 3 Controller Adapter (PEXSAT34RH), Styreenhed til lagring (RAID), 4 Kanal, SATA 6Gb/s lavprofil, 600 MBps, RAID 0, 1, 10, JBOD, PCIe 2.0 x2, for P/N: ST521PMINT - Marvell 88SE9230) - Some problems. But i did mange to get it working.

DeLOCK - Lagringskontrol - SATA 6Gb/s - 600 MBps - RAID 0, 1, 10 - PCIe 2.0 x4 (Producent: DeLOCK | Model-nr.: DEL-89395 - Marvell 88SE9215) - Some probs. But did mange to get it working.

Ziyituod PCIe SATA Card, 4 Port (SA3014 - Marvell 9215) Works out of the box.

Yes plug them into another linux box and read up on mdraid / mdadm recovery. https://raid.wiki.kernel.org/index.php/RAID_Recovery

@wolf7250 - That card from pine64 should be avoided in my opinion, i did only have trubles with it.  I have only cards with Marvell chipset, and i found out buy a simple card not a fancy raid card - less problems. I can later today find my different cards and name them for you.

Done!  https://github.com/armbian/build/commit/91156f11922c00227211d1d765512f09b6398d1a
 
verbosity=1 bootlogo=false console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost2 usbhost3 cpu-clock-1.368GHz-1.3v rootdev=UUID=84d54d78-1a45-4366-9776-2fa013e0e1e6 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 5.44 ms. hardware limits: 480 MHz - 1.37 GHz available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.37 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:89.25%, 648 MHz:0.49%, 816 MHz:1.19%, 960 MHz:0.01%, 1.01 GHz:3.74%, 1.06 GHz:0.01%, 1.10 GHz:0.86%, 1.15 GHz:0.01%, 1.20 GHz:0.82%, 1.22 GHz:0.01%, 1.25 GHz:0.73%, 1.30 GHz:0.01%, 1.37 GHz:2.89% (287)  

@Adrian Cable - I made the changes for sunxi-current and pushed to the repo:  https://github.com/armbian/build/commit/b2adb2935b4dcee57c982a1447de8cf75760dd2a.  This change adds a new boot overlay for the sun8i-h3 that enables a maximum of 1.3GHz at a CPU core voltage of 1.3v.  If you use this overlay, I strongly recommend you try driving the board hard to ensure stability (e.g., "stress --cpu 4", etc.)  Historically on most of my boards the maximum I could push to was 1.2GHz at 1.3v, which is why I added a 1.2GHz overlay for the H5 (and I could only get to 1.368GHz w/a 1.4v core voltage).  I can do the same for the H3, but am short on time atm.  I'll also add this overlay to sunxi-legacy as well, but I won't be able to get to this later.
 
I tested this on one of my H3 boards w/a max CPU voltage of 1.3v:
 
/boot/armbianEnv.txt (note the addition of "cpu-clock-1.3GHz-1.3v" to the "overlays=" line):
verbosity=7 logo=disabled console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost0 usbhost1 usbhost2 uart1 cpu-clock-1.3GHz-1.3v rootdev=UUID=3ad712a7-75cb-4ac1-8cfa-dbb67df8f239 rootfstype=f2fs extraargs=net.ifnames=0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
After booting with this overlay, from "cpufreq-info", w/everything else at the defaults, maximum clock rate is now 1.30GHz:
analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 5.44 ms. hardware limits: 480 MHz - 1.30 GHz available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:96.94%, 648 MHz:0.35%, 816 MHz:0.04%, 960 MHz:0.03%, 1.01 GHz:0.03%, 1.06 GHz:0.02%, 1.10 GHz:0.02%, 1.15 GHz:0.03%, 1.20 GHz:0.02%, 1.22 GHz:0.01%, 1.25 GHz:0.01%, 1.30 GHz:2.50% (253) Please give this a try and let me know how it goes   If 1.3GHz is unstable, I'll try to expedite adding the 1.2GHz overlay as well.
 

Because the opp table in the DTs are common and used for all H3/H5 boards, not just your specific OPi Zero.  The CPU regulator voltage defines the maximum clock rate available, specific to each board.
 
 
Actually this behavior is completely correct - it's how the CPU clock system is defined.  You do not want to make a general PR to increase the default clocks for lower voltages here because this will introduce instabilities across all other AW-based boards (!).
 
There is a very easy way to enable this, however - you can use an overclock overlay.  I created a few of these a couple of years ago; see this thread for more information: 
 
 
Now I just noticed that this patch apparently didn't make it over to the new sunxi-current branch (5.7); I'll fix this.  I also used the H5 prefix for this - I haven't tried it on an H3, but given the common opp table it should work.  I'll take a look at cleaning this up now for sunxi-current and will post back.

Oh ! I've completely forgot about the hack, I've forgot to add it in /etc/rc.local of the 5.8.y build ... I will check now ...
 
EDIT: Thanks for the reminder : it is not freezing any more, at least until now !

Werner - that's a great idea! In case you or others want to test as well, here are my corrected lines in the DTS for the OPi Zero:
 
 
                opp-1104000000 {
                        opp-hz = < 0x00 0x41cdb400 >;
                        opp-microvolt = < 0x13d620 0x13d620 0x13d620 >;
                        clock-latency-ns = < 0x3b9b0 >;
                };
                opp-1200000000 {
                        opp-hz = < 0x00 0x47868c00 >;
                        opp-microvolt = < 0x13d620 0x13d620 0x13d620 >;
                        clock-latency-ns = < 0x3b9b0 >;
                };
                opp-1296000000 {
                        opp-hz = < 0x00 0x4d3f6400 >;
                        opp-microvolt = < 0x13d620 0x13d620 0x13d620 >;
                        clock-latency-ns = < 0x3b9b0 >;
                };
                opp-1368000000 {
                        opp-hz = < 0x00 0x518a0600 >;
                        opp-microvolt = < 0x13d620 0x13d620 0x13d620 >;
                        clock-latency-ns = < 0x3b9b0 >;
                };
 
Running now at 1.368GHz and hasn't crashed. I'm going to try stress etc. and see what happens.
 
-Adrian

Hi Tido,
 
thanks for clarification of root or root privileges.
i didn't know this, sorry.
 
I will read the README.md and start over again on the weekend.
 
 
Ich hoffe...

https://docs.google.com/spreadsheets/d/11iid35ZGlTws1XOqSMJIw0y7nK6bNdpqVq6I4JFihuo/edit?usp=sharing