Bug 193745 - [Mac/uefi] 10.1-beta1 snapshot boots but has no console
Summary: [Mac/uefi] 10.1-beta1 snapshot boots but has no console
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.2-BETA1
Hardware: amd64 Any
: --- Affects Some People
Assignee: Marcel Moolenaar
URL:
Keywords: uefi, vt
: 199697 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-09-18 12:31 UTC by Dave Cottlehuber
Modified: 2015-08-31 20:06 UTC (History)
14 users (show)

See Also:


Attachments
dmesg_from_imac13-4_20140909_10.1beta1 (56.52 KB, text/plain)
2014-09-18 12:31 UTC, Dave Cottlehuber
no flags Details
dmesg from MacBook Pro 3,1 which exhibits the problem. (9.03 KB, text/plain)
2014-10-01 08:31 UTC, Neal Nelson
no flags Details
screen shot of output of updated uefi boot loader with 10.1b3 (524.52 KB, image/png)
2014-10-03 20:58 UTC, Dave Cottlehuber
no flags Details
Proposed fix and cleanups (1.60 KB, patch)
2015-08-15 06:01 UTC, Marcel Moolenaar
no flags Details | Diff
Proposed fix for large frame buffers. (1.94 KB, patch)
2015-08-17 03:25 UTC, Marcel Moolenaar
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Cottlehuber 2014-09-18 12:31:44 UTC
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.
Comment 1 Dave Cottlehuber 2014-09-18 23:22:05 UTC
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
}

```
Comment 2 Neal Nelson 2014-10-01 08:30:28 UTC
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.
Comment 3 Neal Nelson 2014-10-01 08:31:35 UTC
Created attachment 147874 [details]
dmesg from MacBook Pro 3,1 which exhibits the problem.
Comment 4 Ed Maste freebsd_committer 2014-10-02 21:35:46 UTC
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.
Comment 5 huanghwh 2014-10-03 15:16:19 UTC
I have the same problem on a MacBook Pro 11,3.
run gopmodes:
Mode 0: 2880x1800 @ 0x80020000
Mode 1: 2880x1800 @ 0x80020000
Comment 6 Dave Cottlehuber 2014-10-03 20:58:52 UTC
Created attachment 147944 [details]
screen shot of output of updated uefi boot loader with 10.1b3
Comment 7 Dave Cottlehuber 2014-10-03 21:03:24 UTC
@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)
Comment 8 Ben Woods freebsd_committer 2014-10-14 23:48:48 UTC
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?
Comment 9 John Wolfe 2014-10-16 17:44:43 UTC
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.
Comment 10 Allison Nicole Reid 2014-11-01 02:33:47 UTC
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
Comment 11 Dave Cottlehuber 2015-01-20 16:26:19 UTC
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?
Comment 12 Marcus von Appen freebsd_committer 2015-02-18 11:54:20 UTC
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
Comment 13 hartzell 2015-06-14 17:38:36 UTC
[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.
Comment 14 msh 2015-07-28 14:28:12 UTC
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.
Comment 15 Dave Cottlehuber 2015-08-07 21:03:39 UTC
still present on 10.2-rc1 FWIW.
Comment 16 Ed Maste freebsd_committer 2015-08-11 18:57:37 UTC
If you can, please try the patch in PR 191564
Comment 17 hartzell 2015-08-11 23:58:03 UTC
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.
Comment 18 Ed Maste freebsd_committer 2015-08-12 01:05:33 UTC
(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.
Comment 19 hartzell 2015-08-12 02:40:18 UTC
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.
Comment 20 Marcel Moolenaar freebsd_committer 2015-08-14 04:44:19 UTC
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?
Comment 21 msh 2015-08-14 13:52:59 UTC
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!
Comment 22 Marcel Moolenaar freebsd_committer 2015-08-15 05:56:20 UTC
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.
Comment 23 Marcel Moolenaar freebsd_committer 2015-08-15 06:01:05 UTC
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.
Comment 24 Ed Maste freebsd_committer 2015-08-15 11:37:42 UTC
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.
Comment 25 Dave Cottlehuber 2015-08-15 13:09:54 UTC
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.
Comment 26 Dave Cottlehuber 2015-08-15 13:18:41 UTC
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.
Comment 27 commit-hook freebsd_committer 2015-08-15 16:13:44 UTC
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
Comment 28 hartzell 2015-08-15 16:17:04 UTC
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.
Comment 29 Dave Cottlehuber 2015-08-15 18:32:04 UTC
https://wintermute.skunkwerks.at/freebsd/pr193745/
Comment 30 hartzell 2015-08-15 20:01:53 UTC
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!
Comment 31 Marcel Moolenaar freebsd_committer 2015-08-17 03:20:35 UTC
*** Bug 199697 has been marked as a duplicate of this bug. ***
Comment 32 Marcel Moolenaar freebsd_committer 2015-08-17 03:25:19 UTC
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.
Comment 33 hartzell 2015-08-17 03:36:01 UTC
@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.
Comment 34 Dave Cottlehuber 2015-08-17 10:40:07 UTC
@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?
Comment 35 Ed Maste freebsd_committer 2015-08-17 10:56:37 UTC
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.
Comment 36 Ben Woods freebsd_committer 2015-08-17 12:48:23 UTC
(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
Comment 37 Marcel Moolenaar freebsd_committer 2015-08-17 14:59:08 UTC
(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.
Comment 38 commit-hook freebsd_committer 2015-08-18 00:48:00 UTC
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
Comment 39 commit-hook freebsd_committer 2015-08-18 01:54:12 UTC
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
Comment 40 commit-hook freebsd_committer 2015-08-25 15:15:23 UTC
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
Comment 41 hartzell 2015-08-28 02:38:11 UTC
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.
Comment 42 Marcel Moolenaar freebsd_committer 2015-08-28 02:53:02 UTC
(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.
Comment 43 hartzell 2015-08-29 15:56:18 UTC
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.
Comment 44 Marcel Moolenaar freebsd_committer 2015-08-29 16:57:20 UTC
(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.
Comment 45 msh 2015-08-31 20:01:20 UTC
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
Comment 46 Marcel Moolenaar freebsd_committer 2015-08-31 20:06:16 UTC
(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.