On Wed, Jul 02, 2014 at 01:30:46PM -0700, Nathan Whitehorn wrote: > > On 07/02/14 13:28, Marius Strobl wrote: > > On Wed, Jul 02, 2014 at 01:04:48PM -0700, Nathan Whitehorn wrote: > >> It worked at least on my Ultra 5 -- though probably because the ATI > >> Mach64 FCode ROM there is substantially shared with the Mac version. It > >> was even reasonably fast. But regardless of whether it's a generally > >> useful console driver on SPARC, at least it proves that vt(4) works fine. > > As for vt(4), it at least needs to be taught about the differences > > between virtual, physical and bus address with a clue bat. Among > > other problems, similar things hold for the #ifdef'ed sparc64 code > > of ofwfb(4) in combination with the accesses it does. I guess it > > only had a chance of working on your machine because its firmware > > is kind enough to map the framebuffer in (which not all machine > > models do) in the first place _and_ in a special way/location so > > accesses didn't blow. Anyway, even when going the ofwfb(4) route, > > doing reads and writes via bus_space(9) will be noticeably faster > > than going through the MMU on sparc64. > > Yeah, the firmware there is pretty kind. I just wanted to make sure we > were on the same page. The vt core does not require any changes, I > think: it's just that you need new drivers for mach64 and, especially, > creator.
Well, at least dev/fb/fbd.c committed as part of vt(4) should need some fixes and enhancements to work on sparc64 when it comes to running X. But yes, ofwfb(4) being PCI-centric is yet another problem. Marius _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
