Re: O2 framebuffer problems with install kernel

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Jul 28, 2008, at 06:39, Jorge Acereda Maciá wrote:

> I'm right now trying to install NetBSD-current on my 'new' O2, but  
> I get the vertical red strips referred to recently in this list.

You've got an R10k O2?

> Any idea on what the cause could be?

Nope, all we currently know is this:
- - it works fine on R5k O2s
- - it happens on R10k and newer CPUs
The graphics chipset is more or less identical on both so it must be  
the CPU. The big difference is that the R10k is superscalar ( MIPS  
claims the R5k is as well just because it can run an FP op in  
parallel with integer ops, by that logic an 8086/8087 combo is  
superscalar ) and its speculative memory accesses. I don't think it's  
missing memory barriers or something like that because even the R5k  
re-orders accesses even to uncached memory - I ran into that a few  
times - so pretty much every register access has a wbflush() attached  
to it.
So, I can only guess that the R1xk's speculative accesses bite us in  
the rear end but for that things look a bit too predictable to me.  
Unfortunately I can't debug this, my O2 is an R5k model.

> Will the framebuffer work if I install through serial port?

I seriously doubt it.

> I have some free time this week and I'm cross-building from my OSX  
> box, so if you have any suggestion I'm available to do some tests.

Have a look at sgimips/dev/crmfb.c, if you have any MIPS clue see if  
there's something obviously wrong that I'm missing. If you feel like  
it sprinkle wbflush() and maybe delay()s and see if that makes any  
difference ( there are a few instances where we wait for some busy  
bit to set or clear - you may want to put a delay() there in case  
we're too fast and grab those bits too early from some buffer or  
whatever. Maybe we need additional barriers there. Also you may want  
to sprinkle some printf()s for delays and progress reporting.
Oh, and the obvious bit - you may want to verify that your kernel  
really uses the MIPS-3 bus_space ops, especially the 64bit ones.  
CRIME has a bunch of 64bit wide registers that can only be written at  
64bit-aligned addresses, unaligned writes don't throw an error,  
they're silently ignored. 32bit writes work if they're 64bit aligned,  
so if by any chance you end up using MIPS-1 ops then 64bit writes get  
broken down into 2x 32bit which would royally screw up crmfb because  
the non-64bit-aligned write would be ignored and you'd write only the  
upper half of a register.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSI3OKcpnzkX8Yg2nAQIyCQf6AsXJ5DhzQ+FJXgyc8j1QZNn8trp70XZn
RUIKKkswDOsk+LJJlXovdRlYuz1q0t/pLMJ25wVMhI9opRLWSCROcMdjNHIMkxfr
VLzDdF3UU9XH93M2AY6k5bWbngkSMUh+lastbpfzU69nVFseGQYlTre2yxSMIzIO
0W7HmcioiBenqEgYc8pJED8kUGS8uJo6sqQhVxqRyjeMiJX3T20A+SooyXDV3ysP
5QMM0Fao6G/K0Hxr0ugtSNvdjy2rUZMwvP1Nm7cCpzbuE4jREsTgdMOaeX0EzCWc
mo+08tt9AGnOcv4JGcb/OF6Z5Cwba3j/mLkR8mDkEIS/mAeV0AyxrQ==
=y9yT
-----END PGP SIGNATURE-----