rnytom Posted January 17 Posted January 17 Hello, While upgrading my rock64 today, my Linux kernel was upgraded from 6.6.32 to 6.12.9. After rebooting, the board refused to boot: Boot script loaded from usb 0 | 166 bytes read in 407 ms (0 Bytes/s) | 26129699 bytes read in 1634 ms (15.3 MiB/s) | 36473344 bytes read in 48420 ms (735.4 KiB/s) | 54333 bytes read in 826 ms (63.5 KiB/s) | 2825 bytes read in 1653 ms (1000 Bytes/s) | Applying kernel provided DT fixup script (rockchip-fixup.scr) | ## Executing script at 09000000 | Unknown command 'kaslrseed' - try 'help' | Wrong Ramdisk Image Format | Ramdisk image is corrupt or invalid | I tried to manually copy the /boot files from the latest image, but the result was the same. I was able to recover it by copying the /boot files from an image from the archive (I used Armbian_23.11.1_Rock64_bookworm_current_6.1.63.img.xz), then once booted I used armbian-config to install 6.6.63 which also works fine. I'm just wondering if anyone else noticed the same issue with the 6.12.9 kernel (I did a quick search but I didn't find anything similar recently - sorry if I missed it) or if it's only for me? 1 Quote
ff255 Posted January 19 Posted January 19 Hello/ Yes, I have also stumbled on this. It took me a night to figure out and fix what had happened. My rock64 was set to auto-reboot on unattended upgrades, and after auto upgrade to 6.12.9 on 2025-01-16 it refused to boot (I found 6.12.9 in /boot dir). After connecting UART I got the same error: DDR version 1.13 20180428 ID:0x805 N In SRX LPDDR3 786MHz Bus Width=32 Col=11 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=4096MB ddrconfig:7 OUT U-Boot SPL 2017.09-rockchip-ayufan-1065-g95f6152134 (Apr 06 2020 - 08:10:17) board_init_sdmmc_pwr_en setup_ddr_param 1 booted from SPI flash Trying to boot from SPI NOTICE: BL31: v1.3(debug):9d3f591 NOTICE: BL31: Built : 14:39:02, Jan 17 2018 NOTICE: BL31:Rockchip release version: v1.3 INFO: ARM GICv2 driver initialized INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 1 INFO: plat_rockchip_pmu_init: pd status 0xe INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s dK 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 2017.09-rockchip-ayufan-1065-g95f6152134 (Apr 06 2020 - 08:10:39 +0000) Model: Pine64 Rock64 DRAM: 4 GiB MMC: rksdmmc@ff520000: 0, rksdmmc@ff500000: 1 SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In: serial@ff130000 Out: serial@ff130000 Err: serial@ff130000 Model: Pine64 Rock64 misc_init_r cpuid=55524b503039303135000000000e2b23 serial=2e629a67b70686a Net: eth0: ethernet@ff540000 Hit any key to stop autoboot: 0 Card did not respond to voltage select! mmc_init: -95, time 9 Card did not respond to voltage select! mmc_init: -95, time 10 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: Core Release: 3.10a USB3: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus 0 for devices... 2 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 3 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Device 0: Vendor: JMicron Rev: 0409 Prod: Generic Type: Hard Disk Capacity: 122104.3 MB = 119.2 GB (250069680 x 512) ... is now current device Scanning usb 0:1... Found U-Boot script /boot/boot.scr 3185 bytes read in 235 ms (12.7 KiB/s) ## Executing script at 00500000 Boot script loaded from usb 0 166 bytes read in 209 ms (0 Bytes/s) 17928114 bytes read in 1128 ms (15.2 MiB/s) 36473344 bytes read in 1935 ms (18 MiB/s) 54333 bytes read in 1433 ms (36.1 KiB/s) 2825 bytes read in 1809 ms (1000 Bytes/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid SCRIPT FAILED: continuing... Speed: 1000, full duplex BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 ... Thanks to your message and recovery instructions, I managed to repeat it and got a working board! 👍 But now I used armbian-config and selected "SY203 - Disable Armbian kernel upgrades" Seems like it's working # apt-mark showhold armbian-firmware linux-dtb-current-rockchip64 linux-image-current-rockchip64 Thank you very much! 🙏 0 Quote
sans-ltd Posted February 15 Posted February 15 Hello, did anybody find out what went wrong when building kernel 6.12 for the rock64 family of devices? I tried with Armbian_25.2.1_Rockpro64_bookworm_current_6.12.13_minimal.img.xz (kernel 6.12.13) and the issue still persisted. Regards Florian 0 Quote
eselarm Posted February 15 Posted February 15 Various things can be wrong; Yours might have an other cause then the one from @ff255. In the posted U-Boot log I also see JMicron; that brand is notorious for failing UAS and trim, although one should see errors (from U-Boot). Also the U-Boot shown is older and not Armbian originated I see. Also compression type for initramfs might be the failure reason. For my RK3688s and RK3568 SBCs, it really makes a differences what U-Boot I use. For mainline U-Boot, general Linux might/can work better, but some HW support might go wrong. So look what your objective is, what is the use-case of the SBC. You can make sure newer U-Boot is used, I don't know if it is available for rock64 family. Ultimately, those 6.12+ mainline kernels support EFI and virt virtual machines, so the whole image content except the bootloader should work in an aarch64 virtual machine; there you could see if kernel + generated initramfs is the problem, or just rock64 DTB, U-Boot on your board. Or as said the storage chain. I have seen endless issues with RaspberryPi(4) that are not a Linux issue, but just some HW/firmware issues originating from RPI platform. Can be similar for other brands boards. 0 Quote
djurny Posted 22 hours ago Posted 22 hours ago 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, 0 Quote
djurny Posted 8 hours ago Posted 8 hours ago 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. Spoiler 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 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 13115 bytes read in 6 ms (2.1 MiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1:1 636 bytes read in 5 ms (124 KiB/s) Imported environment (/boot/armbianEnv.txt) from mmc 1:1 to 0x9000000 Using version override -6.12.30-current-rockchip64 for image loading var_fdtfile=rk3399-kobol-helios64.dtb 90448 bytes read in 13 ms (6.6 MiB/s) Loaded DT (/boot/dtb-6.12.30-current-rockchip64/rockchip/rk3399-kobol-helios64.dtb) from mmc 1:1 to 0x01f00000 2825 bytes read in 9 ms (305.7 KiB/s) ## Executing script at 09000000 Sourced fixup script (/boot/dtb-6.12.30-current-rockchip64/rockchip/overlay/rockchip-fixup.scr) from mmc 1:1 to 0x9000000 38007296 bytes read in 1617 ms (22.4 MiB/s) Loaded kernel (/boot/Image-6.12.30-current-rockchip64) from mmc 1:1 to 2000000 Using kernel text_offset 0x0 bytes to calculate initial ramdisk load address Using kernel image_size 0x2520000 bytes to calculate initial ramdisk load address 17515242 bytes read in 747 ms (22.4 MiB/s) Loaded initial ramdisk (/boot/uInitrd-6.12.30-current-rockchip64) from mmc 1:1 to 4600000 Trying kaslrseed command... Info: Unknown command can be safely ignored since kaslrseed does not apply to all boards. Unknown command 'kaslrseed' - try 'help' Kernel commandline arguments: root=UUID=8ac95870-8815-4816-82da-6664b846fc34 rootfstype=f2fs rootwait splash=verbose console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=8 ubootpart=21825e31-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u,0x174c:0x1053:u rw net.ifnames=0 libata.force=1:3.0G,2:3.0G,3:3.0G,4:3.0G ipv6.disable=1 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory ## Loading init Ramdisk from Legacy Image at 04600000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 17515178 Bytes = 16.7 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 f4e32000, end f5ee62aa ... OK Loading Device Tree to 00000000f4e18000, end 00000000f4e31fff ... OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] 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. 0 Quote
djurny Posted 20 minutes ago Posted 20 minutes ago 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, 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.