Haiku on x86 macbooks

Development OS
13

FWIW, I’ve just installed Haiku Beta 4 on MacBook Pro 2015 (Model ID: MacBookPro11,5).

I had to use the rEFInd boot manager, and the “Use fail-safe video mode” boot option to be able to launch from the USB installation stick (it was also quite tricky to enter the boot options, I had to quickly press “Space” key several times right after I select Haiku USB in the rEFInd). For whatever reason after the first successful USB boot the UI was in Spanish, so I needed to blindly change the language settings (luckily the globe icon helped to find the right item).

I reformatted the 16 GB FAT32 partition to BeFS via DriveSetup, but for whatever reason it refused to change the partition type from Microsoft basic data partition to Haiku BFS, and I had to do it manually by rebooting into the Mac Recovery Mode deleting the GPT entry and readding it with the correct partition GUID (42465331-3BA3-10F1-802A-4861696B7521).

The Installer doesn’t add the haiku_loader.efi to the ESP (EFI system partition), so one has to copy it manually from the USB stick following the UEFI Booting Haiku instructions. I’m not sure why Installer still doesn’t handle such a simple operation by itself. There’s a 5-years old Trac issue #14967 which aims to handle all of UEFI installation corner cases, but IMHO most of the users would be happy with just the MVP solution suggested by @kallisti5 in one of the comments (as an engineer who embraces pragmatism I can’t agree more with his last sentence there: “You don’t eat an elephant all at once. It’s one bite at a time”).

Nevertheless, after a few hours of trial and error I now have Haiku running natively on a MacBook. Isn’t that awesome? :slight_smile:

1 Like
14

One can find a detailed info about nearly every Mac model at:

1 Like
15

Did you make fail-safe video permanent?

Idk if this is where you choose fail-safe resolution. It’s been a while since I did it in Haiku.

“You can configure Haiku to always boot using the fail-safe video driver by enabling ‘fail_safe_video_mode’ in ~/config/settings/kernel/drivers/kernel”

Oops

16

First I chose it in the Haiku Boot options (by hitting the Space key several times before the loading logo appeared), and then I made it permanent by enabling the fail_safe_video_mode in the file you mentioned.

1 Like
17

Have you used any special options in rEFInd?

I’m trying to boot haiku on the Macmini7,1. However it hangs on the first icon of the loader, not even on-screen output when enabled (however, i can get some when disableing some options like acpi, will try to figure out which exactly)

1 Like
18

Nope, it just works in the EFI mode (and doesn’t work in the CSM/Legacy-mode no matter what I tried).

Btw, here someone mentions to successfully install Haiku on Macmini7,1:


@nephele One more thing I forgot to mention, I use the x64 build.

1 Like
19

I observe the same behavior if I try to load Haiku in VMware with EFI enabled. It boots if I select “Disable local APIC” safe option (which also disables SMP and leaves Haiku with just one CPU core). Interestingly enough, VirtualBox EFI mode boots Haiku without issues (though there’s a visible delay before the first boot icon highlights). Maybe debugging it in VMware (via its gdb stub) would help to fix the issue you have on Macmini7,1.

Also, TIL I wasn’t able to boot Haiku in the CSM (Legacy) mode because MacBookPro11,4 firmware lacks the CSM support (provided in previous versions by the 2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7 UEFI app aka AppleLegacyLoad). Your Macmini7,1 has it, so it should be capable of loading Haiku both with EFI and CSM.

One disadvantage of the EFI boot with Haiku is that the resolution is fixed to just one (2880x1800x32) and there’s no way to change it. It would be nice if Haiku contained a way to specify a custom resolution using a modeline string.

20

Sadly, because of the way EFI works it is not possible to change the efi framebuffer resolution after booting.

Is the resolution you want available in the efi loader menu?

Anyhow the same issue reproducing in vmware is good news, it should make it easier to investigate.

1 Like
21

Run Haiku on VMware as if it were a Mac:

https://shank-s.medium.com/creating-almost-perfect-hackintosh-vm-17126f5328b8

Also run with Qemu prepared with OpenCore:

22

Nope. The only resolution available on my MBP is 2880x1800. I tried to select a different one for rEFInd boot menu, and the rEFInd complained that 2880x1800 is the only one available. I can live with that most of the time, just by doubling the font sizes up to 24. Unfortunately, some UI elements don’t respect font size multiplier and looks really tiny.

23

That’s an interesting info for sure but I’m a bit puzzled what I should do with it. I’m already running Haiku in VMware Fusion so I can select macOS as a guest operating system.

24

Ah, so it is the native panel resolution?

Well, ideally haiku should support running with that nicely. UI elements not scaling properly is a bug, and can be fixed.

1 Like
25

You are using VMware Fusion, you already have a test version. The links show how it works and the software used, which can facilitate the understanding process.

1 Like
26

Yes, it’s the native panel resolution. Once I have time for it I’ll get the screenshots of all non-scaled elements and file a ticket.

Btw, in the Beta 4 release notes I’ve just seen this:

Additionally, on first boot Haiku now attempts to automatically detect if you are on a HiDPI display and set appropriate sizes.

IIRC that didn’t happen on my machine. What’s the algorithm there?

27 
if (mode.virtual_width > 3840 && mode.virtual_height > 2160)
	fontSize *= 2.0f;
else if (mode.virtual_width > 1920 && mode.virtual_height > 1080)
	fontSize *= 1.5f;
28

I was thinking if we can update it to actually do 2x already starting from 2880x1800, wdyt? At 1.5x fonts look too small.
A better algorithm would be to take PPI into account, but I don’t think we read physical screen sizes from EDID at the moment.

29

I wonder if the edid data on macbooks is accurate. Considering it is for the language code of usb mac keyboards it could be?

for those where the data is accurate we can probably have a “smarter” algorithm to determine what physical size looks good for a laptop vs a desktop. and pick a nice middle ground.

But for the pixel size itself, i don’t have a strong opinion on when which font size should start. It’s just heuristics anyway and bound to be wrong.

maybe @waddlesplash has a comment too. IIRC he added that code in the first place.

1 Like
30

I think it is. EDID data can be read using Lunar CLI app.
UPD: we need just the edid-decode tool (the binary can be found in the Lunar dmg):

$ for theedid in $(ioreg -lw0 -r -c "IODisplayConnect" -d 2 | grep IODisplayEDID | sed -E "/^.*<(.*)>/s//\1/"); do edid-decode <<< $theedid; done

edid-decode (hex):

00 ff ff ff ff ff ff 00 06 10 2f a0 00 00 00 00
04 19 01 04 a5 21 15 78 02 6f b1 a7 55 4c 9e 25
0c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 ef 83 40 a0 b0 08 34 70 30 20
36 00 4b cf 10 00 00 1a 00 00 00 fc 00 43 6f 6c
6f 72 20 4c 43 44 0a 20 20 20 00 00 00 10 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cf

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.4
  Vendor & Product Identification:
    Manufacturer: APP
    Model: 41007
    Made in: week 4 of 2015
  Basic Display Parameters & Features:
    Digital display
    Bits per primary color channel: 8
    DisplayPort interface
    Maximum image size: 33 cm x 21 cm
    Gamma: 2.20
    Supported color formats: RGB 4:4:4
    First detailed timing includes the native pixel format and preferred refresh rate
  Color Characteristics:
    Red  : 0.6533, 0.3339
    Green: 0.2998, 0.6201
    Blue : 0.1464, 0.0498
    White: 0.3125, 0.3291
  Established Timings I & II: none
  Standard Timings: none
  Detailed Timing Descriptors:
    DTD 1:  2880x1800   59.990267 Hz   8:5    111.102 kHz    337.750000 MHz (331 mm x 207 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol P
                 Vfront    3 Vsync   6 Vback   43 Vpol N
    Display Product Name: 'Color LCD'
    Dummy Descriptor:
    Dummy Descriptor:
Checksum: 0xcf

And the screen is exactly 33 cm x 21 cm.

31

FWIW, I had the following SO post bookmarked for some time, it describes in details various ways of reading EDID via either UEFI or ACPI:

And in the comment there’s a link to a working UEFI example. It might be helpful as a reference implementation.

32

We already support gettint EDID info from UEFI since hrev57079 (so, in nightlies, but not in beta 4).

Does it not work?

1 Like