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,

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

Hi, The output of `parted [.img file] unit s print` is: 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.

Great, so I used the config file provided in the previous post that I quoted, with a small change: I replaced "LINUXFAMILY" with "BOARDFAMILY". Am I to place patches to the kernel and u-boot inside userpatches? When in the build process should I do that? U-boot does work currently, and the original problem when I try to boot is that after "Starting Kernel..." I have nothing visible over HDMI or on the on board display (Or no way to check that I know of if anything is working). What I understand currently is that since U-boot works, I need to first provide a dts file that makes the display work, and then configure armbian build script to use that dts file, is that the way to go? On linux-sunxi mailing list I was told that the display on this works with the simple panel driver using the "starry kr070pe2t" entry. At this point I am not sure what the immediate next step should be. Thank you!

I have having the same issue as discussed here & it also provided solution for it https://github.com/IceWhaleTech/CasaOS/issues/1136 I have added cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1 to armbianEnv.txt The dmesg logs indicate that these arguments are failing [ 15.630904] Kernel command line: root=UUID=eb6a27ef-3932-431f-92fd-e61fea75356c rootwait rootfstype=ext4 splash=verbose console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=f3aeb909-d11b-ec42-a52c-4507e474335c usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u,0x1058:0x25a2:u cma=256M cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory [ 15.631910] Unknown kernel command line parameters "splash=verbose ubootpart=f3aeb909-d11b-ec42-a52c-4507e474335c cgroup_enable=memory cgroup_memory=1", will be passed to user space. . . . [ 18.261976] Run /init as init process [ 18.262019] with arguments: [ 18.262028] /init [ 18.262034] with environment: [ 18.262039] HOME=/ [ 18.262044] TERM=linux [ 18.262049] splash=verbose [ 18.262054] ubootpart=f3aeb909-d11b-ec42-a52c-4507e474335c [ 18.262060] cgroup_enable=memory [ 18.262065] cgroup_memory=1 [ 18.263469] mmcblk1: p1 p2 The bug still haunts me, any ideas how should I approach this problem