Starting kernel invokes ""Synchronous Abort" - rk3328

[2K-ZONE]

I have a rockchip rk3328 Board here I am trying to boot linux kernel upon. It is a Dusun DSGW-210 which seems to resemble the setup

board=evb_rk3328 board_name=evb_rk3328

Dusun offers a SDK which they claim to be working in their system, the rootfs can be a debian or a buildroot one. I can not compile it (Host needs to be darn old, I got stuck realizing python2 with ftdi libs is required). Reagardeless I want to port their stuff to yocto linux anyway and since the u-boot an kernel config resemble vanilla evb_rk3328 setup and config I thought it should not be too hard. But it is. For me.

I used the JeffyCN yocto meta layer, compiled it and flashed the images. And voila, u-boot seems to work fine! However, when U-boot starts the kernel I get

"Synchronous Abort" handler, esr 0x02000000

The output looks this way:

=> boot Could not find misc partition ANDROID: reboot reason: "(none)" Not AVB images, AVB skip Booting IMAGE kernel at 0x00280000 with fdt at 0x08300000...

Fdt Ramdisk skip relocation No misc partition

Booting Android Image at 0x0027f800 ...

Kernel: 0x00280000 - 0x00af2957 (8651 KiB)

Flattened Device Tree blob at 0x08300000

Booting using the fdt blob at 0x08300000 XIP Kernel Image from 0x00280000 to 0x00280000 ... OK kernel loaded at 0x00280000, end = 0x00af2957 Using Device Tree in place at 0000000008300000, end 00000000083156fd WARNING: could not set reg FDT_ERR_BADOFFSET.

reserved-memory:

drm-logo@00000000: addr=7df00000 size=b8000 Adding bank: 0x00200000 - 0x08400000 (size: 0x08200000) Adding bank: 0x0a200000 - 0x80000000 (size: 0x75e00000) == DO RELOCATE == Kernel from 0x00280000 to 0x00200000 Total: 126428.23/126891.316 ms

Starting kernel ...

"Synchronous Abort" handler, esr 0x02000000

The decoded stackdump looks like this:

./scripts/stacktrace.sh stackdump

SYMBOL File: ./u-boot.sym

Call trace: PC: [< ffffffff8278f004 >] LR: [< 00201d90 >] do_bootm_linux+0x5c/0x74 /home/konsti/Dusun/yocto-JeffyCN/build/tmp/work/dsgw_210-poky-linux/u-boot-rockchip/1_2017.09-r0/git/arch/arm/lib/bootm.c:498

Stack: [< ffffffff8278f004 >] [< 0021757c >] boot_selected_os+0x48/0x80 [< 00216fbc >] do_bootm_states+0x8d0/0x950 [< 00226c44 >] android_bootloader_boot_kernel+0x15c/0x250 [< 00227918 >] android_bootloader_boot_flow+0x2a0/0x2a4 [< 00207970 >] do_boot_android+0xd0/0xf8 [< 0022c104 >] cmd_process+0xdc/0x10c [< 00215284 >] run_list_real+0x6e4/0x728 [< 00215438 >] parse_stream_outer+0x170/0x66c [< 00214b88 >] parse_string_outer+0xcc/0xe4 [< 0021513c >] run_list_real+0x59c/0x728 [< 00215438 >] parse_stream_outer+0x170/0x66c [< 00214b4c >] parse_string_outer+0x90/0xe4 [< 0022b628 >] run_command_list+0x50/0x90 [< 00215ad8 >] autoboot_command+0x40/0x114 [< 00213984 >] main_loop+0x58/0x68 [< 00216150 >] run_main_loop+0xc/0x10 [< 0027c46c >] initcall_run_list+0x58/0x94 [< 00216364 >] board_init_r+0x20/0x24 [< 00201940 >] relocation_return+0x4/0x0

PC Surrounding Instructions: ./make.sh: line 418: -D: command not found

I kindly ask, what could be the culprit? What should I do next to further debug the issue? I admit I am familiar with BSP creation but not so familiar with the rather modern rockchip tools and environment. Could be the format of the kernel image the culprit? I flashed the loader.bin and the WIC file flawlessly like mentioned on the main page with upgrade_tool.

What I especiall wonder is what does "WARNING: could not set reg FDT_ERR_BADOFFSET." mean, is this harmful or leading to the root cause?

I have full boot logs for the working Dusun u-boot and my u-boot available, is it from interest or helpful to post them here completely to compare?

Addresses appearing in the logs look similair in my u-boot like the Dusun u-boot (kernel load addr, RAM banks added, device tree addresses...).

[JeffyCN]

Hi, sorry, i don't know much about that.

It looks something wrong with the yocto's loader and kernel, so you can try to replace them with your local working version by flashing them alone after flashed the WIC. (e.g. upgrade_tool di -u uboot.img / upgrade_tool di -b boot.img)

[2K-ZONE]

Okay, no problem. We are gonaing to cross test and change working images soon. First we have to find out how to unbrick our device which happened yesterday :-D I will tell here when we find out how to get this build to work and what kernel (-image format) is expected. :-)

[JeffyCN]

you can press 'ctrl+d' in serial console during u-boot stage to enter rockusb download mode, and use upgrade_tool to flash new images.

or hold the maskrom key (to disable the emmc) and reset to enter maskrom(bootrom) mode.

[2K-ZONE]

We managed to exchange the Dusun SDK stuff with the files build from this yocto build. We exchanged to this bootloader first out without also exchanging the trust.img which let us to a status where the ctrl commands where not asked for yet:

U-Boot 2017.09 (Oct 08 2023 - 02:14:28 +0000)

Model: Rockchip RK3328 EVB MPIDR: 0x80000000 PreSerial: 2, raw, 0xff130000 DRAM: 2 GiB Sysmem: init Relocation Offset: 7da71000 Relocation fdt: 7bc664a8 - 7bc67ce2 CR: M/C/I Using default environment

DM: v1 rk3036_pll_set_rate: wait pll lock timeout! pll_id=4 rk3036_pll_set_rate: wait pll lock timeout! pll_id=2 rksdmmc@ff500000: 1, rksdmmc@ff520000: 0 Bootdev(atags): mmc 0 MMC0: High Speed, 52Mhz PartType: EFI boot mode: recovery (misc) RESC: 'recovery', blk@0x00027fa4 optee check api revision fail: 1.0 optee api revision is too low

ERROR ### Please RESET the board

But we revoered with the pin Dusun named EMMC_KEY and exchanged the original image with this build's u-boot AND trust and now we are booting again (yes it boots the original Dusun SDK kernel).

We are no investigating what the cuplrit is with this build#s kernel. Hang on, we will get it and tell. Many Thanks for your help!

[landswellsong]

Reporting the same issue on another RK3328 board with RK3328 EVB config. Juding from the stack trace it dies immediately after jumping to kernel code and hitting some garbage?

The kernel is z-compressed apparently could this be a factor? e.g. u-boot doesn't know how to decompress it tries to run as-is. Or is this decompression handled by the kernel itself at early boot?

Stock images both from the vendor and from another RK3328 boards boot fine (as far as going from u-boot to kernel is concerned anyway :) )

I'll try to do some frankenstein with a differing kernel and report back, but overall any pointers are appreaciated.

[landswellsong]

I managed to work around this issue by setting ROCKCHIP_KERNEL_COMPRESSED to 0 (e.g. in local.conf).

With "Rockchip-style" images we get the kernel packaged into an Android-format boot.img. With defaults this builds an image that is detected by file as:

zImage: LZ4 compressed data (v1.4+)

Even though I do see some kind of ARM preamble in the header (not an executable format expert!), I think this just has some format that should either be uncompressed by u-boot, or packaged in some other way. When you remove the compression i.e. you don't get zboot.img overwrite boot.img, you get this instead:

/tmp/boot/zImage: Linux kernel ARM64 boot executable Image, little-endian, 4K pages

And this boots normally. In my case it means 19 Mb vs 8 Mb, which is still nothing, but the whole thing looks like a packaging bug. @2K-ZONE can you please verify on your hardware? If this is the same thing, then maybe someone more knowledgeable about early boot can offer a longer standing solution.

[JeffyCN]

so maybe the loader is missing: CONFIG_LZ4=y CONFIG_LZMA=y

[landswellsong]

@JeffyCN yes, this actually fixes the issue Will someone patch the relevant config in u-boot-rockchip or should I make a PR here?

[JeffyCN]

will, i've uploaded a patch in yocto conf to disable compressing by default, since there're too much boards...

[landswellsong]

@JeffyCN maybe a config fragment for u-boot to enable both by default for all the boards?

[JeffyCN]

the bsp u-boot is maintained by other rockchip team, they are using those configs for some boards with different requirements, for example using uncompressed kernel might help to improve boot-speed. it would be a little hard for me to let them add these configs.

[2K-ZONE]

@2K-ZONE can you please verify on your hardware?

Yes, I will check this also on my board when I have time, maybe today or at least tomorrow!

[2K-ZONE]

Hey cool! I tested ROCKCHIP_KERNEL_COMPRESSED = "0" in my local.conf. The Kernel then has roughly 18MB size - obviously. And this one boots:

Hit key to stop autoboot('CTRL+C'):  0
Could not find misc partition
ANDROID: reboot reason: "(none)"
Not AVB images, AVB skip
Booting IMAGE kernel at 0x00280000 with fdt at 0x08300000...

Fdt Ramdisk skip relocation
No misc partition
## Booting Android Image at 0x0027f800 ...
Kernel: 0x00280000 - 0x01503008 (18957 KiB)
## Flattened Device Tree blob at 0x08300000
   Booting using the fdt blob at 0x08300000
   XIP Kernel Image from 0x00280000 to 0x00280000 ... OK
   kernel loaded at 0x00280000, end = 0x01503008
   Using Device Tree in place at 0000000008300000, end 00000000083156fd
WARNING: could not set reg FDT_ERR_BADOFFSET.
## reserved-memory:
  drm-logo@00000000: addr=7df00000 size=b8000
Adding bank: 0x00200000 - 0x08400000 (size: 0x08200000)
Adding bank: 0x0a200000 - 0x80000000 (size: 0x75e00000)
Total: 782.12/1247.189 ms
KONSTI WAS HERE!!!!!!!!!!!!!!! ARRRRRRRRRRRRRRRRRRRRRGH!

OHNE WORKSPACE.

MIT NEU, NUR UPDATE.IMG?????????????

Starting kernel ...

Including personal debug code :-) Thanks for sorting this out!

[landswellsong]

@2K-ZONE I also made a patch for u-boot-rockchip in my build to add the options that @JeffyCN suggested and it also works. E.g.

diff --git a/configs/rk3328_defconfig b/configs/rk3328_defconfig
index 45383565feb7..cc17d66deaad 100644
--- a/configs/rk3328_defconfig
+++ b/configs/rk3328_defconfig
@@ -146,3 +146,5 @@ CONFIG_RK_AVB_LIBAVB_USER=y
 CONFIG_OPTEE_CLIENT=y
 CONFIG_OPTEE_V1=y
 CONFIG_TEST_ROCKCHIP=y
+CONFIG_LZ4=y
+CONFIG_LZMA=y
\ No newline at end of file