Bug 2189528 - U-Boot fails to boot EFI on roc-cc-rk3328
Summary: U-Boot fails to boot EFI on roc-cc-rk3328
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: uboot-tools
Version: 38
Hardware: aarch64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Peter Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-04-25 14:06 UTC by Charles Timko
Modified: 2024-03-22 04:01 UTC (History)
9 users (show)

Fixed In Version: uboot-tools-2024.04-0.6.rc4.fc40
Clone Of:
Environment:
Last Closed: 2024-03-22 04:01:15 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Charles Timko 2023-04-25 14:06:45 UTC
When attempting to boot the ROC-RK3328-CC Renegade into Fedora IoT 38, the boot fails to boot as far as the version of the package used by Fedora IoT 37.

Reproducible: Always

Steps to Reproduce:
1. Flash Fedora IoT 38 to SD Card using -
`arm-image-installer --image=Fedora-IoT-38.raw.xz --target=roc-cc-rk3328 --media=/dev/sdb --selinux=off --resizefs
2. Insert SD Card into slot and power up board (I have a UART/TTL connection)
3. Wait for boot to fail
Actual Results:  
U-Boot 2023.04 (Apr 04 2023 - 00:00:00 +0000)

Model: Firefly roc-rk3328-cc
DRAM:  2 GiB
PMIC:  RK8050 (on=0x40, off=0x00)
Core:  226 devices, 22 uclasses, devicetree: separate
MMC:   mmc@ff500000: 1, mmc@ff520000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial@ff130000
Out:   serial@ff130000
Err:   serial@ff130000
Model: Firefly roc-rk3328-cc
Net:   eth0: ethernet@ff540000
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found EFI removable media binary efi/boot/bootaa64.efi
966711 bytes read in 55 ms (16.8 MiB/s)
Card did not respond to voltage select! : -110
No EFI system partition
No EFI system partition
Failed to persist EFI variables
Booting /efi\boot\bootaa64.efi
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
Unknown Relocation off 910543ff type f
LoadImage failed: Load Error
Device path: "VenHw(E61D73B9-A384-4ACC-AEAB-82E828F3628B)/Path(131,26,0x01000000831A0800)/Path(131,26,0x0000000084013000)/HD(1,MBR,0xC1748067)/\EFI\fedora\shimaa64.efi"
01 04 14 00 B9 73 1D E6 84 A3 CC 4A AE AB 82 E8 
28 F3 62 8B 03 1A 05 00 01 03 1A 05 00 00 04 01 
2A 00 01 00 00 00 00 08 00 00 00 00 00 00 00 A8 
0F 00 00 00 00 00 67 80 74 C1 00 00 00 00 00 00 
00 00 00 00 00 00 01 01 04 04 36 00 5C 00 45 00 
46 00 49 00 5C 00 66 00 65 00 64 00 6F 00 72 00 
61 00 5C 00 73 00 68 00 69 00 6D 00 61 00 61 00 
36 00 34 00 2E 00 65 00 66 00 69 00 00 00 7F FF 
04 00 

Expected Results:  
Expect to see the boot selection window for ostree

I used Fedora-IoT-38.20230419.2-20230419.2.aarch64.raw.xz

Comment 1 Charles Timko 2023-04-25 14:09:15 UTC
I should also add, I'm not entirely certain that this is the fault of u-boot or Fedora IoT and the way it sets up the partitions.

Comment 2 Peter Robinson 2023-04-25 14:11:01 UTC
(In reply to Charles Timko from comment #0)
> When attempting to boot the ROC-RK3328-CC Renegade into Fedora IoT 38, the
> boot fails to boot as far as the version of the package used by Fedora IoT
> 37.

I don't quite understand what you mean here, do you mean the version shipped with F-37 works properly, and 2023.04 does not? Does the version shipped with F-37 (2022.10 based) work to boot F-38?

Comment 3 Peter Robinson 2023-04-25 14:12:36 UTC
(In reply to Charles Timko from comment #1)
> I should also add, I'm not entirely certain that this is the fault of u-boot
> or Fedora IoT and the way it sets up the partitions.

Does a Fedora minimal aarch64 image work?

We did have some issues upstream with 2023.04 with various rockchip platforms but I had at least one rk3328 device report as working with the final 2023.04 build.

Comment 4 Charles Timko 2023-04-25 14:44:31 UTC
I will do some testing on both of those and report back.

Comment 5 Charles Timko 2023-04-25 15:59:30 UTC
If I use `arm-image-installer` to install the Fedora-Server-38 and then use the 2022.10 uboot, it actually boots up. I'll check to see if 2023.04 works later today during a break.

Comment 6 Charles Timko 2023-04-25 18:20:26 UTC
It looks like 2023.04 also boots the server image. There is something wrong somewhere else and not in u-boot. Thanks for your help.

Comment 7 Solomon Peachy 2024-01-31 13:46:59 UTC
FWIW I'm also seeing a similar issue with F39, uboot 2023.07, and the rock-pi-4c-rk3399 target.

I've tried the IoT and Cloud-Base F38 and F39 targets.  I'll try the server image next, as per the comments.

Comment 8 Peter Robinson 2024-01-31 14:01:45 UTC
Please try the minimal image, not the server image

Comment 9 Solomon Peachy 2024-01-31 14:41:41 UTC
Ok, with Fedora-Minimal-39-1.5.aarch64.raw.xz the Rock4SE gets through u-boot into grub, then after the "EFI: Exiting boot services" proceeds to crash hard with no display.  Sigh.

However, Fedora-Minimal-38-1.6.aarch64.raw.xz manages to boot successfully.  Huzzah!

FYI the minimal download needs to be more discoverable; I had to use google to find it as the main fedora web site didn't even list it as a download option.  Indeed, it's considered an alternative or secondary target, and not available via (some? most? any?) mirrors.

(And the arm-image-installer instructions need to also mention that not all arm images are created equal!)

Comment 10 Peter Robinson 2024-01-31 14:45:50 UTC
(In reply to Solomon Peachy from comment #9)
> Ok, with Fedora-Minimal-39-1.5.aarch64.raw.xz the Rock4SE gets through
> u-boot into grub, then after the "EFI: Exiting boot services" proceeds to
> crash hard with no display.  Sigh.

By display you mean HDMI or Serial output? Does that work on 38?

Comment 11 Solomon Peachy 2024-01-31 14:53:31 UTC
(In reply to Peter Robinson from comment #10)
> By display you mean HDMI or Serial output? Does that work on 38?

HDMI.  But it's not just the display, the whole thing is dead -- no blinking activity light, and the device doesn't attempt to get a DHCP address over the ethernet.

The F38 minimal image worked, with display, networking, working USB, and I was able to interactively finish the setup.  As I type this, it's downloading a large pile of updates.

But that is all outside the scope of this ticket.

Comment 12 Peter Robinson 2024-01-31 15:05:25 UTC
I'd be interested if you see the problem with the same GA kernel as F-39 on F-38.

Also you can add the following to the kernel command line with F-39 (at grub) at "earlycon uefi_debug debug earlyprintk" to see if it outputs anything more.

Comment 13 Solomon Peachy 2024-01-31 16:00:14 UTC
Additional data points -- the F38 6.2.x kernel worked and the current F38 6.6.x kernel worked.  Interestingly, only one of the four USB ports works on this thing.

Adding those extra options onto the F39 kernel cmdline made no difference.  The display simply switches off shortly after the "exiting boot services" line is displayed.

Comment 14 Fedora Update System 2024-03-21 16:25:44 UTC
FEDORA-2024-5f5380bab6 (arm-trusted-firmware-2.10.2-1.fc40 and uboot-tools-2024.04-0.7.rc4.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-5f5380bab6

Comment 15 Fedora Update System 2024-03-22 02:08:17 UTC
FEDORA-2024-5f5380bab6 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-5f5380bab6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-5f5380bab6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 16 Fedora Update System 2024-03-22 04:01:15 UTC
FEDORA-2024-5f5380bab6 (arm-trusted-firmware-2.10.2-1.fc40 and uboot-tools-2024.04-0.6.rc4.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.