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.

[Popolon]

Today armbian-config doesn't show other kernels, it's impossible to switch.
 

* Show only mainstream kernels on the list? => no
* No other kernels available! => ok

Edited Saturday at 03:53 PM by Popolon

[Igor]

1 hour ago, Popolon said:

Today armbian-config doesn't show other kernels, it's impossible to switch.

 

Fresh Orangepi 5 image, this one:
https://netcup-01.armbian.com/incoming/efectn/orangepi5/archive/Armbian_25.8.1_Orangepi5_noble_vendor_6.1.115_gnome_desktop.img.xz

 

Your setup could be broken to some degree, but hard to tell what is missing.

[Popolon]

Sorry that was resolved 2 days ago, but I don't see and never seen this long list. Only 3 options vendor 6.1,  6.12 and  edge (6.16), This morning I also seen the u-boot wasn't the good one. I downloaded for rock5-itx, but had linux-u-boot-cyber-aib-rk3588-edge instead of linux-u-boot-rock-5-itx-edge, changed it, rebooted (on 6.16) worked, tried again 6.12, still no display. I needed to arch-chroot on the armbian to take a screenshot (but I've the same dispay on armbian itself):

 

 

I seen 6.16.4 is now available and work, after /boot/config-6.16.4-edge-rockchip64, gcc 13.3.0 is now again used instead of old 11.x :). Debian Trixie has GCC 14.2.0

 

CONFIG_CC_VERSION_TEXT="aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0"

And after changelog on kernel.org, patch for AV1 acceleration had been applied on this version: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.16.4
 

Fixes: 003afda97c65 ("media: verisilicon: Enable AV1 decoder on rk3588")

Sorry I maybe mix too much subjects in the same post, but:

I also seen a minimal IoT version of Trixie for Rock5-itx. Can I made safely a debian os upgrade from apt? Or is it better to wait release for desktop version ?

Another point. On armbian, only LLVMpipe is used, I compiled last mesa git on arch, will try to do this for debian too. and some application that need to use  EGL+dri (wings3D, blender, obs) report broken DRI2 access. I'm not sure if it's due to some kernel patchs (I reuse the armbian 6.16 kernel on arch), or to the current state of mesa-git. They all works with llvmpipe. Othere applications like PPSSPPSDL work fine without it.

 

Ex, with wings3d + forced zink: MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink wings3d

WARNING: Some incorrect rendering might occur because the selected Vulkan device (Mali-G610) doesn't support base Zink requirements: feats.features.fillModeNonSolid feats.features.shaderClipDistance 
libEGL warning: egl: failed to create dri2 screen
WARNING: Some incorrect rendering might occur because the selected Vulkan device (Mali-G610) doesn't support base Zink requirements: feats.features.fillModeNonSolid feats.features.shaderClipDistance

Edited 1 hour ago by Popolon