prahal

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).

@crosser thanks for the feedback. By new edge release stable you mean vanilla armbian one? That is without copying ebin-dev dtb with the new edge kernel?

from reading the dts there is a helios64:green:status which does not show in 6.12.1 from armbian edge but does in 6.12.9 armbian current. On the opposite side helios64::status is listed in the 6.12.1 but not the 6.12.9. I guess the "green" was discarded from the sysfs file name before but no more. If the fact "green" is not removed anymore is a feature the systemd service helios64-heartbeat-led.service will have to be modified to cope with both file names. It might be a good idea to rename this gpio line as helios64:blue:status (as the led is blue not green). I wonder why it was labelled as green, maybe as a hackish way to have the color not included in the sysfs gpio led file name, as it seems green was not preserved in the sysfs name before around Linux 6.12.9. Or maybe labelling a system led OK status as green is a convention. That would require research as I know few about gpio leds conventions, and that would be better done now, before hard-coding "green" in the helios64-heartbeat-led.service systemd service.

Can you reproduce the helios64 crash without the dtb patch? Could you provide output from /sys/class/leds/ with and without the dtb patch? (and by dtb patch could you confirm you mean you replace the full dtb file, not edit the dtb via dtc or armbian-config to only changed the emmc/opp voltages? I am on 6.12.1-edge-rockchip64 from linux-image-edge-rockchip64 24.11.1 with vanilla armbian dtb and the leds trigger file exists for helios64::status phn@helios64:~$ ls /sys/class/leds/ helios64:blue:hdd-status helios64:blue:power-status helios64:red:ata1-err helios64:red:ata3-err helios64:red:ata5-err helios64::status helios64:blue:net helios64:blue:usb3 helios64:red:ata2-err helios64:red:ata4-err helios64:red:fault mmc0:: phn@helios64:~$ ls /sys/class/leds/helios64\:\:status brightness device invert max_brightness power subsystem trigger uevent

There is only ebin-dev dtb that has the non armbian upstreamed fixes (the older other comments are about doing the same changes on your own dtb, or about requesting feedback from people testing these changes). As far as I know ebin-dev dtb has the emmc fix in dtb and the CPU big voltage upped a little also in dtb. Both from me. They will both be uostreamed to armbian but only the Emma fix will go in Linux upstream (as the voltage up is only a hack that I was requested to try by a pine64 engineer but the cause of the crash is still not know. The current voltages are supposed to be already correct).

I won't be able to test newer image until at least a week, away from the board. Before leaving, I was able to confirm that I get back panel sound with rock-5-itx_debian_bullseye_kde_b6.img.xz image (kernel 5.10.110-37-rockchip). You might want to provide amixer output to sort out any volume level issue. `cat /proc/asound/cards` `amixer` and `amixer -c 3` if card 3 is `rockchipes8316` in `cat /proc/asound/cards` output.