On 07/03/14 12:52, Marius Strobl wrote:
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.
fbd needs a lot of help for a lot of reasons. It doesn't work with
early-boot console drivers at all, for example. The way all the fb stuff
connects is a horribly tangled evil octopus, as well. You'll notice that
ofwfb just ignores all of it at present.
But yes, ofwfb(4) being PCI-centric is yet another problem.
It isn't, actually, and will work perfectly well with non-PCI linear
framebuffers. If the device is a PCI device, it has some hacks to work
around broken firmwares. It also does some additional things in this
case to set the mapping write-combining flag when you use it to mmap()
physical memory (X UMS drivers do this). But I don't think SPARC
supports pmap_setattr() anyway.
-Nathan
_______________________________________________
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"
