Re: recent rasops commits vs. macppc

[Michael <macallan%netbsd.org@localhost>]

Hello,

On Sun, 4 Aug 2019 11:29:58 +0900
Rin Okuyama <rokuyama.rk%gmail.com@localhost> wrote:

> Hi,
> 
> On 2019/08/04 1:00, Michael wrote:
> > On Sat, 3 Aug 2019 14:46:32 +0900
> > Rin Okuyama <rokuyama.rk%gmail.com@localhost> wrote:
> >   
> >> Maybe it's time to remove all non-32bit access to fb.
> >> I expect it is not a very hard work for now ;-).  
> > 
> > I seriously doubt that's the problem, because:
> > - 32bit powerpc doesn't really do 64bit accesses ( unlike sparc for
> >    example ) and altivec is disabled for kernel code ( since gcc started
> >    using altivec for optimized, inlined memcpy )
> > - at least one of the putchar_aa() methods used memcpy() in order to
> >    speed things up by rendering scanlines into cached memory and then
> >    quickly copying them into slow & uncached video memory, which worked
> >    just fine everywhere I tried ( that is, mips, powerpc, sparc, sparc64
> >    and arm )  
> 
> Thank you for your suggestive comments!
> 
> I probably found the cause of failure; new rasops allocates buffer and
> stamp dynamically via kmem_alloc. This may not work in early stages
> during boot.

That would do it - macppc sets up a rasops console *very* early during
kernel startup, before uvm is completely initialized. That's why there
is a RI_NO_AUTO flag to instruct rasops not to auto-generate line
drawing characters ( for fonts that don't have them ), which requires
allocating memory.

> I removed dynamical allocations. Could you please test the attached patch?

I will, thanks for working on this!

> >> PS
> >> I ordered Mac Mini G4, although serial console is hopeless...  
> > 
> > They're nice little machines which usually don't cause much trouble.
> > Opening them is quite painful though.  
> 
> Yeah, I look to forward to playing with it :-).

I have a few of them, there are a few quirks you may run into. If you
have questions don't hesitate to ask!

have fun
Michael