Date: Fri, 31 Oct 2014 10:51:22 +1030 From: William <william@firstyear.id.au> To: Ed Maste <emaste@freebsd.org> Cc: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Loader vs loader efi ficl incompatibility Message-ID: <1414714882.16625.43.camel@ammy.its.adelaide.edu.au> In-Reply-To: <CAPyFy2CrDr=a8_O93TBNFE5HJYJDXE6tuihvJQ9gjDydXbywkQ@mail.gmail.com> References: <1414622725.16625.22.camel@ammy.its.adelaide.edu.au> <CAPyFy2CrDr=a8_O93TBNFE5HJYJDXE6tuihvJQ9gjDydXbywkQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2014-10-30 at 10:59 -0400, Ed Maste wrote: > On 29 October 2014 18:45, William <william@firstyear.id.au> wrote: > > Hi, > > > > To get my laptop working (Macbook pro) with freebsd, at boot you need to > > outb to some memory locations before boot so that graphics works. > > Do you happen to have a good reference for the io ports you mention? I > see them described on a number of Linux forums, but a canonical source > would be nice. So, I should explain. In the MacBookPro 15" 8,2, it has two graphics cards. The i915 intel and a radeon 6770. These are connected to a multiplexer (gmux) and that is connected to the laptop panel via LVDS. When the system boots, the ati card is selected on the gmux, and both powered on. I wish to preboot change to the i915 then boot the system. The reason for doing this preboot is that efifb doesn't support re-probing the display after a switch. As I say this, I mean that FreeBSD doesn't currently appear to support gmux switching, I wrote my own kernel module to do this, so it's very rough and doesn't interact with efifb at all. The obvious reason for the gpu swap and power down of the inactive card is battery and heat. The radeon idle runs at 60+ degrees, and halves the battery. There is no canonical source that I know of, merely reverse engineering. If you want the details of the specific addresses I can provide these, as each one of those 4 has a unique function in the gmux. > > > Are there differences in the ficl interpreter between loader and > > loader.efi? Is this perhaps a bug? > > The loader only includes inb and outb for i386 (the non-UEFI loader is > 32-bit for both i386 and amd64): > > #ifdef __i386__ > dictAppendWord(dp, "outb", ficlOutb, FW_DEFAULT); > dictAppendWord(dp, "inb", ficlInb, FW_DEFAULT); > #endif > > We'd need to make these available in the 64-bit loader.efi, although Removing the ifdef would be enough to make this work for my own personal use? Or would there be unintended consequences. > I'd really like to have MBP support be handled automatically in the > loader itself. > _______________________________________________ Each Mac revision slightly tweaks the gmux, which makes it harder to support. IIRC the linux kernel apple-gmux implementation has this working. The correct way to do this really would be early in loader before the display is setup, change to the intel, and reinit the framebuffer. This relies on Mac hardware detection, the programmatic gmux base address detection, and loader being able to completely reinit the frame buffer in efi. Alternately, you do it just after loader, but just before the freebsd kernel runs so that you don't worry about the screen going black before the efifb gets reinitialised. Then freebsd itself needs a graphics swapping kernel module. You need to be able to carry out a swap, do an LVDS reprobe, and redraw the fb / display. radeon supports this, i915 does not (It's been broken in linux for years and no developers are willing to look at it). For tty with KMS/DRM which does not use these drivers, you likely could just do some handling in efifb. All in all, it would be far more than just a quick "loader" fix imo, and for my specific use case I just need the intel gpu working. I'm quite happy to just drop the outb commands into boot.4th. I'd love to see the fix be done "properly" for all, but I don't have the knowledge to do it, the time etc. I'd be happy some of the work into the loader components for this, but I don't know enough about KMS/DRM to fix those components. Finally, I want to ask if hardware-specific detection should go into loader? I'm not 100% familiar with this architecture and if this very targeted hardware manipulation should go in it. -- William <william@firstyear.id.au>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1414714882.16625.43.camel>