-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version 1.29 No longer boots raspberrypi kernel, only boots upstream kernel #174
Comments
Are you booting in DeviceTree or ACPI mode? |
This is on ACPI with 3GB limit enforced: And this is on pure DeviceTree with 3GB limit enforced: Seems the same. Could be possible DeviceTree is not working? If i grep the configs of the 2 kernels for the word ALIGN the only differences I get are: Here are the 2 config files: |
CONFIG_SND_HDA_ALIGNED_MMIO=y being missing from the manually compiled kernel might be problematic because the pi4 cannot do unaligned reads and writes without handwritten assembly workarounds. The compiled kernel is probably using unimplemented/erroneous LDUR/STUR instructions and fails to boot. |
But that flag seems to be related to the intel HDA driver which is not present on the raspberrypi. Anyway I am going to experiment with the flags between the kernels and see what makes it boot. However I think this is a regression since there were no problems up to version 1.28 |
Despite there being no Intel HDA Sound on Raspberry Pi Hardware, the Linux Kernel for it still contains Intel HDA Drivers/Modules in the tree. This could still be one of many potential causes of the boot failure, the others are listed in the changelog for 1.29: Added Secure Boot, Enabled Boot Discovery Policy and Removed "unnecessary" ACPI CID's. |
I too experience this issue with 5.13 and 5.14 and acpi + device tree. Booting with u-boot and 5.14, also has this issue, so I would guess this is more related to some change in the kernel code than uefi code change. |
It does seem weird that version 1.28 works just fine though. In any case I started from the working config for the fedora mainline kernel and am working my way down to the raspberrypi kernel. And this is the default bcm2711_defconfig |
Please bear in mind that with each version of the UEFI firmware we release, we also update to the latest If you want to determine whether the issue has to do with the UEFI firmware or the Raspberry Pi Foundation support files, you should try to replace If it works, then the problem is not with the UEFI firmware. |
Yes that works so it is a regression in the support files. |
There appears to be a general issue with XHCI and DeviceTree in recent FW. In my limited testing (on RPi4 8GB) using 1.29 FW, I confirmed that Fedora 34 IoT works, but OpenSUSE Leap 15.3, and Debian 10 do not. The OS is not seeing XHCI/USB devices. You can confirm with the OS kernel messages on the serial console, which show xhci probe/init errors. . @jlinton may have more info. He is chasing and has opened a bug against the RPi firmware: raspberrypi/firmware#1617 . He also sent a patch to the EDK2 list (https://edk2.groups.io/g/devel/topic/84933264#79387), but that may not be sufficient if RPi foundation FW/DT files need to change |
This is possibly duplicate of #157 |
It might be related but in my case v1.29 fails to boot kernel 5.10.60 which might not contain these XHCI changes or whatever is causing this. While trimming down the fedora kernel, after changing some USB flags I did indeed run into this, so yes the problem is probably the same. |
Try it with the 1.32 firmware. |
seems to work fine. Then again I had already migrated to a custom kernel that worked anyway. |
I'm going to close this since it's been so long since I ran into this issue that I remember nothing about it. |
Hello, I upgraded today to 1.29 and when trying to boot a manually compiled kernel from https://github.com/raspberrypi/linux I am greeted by this message:
However the standard upstream kernel provided by fedora boots just fine. Also previous versions of the firmware including 1.28 boots the compiled kernels just fine.
The text was updated successfully, but these errors were encountered: