Date: Wed, 02 Jul 2014 13:30:46 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Marius Strobl <marius@alchemy.franken.de> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r268173 - head/sys/conf Message-ID: <53B46BF6.6040205@freebsd.org> In-Reply-To: <20140702202813.GB69016@alchemy.franken.de> References: <201407021946.s62JkgHo051426@svn.freebsd.org> <53B465E0.1040309@freebsd.org> <20140702202813.GB69016@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53B46BF6.6040205>