rnytom Posted January 17, 2025 Posted January 17, 2025 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, 2025 Posted January 19, 2025 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, 2025 Posted February 15, 2025 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, 2025 Posted February 15, 2025 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 May 25, 2025 Posted May 25, 2025 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 May 25, 2025 Posted May 25, 2025 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 May 26, 2025 Posted May 26, 2025 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, 1 Quote
ff255 Posted January 11 Posted January 11 Hello, sorry for late answer, but I had no time to experiment with my rock64 board. Maybe this issue is already resolved, if so please let me know. I'm still using kernel 6.6.63 and holding kernel packages in order not to break a working home server. So I managed to temporary switch kernel to 6.12.9 again for testing (copied old /boot and corrected symlinks) and enter UART console: Скрытый текст 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 26.05.2025 в 06:18, djurny сказал: 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: Here is output of U-Boot commands you asked: Hit any key to stop autoboot: 0 => setenv b => setenv c => setenv a "a/b" => setexpr b sub "a/" "" a Unknown command 'setexpr' - try 'help' => echo ${b} => setexpr c 1 + 1 Unknown command 'setexpr' - try 'help' => echo ${c} => fdt fdt - flattened device tree utility commands Usage: fdt addr [-c] <addr> [<length>] - Set the [control] fdt location to <addr> fdt move <fdt> <newaddr> <length> - Copy the fdt to <addr> and make it active fdt resize [<extrasize>] - Resize fdt to size + padding to 4k addr + some optional <extrd fdt print <path> [<prop>] - Recursive print starting at <path> fdt list <path> [<prop>] - Print one level starting at <path> fdt get value <var> <path> <prop> - Get <property> and store in <var> fdt get name <var> <path> <index> - Get name of node <index> and store in <var> fdt get addr <var> <path> <prop> - Get start address of <property> and store in <var> fdt get size <var> <path> [<prop>] - Get size of [<property>] or num nodes and store in <var> fdt set <path> <prop> [<val>] - Set <property> [to <val>] fdt mknode <path> <node> - Create a new node after <path> fdt rm <path> [<prop>] - Delete the node or <property> fdt header - Display header info fdt bootcpu <id> - Set boot cpuid fdt memory <addr> <size> - Add/Update memory node fdt rsvmem print - Show current mem reserves fdt rsvmem add <addr> <size> - Add a mem reserve fdt rsvmem delete <index> - Delete a mem reserves fdt chosen [<start> <end>] - Add/update the /chosen branch in the tree <start>/<end> - initrd start/end addr NOTE: Dereference aliases by omitting the leading '/', e.g. fdt print ethernet0. => echo ${fdtfile} rockchip/rk3328-rock64.dtb => echo ${fdt_addr_r} 0x01f00000 => echo ${kernel_addr_r} 0x02000000 => echo ${ramdisk_addr_r} 0x04000000 => ver U-Boot 2017.09-rockchip-ayufan-1065-g95f6152134 (Apr 06 2020 - 08:10:39 +0000) aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 GNU ld (GNU Binutils for Ubuntu) 2.30 => CTRL-A Z for help | 1500000 8N1 | NOR | Minicom 2.10 | VT102 | Offline | ttyUSB0 I have set up rock64 to boot from SSD connected over USB3-SATA adapter (bought from pine64 store) without SD-card. To make it work I flashed latest U-Boot from ayufan to SPI by this tutorial. Maybe this error because of old U-Boot, and you're right, looks like it doesn't support setexpr command 26.05.2025 в 06:18, djurny сказал: does not have setexpr built-in djurny, thank you for looking into this. And one question I don't understand, if I should upgrade U-Boot in SPI or I should erase SPI and wirte U-boot somewhere else? And will I be able to boot directly from USB-SSD without SD-card after that? 0 Quote
djurny Posted January 14 Posted January 14 Hi @ff255, It's been a while, I'm assuming you are still getting the same error as mentioned below: 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... The output you shared helps, but can you share a little bit more? Would need to know the following for your case: Filesize of your kernel image file Filesize of your initrd file If possible, filesize of the DT file being loaded. With those three values, we should be able to calculate the correct load addresses and try booting. (All this also presuming that your issue is that the load addresses used by U-Boot/the bootscript do not leave enough room for either a kernel or initrd file, causing one of those to overlap the start of the other.) Groetjes, 0 Quote
ff255 Posted Saturday at 03:10 PM Posted Saturday at 03:10 PM Hello, @djurny 👋 Thank you for helping! I'm happy to provide as much info as I can 14.01.2026 в 03:25, djurny сказал: It's been a while, I'm assuming you are still getting the same error as mentioned Yes, I tried to load the same kernel (6.12.9) and got exactly the same error. 14.01.2026 в 03:25, djurny сказал: Filesize of your kernel image file Filesize of your initrd file If possible, filesize of the DT file being loaded. cd /boot/ ls -al ... -rw-r--r-- 1 root root 17928050 Jan 15 2025 initrd.img-6.12.9-current-rockchip64 ... -rw-r--r-- 1 root root 36473344 Jan 12 2025 vmlinuz-6.12.9-current-rockchip64 As I can guess this is DT file: cd /boot/dtb-6.12.9-current-rockchip64/rockchip/overlay/ ls -al ... -rw-r--r-- 1 root root 2825 Jan 12 2025 rockchip-fixup.scr ... 0 Quote
djurny Posted Sunday at 01:57 AM Posted Sunday at 01:57 AM Hi @ff255, Can you try with the following changes/additions to armbianEnv.txt: # previous load addresses # fdt_addr_r=0x01f00000 # kernel_addr_r=0x02000000 # ramdisk_addr_r=0x04000000 # new load addresses fdt_addr_r=0x01f00000 kernel_addr_r=0x02000000 ramdisk_addr_r=0x04400000 # new kernel_addr_r is aligned to 2MiB boundary # new ramdisk_addr_r is aligned to 2MiB boundary - not really neccessary afaik but "why not both?" Quick calculation below: edit: updated the sheet and put the correct numbers here Groetjes, 1 Quote
ff255 Posted 2 hours ago Posted 2 hours ago (edited) 18.01.2026 в 04:57, djurny сказал: # new load addresses fdt_addr_r=0x01f00000 kernel_addr_r=0x02000000 ramdisk_addr_r=0x04400000 Yay, it booted! 😃👏 @djurny , thank you very much! 🙏 bootlog from UART console Скрытый текст DDR version 1.13 20180428 ID:0x805 N In 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... 1 USB Device(s) found scanning bus 1 for devices... 2 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 3 for devices... 2 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 243 ms (12.7 KiB/s) ## Executing script at 00500000 Boot script loaded from usb 0 514 bytes read in 222 ms (2 KiB/s) 17928114 bytes read in 800 ms (21.4 MiB/s) 36473344 bytes read in 1261 ms (27.6 MiB/s) 54333 bytes read in 1424 ms (37.1 KiB/s) 2825 bytes read in 1796 ms (1000 Bytes/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 ## Loading init Ramdisk from Legacy Image at 04400000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 17928050 Bytes = 17.1 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 fbde9000, end fcf01f72 ... OK reserving fdt memory region: addr=1f00000 size=73000 Loading Device Tree to 00000000fbd73000, end 00000000fbde8fff ... OK Starting kernel ... Armbian 25.11.2 bookworm ttyS2 Sorry, I gave wrong size for DT file... That seems right: /boot/dtb-6.12.9-current-rockchip64/rockchip# ls -l |grep rock64 -rw-r--r-- 1 root root 54333 Jan 12 2025 rk3328-rock64.dtb I guess it's ok until DT is smaller than align size So AFAICS if kernel size will grow, I should just re-calc the values? But now I got another problem, with this kernel HDMI suddenly stopped working... and all 3 LEDs (dc in, pwr, stby) are ON at the same time... although this seems to be a separate topic.. UPD: after apt-mark unhold kernel, dtb, firmware packages, apt-updating (to 6.12.58 kernel) and rebooting HDMI started to work again! For me this topic is solved, thank you once again! 👍 (Now I just wonder where that load address values come from, and why they didn't auto-change on kernel upgrade...) Edited 1 hour ago by ff255 HDMI is working 0 Quote
djurny Posted 2 hours ago Posted 2 hours ago (edited) Hi @ff255, Next time, you can indeed try to calculate the load addresses using the following method: kernel_load_addr_r = (trunc( (fdt_load_addr_r + fdt_size + 1 + 64KiB) / align_to) + 1) * align_to ramdisk_load_addr_r = (trunc( (kernel_load_addr_r + kernel_size + 1) / align_to) + 1) * align_to With align_to being the alignment boundary - 2MiB for ARM64 and for other platforms it depends on their architecture, 4KiB is a safe and sane boundary to align to. edit (again): The +1 is to prevent an OBOE in U-Boot; if the next load_addr starts immediately after with no padding, the logic in U-Boot wrongly accuses the images to overlap The +64KiB is the "fdt_extrasize" which should allow for any possible addition to the DT by any of the (DT fixup) scripts. Groetjes, Edited 1 hour ago by djurny stop and think before i post 1 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.