GRUB EFI Boot: Data Abort Exception

#1

I’m trying to set up an image for Talos Linux. It’s got its own pretty opinionated & minimalist image generator that assumes a GRUB EFI boot, and I cannot practically use something like extlinux.conf instead (believe me, I went pretty far down this road :stuck_out_tongue:)

For slightly more context, I re-compiled radxa/u-boot with EFI support by adding the following to ./u-boot/configs/rock-5b-rk3588_defconfig:

CONFIG_CMD_BOOTEFI=y
CONFIG_EFI_LOADER=y

This is all working, and I can get to a GRUB shell that was loaded via the EFI and has access to the root partition.

As soon as I try to actually boot the kernel, however, I’m getting a Data abort exception.

Here’s the full log:

Booting `A - Talos v1.2.0-alpha.2-32-gfaf92ce01-dirty'

EFI stub: Booting Linux Kernel...
EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value
EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary
EFI stub: ERROR: Could not determine UEFI Secure Boot status.
EFI stub: Using DTB from configuration table
EFI stub: ERROR: Failed to install memreserve config table!
EFI stub: Exiting boot services and installing virtual address map...
"Synchronous Abort" handler, esr 0x96000010

* Reason:        Exception from a Data abort, from current exception level
* PC         =   00000000002044d0
* LR         =   00000000002044cc
* SP         =   00000000eb9f6d60
* ESR_EL2    =   0000000096000010
* Reloc Off  =   00000000edb66000

x0 : 0000000000400000 x1 : 0000000000000000
x2 : 0000000000000000 x3 : 00000000ebd6daea
x4 : 0000000000000000 x5 : 0000000000000010
x6 : 0000000000000000 x7 : 00000000ede2d704
x8 : 0000000000000008 x9 : 0000000000000003
x10: 0000000000000044 x11: fffffffffffffffd
x12: 0000000000000000 x13: 00000000eb9f6ec8
x14: 00000000a7d10000 x15: 00000000eb9f6e6c
x16: 00000000ea9c2030 x17: 0000000000000005
x18: 00000000eb9ffce0 x19: 0000000000400000
x20: 0000000000000000 x21: 00000000ab3a9000
x22: 00000000ebd85d80 x23: 00000000ab2c0a64
x24: 00000000eb9f7058 x25: 00000000ebd85d80
x26: 00000000ab3a9000 x27: ffffffffffffffff
x28: 00000000ab3a1161 x29: 00000000eb9f6f40


Call trace:
  PC:   [< 002044d0 >]
  LR:   [< 002044cc >]

Stack:
        [< 002044d0 >]
        [< 00289454 >]
        [< ffffffffbd76067c >]
        [< ffffffffbd75afec >]
        [< ffffffffbd75a858 >]
        [< 002899a8 >]
        [< fffffffffcdc2dfc >]
        [< fffffffffce4558c >]
        [< fffffffffcca0c24 >]
        [< fffffffffcca07a8 >]
        [< fffffffffcc9cc20 >]
        [< fffffffffcc9d054 >]
        [< fffffffffcc9d130 >]
        [< fffffffffccaa404 >]
        [< fffffffffcca9018 >]
        [< fffffffffcca9e94 >]
        [< fffffffffcca9018 >]
        [< fffffffffcca827c >]
        [< fffffffffcc9cf50 >]
        [< fffffffffcca083c >]
        [< fffffffffcc9cc20 >]
        [< fffffffffcc9d054 >]
        [< fffffffffcc9d130 >]
        [< fffffffffce671f0 >]
        [< fffffffffce673f8 >]
        [< fffffffffce64e20 >]
        [< 00209088 >]
        [< 002093dc >]
        [< 00209460 >]
        [< 0022b08c >]
        [< 0021847c >]
        [< 00218630 >]
        [< 00217d80 >]
        [< 00218334 >]
        [< 00218110 >]
        [< 00218630 >]
        [< 00217d44 >]
        [< 0022a654 >]
        [< 0022b08c >]
        [< 0021847c >]
        [< 00218110 >]
        [< 00218630 >]
        [< 00217d44 >]
        [< 0022a654 >]
        [< 0022b08c >]
        [< 0021847c >]
        [< 00218630 >]
        [< 00217d44 >]
        [< 0022a654 >]
        [< 0022b08c >]
        [< 0021847c >]
        [< 00218110 >]
        [< 00218110 >]
        [< 00218630 >]
        [< 00217d44 >]
        [< 0022a654 >]
        [< 0022b08c >]
        [< 0021847c >]
        [< 00218110 >]
        [< 00218630 >]
        [< 00217d44 >]
        [< 0022a654 >]
        [< 0022b08c >]
        [< 0021847c >]
        [< 00218630 >]
        [< 00217d44 >]
        [< 0022a654 >]
        [< 0022b08c >]
        [< 0021847c >]
        [< 00218630 >]
        [< 00217d80 >]
        [< 00218334 >]
        [< 00218110 >]
        [< 00218630 >]
        [< 00217d44 >]
        [< 0022a654 >]
        [< 0022b08c >]
        [< 0021847c >]
        [< 00218630 >]
        [< 00217d44 >]
        [< 0022a5b8 >]
        [< 00218cd0 >]
        [< 00216b58 >]
        [< 0021934c >]
        [< 0028fcf8 >]
        [< 002195c4 >]
        [< 00201e18 >]

Copy info from "Call trace..." to a file(eg. dump.txt), and run
command in your U-Boot project: ./scripts/stacktrace.sh dump.txt 

Resetting CPU ...

### ERROR ### Please RESET the board ###

I didn’t get anywhere with stacktrace.sh from radxa/u-boot, unfortunately. It didn’t symbolicate anything - I did tell it to use the same gcc toolchain from radxa/toolchain that I used for the build because it was looking for one that didn’t exist but not sure if that was really the problem.

I’m using the kernel & DTB from the most recent Debian Bullseye release (rock-5b-debian-bullseye-xfce4-arm64-20221118-1736-gpt.img).

I’ve also tried a locally-compiled kernels/DTB (both linux-5.10-gen-rkr3.4 & stable-5.10-rock5) with the same result.

I tried looking at an Armbian EFI image for the Station M3 (an RK3588S-based board), specifically Armbian_22.11.0-trunk_Station-m3_jammy_legacy_5.10.66.img. I didn’t see any special clues there - its setup looks virtually identical to mine.

I’m not getting any Linux kernel output before the “Synchronous Abort” handler kicks in. I only have a single USB-TTL cable so can’t use earlycon but I’m skeptical it’d yield too much more either.

Does anyone have more experience or advice here?

#2

Ah, I think I found my answer: https://github.com/radxa/u-boot/issues/12#issuecomment-1321419215

Time to look at EDK2 :upside_down_face:

#3

did you get it to work with EDK2?

#4

I didn’t end up trying EDK2 - between this thread:

And then someone on Discord telling me:

I don’t think the BSP kernel is meant to be booted in UEFI mode at all. It fails in largely the same way when I try to boot it from the EDK2 shell (more complete UEFI implementation).

I decided it wasn’t worth pursuing :grimacing:

(I want support for Talos Linux, which can produce images for ARM64 with custom kernels assuming they support UEFI. I’m now very deep into a fork because that was the least of the issues :upside_down_face:)

#5

I wonder who wrote it?

Here are images (20221209-EFI) with an almost working EFI\Grub for Rock5b. But to fully start the system, you need a UART console and execute a couple of commands in it, I haven’t found out yet. what is not enough to fully automatically start the system, grub stops in rescue mode (and you need to run two commands to continue).
On Firefly Station M3 everything works fine in automatic mode and there is a Grub menu in the UART console,

There is also an option with EDK2 in the 20221209-EDK2-EFI directory, but for me it stops at the request to save settings with a choice of where to start the system from, and does not want to accept the “Y” symbol from the UART console (I sin against the poor of my UART console).

1 Like
#6

I checked the launch of EFI\Grub mode when placing the entire system on NVMe, everything starts up and works fine with NVMe (while the SD card is used exclusively for u-boot placement, because I have not yet checked how my u-boot can be written to SPI). At the same time, the device startup sequence works correctly with my u-boot (unlike the stupid option used in the official u-boot for NVMe) - if you connect an SD card, the system automatically starts from the SD card, the system on NVMe does not interfere with this in any way, and I assume that the RKTools tools for work via USB, the same will work correctly. :stuck_out_tongue_closed_eyes:

p.s. I’m not really worried about where I’ll have a u-boot, on SPI or on an SD card, and I don’t want to risk my instance to waste time on recovery later if something doesn’t work. If someone wants to check how the new u-boot works from SPI, it can be installed on SPI by the standard procedure from armbian-conf (all files are included in the image).

1 Like
NVMe boot? Needs updated uboot?
#7

Ha ha… after installing the image from EFI\Grub on Nvme, I tried to connect an SD card with an EDK2-EFI image and voila, there is a Grub menu in the UART console and the system starts and works normally. :)

1 Like
#8

That sounds very interesting!
But UART console sounds somewhat hacky.

Would it be possible to get output from your grub on standard monitor?
EFI or no EFI? What ever …
Like any linux works?

Guess eMMc or NVMe are big enuf to hold a grub with several bootable partitions.
Grub is what I miss most with radxa rockpi.

What you think?

#9

You can, “just” add the necessary patches. Do you have such patches for HDMI on rk3588 (for u-boot or for EDK2) ?

#10

Do you have instructions for building these images from source? I have reservations against flashing random images on Yandex built from unknown sources.

#11

Instructions for creating Armbian and sources are freely available.

https://docs.armbian.com/Developer-Guide_Build-Preparation/

Information about EDK2 and sources - all links are on this forum.

#12

Thanks a lot!

For u-boot, what config options were needed beyond Radxa defaults?

#13

Sorry, I didn’t understand the question.

by the way, is this your GIT?

#14

Yes, it is.
That was my earlier attempt at compiling EDK2 with NVMe and graphics enabled.

#15

And what was the result?
By the way, what is your Rock 5b model with 16 GB of RAM or less?

#16

How does this process work? Asking for a noob friend :innocent:
Is it someting like:

  1. Flash radxa Ubuntu on sdcard
  2. Dd the image on the nvme
  3. Start from the sdcard and chroot into the nvme
  4. Install grub?
#17

I don’t understand the essence of the question, what do you want to get out?