The title pretty much says it all. Its sad because this would be a very convenient way to boot except for one little hangup: KMS kills it all. I've tried for the past two weeks to find a work-around. I've tried initramfs, edid, enabling all the EFI kernel options, I've built a dozen kernels with various options enabled. The *only* way it will boot is by passing nomodeset. Otherwise, it freezes after "fb: Switching to radeondrmfb from EFI VGA". This happens very early on in the boot, after maybe 50 or 60 lines of output to the display. Nothing is written to dmesg. I understand Xorg requires KMS so passing nomodeset is not a solution. Bug #66791 is similar, but I'm not convinced its exactly the same issue. It seems a solution may require collaboration between rEFInd and stubloader developers. Let me know if there's something I can provide to help.
Hello, I have had this problem as well: kernel boots until "fb: Switching to radeondrmfb from EFI VGA" and then freezes. I even left it sitting there for a day just to be sure ;) I eventually solved it for myself, though. My problem was that I had set CONFIG_DRM_RADEON=y and CONFIG_FIRMWARE_IN_KERNEL=y in my kernel, but neglected to give it a list of firmware blobs or a firmware path. Honestly, I was a little confused by the CONFIG_EXTRA_FIRMWARE option at first. I didn't know I needed to put something in the little paretheses () beneath the option (and thus didn't read the "help" for it, either). |Device Drivers ---> | Generic Driver Options ---> | -*- Userspace firmware loading support | [*] Include in-kernel firmware blobs in kernel binary | () | ^ | Hmmmm, what's this, and can I do anything with it? | Oh well, I guess I'll go configure a logger or something. If I hadn't gone back and read the Gentoo docs later, I'd never have been able to figure that out, much less enter the correct values. This is where I learned how to set up the firmware properly: https://wiki.gentoo.org/wiki/Radeon#Firmware Note that this page provides a (very useful!) table of chipsets/cards and their corresponding firmware blob selections. After I set up the firmware correctly, everything booted up and worked very nicely. Both my machine and kernel were perfectly fine after all; the kernel was just a little misunderstood ;) My advice to the maintainers would be this: Give a a descriptive error message when the firmware isn't available. Something like this: ERROR: radeon firmware missing. CONFIG_FIRMWARE_IN_KERNEL is set to y, but the adjacent CONFIG_EXTRA_FIRMWARE and CONFIG_EXTRA_FIRMWARE_DIR options are either empty or incorrect. CONFIG_EXTRA_FIRMWARE="..." CONFIG_EXTRA_FIRMWARE_DIR="..." See <URL of documentation> for details. Try to also detect this during kernel configuration (or compilation), if possible. Even if you can't test the correctness of the selection during configuration, you should at least be able to weed out the obviously incorrect empty string. This all happened on an AMD A4-5000 APU that yields this graphics device with 'lspci': 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Kabini [Radeon HD 8330] Kernel 4.0.5 with Gentoo patchset (=sys-kernel/gentoo-sources-4.0.5).
Thanks Chad. The wiki you linked above says: "Microcode is required for R600 and newer GPUs." Mine is R500. I'm given to believe we have different problems. Congratulations on your solution.