ff255

Hi @ff255,
There is an effort to add this calculation in the U-Boot bootscript. I'll have a look at doing this during updates to initramfs or kernel, good suggestion!
Groetjes,

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,

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,

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,

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?