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.

Mainline audio is not working. Vendor audio is working but not activated by default yet

Sorry took so long: workaround is to set the two mixer controls via cli: amixer -c 4 sset 'Left Headphone Mixer Left DAC' on amixer -c 4 sset 'Right Headphone Mixer Right DAC' on they are off on armbian and on the initial image I was testing with which you properly sorted out was Radxa default Debian image. Edit: note you can increase the sound output by increasing "Headphone Mixer", via amixer or interactively via "alsamixer -c 4". Edit 2: note that this only works for the vendor kernel. I don't get audio out with the mainline one (replace -c 4 by -c 0 there as there is only one audio device available with mainline)

Sorry for the late reply. Note the baud rate is set in U-Boot to 1.5Mbps (and your device tells max 1Mbps).

This is for rock 5b. The U-boot requirements is for rock 5b only as it seems to be due to rock 5b being powered via this usb-c port (and talks about the USB-PD negociation needing to happen in u-boot). So this patch to rock 5b dts will not fix rock-5-itx support. Edit: Mind I have not checked yet if the rock-5-itx dts already has this code or not.

Thanks, @Alex T, for your hindsights. Would plugging an ATX power supply instead of the original external power supply help sort this out? What kind of ATX PSU would be required? I had measured the voltage on the board with a voltmeter and got a little above 12V fine, but I believe to phase out transient voltage drops an oscilloscope is required (I got a portable oscilloscope a few months ago). Also, I have a test case (attached cpufreq-switching-2.c) that always crashes the big CPUs (even when I set a 5 milliseconds delay between transitions, with #define TRANSITION_DELAY 5000). I believe if the power supply is at fault, I should be able to see small voltage drops on the 12V rail on the board with the oscilloscope? cpufreq-switching-2.c

I landed the restoration of the eMMC hs400 support and the fix for the helios64-heartbeat-led.service that I had broken in a previous commit. The upped voltages are not in. Though these upped voltage seems to help a lot of people, they are not the endgame. Ie I tried setting all the CPU b voltages to max 1.2, and I believe I can still crash the CPUs b with my test case... Also, I am onboarding on another board maintenance. Fixed an issue with a PL2303 USB serial adapter that it did not support 1.5Mbps but only 1.2Mbps.... In the meantime, I nailed down an issue on edge 6.14 that might also affect other version but not tested yet. I fixed it locally by setting the startup time for HDD rail a and rail b to have them not start at the same time by the kernel. Ie the upstream Linux kernel have the HDD rails defined, and it seems it restarts them when the kernel load thus draining too many amps on my board and I repeatedly had: Internal error: synchronous external abort: 0000000096000210 [#1] PREEMPT SMP (...) [ 3.890774] Call trace: [ 3.891012] rockchip_pcie_rd_conf+0xf4/0x1e8 (P) [ 3.891461] pci_bus_read_config_dword+0x7c/0xdc [ 3.891906] pci_bus_generic_read_dev_vendor_id+0x34/0x1b4 [ 3.892428] pci_scan_single_device+0xa0/0x108 [ 3.892857] pci_scan_slot+0x68/0x1c4 [ 3.893216] pci_scan_child_bus_extend+0x44/0x2cc [ 3.893668] pci_scan_bridge_extend+0x320/0x60c [ 3.894104] pci_scan_child_bus_extend+0x1b8/0x2cc [ 3.894564] pci_scan_root_bus_bridge+0x64/0xe4 [ 3.895000] pci_host_probe+0x30/0x108 [ 3.895367] rockchip_pcie_probe+0x43c/0x5e4 [ 3.895777] platform_probe+0x68/0xdc I cannot reproduce this PCIe failure after adding the 10 seconds delay that Kobol devs put in the u-boot between rail a and rail b startup. Though, 10 seconds seems a lot, but I have no clue why the Kobol team chose such a huge value.

I "believe" that a board can only ship one DTB armbian wise. I will have to study that to be confident though. If the board is not the same hardware wise, it could be it requires its own "board" config in armbian. It being close won't help (except it will make it easier for this board maintainer as most of the work will already have been done). I have no experience in adding a new board to armbian, but I believe cloning the armbian/build repository and creating a new config/boards/ is the first step. And having a new tag for this board on the forum. As a local hack (I believe this is not a proper fix but I might be wrong), you might be able to create an override dtb file to remove existing nodes and add new ones to an existing board dtb.

So the vendor 6.1 kernel set both the pcie3x2 ASMedia SATA and pcie3x4 M.2 M.Key vpcie3v3-supply with the same `vcc3v3_pcie30` supply which is the supply for the pcie ref clock so they worked around the issue by describing incorrectly the supply for these pcie controllers. This pcie ref clock power supply patch set is likely still of interest for the mainline 6.12 branch. I confirm that I was at least once able to reproduce the ASMedia SATA not seen with the gated ref clock patch set applied to the vendor branch (even though as I found later on there was already a workaround in the vendor kernel in that they set the oscillator supply as the supply for both pcie controllers even though that does not describe the hardware correctly).

Still building 6.1 vendor with the gated clock patch set. Though I noticed the mainline kernel has default pinctrl settings for pcie but not the vendor one. If one want to try testing these dts pinctrl pcie definition from mainline to vendor.

I will try this 6.13 patchset but it looks like SATA drives are already stable with 6.12 (iè without this patchset) or at least more stable than vendor 6.1. Could be another fix between 6.1 and 6.12 helps. Envoyé de mon CPH2089 en utilisant Tapatalk

If LED issue was helios64:green:status in sysfs instead of helios64::status it is fixed in git.

The 2.5Gbps hardware issue is when operating in 1Gbps mode only (2.5Gbps was always fine hardware wise) https://blog.kobol.io/2020/11/13/helios64-2-5g-ethernet-issue/

These are not error messages but information messages. Ie "waking up from sleep" messages when the device wakeup. Edit: I will have to investigate. "exception Emask 0x0 SAct 0x40 SErr 0x0 action 0x6" and hard resetting the link on wake-up from HDD sleep might not be normal after all.

About the helios64-hearttbeat-led.service I found the cause. When I synced the armbian dts to the upstream one the fact there was a "green" in thre label of the upstream dts slipped through. I will revert this change back to helios64::status instead of helios64:green:status. (the issue was introduced in armbian 6.9 kernels).