Armbian doesnt seem to see sata harddrives.

[prahal]

@Popolon indeed this issue rot for a long time. I cleaned up my backlog to have more time for armbian. Also I still have quite a few processes to learn about armbian board maintenance still to this day. 

 

But you confirm that with mainline 6.12 all is fine ? But, indeed no HDMI out and no audio. I still have a patch for mainline 6.12 in the pipe about a race condition between SATA chip and nvme as far as I remind. I will prioritize data vendor kernel debugging if this mainline patch is not required (and indeed mainline still lacks any multimedia capability, this might be a showstopper for most users) even though I am close to complete testing and send PR for this one.

 

As of now I have confirmed that this mainline patch set does not help vendor as the vendor branch has a hack that workaround the issue that mainline faces about this SATA/nvme race.

 

[prahal]

On 2/20/2025 at 11:24 PM, sdyspb said:

Just look at this from datasheet and schematic perspective - ASM1164 needs SSC if SRIS is enabled, but according to datasheet of clock generator there is no SSC, so the original schem is not correct. There are three solutions:

 

1) place somehow clock with SSC or the best one is adding the independent clock for ASM1164

2) unsolder R29 to disable SRIS

3) disable SRIS by software

 

At this moment I choose number two, but if you find the third one I will stand on your side 

 

Actually, SRIS means that RC and EP are clocked by different sources (I think it is like SSC where some jitter always exists), but in Radxa 5 ITX all the clocks are produced by one oscillator, so, SRIS is not right mode for this board. According to PCIe architecture the board uses Common REFCLK, not SRIS. Due to Common Clock the PLL of ASM1164 can't sync in SRIS mode because it needs a little deviation to be locked

 

Commit a1fe1eca0d8be69ccc1f3d615e5a529df1c82e66 in upstream tells that 

"rxX_cmn_refclk_mode"
RX common reference clock mode for lane X. This mode should be enabled
only when the far-end and near-end devices are running with a common
reference clock.

 

The link training either fails or is highly unstable (link state will jump
continuously between L0 and recovery) when this mode is enabled while
using an endpoint running in Separate Reference Clock with No SSC (SRNS)
mode or Separate Reference Clock with SSC (SRIS) mode.

 

I applied this patch and set `rockchip,rx-common-refclk-mode = <0 0 0 0>;` for `&pcie30phy` in rk3588-rock-5-itx.dtb as upstream does and SATA detection is stable now.

 

 

To all:

I still have that patch for upstream 6.12 to avoid having the ASM Sata PCIe controller hang when the M.2 PCIe controller is initialized first, pending. However, there were no reports of Armbian sata detection failure with 6.12 in this thread. Please report if I should bring it sooner.

 

[Popolon]

Last try of 6.12 1 or 2 weeks ago, was still with display failure. 6.1 works fine, now, with both HDMI out and I believe SATA working at each boot. I believe than since your last change SATA works far better with 6.1 vendor kernel. I'm mainly using the 6.16rc7 armbian kernel on archlinux now where I compile time to time last mesa git, to take benefits of more GL features, Vulkan 1.4 support + zink, however some softwares like obs studio, blender, wings3D, GTK4-demos fails with zink, due to problems with broken DRI. X11 have some slowdown too, but Wayland is perfectly smooth with mainline kernel + mesa drivers.

 noticed that 6.16.0 was compiled with GCC11, where 6.16rc7 was compiled with GCC13.3, there is a lot of optimizations in perfs between the two GCC  releases, and Debian13 is now shiped with GCC 14.2.

 

kernel 6.17rc1 bring AV1 accelerated video on RK3588. and rc2 is now released, I don't know if there are projects to upgrade mainline kernel and/or Debian version? Debian is sadely shipped with Mesa 25.1.0. Vulkan 1.4 support was reached with Mesa 25.2. It is however maybe more stable, I didn't tried 25.1.0 stable?

[Werner]

At some point we will bump edge to 6.17. These bumps always take time since our patchset on top always needs adjustments.

There are 3rd party ppa's for newer mesa. I suggest to use kisak since those are briefly tested. Otherwise go for oibaf which are automated untested, therefore latest mesa packages.

In terms of Debian, no clue if there is a similar apt repo for such.