Jump to content

prahal

Members
  • Posts

    154
  • Joined

  • Last visited

Other groups

Contributor/Maintainer

2 Followers

Profile Information

  • Gender
    Male
  • Location
    France
  • Interests
    NAS, media center, Kernel

Contact Methods

  • Mastodon
    @abws
  • IRC
    #abws
  • Github
    prahal
  • Discord
    prahal

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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/
  2. 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.
  3. 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).
  4. @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?
  5. 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.
  6. 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
  7. 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).
  8. 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.
  9. Yes I planned them for 24.11 but had personal issue and also I took part in another board mainternship. The emmc patch need only that I sort out of to apply it to the current patfhset. I asked for insight on how to handle reformatting existing patch that I modify and was told that I should submit any changes to a patch in a separate patch by Werner but I am still uneasy to small patch files instead of fixing existing patches. I wonder if I explain my situation clearly ... The voltage patch needs a little more work as I made many instances of the voltage change on my side, so I need to disassemble ebin-dev dtb though it is achievable in a few hours. In short I tried learn ingambian processes first, had a little more work on another board (mostly learning required additional hardware and ordering it, then handlingna few glitches like power supply dying) then personal matters and taking part in gatherings. I now plan these commits for 25.02.
  10. I also think of a hardware issue. If you have a voltmeter you could check if you have 12V in the board (taking the ground on metal case around connector (ethernet, etc). Might be a repair shop could fix it. I don't know the cost of such a repair.
  11. I don't know why you don't get a shell on the serial console. But we can get the network issue worked around. There are two ethernet interfaces: end0 the 1Gbls and the second in your cawe enx646266d0034d the 2.5Gbps ethernet one. The enx646266d0034d is MAC hw address 64:62:66:d0:03:4d (I've the mac addr is in the interface name). The end0 should be the same minus one is 64:62:66:d0:03:4c. What are the status of the LEDs on the front panel (blinking/solid)?
  12. I believe it is supported https://wiki.kobol.io/helios64/hardware/ in the comments
  13. You could check with a voltmeter on the board for the 12V. Schematics are here https://wiki.kobol.io/helios64/docs/ . Do you have serial console output ? Though I believe with such an issue this is highly unlikely. From https://wiki.kobol.io/helios64/led/ comments, the system status LED and LAN LED are software controlled and HDD Activity LEDs hardware controlled. Though highly liekly LED1 (system rail power) is hardware controlled.
  14. Awesome. And thanks a lot for the feedback. Could you explain which side you disconnect/reconnected? The HDD side only? Or on the motherboard too? I believe HDD side is enough, just want a clue if that could be wrong. I believe the connector were not clean, or a bit oxidized out of fabric (maybe connectors were stored in an area with an aggressive climate... I am no expert, but I clue that with the parts being serviced during Covid mess, some unusual process happened). It is not like the hardware is bad, only "dirty". Here I had bad lost connectivity to an HDD, extracting and inserting it a few times back seemed to have cleaned the connectors (I also put isopropanol on them, but I don't remind if I brushed them at that time).
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines