Bug 2402498 - Firmware device tree fall back doesn't appear to be working
Summary: Firmware device tree fall back doesn't appear to be working
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: uboot-tools
Version: 43
Hardware: aarch64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Peter Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F43FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2025-10-08 13:29 UTC by Dusty Mabe
Modified: 2025-10-23 23:53 UTC (History)
11 users (show)

Fixed In Version: uboot-tools-2025.10-1.fc44 uboot-tools-2025.10-1.fc43
Clone Of:
Environment:
Last Closed: 2025-10-23 23:53:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dusty Mabe 2025-10-08 13:29:13 UTC
I'm trying to use uboot on a nanopi R5C. I've been working on and off with pbrobinson to get this board working without issue for some time now. I've been testing new versions of uboot from copr [1] and haven't been able to get it to work. The problematic symptom (i.e. when the correct DT isn't used) is that the internal eMMC isn't usable. If booted from SD card, you'll get errors when writing to the eMMC. If booting from the eMMC it will fail to boot (trying to mount the filesystems).

All of that context is building up to:

There were some fixes for this problem that landed some time ago [2], and should have also landed in newer uboot releases but apparently loading from FW doesn't seem to be working.

The only thing that appears to work is if I load the DT manually from the /boot/ partition (i.e. the one delivered by the kernel) during startup:

```
# load from eMMC 
#   => mmc list 
#   mmc@fe2b0000: 1
#   mmc@fe310000: 0 (eMMC)
#   => load mmc 0:2 ${kernel_addr_r} efi/fedora/grubaa64.efi
#   4210160 bytes read in 48 ms (83.6 MiB/s)
#   => load mmc 0:3 ${fdt_addr_r} ostree/fedora-coreos-0f14c4b606322a31f25eb70ab4afa9e397c34541192218baf8ef65f77c9fb129/dtb/rockchip/rk3568-nanopi-r5c.dtb
#   60703 bytes read in 43 ms (1.3 MiB/s)
#   => bootefi ${kernel_addr_r} ${fdt_addr_r}
```

When I boot purely without running the above commands the output looks like:


```

DDR 03ea844c5d typ 24/09/03-10:42:57,fwver: v1.23
In
wdqs_if: 0x1010100
LP4/4x derate en, other dram:1x trefi
SRX
ddrconfig:0
MID:0xff
LPDDR4X, 324MHz
BW=32 Col=10 Bk=8 CS0 Row=17 CS=1 Die BW=16 Size=4096MB
tdqss_lf: cs0 dqs0: 72ps, dqs1: -72ps, dqs2: 72ps, dqs3: -48ps,
tdqss_hf: cs0 dqs0: 72ps, dqs1: -72ps, dqs2: 72ps, dqs3: -48ps,

change to: 324MHz
PHY drv:clk:36,ca:36,DQ:29,odt:240
vrefinner:16%, vrefout:41%
dram drv:40,odt:0
clk skew:0x60

change to: 528MHz
PHY drv:clk:36,ca:36,DQ:29,odt:240
vrefinner:16%, vrefout:41%
dram drv:40,odt:0
clk skew:0x58

change to: 780MHz
PHY drv:clk:36,ca:36,DQ:29,odt:60
vrefinner:16%, vrefout:41%
dram drv:40,odt:0
clk skew:0x58
rx vref: 14.6%
tx vref: 36.0%

change to: 1560MHz(final freq)
PHY drv:clk:36,ca:36,DQ:29,odt:60
vrefinner:16%, vrefout:22%
dram drv:40,odt:80
vref_ca:00000071
clk skew:0x13
rx vref: 14.6%
tx vref: 20.8%
cs 0:
rdtrn RS:
DQS0:0x35, DQS1:0x32, DQS2:0x35, DQS3:0x37,
min  : 0xb  0xd 0x10  0xf  0x2  0x5  0xa  0x8 , 0x2  0x2  0xb  0xf  0xb 0x10  0xf 0x11 ,
       0xf  0xe  0xc  0xa  0x2  0x4  0x5  0xa , 0xb  0xb  0x7  0x1 0x10 0x10 0x12  0xf ,
mid  :0x26 0x27 0x2b 0x29 0x1d 0x20 0x24 0x24 ,0x1d 0x1d 0x26 0x29 0x26 0x2b 0x2a 0x2b ,
      0x2b 0x29 0x27 0x25 0x1e 0x1f 0x20 0x24 ,0x26 0x26 0x22 0x1c 0x2b 0x2a 0x2d 0x2a ,
max  :0x42 0x42 0x46 0x44 0x38 0x3c 0x3f 0x41 ,0x38 0x39 0x41 0x44 0x42 0x46 0x46 0x45 ,
      0x47 0x45 0x42 0x40 0x3a 0x3a 0x3b 0x3f ,0x42 0x41 0x3d 0x38 0x47 0x45 0x48 0x46 ,
range:0x37 0x35 0x36 0x35 0x36 0x37 0x35 0x39 ,0x36 0x37 0x36 0x35 0x37 0x36 0x37 0x34 ,
      0x38 0x37 0x36 0x36 0x38 0x36 0x36 0x35 ,0x37 0x36 0x36 0x37 0x37 0x35 0x36 0x37 ,
wrtrn RS:
DQS0:0x21, DQS1:0x5, DQS2:0x21, DQS3:0xa,
min  :0x68 0x6d 0x6e 0x6c 0x60 0x63 0x65 0x66 0x64 ,0x45 0x45 0x4d 0x51 0x4f 0x53 0x54 0x54 0x4d ,
      0x6d 0x6c 0x6a 0x68 0x61 0x61 0x63 0x65 0x69 ,0x52 0x50 0x4d 0x49 0x54 0x57 0x55 0x54 0x51 ,
mid  :0x83 0x87 0x89 0x87 0x7a 0x7d 0x7f 0x80 0x7d ,0x60 0x60 0x67 0x6b 0x6a 0x6d 0x6e 0x6d 0x67 ,
      0x89 0x88 0x83 0x82 0x7b 0x7b 0x7d 0x80 0x82 ,0x6c 0x6a 0x67 0x62 0x6e 0x71 0x70 0x6f 0x6b ,
max  :0x9e 0xa1 0xa4 0xa2 0x95 0x97 0x9a 0x9b 0x96 ,0x7b 0x7b 0x82 0x85 0x85 0x87 0x88 0x87 0x82 ,
      0xa5 0xa4 0x9d 0x9c 0x95 0x95 0x97 0x9b 0x9b ,0x87 0x84 0x81 0x7c 0x89 0x8c 0x8b 0x8a 0x85 ,
range:0x36 0x34 0x36 0x36 0x35 0x34 0x35 0x35 0x32 ,0x36 0x36 0x35 0x34 0x36 0x34 0x34 0x33 0x35 ,
      0x38 0x38 0x33 0x34 0x34 0x34 0x34 0x36 0x32 ,0x35 0x34 0x34 0x33 0x35 0x35 0x36 0x36 0x34 ,
CBT RS:
cs:0 min  :0x3e 0x37 0x40 0x37 0x40 0x38 0x40 ,0x40 0x39 0x40 0x37 0x40 0x37 0x40 ,
cs:0 mid  :0x7a 0x79 0x7b 0x78 0x7b 0x79 0x6d ,0x7a 0x79 0x7a 0x79 0x7a 0x78 0x6c ,
cs:0 max  :0xb6 0xbb 0xb7 0xba 0xb6 0xbb 0x9a ,0xb5 0xba 0xb5 0xbb 0xb5 0xb9 0x98 ,
cs:0 range:0x78 0x84 0x77 0x83 0x76 0x83 0x5a ,0x75 0x81 0x75 0x84 0x75 0x82 0x58 ,
out

U-Boot SPL 2025.10-rc5 (Sep 26 2025 - 00:00:00 +0000)
Trying to boot from MMC1
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
## Checking hash(es) for Image atf-3 ... sha256+ OK
NOTICE:  BL31: v2.13.0(release):
NOTICE:  BL31: Built : 00:00:00, Jul 23 2025
NOTICE:  BL31: Rockchip release version: v1.0


U-Boot 2025.10-rc5 (Sep 26 2025 - 00:00:00 +0000)

Model: FriendlyElec NanoPi R5C
SoC:   RK3568B2
DRAM:  4 GiB
PMIC:  RK809 (on=0x40, off=0x00)
Core:  321 devices, 27 uclasses, devicetree: separate
MMC:   mmc@fe2b0000: 1, mmc@fe310000: 0
Loading Environment from nowhere... OK
In:    serial@fe660000
Out:   serial@fe660000
Err:   serial@fe660000
Model: FriendlyElec NanoPi R5C
SoC:   RK3568B2
Net:   No ethernet found.
starting USB...
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
USB EHCI 1.00
USB OHCI 1.0
USB EHCI 1.00
USB OHCI 1.0
Bus usb@fcc00000: 1 USB Device(s) found
Bus usb@fd000000: 2 USB Device(s) found
Bus usb@fd800000: 1 USB Device(s) found
Bus usb@fd840000: 2 USB Device(s) found
Bus usb@fd880000: 1 USB Device(s) found
Bus usb@fd8c0000: 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Card did not respond to voltage select! : -110
Card did not respond to voltage select! : -110

  *** U-Boot Boot Menu ***

      Fedora
      mmc 0
      0. Exit


  Press UP/DOWN to move, ENTER to select, ESC to quit
Booting: Label: mmc 0 Device path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/eMMC(0)/eMMC(1)
Card did not respond to voltage select! : -110
error: ../../grub-core/term/serial.c:278:serial port `com2' isn't found.
error: ../../grub-core/commands/terminal.c:138:terminal `serial' isn't found.
error: ../../grub-core/commands/terminal.c:138:terminal `serial' isn't found.

                                                                                      GRUB version 2.12

 ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
 │*Fedora CoreOS 42.20250929.2.0 (ostree:0)                                                                                                                                                │

```

and the eMMC problem comes back. I'm expecting some sort of "using FW DTB" message or similar.


[1] https://copr.fedorainfracloud.org/coprs/pbrobinson/u-boot/
[2] https://github.com/torvalds/linux/commit/8eca9e979a1efbcc3d090f6eb3f4da621e7c87e0

Reproducible: Always

Comment 1 Dusty Mabe 2025-10-08 13:30:00 UTC
The version I'm using is uboot-images-copr-2025.10-0.7.rc5.fc43.noarch.rpm - I realize this isn't a koji built RPM but I was asked to open an issue here anyway.

Comment 2 Peter Robinson 2025-10-08 13:35:15 UTC
Thanks for the report, will investigate

Comment 3 Peter Robinson 2025-10-13 16:51:43 UTC
I can see this issue on the RPi4 and some other devices when booted with certain configs.

Comment 4 Fedora Blocker Bugs Application 2025-10-13 16:53:19 UTC
Proposed as a Blocker for 43-final by Fedora user pbrobinson using the blocker tracking app because:

 This is causing issues on at least rpi4 when booted with firmware DT with some overlays configured. As the original reporter suggested it's happening on other devices too.

Comment 5 Peter Robinson 2025-10-13 18:01:51 UTC
Seems it's regressed at some point after rc3.

Comment 6 Fedora Update System 2025-10-13 23:38:09 UTC
FEDORA-2025-a367024bc9 (uboot-tools-2025.10-1.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-a367024bc9

Comment 7 Fedora Update System 2025-10-14 06:42:39 UTC
FEDORA-2025-a367024bc9 (uboot-tools-2025.10-1.fc44) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 8 Kamil Páral 2025-10-14 07:54:27 UTC
Reopening for F43 processing.

Comment 9 Fedora Update System 2025-10-14 09:51:12 UTC
FEDORA-2025-5e69656e63 (arm-trusted-firmware-2.13.0-4.fc43 and uboot-tools-2025.10-1.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-5e69656e63

Comment 10 Adam Williamson 2025-10-15 01:06:11 UTC
+3 FE in https://pagure.io/fedora-qa/blocker-review/issue/1984 , marking accepted FE.

Comment 11 Fedora Update System 2025-10-15 01:17:12 UTC
FEDORA-2025-5e69656e63 has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-5e69656e63`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-5e69656e63

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

Comment 12 Lukas Ruzicka 2025-10-20 18:57:29 UTC
Discussed at the blocker review meeting on 20th Oct. 2025

AGREED AcceptedFinalBlocker 

This is accepted as a blocker on the basis that it's believed to affect relatively common configurations of the Raspberry PI 4 (a very commonly used device for Fedora aarch64) as well as the reported Nanopi R5C (@adamwill:fedora.im, 17:52:59)

https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2025-10-20/f43-blocker-review.2025-10-20-16.02.html

Comment 13 Adam Williamson 2025-10-21 17:12:49 UTC
Dusty, can you confirm this is fixed in https://kojipkgs.fedoraproject.org/compose/43/Fedora-43-20251016.1/ , and karma https://bodhi.fedoraproject.org/updates/FEDORA-2025-5e69656e63 if so? Thanks.

Comment 14 Dusty Mabe 2025-10-23 13:58:14 UTC
Hey Adam,

Unfortunately I can't test this properly. Because of the board I have (nanopi r5c) I have to use the build from copr.

I did test uboot-images-copr-2025.10-1.fc43.noarch.rpm [1] and I still couldn't get FW DT fallback working with it. Though, Peter has mentioned that the similar problem he was seeing with other boards (hence why I opened the bug) is fixed by this update. So the remaining issue must be something specific to the r5c (or that class of device).

[1] https://copr.fedorainfracloud.org/coprs/pbrobinson/u-boot/build/9695857/

Comment 15 Fedora Update System 2025-10-23 23:53:39 UTC
FEDORA-2025-5e69656e63 (arm-trusted-firmware-2.13.0-4.fc43 and uboot-tools-2025.10-1.fc43) has been pushed to the Fedora 43 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.