Helios-64 Fails to boot since upgrading to Bookworm

[Carlos Hartmann]

Quick preface: I'm a noob in many ways, though I'm trying to learn. I may make obvious mistakes and may need clearer instructions than most. Would really appreciate someone working with me here!

 

So I realized earlier this year that I was still on Buster and that there were two newer OSs that I could upgrade to. I upgraded to Bullseye with support from ChatGPT which worked nicely. The upgrade to Bookworm hosed my system and it now fails to reboot.

 

System Info (prior to failure):
- Helios64 board
- Armbian with OMV
- Originally running Buster, then upgraded in sequence: first to Bullseye (worked fine), then to Bookworm
- System was always booted from an SD card, not eMMC
- Upgrade was done via `apt` commands, no manual flashing of U-Boot

 

Current Symptoms:
- After Bookworm upgrade, the system fails to boot.
- Via USB-C serial connection (using `screen`), I get mostly garbled output like:

�`���x�f������������f�������f��~�怘����怘�

Or:

ZZ���B>��^�������������N��f�&F�goFFWFWGGG�oo{{q�{{{{z{{����_G_�#g�_WN�o.���wgG�WwwwWw�NWN�W�_ow_fW�Wo�v�oNogoWffOgFGFONNfFOW^Wf_G�~gg�

 

- Occasionally, I saw more verbose output including:

SetTTY (fd 5): ioctl failed: Invalid argument

 

Sorry, could not find a PTY

- No SSH access; connection refused (network stack never comes up).
- The fans spin up for a few seconds and the Ethernet LED blinks briefly, then stalls.

 

What I've Tried:
- Reflashed several SD cards (Verbatim Premium and Sandisk Extreme Pro) with the latest Armbian Bookworm images (Minimal, OMV, and Noble).

- I still have my old SD card that was Buster and got upgraded to Bullseye and then Bookworm, also made a backup image of it.
- Repeated all tests on my second, so-far unused Helios64 — same symptoms.
- Changed power cables and tried both UPS and direct plugging to wall socket.
- Verified serial setup with `screen /dev/tty.usbserial 1500000`.

 

SD Card Behavior:
- After flashing via `dd`, macOS warns “Cannot initialize disk” — I believe this is expected.
- On insertion and power-up: usually fans spin and LEDs blink, but no consistent or successful boot.

 

Desired Outcome:

- I'd like to use Bookworm on Helios 64. If not possible, then I'd like to use Bullseye I guess, but I wasn't able to find an image online. Only Bookworm, Jammy, and Noble.
- I'm aware of firmware and DTB tweaks recommended on here to make Bookworm stable — but I can’t try these yet because I never reach a usable system.

 

Questions:
1. Is there any place where I can download an official or community-maintained Bullseye image for Helios64? Should I even try to use Bullseye?
2. Is the serial output I’m seeing a sign of a bootloader issue (U-Boot or DDR init)?
3. Can the Bookworm image be made to boot reliably with certain tweaks *before* boot (e.g. editing partitions manually)?
 

ChatGPT suggested to boot the system without eMMC and this is certainly territory where I don't trust AI anymore. I think I need to try fixing the server with help from you and understanding the process myself.

 

Since my main Helios64 is offsite, I took my second Helios64 home with me until I figure out what the issue is and I'm able to boot it up and get it running. Then I'll hopefully be able to fix my offsite machine during one of my visits there.

 

I should also say that it would occasionally get "stuck" on a reboot attempt and I needed to physically turn it off and an again to boot successfully. This never happened twice in a row, i.e. the manual reboot always fixed it. Regular reboots worked with roughly a 80-90% success rate but it didn't have to reboot very often at all. Still, this makes me believe that maaaybe there is some hardware issue present. Then again, the second Helios experiencing the same issues makes this more unlikely I suppose.

Edited Sunday at 02:03 PM by Carlos Hartmann
Completeness

[djurny]

Hi there,

Some things you might want to check or confirm:

 

Quote

- After flashing via `dd`, macOS warns “Cannot initialize disk” — I believe this is expected.

I would expect that your OS would detect a new disk with one partition called armbi_root. Are you confident that you have used the correct image?

 

If you are using wget to download an image from the main site's download area (https://www.armbian.com/helios64/) https://dl.armbian.com/helios64/Bookworm_current_minimal, do note that this will download Bookworm_current_minimal, which is actually an .xz image! You need to rename it to .xz and then unxz it to your SDcard. You cannot just dd that as that won't work.

 

djurny@ekspiees:~/Downloads$ wget https://dl.armbian.com/helios64/Bookworm_current_minimal
--2025-06-01 08:12:51--  https://dl.armbian.com/helios64/Bookworm_current_minimal
Resolving dl.armbian.com (dl.armbian.com)... 152.53.81.238
Connecting to dl.armbian.com (dl.armbian.com)|152.53.81.238|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://armbian.chi.auroradev.org/dl/helios64/archive/Armbian_24.11.1_Helios64_bookworm_current_6.6.62_minimal.img.xz [following]
--2025-06-01 08:12:52--  https://armbian.chi.auroradev.org/dl/helios64/archive/Armbian_24.11.1_Helios64_bookworm_current_6.6.62_minimal.img.xz
Resolving armbian.chi.auroradev.org (armbian.chi.auroradev.org)... 23.186.112.5, 2602:fc41::5
Connecting to armbian.chi.auroradev.org (armbian.chi.auroradev.org)|23.186.112.5|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 251530384 (240M) [application/x-xz]
Saving to: 'Bookworm_current_minimal'

Bookworm_current_minimal               100%[==========================================================================>] 239.88M  24.2MB/s    in 10s     

2025-06-01 08:13:02 (23.6 MB/s) - 'Bookworm_current_minimal' saved [251530384/251530384]

djurny@ekspiees:~/Downloads$ ls -l Bookworm_current_minimal 
-rw-rw-r-- 1 djurny djurny 251530384 Nov 24  2024 Bookworm_current_minimal
djurny@ekspiees:~/Downloads$ file Bookworm_current_minimal
Bookworm_current_minimal: XZ compressed data, checksum CRC64
djurny@ekspiees:~/Downloads$ 

 

Are you running any disks in your Helios64? When I was testing/playing around with my Helios64 and rebooting a lot, I decided to take out some disks to prevent them from being stopped/started all the time. This led to random stalls in the OS reaching console login. After reinserting all disks this went away.

 

Also, just to be clear where I'm coming from: I'm also still running Buster (5.9.13-rockchip64 #trunk.16) on my Helios64. Did not yet spend any time to go for Bookworm fully.

 

Groetjes,

 

[Carlos Hartmann]

Hi there,

 

appreciate you answering!

I downloaded via the browser and manually ran 

xz -d Armbian_24.8.1_Helios64_bookworm_current_6.6.47_minimal.img.xz

 I then ran the dd command using the resulting .img file.

 

However, diskutil does not show a partition called ambi_root.

Relevant part of diskutil list:

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *31.3 GB    disk4
   1:                      Linux                         31.0 GB    disk4s1
                    (free space)                         325.1 MB   -

 

Not sure if this points to something being out of order.

 

Also, I should mention I tried USBImager but it will not even start as macOS says it is "damaged". The balena Etcher is not recommended according to the Armbian documentation.

 

On that documentation page I saw that they recommend specific microSD cards. Comparing with the ones I bought I think I may need to buy one that is actually recommended. Even if it's not the cause of the issues, I saw somewhere that the wrong SD card can be a headache in the long run. 

 

As for the drives, I had a full stack of 5 drives in my main Helios, and 4 non-configured ones in the spare Helios (was just using it as cold storage really). I transported the spare Helios without any drives to my place now and verified that the behavior remains the same.

So, in short: same behavior with and empty, full, and 4/5 Helios.

[djurny]

Hi,

Curious what the result is of "parted u s pr" on the unxz'd image?

As for the tools you mentioned, the basics like dd or even unxz'ing directly onto your device are a safe bet. I like to see what's going on and add sauce myself when needed.

 

In addition to that, can you share the sha256sum of the unxz'd image file? I'm getting:

djurny@ekspiees:~/Downloads$ sha256sum Bookworm_current_minimal
6a28d5e6af0eb3ab3f534a14f2f2092633397092e7032bf0f82621fea58194d7  Bookworm_current_minimal

 

Also, try to loop-mount the image file to check if the contents are readable:

 

First check the offset of the first partition in amount of sectors:

djurny@ekspiees:~/Downloads$ parted Bookworm_current_minimal u s pr
WARNING: You are not superuser.  Watch out for permissions.
Model:  (file)
Disk /home/djurny/Downloads/Bookworm_current_minimal: 2646016s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End       Size      Type     File system  Flags
 1      32768s  2646015s  2613248s  primary  ext4

 

Mount the image:

djurny@ekspiees:~/Downloads$ mkdir /tmp/image

djurny@ekspiees:~/Downloads$ sudo mount -o loop,offset=$((512 * 32768)) Bookworm_current_minimal /tmp/image
[sudo] password for djurny: 2444666666

djurny@ekspiees:~/Downloads$ ls -Failh /tmp/image/boot/
total 63M
32709 drwxr-xr-x  3 root root 4.0K Nov 24  2024 ./
    2 drwxr-xr-x 19 root root 4.0K Nov 24  2024 ../
29474 -rw-r--r--  1 root root    0 Nov 24  2024 .next
29472 lrwxrwxrwx  1 root root   33 Nov 24  2024 Image -> vmlinuz-6.6.62-current-rockchip64
29475 -rw-r--r--  1 root root 4.9M Nov 17  2024 System.map-6.6.62-current-rockchip64
29476 -rw-r--r--  1 1005 1005  130 Nov 24  2024 armbianEnv.txt
29477 -rw-r--r--  1 root root  38K Nov 24  2024 boot.bmp
29478 -rw-r--r--  1 1005 1005 3.8K Nov 24  2024 boot.cmd
29479 -rw-rw-r--  1 root root 3.9K Nov 24  2024 boot.scr
29480 -rw-r--r--  1 root root 243K Nov 17  2024 config-6.6.62-current-rockchip64
29473 lrwxrwxrwx  1 root root   29 Nov 24  2024 dtb -> dtb-6.6.62-current-rockchip64/
32710 drwxr-xr-x  3 root root 4.0K Nov 24  2024 dtb-6.6.62-current-rockchip64/
29669 -rw-r--r--  1 root root  15M Nov 24  2024 initrd.img-6.6.62-current-rockchip64
29672 lrwxrwxrwx  1 root root   33 Nov 24  2024 uInitrd -> uInitrd-6.6.62-current-rockchip64
29671 -rw-r--r--  1 root root  15M Nov 24  2024 uInitrd-6.6.62-current-rockchip64
29481 -rw-r--r--  1 root root  29M Nov 17  2024 vmlinuz-6.6.62-current-rockchip64
djurny@ekspiees:~/Downloads$ 

 

After dd'ing the image to an SDcard, I was able to boot my Helios64 successfully:

djurny@ekspiees:~/Downloads$ sudo dd if=Bookworm_current_minimal of=/dev/mmcblk0 conv=fsync status=progress

 

Spoiler

DDR Version 1.24 20191016
In
soft reset
SRX
channel 0
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 416MHz 0,1
Channel 0: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
256B stride
channel 0
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
change freq to 856MHz 1,0
ch 0 ddrconfig = 0x101, ddrsize = 0x40
ch 1 ddrconfig = 0x101, ddrsize = 0x40
pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
ddr_set_rate to 328MHZ
ddr_set_rate to 666MHZ
ddr_set_rate to 928MHZ
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
ddr_set_rate to 416MHZ, ctl_index 0
ddr_set_rate to 856MHZ, ctl_index 1
support 416 856 328 666 928 MHz, current 856MHz
OUT
Boot1: 2019-03-14, version: 1.19
CPUId = 0x0
ChipType = 0x10, 323
SdmmcInit=2 0
BootCapSize=100000
UserCapSize=14910MB
FwPartOffset=2000 , 100000
mmc0:cmd5,20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=30528MB
FwPartOffset=2000 , 0
StorageInit ok = 65838
SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT 0x3380ec0 signature is wrong
recovery gpt...
GPT 0x3380ec0 signature is wrong
recovery gpt fail!
LoadTrust Addr:0x4000
No find bl30.bin
No find bl32.bin
Load uboot, ReadLba = 2000
Load OK, addr=0x200000, size=0xdcfd8
RunBL31 0x40000
NOTICE:  BL31: v1.3(debug):42583b6
NOTICE:  BL31: Built : 07:55:13, Oct 15 2019
NOTICE:  BL31: Rockchip release version: v1.1
INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO:    Using opteed sec cpu_context!
INFO:    boot cpu mask: 0
INFO:    plat_rockchip_pmu_init(1190): pd status 3e
INFO:    BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR:   Error initializing runtime service opteed_fast
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9


U-Boot 2020.07-armbian (Oct 13 2020 - 16:49:59 +0200)

SoC: Rockchip rk3399
Reset cause: RST
DRAM:  3.9 GiB
PMIC:  RK808 
SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
MMC:   mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Model: Helios64
Revision: 1.2 - 4GB non ECC
Net:   eth0: ethernet@fe300000
scanning bus for devices...
Hit any key to stop autoboot:  0
=> run bootcmd
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
3906 bytes read in 7 ms (544.9 KiB/s)
## Executing script at 00500000
Boot script loaded from mmc 1:1
130 bytes read in 6 ms (20.5 KiB/s)
15073177 bytes read in 644 ms (22.3 MiB/s)
30097920 bytes read in 1281 ms (22.4 MiB/s)
88353 bytes read in 19 ms (4.4 MiB/s)
2825 bytes read in 15 ms (183.6 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 09000000
Trying kaslrseed command... Info: Unknown command can be safely ignored since kaslrseed does not apply to all boards.
Unknown command 'kaslrseed' - try 'help'
## Loading init Ramdisk from Legacy Image at 06000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    15073113 Bytes = 14.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to f5086000, end f5ee5f59 ... OK
   Loading Device Tree to 00000000f5008000, end 00000000f5085fff ... OK

Starting kernel ...


helios64 login: root (automatic login)

Last login: Sun Jun  1 18:24:17 UTC 2025 on tty1

Waiting for system to finish booting ...
/usr/lib/armbian/armbian-firstlogin: line 662: /sys/class/graphics/fb0/virtual_size: No such file or directory
Welcome to Armbian! 

Documentation: https://docs.armbian.com | Community support: https://forum.armbian.com

IP address: 192.168.2.36 

Create root password: 

 

 

It all seems to work? So my guess is something is going wrong with either the image file you have downloaded or the writing to the SDcard...

 

Grt,

[Carlos Hartmann]

Hi,

The output of `parted [.img file] unit s print` is:

 

Zitat

 

root@94046707031f:/# parted /mnt/Downloads/bookworm_minimal/Armbian_24.11.1_Helios64_bookworm_current_6.6.62_minimal.img unit s print

Model:  (file)

Disk /mnt/Downloads/bookworm_minimal/Armbian_24.11.1_Helios64_bookworm_current_6.6.62_minimal.img: 2646016s

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Disk Flags: 

 

Number  Start   End       Size      Type     File system  Flags

 1      32768s  2646015s  2613248s  primary  ext4

 

 

I'm on macOS, which isn't able to read ext4. Mounting didn't work at all. I also tried with a Debian image via docker but the mount command was not permitted (even with using sudo).

The only other Linux machine I have is a Steam Deck, which I might be able to use in Desktop mode for this.
 

I did run sha256sum on the downloaded file and checked with the hash on the Armbian page. Afterwards just ran `xz` and `dd`. 

I repeated this on a different machine (also macOS) and the outcome still the same.

EDIT: Oh you meant for me to run sha256sum on the unxz'd file, so the .img file directly. The checksum is indeed the same as what you posted.

 

I do agree that it seems like the SDcard and/or image are at fault. I tested two different power cables on two different Helios64 machines, it kind of has to be this. But what else could I try?

 

The USB-C cable I use to get access via `screen` is USB-C to USB-C and is confirmed to be for data&charge. I saw that the Helios64 documentation says to use USB-C to USB-A but I doubt that this is the reason for the flaky connection. It does seem like an issue with the Helios64.

 

Edited Sunday at 08:40 PM by Carlos Hartmann

[Carlos Hartmann]

Just a short update to say that I also tried the balena Etcher with no changed behavior.

[djurny]

Hi,

Just to baseline some stuff:

• The baudrate you use in screen, it's set to 1.500.000 ?
• Did the serial cable work before? Or is this the first time you use a C-C cable?
  I know too little about the differences of C-C vs A-C cables, but if this is the first time using the C-C cable, please try to use A-C with some Mac-to-A hub. I can only confirm an A-C cable works here.
• Are you sure that the connector of the C end at the Helios64 side is making proper contact?
  In my (and other's case) the actual plug part did not fully pass through the case. I had to cut some of the plastic away of the C side to expose more of the actual connector. This way it fully entered the case and made better contact with the board. Not sure if I'm explaining this well or not, let me know if this is not clear.
• Is there anything on your Mac side that is trying to automatically mount the card while you are writing the image?
• Are you sure the entire image was written to the SDcard?
  e.g. Did you use conv=fsync for dd ? Or a sync before removing the SDcard? (There is no umounting happening as the card could not be mounted you mentioned.)
• Did you try and sha256 sum the SDcard contents as well?
  You should be able to do that (slowly) with
  dd if=/dev/sdcard bs=1 count=$(stat -c '%s' Bookworm_current_minimal) | sha256sum
  Make sure to remove the card first and reinsert it to avoid dd is reading cache.

Grt,

[Carlos Hartmann]

• baudrate: indeed at 1500000
• The serial actually did not work before. Back when I first installed the Helios I used a C-A cable.
  Now I gave it a try with one and it improved the behavior: instead of appearing and disappearing, the usbserial device is now constant. The issue is just that nothing is shown via `screen`. I think I'll try by inserting a HDD because of what you said.
• I remember the USB-C cable issue. To be sure, I had removed a sliver of plastic using a cutter just like I did a couple years ago. No issues with clarity, I know about that quirk of the Helios. But yeah, this was not the issue now as I only worked with "modified" USB-C connectors.
• I unmounted the "disk" (SD card) before working with it. That should be safe as nothing tried mounting it afterward.
• Was the whole thing written: The `dd` command finished and balena Etcher even confirmed that the Flash was complete. So I think this is also a yes.
• conv=fsync: No I did not do this. Repeating the whole procedure with this and then after reinserting, I'll get a sha256sum of the contents…
  It worked, the resulting sha256sum is identical. Just trying to boot the machine again…
  Same behavior, sadly. HDD not yet inserted btw, will do that tomorrow.
   

[djurny]

Hi there,

Some notes from my side, with the image we are now both trying out, I do have some issues every other boot. Seems that the kernel gets stuck at:

[   19.941334] amba ff6d0000.dma-controller: deferred probe pending: (reason unknown)
[   19.942069] amba ff6e0000.dma-controller: deferred probe pending: (reason unknown)
[   19.942765] platform ff1d0000.spi: deferred probe pending: (reason unknown)
[   19.943404] platform ff1e0000.spi: deferred probe pending: (reason unknown)
[   19.944042] platform ff200000.spi: deferred probe pending: (reason unknown)

No idea why. This seems to alternate every other boot, so after a reboot this appears to be tolerated, but the next reboot the kernel gets stuck again. And stuck in like magic sysrq stops working.

 

Make sure you have verbosity=8 in your armbianEnv.txt, to make sure some (read: more) output is generated on the console.

Groetjes,

[Carlos Hartmann]

I set up an Ubuntu VM on my Mac to do linux stuff.

With that I edited the ambianEnv.txt as you said.

 

Behavior is the same. I should also add that there is a regular double-blink of the System LED after the initial fans (of about 2-3 seconds).

 

I now remember that back when I set up the Helios, I was told to use PuTTY on Windows instead of my mac. Maybe there's an incompatibility of some sort?
I checked and they recommend a set of drivers for Mac that I hadn't installed. I did and after playing around -- and only occasionally while playing around with connecting, disconnecting, rebooting -- did I sometimes get some garbled output in the serial window:

 

Zitat

u�p��u:puv322��wvru7vrsvv�:�gwvww�vuw3213;wv�p�9;��1:q�;2vs232�u�?3�wv1�3v1232uw��3w�wv79su�u2u�9wu��wvu�pwwvr�3���vs23�v36752�2��uvr9��pw�s2u3vu36ٻ:�3vw�pwvwv�77���vu:p߻22�7v2�u�p�362ٻ�u22u:�ٻ:p�v�2�2vwv93v7v2�:�2��:vwv9���v21��w�p7��r3��pqvq2�23���vvwvwvs;23wwu�1v762w�vwv���23123vwu�323u��:9;:w��wu:�9:7ws3vqwvٻ��ws231;���9wwv2�vq���rw�rsu:�uv�2�u:p�w2u:p�1w1�2�vswv9v�2�3v�2���:�9�:�wvwv2�v�2u�2���13v313vswqw:ww1�6;�13vw��21331v����v3sw:�9��1�2�13v3��2���v3sw��9�v7��v33wrwqw:3sw:q72�sww ;���3���s1331;v3�13213��;ww�www�swv�;��www�1361ww�3�3�qwvqwvwwqwv

 

posting it because it's the longest and least garbled output I've gotten so far.

 

The command was exactly as on the Helios64 website, i.e. the baud rate was correct.

 

Not sure where to go from here and what to blame.

[djurny]

Hi there,

I think what would be next is to try an older image to see if the serial console and hardware itself are still working.

If you're interested, I still have a version here locally: Armbian_20.08.10_Helios64_buster_current_5.8.14.img.xz.

Groetjes,

[Carlos Hartmann]

Oh yes, I've been meaning to test an older version but didn't find any anywhere. Can you upload here directly?

 

Maybe slightly OT: Do you know why older versions aren't preserved anywhere? I thought it'd be easy to find buster and bullseye images but didn't manage at all. Seems like it can't be too uncommon that a newer version causes issues and one has to fall back.

Edited 9 hours ago by Carlos Hartmann

[djurny]

Hi @Carlos Hartmann,

Backups of anything are a good thing. So my advise would be to always keep the ISOs you downloaded somewhere 'safe'. Not that safe that you will forget where you stashed it of course (looking at you @djurny...).

Groetjes,

[Carlos Hartmann]

I see, now I get it!

 

So it's everyone's duty to keep around what they think might still be necessary ahead. Did not know of this quirk in the world of Linux.

 

Definitely OT: This explains the running gag among data hoarders when they justify their ample storage space with "Linux ISOs" but really mean socially less accepted things.

[Igor]

1 hour ago, Carlos Hartmann said:

Do you know why older versions aren't preserved anywhere?

We keep (most of) old images here:
https://fi.mirror.armbian.de/archive/

https://fi.mirror.armbian.de/oldarchive/