Helios64 - Armbian 23.08 Bookworm issues (solved)

[prahal]

2 hours ago, BipBip1981 said:

Since few days i note a problem with SATA on my Helios64.

 

@BipBip1981

Could you grep for "ata", or check the logs for ata errors and paste them? Or tell if there are no other messages with ata in the logs?

Don't you have any "hard resetting link" messages in the kernel logs?

 

On my side I once had drives that were not detected extracting the drive from the SATA power and data socket a few times (and cleaning them with isopropanol once, might have helped) did it. I believe my socket were oxidized though that is a wild guess. Issue gone either way.

 

[BipBip1981]

Hi,

 

Same with 28.11-trunk build myself and 6.6.56 kernel

Below grep SATA and grep ata:

 

root@helios64:~# dmesg | grep SATA
[    3.137429] ahci 0000:01:00.0: AHCI 0001.0301 32 slots 5 ports 6 Gbps 0x1f impl SATA mode
[    3.151033] ata1: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010100 irq 74
[    3.151704] ata2: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010180 irq 75
[    3.152392] ata3: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010200 irq 76
[    3.153059] ata4: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010280 irq 77
[    3.153722] ata5: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010300 irq 78
[   10.588155] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   11.116112] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   11.628156] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   12.116158] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   12.624185] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
root@helios64:~# dmesg | grep ata
[    0.000000] Memory: 3787452K/4061184K available (16960K kernel code, 2318K rwdata, 5248K rodata, 4736K init, 604K bss, 142660K reserved, 131072K cma-reserved)
[    0.018184] CPU features: detected: ARM errata 1165522, 1319367, or 1530923
[    0.719520] libata version 3.00 loaded.
[    3.151033] ata1: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010100 irq 74
[    3.151704] ata2: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010180 irq 75
[    3.152392] ata3: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010200 irq 76
[    3.153059] ata4: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010280 irq 77
[    3.153722] ata5: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010300 irq 78
[    3.163337] dwmmc_rockchip fe320000.mmc: DW MMC controller at irq 82,32 bit host data width,256 deep fifo
[    8.508139] ata1: link is slow to respond, please be patient (ready=-19)
[   10.588155] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   10.610022] ata1.00: ATA-9: WDC WD80EFAX-68KNBN0, 81.00A81, max UDMA/133
[   10.620898] ata1.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[   10.624658] ata1.00: Features: NCQ-sndrcv NCQ-prio
[   10.639786] ata1.00: configured for UDMA/133
[   11.116112] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   11.117876] ata2.00: ATA-9: WDC WD80EFAX-68KNBN0, 81.00A81, max UDMA/133
[   11.128615] ata2.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[   11.132356] ata2.00: Features: NCQ-sndrcv NCQ-prio
[   11.148021] ata2.00: configured for UDMA/133
[   11.628156] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   11.630146] ata3.00: ATA-9: TS256GSSD370S, O1225G, max UDMA/133
[   11.630849] ata3.00: 500118192 sectors, multi 1: LBA48 NCQ (depth 32), AA
[   11.632376] ata3.00: Features: Dev-Sleep
[   11.635170] ata3.00: configured for UDMA/133
[   12.116158] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   12.118227] ata4.00: ATA-9: WDC WD80EFBX-68AZZN0, 85.00A85, max UDMA/133
[   12.128937] ata4.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[   12.132823] ata4.00: Features: NCQ-sndrcv NCQ-prio
[   12.148357] ata4.00: configured for UDMA/133
[   12.624185] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   12.626073] ata5.00: ATA-9: WDC WD80EFBX-68AZZN0, 85.00A85, max UDMA/133
[   12.636772] ata5.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[   12.640617] ata5.00: Features: NCQ-sndrcv NCQ-prio
[   12.656091] ata5.00: configured for UDMA/133
[   52.828386] EXT4-fs (dm-1): mounted filesystem 58534626-3f89-40db-9b0e-9519a2805962 ro with writeback data mode. Quota mode: none.
[   56.637970] EXT4-fs (mmcblk0p1): mounted filesystem ba516afd-4114-4179-8bcf-3d0f63b058fe r/w with ordered data mode. Quota mode: none.
[   64.262140] EXT4-fs (dm-2): mounted filesystem cc702057-ff5f-4b6f-ad29-4f5d5d96216e r/w with ordered data mode. Quota mode: none.
[   64.341677] systemd[1]: Starting plymouth-read-write.service - Tell Plymouth To Write Out Runtime Data...
[   64.358217] systemd[1]: Finished plymouth-read-write.service - Tell Plymouth To Write Out Runtime Data.
[   66.316142] systemd-journald[1673]: Data hash table of /var/log/journal/21a29cba476e44048a808d9a655190f3/system.journal has a fill level at 88.2 (4015 of 4551 items, 2621440 file size, 652 bytes per hash table item), suggesting rotation.

Edited October 17, 2024 by BipBip1981

[BipBip1981]

Hi everybody,

 

For information Prahal dtb patch file is not for me the problem because my  problem is only on ata1 after cold boot, never after reboot command.

I think hardware problem like harddisk, cables or mainboard... i continu to search.

 

Have good day

Edited October 18, 2024 by BipBip1981

[prahal]

On 10/17/2024 at 7:20 AM, BipBip1981 said:

[    8.508139] ata1: link is slow to respond, please be patient (ready=-19)
[   10.588155] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   10.610022] ata1.00: ATA-9: WDC WD80EFAX-68KNBN0, 81.00A81, max UDMA/133
[   10.620898] ata1.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[   10.624658] ata1.00: Features: NCQ-sndrcv NCQ-prio
[   10.639786] ata1.00: configured for UDMA/133

 

-19 in ata1: link is slow to respond, please be patient (ready=-19) is ENODEV in https://github.com/torvalds/linux/blob/6efbea77b390604a7be7364583e19cd2d6a1291b/drivers/ata/libata-core.c#L3594

but ready is resetted to 0 else the function would exit before this message https://github.com/torvalds/linux/blob/6efbea77b390604a7be7364583e19cd2d6a1291b/drivers/ata/libata-core.c#L3577

 

As I told, I had bad contact on my sata ports, try removing and inserting the HDD in the sata socket a few times. That might remove things on the contacts. On my side I also clean the sata sockets with isopropanol when I bought some (I use 99,5% isopropanol but I don't know if less concentrated is OK).

You might paste the complete log around the ata1 lines in the kernel log.

If the issue is always with the same sata port, you could try swapping the HDD to see if the issue follows the HDD or if this is the link or port.

But indeed I guess the issue is hardware.

 

[BipBip1981]

Hi,

 

I swap ata1 and ata5, problem stay on ata1, i look cable and socket on ata1

 

Keep in touch

[BipBip1981]

Hi, few days ago, i disconnect and reconnect all connectors on ATA1 line, it's seem to become Okok 😉 

Edited October 23, 2024 by BipBip1981

[prahal]

On 10/22/2024 at 6:22 PM, BipBip1981 said:

Hi, few days ago, i disconnect and reconnect all connectors on ATA1 line, it's seem to become Okok 😉 

 

 

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

 

[BipBip1981]

Hi,

For feedback, i disconnect from SATA connector by unrack/rack harddisk and i disconnect and reconnect plug on mainboard side.

Have a good day.

[drs]

Hey everyone,

 

I just updated my helios64, from bullseye to bookworm and the armbian packages from 23.02.2 to 24.11.1

 

After rebooting I couldn't reach my helios64 anymore via network, i.e. dropbear within initramfs. So I figured that nic device names may have changed (and so the IP= setting within initramfs.conf wouldn't work anymore)  and connected via serial console with picocom.

 

But unfortunately the serial console output just ends every reboot with these lines (full serial console output as attachment):

[    7.169342] r8152 2-1.4:1.0 enx646266d0034d: renamed from eth0
[    7.236959] device-mapper: uevent: version 1.0.3
[    7.237900] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@redhat.com
[    7.254918] NET: Registered PF_ALG protocol family
[    7.323029] zram: Added device: zram0
[    7.646108] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn
[    7.834575] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    7.835330] sd 1:0:0:0: Attached scsi generic sg1 type 0
[    7.836020] sd 2:0:0:0: Attached scsi generic sg2 type 0
[    7.836914] sd 3:0:0:0: Attached scsi generic sg3 type 0
[    7.837806] sd 4:0:0:0: Attached scsi generic sg4 type 0
[    7.969567] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn
[    8.043475] async_tx: api initialized (async)

 

Does anyone have any idea why the serial console output just ends and any idea what to do?

 

bookworm_serial_console.txt

[prahal]

On 12/16/2024 at 12:05 AM, drs said:

After rebooting I couldn't reach my helios64 anymore via network, i.e. dropbear within initramfs. So I figured that nic device names may have changed (and so the IP= setting within initramfs.conf wouldn't work anymore)  and connected via serial console with picocom.

 

But unfortunately the serial console output just ends every reboot with these lines (full serial console output as attachment):

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

Edited December 18, 2024 by prahal
request details

[snakekick]

Hello @prahal do you think you will impementing your dtb changes to official sources so we can upgrade to newer kernel without manuell changes are needed?

Thank you

Edited December 23, 2024 by snakekick

[BipBip1981]

Hello @prahal, i agree with @snakekick , you dtb changes is ready to go to official sources.

I use it from the beginning, my helios now work good and stop to crash.

My brother use it and same result.

Your dtb changes commit to official sources for the first january 2025 will be a perfect.

 

[prahal]

On 12/23/2024 at 3:23 PM, snakekick said:

Hello @prahal do you think you will impementing your dtb changes to official sources so we can upgrade to newer kernel without manuell changes are needed?

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.

[ebin-dev]

On 12/25/2024 at 5:50 PM, prahal said:

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.

 

The voltage values were changed in opp-table-1 - the values used can be found (here) earlier in this thread. The dtb for the 6.6 branch still works fine with them (cache awareness and emmc HS400 speed is also enabled in it). I am currently using it with linux-6.6.72 as it provides the best performance and stability.

 

rockchip64-current was bumped from kernel branch 6.6 to 6.12 (on Dec. 21st) and rockchip64-edge bumped to branch 6.13. These kernel versions are available on beta.armbian.com and any issues could be reported here.

 

The downside is that linux-6.6 rockchip64 kernel versions are not built anymore by the current armbian build system.

 

rk3399-kobol-helios64.dtb-6.6.xx-L2-hs400-opp

rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp

Edited 5 hours ago by ebin-dev
updated linux debs

[axel]

It's really nice to see all these recent community efforts to revive and keep the Helios64 alive and useful.

However, the relevant info seems to be a bit all over the place.

 

For instance, with the device tree files (dtb files). Which one is the "latest" one? How do you know which one to use for your current kernel? Where should you download it? (as an attachment to a user post on this forum?) Are they going to be merged as part of regular Armbian?

These questions are not that hard to answer if you read through the topics and have some technical knowledge, but that's sort of the problem!

 

Essentially, it would be great to start making things a bit more organised so people don't have to piece the information together from various forum posts

[prahal]

4 hours ago, axel said:

However, the relevant info seems to be a bit all over the place.

 

For instance, with the device tree files (dtb files). Which one is the "latest" one? How do you know which one to use for your current kernel? Where should you download it? (as an attachment to a user post on this forum?) Are they going to be merged as part of regular Armbian?

These questions are not that hard to answer if you read through the topics and have some technical knowledge, but that's sort of the problem!

 

Essentially, it would be great to start making things a bit more organised so people don't have to piece the information together from various forum posts

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

[ebin-dev]

On 1/10/2025 at 2:50 PM, axel said:

For instance, with the device tree files (dtb files). Which one is the "latest" one? How do you know which one to use for your current kernel? Where should you download it? (as an attachment to a user post on this forum?) Are they going to be merged as part of regular Armbian?

 

The dtbs attached to my previous post can be used for kernel branches 6.6.xx and 6.12.xx  respectively as identified in their names. There is no latest version - they are all the same for each kernel branch and posted for your convenience (so you don't have to compile them by yourself) until the patches make it into Armbian - hopefully soon.

 

The message is actually that linux 6.6 rockchip64 kernels (LTS) are not built anymore by the current Armbian build system. Therefore there is an urgent need to test linux 6.12 on Helios64 (and report any issues here), since that is what is going to be shipped with the next release.

[BipBip1981]

Hi, i build and pass to last armbian from source with 6.12 kernel to test dtb file with it. Keep in touch.

Edited Sunday at 08:34 PM by BipBip1981

[BipBip1981]

Hi,

System work well with Kernel 6.12 and DTB patch, juste a problem with the service folow.

Keep in touch.

 

root@helios64:~# systemctl status helios64-heartbeat-led.service
× helios64-heartbeat-led.service - Enable heartbeat & network activity led on Helios64
     Loaded: loaded (/etc/systemd/system/helios64-heartbeat-led.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Thu 2025-01-16 20:26:24 CET; 34min ago
    Process: 2899 ExecStart=bash -c echo heartbeat | tee /sys/class/leds/helios64\:\:status/trigger (code=exited, status=1/FAILURE)
   Main PID: 2899 (code=exited, status=1/FAILURE)
        CPU: 20ms

Jan 16 20:26:24 helios64 systemd[1]: Starting helios64-heartbeat-led.service - Enable heartbeat & network activity led on Helios64...
Jan 16 20:26:24 helios64 bash[2906]: tee: '/sys/class/leds/helios64::status/trigger': No such file or directory
Jan 16 20:26:24 helios64 bash[2906]: heartbeat
Jan 16 20:26:24 helios64 systemd[1]: helios64-heartbeat-led.service: Main process exited, code=exited, status=1/FAILURE
Jan 16 20:26:24 helios64 systemd[1]: helios64-heartbeat-led.service: Failed with result 'exit-code'.
Jan 16 20:26:24 helios64 systemd[1]: Failed to start helios64-heartbeat-led.service - Enable heartbeat & network activity led on Helios64.

Edited Thursday at 08:01 PM by BipBip1981

[ebin-dev]

On 1/16/2025 at 9:01 PM, BipBip1981 said:

Hi,

System work well with Kernel 6.12 and DTB patch, juste a problem with the service folow.

Keep in touch.

 

Could you check if the 'rtl8156a-2 v2' firmware is loaded (dmesg | grep r8152) ? 

I did not see that during my tests.

Thanks !