Created attachment 147441 [details] dmesg_from_imac13-4_20140909_10.1beta1 # Objective Boot to FreeBSD and see the console during boot on UEFI-only Apple iMac. # Expected Result beautiful lines of console bliss scroll merrily past until the joyous login prompt appears; all celebrate. # Actual Result loader.efi gets us to: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Start @ 0xffffffff802d89c0 ... And then no further activity (flickering, output, anything) is seen. However the system successfully boots and dmesg is attached. The method of installation was slightly unconventional, using an existing OpenZFS-on-OSX zpool and manually setting up zfs mountpoints before running the normal CD-based installation, using http://ftp.at.freebsd.org/pub/FreeBSD/snapshots/amd64/10.1-PRERELEASE/ from 2014-09-08. # Configs: ## EFI FAT partition - refind 0.8.3 - /EFI/FREEBSD/loader.efi copied from FreeBSD /boot/loader.efi - /EFI/boot copied from FreeBSD /boot (includes kernel modules etc) - loader.conf as follows: ``` kern.geom.label.disk_ident.enable="0" kern.geom.label.gptid.enable="0" kern.vty="vt" zfs_load="YES" vfs.root.mountfrom="zfs:zroot/root" ``` at the console, OK show ... console=efi if that's of use. Setting `kern.vty="vt"` or not makes no difference.
Using this refind.conf, I can now remove the ugly /EFI/FREEBSD/loader.efi wart: ``` ## /efi/refind/refind.conf textmode 2 resolution 2560 1440 dont_scan_dirs /boot dont_scan_files boot1.efi menuentry "FreeBSD via \boot\loader.efi" { icon \EFI\refind\icons\os_freebsd.png loader \boot\loader.efi graphics off options -v } ```
I have the same problem on a MacBook Pro 3,1. It boots happily (although much faster with the refind.conf shown in the previous comment), but there is no further output on the console after: Booting [/boot/kernel/kernel]... Start @ 0xffffffff802d8a40 ... I can ssh in and everything seems to be running happily though.
Created attachment 147874 [details] dmesg from MacBook Pro 3,1 which exhibits the problem.
I put a test version of loader.efi at people.freebsd.org/~emaste/uefi/loader.efi that adds a "gopmodes" command. If someone can run it and run gopmodes from the loader prompt it should confirm or rule out at least one issue.
I have the same problem on a MacBook Pro 11,3. run gopmodes: Mode 0: 2880x1800 @ 0x80020000 Mode 1: 2880x1800 @ 0x80020000
Created attachment 147944 [details] screen shot of output of updated uefi boot loader with 10.1b3
@emaste thanks, this off the UEFI boot disc1.iso from 10.1 b3 now. OK mode Mode 0: 80 columns, 25 rows Mode 1: 80 columns, 50 rows Mode 2: 320 columns, 75 rows choose the mode with "col <mode number>" OK col 2 col not found OK gopmodes Mode 0: 2560x1440 @ 0x90020000 Mode 1: 2560x1440 @ 0x90020000 OK boot -v [37;44mBooting... [0m Start @ 0xffffffff802d8a40 ... EFI framebuffer info: add, size 0x90020000, 0x1680000 dimensions 2560 x 1440 stride 4096 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 [and then nothing more ever until reboot)
I was having this issue when testing the FreeBSD 10.1RC1 uefi memstick installer, and could never get the kernel load messages to appear on my screen (although I believe it was booted in the background as I could hear disk activity and a ctrl+alt+delete successfully rebooted the laptop. Haven't tested with 10.1RC2 yet, but the announcement didn't mention it was fixed. I have a MacBook Pro mid-2010 edition (nvidia graphics). How can I help troubleshoot further? Is there a chance we could get this resolved for 10.1 release?
I am seeing the same stop at the "Start @ 0xffffffff802d89c0 ..." on a Dell T320 when using either the UEFI memstick or DVD (RC1 & RC2)when using the UEFI boot mode. All images boot cleanly, as expected, when using the BIOS boot. Let me know if I can be of any assistance.
I ran the test loader.efi on a 10.1-RC3-uefi-memstick disk on my Macbookpro10,1: gopmodes Mode 0: 2880x1800 @ 0x90020000 Mode 1: 2880x1800 @ 0x90020000 mode Mode 0: 80 columns, 25 rows
Retested with latest FreeBSD-11.0-CURRENT-amd64-20150111-r276981-bootonly.iso, no change. It seems the same system when booted in "MBR" mode (e.g. from PCBSD 10.1 CD or from an external MBR partitioned disk) works, its only the UEFI mode that fails. Anything further we can help with here?
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
[Me Too.](https://lists.freebsd.org/pipermail/freebsd-questions/2015-June/266281.html) I'm seeing the problem on a 2008 Mac Pro. Runs 10.1 fine from a DVD, but does not have a console with the EFI version of the DVD, memstick, or an EFI hard drive. Let me know if there's anything I can gi into that might help make it work. g.
I have the same issue on a 2015 27" iMac. 10.1 boots fine from DVD media, but after completing installation, screen freezes during boot at "Start @ 0xffffffff802d89c0 ...". Like others, I can ssh in. If I can do anything to help out, please let me know.
still present on 10.2-rc1 FWIW.
If you can, please try the patch in PR 191564
That image does not change the behavior described here. It boots up through Start @ 0xffffffff802fa000 and/but there is not further activity on the screen. The thumbdrive activities light blinks, and I suspect that the system is alive, but I have no way to confirm it. Thanks for working on this.
(In reply to hartzell from comment #17) Thanks. brd's reply in PR 191564 confirms that his Macbook Pro (other than having no console) boots successfully with the patch -- it at least does not introduce a regression. We'll need further changes for certain Macs still it seems.
I believe that mine has been booting successfully the entire time, except for the lack of a console. I haven't figured out how to tell for sure though. I can watch the usb stick flash as if it's booting even after the screen stops updating, and when I hit the power button it goes through what seems like an ACPI shutdown (albeit w/out any console chatter). I'll try to grab a moment and try the stock image again to be sure.
I can reproduce this on a Macmini4,1. From the looks of it, the graphics H/W is in text mode and not in graphics mode. This makes sense, because the Mac firmware switches to text mode when running the FreeBSD loader. Calling gop->SetMode() doesn't seem to switch the H/W to graphics mode. Maybe we need to disable text mode? Maybe remove the TextOutput handler?
I tried the patch in patch in PR 191564 (I dd'ed Ed's image to a USB stick). I have the exact same symptoms as before. Console freezes in the same spot: "Start @ 0xffffffff802d89c0 ..." This is on a 2015 27" iMac. If I have some time later today I'll give it another go. We have some 24" iMacs here in the office that I can test on. Thanks for all the hard work. All the best!
The problem is this: Precondition: Certain Macs have a frame buffer of a particular resolution with a stride that is larger than the horizontal resolution. Mine is: dimensions 1280 x 1024 stride 2048 Dave's GOP info is: dimensions 2560 x 1440 stride 4096 The bug: The EFI frame buffer driver determines the number of bits per pixel as stride * bytes-per-pixel / width * 8 (where width is the horizontal resolution). On my Mac this results in (2048 * 4) / 1280 * 8 = 6 * 8 = 48. That is 6 bytes per pixel. Bogus. The kernel doesn't know what to do with 6 bytes per pixel. It doesn't determine the color map and it doesn't even write anything to the frame buffer. Only 1-4 bytes pixel is supported. The computation of BPP is simply wrong. It's the same as the depth that we get from the loader, which gets it from UEFI. The depth is 32 or 4 bytes per pixel.
Created attachment 159892 [details] Proposed fix and cleanups The attached patch makes the EFI console work on my Mac mini. I appreciate if someone who reported a problem can apply this to a CURRENT sandbox, build a kernel and let me know if it fixes the problem for him/her as well.
The change looks good. It looks like we should subsequently do a sweep through vt to clean up fb_bpp vs fb_depth, which are indeed redundant.
No luck on 27" iMac here. Not sure if my build steps were correct though: https://gist.github.com/dch/9389537e4cadad247419 and after git clone -b master --single-branch --depth 1 \ git://github.com/freebsd/freebsd.git /usr/src doing curl https://bz-attachments.freebsd.org/attachment.cgi\?id\=159892 | patch -p0 following on with the rest to make a memstick.
No luck on a 15" MBP 2014 Retina model either. Last info on screen is as follows: addr 0x90000000, 0x1437000 dim 2880x1800 stride 2944 masks 0x00ff0000 0x0000ff00 0x000000ff 0xff000000 I *can* see the build date is root@ ... Aug 15 so I've done something right. I'll rebuild CURRENT + the patch again later this evening just in case.
A commit references this bug: Author: marcel Date: Sat Aug 15 16:13:29 UTC 2015 New revision: 286809 URL: https://svnweb.freebsd.org/changeset/base/286809 Log: Improve support for Macs that have a stride not equal to the horizonal resolution (width). In those cases fb_bpp ended up completely wrong -- as in 6 bytes per pixel or something like that. Since we already have a way to calculate fb_depth given the masks and fb_bpp is effectively the same as fb_depth, all we need to do is make sure fb_bpp is rounded to the next multiple of the number of bits in a byte -- we assume we can divide by the number of bits in a byte throughout vt(4). While here: - simplify how we calculate fb_depth. - use fb_bpp instead of fb_depth to calculate fb_stride; we know we can divide fb_bpp. - don't limit fb_width and fb_height by VT_FB_DEFAULT_WIDTH and VT_FB_DEFAULT_HEIGHT (resp.). Those constants have not relation to the size of the frame buffer. This at least fixes "lower-resolution" Macs. We're talking 1280x1024 or so. There still is a problem with 27" Macs, which typically have a horizontal resolution over 2K. PR: 193745 (partial) Ok'd by: emaste@ Changes: head/sys/dev/vt/hw/efifb/efifb.c
Hi All, I'm not in a position to build right now, but if someone can make a thumb drive image available, I can test it on my Mac Pro. Thanks for digging into this.
https://wintermute.skunkwerks.at/freebsd/pr193745/
I do not see any improvement. As before, the last thing written to the console is Start @ 0xffffffff802fa000 The machine seems to be alive, responds to a quick press of the power button by shutting down. This is a 2008-ish mac pro tower attached to a 30" Dell monitor. Thanks!
*** Bug 199697 has been marked as a duplicate of this bug. ***
Created attachment 159937 [details] Proposed fix for large frame buffers. The change to pmap.c increased the number of page table pages set aside during boot. This is needed to make it possible to map a large frame buffer into the kernel's address space. The change to vt.h and vt_fb.c deal with the fact that the console code has a fixed buffer for its history and a frame buffer that is larger than that buffer will cause all kinds of memory corruption. We cap the side of the display. We center the output on the frame buffer by calculating an offset by which to transpose the output.
@dave, I can't build this, but if you can make an image available let me know and I'll take it for a spin.
@hartzell https://wintermute.skunkwerks.at/freebsd/pr193745/ @marcel success! we get all the way through to installer now https://pbs.twimg.com/media/CMmrxSuWIAAylS7.jpg on MBP 15" 2014 retina. note that the screen size is maybe 2/3 of actual size. Can I get any more info to help here?
Great to hear that it's working! (In reply to Dave Cottlehuber from comment #34) > note that the screen size is maybe 2/3 of actual size. Can I get any more info > to help here? Right now this is expected - per Marcel's comment #32 > The change to vt.h and vt_fb.c deal with the fact that the console code has a > fixed buffer for its history and a frame buffer that is larger than that buffer > will cause all kinds of memory corruption. We cap the [size] of the display. We > center the output on the frame buffer by calculating an offset by which to > transpose the output. Other changes will need to be made in vt(4) to properly support this. I suspect that a 360 column display (2880 / 8) isn't really what we want, and that we need to provide a bigger font for high DPI displays.
(In reply to commit-hook from comment #27) > A commit references this bug: > > Author: marcel > Date: Sat Aug 15 16:13:29 UTC 2015 > New revision: 286809 > URL: https://svnweb.freebsd.org/changeset/base/286809 I can confirm this commit has fixed UEFI boot on my MacBook Pro mid-2010 edition (nvidia graphics). Thank you everyone for your work! http://woods.am/MacBook-vt4-1.jpg http://woods.am/MacBook-vt4-2.jpg http://woods.am/MacBook-vt4-3.jpg
(In reply to Ed Maste from comment #35) Yeah, retina displays definitely warrant a bigger font and it's probably ok to assume that every large frame buffer is helped with a bigger font. I don't expect people to sit right in front of a 4K TV, so a bigger font would make text readable across the room... With UEFI, the loader is in the unique position to know the resolution before booting the kernel. It would be great if the loader would pre-load a bigger font (depending on resolution) and have vt(4) look for fonts in the list of preloaded objects.
A commit references this bug: Author: marcel Date: Tue Aug 18 00:47:03 UTC 2015 New revision: 286867 URL: https://svnweb.freebsd.org/changeset/base/286867 Log: Support frame buffers that are larger than the default screen size as defined by VT_FB_DEFAULT_WIDTH and VT_FB_DEFAULT_HEIGHT (at this time 2048x1200). The default is really a max. We cap the height and width to those defaults and position the screen in the center of the frame buffer. Ideally we use a bigger font to utility the entire real estate that is the frame buffer, but that's seen as an improvement over making it work first. PR: 193745 Changes: head/sys/dev/vt/hw/fb/vt_fb.c head/sys/dev/vt/vt.h
A commit references this bug: Author: marcel Date: Tue Aug 18 01:53:42 UTC 2015 New revision: 286868 URL: https://svnweb.freebsd.org/changeset/base/286868 Log: Add 24 more page table pages we allocate on boot-up. 16MB slop is a little tight in and by itself, but severily insufficient when one needs to map a large frame buffer as part of console initialization. 64MB slop should be enough for a while. As an example: a 15" MacBook Pro with retina display needs ~28MB of KVA for the frame buffer. PR: 193745 Changes: head/sys/amd64/amd64/pmap.c
A commit references this bug: Author: marcel Date: Tue Aug 25 15:14:52 UTC 2015 New revision: 287128 URL: https://svnweb.freebsd.org/changeset/base/287128 Log: MFC r286808, r286809, r286867, r286868 - Improve support for Macs that have a stride not equal to the horizonal resolution (width). - Support frame buffers that are larger than the default screen size. - Support large frame buffers: add 24 more page table pages we allocate on boot-up. PR: 193745 Changes: _U stable/10/ stable/10/sys/amd64/amd64/pmap.c stable/10/sys/dev/vt/hw/efifb/efifb.c stable/10/sys/dev/vt/hw/fb/vt_fb.c stable/10/sys/dev/vt/vt.h stable/10/sys/dev/vt/vt_core.c
I'm not sure if this should have been closed, the changes did not fix my mid-2008 Mac Pro. Or, perhaps I should open a new bug. I updated my svn repo, built and installed everything, and then cd /usr/src/release/ make -DNOPORTS -DNODOC uefi-memstick dd if=uefi-memstick.img of=/dev/da0 bs=1m The memstick booted and presented me with a small terminal window centered in my large monitor, so I believe that I built everything correctly and that I am testing these changes. As before, I end up stuck at Booting... Start @ 0xffffffff802dfd10 Thanks for all the help.
(In reply to hartzell from comment #41) Given that you got a terminal centered on your monitor while booting an UEFI based memstick, I think your problem isn't the EFI console -- well, not anymore I guess. Please file a different PR and provide as much detail as you can. Like the installation settings and choices. We need to reproduce it before we can fix it.
I created a new bug for my ongoing issue, Bug 202730. It looks like I managed to create it twice, 202731 seems to be an exact duplicate. Thanks for any help.
(In reply to hartzell from comment #43) :) I did the same just recently. It's a bug in Bugzilla to not have a button that shows that it has been pressed.
Hi all, Thanks to everyone for the hard work! I just did some tests with the image from comment #34. On a 2015 21.5" iMac, everything boots perfectly. On my 2015 27", I still get the same symptoms as originally described in the bug report. I'm guessing that the 27" just has some crazy stride? Let me know if there is anything I can do. -msh
(In reply to msh from comment #45) Please check out 202730. On a 2008 Mac Pro the EFI firmware doesn't implement the graphics output protocol and there's no console. If you have no console output at all, that bug may be more relevant to you. If you want to help test that problem (i.e. bug 202730), download the attached loader from that bug and run the gop command. If the gop command returns an error, then that's your problem. Run the uga command to make sure the firmware support UGA instead of GOP. If the uga command has no errors, check that the stride is ok and try to boot.