Created attachment 33766 [details] [review] Bios from firmware loading hack Apple's iMacs and MacBooks don't have a video bios loaded when booting the Linux Kernel via an EFI bootloader rather than using Apple's bootcamp PC bios compatibility layer. This prevents the ATI Radeon kernel modesetting from working. Grub2 has a functionality to load a video bios image from a file stored on the efi boot partition. This makes the user mode setting in the X11 driver happy, but the kernel driver doesn't find the bios(invalid PCI Rom signature). Hacking the driver to try the load-from-vram method doesn't work either. I have created a hacky new bios loading method that loads a bios image via the kernel firmware loader from radeon/vbios.bin. I created this file from a bootcamp boot in the way documented in the Grub 2 wiki(http://grub.enbug.org/TestingOnMacbook). This way radeon KMS works, but like loading a bios image via the bootloader this is not a particularily pretty solution. I am using a native EFI bootloader instead of bootcamp because bootcamp is not capable of booting from a USB disk.
Oh, I forgot: The Intel DRM driver works just fine with KMS without a bios image(tested with a GMA 965 aka X3100). On the Nvidia side I have to use the EFI framebuffer, then start X with the proprietary driver, which obviously breaks my EFI framebuffer. I'm looking forward to noveau...
Hi, since I'm triple booting my MBP for some time now (using mostly grub2@efi) I integrated your patch im my local git tree and can confirm it works as intended. Without using radeon-ucode binaries I'm able to run X in full resolution without any trouble (no direct rendering however). I was even able to compile the radeon kms driver directly into the kernel by including the vbios / ucode binaries as blobs or placing them in my intramfs. However when trying to enable direct rendering (by loading radion-ucodes) I get some serious display flicker and sometimes a wrong display placement. Looks like some timings are horribly wrong.. I really love to be able to boot my kernel in pure EFI mode without fakebios etc. If I can be of any help to improve the situation let me know. I'm not unexperienced in kernel/driver coding and I'm a happy guinea pig ;) -- my hardware specs -- MacBookPro8,2 (early 2011) - Intel Core I7 (2,2Ghz, quad) - ATI Radeon HD 6750m (the 1Gb model) ------------------------
I'm booting an imac12,2 in UEFI mode (need a "Run EFI in physical mode" patch before doing so), here's how : 1) boot from latest ubuntu live CD (hold alt, or c, at boot) 2) dump the bios dd if=/dev/mem of=vbios.bin bs=65536 skip=12 count=1 3) move it to your partition's /lib/firmware/radeon/vbios.bin 4) use your patch, but move the radeon_read_bios_from_firmware call before all other calls to get the bios (force using vbios.bin) That's it and thank you :)
What is the real reason that the driver doesn't see the video BIOS? Is it looking at the wrong address? Is some MMU wrongly setup? I mean the video BIOS is obviously there, if you can extract it with dd. I would rather see the real bug fixed than have a workaround.
(In reply to comment #4) I assume you're not familiar with mac or didn't read the while bug history. Mac are booted using the EFI runtime one of the successors to BIOS. > What is the real reason that the driver doesn't see the video BIOS? Is it > looking at the wrong address? Is some MMU wrongly setup? I mean the video BIOS > is obviously there, You're wrong here. The bios is there if you boot in 'legacy mode'. Legacy mode means your EFI machine will load and run a (slow) BIOS emulation. > if you can extract it with dd. This exact step happens in legacy mode. If you boot in native EFI you don't have any BIOS at all. > I would rather see the real > bug fixed than have a workaround. As nice as it sounds 'fixing' would imply writing a separate KMS driver which would work entirely without the need to access the BIOS.
Sorry for being slightly off-topic. I was implicitly referring to bug 27314, where I observe the same problem "radeon 0000:01:00.0: Invalid ROM contents" when booting in legacy mode (where we obviously do have a vbios).
(In reply to comment #3) > I'm booting an imac12,2 in UEFI mode (need a "Run EFI in physical mode" patch > before doing so), > here's how : > 1) boot from latest ubuntu live CD (hold alt, or c, at boot) > 2) dump the bios > dd if=/dev/mem of=vbios.bin bs=65536 skip=12 count=1 > 3) move it to your partition's /lib/firmware/radeon/vbios.bin > 4) use your patch, but move the radeon_read_bios_from_firmware > call before all other calls to get the bios (force using vbios.bin) > Thats exactly what I did on my MBP however the screen flicker remains.. I'm pretty sure the BIOS is valid (dmesg identifies it as ATOM BIOS: Apple) and strings revealed data like "Whistler Pro" which IIRC is the type code used by the Radeon HD 6xxx series. Since Jérémy has a working setup with GPU acceleration I can only suspect a problem in the microcode. iMac12,2 has a Radeon HD 6970M which utilizes the CAYMAN microcode while my Radeon HD6750M is using TURKS. So I'm stuck with working but non-accelerated radeondrmfb.
(In reply to comment #7) > Since Jérémy has a working setup with GPU acceleration I can only suspect a > problem in the microcode. iMac12,2 has a Radeon HD 6970M which utilizes the > CAYMAN microcode while my Radeon HD6750M is using TURKS. Mine is [1002:6740] : [ 9.285052] [drm] Loading TURKS Microcode which kernel version are you using ?
(In reply to comment #8) > Mine is [1002:6740] : > [ 9.285052] [drm] Loading TURKS Microcode > > which kernel version are you using ? 2.6.39-rc7-00215-g194a526 git head with local patches applied (phys-efi, radeon-firmware hack) I'm running Gentoo linux amd64.
linux 3.2-rc7 is working without any patch, just radeon kms, on iMac12,2 EFI boot. (grub-efi-amd64)
Still doesn't work for me, Linux 3.2.1, iMac5,1. Loading the module writes this in dmesg: [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. checking generic (c0010000 510000) vs hw (c0000000 8000000) fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver Console: switching to colour dummy device 80x25 radeon 0000:01:00.0: can't find IRQ for PCI INT A; please try using pci=biosirq radeon 0000:01:00.0: setting latency timer to 64 [drm] initializing kernel modesetting (RV530 0x1002:0x71C5 0x106B:0x0080). [drm] register mmio base: 0xC8400000 [drm] register mmio size: 65536 radeon 0000:01:00.0: Invalid ROM contents radeon 0000:01:00.0: Invalid ROM contents [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM radeon 0000:01:00.0: Fatal error during GPU init [drm] radeon: finishing device. [TTM] Memory type 2 has not been initialized. [drm] radeon: cp finalized vga_switcheroo: disabled radeon: probe of 0000:01:00.0 failed with error -22 From this point on the efi framebuffer is dead(not surprising). It is shown the last screen content from before the radeon driver was loaded.
It looks like there are more things odd in the iMac5,1 firmware: *) A lot of PCI devices don't work when booted via efi, most importantly the USB hosts. The kernel complains about broken interrupts. This can be worked around with the grub2 fakebios or loadbios commands. *) Even with my vbios.bin hack direct rendering doesn't work. Glxgears shows a black window and the screen freezes. The mouse pointer is still moving. I can kill the X server with SIGKILL, but then the display turns off and I have to reboot to recover. There are no obvious messages in the X server output, glxgears output(via ssh) or dmesg. The second problem can be worked around by putting the system to sleep after loading radeon.ko and before running a 3D app. S3 sleep works fine, and after the wakeup the GPU seems to work correctly. However, sleep mode doesn't magically fix the missing rom image. I'll attach a lspci -vvv output from before and after the standby and the dmesg output, maybe someone spots a difference in the GPU state.
Created attachment 56618 [details] lspci output before standby The radeon.ko module was loaded at this time with the firmware hack.
Created attachment 56619 [details] lspci output after standby
Created attachment 56620 [details] dmesg output
This works for my MacBook Pro 8,3. It allows me to use my thunderbolt monitor whilst booting via EFI, something that is not possible when using the Intel IGD.
Nouveau allows to load vbios from image file now. http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=c9b07e9e85e5b7fe38c9f009967e8bed51d3760b
What would it take to get this patch into mainline? Like I said before I have a MacBook Pro 8,3 and the patch works for me, allowing me to boot via EFI and use the Radeon graphics card to power my Apple Thunderbolt Display. This is something that was only possible when booting via BIOS.
IIRC, Matthew Garret had a patch to fetch the vbios from EFI during early boot. Also, there is a way to fetch the vbios on legacy free EFI systems via ACPI, however, I don't know if apple uses it or not.
(In reply to comment #19) > IIRC, Matthew Garret had a patch to fetch the vbios from EFI during early boot. Is this online anywhere? Do you have a link?
I'm on a Mac Pro 1,1 with the original ATI X1900XT card, and had similar problems booting via EFI. After the modesetting was initialized the screen went blank, but the computer completed booting. Therefore, I applied the patch, which made the kernel boot absolutely fine. When I want to start X however, the picture gets distorted. No errors or warnings are shown in the Xorg log file. Starting X with BIOS boot works absolutely fine with the same install. One thing I've no noticed is that the kernel doesn't reserve the memory space for the video ROM (0x000c0000-0x000cffff) in EFI boot as it does in BIOS mode. I've tried to write a DSDT patch for this to reserve the area, without success. I suspect that the ATI drivers (xf86-video-ati) tries to read the video ROM both from the kernel, that was placed there through the patch, and from the memory range, which is not there in EFI boot. I run a Gentoo install with Grub2 boot, 3.3 vanilla kernel, Xorg-server 1.12 and xf86-video-ati compiled from GIT.
Exact same issue appears on an HP EliteBook 8470p if you select "native UEFI" as boot method in setup. Legacy and hybrid boot options work fine. Changing bug title since this is not a Mac-specific issue, although it is more severe on Macs without the legacy/hybrid options easily accessible. It seems that the driver either cannot rely on the AtomBIOS being accessible, or we need to add code to enable the mapping with some PCI hacks?
On UEFI systems the vbios should be accessible via the ACPI VFCT. See the bottom of atombios.h for struct definitions. Macs do their own thing so I don't know if this will work on them or not.
(In reply to comment #23) > On UEFI systems the vbios should be accessible via the ACPI VFCT. See the > bottom of atombios.h for struct definitions. Macs do their own thing so I > don't know if this will work on them or not. Should this already work on 3.4.7 and should I file a separate report about ACPI VFCT being broken or is that future tense/upcoming? Also, in hybrid boot mode at least, acpidump gives me no hits for VFCT (just tried acpidump | grep VFCT, that should show something shouldn't it?) Will try under native UEFI in a minute...
(In reply to comment #24) > Should this already work on 3.4.7 and should I file a separate report about > ACPI VFCT being broken or is that future tense/upcoming? Support for fetching the vbios from VFCT still needs to be implemented. > > Also, in hybrid boot mode at least, acpidump gives me no hits for VFCT (just > tried acpidump | grep VFCT, that should show something shouldn't it?) Will try > under native UEFI in a minute... I'm not too familiar with ACPI and UEFI unfortunately. It's part of the GOP stuff for UEFI.
Created attachment 65100 [details] [review] hacked-up radeon VFCT BIOS access patch So the good news is that a VFCT ACPI table does indeed show up when I boot under UEFI native mode on the HP EliteBook. I hacked up some code to get the BIOS from there and it successfully brought up the card and drove my DisplayPort screen. (hack patch attached) The bad news is that the LVDS panel first went backlight-off, on starting X started displaying flickering pixelgarbage and at some later point the entire box locked up. I'll go diff the BIOS images against each other, maybe the BIOS from VFCT is corrupted...
(In reply to comment #26) > Created attachment 65100 [details] [review] [review] > hacked-up radeon VFCT BIOS access patch > > So the good news is that a VFCT ACPI table does indeed show up when I boot > under UEFI native mode on the HP EliteBook. > > I hacked up some code to get the BIOS from there and it successfully brought up > the card and drove my DisplayPort screen. (hack patch attached) > Excellent. > The bad news is that the LVDS panel first went backlight-off, on starting X > started displaying flickering pixelgarbage and at some later point the entire > box locked up. You probably need this patch: http://lists.freedesktop.org/archives/dri-devel/2012-July/025567.html
(In reply to comment #27) > > The bad news is that the LVDS panel first went backlight-off, on starting X > > started displaying flickering pixelgarbage and at some later point the entire > > box locked up. > > You probably need this patch: > http://lists.freedesktop.org/archives/dri-devel/2012-July/025567.html After both patches, that indeed fixes things as soon as X is started, but the console is still broken. After loading the module, the panel just switches off, though the console is still usable. Plugging my DisplayPort screen in also reenables the LVDS panel, although the image is wrapped around by around 100 pixels. (Left part of my prompt is on the right of the screen.) Wraparound might be related to the different resolution for the ext display; the external screen only shows the nonwrapping part of the image (and is therefore missing the first characters of the prompt). Either way that's a separate bug... Apart from the above, I now have working graphics (including 3D) on an UEFI native booted HP EliteBook. I'll clean up my hack VFCT patch and send it to dri-devel. P.S.: The laptop also needs your backlight control patch, thanks a zillion for that - you wouldn't believe how nuts that was driving me.
Is the lvds console display shifted if you don't connect any external monitor ?
(In reply to comment #29) > Is the lvds console display shifted if you don't connect any external monitor ? So far I only got the LVDS to display anything by connecting the DP monitor, so I don't really know. I didn't try much there... I'll try some other magic incantations/plug sequences tomorrow, maybe there's a sequence to get LVDS-only with it actually showing something. Starting X while the LVDS is off works fine, reenabling it. Also, the "LVDS off" state after loading the module has the backlight off too, maybe it's a bug in the brightness control and there is content but I just don't see it...
(In reply to comment #30) > (In reply to comment #29) > > Is the lvds console display shifted if you don't connect any external monitor ? > > So far I only got the LVDS to display anything by connecting the DP monitor, so > I don't really know. I didn't try much there... I'll try some other magic > incantations/plug sequences tomorrow, maybe there's a sequence to get LVDS-only > with it actually showing something. > > Starting X while the LVDS is off works fine, reenabling it. Correction: I just had a hard freeze after an hour or so of X use. Since I need to get some things done, I've booted in hybrid UEFI mode now with only the brightness patch applied. The LVDS-blank-after-insmod issue is gone, so it's not the backlight control I guess. Also, interestingly, the power consumption of the laptop was considerably lower under UEFI native mode (24W) vs. UEFI hybrid mode (29W). Could be either the CRTC programming patch or something completely unrelated.
Created attachment 65357 [details] [review] VFCT patch Hi David, I took the liberty of cleaning up your UEFI VFCT patch. I'd like to get it into the next drm fixes pull in the next day or so. If you are ok with it or would like anything changed, please let me know.
I tried the VFCT patch on a Mac Pro 1,1, and it gives me a kernel panic. I can't really give any details on it because the screen output is garbled. The previous patch with adding the video ROM to the kernel works, but without X support. Should the VFCT table show up in /sys/firmware/acpi/tables? If so, the Mac doesn't support this method. Does anyone know what Darwin/OSX does to get the ROM?
Created attachment 66308 [details] DSDT table from Macbook Pro 8,2 (EFI boot) Alex, Please see the DSDT table from a Macbook Pro booted in EFI mode. Maybe it will give you some ideas for extracting the VBIOS.
(In reply to comment #34) > Alex, > Please see the DSDT table from a Macbook Pro booted in EFI mode. Maybe it will > give you some ideas for extracting the VBIOS. Sorry, I'm not really much of an ACPI or Mac expert. I don't see anything relevant. IIRC, the vbios on macs is only available in boot services so it's likely gone by the time the OS is loaded. You'd probably need the boot loader to grab it and store a copy somewhere so the OS can access it when it loads. I'm not sure how Apple does it. Someone more familiar with Macs may have some ideas.
My guess would be that they simply store it in the driver, i.e. similarly to what my hack does. Considering that they have hardware and software under full control I don't see why they want a video bios that's separate from the driver.
A patch referencing this bug report has been merged in Linux v3.6-rc3: commit 268ba0a99f89a84dc5eb312470896113d0709c74 Author: David Lamparter <equinox@diac24.net> Date: Thu Aug 16 15:45:20 2012 -0400 drm/radeon: implement ACPI VFCT vbios fetch (v3)
Created attachment 67258 [details] dmesg output from failing loading of radeon driver in 3.6.0_rc3 I tried with kernel 3.6.0_rc3 (using the Gentoo Linux ebuild sys-kernel/git-sources-3.6_rc3) but that doesn't change anything... Maybe someone can use the attached dmesg log for some useful information. (This is without using any changes to GRUB, but when I load vbios.bin and int10.bin the behaviour doesn't change)
(In reply to comment #38) > Created attachment 67258 [details] > dmesg output from failing loading of radeon driver in 3.6.0_rc3 > > I tried with kernel 3.6.0_rc3 (using the Gentoo Linux ebuild > sys-kernel/git-sources-3.6_rc3) but that doesn't change anything... > Maybe someone can use the attached dmesg log for some useful information. > (This is without using any changes to GRUB, but when I load vbios.bin and > int10.bin the behaviour doesn't change) From what I've been told, you need to boot using the EFI stub method and not a boot-loader. Also, you may need to pass some kernel options (eg initrd) so the easiest way to do this is from within an EFI shell. How are you booting the kernel?
(In reply to comment #39) > From what I've been told, you need to boot using the EFI stub method and not a > boot-loader. Also, you may need to pass some kernel options (eg initrd) so the > easiest way to do this is from within an EFI shell. Do you have any more details on that? I'd like to try it! > How are you booting the kernel? linux /boot/vmlinuz root=/dev/sda3 I have never needed an initrd, all required modules are built in...
(In reply to comment #40) > (In reply to comment #39) > > From what I've been told, you need to boot using the EFI stub method and not a > > boot-loader. Also, you may need to pass some kernel options (eg initrd) so the > > easiest way to do this is from within an EFI shell. > Do you have any more details on that? I'd like to try it! Make sure you have CONFIG_EFI and CONFIG_EFI_STUB set for your kernel. Put the kernel image in a filesystem that can be read by the EFI firmware or has a driver for it. Boot into the EFI shell. I do this via rEFIt. cd to the location of the kernel then execute it by typing it's name. Kernel parameters can be listed after the kernel name. > > How are you booting the kernel? > linux /boot/vmlinuz root=/dev/sda3 > I have never needed an initrd, all required modules are built in... OK. So you haven't actually said, but you must be booting via Grub either in EFI mode or BIOS compatiability mode. Neither of those will work in extracting the AtomBIOS from the configurations. It needs to be done before calling ExitBootServices() in EFI mode and Grub isn't set up to do anything this tricky. Hence you have to use the inbuilt kernel loader in the EFI stub code.
Created attachment 67314 [details] EFI stub boot, 3.6-rc6 This doesn't work for me either, using EFI stub booting direct from Refind. dmesg attached. Some additional details: * MacBook Pro 8,3 * Arch Linux * Kernel 3.6rc6 * Kernel command-line: vmlinuz-linux-mainline-3.x.efi root=/dev/disk/by-label/Root ro add_efi_memmap radeon.modeset=1 i915.modeset=1 i915.lvds_channel_mode=2 initrd=\EFI\arch\initramfs-linux-mainline-3.x.img Relevent log lines: [ 5.146024] vga_switcheroo: enabled [ 5.146064] radeon 0000:01:00.0: Invalid ROM contents [ 5.146127] radeon 0000:01:00.0: Invalid ROM contents [ 5.146156] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM [ 5.146190] radeon 0000:01:00.0: Fatal error during GPU init [ 5.146221] [drm] radeon: finishing device. [ 5.146222] [TTM] Memory type 2 has not been initialized [ 5.147271] vga_switcheroo: disabled [ 5.147416] radeon: probe of 0000:01:00.0 failed with error -22
Seems to be my bad. I've got some extra patches that aren't in 3.6 to make this EFI stub booting thing work (not that the actual graphics switching works for me at the moment). They can be downloaded here: http://people.canonical.com/~sforshee/apple-gmux-patches/ However, I've been just rebasing them in my git tree for a while so I don't know if they cleanly apply.
(In reply to comment #43) > Seems to be my bad. I've got some extra patches that aren't in 3.6 to make > this EFI stub booting thing work (not that the actual graphics switching > works for me at the moment). They can be downloaded here: > > http://people.canonical.com/~sforshee/apple-gmux-patches/ > > However, I've been just rebasing them in my git tree for a while so I don't > know if they cleanly apply. Hi, My Hardware : macbook pro 8.2 OS: Ubuntu 12.04 I've tested on linux 3.6.2 with patchs 0002 to 0008 only, the others one are already included in 3.6.2 Linux EFI stub boot with the following options : [ 0.000000] Kernel Command line: vmlinuz-3.6.2.efi root=UUID=xxxxxxxx ro add_efi_memmap i915.lvds_channel_mode=2 i915.modeset=1 radeon.modeset=1 elevator=noop vt.handoff=7 initrd=EFI\gmux\initrd.img-3.6.2 Good news, the radeon card is recognised with an EFI stub boot only ! But the screens stay black !! (lcd panel and hdmi) ..., X is started because I heard lightdm ubuntu sound, but all are black, no X and no console frame buffer. grep drm /var/log/dmesg.0 [ 2.657608] [drm] Initialized drm 1.1.0 20060810 [ 2.714673] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 2.714678] [drm] Driver supports precise vblank timestamp query. [ 2.716738] [drm:intel_panel_setup_backlight] *ERROR* Failed to get maximum backlight value [ 2.759521] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [ 2.850547] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2 [ 2.875632] fbcon: inteldrmfb (fb0) is primary device [ 3.038809] fb0: inteldrmfb frame buffer device [ 3.038829] drm: registered panic notifier [ 3.187709] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 5.529949] [drm] radeon kernel modesetting enabled. [ 5.530228] [drm] initializing kernel modesetting (TURKS 0x1002:0x6741 0x106B:0x00E2). [ 5.530299] [drm] register mmio base: 0xB0800000 [ 5.530301] [drm] register mmio size: 131072 [ 5.530343] [drm] GPU not posted. posting now... [ 5.545249] [drm] Detected VRAM RAM=1024M, BAR=256M [ 5.545252] [drm] RAM width 128bits DDR [ 5.545356] [drm] radeon: 1024M of VRAM memory ready [ 5.545358] [drm] radeon: 512M of GTT memory ready. [ 5.545378] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 5.545380] [drm] Driver supports precise vblank timestamp query. [ 5.545512] [drm] radeon: irq initialized. [ 5.545516] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 5.545871] [drm] probing gen 2 caps for device 8086:101 = 2/0 [ 5.545874] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 5.545959] [drm] Loading TURKS Microcode [ 5.765427] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). [ 5.787353] [drm] ring test on 0 succeeded in 2 usecs [ 5.787761] [drm] ib test on ring 0 succeeded in 0 usecs [ 5.790458] [drm] Radeon Display Connectors [ 5.790462] [drm] Connector 0: [ 5.790464] [drm] LVDS-2 [ 5.790467] [drm] DDC: 0x6470 0x6470 0x6474 0x6474 0x6478 0x6478 0x647c 0x647c [ 5.790469] [drm] Encoders: [ 5.790471] [drm] LCD1: INTERNAL_UNIPHY [ 5.790473] [drm] Connector 1: [ 5.790475] [drm] DP-2 [ 5.790476] [drm] HPD1 [ 5.790479] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [ 5.790481] [drm] Encoders: [ 5.790482] [drm] DFP1: INTERNAL_UNIPHY1 [ 5.790484] [drm] Connector 2: [ 5.790486] [drm] DP-3 [ 5.790487] [drm] HPD2 [ 5.790490] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [ 5.790491] [drm] Encoders: [ 5.790493] [drm] DFP2: INTERNAL_UNIPHY1 [ 5.790495] [drm] Connector 3: [ 5.790497] [drm] DP-4 [ 5.790498] [drm] HPD3 [ 5.790501] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c [ 5.790503] [drm] Encoders: [ 5.790505] [drm] DFP3: INTERNAL_UNIPHY2 [ 5.790649] [drm] Special thermal controller config [ 5.793123] [drm] radeon: power management initialized [ 6.213991] [drm] fb mappable at 0x90142000 [ 6.213993] [drm] vram apper at 0x90000000 [ 6.213994] [drm] size 8294400 [ 6.213996] [drm] fb depth is 24 [ 6.213997] [drm] pitch is 7680 [ 6.214080] fb1: radeondrmfb frame buffer device [ 6.214085] [drm] Initialized radeon 2.24.0 20080528 for 0000:01:00.0 on minor 1 grep vga_switcheroo /var/log/dmesg.0 [ 4.279348] vga_switcheroo: enabled
(In reply to comment #44) > > Good news, the radeon card is recognised with an EFI stub boot only ! > > But the screens stay black !! (lcd panel and hdmi) ..., X is started because > I heard lightdm ubuntu sound, but all are black, no X and no console frame > buffer. It looks like you have a hybrid system with both an integrated GPU and a discrete GPU. You'll need to switch the mux to switch between the two GPUs (the integrated is probably selected by default). Apple has their own proprietary mux and I'm not sure how well it's supported in Linux.
Radeon now works for me on a MBP 8,2 booted from efistub in Linux 3.8.x. Can anyone else confirm this? You just need to make sure you add the PCI IDs to the xorg for both cards. Should Xorg detect them automatically? Is this another bug? Thank you! Now we just need the IGP to show something onscreen when switching to it and it will be perfect...
> Radeon now works for me on a MBP 8,2 booted from efistub in Linux 3.8.x. > Can anyone else confirm this? You just need to make sure you add the PCI IDs > to the xorg for both cards. Should Xorg detect them automatically? Is this > another bug? For nouveau on a MBA also booted via EFI stub I was told that "detection of display by Xorg" happened through some magic bit set by first going through efifb prior to native driver. Without going through efifb Xorg didn't want to choose the available nVidia GPU. (though linux console happily used the GPU). Possibly the same applies to radeon.
(In reply to comment #46) > Radeon now works for me on a MBP 8,2 booted from efistub in Linux 3.8.x. > Can anyone else confirm this? You just need to make sure you add the PCI IDs > to the xorg for both cards. Should Xorg detect them automatically? Is this > another bug? What do you mean by "make sure you add the PCI IDs to the xorg for both cards"? The driver should autodetect the cards fine. However for systems with multiple VGA cards, you may have to manually specify which ones you want to start X on.
(In reply to comment #48) > What do you mean by "make sure you add the PCI IDs to the xorg for both > cards"? The driver should autodetect the cards fine. However for systems > with multiple VGA cards, you may have to manually specify which ones you > want to start X on. Currently my xorg.conf.d directory contains the following config: $ cat /etc/X11/xorg.conf.d/* Section "Device" Identifier "Radeon Graphics" BusID "PCI:1:0:0" EndSection Section "Device" Identifier "Intel Graphics" BusID "PCI:0:2:0" Driver "intel" Option "AccelMethod" "sna" #Option "AccelMethod" "uxa" #Option "AccelMethod" "xaa" EndSection Is the BusID line in the intel device section not needed? What is needed for X to automatically detect multiple GPUs properly and show some video output from the correct card?
(In reply to comment #49) > > Is the BusID line in the intel device section not needed? What is needed for > X to automatically detect multiple GPUs properly and show some video output > from the correct card? You'll need to use vga-switcheroo to select the card you want to use. Then you should be able to start X without any config and it will start on the one selected by vga-switcheroo. Having two device sections as your config does will force X to try and start on both devices.
(In reply to comment #50) > You'll need to use vga-switcheroo to select the card you want to use. Then > you should be able to start X without any config and it will start on the > one selected by vga-switcheroo. Having two device sections as your config > does will force X to try and start on both devices. I tried without the BusID but all I got was a black screen. For some reason when I switch to the intel GPU I get a black screen also, though it did work when I booted from grub-efi earlier with the well documented outb commands to disable AMD (no BIOS from EFI w/o efistub). Not sure if it's an issue with vga-switcheroo, intel driver or something else. I don't know if it's a problem, but both cards are powered on at boot. I can switch back and forth between the GPUs (though it's tricky doing so blind when on intel graphics). Any other suggestions? Thanks.
(In reply to comment #51) > Any other suggestions? Thanks. You might ask on the dri-devel mailing list. This is getting off topic for this bug.
I can also confirm that Radeon KMS works on my MacBookPro8,2 with kernel version 3.8-rc6 and EFI stub boot. I also needed to add a device section to my xorg.conf. I don't see any video BIOS in /dev/mem so I guess it is loading from ACPI instead. Out of curiosity, I tried to load fglrx and it failed to find a valid VBIOS so fglrx must not have the ACPI loading method. blee@supra ~ $ sudo dd if=/dev/mem of=/dev/stdout bs=65536 skip=12 count=1 2>/dev/null | hexdump 0000000 ffff ffff ffff ffff ffff ffff ffff ffff * 0010000 [ 2.589927] [drm] Initialized drm 1.1.0 20060810 [ 2.589966] [drm] radeon defaulting to kernel modesetting. [ 2.589969] [drm] radeon kernel modesetting enabled. [ 2.590189] [drm] initializing kernel modesetting (TURKS 0x1002:0x6741 0x106B :0x00E2). [ 2.590226] [drm] register mmio base: 0xB0800000 [ 2.590229] [drm] register mmio size: 131072 [ 2.590253] ATOM BIOS: Apple [ 2.590264] [drm] GPU not posted. posting now... [ 2.599466] radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003 FFFFFFF (1024M used) [ 2.599472] radeon 0000:01:00.0: GTT: 512M 0x0000000040000000 - 0x000000005FF FFFFF [ 2.604787] [drm] Detected VRAM RAM=1024M, BAR=256M [ 2.604793] [drm] RAM width 128bits DDR [ 2.604843] [TTM] Zone kernel: Available graphics memory: 4042710 kiB [ 2.604846] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 2.604849] [TTM] Initializing pool allocator [ 2.604858] [TTM] Initializing DMA pool allocator [ 2.604893] [drm] radeon: 1024M of VRAM memory ready [ 2.604896] [drm] radeon: 512M of GTT memory ready. [ 2.604917] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 2.604920] [drm] Driver supports precise vblank timestamp query. [ 2.604982] radeon 0000:01:00.0: irq 45 for MSI/MSI-X [ 2.604993] radeon 0000:01:00.0: radeon: using MSI. [ 2.605028] [drm] radeon: irq initialized. [ 2.605033] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 2.605463] [drm] probing gen 2 caps for device 8086:101 = 2/0 [ 2.605470] [drm] PCIE gen 2 link speeds already enabled [ 2.605534] [drm] Loading TURKS Microcode
This does seem to be fixed in 3.8 series kernels. I just tested 3.8-rc6 and booted fine into radeondrmfb. I could get the vgaswitcheroo to move between the integrated and discrete, but I couldn't get the intel console to work (will have to check my config).
This has regressed some time after 3.9-rc2. I haven't tried 3.9-rc3 but it is definitely not working anymore in 3.9-rc4: [ 2.603538] [drm] initializing kernel modesetting (TURKS 0x1002:0x6741 0x106B:0x00E2). [ 2.603568] [drm] register mmio base: 0xB0800000 [ 2.603570] [drm] register mmio size: 131072 [ 2.603605] radeon 0000:01:00.0: Invalid ROM contents [ 2.603641] radeon 0000:01:00.0: Invalid ROM contents [ 2.603646] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM [ 2.603649] radeon 0000:01:00.0: Fatal error during GPU init
Same here Linux 3.9.0-rc4 [ 5.800732] [drm] Initialized drm 1.1.0 20060810 [ 5.835989] [drm] radeon kernel modesetting enabled. [ 5.839889] [drm] initializing kernel modesetting (TURKS 0x1002:0x6741 0x106B:0x00E2). [ 5.840512] [drm] register mmio base: 0xB0800000 [ 5.840520] [drm] register mmio size: 131072 [ 5.840667] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM [ 5.840687] [drm] radeon: finishing device.
I can confirm on my machine (macbookpro8,2) that v3.9-rc4 doesn't work and v3.9-rc3 does work. Looking at the changes in drivers/gpu/drm/radeon between these two versions doesn't reveal anything that stands out as the culprit. Does anyone want to bisect?
This still doesn't work for 3.9-rc5.
Possibly fixed by this patch set: https://patchwork.kernel.org/patch/2344041/
It does look like commit 547b52463 did introduce the problem (tho I didn't finish bisecting). The patch set does fix the issue for me.
Work again on Linux 3.9.0-rc6 without patch.
At this point these are all core kernel changes being discussed and have nothing to do with the radeon driver. Closing.
I tested today and the problem is still present. Which is your .config and how are you loading the kernel? I'm trying to load it using grub2.
The system is a macbookpro 8.2 and it fails to find the bios as reported before. Probably the problem is in the grub configuration or in the kernel, anybody with a working system could point me to and example configuration?
Works for me in 3.9-rc6. As stated above, you cannot use grub to load the firmware as the information is only accessible before you exit the boot services in EFI. The kernel must be booted using EFI stub booting (that's where the code for getting the bios image is). I use rEFInd as this now automaigcally passes the initramfs location to the kernel.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.