Skip to main content
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [SOLVED] 32bit Mac EFI doesn't expose vbios in UEFI mode (Read 600 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[SOLVED] 32bit Mac EFI doesn't expose vbios in UEFI mode

I successfully installed artix with the runit basestrap iso to the hdd of my old macbook pro 2,1 (late 2006). This model includes a ATI Mobility Radeon X1600 GPU.
Before artix I had manjaro installed to this machine with a CD using BIOS boot (these models still use 32bit EFI firmware but can boot BIOS to dual boot windows). Manjaro apparently used systemd + grub which happened to work.

The new configuration was installed using "grub-install --target=i386-efi --removable..." to boot runit artix in true UEFI mode on an old macbook pro. Issues arise with the GPU on boot time. I have mesa, vesa and xf86-video-ati installed but can only boot into console with kernel parameter nomodeset active. Apparently this can not provide any graphical interface since it forces UMS and the open source driver doesn't support it anymore.
When I remove nomodeset from grub runit will plain freeze after
Code: [Select]
:: Waiting for udev uevents to be processed [Busy]
With a verbose output I can see that the failing line is the error message of the driver:
Code: [Select]
[drm:radeon_init] *ERROR* No UMS support in radeon module!
This error will also print with nomodeset but that way it will at least boot to the console to be able to make changes to the system. This is problematic since I cannot use any graphical interface with nomodeset (Xinit bails out on "Fatal server error: no screens found") but without it runit will get stuck on the very same error message.

There are pretty old bug reports in the redhat tracker about this behaviour but no solutions found anywhere.
Is there anything I can do about this? Can I tell runit to ignore this? Would that help in any way? Is it maybe not runit itself but something else? See below.

Re: runit cannot boot old radeon X1600 without nomodeset

Reply #1
I don't think this has anything to do with runit. Your card is old, but it should be supported by xf86-video-ati which does support KMS. I don't know if you've tried these kernel parameters in the Arch wiki. It namedrops the exactly same GPU, so I figure it's worth trying.

Intel Kernel Parameters

Reply #2
The mentioned parameters didn't have any effect at all. The real issue here, after a lot of reading is this (adjusted the title to reflect it):

I found quite some people on different sites having issues with this for over a decade. Apparently the Macintosh EFI is a real headache not exposing the video bios in UEFI mode but very well does so in hybrid BIOS mode (that's why my manjaro install from CD worked, it installed in BIOS boot mode). The best hints on the topic I could found are mentioned in this bug report on the Freedesktop Tracker but they are now already eight years old and I guess nobody knows wether there have been any improvements on this (feels like there's not been any). The very first post explains it clearly:
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.
I am reading into rEFInd and trying it out in hope it's maybe capable to read the vbios and pass it on or something like that (the latest comment mentions this)...In the bug report some people even did hacks and patches for their firmwares...That goes pretty far even for a hobbyist...The latest comment also says it's only possible to get around by booting the kernel using EFISTUB:
The kernel must be booted using EFI stub booting (that's where the code for getting the bios image is).

How would I go about the latter? Or does anybody have experience with rEFInd regarding this kind of trickery? The apple firmware searches for any BOOTIA32.EFI file on any partition and uses that to boot the system. This is the trick to get grub, refind or any other boot loader to boot from EFI directly on these machines. But the real issue is with the video bios. I am reading the arch wiki on EFISTUB but it's really quite abstract.

Some say to dump the vbios and have grub load it manually, some say it's too much workaround and rEFInd can load with EFISTUB. Pfffft....

Re: 32bit Mac EFI doesn't expose vbios in UEFI mode

Reply #3
Do you still have manjaro installed?
What firmware was manjaro using to boot?  Whatever it is it came from Arch, I don't think they make anything of their own, they repackage Arch pkgs.  I don't think it has anything to do with the init system, so if Manjaro boots Artix will too.
What if you were to give the linux boot line a lower resolution through the vga commanf (vga=0x024c.. or whatever)?
Do you have a copy of the Manjaro grub menu entry?  Try to alter it to fit the artix uuid hd0msdos12 .. partition etc.

Just taking wild shots that you may find helpful

Re: Manjaro, Arch and video modes

Reply #4
The problem in the end is solely with the vbios not being exposed in EFI mode.
Do you still have manjaro installed?
What firmware was manjaro using to boot?
Macintosh hybrid BIOS, originally used for booting Windows with Bootcamp. (This mode extracts vbios for Windows to work)
What if you were to give the linux boot line a lower resolution through the vga commanf (vga=0x024c.. or whatever)?
It's useless to set any kernel parameters others than nomodeset (which disables KMS completely) since KMS can not get any video resolution information from the Macintosh EFI. (I've already tried a ton.)
Code: [Select]
grub> videoinfo
List of supported video modes:
Legend: mask/position=red/green/blue/reserved
So when booting (any really) Linux in EFI mode I can either:
  • boot with nomodeset to disable KMS and get to a console even without video information
  • boot without kernel parameters and have the radeon driver fail on KMS because there's no video information

It seems the only way to make EFI boot work on these 32bit EFI Macbooks is with EFISTUB. Thank you for your thoughts anyways. I appreciate any interest in the issue!

Re: 32bit Mac EFI doesn't expose vbios in UEFI mode

Reply #5
Could any of this be of any help then?

Code: [Select]
1 aur/beefi 0.2-1 (0) (0.00)
    a bootable EFISTUB kernel image creator (for UEFI systems)
2 aur/beefi-git r11.cb62a98-1 (1) (0.00)
    a bootable EFISTUB kernel image creator (for UEFI systems)
3 aur/efistub-git r18.4c8bc0c-1 (1) (0.00)
    Manage UEFI only (secure) boot configurations for Linux EFISTUB kernels

Re: 32bit Mac EFI doesn't expose vbios in UEFI mode

Reply #6
This use case is heavy...and there's actually many people searching for this.

The mentioned bug reports talk about EFISTUB but reading more and more I am about to compile a custom Kernel and this catches my eye:
Code: [Select]
Processor type and features
    [*] EFI runtime support
        [*] EFI stub support
            [*] EFI mixed-mode support


Enabling this feature allows a 64-bit kernel to be booted
on a 32-bit firmware, provided that your CPU supports 64-bit

Note that it is not possible to boot a mixed-mode enabled
kernel via the EFI boot stub - a bootloader that supports
the EFI handover protocol must be used.

So this actually says it's virtually impossible to do what I said earlier. I can absolutely not boot the kernel with EFI stub only...
I'll apply these two patches to my custom kernel and see what happens with a dumped vbios and a corresponding boot loader.

EDIT: SUCCESS (June 25, 2018):

Got a full functioning cross architecture EFI booting Artix Linux with latest runit and Plasma smooth as shit on my 2,16GHz Intel Duo Core MacBook Pro from late 2006!
I am amazed to say the least!
This poor guy has only 2GB RAM and Plasma (5.13 [had performance improvements]) is completely responsive and usable. Apparently one can not expect the same responsiveness of Puppy or such but even with a ton of transparencies and animations (which are optional) this is working without flaws. CPU get's pretty hot eventually which it does with any DE really. I copied about 8GB from a USB and CPU heated up to about 72°C.
Keyboard backlight works out of the box even with buttons, as does screen and audio buttons. Monitor backlight adjust does not work yet. iSight firmware might be necessary, runit bailed on me with this one, but it was before getting the vbios right.

What I did:
Downloaded the official mainline kernel source (could be stable, or -ck or anything that's known to work decently) and customized quite some options with "make xconfig", being the most important ones any apple device support that can be turned on (although not being the crucial part any of this.) After setting up the .config I applied the aforementioned load_bios_from_firmware patch and compiled (this is the important one). I compiled on my desktop arch system, so I had to take care of all the modules. I found this short guide on compiling for different hosts to be pretty helpful. In the end I did not apply the other patch mentioned, it is very old and some of the tweaked source files don't even exist anymore. Lastly dumped the video bios of the MacBook with a Puppy Live CD (could be any other BIOS booted live CD) and put the files in the right place.
Personally I chose to pull the drive out of the MacBook. This allowed me to connect it to my desktop and just do a normal UEFI Live USB chroot basestrap, put the vbios files and just about anything else into place and then put it back and play around with the kernel images.

If anyone has further questions on this don't hesitate to ask. Only read the mentioned links (at minimum least the last one) before asking though.

Here is some eye candy with my SDDM Chili for Plasma theme, Flat OSX Window Decorations and NixOS folder icons.
(Is some open source advertising allowed?)

To Do:
Try the same with the 4.17 linux-ck kernel when it is released these days.

Re: [SOLVED] 32bit Mac EFI doesn't expose vbios in UEFI mode

Reply #7
Some great skill is shown here! Congrats and thanks for the detailed sharing.