ATK

Any thing related Allwinner A20 SOC will go to "Allwinner A20 Forum section" 

Confirm that a fresh install of Armbian_21.08.3_Bananapipro_focal_current_5.10.60 does not get a visible sata connection (BananaPi Pro).
This cmd line followed by a reboot enables the sata (same is in first post, just all in one line).
apt install linux-image-current-sunxi=21.05.6 armbian-firmware=21.05.8 linux-dtb-current-sunxi=21.05.6  
Dieter
 
Hi again, 
more findings:
It is sufficient to downgrade the device tree:
apt install linux-dtb-current-sunxi=21.05.6 I had compared the kernel config (find current config in /proc/config.gz), no changes regarding sata. Only a very few changes, mostly adding drivers as module.
 
So far I had no time to compare the device tree yet. Someone wrote he did that but did not find relevant changes. Well, I hope he was wrong :-).
 
 
BTW: the next line will reverse the changes.
apt full-upgrade  
PS: Running a kernel with a different device tree is not recommend, I did it only to hunt down the issue a bit.
 
Dieter
 
And more info:
Some people wrote that these events show up in the syslog and searched in that direction.
ahci-sunxi 1c18000.sata: supply ahci not found, using dummy regulator ahci-sunxi 1c18000.sata: supply phy not found, using dummy regulator ahci-sunxi 1c18000.sata: supply target not found, using dummy regulator Since I was convinced these messages are normal, I double checked with working sata and they are there as well.
 
Dieter
 
Decompiled the DT, then compared.
This is a difference regarding sata:
sata@1c18000 { clocks = <0x02 0x31 0x02 0x7a>; compatible = "allwinner,sun4i-a10-ahci"; interrupts = <0x00 0x38 0x04>; phandle = <0x5f>; reg = <0x1c18000 0x1000>; status = "okay"; target-supply = <0x24>; }; This line is new in latest version:
target-supply = <0x24>; It is not unlikely that this line causes the issue.
The 0x24 points to item ahci-5v and that is disabled.
ahci-5v { compatible = "regulator-fixed"; enable-active-high; gpio = <0x19 0x01 0x08 0x00>; phandle = <0x24>; regulator-boot-on; regulator-max-microvolt = <0x4c4b40>; regulator-min-microvolt = <0x4c4b40>; regulator-name = "ahci-5v"; status = "disabled"; }; No change for this item between the versions.
I do not know how to enable it (yet). Any ideas ?
 
This is how I extracted the DT and decompiled:
copy "/sys/firmware/devicetree" to my worksation running "dtc --in-format fs base --out-format dts --out dt.dts --symbols --auto-alias --phandle both  --sort" use meld to compare both versions Dieter

Since we're now dealing with a few more H3 devices and some vendors also provide OS images and users get confused a small note regarding kernel situation with H3 at the moment and also an update regarding performance relevant settings (by tweaking these intelligently H3 devices might run multiple times faster!).
  Mainline kernel:   The linux-sunxi guys are doing a great job writing all the stuff necessary from scratch and sending it upstream so that H3 and boards are more and more supported by the stock linux kernel available from kernel.org. For us at Armbian the missing Ethernet driver for H3 was the showstopper that prevented us releasing Armbian images with kernel 4.x so far.    In the meantime or since we had to realize how horribly some H3 boards might overheat (BPi M2+ is currently the worst example but it turned out that NanoPi M1 and Beelink X2 behave the same) missing THS support in mainline kernel is another important reason that prevents Armbian releases for H3 boards. We tried to run the boards downclocked to just 816 MHz just to realize recently that BPi M2+ with specific test workloads has to throttle down to 240 MHz (and needs to kill CPU cores so under worst case conditions we could drive the M2+ only with 2 cores at 240 MHz which is a really bad joke -- so we need throttling working with mainline kernel to release Armbian vanilla images to the public)   BSP kernel:   So while we're testing with mainine kernel stuff from time to time all we now have to release to endusers are some variants of Allwinner's Android kernel for H3 devices (called BSP kernel -- BSP is for 'board support package', that's an ugly tarball with an 3.4.39 kernel Allwinner throws at manufacturers who want to create H3 devices).   Allwinner's 1st BSP kernel variant:   Allwinner published 3.4.39 Android kernel sources last year here. All the official OS images for Orange Pis rely on this stuff (still version 3.4.39 and not even a fix for the rootmydevice security issue). This BSP variant also shows somewhat strange throttling settings (not throttling down while still running on all 4 CPU cores but killing CPU cores one after another without bringing them ever back without a reboot). So be prepared that you get horrible performance results with these settings (that explains the horribly low performance scores that are published on phoronix.com for various H3 based Orange Pi boards)   Loboris' kernel:   The aforementioned kernel sources are basically the stuff Boris Lovosevic (loboris) used to provide the first useable OS images for Orange Pis. He did a really great job fixing tons of issues (eg. enabling GBit Ethernet on OPi Plus or 1-Wire, camera support and so on). Unfortunately he was member of team overclocking so with his so called dvfs settings (dynamic voltage frequency scaling) the Oranges were overvolted (to be able to provide overclocking) and showed all sorts of strange symptoms (insanely high temperatures and stability issues). But this wasn't related to kernel functionality, just settings influencing power supply to the SoC/CPU and enabled overclocking.   Yann Dirrson's fork:   When we at Armbian started supporting H3 boards we relied on different kernel sources (ssvb, one member of the linux-sunxi community used Allwinner's original BSP sources, patched Mali support in to create a small OS image being able to test DRAM reliability. Another linux-sunxi guy forked this kernel tree and patched in a few more stuff (also some of loboris' great work) so we started using this fork as our basis.   1st Armbian legacy kernel:   Igor immediately started to patch the horribly outdated 3.4.39 kernel up to the most recent 3.4.y version (3.4.110 back then IIRC) and we threw in a bunch of other patches to improve this and that. Also as the result of still ongoing efforts to maximize performance/throttling settings Armbian shipped with totally different thermal settings which led in the end to pretty good performance of the boards (since we refrained from overvolting and developed sane settings)   Alwinner's 2nd BSP kernel variant:   When FriendlyARM announced their H3 based NanoPi M1 they also released a newer H3 user manual and also a new BSP kernel variant they obviously both got from Allwinner in the meantime. Jernej maintaining the unofficial H3 OpenELEC fork looked immediately through and spotted a lot of changes.    2nd Armbian legacy kernel:   So we (Armbian and jernej/OpenELEC) decided to switch to this newer BSP kernel, Igor cleaned up some stuff and again rebased all patches (up to 3.4.112 IIRC) to the new kernel sources and we adopted all other patches that were still relevant (we could drop a few). This way we could solve the ugly kswapd bug that plagued us before (one CPU core 100% active and eating up memory) and if I understood correctly also some HDMI/display area improved a lot.   Currently only Armbian and Jernej's unofficial OpenELEC fork use this kernel with all our many patches on top (maybe a few hundred security relevant and also a lot of functionality improvements): https://github.com/igorpecovnik/lib/tree/master/patch/kernel/sun8i-default(currently exactly 112 rather large patches that add support for various hardware, new features, many fixes)   The SinoVoip experience:   While all this happened Foxconn/SinoVoip released their BPi M2+ (a close clone of Orange Pi PC/Plus) and decided to rely on loboris' unmaintained and outdated 3.4.39 kernel for whatever reasons. Since BPi M2+ doesn't use the superiour voltage regulator used on the bigger Oranges at least no overvolting/overclocking is possible here. But for yet unknown reasons this board overheats terribly so we at Armbian adjusted our throttling settings very very low so be prepared that with official SinoVoip OS images strange things might happen when you put some load on this board.   Further improvements:   In the meantime we further improved thermal/performance behaviour and patched also the kernel so that when the board recovers from heavy overheating killed CPU cores are brought back when temperatures are normal again. In addition to that we provide way more cpufreq steps to allow finetuning throttling behaviour based on environmental conditions (as example: when you're running your device in a small enclosure more throttling will occur and you will benefit from more cpufreq steps in lower regions around 900-1000 MHz. If you go the other route and add a good heatsink and some airflow through a fan Armbian will provide you with a tool able to unlook higher cpufreq steps later this year on supported boards)   Summary:   Now a short overview about kernel situation combined with thermal/performance settings: Official Orange Pi images from Xunlong: 3.4.39, no rootmydevice fix, tons of security fixes missing, performance issues after medium load due to killed CPU cores Orange Pi images from loboris: 3.4.39, no rootmydevice fix, tons of security fixes missing, thermal/stability problems due to overvolting, missing sane cpufreq steps (not possible to use 1.3GHz for example) Official Banana Pi M2+ images from SinoVoip: 3.4.39, rootmydevice fixed, tons of security fixes missing, performance issues after higher load due to killed CPU cores Official NanoPi M1 images from FriendlyARM: 3.4.39, still no rootmydevice fix, tons of security fixes missing, unknown status regarding thermal/performance settings Armbian/OpenELEC: 3.4.112, rootmydevice fixed within hours (not an issue on OpenELEC), applied all available fixes from 3.4.y LTS release, constantly improving thermal settings (which means: performance)