djurny

Hi @Werner, Not to pick nits, but 7 is the highest level (lowest priority) you can give a printk() statement. To make them appear however, the loglevel of the printk() needs to be smaller than the loglevel of the console, meaning the [console] loglevel needs to be 7+1: loglevel= [KNL,EARLY] All Kernel Messages with a loglevel **smaller** than the console loglevel will be printed to the console. It can also be changed with klogd or other programs. The loglevels are defined as follows: Also, the following text also steers into the direction of using 8 instead of 7 to show all printk() messages: To change the current console_loglevel simply write the desired level to ``/proc/sys/kernel/printk``. For example, to print all messages to the console:: # echo 8 > /proc/sys/kernel/printk (Taken from https://www.kernel.org/doc/Documentation/core-api/printk-basics.rst.) Grt,

Hi @gyrex, You might want to try without the fstab entry for your root filesystem: UUID=024728b4-7d81-4433-8476-0f98407d1481 / ext4 defaults,noatime,commit=600,errors=remount-ro 0 1 and add the following to your armbianEnv.txt. extraargs=rw The fstab entry for your rootfs is there to remount your rootfs with some options, it is not there to actuall mount it - that's already done by the rootdev/rootfstype in your kernel commandline. or: change the last digit from 1 to 0 in the fstab entry for your rootfs to prohibit fsck during boot. Hopefully that would allow the system to complete it's boot and make room for some live troubleshooting. Thx, Groetjes,

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,

Hi @Vodalex, Write down the MAC address of the interface you want to use to wake up the Helios4. ip link show You would need to put the Helios4 in suspend, by either: sudo pm-suspend or: echo 'suspend' | sudo tee /sys/power/state To wake it up, from another system, make sure that wakeonlan is installed. Then: wakeonlan ${HARDWARE_ADDRESS} That should be it. Groetjes,

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,

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,

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,

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 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,

Hi there, Some things you might want to check or confirm: 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,

Hi, wake-on-lan should be working now due to https://github.com/armbian/build/pull/8235. Groetjes,

Testing on Nanopi R2S revealed that U-Boot there does not have setexpr built-in. I expect it will be the same on the 'Rock64' board you have? To make sure - as I do not have your hardware here - can you check if the following commands work on your U-Boot monitor commandline: setenv b setenv c setenv a "a/b" setexpr b sub "a/" "" a echo ${b} setexpr c 1 + 1 echo ${c} fdt Also, to give a workaround (hopefully), the output of the following on the U-Boot monitor commandline: echo ${fdtfile} echo ${fdt_addr_r} echo ${kernel_addr_r} echo ${ramdisk_addr_r} ver Thx, Groetjes,

Hi there, Ok, after some walking back and forth, typos, reboots, rewriting entire images, multiple armbianEnv.txt files, looking into U-Boot sources, googling (of course) I managed to find some things and got U-Boot on my Helios64 to boot properly again. In short, the aarch64 requirements to the linux kernel, the way U-Boot sometimes will move the loaded kernel image in memory might overwrite the starting point of the inital ramdisk. The load addresses for kernel and initial ramdisk are mostly hardcoded in U-Boot but can be overridden by armbianEnv.txt or the bootscript. As Helios64 uses Rockchip rk3399 from the aarch64 family, the attached boot.scr might also work for you. This bootscript will only work on aarch64 systems, as it assumes the kernel is uncompressed! If you test this, make sure to make a backup of your existing boot.scr or read up on how to regenerate the boot.scr from your boot.cmd. Make sure you have serial console available Copy the attached bootscript to /boot Add verbosity=1 (if not already there) to your armbianEnv.txt Reboot Would be great that if you test, to share the serial console output here to see it it also works for you. I will also test and verify on one of my Nanopi R2Ss somewhere today or tomorrow. Will put all the details into a pull request. Groetjes, Update: Removed boot.scr as testing on Nanopi R2S showed some misbehavior.

Hi there, I'm seeing the same while trying to update some U-Boot bootscripts on my Helios64 (rockchip aarch64). Seems there needs to be more space between $kernel_load_addr_r and $ramdisk_addr_r. How much is a bit puzzling, as for other archs it's usually enough to count the kernel's image size (and some alignment). If i come across something interesting, I will share here too. Groetjes,

I also have some oom issues when doing an aptitude upgrade in my opizero w/256 MiB ram. Guess even more on a 128MiB board like yours. Best to add a swap file to make sure upgrades go without issue. Grt,

Little odd that it fails to load the fix up script there; In the old boot.cmd it checks if it can find the file and loads it if it can. Can you share a serial console log of the 21.x release that did work? Incl aembianmonitor -u output? Thx, Grt,

Hi @Zaf9670, Your situation actually helped find an OBOE in the U-Boot image overlap test, so thank you for that! Can you try with an older image and share the U-Boot output? Also, can you add the following in your armbianEnv.txt: verbosity=8 earlycon=on console=serial I've had better experience with setting console to serial only and earlycon might help the kernel spew out some things earlier on. Groetjes,

Hi @Ed van den Enden, I'm still pressing "X" to doubt that dtoverlay=... will work for sunxi boards running Armbian like the Banana Pi M2 zero, as your points do not work on my Orange Pi zero (which is running sunxi Allwinner H2+ just like the Bananana Pi M2 zero). Also, your provided logging clearly indicates that the kernel did not configure any additional RTC, just the H2+ built-in one. But then again, I don't mind being wrong every now and then in life. Can you share the output of the following commands: ls -Failh /dev/rtc* ls -Failh /sys/class/rtc/ egrep -- . /sys/class/rtc/*/name dmesg | egrep -i -- 'rtc' And to read the actual clocks: sudo hwclock --rtc=/dev/rtc0 # per default this is the H2+ built-in RTC sudo hwclock --rtc=/dev/rtc1 # per default this is going to be the I2C RTC Posting the link to @IgorS's topic that shows exactly what to do here again: Also, for reference, here is a link to the Allwinner H2+ datasheet, where it also mentions clearly (chapter 4.8 RTC on page 171) that the SoC itself also has an on-board RTC (this is the RTC detected by the kernel as sun6i-rtc and the one you actually are reading in your case): https://wiki.friendlyelec.com/wiki/images/0/08/Allwinner_H2+_Datasheet_V1.2.pdf Groetjes,

Hi @Zaf9670, Are you sure you did the setenv fdt_addr_r 41000000 U-Boot claims DT is still loaded/applied to the original load address: Working FDT set to 41900000 Can you share your armbianEnv.txt and boot.cmd? I'll have a look at the defailt bootscript in the meantime, perhaps some parts of the bootscript is using fdt_addr_r and other parts might still use loadaddr or scriptaddr... Thx, Gr,

Hi @Zaf9670, Can you try to reset the U-Boot monitor, press any key to stop the autobooting, then enter the following on the commandline: setenv fdt_addr_r 41000000 setenv kernel_addr_r 41080000 setenv ramdisk_addr_r 42080000 These load addresses are based on the sizes of the DT (438272 bytes) and the kernel image (11013984 bytes). Then to kick off the boot: run bootcmd Do share the results please. Groetjes, p.s. That device tree is huge! 428 KiB??

Hi there, Now two pull requests are awaiting review: - https://github.com/armbian/build/pull/8166#issuecomment-2867147049 Update the boot.scr script to calculate load addresses in case `setexpr` is available on the U-Boot monitor. - https://github.com/armbian/build/pull/8170#issuecomment-2867915659 Enable the `setexpr` command on the U-Boot monitor, to unlock load address calculation in combination with the boot.scr update. Both are now tested OK using a built armbian 'minimal' image based on Bookworm. Groetjes,

Hi @Igor, all, Made some updates, see here (including some minor corrections). Tested it with a built image (bookworm-minimal) and it seems to work: I will see how i can change U-Boot configuration to allow for `setexpr` to work, as using `setexpr` will make sure this does not need constant changing whenever kernel grows in size. As this is my first pull request, not sure what to do next? Please have a look-see, Groetjes,

Hi @Zzzz, @Zaf9670, After it fails to boot, can you type the following in the U-Boot monitor prompt and share the ouput: echo $fdt_addr_r echo $kernel_addr_r echo $ramdisk_addr_r setexpr abc 1 + 1 echo "abc=x${abc}x" fdt header fdt header get def totalsize echo "def=x${def}x" Thanks, Groetjes,

Hi @Vaclav Rada, You can also disable the systemd 'predictable naming convention' of interface naming by adding: net.ifnames=0 to your kernel commandline. This can be done in armbianEnv.txt by adding them to the extraargs variable as follows: extraargs=net.ifnames=0 Would be better to adjust your armbianEnv.txt instead of changing on-disk systemd service unit files, as they will be overwritten whenever an update comes along. I have not seen a situation myself where using the 'new' naming convention for network interfaces would work out better. But perhaps my use cases are not as flashy as other's 🙂 Groetjes,

Hi @Igor, Seems that U-Boot 2019.04-armbian-2019.04-S3c99-P6351-H9530-V0854-Bb703-R448a does not have the `setexpr` command configured. I will do more testing and figure out how the change can handle `setexpr` missing and configuring U-Boot to have `setexpr` available. Thanks! Groetjes,

Hi @Heisath, I think i can make a pull request from here: https://github.com/armbian/build/compare/main...djurny:build:patch-1, but would like to see someone else besides me test and scrutinize change. If positive results are in, I would very happy to finally contribute something! Groetjes,