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 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 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 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 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 Monday at 02:24 PM 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]

23 hours ago, 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 (attached) still works fine with them (cache awareness and emmc HS400 speed is also enabled in it).

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

Edited 13 hours ago by ebin-dev