Date: Fri, 26 Oct 2012 18:07:08 -0700 From: matt <sendtomatt@gmail.com> To: Justin Hibbits <chmeeedalf@gmail.com> Cc: freebsd-ppc@freebsd.org Subject: Re: Does drm/dri currently work on PPC? (SUCCESS!) Message-ID: <508B33BC.1090107@gmail.com> In-Reply-To: <CAHSQbTCdFy19Dt8nWQ%2Bi8BjyTCEAcPjL4CM2da7VA5okLH53Qg@mail.gmail.com> References: <5083C719.1040109@gmail.com> <CAKLtBChswXj7HcZeC=SaJgMNDrZXu==DHFP5PW4wB9=ruKSWWA@mail.gmail.com> <20121021092136.20307802@narn.knownspace> <50846392.70007@gmail.com> <CAHSQbTC7SA8qiVGQi%2BfmsmzYBVQLR09Dmzhjk1Ev=srsufc_HQ@mail.gmail.com> <5085F595.4050609@gmail.com> <20121022215945.436873dc@narn.knownspace> <5089A6DB.9070904@brakiri.com> <5089DF27.9020803@gmail.com> <20121025213018.2bfa5068@narn.knownspace> <5089F799.9030507@gmail.com> <508A17C9.4030007@gmail.com> <CAHSQbTCdFy19Dt8nWQ%2Bi8BjyTCEAcPjL4CM2da7VA5okLH53Qg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/26/12 05:15, Justin Hibbits wrote: > On Fri, Oct 26, 2012 at 12:55 AM, matt <sendtomatt@gmail.com > <mailto:sendtomatt@gmail.com>> wrote: > > > > It was working without DRM "out-of-the-box". Of course I've made > a mess > > trying different versions of both Xorg and the radeon driver. > I'm in the > > process of getting back to the working config so I can be sure > any test > > changes work/don't work. > > > > OpenBSD's mpi@ apparently did a lot recently over there getting > DRM to > > work on the G4 mini. We already had about half of the commits I > see at > > freshbsd, in one way or another...Our rmb/wmb() I think has had PPC > > barriers since earlier this year? He did #define __BIG_ENDIAN, which > > apparently was a big deal for the drm code (it's ifdef'd in a couple > > places), not sure if we are already doing that. > > If someone has a G4 radeon mini they could test to see if drm > works for > > them or not, to rule out AGP issues (I guess they are PCI?). > > > > I'm not sure how the OpenBSD attachment process works vs ours, > some of > > the other commits of note were related to passing the BAR and memory > > regions from the vgapci to drm. When I kldload drm after > compiling it, > > it doesn't do anything...but if I kldload radeon.ko, it > recognizes agp > > memory and being related to vgapci at the correct pci > address...I'm not > > sure if we "are there" or not. I also didn't have DRM on OpenBSD > either. > > > > I think if radeon had drm on *any* big-endian platform it should > rule > > out endian issues in drm or radeon. Not sure if this is the case, I > > guess macppc would be the most likely. > > > > Matt > So I removed WITH_NEW_XORG, deinstalled a ton of ports, and > reinstalled > Xorg. I rebuild drm with __BIG_ENDIAN defined (not sure if this > matters). I previously put a lot of WERROR= and NO_WERROR= into > various > drm makefiles to get gcc to shut up about unused return values. X > -configure worked, and the xorg log indicates the drm device was > successfully opened and I have drm on PPC. > mesa-demos is marked broken for PPC, haven't tried glxinfo or > glxgears yet. > > The good news is it works! > The bad news: > -Cannot switch back to syscons, screen gets corrupted then the system > hard locks > -WITH_NEW_XORG breaks it somehow > > Thanks to mpi@openbsd.org <mailto:mpi@openbsd.org>, Justin & Nathan! > > Matt > > > That's fantastic! If I'm able to get my current project done (PMU > sleep/speed change on PowerBook) I'll definitely give that a shot this > weekend. > > One thing that may help with switching back to syscons is, NetBSD has > a radeonfb driver for console framebuffer.Earlier in the week I > briefly looked at that, and it may not be too difficult to port it to > FreeBSD and integrate with syscons. Only major hurdle for that would > be dealing with ofwfb as well. Just some more tinkering :) > > Excellent news! > > - Justin Be aware that radeonfb has had issues before, I think it's what was making the console unusable on my NetBSD-current attempt. NetBSD's radeonfb maintainer turned it off for the release of 6.0, I think. Might be better now. Switching consoles or killing X (such as reboot or shutdown) definitely crashes the system at least 75% of the time (small dataset). It rebooted once after being told to reboot from X, but it may have just panic'd and rebooted itself. I haven't attached gdb to X yet over ssh while it happens, so I'm not sure if X is crashing or syscons/ofwfb is corrupting memory trying to take over or both. Good luck with those PMUs. Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?508B33BC.1090107>