Date: Wed, 2 Jul 2014 22:28:13 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Nathan Whitehorn <nwhitehorn@freebsd.org> 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: <20140702202813.GB69016@alchemy.franken.de> In-Reply-To: <53B465E0.1040309@freebsd.org> References: <201407021946.s62JkgHo051426@svn.freebsd.org> <53B465E0.1040309@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140702202813.GB69016>