svn commit: r268173 - head/sys/conf

[Nathan Whitehorn]

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