Hello, On Sun, 4 Aug 2019 11:29:58 +0900 Rin Okuyama <rokuyama...@gmail.com> wrote:
> Hi, > > On 2019/08/04 1:00, Michael wrote: > > On Sat, 3 Aug 2019 14:46:32 +0900 > > Rin Okuyama <rokuyama...@gmail.com> 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