Bug 2264415 - Raspberry Pi 4 won't boot into graphical environment
Summary: Raspberry Pi 4 won't boot into graphical environment
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 40
Hardware: aarch64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: BetaBlocker, F40BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2024-02-15 13:34 UTC by Lukas Brabec
Modified: 2024-03-05 22:48 UTC (History)
34 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-03-05 22:48:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
journal log (235.11 KB, text/plain)
2024-02-15 13:34 UTC, Lukas Brabec
no flags Details
rpm -qa (66.52 KB, text/plain)
2024-02-15 13:34 UTC, Lukas Brabec
no flags Details

Description Lukas Brabec 2024-02-15 13:34:01 UTC
Created attachment 2016909 [details]
journal log

Description of problem:

Raspberry Pi 4 and 400 with Fedora 40 20240213.n.1 won't boot into graphical environment. Text part of boot (U-boot and systemd) is visible as expected, but when the computer switches to graphical, connected display goes black ("no hdmi signal from your device"). See the attached journal log. With nomodeset it boots as expected. Filing against GDM (which is probably the wrong component) as the error in journal is from gdm-x-session:

/usr/libexec/gdm-x-session[1276]: (EE) open /dev/dri/card0: No such file or directory
...snip...
/usr/libexec/gdm-x-session[1276]: (EE) open /dev/fb0: No such file or directory
...snip...
/usr/libexec/gdm-x-session[1276]: (EE) open /dev/dri/card0: No such file or directory
...snip...
/usr/libexec/gdm-x-session[1276]: (EE) open /dev/fb0: No such file or directory
/usr/libexec/gdm-x-session[1276]: (EE) No devices detected.
/usr/libexec/gdm-x-session[1276]: (EE)
/usr/libexec/gdm-x-session[1276]: Fatal server error:
/usr/libexec/gdm-x-session[1276]: (EE) no screens found(EE)


Version-Release number of selected component (if applicable):

Linux fedora 6.8.0-0.rc4.20240212git716f4aaa7b48.35.fc40.aarch64 #1 SMP PREEMPT_DYNAMIC Tue Feb 13 00:16:47 UTC 2024 aarch64 GNU/Linux

gdm-46.alpha-4.fc40.aarch64
xorg-x11-server-Xorg-1.20.14-32.fc40.aarch64
uboot-images-armv8-2024.01-2.fc40.noarch

Comment 1 Lukas Brabec 2024-02-15 13:34:44 UTC
Created attachment 2016910 [details]
rpm -qa

Comment 2 Fedora Blocker Bugs Application 2024-02-15 13:39:05 UTC
Proposed as a Blocker for 40-beta by Fedora user lbrabec using the blocker tracking app because:

 A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility.

Comment 3 Geoffrey Marr 2024-02-20 05:37:26 UTC
Discussed during the 2024-02-19 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Beta)" was made as it violates the following criterion:

"Release-blocking ARM disk images must boot to the initial-setup utility" for the ARM Workstation disk image (which is release-blocking) on the Raspberry PI 4 (which is a "supported ARM platform" as defined right above that criterion).

[0] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-02-19/f40-blocker-review.2024-02-19-17.00.log.txt

Comment 4 Lukas Brabec 2024-02-20 15:46:20 UTC
Testing 40-20240219.n.0.aarch64:
Raspberry Pi 4: Workstation does boot, but has the same issue (and goes graphical with nomodeset). The same issue is when trying to boot KDE.
Raspberry Pi 400: neither Workstation nor KDE boots.

Workstation-39-1.5.aarch64 boots on both RPi 4 and 400.

Comment 5 Adam Williamson 2024-02-20 17:24:32 UTC
well, it's clearly not gdm now. probably kernel or mesa, let's guess mesa. Also CCing Peter as this is obviously a significant ARM bug and he may have some idea about it.

Comment 6 Peter Robinson 2024-02-20 17:41:29 UTC
There's actually two problems here.

Comment 7 Peter Robinson 2024-02-20 18:43:37 UTC
So the first bug is rhbz #2247873 which is the issue we saw at GA for F-39 which caused us to roll back U-Boot, I have been working on this and hope to have a fix soon.

The second bug, which is partially as a result of the first bug, is because the downstream RPi DT that is provided added an incompatibility around the sound which causes an error on the vc4 display driver loading:

Jan 25 01:00:09 fedora kernel: vc4_hdmi fef00700.hdmi: Could not register PCM component: -517

I believe this DT change in downstream DT causes the issue:
https://github.com/raspberrypi/linux/commit/0491a0aecb999b1a013ad4a6ad3816c535ac6e73

There has been mention of sending the associated kernel change upstream but I am not sure if it has been sent or not.

So the first bug is referenced above, and this bug is a kernel bug.

Comment 8 Adam Williamson 2024-02-20 23:38:52 UTC
I thought #2247873 was specific to Server because of the whole XFS /boot thing?

Comment 9 Peter Robinson 2024-02-21 00:15:20 UTC
(In reply to Adam Williamson from comment #8)
> I thought #2247873 was specific to Server because of the whole XFS /boot
> thing?

Sort of, there was an extra bug introduced upstream that made U-Boot not be able to find the DT on /boot because the ESP is the first partition. So the server issue will still exist after the other bug ceases to exist. That's where this bug kicks in in that use case due to the FW DT problem with the kernel.

Comment 10 Fedora Update System 2024-03-04 19:32:43 UTC
FEDORA-2024-20c5181331 (bcm283x-firmware-20240229-1.dc94391.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-20c5181331

Comment 11 Fedora Update System 2024-03-05 01:58:48 UTC
FEDORA-2024-20c5181331 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-20c5181331`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-20c5181331

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

Comment 12 Lukas Brabec 2024-03-05 15:10:49 UTC
(In reply to Fedora Update System from comment #10)
> FEDORA-2024-20c5181331 (bcm283x-firmware-20240229-1.dc94391.fc40) has been
> submitted as an update to Fedora 40.
> https://bodhi.fedoraproject.org/updates/FEDORA-2024-20c5181331

This update fixes the problem for Raspberry Pi 4. Tested Workstation-40-20240223.n.0 (the latest compose nominated) and Workstation-40-20240304.n.0 (the latest from Adam's nightlies page), both hit this bug, then I booted with nomodeset, installed this update and finally I was able to boot to graphical environment.

Raspberry Pi 400 doesn't boot at all with 40-20240223.n.0 and 40-20240304.n.0 (tested both as is and with the firmware update), the display is black from the start (but display is on, there is a backlight). 40-20240219.n.0 shows the same behaviour. I couldn't retest the 40-20240213.n.1 from the first comment, as it is not in kojipkgs anymore. fzatlouk pointed out that it could be due to u-boot bump. On 40-20240304.n.0, I downgraded u-boot to 2024.01-2.fc40, but the RPi400 behaves the same, black screen.

Comment 13 Peter Robinson 2024-03-05 15:17:32 UTC
> fzatlouk pointed out that it could be due to u-boot bump. On
> 40-20240304.n.0, I downgraded u-boot to 2024.01-2.fc40, but the RPi400
> behaves the same, black screen.

It's unlikely to be U-Boot in this context, can you file a different bug for this and I'll deal with that problem separately as it looks to be a different bug. My RPi-400 had a broken mSD slot so I'll need to test that with a USB stick. Pleas add karma on the update.

Comment 14 Adam Williamson 2024-03-05 16:04:21 UTC
We don't list the Pi 400 as supported at https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi , so I think we can say the release-blocking aspect is fixed if Pi 4 works, and the new bug doesn't have to be a blocker?

Comment 15 Geoffrey Marr 2024-03-05 16:10:43 UTC
(In reply to Adam Williamson from comment #14)
> We don't list the Pi 400 as supported at
> https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi , so I think
> we can say the release-blocking aspect is fixed if Pi 4 works, and the new
> bug doesn't have to be a blocker?

I would say the RPi4 and RPi400 are the same thing... I almost explicitly use the 400 for all my ARM/IoT testing. I realize there are minor differences, but I think most users will equate the 4 and 400... "The 400 just has an added keyboard" (from a user's POV).

Comment 16 Geoffrey Marr 2024-03-05 16:13:08 UTC
(In reply to Geoffrey Marr from comment #15)
> (In reply to Adam Williamson from comment #14)
> > We don't list the Pi 400 as supported at
> > https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi , so I think
> > we can say the release-blocking aspect is fixed if Pi 4 works, and the new
> > bug doesn't have to be a blocker?
> 
> I would say the RPi4 and RPi400 are the same thing... I almost explicitly
> use the 400 for all my ARM/IoT testing. I realize there are minor
> differences, but I think most users will equate the 4 and 400... "The 400
> just has an added keyboard" (from a user's POV).

...almost *exclusively* use the 400...

Not explicitly.

It's early.

Comment 17 Adam Williamson 2024-03-05 16:24:36 UTC
ah, okay, that's unfortunate :/ Still needs to be a separate bug, then, but should probably be proposed as a blocker.

Comment 18 Peter Robinson 2024-03-05 17:20:34 UTC
> I would say the RPi4 and RPi400 are the same thing... I almost explicitly
> use the 400 for all my ARM/IoT testing. I realize there are minor
> differences, but I think most users will equate the 4 and 400... "The 400
> just has an added keyboard" (from a user's POV).

From the PoV of graphics they are the same thing, but it seems it's not even producing early output up to the grub2 stage which is a different bug. I suspect it needs to be filed against bcm283x-firmware

Comment 19 Peter Robinson 2024-03-05 18:28:13 UTC
> We don't list the Pi 400 as supported at
> https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi , so I think
> we can say the release-blocking aspect is fixed if Pi 4 works, and the new
> bug doesn't have to be a blocker?

I have updated this.

Comment 20 Adam Williamson 2024-03-05 18:59:13 UTC
I went ahead and filed https://bugzilla.redhat.com/show_bug.cgi?id=2267968 for the 400 issue, so we don't lose it if this update is pushed stable.

Comment 21 Fedora Update System 2024-03-05 22:48:34 UTC
FEDORA-2024-20c5181331 (bcm283x-firmware-20240229-1.dc94391.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.